NavList:

   

Reply

One of the books on my shelf is "The Standard C Library" by P.J.
Plauger. It includes source code for all the functions, including
transcendentals such as sine and cosine. (Back in those days, you
couldn't assume the hardware included a floating point processor.) He
says you should never attempt to "help" a trig function by removing
multiples of a full circle from the argument. If the function was
written by a proficient numerical analyst, it already does that, and
probably better than you!

Of course angles aren't just passed to trig functions. They also
participate in arithmetic operations with each other, and in some cases
it helps to normalize the angles first. Suppose you add 720.1 + 360.1
with a hypothetical 4-digit calculator. The sum is 1080.2, which
displays as 1080. If you had performed a modulo 360 on both operands
first, the result would be the correct 0.2.

Henning makes much use trunc(): his function to remove multiples of 360
from angles. But I'm skeptical there's a benefit in practice, so I
rewrote his Javascript. I renamed his trunc() to oldtrunc(), and wrote a
new trunc():

function trunc(x)
{
return x;
}

In other words, it does nothing. The original trunc() implementation
must be retained because it's necessary in a few places:

1. Display formatting of mean and true sidereal time, GHA Sun, SHA Sun,
GHA Moon, SHA Moon, GHA Aries, GHA Polaris, and SHA Polaris. For
example, GHAsun = OutHA(oldtrunc(GHAsun));. Most of these are in
function Output(), but a couple are elsewhere.

2. At the end of function Sun(), the equation of time statement EOT =
4*oldtrunc(GHAsun)+720-1440*dayfraction;

3. In function MoonPhase(), the statement x = oldtrunc(x);


To test the new code, I loaded one tab of Internet Explorer with the
original code, and a second tab with the new code. At 10 randomly
selected times in the years 2000 - 2050, I held down the Ctrl key and
repeatedly pressed Tab. That switches back and forth between the browser
tabs. By watching for movement in the alternating images I verified
identical outputs in each test case. I also checked each Moon RA and
dec. against MICA. The worst discrepancy was 4", and the root of the
mean squared error was 2.7".

Henning's code is based on the work of Jean Meeus (Astronomical
Algorithms, ch. 45, Position of the Moon). Meeus says, "To avoid working
with large angles, reduce them to less than 360°.". Perhaps he's
unnecessarily fussy. I wrote a complete implementation of the same
chapter and reported results last October:

https://navlist.net/Moon-ephemeris-Meeus-vs-JPL-Hirose-oct-2015-g33245

My code doesn't normalize any angles. Its output is rectangular
coordinates so I don't have to deal with angles outside the normal range.

   

Reply