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

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.

*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):