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

*To*: srfi-77@xxxxxxxxxxxxxxxxx*Subject*: Re: Is exact 0 "stronger" than inexact 0.0?*From*: Marcin 'Qrczak' Kowalczyk <qrczak@xxxxxxxxxx>*Date*: Sun, 23 Oct 2005 20:17:22 +0200*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <20051023173417.6D2841B77BB@xxxxxxxxxxxxxxxxxxxxx> (Aubrey Jaffer's message of "Sun, 23 Oct 2005 13:34:17 -0400 (EDT)")*Mail-followup-to*: srfi-77@xxxxxxxxxxxxxxxxx*References*: <20051023173417.6D2841B77BB@xxxxxxxxxxxxxxxxxxxxx>*Sender*: Marcin 'Qrczak' Kowalczyk <qrczak@xxxxxxxxxx>*User-agent*: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Aubrey Jaffer <agj@xxxxxxxxxxxx> writes: > (* 0 +inf.0) ==> +nan.0 > ... > (/ 0 0.0) ==> unspecified > (/ 0.0 0) ==> +nan.0 > (/ 0.0 0.0) ==> +nan.0 > > Why is only (/ 0 0.0) out of this set unspecified? I don't know. In my model and implementation: (* 0 +inf.0) ==> 0 (/ 0 0.0) ==> 0 (/ 0.0 0) ==> error (/ 0 0) ==> error In general my recipe for evaluating such operations is as follows: 1. Replace 0.0 with a very small positive number, +inf.0 with a very large number, -0.0 and -inf.0 analogously, +nan.0 with any number. 0 stays exact. 2. Perform the operation. 3. Try to perform the inverse substitution. If the answer would depend on the initial choice of substituted numbers: a) If the result can't decide between 0.0 and -0.0, answer 0.0 (in most rounding modes) or -0.0 (when rounding towards -inf). b) If the result can't decide between a number and an error, answer the number (this happens e.g. for (/ 0 +nan.0)). c) Otherwise answer +nan.0. This algorithm doesn't explain two-argument atan near zero, which is treated specially, as per IEEE and other languages (the algorithm would answer +nan.0). Disclaimer: I haven't checked whether atan is the only special case, I formulated the rules just now. Note that in my model (- 0 x) is (- x), but (- 0.0 x) is different (assuming the default rounding mode). Also (+ A (* B +i)) is A+Bi; this would not be true if complex numbers had both real and imaginary part of the same exactness, because adding 0.0 is not identity at -0.0. -- __("< Marcin Kowalczyk \__/ qrczak@xxxxxxxxxx ^^ http://qrnik.knm.org.pl/~qrczak/

**References**:**Is exact 0 "stronger" than inexact 0.0?***From:*Aubrey Jaffer

- Prev by Date:
**Is exact 0 "stronger" than inexact 0.0?** - Next by Date:
**Re: arithmetic issues** - Previous by thread:
**Is exact 0 "stronger" than inexact 0.0?** - Next by thread:
**Common Lisp solved this problem 20 years ago** - Index(es):