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