[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
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.