# 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 Posting Code: Name: Email:
Re: Calculators, cosines, and floating point computation
Date: 2019 Jun 10, 09:50 -0400
Paul

I like the trick of a computation compared to the define.  Clever.

I was tasked at GE with finding an indideous bug.  The person hadn't bothered with the nicety of a define.  That person used the literal constant everywhere, the actual digits.  The bug?  In one very magical spot, they dropped one zero of many, providing an order of magnitude error.  Sporadically occurring bug too.  Ridiculously hard to find, because even when looking right at it, it appeared to be the correct value.  I had a serious chat with the person over standards and practices.

On Mon, Jun 10, 2019, 8:34 AM Paul Hirose <NoReply_Hirose@fer3.com> wrote:

```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
error.

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.
```

View and reply to this message

Browse Files

Drop Files

### 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)