Re: IEEE floating point support for guile?

[John W. Eaton]

On  8-Nov-2000, Jim Blandy <address@hidden> wrote:

| > 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?

Octave uses IEEE floating point arithmetic on systems that have it,
but doesn't try to do anything to set rounding modes.  Whether
exceptions are raised depends on what the underlying system does.  I
think this should be fixed so that people have more control.  I'd also
be willing to change things so that exceptions are raised by default
when Inf or NaN is generated.

| > A related problem on the x86 architecture, and perhaps on others, is
| > that the 80-bit extended representation is enabled by default.

| 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?

If possible, I suppose this kind of control should also be available
to the user.  I don't know what the best default would be.  As I
understand it, for expressions like

  z * (x + y)

in Octave, the computation does not use extended precision because
intermediate values are stored to (temporary) variables in the process
of evaluating the expression, and that causes them to be truncated to
64 bits.

jwe