Welcome to the NavList Message Boards.

NavList:

A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding

Compose Your Message

Message:αβγ
Message:abc
Add Images & Files
    or...
       
    Reply
    Re: Henning Umland's long term almanac. Is it wrong?
    From: Paul Hirose
    Date: 2016 Feb 25, 21:14 -0800

    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:
    
    http://fer3.com/arc/m2.aspx/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
    Browse Files

    Drop Files

    NavList

    What is NavList?

    Join NavList

    Name:
    (please, no nicknames or handles)
    Email:
    Do you want to receive all group messages by email?
    Yes No

    You can also join by posting. Your first on-topic post automatically makes you a member.

    Posting Code

    Enter the email address associated with your NavList messages. Your posting code will be emailed to you immediately.
    Email:

    Email Settings

    Posting Code:

    Custom Index

    Subject:
    Author:
    Start date: (yyyymm dd)
    End date: (yyyymm dd)

    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site