[Top][All Lists]

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

[Octave-patch-tracker] [patch #9974] [octave forge](mapping) gc2sc scxsc

From: Philip Nienhuis
Subject: [Octave-patch-tracker] [patch #9974] [octave forge](mapping) gc2sc scxsc gcxsc
Date: Fri, 2 Oct 2020 02:29:17 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #8, patch #9974 (project octave):

Just to keep you informed:
Yesterday I've been playing a bit with the logic in the Stackoverflow post
mentioned in scxsc.m. Using sind/cosd/atan2d I got it to work perfectly for
small circles on perpendicular axes (lat1/lon1 = (0, 0); lat2/lon2 = (0, 90)
with radii of 45 degrees, i.e. output of 2 X lat/lon = (0, 45), the one
intersection/tangential point.
But any other values (e.g., radii of 45 and 46 degrees) gave wrong results
(like 134.some for lon and/or lat => wrong hemisphere). Could be an atan2
input issue (IOW output is not the principal value). But also smaller values
failed in other ways.
The SO procedure seems mathematically correct to me but I'm a bit wary of the
corner cases.

In any case there should be checks on x02 and n2 to be max. 1, to avoid
complex intermediate outcome when later on sqrt() is fed a very small negative

Which makes me think that the scxsc.m code at large may need to become more
robust against internal rounding errors / inaccuracies of the goniometric
functions. Also, as stated in the S.O. post, the cross product's accuracy may
be a factor.

To be continued :-)


Reply to this item at:


  Message sent via Savannah

reply via email to

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