Hacker News new | ask | show | jobs
by notjpl 3751 days ago
I agree, that's a poor answer by NASA director and chief engineer. Here is a better answer:

The precision used for calculations is dependent on the number of "steps" required to get to the final result. Roughly, for N repeated calculations you lose somewhere between sqrt(N) * eps to N * eps of precision (eps=2e-16 for IEEE64).

Here are some actual examples:

IEEE64 (~16 decimal digits) is OK for interplanetary navigation for few months, where relatively low accuracy is required.

With the same precision, you start to lose phase accuracy above 24 hours if you're simulating GPS constellations. You need quad precision or above for simulations > 24 hours.

For simulating planet trajectories and solar system stability (Lyapunov time of planets), IEEE64 is good for ~10 mya in the future (Neptune-Pluto Lyapunov time), IEEE128 for ~200-1000mya, above that it is recommended to use 256bit floats and above. This is assuming typically ~1000 steps per simulated orbit.

Fun fact: we know from simulations that Pluto trajectory is stable for >10G years, but unpredictable above >10M years because of chaotic (but stable) interaction with Neptune.

[1] https://en.wikipedia.org/wiki/Stability_of_the_Solar_System

3 comments

Here are some actual examples:

Something to add to your list of examples: During the first Gulf war, 28 US soldiers died due to accumulated rounding errors in the Patriot Missile battery computers: https://www.ima.umn.edu/~arnold/disasters/patriot.html

(This was in fact a known issue, and operators had been instructed to reboot the computers every 8 hours. Unfortunately this instruction ignored the fact that, in the field, nobody wanted to be responsible for turning off their defensive systems for a minute.)

Yeah, that doesn't surprise me in the least, many high-tech military systems have MTBF/MTTF of a few hours at best. Also, that's what you get when you try to do radar time computations using 24-bit fixed point in Ada.

Back to astronomy, in many astronomy libraries (such as astropy library) computations regarding time are done using 2 doubles (about 106 bit precision). 1 double is not enough.

_brandmeyer_ also mentioned something important that I totally forgot - any trigonometric computation requires computing modulo-pi to an accuracy of 1 ulp, which requires storing PI to ~1144 bits for double precision (for numbers near pi) (see Kahan argument reduction paper).

Since Intel processsors don't reach the required precision for IEEE standard above pi/2, this modulo reduction is done in software to this day. gcc maintains a 1144 bit PI constant and does a 1144 bit modulo every time you compute a sine/cosine above pi.

TLDR - 344 decimal digits of PI are used. High-precision PI computation is surprisingly more common than we expect...

[1] http://docs.astropy.org/en/stable/time/index.html

[2] https://software.intel.com/en-us/blogs/2014/10/09/fsin-docum...

[3] https://gcc.gnu.org/gcc-4.3/changes.html

[4] http://www.csee.umbc.edu/~phatak/645/supl/Ng-ArgReduction.pd...

any trigonometric computation requires computing modulo-pi to an accuracy of 1 ulp

For the trigonometric function itself, sure. For any reasonable algorithm which uses the trigonometric function, no. If find yourself computing sin(10^6), you're not really trying to compute sin(10^6); you're trying to compute sin(x) for some value of x which you know lies between 10^6(1 - epsilon) and 10^6(1 + epsilon). So the extent to which trigonometric calculations can lose precision by not doing extra-precision argument reduction, that precision was already lost in computing the unreduced argument.

Disagreed, the answer isn't aimed at engineers or actually at any science-oriented people, it's directed at the general public who don't even care what IEEE is.
As a software engineer, though, I find this answer way more interesting. That one part in 10^15 ends up being ~an inch on the scale of the solar system is thoroughly unsurprising.
So don't use a lossy floating point representation and use arbitrary precision instead.

Just because π is estimated to 15 significant digits doesn't mean the entire calculation needs to be.

Arbitrary precision is not a valid answer: every multiplication doubles the number of mantissa bits. Starting with a 64-bit precision, after just 40 multiplications, you will have consumed 800 GB of RAM just for storing a single number, at which point you'll ask yourself: how many decimal digits do I really need? Which was the initial question...
Pi cannot be stored exactly even with arbitrary precision.