[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: Bradley Lucier <lucier@xxxxxxxxxxxxxxx>*Subject*: Re: IEEE 754 floating-point arithmetic is not completely ordered*From*: Jens Axel Søgaard <jensaxel@xxxxxxxxxxxx>*Date*: Sat, 16 Apr 2005 17:53:28 +0200*Cc*: srfi-67@xxxxxxxxxxxxxxxxx, Sebastian Egner <sebastian.egner@xxxxxxxxxxx>*Delivered-to*: srfi-67@xxxxxxxxxxxxxxxxx*In-reply-to*: <y9ld5sux2j1.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>*References*: <y9ld5sux2j1.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>*User-agent*: Mozilla Thunderbird 0.7.3 (Windows/20040803)

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 tobuild a total order on all Scheme values (why, I haven't really figuredout yet), so I would argue (0) that it *should* be a total order on allscheme values, (1) that any two values that are not eqv? should notcompare equal in your total order, and (2) that eqv? on IEEEfloating-point should compare at the sign bit, the biased exponent, andthe 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 signbit, the biased exponent (which is the maximum value) and the mantissa(which must be nonzero). It might be natural to order all NaNs withsign bit 1 above +inf. and all NaNs with sign bit -1 below -inf. Iwould also order -0. before 0.

Oops. In the above discussion I ignored the problem of different NaNs. -- Jens Axel Søgaard

**Follow-Ups**:

**References**:**Re: IEEE 754 floating-point arithmetic is not completely ordered***From:*Bradley Lucier

- Prev by Date:
**Re: IEEE 754 floating-point arithmetic is not completely ordered** - Next by Date:
**Re: Circular structures [was Re: IEEE 754 floating-point arithmetic is not completely ordered]** - Previous by thread:
**Re: IEEE 754 floating-point arithmetic is not completely ordered** - Next by thread:
**Re: Circular structures [was Re: IEEE 754 floating-point arithmetic is not completely ordered]** - Index(es):