Slashdot Mirror
How Many Digits of Pi Does NASA Use? (kottke.org)
An anonymous reader quotes an article on Kottke.org: Mathematicians have calculated pi out to more than 13 trillion decimal places, a calculation that took 208 days. NASA's Marc Rayman explains that in order to send out probes and slingshot them accurately throughout the solar system, NASA needs to use only 15 decimal places. Rayman explains, "The most distant spacecraft from Earth is Voyager 1. It is about 12.5 billion miles away. Let's say we have a circle with a radius of exactly that size (or 25 billion miles in diameter) and we want to calculate the circumference, which is pi times the radius times 2. Using pi rounded to the 15th decimal, as I gave above, that comes out to a little more than 78 billion miles. We don't need to be concerned here with exactly what the value is (you can multiply it out if you like) but rather what the error in the value is by not using more digits of pi. In other words, by cutting pi off at the 15th decimal point, we would calculate a circumference for that circle that is very slightly off. It turns out that our calculated circumference of the 25 billion mile diameter circle would be wrong by 1.5 inches. Think about that. We have a circle more than 78 billion miles around, and our calculation of that distance would be off by perhaps less than the length of your little finger."
I just use M_PI which is defined in math.h:
#define M_PI 3.14159265358979323846264338327950288
The symbolic constant is easier than typing in 15 digits, and the compiler recognizes the constant and optimizes it to use the hardware constant built in to the FPU, so I get faster execution as well.
And similarly, 39 digits of pi will let you calculate a sphere the size of the observable universe with an error the width of a single hydrogen atom.
Liberty in your lifetime
https://en.wikipedia.org/wiki/Double-precision_floating-point_format
"This gives 15–17 significant decimal digits precision. If a decimal string with at most 15 significant digits is converted to IEEE 754 double precision representation and then converted back to a string with the same number of significant digits, then the final string should match the original. If an IEEE 754 double precision is converted to a decimal string with at least 17 significant digits and then converted back to double, then the final number must match the original.[1]"
I don't think so. The normal standard for a mirror is 1/4 the wavelength of the light it's supposed to be reflecting, or around 100 nm. Even ultra-high precision mirrors like the ones on the Hubble Space Telescope are only ground to within about 10 nm. A 10 nm error on a mirror 100m in diameter- far larger than any mirror currently under construction- is still only 1 part in 10^10, far lower precision than what you're talking about. Unless you're building a mirror the size of a planet, you aren't going to need more than 15 digits of precision.
There's no point in questioning authority if you aren't going to listen to the answers.
How so? For high-precision applications, you'd typically want a mirror with a deviation from its calculated surface that is better than lambda/20. For UV light at 200 nm and a mirror size of 1 m, that would be about 8 significant digits to describe the surface. Then you have 7 more digits to deal with intermediate results during the calculation.
Note: For X-ray mirrors, the wavelength is much shorter, but because X-ray mirrors are grazing-incidence mirrors, the surface tolerance is more like lambda/1 - - which also boils down to about 8 significant digits. Anyway, to describe the surface with an accuracy down to the size of an atom, you still only need 10 significant digits.
Avantslash: low-bandwidth mobile slashdot.
If you plug that number into an iterative algorithm that uses any ill-conditioned functions, the 1.5-inch error can grow exponentially at every step. Ensuring that computations have acceptable error margins is an extremely complex and tricky subject.
Orbital motions can be calculated in ways that don't suffer from these problems. Use of quaternion (or equivalent) methods for rotations in 3 dimensional space rather than traditional Euler angles leads to much more stable numerical results.
If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?
I can't think of a step in the process of making focusing mirrors that requires a decimal expansion of pi more accurate than 3.14 (an error of 0.05%).
The only step that I can think of that needs a decimal expansion at all is to estimate how deep you need to hog out the material at the roughest formation (i.e., estimating the saggita). That estimation doesn't need better tolerance than 0.1%.
The spec on the focal length probably has a tolerance of 1% or 0.1% since nearly every device has an adjustable instrument/detector platform to refocus. You could measure the actual focal length of any mirror more accurately than 0.1%; however, it barely matters because I can't think of any use for pi in performing the measurement.
I can't think of any mirror test in use that requires a decimal expansion of pi: not Ronchi, not Foucault, not interferometry.
Honestly, the only exception I can think of is a spin cast mirror, which probably needs an accurate rotational speed on the platter. It may not, though - spin casting is only used to rough out the shape. Maybe it's better than 0.1% and maybe not (it's definitely not one part in a quadrillion, though). The LZT liquid mirror uses closed loop control to fix the rotational speed to within one part in a million but I think it just needs to be constant, rather than precise, so that the focal length doesn't change during an observation and so eddy currents aren't set up in the mirror surface. For all I know they adjust the focus by changing the rotational speed of the platter so an accurate expansion for pi doesn't even enter into it at all. It's possible that slashdot has not yet devolved into a such a pit of misinformation that one of the star nerds that works on the LZT will read this and chime in. Probably not.
Posting because I've seen too many programmers misunderstand this and screw things up when using floats. This does not mean you can do whatever you want with floats and your accuracy will be at least 1.5 inches within a 25 billion mile radius. It means an individual double float number has a precision of 17 significant figures, nothing more. When you start doing math with that number, the precision can quickly go out the window.
For example, if you add a large float to a small float, say 3.14159265359x10^8 + 2.7182818284x10^-3, the latter number doesn't actually matter because it's largest digit is smaller than the uncertainty (the last significant figure) in the first number. In other words, floating point's accuracy decreases the further you get from zero. A solar system modeled with ints will have the same resolution everywhere, which is how people want to think significant figures work. But a solar system modeled with double floats will have very fine resolution close to the origin, lousy resolution out near the edges.
To do this sort of math accurately using float (e.g. calculating docking coordinates for two spacecraft orbiting Jupiter), you are better off first doing a coordinate transform to center your zero closer to where everything is happening, do your math, then transform the results back to your original coordinates (or keep them in your new coordinate system if you plan to do more math there later). Obviously that's a pointless exercise with this simplified math problem, but it can make a big difference in accuracy with more complex math.
For a real-world example, we once networked two flight simulators together and tried to make them fly in formation. The position of the second plane appeared to jump all over the place when viewed from the first plane, and vice versa. What was happening was our coordinate system was fixed to the Earth. Planes fly on the order of 1000 kph. At that speed, a transient network lag error of only 10 milliseconds results in a position error of several meters (dp = v * dt). It didn't matter that we knew the velocities to 7 significant figures or even if we'd known them to 17 significant figures, because the error in the timestamp overwhelmed that accuracy. The fix was to define a new coordinate system centered on the first plane. The velocity of the second plane was then only a few cm/sec relative to the first plane (since they're flying in formation), and the jumping disappeared since a 10 ms error only resulted in only a few millimeters of error.