Welcome to the NavList Message Boards.


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

Compose Your Message

Add Images & Files
    Re: Two-body fix caveat
    From: Peter Hakel
    Date: 2009 Nov 4, 12:15 -0800
    There is a distinction to be made between the intrinsic accuracy of numerics on modern computers on the one hand, and getting an inaccurate result due to an inaccurate input (i.e. error propagation through a formula) on the other.  I think the former is quite good, while George makes a valid argument about the latter.

    I base this comment on my experience with Excel, which yields the discriminant = zero (instead of, say, -1e-10) for the test example I presented with Van Allen's method.  The comparison of the computed second altitude (now using John Karl's equations) with the known input value (my suggestion for resolving the LHA1 ambiguity) shows a little round-off, as their difference was of the order of 1e-14.  I was very happy to see that Excel adequately handles VSOP87 formulae, that in some cases require summations of more than a 1000 terms.

    There is one case, however, where I have seen Excel's numerical abilities challenged.  It occurred in extracting a fix from a noon-curve (or any meridian transit, for that matter).  If I use the charting feature and extract the parameters of the quadratic fit from there, everything is fine.  If, on the other hand, I use quadratic least-squares formulae from Meeus without plotting a chart, the results can be a bit off...  A Fortran program in double precision shows the same problem, while the same program compiled in quadruple precision gives accurate results yet again, agreeing with Excel's chart and fitting results.  Interesting, does anyone know enough about Excel's inner workings to explain this?  I addressed the problem in Excel by first stretching the time axis to a larger interval, run that stretched noon curve through the least-squares formulae, and the recompress the results for LAN and longitude to the original scale.  That seems to work OK, as we have seen from my processing of Jeremy's and Antoine's meridian transit data a few weeks ago.

    Peter Hakel

    From: George Huxtable <george@hux.me.uk>
    To: navlist@fer3.com
    Sent: Wed, November 4, 2009 3:19:55 AM
    Subject: [NavList 10427] Re: Two-body fix caveat

    [parts deleted in reply by PH]

    The other problem, associated with calculaing LHA from its cosine, for a
    body near due-North or due-South, is the IMPRECISION of that calculation. It
    becomes very dependent on the precision of the altitude observation and the
    declination, because of the way the cosine function changes so slowly with
    angle, around zero and 180 degrees. To put it another way, no navigator with
    any common sense would try to deduce his longitude by observing a star to
    his North or South. In that, lies the answer to both the imprecision problem
    and the ambiguity in longitude. He would work it from the other body

    NavList message boards: www.fer3.com/arc
    Or post by email to: NavList@fer3.com
    To unsubscribe, email NavList+unsubscribe@fer3.com

    Browse Files

    Drop Files


    What is NavList?

    Join NavList

    (please, no nicknames or handles)
    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 Settings

    Posting Code:

    Custom Index

    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