octave-patch-tracker
[Top][All Lists]

[Octave-patch-tracker] [patch #9958] [octave forge](mapping) gcxgc

 From: Philip Nienhuis Subject: [Octave-patch-tracker] [patch #9958] [octave forge](mapping) gcxgc Date: Thu, 30 Jul 2020 16:36:42 -0400 (EDT) User-agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0

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

Hmmm, this doesn't make sense:

>> [a, b] = gcxgc3 (0, 0, 90, 0, 180, 80)
warning: gcxgc: Non-unique intersection.
warning: called from
gcxgc3 at line 132 column 5

a =
NaN   NaN

b =
NaN   NaN

The azimuths are clearly different, aren't they?
Matlab gives:

>> [a, b] = gcxgc3 (0, 0, 90, 0, 180, 80)
a =
1.0e-6 *
-0.3632   -0.3632
b =
0.0000  180.0000
>>

and your previous version yields the same, even much more accurate than
Matlab.

But then:

>> [a, b] = gcxgc2 (90, 0, 90, -90.000001, 180, 80) ## previous version
error: atan2: not defined for complex numbers
error: called from
gcxgc2 at line 126 column 10
## new version
>> [a, b] = gcxgc3 (90, 0, 90, -90.000001, 180, 80)
a =
-89.99999432871816   89.99999432871817

b =
-90.00000003544301   89.99999996455699

==> I think there should be a check for latitudes at or beyond the N and S
poles. That's a straightforward fix. Probably by chance your new version
correctly detects latitudes exactly at the poles through the math, but not so
beyond the poles.

(FYI Matlab accepts and gives finite answers for any latitude != 90 or -90
degrees, incl. +90.00001 and -90.00001 - the latter incorrectly IMO. Matlab
doesn't document this or any wrapping around the [-90,90] interval)

_______________________________________________________

<https://savannah.gnu.org/patch/?9958>

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

```