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

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 contain all messages, not just those from before July 7th, 2015.



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