Re: IEEE floating point support for guile?

[Jim Blandy]

> Actually, I think you have it backwards.  These operations should
> produce exceptions by default, and optionally not do so.
> 
> The default should be safe in that either the computation proceeds
> correctly, or it signals an exception.  This is the right behavior for
> naive users, because it guarantees that any problems such as overflow
> or underflow are noticed and not silently ignored.
>
> Sophisticated users can turn this off to take advantage of the
> extended representation.  Such users presumably understand how to deal
> with this added complexity.

Yes, I agree.  What is Octave's current practice here?

> A related problem on the x86 architecture, and perhaps on others, is
> that the 80-bit extended representation is enabled by default.  This
> is incorrect, because it means that the results of a computation
> depend on details of the compiled code.  For example, a computation in
> which a floating-point register is spilled to memory can get a
> different answer than an identical computation in which the register
> is not spilled.
>
> It's far better to switch the hardware into the mode
> where all results are stored internally in the standard 64-bit format.
> That makes the computations completely repeatable.  It also makes them
> portable to other architectures.

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?

(It's a pity the precision is a global mode, and not a per-instruction
thing.  It seems to me that providing extended-precision instructions,
instead of a global mode, would still provide the benefits of the
larger mantissa, but interact more nicely with compiler
optimizations.)