|
|
|
|
|||||
|
||||||
Subject: Re: Computing tables
From: Jim Manzari (manzari@XXX.XXX)
Date: Fri Sep 10 1999 - 17:34:25 EDT
"Richard B. Emerson" wrote:
> ...So, once again, I'll ask those who've either re-computed their own tables
> or otherwise adopted techniques using tables outside of the HO "family", how
> do you verify your tables?
Rick --Here's my nickel's worth, which I hope will be helpful...
What I think you're asking has to do with the concept of computational
"accuracy" and "precision" -- two separate or distinct aspects of the your
question.
On one hand you might ask...are the numerical algorithms in use sufficiently
robust to avoid problems when functional arguments approach trigonometric
limits, such as when the tangent of an angle approaches 90-degrees? Errors of
this type might be classified as discrepancies in "accuracy".
On the other hand, you might ask...does the underlying math library provide
sufficient precision? Does the math library in use properly account for
rounding, truncation, and stability inherent in discrete or finite precision
computation? Errors of this type might be classified as discrepancies in
"precision".
In order to understand the differences (errors) between two navigation tables,
say that of an amateur table vs an "official" almanac table, one would have to
1) evaluate the underlying algorithms to determine the comparative "accuracy",
and 2) evaluate the underlying math libraries to determine the comparative
"precision".
Generally speaking, given the current state of computing sciences, floating
point hardware, and standards such as IEEE and ANSI, one would be hard pressed
to find a math library now-days that is not precise, error free, and stable.
Certainly the latter statement is true at the levels of precision and
repeatability needed for practical navigation. Users of a math library must
"trust" that the library will produce correct results. Ultimately the
"correctness" of a math library is traceable back to some standard, such as
the "Handbook of Mathematical Functions", Abrammowitz & Stegun, National
Bureau of Standards.
Regarding algorithmic accurary...this is, in my view, where the "art" of
computation comes into play. There are a lot of "tricks" needed in order to
produce stable and accurate astronomical tables (and by implication,
navigational tables). Jean Meeus, in his "Astronomical Algorithms" touches on
this in Chapter 1, Hints and Tips. Techniques such as how to handle powers of
time, avoiding powers, shortening of program to avoid rounding errors, and
safety tests are just a few of the techniques discussed by Meeus. Montenbruck
and Pfleger also touch on this in the introduction to their "Astronomy of the
Personal Computer". "Numerical Recipes in C" by Press, et. al. and "The
Standard C Library" by Plauger are also good sources of computational
"tricks", in my view.
Having said all this, personally I always spot-check any algorithm I develop
against the "Astronomical Almanac", paying particular attention to "cardinal"
points where the algorithm may break down. If my new table is within a few
tenths of an arc-second, compared to the "official" Astronomical Almanac
results, I accept that it is precise and accurate, good enough for my purpose.
Knowing that I've taken care to avoid errors by following the guidelines of
experts like Meeus, et. al., I can be relatively confident that my algorithm
will probably be "good enough" over a wide range of arguments (there are
formal ways to prove correctness, but for amateur navigation I don't think
these are necessary). Judgement plays a prominent role, as it must, in this
type of evaluation. The art of celestical navigation is, after all, not about
right or wrong, but rather about better or worst.
Regards,
Jim Manzari
|