[Ecls-list] [PATCH] Improve floating-point exception handling.

[Raymond Toy]

Juan Jose Garcia-Ripoll wrote:
> On Tue, Jun 2, 2009 at 4:31 PM, Gabriel Dos Reis
> <gdr at integrable-solutions.net> wrote:
>   
>> Again, I never made a wish that ECL does not implement CL spec.  All
>> I suggested was a way for ECL to let people shoot themselves (from CL
>> spec perspective) with IEEE-754 semantics if they wanted to.  I suspect
>> that can only contribute to the useful of ECL.
>>     
>
> Sure. What I have been wondering all the time is whether the
> introduction of these types can be done without breaking other
> assumptions (behavior under EQ, EQL, etc, hashing, printing, reading,
> etc).
>   
CMUCL and SBCL are existence proofs that it can be done without breaking
things.  (Barring bugs, of course.)
>   
>> SBCL lets people construct NaNs, and starts being annoying only when
>> some operations are non-sensical (and rightly so).  For example,
>> SBCL lets me constructs infinities or NaNs through FFI without getting
>> mad -- unlike CLISP which I've stopped recommending for building OpenAxiom.
>> My hope is that ECL does not take the CLISP path on this.
>>     
>
>   
CMUCL and SBCL allow you to create infinities and NaNs natively.  You
don't need to use an FFI if you don't want to.

> Along the line of what I mentioned before, one thing that bothers me
> is that NaNs are not unique and yet they probably compare true through
> C's. We already had a problem with negative zeros which was pretty
> similar, but seems it was solved by CMUCL people with a clever
> understanding of how interval types should behave.
>   
NaNs are never = to anything, even themselves.  Most architectures have
instructions that do the expected thing for = (and < and >).  If you
want eql, you have to compare the bits yourself,  but that's not too hard.
> Ok, so to get things more or less right, these are the questions that
> pop out of my head
>
> - One or more NaNs?
>   
I think you kind of have to support all NaNs because the HW will do
whatever it feels like.  There are also signaling and non-signaling NaNs.
> - Behavior under EQ, EQL, EQUAL, ==? NaNs are not numerically equal,
> not even to themselves, yet one would expect (EQ x x) = T for all lisp
> objects.
>   
I think you can do the obvious things.  =, < and > always fail.  EQL
compares bits.
> - Do +-Infs fit in the interval type system?
>   
In CMUCL, unbounded intervals contain infinity.  So (double-float 1.0)
is the interval from 1.0 to +Inf and (double-float * -1.0) is -Inf to
-1.0.  I'm pretty sure SBCL behaves the same since it inherited that
part of CMUCL.

> - What about NaNs? They are probably (AND FLOAT (NOT (FLOAT * *))) but
> only if Infs can be written as intervals, which I doubt.
>   
Good question.  I don't know how to represent that as a type, other than
using an EQL type or maybe SATISFIES.
> - Hashing is probably determined by point 2
> - If NaNs are not always equal, not even to themselves, then we can
> probably print them using #. followed by a constant name or some
> function.
>   
CMUCL prints it as #<DOUBLE-FLOAT Quiet NaN>;  it doesn't show the bits,
which is a bit of a defect.
> - Same would probably apply to +-Inf.
>   
CMUCL uses, for example, #.ext:double-float-positive-infinity.

There was some proposal on the cmucl mailing lists for some kind of way
of printing these numbers in a simpler, mostly readable way. Don't
remember the details anymore, though.

Ray