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.
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
ad 1)
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.
ad 2)
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)
#f
> (eqv? +0.0 -0.0)
#t
> (= +0.0 -0.0)
#t
> (eq? +0.0 -0.0)
#f
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)
#f
> (< 1 +nan.0)
#f
> (= +nan.0 +nan.0)
#f
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.
ad 3)
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