Re: My suggestions to the R6RS committee about numerics

[Aubrey Jaffer <agj@xxxxxxxxxxxx>]

 | From: Bradley Lucier <lucier@xxxxxxxxxxxxxxx>
 | Date: Mon, 23 May 2005 14:36:18 -0500
 | 
 | OK, let's try this again.
 | 
 | I wrote:
 | 
 | > The first part deals with IEEE 754/854 arithmetic. If you don't  
 | > support this arithmetic, then things are still up in the air.
 | > ...
 | > 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.
 | > ...
 | > If an implementation uses IEEE 754/854 format for inexact numbers  
 | > then:
 | 
 | etc.  I mean to imply that other types of inexact arithmetic are  
 | possible, and these parts of the specification don't necessary apply  
 | to them.  I don't pretend to be able to imagine all possible inexact  
 | arithmetic systems.

You shouldn't need to.  We shouldn't code around bizarre, hypothetical
number-systems having such poor behavior that they will never be
implemented.  The language standard should try to specify mathematical
properties essential to computation.

Fixed-size inexact representations should be constrained with a rule
like:

  Increasing from the origin (0), the differences between adjacent
  inexact numbers are nondecreasing.
  Decreasing from the origin (0), the differences between adjacent
  inexact numbers are nonincreasing.

Such a rule allows both floating-point and logarithmic number systems.

 | You wrote:
 | 
 | > Why are you restricting the specification of inexacts to  
 | > IEEE-754/854 arthmetic?
 | 
 | which I take to imply that you think my entire specification allows  
 | only IEEE-754/854 arithmetic.
 | 
 | Is this right?  If so, I don't understand why you think this.

For inexacts your proposal specifies only the behavior of IEEE-754/854
numbers; leaving the rest "up in the air".  You have explained why
above; thanks.

 | Again, I wrote:
 | 
 | > (exact? z)                      procedure
 | > (inexact? z)                    procedure
 | >
 | > These numerical predicates provide tests for the exactness of a
 | > quantity.  For any Scheme number, precisely one of these
 | > predicates is true.
 | >
 | > <Add the following>
 | >
 | > 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>
 | 
 | This says explicitly that "For any Scheme number, precisely one of  
 | these predicates is true."
 | 
 | Now, I understand that
 | 
 | "z is exact"    if and only if "(exact? z) => #t"
 | "z is inexact"  if and only if "(inexact? z) => #t"
 | 
 | Under my recommendation, precisely one of these is true, so each  
 | scheme number is either exact or inexact, not both, and not neither.
 | 
 | You wrote:
 | 
 | > 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.
 | 
 | So what are you thinking?  What are you trying to say?  Do you think  
 | that this is in some way incompatible with my definition of exact?  
 | and inexact??  Or are you trying to make a separate point?

Section 6.2.2 Exactness states:

  With the exception of `inexact->exact', the operations described in
  this section must generally return inexact results when given any
  inexact arguments.

[SRFI-70 strengthens this assertion by removing the word "generally".]

REAL-PART or IMAG-PART returning an exact number for an inexact
argument violates this provision.