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 ____________________ Racket Users list: http://lists.racket-lang.org/users
