[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*: qrczak@xxxxxxxxxx*Subject*: Re: arithmetic issues*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Fri, 21 Oct 2005 23:19:18 -0400 (EDT)*Cc*: srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <871x2elrl2.fsf@xxxxxxxxxxxxx> (qrczak@xxxxxxxxxx)*References*: <20051021145326.816C11B77BB@xxxxxxxxxxxxxxxxxxxxx> <871x2elrl2.fsf@xxxxxxxxxxxxx>

| From: "Marcin 'Qrczak' Kowalczyk" <qrczak@xxxxxxxxxx> | Date: Fri, 21 Oct 2005 19:15:05 +0200 | | 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? Yes. srfi-70 has FINITE? and INFINITE?. The only reference to them in srfi-77 is: If x is an inexact real number, then `(integer? x)' is true if and only if (and (finite? x) (= x (round x))) Were the finiteness predicates left out of srfi-77 accidentally? | (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). In srfi-70 (and (infinite? x) (not (real? x))) is true for NaNs. | > 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. That argues for making real and complex be separate types (which can be done without mixed exactness). But mixed exactness spawns many senseless combinations. What does 1.23+5i represent? | > | * 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. I was simple pointing out that the description was inconsistent. There are two ways to fix the problem: [1] Change the description to say that floor returns an integer or -inf.0. or [2] Change the description to restrict floor's argument to FINITE real numbers.

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

**Re: arithmetic issues***From:*Marcin 'Qrczak' Kowalczyk

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