[racket] 80-bit precision in Racket

Sorry, I feel the need to add my 2 cents to this.

On Tue, 13 Nov 2012 22:43:08 -0800 (PST)
Hugh Aguilar <hughaguilar96 at yahoo.com> wrote:

> > We are doing numerical integration of celestial bodies over large
> >periods of time (100 years is a norm).
> 
> I'm new to Scheme, so I may be totally wrong about this --- but,
> isn't a numerical program like this exactly what Scheme is *not*
> designed for? Isn't Scheme primarily for dynamic-OOP programs? 

No, OOP is implemented on top of Scheme, it's not part of the core
language. If you don't use it, there is no penalty for it. That's
the case for all object systems I know of. 

Racket has become pretty fast in recent years due to
its JIT compiler and is able to use fixed precision numbers without
overhead under certain cirucmstances. I think that's what this
discussion is about.

> I would really write a program like yours in Forth.

If speed really matters most, more than maintainability and
development time, then Fortran would be the right choice. Fortran with
the Intel compiler is probably the fastest option. Ada is also very
fast, but frequently beaten by optimized C.

> If I was going to use Scheme, I would use Gambit or one of the other
> Scheme systems that compile into C, which does support 80-bit floats.
> I definitely wouldn't mess with any system that uses a VM and JIT, as
> that is horribly complicated (and it also tends to be slow). 

JIT compilers can be faster than non-JIT compilers, because they allow
for optimizations that cannot be implemented for static executables.
However, I don't think Racket has evolved that far yet.

If I recall correctly, so far only Fortran and sometimes Ada beat
C/gcc and C/icc in sheer execution speed in artificial benchmarks.
Notice that anything using the Intel compiler usually beats
anythingusing gcc, though. However, if speed really matters that much
you'd also have to consider GPU programming (CUDA or OpenCL). Except
for Ada (which is a complicated, but very maintainable language), none
of these options makes the programs particularly maintainable or easy
to write, and icc is expensive and very hardware specific.


Best,

Erich


>
> 
> 
> Message: 1
> Date: Sun, 11 Nov 2012 15:11:50 +0400
> From: Dmitry Pavlov <dpavlov at ipa.nw.ru>
> To: Matthias Felleisen <matthias at ccs.neu.edu>
> Cc: users at racket-lang.org
> Subject: Re: [racket] 80-bit precision in Racket
> Message-ID:
>     <CAA-Jc7GMds-Um3p0aaeg-X-Y6FzQB=t1oS3gK-pNVmx5ZgSPpg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> 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