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

Re: IEEE 754 floating-point arithmetic is not completely ordered

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

IEEE 754 does not specify any total order on floating point values,
not even a partial order because NaN is specified as incomparable with
itself whereas a partial order is reflexive. In IEEE 754 it is -0.0 = +0.0.

Currently, COMPARE-REAL is underspecified just as R5RS is, i.e. there is
no portable notion of NaN, -INF, -0, and +INF at all. It might make sense to
specify COMPARE-REAL for the special symbols, in case they are present
in the implementation:

1. For +/-INF it is pretty clear: -INF < other REALs < +INF.

2. Concerning NaN (not a number), the situation is more difficult. Of course,
COMPARE-REAL should define a total order, so either it bombs on
comparing NaN, or NaN has a well specified place in the ordering.
The intention of NaN is defering error conditions; so maybe having an
error thrown in COMPARE-REAL is not so bad after all because you
may be in trouble at that point anyhow.

3. The really tricky one is -0 (i.e. "equal" to +0, but sign is -1):
a) Does (COMPARE-REAL -0.0 +0.0) evaluate to 0, or to -1?
b) Does (COMPARE-REAL 0 +0.0) evaluate to 0, or to -1?
Unfortunately, all possible choices can lead to surprises.
I would settle for 0 = +0.0 = -0.0; this is at least consistent with
R5RS' "=" and with the view of IEEE 754. Having two or three
zeros float around may be more confusing than occasionally
losing sign and precision information.

So my suggestion: COMPARE-REAL throws and error on NaN arguments, and

        -INF < negative REALs < -0.0 = 0 = +0.0 < positive REALs < +INF.

What would be your suggestion?

> You give an example involving PLT 208 and coercion of an exact real
> part to inexact because of an inexact imaginary part.  You might note
> that other Scheme implementations may not require or implement this
> coercion.

That is why we explicitly state using PLT. But it is a good idea to add a note.