NavList:

   

Reply

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.

   

Reply