[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: My suggestions to the R6RS committee about numerics
| 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
| 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
[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.