Re: address@hidden: IEEE floating point support for guile?]

[Mikael Djurfeldt]

Gerald Jay Sussman <address@hidden> writes:

> I want my numerical programs to be predictable and reliable, so...
> 
> I want to know when I divide by zero!  I want to know when I overflow
> or underflow!
> 
> Sometimes a NaN is the right thing, but most of the time it is not the
> right thing.  Most of the time it is a signal that I have a
> singularity or other bad problem that needs special attention.

Note that we're talking about an implementation decision for Guile
here.  I'm reacting against the suggestion to switch from NaN to
exceptions, that is, at least initially, not being able to use NaN in
Guile.

I think you ask for reasonable things, but "most of the time" is very
dependent upon context.  From my own experience, from vague memory of
the usage patterns of numerical analysts and from a recent discussion
with one numerical analyst it is my impression that *not* having NaN
is a severe and unpractical limitation.  It would force a more complex
structure of some programs and would make Guile harder to use in many
situations where algorithms work on problems with parallel structure.

Using the exceptions to decide intelligently what to do is not an
option for Guile right now since the current Guile exceptions aren't
restartable.

Instead of switching to using exceptions, I'm suggesting to find a way
in which we can have both.

> And, I want the standard IEEE rounding rules in place.  I don't want
> to do arithmetic with 80 bits in the chip and 64 bits in memory.  I
> want the 64 bit mode unless I explicitly ask for 80 bit accumulations!

Me too.

Thanks for your comments,
Mikael