[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-patch-tracker] [patch #9953] [octave forge] (mapping) angl2str

From: Philip Nienhuis
Subject: [Octave-patch-tracker] [patch #9953] [octave forge] (mapping) angl2str
Date: Sat, 29 Aug 2020 17:42:41 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #10, patch #9953 (project octave):

Hi Ricardo,

My pleasure.

It's not that have something to commit ("push") yet, just your version with
your round.m absorbed as subfunction with input validation commented out; plus
a version with only *some* stye fixes yet, more to come in the next days.

It just occurred to me that there's also *roundn.m* in the mapping package -
could you please check if that fits your needs for anglstr.m rather than
round.m? If yes the code could be even simpler as round.m wouldn't be needed
at all then.

Furthermore I just saw an issue:

>> angl2str ([-181.6999; -181.699999; -181.6999999999; -181.7; 181.71], 'ew',
'degrees2dms', -4)
ans =
 181° 41' 59.6400" W
 181° 41' 59.9964" W
 181° 41' 00.0000" W
 181° 41' 00.0000" W
 181° 42' 36.0000" E

where in the steps from -181.699999 .. -181.7 some erroneous wrapping occurs;
somewhere in that sequence I'd expect minutes to go to 42, not stay 41. No
doubt this is related to rounding somewhere, but whatever the cause it is
I just checked with Matlab and that yielded a remarkable result for -181.7:
while it gets the total right as it returns <degrees> 41' 60", it should of
course round to 42' 00". Hmmm, wonky rounding as well there ...

To check this sort of rounding stuff around critical values like 180 or 360
degrees, or 0 (zero), etc., I usually enter a small input range around such
values with a tiny increment along the lines of:

output = <function> ([start : 1e-9 : end], < rest of input args>);

and then check for monotony in the output (min/max (diff (output)), for
strings usually after applying some regexps & str2double & optional
postprocessing. You'd be surprised to see how many problems sometimes turn up
then :-)
(but in the above case I didn't even get that far, I was just trying a few
values to compare with Matlab.)

Could you have a look at these two things, please? (roundn.m and that accuracy


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]