[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*: Thomas Bushnell BSG <tb@xxxxxxxxxx>*Subject*: Re: string->number*From*: bear <bear@xxxxxxxxx>*Date*: Thu, 16 Jun 2005 09:59:30 -0700 (PDT)*Cc*: Aubrey Jaffer <agj@xxxxxxxxxxxx>, mathematica@xxxxxxxxx, alexshinn@xxxxxxxxx, srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <871x72wcd9.fsf@xxxxxxxxxxxxxxxxx>*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> <20050615211040.E9DDA1B77B4@xxxxxxxxxxxxxxxx> <871x72wcd9.fsf@xxxxxxxxxxxxxxxxx>

Hmmm.... I like the idea of an implementation able to represent more numbers exactly. An "Nth Power of M" exact representation, where N and M are allowed to be any integer, would add much of that subset of the number line resulting from ordinary computation to the numbers exactly representable. I think that is an unequivocally good thing. The implementor of such an implementation would need to take great care when writing procedures to perform comparisons among exact numbers, but the problem is not insoluble. At the moment, though, we're discussing inexact numbers in IEEE-ish mantissa-exponent style notation, but of differing lengths. And my personal take on that is, rather than treat each number as a "neighborhood" I'd prefer to treat it as a "point" on the number line. This allows a very specific kind of inconsistency, but that inconsistency happens for good and comprehensible reasons, and "hiding" it may sometimes hide important information. Example of inconsistency: Consider two computations, A and B, that yield results a and b such that a > b, but by a very small amount. If a is stored in a short, forcing a round down, and b is stored in a short, forcing a round down (but not as much), then (= a b) ==> #t, even though the computations A and B return different values. If a is stored in a short, forcing a round down, and B is stored in a long, forcing a (*MUCH* smaller) round up or down, then (> b a) ==> #t, even though B gives a value strictly less than A when carried out to the same precision. But I think this kind of "inconsistency" is both reasonable and expected by anyone who would have a reason to specify that the results should be given in a specific floating-point format, and efforts to "avoid" it can only result in inconsistencies of a less understood or less expected kind, possibly reducing the utility of extended float formats by crippling comparisons against them. Bear

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

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

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

- Prev by Date:
**Re: string->number** - Next by Date:
**Re: string->number** - Previous by thread:
**Re: string->number** - Next by thread:
**Re: string->number** - Index(es):