[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*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Subject*: Re: inexactness vs. exactness*From*: bear <bear@xxxxxxxxx>*Date*: Thu, 21 Jul 2005 17:22:12 -0700 (PDT)*Cc*: srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <20050721170155.F3A021B77B4@xxxxxxxxxxxxxxxx>*References*: <y9lvf38ba3a.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0507180818240.7111@xxxxxxxxxxxxxx> <20050718235825.0D1381B77B4@xxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0507181844440.8883@xxxxxxxxxxxxxx> <20050721170155.F3A021B77B4@xxxxxxxxxxxxxxxx>

On Thu, 21 Jul 2005, Aubrey Jaffer wrote: >You are suggesting that an implementation in which inexact numbers are >not neighborhoods can conform to R5RS. I will show that this is >impossible. > >If real inexacts are not neighborhoods, then they correspond to single >mathematical numbers (points). > >The number of inexact numbers possible in this hypothetical system is >either finite or not. > >Finite number of inexacts: > > There are an infinite number of possible continuous formulas (Scheme > procedures) yielding distinct values when applied to inexact > arguments. If the number of possible inexact numbers is finite, > then an infinite number of the formula results must map to the > finite inexacts; and (because of continuity) they must be > neighborhoods. You are confusing the limitations of real hardware with the specification in order to arrive at a false dilemma. The standard allows implementations to regard every inexact number as (say) negative nineteen and still be compliant; inexactness means simply that there is a chance (in such a boneheaded implementation a near certainty) that the inexact number is wrong. Now, you can regard this single-valued inexact number system as the ultimate "neighborhood", or you can regard it as being potentially wrong; IMO, the standard does the latter. >Infinite number of inexacts: > > There are an infinite number of possible formulas (Scheme > procedures) involving transcendental functions yielding distinct > values when applied to inexact arguments. > > R5RS 6.2.2 Exactness states: > > If two implementations produce exact results for a computation > that did not involve inexact intermediate results, the two > ultimate results will be mathematically equivalent. This is > generally not true of computations involving inexact numbers since > approximate methods such as floating point arithmetic may be used, >=> but it is the duty of each implementation to make the result as >=> close as practical to the mathematically ideal result. > > By R5RS 6.2.2, if a transcendental function returns an approximate > result, then it must map to the nearest inexact number. Thus > inexacts designate their closest neighborhoods. No, this just says that you acknowledge the answer is wrong, but exhorts you you try to make the system something other than totally useless. This doesn't make the inexact numbers into "neighborhoods," it just means that the exact answer is not representable so we're giving a wrong answer and we're going to get as close to the correct answer as we can. If your only representable inexact number is minus nineteen, then that's what you return; but you don't make it exact, because that would be claiming that it were the correct answer. >So, not only is it proved that: > >* Scheme inexact real numbers correspond to real neighborhoods; You've proved no such thing. Inexact has no meaning other than "this answer may be wrong." Bear

**Follow-Ups**:**Re: inexactness vs. exactness***From:*Aubrey Jaffer

**References**:**Revision of SRFI 70 available***From:*Michael Sperber

**Re: Revision of SRFI 70 available***From:*bear

**inexactness vs. exactness***From:*Aubrey Jaffer

**Re: inexactness vs. exactness***From:*bear

**Re: inexactness vs. exactness***From:*Aubrey Jaffer

- Prev by Date:
**Re: Nitpick with FLOOR etc.** - Next by Date:
**Re: Nitpick with FLOOR etc.** - Previous by thread:
**Re: inexactness vs. exactness** - Next by thread:
**Re: inexactness vs. exactness** - Index(es):