# [racket] 80-bit precision in Racket

Neil, Matthias,
Certainly not #2, and I doubt that #4 is a problem for us
(although it may be, buried somewhere in specific calculations).
#1 and #3 definitely are our case. We are doing numerical
integration of celestial bodies over large periods of time
(100 years is a norm). The forces that act on bodies may be of
quite different orders of magnitude: for example, for near-Earth
objects the acceleration towards the Sun is about 2.9e-4 AU/days^2,
while corrections for peculiar relativistic effects (Lense-Thirring
acceleration etc.) can be as small as 1e-17 AU/days^2 (I do not
have exact numbers now). And those effects must be taken
into account. Yet the numerical integration procedure has its
numerical inaccuracies, too. So when we integrate these
accelerations over ten or more years, it sort of pushes the
limit of double precision representation. Again, I do not
(yet) have a precise mathematical proof of it, but it is
more or less obvious that we need to try 80-bit at least.
In addition to the above: it is known that the DE ephemeris
done at JPL, NASA were integrated with *quadruple* (128-bit)
precision:
http://naif.jpl.nasa.gov/pub/naif/generic_kernels/spk/planets/a_old_versions/de414.cmt
so it may be a clue that even 80-bit is not enough!
We are going to try 128-bit after we get 80-bit done.
#5 is also our case. Legacy system that we are porting to Racket
uses extended precision numbers.
Thanks for your help!
Best regards,
Dmitry