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

[Philip Nienhuis]

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)


    _______________________________________________________

Reply to this item at:

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

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