[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #65291] [octave forge] (mapping) degrees2dms p
From: |
anonymous |
Subject: |
[Octave-bug-tracker] [bug #65291] [octave forge] (mapping) degrees2dms produces incorrect results |
Date: |
Wed, 6 Mar 2024 23:16:48 -0500 (EST) |
Follow-up Comment #9, bug #65291 (group octave):
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?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65291>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
- [Octave-bug-tracker] [bug #65291] [octave forge] (mapping) degrees2dms produces incorrect results,
anonymous <=
Message not available
Message not available
Message not available
Message not available
Message not available
Message not available
Message not available
Message not available