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

*To*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Subject*: Re: +nan.0 contradiction*From*: Bakul Shah <bakul@xxxxxxxxxxxxx>*Date*: Sat, 22 Oct 2005 12:42:38 -0700*Cc*: srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: Your message of "Sat, 22 Oct 2005 12:46:25 EDT." <20051022164625.93B8F1B77BB@xxxxxxxxxxxxxxxxxxxxx>

> | This SRFI regards +nan.0 as a real number whose value is so > | indeterminate that it might represent any real number within the > | closed interval [-inf.0,+inf.0]. > > That sentence implies that (<= -inf.0 +nan.0 +inf.0). > > But that is not true in IEEE-754 arithmetic as compiled by gcc running > on an Intel(R) Pentium(R) 4 CPU. As per IEEE754, all relational operators except != return false when one or both operands are NaN. != returns true when one or both operands are NaN. More directly, IEEE754 says NaN is the result of an *invalid* operation, when an operation's operands lie outside its domain. For example, Dividing 0 by 0 is invalid and creates a NaN -- a NaN also means Not *any* Number! The quoted sentence should simply be removed from the srfi. One nit: The +NaN.0 syntax is misleading since the signedness of NaN is *not* defined. I would much prefer a special syntax like #NaN (and #SNaN if you want to deal with signalling NaNs). Recommended reading: Prof. Kahan's Lecture Notes on the Status of IEEE 754 for Binary Floating-Point Arithmetic.

**References**:**+nan.0 contradiction***From:*Aubrey Jaffer

- Prev by Date:
**Re: Exactness** - Next by Date:
**Re: multiplicative inverse of 0.0** - Previous by thread:
**+nan.0 contradiction** - Next by thread:
**multiplicative inverse of 0.0** - Index(es):