[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*: Bradley Lucier <lucier@xxxxxxxxxxxxxxx>*Date*: Sat, 16 Apr 2005 15:41:06 +0200*Delivered-to*: srfi-67@xxxxxxxxxxxxxxxxx*Old-date*: Fri, 15 Apr 2005 14:18:25 -0500*User-agent*: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.5 (chives, berkeley-unix)

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

**Follow-Ups**:**Re: IEEE 754 floating-point arithmetic is not completely ordered***From:*Jens Axel Søgaard

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