[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
losing sign and precision information.
So my suggestion: COMPARE-REAL throws
and error on NaN arguments, and
< 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
> that other Scheme implementations may not require or implement this
That is why we explicitly state using
PLT. But it is a good idea to add a note.