While world record holders may have memorized more than 70,000 digits of pi, a JPL engineer explains why you really only need a tiny fraction of that for most calculations – even at NASA.
About 17 bytes of data. For reference a common size for numbers is 8 bytes. I imagine Nasa has hardware for efficiently handling larger numbers such as 16 bytes and possibly more.
I mean, so do you. Any common device can handle computation with numbers a lot larger than 8 bytes, using appropriate software. Hell, even Python can handle that pretty routinely.
Very large numbers are used routinely in cryptography.
The article literally states that NASA uses at most 16 digits of pi, that’s around 53 bits.
IEEE double precision float also have 16 decimal digits / 53 significant bits.
Dedicated hardware for that format exists since the 1980 launch of the Intel 8087.
Thanks Anton. Do you know anything more? I once made a physics simulation the scale of the solar system, including a space shuttle. Doubles weren’t good enough.
There is a trick to achieve double the precision of your hardware, it’s explained in this video. Many languages also come with arbitrary precision numbers which are probably a lot slower.
The main way of improving the code is however is probably understanding floats and keeping their limitations in mind.(Wikipedia article, interactive website) Floats are denser near zero and more imprecise the larger the absolute value is. This means subtracting numers that are close to each other or is a problematic operation.
I don’t know how your code is structured but lets say your origin point is at the star.
If the shuttle is approaching a space station they are relatively close together (say 1km) in compared to their distance to the origin point (150 million kilometres). If you get their relative positions by subtracting their absolute position vectors, you probably have a high rounding error (with 32 bit floats they would literally have the same position).
In that case it would probably be better to use a fixed width format or chunks with local origin points, as those approaches spread representable positions more evenly in space instead of having most of them inside the star.
I hope I gave you some useful tips on how to deal with floating point numbers, Anton.
About 17 bytes of data. For reference a common size for numbers is 8 bytes. I imagine Nasa has hardware for efficiently handling larger numbers such as 16 bytes and possibly more.
Sure they do but they don’t need to routinely do this sort of calculation. It’s just a fun demonstration of uncertainty.
I mean, so do you. Any common device can handle computation with numbers a lot larger than 8 bytes, using appropriate software. Hell, even Python can handle that pretty routinely.
Very large numbers are used routinely in cryptography.
The article literally states that NASA uses at most 16 digits of pi, that’s around 53 bits.
IEEE double precision float also have 16 decimal digits / 53 significant bits. Dedicated hardware for that format exists since the 1980 launch of the Intel 8087.
Thanks Anton. Do you know anything more? I once made a physics simulation the scale of the solar system, including a space shuttle. Doubles weren’t good enough.
There is a trick to achieve double the precision of your hardware, it’s explained in this video. Many languages also come with arbitrary precision numbers which are probably a lot slower.
The main way of improving the code is however is probably understanding floats and keeping their limitations in mind.(Wikipedia article, interactive website) Floats are denser near zero and more imprecise the larger the absolute value is. This means subtracting numers that are close to each other or is a problematic operation.
I don’t know how your code is structured but lets say your origin point is at the star. If the shuttle is approaching a space station they are relatively close together (say 1km) in compared to their distance to the origin point (150 million kilometres). If you get their relative positions by subtracting their absolute position vectors, you probably have a high rounding error (with 32 bit floats they would literally have the same position). In that case it would probably be better to use a fixed width format or chunks with local origin points, as those approaches spread representable positions more evenly in space instead of having most of them inside the star.
I hope I gave you some useful tips on how to deal with floating point numbers, Anton.