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

[Gabriel Dos Reis]

On Tue, Jun 2, 2009 at 9:53 AM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> 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).

You are, naturally, absolutely right in pointing out what technical challenges
need to be solved.

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

Absolutely agreed.

>
> Ok, so to get things more or less right, these are the questions that
> pop out of my head
>
> - One or more NaNs?

>From now on, I assume we are talking of extension, so where I say "should"
should be understand in that context.

I believe ECL should have the full gamut of IEEE NaNs, not just one.

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

As with signed zeros, the EQ rules shoult continue to apply.  The EQL
usual rule at looking at the bit pattern should continue to apply.  However,
numerical equality '=' should be the funny thing (== in C).

> - Do +-Infs fit in the interval type system?

The way we approached this in OpenAxiom is that we have the notion of
   * two-point completion of floats -- basically +inf and -inf are the end point
     of that system.  It contains the usual floating point sytem
without infinities.

   * One point completion of floats -- basically all infinities get
smashed on one
     point.  I believe C99 does something close to this.

> - What about NaNs? They are probably (AND FLOAT (NOT (FLOAT * *))) but
> only if Infs can be written as intervals, which I doubt.
> - 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.

Yes, agreed.

> - Same would probably apply to +-Inf.

Yes.

And some test predicates ala isnan, etc. so that people don't think they have to
test NaN for equality.  A primary reason to have NaNs is that their mantissa
carry information.  There probably need to be a way to get those bit pattern,
however, I do not know how that constrain the GC system -- does the GC
depend on the fact that some bit pattern will never occur in a float object?