This page is part of the web mail archives of SRFI 67 from before July 7th, 2015. The new archives for SRFI 67 are here. Eventually, the entire history will be moved there, including any new messages.
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