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

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

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


From: Philip Nienhuis
Subject: [Octave-patch-tracker] [patch #9958] [octave forge](mapping) gcxgc
Date: Fri, 14 Aug 2020 08:59:41 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0

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

I'm reviewing & adapting your latest contribution in more detail.
Some code needs to be properly "vectorized" (actually: adapted to allow vector
inputs), a.o. L.182 & 185 (".^" rather than just "^") and the cross product in
L.134 that needs a 3rd DIM argument (in this case: 2).
While similarly adapting the if block in L.154-166 it turned out that the
invoked computation method is still unreliable:

## Correct:
>> [a, b] = gcxgc (45, 45, 90, -40, -135, 90)
warning: gcxgc: Non-unique intersection.
a =
   NaN   NaN
b =
   NaN   NaN

>> [a, b] = gcxgc (45, 45, 90, -40, -135, 90)
warning: gcxgc: Non-unique intersection.
a =
   NaN   NaN
b =
   NaN   NaN
## Incorrect. (45, 45) and (-40, -135) are no antipodes so
## even though the great circles have horizontal W tangents in
## those coordinates they do not coincide. Same of course for:
>> [a, b] = gcxgc (40, 45, 90, -40, -135, 90)
warning: gcxgc: Non-unique intersection.
a =
   NaN   NaN

b =
   NaN   NaN


The gcxgc3.m I uploaded yesterday works fine and gives more accurate results
than Matlab. I tend to -for the time being- use that one until/unless you want
to improve the code from the comment #15 version.

What's your opinion?

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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