IEEE floating point support for guile?

[Chris Hanson]

   Date: 08 Nov 2000 11:28:30 -0500
   From: Jim Blandy <address@hidden>

   How do people actually writing heavily numeric code feel about this
   extra precision?  If Guile insists on putting the FPU in double
   precision (64 bit) mode, will that annoy people who try to use Guile
   in numeric applications?

Let me inject an opinion from two people here at MIT who do a lot of
numerical computation.  (I've CC'd them to the message so they can
complain if I misrepresent their position.)

Jack Wisdom and Gerry Sussman are currently teaching a class on
computational classical mechanics, which involves the use of Scheme
code to solve mechanics problems.  They have also done extensive
simulations of the solar system (not in Scheme) to understand its
dynamics.

Both Jack and Gerry are much more interested in having repeatable
results and well-defined error bounds than in having extra precision.
The primary issue in numeric computation is _not_ precision (at least
if you use 64-bit IEEE), but error control.  And error control depends
critically upon deep understanding of the precise behavior of the
floating-point computations.  The IEEE standard was important
precisely because it carefully defined the entire floating-point
instruction set, which made it possible for numerical analysts to
design to this one specification and have their code run properly on
any conforming implementation.  Taking the same code and running it on
a non-conforming implementation, even one with extra precision, can
actually produce results that are LESS ACCURATE, because the
operations will behave differently than expected and therefore produce
different kinds of errors.  The errors from different parts of the
computation are supposed to fall into known ranges, and then be
combined in known ways, to produce an aggregate error.

This is the essence of the argument in favor of using a standard
floating-point implementation.  It's also the reason why the rounding
mode should always be set to "round-to-nearest": because that is the
standard way to do it, which provides the correct known error
behavior.

It's a real pity that almost no one understands this, _including_ many
of the designers of floating-point hardware.