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

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.

*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):