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