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

*To*: srfi-67@xxxxxxxxxxxxxxxxx*Subject*: Re: IEEE 754 floating-point arithmetic is not completely ordered*From*: Sebastian Egner <sebastian.egner@xxxxxxxxxxx>*Date*: Tue, 12 Apr 2005 14:34:44 +0200*Delivered-to*: srfi-67@xxxxxxxxxxxxxxxxx*In-reply-to*: <Zg7gE.A.-cF.hG5WCB@rotkohl>

IEEE 754 does not specify any total order on floating point values,

not even a partial order because NaN is specified as incomparable with

itself whereas a partial order is reflexive. In IEEE 754 it is -0.0 = +0.0.

Currently, COMPARE-REAL is underspecified just as R5RS is, i.e. there is

no portable notion of NaN, -INF, -0, and +INF at all. It might make sense to

specify COMPARE-REAL for the special symbols, in case they are present

in the implementation:

1. For +/-INF it is pretty clear: -INF < other REALs < +INF.

2. Concerning NaN (not a number), the situation is more difficult. Of course,

COMPARE-REAL should define a total order, so either it bombs on

comparing NaN, or NaN has a well specified place in the ordering.

The intention of NaN is defering error conditions; so maybe having an

error thrown in COMPARE-REAL is not so bad after all because you

may be in trouble at that point anyhow.

3. The really tricky one is -0 (i.e. "equal" to +0, but sign is -1):

a) Does (COMPARE-REAL -0.0 +0.0) evaluate to 0, or to -1?

b) Does (COMPARE-REAL 0 +0.0) evaluate to 0, or to -1?

Unfortunately, all possible choices can lead to surprises.

I would settle for 0 = +0.0 = -0.0; this is at least consistent with

R5RS' "=" and with the view of IEEE 754. Having two or three

zeros float around may be more confusing than occasionally

losing sign and precision information.

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?

> part to inexact because of an inexact imaginary part. You might note

> that other Scheme implementations may not require or implement this

> coercion.

That is why we explicitly state using PLT. But it is a good idea to add a note.

Sebastian.

- Prev by Date:
**IEEE 754 floating-point arithmetic is not completely ordered** - Next by Date:
**Two maybe-bugs and two proposals** - Previous by thread:
**IEEE 754 floating-point arithmetic is not completely ordered** - Next by thread:
**Re: IEEE 754 floating-point arithmetic is not completely ordered** - Index(es):