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

*To*: srfi-77@xxxxxxxxxxxxxxxxx*Subject*: Re: arithmetic issues*From*: Marcin 'Qrczak' Kowalczyk <qrczak@xxxxxxxxxx>*Date*: Fri, 21 Oct 2005 19:15:05 +0200*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <20051021145326.816C11B77BB@xxxxxxxxxxxxxxxxxxxxx> (Aubrey Jaffer's message of "Fri, 21 Oct 2005 10:53:26 -0400 (EDT)")*Mail-followup-to*: srfi-77@xxxxxxxxxxxxxxxxx*References*: <20051021145326.816C11B77BB@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: > Being error objects, syntax for NaNs should be unspecified. I disagree. Note that supporting special values (+inf.0, -inf.0, +nan.0, -0.0) needs at least functions to recognize them, in particular finite? (to go a fast path for non-pathological cases) and either negative-zero? or sign-bit? (the latter answering "positive" for 0.0 and "negative" for -0.0). Recognizing NaN is more clear with a distinguished predicate than with (= x x). > None of the examples in SRFI-77 return -0.0 unless they are passed > -0.0 as an argument. Does -0.0 result only from a literal -0.0 > constant? For example (- 0.0), (/ -inf.0) and -1e-2000 yield -0.0, (* 0.0-i 0.0-i) yields (-1.0-0.0i). > In an implementation with -0.0, what is the result of (* -5.0 0.0)? -0.0 > -0.0 is insufficiently specified by SRFI-77; it will be a portability > killer. The relevant IEEE standard that everybody uses specifies it. Most processors support it natively. > Mathematically, mixed exactness complex numbers makes no sense. Not true. For example 1.23 is a real number for sure, but its value could have been rounded. 1.23+0.0i and 1.23-0.0i signify that the true value might not be real. 1.23+0i can be unified with 1.23 just like 123/1 is unified with 123. > The procedures REAL-PART, IMAG-PART, and MAKE-RECTANGULAR already > guarantee that the orthogonal representation is available. The > language should not constrain an internal representation which is > transparent to the user. It's not transparent anyway if real-part and imag-part are reqired to return former arguments of make-rectangular (as long as they are real numbers) in the sense of eqv? or at least =. No implementation uses a different representation anyway, so constraining is theoretical. C++ made the mistake of not specifying the layout of complex numbers and having re() and im() as methods instead of fields. Every implementation does the same anyway, and not specifying this makes harder to interface to other languages. > | * Should `(floor +inf.0)' return +inf.0 or signal an error > | instead? (Similarly for ceiling, flfloor, infloor, etc.) > > Floor is specified to return an integer. +inf.0 is not an integer. > Thus it is an error. IMHO it's more useful to return +inf.0, because then the program doesn't have to treat the possibility of overflow at this point yet. IEEE, processors, and other languages which return an inexact number here, all return +inf.0 I think. -- __("< Marcin Kowalczyk \__/ qrczak@xxxxxxxxxx ^^ http://qrnik.knm.org.pl/~qrczak/

**Follow-Ups**:**Re: arithmetic issues***From:*Aubrey Jaffer

**References**:**arithmetic issues***From:*Aubrey Jaffer

- Prev by Date:
**Re: arithmetic issues** - Next by Date:
**Re: Exactness** - Previous by thread:
**Re: arithmetic issues** - Next by thread:
**Re: arithmetic issues** - Index(es):