bugGNU Octave - Bugs: bug #65291, [octave forge] (mapping)...

 
 

bug #65291: [octave forge] (mapping) degrees2dms produces incorrect results

Submitter:  Goran Gasparovic <gasparovic>
Submitted:  Sun 11 Feb 2024 01:14:53 PM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Patch Submitted Assigned to:  philipnienhuis
Originator Name:  Goran Gasparovic Open/Closed:  * Open
Release:  * other Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 28 Mar 2024 07:34:54 AM UTC, comment #17: 


> Hopefully I'll be able to review it in the coming weeks, I hope you're not offended by that time schedule.

Certainly not offended.  There have been some large delays for my posts here as well, and that may continue.

> As to sign handling - isn't it just so that the input sign simply carries over to only the degrees part?

It's more complicated than that.  As stated in the help text I revised, "The sign of the first nonzero output component matches the sign of the input, and the other output components are not less than zero".  I intentionally avoided documenting the sign of zeros, but a more complete description of the actual behavior would be "The signs of output components not after a nonzero output component match the sign of the input, and any other output components have positive sign".

> Then, I haven't tested the degrees2* functions but I know that many Matlab mapping functions happily accept latitude values that are larger (or smaller) than 90 (or -90) degrees; same for longitudes > 360 or < -360.  I don't know any use for such values (but who am I, I'm just a hydrogeologist and a hobby sea sailor using maps quite regularly :-) ).

Inputs larger than 360 make more sense if they're just generic angles instead of coordinates.  Also, degrees2dms could be used to convert hours to hours, minutes, and seconds.  Maybe the documentation should mention that.

> So in various mapping functions (mainly coordinate transforms IIRC, it's a while ago) I've added wrapping functions - I haven't looked yet but degrees2dms.m and degrees2dm.m may also need it and/or benefit from it.

I'm not sure this is what you mean, but I don't think it makes sense for wrapping to be built in to degrees2dm or degrees2dms.  Better to let the user do whatever wrapping they need beforehand.

> Now, looking at comment #13 for the first time I see some questionable Matlab outputs. For values of +-Inf I'd rather see a warning or maybe even an error. Returning Infs (that contrary to NaNs allow some further computations) may have been chosen by TMW to allow processing to continue, implicitly accepting the risk of hard-to-uncover errors or even silently returned wrong results in later stages. Coming from the practical rather than theoretical side I tend to find this a bit of an irresponsible choice.
> What would be your opinion?

I might agree if we were talking about angl2str, but not for degrees2dms and degrees2dm.  The standard approach for handling NaNs and infinities seems well established, and I think deviating for these functions would cause more problems that it would solve.  Anyone who needs to check for special values can easily do so, and may be able to do so in a more convenient location within their program.

> As to anonimity: sure, you're not the first, but it'll have to pushed under someone's name and that'll probably be mine. But I'll credit "Anonymous" in the commit message.
> OK?

That's fine.


> In a spell between other work I just tried this with your new degrees2dms.m:
> where minute values still can be 60 and don't overflow to minutes.

Well, as you demonstrated with `format long`, the seconds values are actually less that 60.  They are just displayed as 60 with certain settings.  The functions I provided will never return minutes or seconds with magnitude greater than or equal to 60.

> To have proper output, seconds >= 59.5 (rather than >= 60.0-eps) need to overflow to minutes.

Why?  That's certainly not the documented behavior.  For a latitude coordinate on Earth, it could change the location by 15 m.

Setting aside performance, implementation simplicity, and MATLAB compatibility, why should the output angle be anything other than as close as possible to the input angle?

> IIRC that's also what I did for angl2str.m (patch #9953).

I didn't look at that patch specifically, but with mapping-1.4.2, `angl2str(1 + 59.99/3600, 'pm', 'degrees2dms')` returns ` +1° 00' 59.99" `

> still mostly bug-for-bug compatible with Matlab (although just a tiny bit better :-) see last-but-one row):

I wonder if the different output in that case is actually due to different input caused by different behavior of `1 : 0.6 : 5`.  I believe the exact meaning of such expressions is not documented in Octave or MATLAB.  Something like `[0:6] * 0.6 + 1` where the increment is an integer seems more likely to produce the same result everywhere.

If MATLAB's degrees2dms and degrees2dms.m from my previous comment actually produce different outputs for the same inputs, I would be interested to learn more.

> (where you can also see that Matlab warns about a wrong dimension of the input vector while Octave doesn't.)

It seems the warning is disabled by default in Octave, but it can be demonstrated as follows:

warning('on', 'Octave:array-to-vector')
degrees2dms([1, 2])


Anonymous
Mon 25 Mar 2024 03:00:23 PM UTC, comment #16: 

In a spell between other work I just tried this with your new degrees2dms.m:

>> degrees2dms ([1 : 0.6 : 5]')
ans =
    1.0000         0         0
    1.0000   36.0000    0.0000
    2.0000   12.0000    0.0000
    2.0000   47.0000   60.0000
    3.0000   23.0000   60.0000
    4.0000         0         0
    4.0000   35.0000   60.0000

where minute values still can be 60 and don't overflow to minutes.
Or,

>> format long
>> degrees2dms ([1 : 0.6 : 5]')
ans =
   1.000000000000000e+00                       0                       0
   1.000000000000000e+00   3.600000000000000e+01   4.263256414560601e-13
   2.000000000000000e+00   1.200000000000000e+01   6.394884621840902e-13
   2.000000000000000e+00   4.700000000000000e+01   5.999999999999915e+01
   3.000000000000000e+00   2.300000000000000e+01   5.999999999999957e+01
   4.000000000000000e+00                       0                       0
   4.000000000000000e+00   3.500000000000000e+01   5.999999999999872e+01

To have proper output, seconds >= 59.5 (rather than >= 60.0-eps) need to overflow to minutes. IIRC that's also what I did for angl2str.m (patch #9953).

Yet I wonder if we should hunt down this all the way or just leave it as-is. It's not pretty but still mostly bug-for-bug compatible with Matlab (although just a tiny bit better :-) see last-but-one row):

>> degrees2dms ([1 : 0.6 : 5])
Warning: Reshaping input into 7-by-1 column vector.  Output will be 7-by-3.
> In degrees2dms (line 57)
ans =
    1.0000         0         0
    1.0000   36.0000    0.0000
    2.0000   12.0000    0.0000
    2.0000   47.0000   60.0000
    3.0000   23.0000   60.0000
    3.0000   59.0000   60.0000
    4.0000   35.0000   60.0000

(where you can also see that Matlab warns about a wrong dimension of the input vector while Octave doesn't.)

Philip Nienhuis <philipnienhuis>
Group Member
Fri 22 Mar 2024 08:44:50 PM UTC, comment #15: 

Thank you very much Anonymous for the contribution.
Hopefully I'll be able to review it in the coming weeks, I hope you're not offended by that time schedule.
I'll also check out degrees2dm.m (bug #65508).

Some initial comments:

As to sign handling - isn't it just so that the input sign simply carries over to only the degrees part? I'm unsure here, but TTBOMK, DMS coordinates in real world navigation are represented as <dd[NSWE] mm ss> where negative signs are are morphed to S or E and the minutes and seconds values point in the pertinent N / S / E or W direction.

Then, I haven't tested the degrees2* functions but I know that many Matlab mapping functions happily accept latitude values that are larger (or smaller) than 90 (or -90) degrees; same for longitudes > 360 or < -360.  I don't know any use for such values (but who am I, I'm just a hydrogeologist and a hobby sea sailor using maps quite regularly :-) ). So in various mapping functions (mainly coordinate transforms IIRC, it's a while ago) I've added wrapping functions - I haven't looked yet but degrees2dms.m and degrees2dm.m may also need it and/or benefit from it.
Now, looking at comment #13 for the first time I see some questionable Matlab outputs. For values of +-Inf I'd rather see a warning or maybe even an error. Returning Infs (that contrary to NaNs allow some further computations) may have been chosen by TMW to allow processing to continue, implicitly accepting the risk of hard-to-uncover errors or even silently returned wrong results in later stages. Coming from the practical rather than theoretical side I tend to find this a bit of an irresponsible choice.
What would be your opinion?

As to anonimity: sure, you're not the first, but it'll have to pushed under someone's name and that'll probably be mine. But I'll credit "Anonymous" in the commit message.
OK?

Philip Nienhuis <philipnienhuis>
Group Member
Fri 22 Mar 2024 03:46:29 PM UTC, comment #14: 

Thanks for the additional MATLAB output.

Attached is a version of degrees2dms.m along the lines of the first option I described in comment #11.  Changes compared to the current version at https://sourceforge.net/p/octave/mapping/ci/default/tree/inst/degrees2dms.m are as follows:

  • Documentation:
    • Specify that the minutes and seconds components will always have magnitude less than 60.
    • Adjust the first example to make everything exact and to demonstrate fractional seconds.
    • Remove the second example which was incorrect and is now redundant.
    • Simplify and hopefully clarify the explanation of sign handling.
    • Remove the negative sign (which does not seem to be displayed by default) from a zero in the result in the last example.
  • Implementation:
    • Reject non-real input.
    • Add special handling for char and logical input to improve performance and clarity.
    • Change the computation of the seconds to improve accuracy.  Output should now match that of MATLAB R2023b for class single, and I suspect it matches for class double as well.
      • Overflow for large inputs is avoided.
      • Minutes and seconds now depend only on the fractional part of the input.
      • Possible issues are avoided by not using the rem function.  Documentation for rem claims that "values within a few eps of an integer will be rounded to that integer before computation for compatibility with MATLAB", but I have failed to verify this.
    • Update the sign-flipping logic to produce same output as MATLAB R2023b, and hopefully improve clarity.
    • Reject input types not explicitly handled.
      • This might be unreachable currently, but is intended to prevent applying the function to types where it hasn't been validated.  Not sure this is a good idea.
  • Tests:
    • Remove tests enforcing incorrect results.
    • Add tests, including extensive checks of values near transition points where issues seem most likely.
  • Other:
    • Add `## Copyright (C) 2024 The Octave Project Developers` because I am offering this contribution anonymously.


My offer to provide a more accurate version (the second option I described in comment #11) still stands.  Please let me know if this is desired.

See also bug #65508 for degrees2dm.m which I just opened.


(file #55881)

Anonymous
Tue 12 Mar 2024 03:34:55 PM UTC, comment #13: 

here are the comment #9 outputs in Matlab 2023b:


>> format long
>> x = [Inf; -Inf; 0; -0; -0.01; -0.5; -0.51; -5; -5.01; -5.5]
x =
                 Inf
                -Inf
                   0
                   0
  -0.010000000000000
  -0.500000000000000
  -0.510000000000000
  -5.000000000000000
  -5.010000000000000
  -5.500000000000000
>> 1 ./ x
ans =
   1.0e+02 *
                   0
                   0
                 Inf
                -Inf
  -1.000000000000000
  -0.020000000000000
  -0.019607843137255
  -0.002000000000000
  -0.001996007984032
  -0.001818181818182
>> degrees2dms(x)
ans =
                 Inf                 NaN                 NaN
                -Inf                 NaN                 NaN
                   0                   0                   0
                   0                   0                   0
                   0                   0 -36.000000000000000
                   0 -30.000000000000000                   0
                   0 -30.000000000000000  36.000000000000085
  -5.000000000000000                   0                   0
  -5.000000000000000                   0  35.999999999999233
  -5.000000000000000  30.000000000000000                   0
>> 1 ./ ans
ans =
                   0                 NaN                 NaN
                   0                 NaN                 NaN
                 Inf                 Inf                 Inf
                -Inf                -Inf                -Inf
                -Inf                -Inf  -0.027777777777778
                -Inf  -0.033333333333333                 Inf
                -Inf  -0.033333333333333   0.027777777777778
  -0.200000000000000                 Inf                 Inf
  -0.200000000000000                 Inf   0.027777777777778
  -0.200000000000000   0.033333333333333                 Inf
>> degrees2dm(x)
ans =
                 Inf                 NaN
                -Inf                 NaN
                   0                   0
                   0                   0
                   0  -0.600000000000000
                   0 -30.000000000000000
                   0 -30.600000000000001
  -5.000000000000000                   0
  -5.000000000000000   0.599999999999987
  -5.000000000000000  30.000000000000000
>> 1 ./ ans
ans =
                   0                 NaN
                   0                 NaN
                 Inf                 Inf
                -Inf                -Inf
                -Inf  -1.666666666666667
                -Inf  -0.033333333333333
                -Inf  -0.032679738562092
  -0.200000000000000                 Inf
  -0.200000000000000   1.666666666666702
  -0.200000000000000   0.033333333333333


Nicholas Jankowski <nrjank>
Group Member
Sat 09 Mar 2024 10:31:29 PM UTC, comment #12: 

I can provide Matlab output for the comment #9 tests but I'm away until somewhere next wek. Hang on ...

Philip Nienhuis <philipnienhuis>
Group Member
Fri 08 Mar 2024 08:05:49 PM UTC, comment #11: 

Somehow I didn't realize the Octave mapping package had angl2str.  Thanks for pointing that out.

> > Does the `elseif (ischar (deg))` branch prevent some incorrect result, or was it just added for clarity or to save unnecessary computation?
> Again, degrees2dms.m is not my code.

Based on your comment #2 I thought you added that part.  Maybe I didn't understand what you meant.

> Then, you mention a d2dms function you wrote. Would you like to swap the current mapping function's code with your code? Or amend it with your code?
> I'm all open to suggestions.

I am offering to modify the current degrees2dms function to resolve the off-by-one-minute issue, improve tests, and correct some issues in the documentation.  To calculate the magnitudes of the degrees-minutes-seconds components, I propose to use one of the following two methods:

  • The method used in the d2dms function I provided in comment #6.
    • Accuracy is reasonable.  Recomputing degrees from the output as `s/3600 + m/60 + d` seems to be within 1 ulp or so of the original input.
    • It is quite simple.
    • Hopefully it is reasonably easy to become convinced that it has no major issues.
    • Performance is good.
    • Based on comment #7 it seems to MATLAB-compatible for single.  I would guess it is for double as well.
  • A more accurate method I developed.
    • Output angle is as near as possible to the input angle.
    • It is roughly four times more complicated.
    • It was not very easy to convince myself that it's correct.  I still wouldn't put my confidence over 99%.
    • Performance on my machine is roughly two times worse.
    • Due to the better accuracy, it is not MATLAB-compatible.


I am seeking input as to which approach would be preferred.

As for the handling of negative inputs, I am hopping someone will be able to provide MATLAB output for the test in comment #9.

Anonymous
Thu 07 Mar 2024 07:34:37 PM UTC, comment #10: 

Hi Anonymous,

Again, degrees2dms.m is not my code. Feel free to suggest improvements and if we agree (I'm probably easy to convince here) they can be pushed.

What you write about angle2str.m's rounding might (partly?) have been covered in patch #9953. At least, in my reminiscence of handling that contribution we had some rounding issues resembling the current bug subject.

> Hopefully we agree that the output of degrees2dms must always have the following properties (assuming finite input):

I'm not so sure anymore that minutes and seconds should overflow to degrees and minutes, resp., if (rounded) they reach integer 60 (sign to be taken into account obviously, but signs only apply to the degrees section). But they should overflow if their binary representation surpasses integer 60. So there's some room for "suggested accuracy" there beyond pure integer representations.
Moreover, I see no reason for the smallest unit (seconds here) to be strictly integer. That can be covered in some extra input parameter (as far as I'm concerned we need not be limited to strictly Matlab compatibility here, we can offer "more").
For the rest I agree.

> Regarding the other changes in the file attached to comment #2:

Matlab's degrees2dms doesn't seem to have rigid input validation, it just uses the int8 of uint8 values of character input (...)

> Does the `elseif (ischar (deg))` branch prevent some incorrect result, or was it just added for clarity or to save unnecessary computation?

Again, degrees2dms.m is not my code.

Then, you mention a d2dms function you wrote. Would you like to swap the current mapping function's code with your code? Or amend it with your code?
I'm all open to suggestions.

BTW I plan to make a new mapping pkg release somewhere this summer. All that is keeping me from it is switching to the Octave-packages way of doing things ("my" packages mapping and io are still at SourceForge).
So, a better degrees2dms.m would fit in the plan ...

Philip Nienhuis <philipnienhuis>
Group Member
Thu 07 Mar 2024 04:16:48 AM UTC, comment #9: 

nrjank,

Thanks for fixing the comparison operators and running my test.  Assuming no logic errors, the output demonstrates that my d2dms function exactly matches MATLAB's degrees2dms for all finite arguments of class single with positive sign.

To understand how infinities and signed zeros are handled, I would also be interested to see the output of MATLAB for the following:

x = [Inf; -Inf; 0; -0; -0.01; -0.5; -0.51; -5; -5.01; -5.5]
1 ./ x
degrees2dms(x)
1 ./ ans
degrees2dm(x)
1 ./ ans



philipnienhuis,

The degrees2dms function just returns an array of numbers.  Converting an angle to text of the form dd°mm′ss.sss″ or similar sounds like a job for a different function.  For example, MATLAB's angl2str function is seemingly intended to cover this use case.

Hopefully we agree that the output of degrees2dms must always have the following properties (assuming finite input):

  • The degrees and minutes components are integers.
  • The minutes and seconds components have magnitudes less than 60.
  • The sign of the first nonzero component matches that of the input.
  • Components after the first nonzero component not less than zero.


Beyond that, it would arguably be ideal to return a result which is as near as possible (in the angular sense) to the input angle (which may not be exactly representable in degrees-minutes-seconds form).  Unfortunately this is more complex (especially for inputs of class double) and less MATLAB-compatible than the approach from my d2dms function.  I am willing to offer an implementation of either approach.  Thoughts?

Regarding the other changes in the file attached to comment #2:


    ## Formally not Matlab-compatible (only real input accepted)
    ## but Matlab still accepts it


  elseif (ischar (deg))
    ## Formally not Matlab-compatible as well (only real input accepted)
    ## but Matlab still accepts it
    dms = [fix(deg(:)) zeros(numel (deg), 2)];


I'm not exactly sure what the MATLAB documentation means by "real-valued", but certainly all possible values of the integer types are real numbers.  The isreal function is documented to return true for these, and for char and logical types as well.  I don't see any evidence of incompatibility here.  I do note that we don't actually reject complex inputs though.

Does the `elseif (ischar (deg))` branch prevent some incorrect result, or was it just added for clarity or to save unnecessary computation?

Anonymous
Tue 13 Feb 2024 09:00:18 PM UTC, comment #8: 

OK I'll set status back to just "confirmed".

These functions (degrees2dms, dms2degrees, dm2degrees, dms2degrees) haven't been written by me.  While their code looks quite straightforward, corner cases like losing seconds or minutes easily fall victim to double (im)precision that isn't catched properly.
I'm also a bit surprised that this bug pops up only now.

As an aside:
Degrees-minutes-seconds display output like [1, 11, 60] looks a bit wonky as it suggests that a minute can be subdivided in 61 ... yeah, what? 'intervals'? rather than 60 seconds (0..60 rather than 0..59). OTOH display output like in comment #2, where output precision is much higher, is accurate. It is the display rounding that's hard to get right.
So I can understand e.g. Matlab in emitting such results - it's a lot easier to not have to worry about carry-over when rounding to display precision. But in most practical use (e.g., navigating at sea) it would be frowned upon and most navigation SW I know either doesn't accept such input or morphs it into "proper" display rounding.

From comment #2:

> when rounded to nearest double is [1, 11, 59.9999999999998436805981327779591083526611328125]

Rounding to display precision (IIUC different than "double precision") should give [1, 12, 0].  On the surface of the Earth the inaccuracy would be in the order of 3^(-10) m:

>> (60 - 59.9999999999998436805981327779591083526611328125) * 1852
ans = 2.895035322580952e-10

(one minute ~ a nautical mile = 1852 m)

I might give fixing it another try later on, but I have little time to devote to it, sorry. Hopefully someone beats me to it.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 13 Feb 2024 06:38:40 PM UTC, comment #7: 


a = single(0:(2 .^ 23 - 1)) .';
b = 1 + a .* eps('single');
positive_normal_mismatches = 0;
positive_normal_total = 0;
for p = (-126):127
d = pow2(p) .* b;
positive_normal_mismatches = positive_normal_mismatches + sum(any(d2dms(d) ~= degrees2dms(d), 2));
positive_normal_total = positive_normal_total + numel(d);
end
positive_normal_mismatches
positive_normal_mismatches =
     0
positive_normal_matches = positive_normal_total - positive_normal_mismatches
positive_normal_matches =
     2.130706432000000e+09
d = pow2(-149) .* a;
positive_zero_and_subnormal_mismatches = sum(any(d2dms(d) ~= degrees2dms(d),2))
positive_zero_and_subnormal_mismatches =
     0
positive_zero_and_subnormal_matches = numel(d) - positive_zero_and_subnormal_mismatches
positive_zero_and_subnormal_matches =
     8388608


Nicholas Jankowski <nrjank>
Group Member
Tue 13 Feb 2024 05:44:03 PM UTC, comment #6: 

It would be interesting to see the output of MATLAB for the following which I expect will run in less than 5 minutes:


format long

function dms = d2dms (d)
  df = fix(d);
  m = (d - df) .* 60;
  mf = fix(m);
  s = (m - mf) .* 60;
  dms = [df, mf, s];
end

a = single(0:(2 .^ 23 - 1)) .';
b = 1 + a .* eps('single');

positive_normal_mismatches = 0;
positive_normal_total = 0;
for p = (-126):127
  d = pow2(p) .* b;
  positive_normal_mismatches = positive_normal_mismatches + sum(any(d2dms(d) != degrees2dms(d), 2));
  positive_normal_total = positive_normal_total + numel(d);
end
positive_normal_mismatches
positive_normal_matches = positive_normal_total - positive_normal_mismatches

d = pow2(-149) .* a;
positive_zero_and_subnormal_mismatches = sum(any(d2dms(d) != degrees2dms(d), 2))
positive_zero_and_subnormal_matches = numel(d) - positive_zero_and_subnormal_mismatches


Anonymous
Tue 13 Feb 2024 01:50:47 PM UTC, comment #5: 

yes, seems like we're still losing the minute:

matlab:

>> degrees2dms(2-eps())
ans =
   1.000000000000000  59.000000000000000  59.999999999999147


the BIST was likely just set without considering float or display error.

again, matlab gives:


>> degrees2dms(10+0.5/60)
ans =
   10.0000         0   30.0000

>> format long
>> ans
ans =
  10.000000000000000                   0  29.999999999998295

>> [10 0 30] - ans
ans =
   1.0e-11 *
                   0                   0   0.170530256582424



Nicholas Jankowski <nrjank>
Group Member
Tue 13 Feb 2024 06:49:43 AM UTC, comment #4: 

With the proposed fix from comment #2, degrees2dms(2 - eps()) returns [1, 60, 59.9999999999990905052982270717620849609375] for me, which is off by 1 minute or so.

If a well-defined specification for this function can be developed, it might be feasible for proposed implementations to be exhaustively tested on inputs of class single.

Some of the current test cases seem strange.  For instance, the exact result for degrees2dms(10 + 0.5 / 60) would be [10, 0, 29.9999999999982946974341757595539093017578125] which is exactly representable, but a test requires it to return exactly [10, 0, 30].

Anonymous
Mon 12 Feb 2024 10:53:19 PM UTC, comment #3: 

In Octave, 1.2 means the nearest double which is actually 1.1999999999999999555910790149937383830547332763671875.  The exact result for this input would be [1, 11, 59.999999999999840127884453977458178997039794921875] which when rounded to nearest double is [1, 11, 59.9999999999998436805981327779591083526611328125].

Anonymous
Mon 12 Feb 2024 05:40:03 PM UTC, comment #2: 

Please try with attached degrees2dms.m and report back.

Put it somewhere in your path before the mapping package paths, or try to swap it with the one in the mapping package. You can find that one using:
which degrees2dms
in Octave's command window.
If it works for you I'll push a fix.


The original bug got fixed by just adding or subtracting eps.
But Octave's degrees2dms, like Matlab's, also accepts logical and character input although the Matlab docs only mention "real-valued input". So the fix needed some extra provisioning.
It all feels a bit like a kludge but it works for me.

Status set to "patch submitted".

(file #55687)

Philip Nienhuis <philipnienhuis>
Group Member
Sun 11 Feb 2024 03:48:58 PM UTC, comment #1: 

checking in matlab 2023b:


>> degrees2dms(1.2)

ans =

    1.0000   11.0000   60.0000

>> ans - [1 11 60]

ans =

   1.0e-12 *

         0         0   -0.2132


vs octave (9.0.91), mapping 1.4.2 (which loads matgeom 1.2.3 and geometry 4.0.0):


>> degrees2dms(1.2)
ans =

    1   11    0


>> ans - [1 11 0]
ans =

   0   0   0


marking as confirmed, cc'ing pkg maintainer.

Nicholas Jankowski <nrjank>
Group Member
Sun 11 Feb 2024 01:14:53 PM UTC, original submission:  

Bug report, octave-8.4.0-w64.7z, "Intel(R) Core(TM) i3-5005U CPU @ 2.00GHz   2.00 GHz".


-----
>> pkg load mapping
warning: function (...) octave-8.4.0-w64\octave-8.4.0-w64\mingw64\share\octave\packages\matgeom-1.2.3\geom2d\normalize.m shadows a core library function (...)
>> degrees2dms (1.2)
ans =
    1   11    0
-----


The answer should be [1 12 0].

Goran Gasparovic <gasparovic>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #55881:  degrees2dms.m added by None (6KiB - application/octet-stream)
file #55687:  degrees2dms.m added by philipnienhuis (4KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by nrjank
  • -email is unavailable- added by gasparovic (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-03-22 philipnienhuis Assigned toNone philipnienhuis
    2024-03-22 philipnienhuis StatusConfirmed Patch Submitted
    2024-03-22 None Attached File- Added degrees2dms.m, #55881
    2024-02-13 philipnienhuis StatusPatch Submitted Confirmed
        Assigned tophilipnienhuis None
        Operating SystemMicrosoft Windows Any
    2024-02-12 philipnienhuis Attached File- Added degrees2dms.m, #55687
        StatusConfirmed Patch Submitted
        Assigned toNone philipnienhuis
    2024-02-11 nrjank StatusNone Confirmed
        Release8.4.0 other
        SummaryPkg mapping: degrees2dms [octave forge] (mapping) degrees2dms produces incorrect results
        Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code