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

Re: My suggestions to the R6RS committee about numerics

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.

 | 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

  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.