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

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

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.