# NavList:

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

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