Re: IEEE floating point support for guile?

[Jim Blandy]

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

Okay.  Given John's and Chris's comments, I think we have a consensus:

- By default, Guile should use the standard IEEE double-precision
  format for all flonum values and intermediate values.  On the IA-32,
  this implies changing the FPU's precision control field to "double
  precision (53-bits)".
- By default, floating-point operations in Guile should raise
  exceptions, rather than generating Inf or NaN values.  On the IA-32,
  this implies enabling software exception handling for underflow,
  overflow, zero divide, denormalized operands, and invalid operation
  exceptions.
- Guile should eventually provide some way to support users who want
  to work with extended doubles, or prefer non-signalling operations,
  but implementing the earlier suggestions should not be delayed until
  we agree on the interface to these more sophisticated facilities.