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

*To*: lucier@xxxxxxxxxxxxxxx*Subject*: Re: My suggestions to the R6RS committee about numerics*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Tue, 24 May 2005 20:30:31 -0400 (EDT)*Cc*: srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <77C632E3-4F60-4CFD-867F-AD716D931C95@xxxxxxxxxxxxxxx> (message from Bradley Lucier on Mon, 23 May 2005 14:36:18 -0500)*References*: <77C632E3-4F60-4CFD-867F-AD716D931C95@xxxxxxxxxxxxxxx>

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

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

- Prev by Date:
**Re: [srfi-70] Limit** - Next by Date:
**Re: infinities reformulated [was Re: My ideas about infinity in Scheme (revised)]** - 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):