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

*To*: bear <bear@xxxxxxxxx>*Subject*: Re: inexactness vs. exactness*From*: Paul Schlie <schlie@xxxxxxxxxxx>*Date*: Tue, 09 Aug 2005 13:21:33 -0400*Cc*: Aubrey Jaffer <agj@xxxxxxxxxxxx>, <will@xxxxxxxxxxx>, <srfi-70@xxxxxxxxxxxxxxxxx>*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <BF1E5B23.B218%schlie@xxxxxxxxxxx>*User-agent*: Microsoft-Entourage/11.1.0.040913

(sorry, obviously I can't do arithmetic, as 10^300 => ~1K bits of precision implying that an application domain specific library would be required for public key cryptography beyond this precision, but still seems reasonable for most very large integer and/or geometric purposes that I can think of?) > From: Paul Schlie <schlie@xxxxxxxxxxx> > Date: Tue, 09 Aug 2005 13:07:47 -0400 > To: bear <bear@xxxxxxxxx> > Cc: Aubrey Jaffer <agj@xxxxxxxxxxxx>, <will@xxxxxxxxxxx>, > <srfi-70@xxxxxxxxxxxxxxxxx> > Subject: Re: inexactness vs. exactness > Resent-From: <srfi-70@xxxxxxxxxxxxxxxxx> > Resent-Date: Tue, 9 Aug 2005 19:09:43 +0200 (DFT) > >> From: bear <bear@xxxxxxxxx> >> On Mon, 8 Aug 2005, Paul Schlie wrote: >> >>> Thanks, I guess my point/question was predominantly related to the >>> observation that there seems often little need for truly "exact" >>> values beyond theoretical geometry and/or combinatorial mathematics, >>> which often themselves only require a determinable finite precision; >> >> This is a point on which you're going to lose. Combinatorial >> mathematics has developed subfields called cryptography, >> compression, and correction codes which are fundamental to >> modern networking. If you're doing any of those and you >> round anything off, you lose. > > - no, I've tried to already consider this, but as such algorithms tend to > only require (and actually rely on) finite precision modular integer > arithmetic, most typically well within the ~3K or so equivalent bits of > integer precision what would be required to represent a double's dynamic > range of a ~10^300 exactly (even for pubic key algorithms, which tend to > be typically be limited in practice to ~2k bits for even very secure key > exchanges). > >>> while simultaneously observing there's often broader need for more >>> precise potentially "inexact" values than typically supported by >>> double precision floating point implementations; so it just seemed >>> that in practice that it may be more useful to define that "exact" >>> values need only be as precise as necessary to support the exact >>> representation of the integer values bounded by the dynamic range of >>> the implementation's "inexact" implementation, and their >>> corresponding reciprocal values in practice (as you've implied); >> >> NACK! If you have limited precision, and the limited precision >> affects the answer, then the answer is inexact. PERIOD. There is no >> such thing as "exact numbers limited in precision" to *ANY* limit of >> precision. Once you go beyond a limit of precision and round >> something, you aren't talking about exact numbers anymore. Exact >> numbers are, by definition, *infinitely* precise. You may be talking >> about limiting the representation size of exact numbers, thereby >> decreasing the size of the set of exact numbers you can represent; but >> that's not the same thing. > > - so what, in practice all values beyond the theoretical are based on > measured values which are imprecise by definition; therefore in practice > I find it hard to believe that there's any truly identifiable value of > lossless calculations beyond the precision typically required by lossless > cryptography by default (which as required more domain specific library > packages can themselves leverage without having to burden the general > implementation or programmer with preventing the specification of > calculations which may yield irrational values, and/or force the > truncation of a result to significantly less precision than may be > supported by a inexact implementation?) > >> Infinite precision in finite memory arises when the number happens to >> match our representational scheme very well; integers and ratios of >> integers happen to be infinitely precise things we can represent in >> finite memory - but the finiteness of our memory means that we can >> only represent an infinitesimal fraction of those in any fixed amount >> of space. Things work because our usual calculations tend to give us >> results that are in the set of things we can represent; and when they >> don't, we can throw an error, if it's last-bit critical, or return an >> inexact number, if it isn't. >> >>> thereby both providing a likely reasonably efficient "inexact" (aka >>> double) >and a likely reasonably precise corresponding "exact" >>> representation, >> >> I will say it again. Exact numbers aren't "reasonably" precise. they >> are *exact*, which is to say "infinitely" precise. You are arguing >> for extended-precision inexact numbers, and I agree with you that >> these are needed and useful - but to call them exact is to confuse the >> issue and does not help. > > - yes, I know what the definition of the word is, but don't believe it's > literally significant beyond some reasonably typically required precision > as I've tried to explain above given our cryptography example. > > As in practice, it seems much more useful to know for example that an > inexact value may only be precise to ~50 bits of precision, and > hypothetically an exact value may only be precise to ~3000 bits, and both > constrained to the same dynamic range, where then with that knowledge, the > most appropriate form may be utilized directly, and/or leveraged by more > application specific domain libraries as may be required. > > (I know we differ in opinion on this point, but thank you for the > opportunity to express it, regardless of our being in agreement.) > >

**References**:**Re: inexactness vs. exactness***From:*Paul Schlie

- Prev by Date:
**Re: inexactness vs. exactness** - Next by Date:
**Wrapping up SRFI-70** - Previous by thread:
**Re: inexactness vs. exactness** - Next by thread:
**Re: inexactness vs. exactness** - Index(es):