Re: [MIT-Scheme-devel] floating-point environment

[Taylor R Campbell]

   Date: Tue, 12 Oct 2010 23:04:54 -0700
   From: address@hidden (Matt Birkholz)

   I was wondering what all you had in mind.  The floating environment
   object looked opaque -- not just a set of flags.  Yet I expect the NaN
   option to toss the interesting detail and the trap option to reflect
   these details in a signaled condition object.  That does not leave
   much but the "enables" in the environment.  A fluid-bound mask might
   KISS.

The floating-point environment is usually stored in several machine
registers.  If by `fluid-bound mask' you mean a variable that one can
FLUID-LET, we don't have any mechanism for variables to reflect
machine registers like that.  But if you mean readers and writers for
the state which one can use in DYNAMIC-WIND, well, that's what I
proposed -- FLO:MASKED-EXCEPTIONS, FLO:SET-MASKED-EXCEPTIONS!, &c.,
with a thread-local floating-point environment.

   > It may also be necessary to frob the floating-point environment in
   > the thread timer interrupt handler.

   ALL interrupts?

All thread timer interrupts.  (There are other interrupts, but these
are the most frequent.)  Most of these eventually switch threads
anyway, which would involve changing the floating-point environment.

   Do you expect the condition system to be too costly, thus deferred
   exceptions (which can be checked and possibly cleared later) are
   preferable?

The machines and C libraries give us two choices in exceptional
situations: trap; or give a well-defined, if undesirable, result (0,
NaN, +/-inf) on which further arithmetic can happen, and set the
exception flags.  The condition system can be used to handle traps;
using it to substitute results deep inside a computation is not as
straightforward.

As for performance costs, I don't know what they will be.  That's why
I want to implement this, measure the performance, and see how the
operations turn out to be used.  This is an experiment: I want to
better understand IEEE 754 by implementing and using all of it in a
practical system such as MIT Scheme.

Arthur recently added primitives to convert between integers and the
IEEE 754 floating-point values that their bit patterns represent.  But
these explode if you pass in an integer representing, say, a NaN.  To
avoid that requires masking or handling the floating-point exception.
Since Arthur's primitives will usually involve bignums anyway, perhaps
involving the condition system to do this won't be so bad.  But if we
instead had primitives to read floating-point values from and write
them to octet vectors, which could be relatively easily open-coded, I
imagine the difference between frobbing the machine's floating-point
exception mask versus involving the condition system would be pretty
substantial.