Re: My suggestions to the R6RS committee about numerics

[Bradley Lucier <lucier@xxxxxxxxxxxxxxx>]

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