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

*To*: tb@xxxxxxxxxx*Subject*: Re: string->number*From*: Aubrey Jaffer <agj@xxxxxxxxxxxx>*Date*: Wed, 15 Jun 2005 17:10:40 -0400 (EDT)*Cc*: mathematica@xxxxxxxxx, alexshinn@xxxxxxxxx, srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <874qcgchtz.fsf@xxxxxxxxxxxxxxxxx> (message from Thomas Bushnell BSG on Thu, 02 Jun 2005 19:08:56 -0700)*References*: <20050531071658.EC10C1167@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20050531234805.0EC7F1B77B4@xxxxxxxxxxxxxxxx> <874qcgg4uf.fsf@xxxxxxxxxxxxxxxxx> <20050602161228.B3E3D1B77B4@xxxxxxxxxxxxxxxx> <87hdggentm.fsf@xxxxxxxxxxxxxxxxx> <20050602191022.A42F31B77B4@xxxxxxxxxxxxxxxx> <87zmu8cynq.fsf@xxxxxxxxxxxxxxxxx> <20050603015939.99B1C1B77B4@xxxxxxxxxxxxxxxx> <874qcgchtz.fsf@xxxxxxxxxxxxxxxxx>

| From: Thomas Bushnell BSG <tb@xxxxxxxxxx> | Date: Thu, 02 Jun 2005 19:08:56 -0700 | | Aubrey Jaffer <agj@xxxxxxxxxxxx> writes: | | > | From: Thomas Bushnell BSG <tb@xxxxxxxxxx> | > | Date: Thu, 02 Jun 2005 13:05:29 -0700 | > | > ... My point is that inexact numbers correspond to real number | > neighborhoods; and hence have finite precision. | | Ok, that's fine. I agree completely with what you've said about | *inexact* numbers. | | ... I think that a Scheme implementation may also extend the nature | of an external representation if it wishes, provided it keeps | numbers separate from identifiers for all programs, in the right | way. | | In other words, an implementation can invent a new syntax, say #s, | where #sNNNN is the square root of NNNN, exact iff NNNN is. For a | great many of the standard operations of Scheme, this exactness can | be easily preserved with a straightforward implementation. I am having difficulty with inexact square-root numbers. The real numbers have a total ordering. So for any two real numbers x1 and x2, either x1 < x2, x1 > x2, or x1 = x2. #s2. splits the 1.4142135623730951 neighborhood into three parts; lets call them #s2.-, #s2., and #s2.+. Because "... it is the duty of each implementation to make the result as close as practical to the mathematically ideal result", 1.414213562373095048801689 must map to #s2., while 1.4142135623730951 maps to #s2.+. The split neighborhoods must be distinguished from each other because of the total ordering. But a floating-point representation has no additional bits to encode which side of which square-root any particular floating-point value is. Thus inexact square-root numbers and inexact floating-point representation are incompatible. | NUMBER->STRING must produce this representation, and STRING->NUMBER | must be able to handle it, and it should work the same as READ and in | program text. Such an extension is fully allowed by R5RS. | | If you argue that external representations for numbers CANNOT be | extended, then you can make no sense of the explicit statements in the | standard and the rationale for supporting exact numbers of just this | sort. Polar representation works because the polar coordinates of Real numbers are in one-to-one correspondence with the Real numbers. But one cannot casually add new inexact representations.

**Follow-Ups**:**Re: string->number***From:*Thomas Bushnell BSG

**References**:**Re: infinities reformulated***From:*Chongkai Zhu

**Re: infinities reformulated***From:*Aubrey Jaffer

**Re: infinities reformulated***From:*Thomas Bushnell BSG

**Re: infinities reformulated***From:*Aubrey Jaffer

**Re: infinities reformulated***From:*Thomas Bushnell BSG

**string->number***From:*Aubrey Jaffer

**Re: string->number***From:*Thomas Bushnell BSG

**Re: string->number***From:*Aubrey Jaffer

**Re: string->number***From:*Thomas Bushnell BSG

- Prev by Date:
**Re: [srfi-70] Limit** - Next by Date:
**Re: string->number** - Previous by thread:
**Re: string->number** - Next by thread:
**Re: string->number** - Index(es):