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

*To*: srfi-70@xxxxxxxxxxxxxxxxx*Subject*: Re: My suggestions to the R6RS committee about numerics*From*: Bradley Lucier <lucier@xxxxxxxxxxxxxxx>*Date*: Sat, 21 May 2005 18:13:48 +0200*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <20050520191313.4B90C1B77B4@xxxxxxxxxxxxxxxx>*Old-date*: Fri, 20 May 2005 15:23:28 -0500*References*: <y9ly8acfewc.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20050520191313.4B90C1B77B4@xxxxxxxxxxxxxxxx>*User-agent*: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5-b20 (berkeley-unix)

Hi, Aubrey: We already discussed many of these issues on various threads in comp.lang.scheme. On May 20, 2005, at 2:13 PM, Aubrey Jaffer wrote: > | From: Bradley Lucier <lucier@xxxxxxxxxxxxxxx> > | Date: Wed, 18 May 2005 22:38:43 +0200 > | > | .., I sent document about proposed changes to numerics to > | Marc Feeley last March to forward to the committee. Since then my > | thinking has evolved a bit, but I thought I would just include my > | comments verbatim here. > | > | Brad > | > | The first part deals with IEEE 754/854 arithmetic. If you don't > | support this arithmetic, then things are still up in the air. > | > | 6.1 Equivalence predicates > | ... > | Note: This section does not state under which conditions eqv? > | returns #t or #f for inexact numbers that are not in IEEE > 754/854 > | format. We recommend that numbers not in IEEE 754/854 > format for > | which a base, sign, number of exponent digits, exponent bias, > | biased exponent, number of significand digits, and > significand can > | be defined follow the same rules as above. > > Why are you restricting the specification of inexacts to IEEE-754/854 > arthmetic? I'm not doing as you suggest; perhaps you misinterpret my recommendation. > > | 6.2.5. Numerical operations > | > | (number? obj ) procedure > | (complex? obj ) procedure > | (real? obj ) procedure > | (rational? obj ) procedure > | (integer? obj ) procedure > ... > | <add this> > | If an implementation uses IEEE 754/854 format for inexact > numbers then: > | > | * If z is an inexact complex number, then (real? z) is true if and > | only if both (exact? (imag-part z)) and (zero? (imag-part z)) are > | true. > ... > | For implementations that allow (real z) and (imag z) to have > different > | exactness, then (exact? z) returns #t if and only if both (exact? > | (real z)) and (exact? (imag z)) return #t. > | <end of addition> > > A number is either exact or inexact; and a complex number (like a > rational number) is one number, not two. Exactness thus applies to > the whole complex number, not to its components. Is this an objection to part of my recommendation? Under my recommendation, (exact? z) still returns either #t or #f. > > | <change the following predicates> > | (zero? z) library procedure > | (positive? x) library procedure > | (negative? x) library procedure > | (odd? n) library procedure > | (even? n) library procedure > | These numerical predicates test a number for a particular > | property, returning #t or #f. > | > | If an implementation uses IEEE 754/854 format for its inexact > numbers, > | then zero?, positive?, and negative? return #f if called with a NaN > | argument. > > The names of the arguments already restrict positive?, negative?, odd? > and even? to argument types to which NaN does not belong. Passing NaN > to them is an error. I didn't understand this comment until I read the one below. I take it from your next comment that NaN is not real; I disagree. > > | <change the following procedures> > | > | (max x1 x2 : : : ) library procedure > | (min x1 x2 : : : ) library procedure > | > | These procedures return the maximum or minimum of their arguments. > | > | (max 3 4) =) 4 ; exact > | (max 3.9 4) =) 4.0 ; inexact > | > | If an implementation uses IEEE 754/854 format for its inexact > numbers, > | and any of the arguments to max and min are NaNs, then max and min > | returns one of the NaN arguments as its result. > > IEEE NaN is not real, having no position in the well-ordered > real-numbers. It is thus an illegal argument to MAX, MIN, <, <=, >, > and >=. Again, I disagree; I would follow IEEE 754/854 practice and require that NaN be unordered wrt any other value (including itself), but that it still be real (but not rational). > > | <change the following procedures> > | (+ z1 : : : ) procedure > | (* z1 : : : ) procedure > | > | These procedures return the sum or product of their arguments. > | > | (+ 3 4) =) 7 > | (+ 3) =) 3 > | (+) =) 0 > | (* 4) =) 4 > | (*) =) 1 > | > | Note: We recommend that (+ 0 z) => z, (* 1 z) => z, and (* 0 > z) => > | 0 for all z. This simplifies some rules for addition and > | multiplication for complex and inexact numbers if an > | implementation uses IEEE 754/854 format for its inexact > | arithmetic. > > Processors have either hardware to manipulate floating-point numbers, > or library routines to emulate the hardware. Changing the IEEE-754 > rules (so that 0 * NaN --> 0) will complicate, not simplify the > implementation of numerics. Perhaps you misunderstand my notation (which I believe to be standard, by the way). By "0" I mean "exact 0", not inexact 0, thus not IEEE-754 0. Since I know of no current processor that has a "multiply a floating-point number by an exact integer" instruction, then I don't think your objection here is valid. I also find it ironic that you're very willing to change the semantics of Scheme in your immediately previous suggestion to disallow the use of hardware compare instructions for comparing IEEE-754 values, while complaining about a perceived (but in truth, false) problem in my specification that you imagine would disallow the use of hardware multiply. Brad

**References**:**My suggestions to the R6RS committee about numerics***From:*Bradley Lucier

**Re: My suggestions to the R6RS committee about numerics***From:*Aubrey Jaffer

- Prev by Date:
**Re: My suggestions to the R6RS committee about numerics** - Next by Date:
**Re: My ideas about infinity in Scheme (revised)** - Previous by thread:
**Re: My suggestions to the R6RS committee about numerics** - Next by thread:
**Re: My suggestions to the R6RS committee about numerics** - Index(es):