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

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.

*To*: lucier@xxxxxxxxxxxxxxx*Subject*: Re: My suggestions to the R6RS committee about numerics*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Fri, 20 May 2005 15:13:13 -0400 (EDT)*Cc*: srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <y9ly8acfewc.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> (message from Bradley Lucier on Wed, 18 May 2005 22:38:43 +0200)*References*: <y9ly8acfewc.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

| 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? | 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. | <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. | <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 >=. | <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.

**Follow-Ups**:**Re: My suggestions to the R6RS committee about numerics***From:*Bradley Lucier

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

- Prev by Date:
**Re: is NaN a number?** - Next by Date:
**Re: FP Hardware** - 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):