NavList:

"Frank Reed" <FrankReedCT@aol.com> wrote:

>   To calculate this, draw the Moon-Zenith-Sun triangle leaving enough
>   room to draw a little picture of the Moon including the line of cusps.
>   That line will always be exactly perpendicular to the Moon-Sun arc.
>   Calling LD the angle between the Sun and Moon, and h1 and h2 the
>   altitudes of the Moon and Sun respectively, you can calculate a
>   quantity which is the "corner cosine" at the Moon in the triangle:
>      A = [sin(h2) - sin(h1)*cos(LD)] / [cos(h1)*sin(LD)].
>   This follows directly and simply from the cosine formula of spherical
>   trigonometry (and swapping altitudes, h1 and h2, for zenith distances,
>   z1 and z2. The quantity A is the cosine of the angle between the
>   Moon-Sun arc and the vertical arc passing through the Moon. If A is
>   less than zero, the navigator should shoot the Lower Limb. If A is
>   greater than zero, shoot the Upper Limb.

Yes, that looks right.  Certainly a simpler formula than mine.

>   Jim Van Zandt's very slick vector approach to the problem should
>   yield the same results (though he works in terms of the azimuth
>   difference between the two bodies instead of the great circle
>   angle between them). 

I wasn't sure LD would be conveniently available.  Near full moon (the
case that started this thread) the sun and moon will both be visible
only briefly if at all, and the distance is much greater than the 120
degree limit of the typical sextant, so it may be hard to measure.
The distance is tabulated for use in calculating the current time
(method of lunars), but, again, usually only for times when both are
visible.

>   Say, Jim, just of out "math culture" curiosity, where, or rather,
>   in what course of study, did you learn to do angular positional
>   calculations that way? I'm so accustomed to the spherical trig
>   approach that I never think of using vectors for these problems,
>   though of course they are geometrically equivalent.

My degree is in physics, but I have been doing engineering for quite a
while (e.g. radar target tracking). 

I have been bit several times by programs based on trig (flat or
spherical) which work fine for the case you draw your initial sketch
for, but then blow up at some later time.  Sometimes the problem is
numerical instability (e.g. involving the cosine of a very small
angle).  Other times it is choosing the wrong branch (positive or
negative square root, asin less than or greater than 90 degrees).  So
my general approach to a problem involving angles is:

1) If it can be done by applying rotation matrices, then do it that
   way.  Rotating is always stable.

2) Otherwise, if it can be done with vector operations (dot or cross
   products), then do it that way.

3) Don't use acos or asin, because these have the numerical
   instability and branch selection problems mentioned above.  If I
   have found a formula for the cosine of the angle I need, I am only
   half finished.  I next look for an independent formula for the sine
   of the angle.  Then I use atan2. 

   (When I first learned FORTRAN, it had atan2 but not asin or acos.
   The next version of the language had both functions, and I thought
   it was great.  Now I think the original language designers had the
   right idea.)

             - Jim Van Zandt

p.s. I believe I ran across an article in the archives where George
Huxtable was advocating atan2 for similar reasons.

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to NavList@fer3.com
To , send email to NavList-@fer3.com
-~----------~----~----~----~------~----~------~--~---