Email list hosting service & mailing list manager


Re: +nan.0 problems Marcin 'Qrczak' Kowalczyk 22 Oct 2005 18:52 UTC

Aubrey Jaffer <xxxxxx@alum.mit.edu> 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
   \__/       xxxxxx@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/