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

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.

*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):