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: Calculators, cosines, and floating point computation
    From: Paul Hirose
    Date: 2019 Jun 9, 23:56 -0700

    One application of the arc cosine function is to obtain an accurate
    value of pi. For those who have not done much astronomical programming
    it may come as a surprise that many major languages don't have a "pi
    button" like a calculator!
    In a "how do I get pi" thread in a Fortran discussion group, some
    replies simply offered a numeric literal with a plethora of decimal
    places. One person recommended 4 * atan(1.0). I was chastised for
    suggesting arc cos(-1) since the function is extremely sensitive to
    error at that point, which is the extreme limit of the function's
    domain. At least that's the theory.
    On the principle that an ounce of experimental data is worth a pound of
    theory, I posted source code for a program to display the arc cosine at
    single, double, and extended precision, and asked if anyone could name a
    Fortran implementation which did not give a highly satisfactory pi.
    There was no more criticism.
    I'm still interested to hear of any case where that's not true. On my
    system, 4 * Atan(1) and Acos(-1) are both identical to the Windows .NET
    Framework constant for pi.
    Nevertheless, it's common to code pi as a numeric literal. For instance,
    the IAU SOFA library uses the C language "#define" directive:
    #define DPI (3.141592653589793238462643)
    I don't think that's best practice. The first problem is where to get a
    reliable value for pi. Wikipedia?
    Even if the value is correct to the last digit, there's still a
    reliability problem. Imagine you are responsible for maintenance of that
    code. Are you certain the original programmer used the correct constant?
    (That programmer may have been you, a few years ago.)
    And even if it was originally correct, source code can be modified many
    times during its lifespan. All it takes is one slip with a text editor
    to corrupt a constant. If you're lucky the error will be obvious.
    Those issues disappear if pi and other constants are computed at run
    time. And, if your code is someday compiled on a machine with higher
    precision floating point, the accuracy automatically steps up to match
    the new architecture.
    I admit this approach is not always practical with existing code. For
    instance, in the SOFA library I have retained the original coding of the
    constants. But I added something. Each constant is compared to a value
    computed at run time, and an exception thrown if there's any significant
    Programs are easier to write and more reliable if you make them compute
    their own constants. What's not practical to compute, such as the
    sidereal to solar ratio, should be assigned to a variable. That way you
    have only one opportunity to enter the wrong number.

    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