This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.
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