[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IEEE 754 floating-point arithmetic is not completely ordered
Bradley Lucier wrote:
> Sebastian Egner wrote:
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?
Well, it depends on what your goal is. You go to a lot of trouble to
build a total order on all Scheme values (why, I haven't really figured
out yet), so I would argue (0) that it *should* be a total order on all
scheme values, (1) that any two values that are not eqv? should not
compare equal in your total order, and (2) that eqv? on IEEE
floating-point should compare at the sign bit, the biased exponent, and
the mantissa (which are all defined for NaNs and +-0.).
Here are some potential goals:
1) compare-real should mimick the behaviour of < and =
2) compare-real should do the "right thing" w.r.t numerical calculations
3) default-compare should define a total order on almost all Scheme values
From a user perspective it is nice that (<? x y) behaves exactly
as (< x y).
From an efficiency perspective defining compare-real in terms of
the built-in < and = is efficient (in Schemes where compare-real
isn't a primitive).
The down side of 1) is that compare-real will be just as
underspecified w.r.t NaN and Inf as < and = are in R5RS.
This demands a specification of how -inf, +inf, NaN, +0.0, 0.0 and -0.0
should be treated. What the "right thing" is I don't know.
Should the zeros be considered equal or not? In a randomly picked
implementation (PLT Scheme) the current behaviour is:
> (< -0.0 +0.0)
> (eqv? +0.0 -0.0)
> (= +0.0 -0.0)
> (eq? +0.0 -0.0)
What would a numerical analyst prefer?
The other thing to consider is NaN. In PLT Scheme NaN is "incomparable"
to other numbers (and itself!):
> (< +nan.0 1)
> (< 1 +nan.0)
> (= +nan.0 +nan.0)
Since compare functions are transitive this treatment of NaN is hopeless.
Either NaN should be larger (or smaller) than all other numbers or
comparing with NaN provoke an error. Which behaviour is the "right thing"
I don't know.
Having a total order on all Scheme values is convenient when working
with heterogenous data structures. Sorting a list of numbers without
worrying whether NaN is a member or not would be a good thing.
Of these goals I consider 1) and 2) the most important, since it
is quite easy to new compare functions in case of 3).
Would it be advantageous to have both an compare-real for 1) and an
compare-ieee-real for 2) ?
Put the three together and I would compare -0.0 and +0.0 as different,
and the various NaN's artificially in terms of the values of the sign
bit, the biased exponent (which is the maximum value) and the mantissa
(which must be nonzero). It might be natural to order all NaNs with
sign bit 1 above +inf. and all NaNs with sign bit -1 below -inf. I
would also order -0. before 0.
Oops. In the above discussion I ignored the problem of different NaNs.
Jens Axel Søgaard