Re: IEEE 754 floating-point arithmetic is not completely ordered Bradley Lucier (16 Apr 2005 13:41 UTC)
Re: IEEE 754 floating-point arithmetic is not completely ordered Jens Axel Søgaard (16 Apr 2005 15:53 UTC)

Re: IEEE 754 floating-point arithmetic is not completely ordered Bradley Lucier 16 Apr 2005 13:41 UTC

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.

Brad