[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: +nan.0 problems

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.



Aubrey Jaffer <agj@xxxxxxxxxxxx> writes:

> The total order of the reals is a crucial property for many
> applications.

It is well known that the default order on the floating point
approximation of reals is not total.

Not that it's the only pitfall. Some applications might rely on the
fact that x + y - x = y, which is false in this world too. But at
least all languages providing an interface to IEEE floats have the
same pitfalls.

IEEE anticipates the possibility of letting various errors be
signalled (in a catchable way) instead of producing special answers.
It would be a challenge to make this accessible from Scheme. C99
allows to track this as changing a global set of flags; on Unix it can
generate a SIGFPE signal. I'm not familiar with details. I've heard
that CMUCL and SBCL deal with this (through the Unix way).

> This could be resolved by either:
>
>   (real? +nan.0)  ==> #f and (complex? +nan.0)  ==> #f
>
> or
>
>   Stop using the term `real' to refer to IEEE flonums.  How about
>   RIEEEL?

If +nan.0 is not considered real nor complex, beware that some
operations which used to be treated as closed over these fields
are no longer closed. I'm not sure which is worse.

I like the name RIEEEL :-)

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@xxxxxxxxxx
    ^^     http://qrnik.knm.org.pl/~qrczak/