# Re: IEEE 754 floating-point arithmetic is not completely ordered

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.

```Sorry, I don't subscribe to the mail list so I didn't get your reply.

Re:

> 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.).

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.

What are your goals?  2 and 2. are not eqv?, so they should differ in
your order.  You talk about the numerical tower, but the tower is
orthogonal to exactness.  How does your total order deal with 2 and 2.?

The whole proposal with respect to numbers seems confused.  Or at least
I'm confused by it.