[Octave-bug-tracker] [bug #65291] [octave forge] (mapping) degrees2dms produces incorrect results

[anonymous]

Follow-up Comment #17, bug #65291 (group octave):


> 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])




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65291>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/