[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*: Paul Schlie <schlie@xxxxxxxxxxx>*Subject*: Re: inexactness vs. exactness*From*: bear <bear@xxxxxxxxx>*Date*: Sun, 31 Jul 2005 11:46:54 -0700 (PDT)*Cc*: Aubrey Jaffer <agj@xxxxxxxxxxxx>, will@xxxxxxxxxxx, srfi-70@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-70@xxxxxxxxxxxxxxxxx*In-reply-to*: <BF124FA3.B08F%schlie@xxxxxxxxxxx>*References*: <BF124FA3.B08F%schlie@xxxxxxxxxxx>

Limiting the precision to that of the most-precise inexact argument, as suggested by Will Clinger and myself at different times, seems like a relatively practical thing to do (explanations below). However, it would be forbidden by the current suggested wording, because it runs against the principle of using a particular inexact value (expressible in, say, four words because one of the arguments was an inexact with four words of precision) when there are inexact values (which are expressible in 1024 words) that are actually closer to the mathematically expected result. On Sun, 31 Jul 2005, Paul Schlie wrote: >> From: bear <bear@xxxxxxxxx> >> I know that it's not the right thing in all cases and all times, >> but I think it's a good thing in most of the cases I use, for >> an operation on exact arguments whose mathematically correct >> result is too large to be represented as an exact number, to >> (silently) return an inexact number of the highest available >> precision. >- As personally I think it's poor idea to place the responsibility > to limit the precision of exact data such that calculations will > not exceed the practical physical limitations of an exact > implementation's representational capabilities on the programmer, > but rather believe that it's the responsibility of the implementation > to endeavor to limit the precision of an exact value's representation > to some practical physical limit in an effort to prevent such > scenarios; I'd rather see it become acceptable that an exact > implementation may return an imprecise exact value limited to some > implementation defined precision limit, where the precision limit > of an exact value's representation is presumed to be greater than > the precision supported by an inexact value's representation. Uh, this is faint and fuzzy thinking; no matter what the precision limit, if you have a situation where you're not getting the exact mathematically correct result, you must mark the result as being an inexact number. There is no limit on the size of the representation for inexact numbers; the "highest available precision" for inexacts may be several kilobytes long depending on what the implementation's author did. I agree with you, I think, about the desirable behavior: use exact results until they get too big, and then switch to inexact results _of_about_the_same_representational_precision to prevent further out-of-control growth. Unfortunately, most implementors limit inexacts to 64 bit (or even 32 bit) real values, and therefore have drastically different precision ranges and limits available for exact and inexact numbers. > As this would imply that such an exact implementation may have some > practical precision limit, it correspondingly must either be defined > to have the same representational magnitude bounds as an inexact > implementation, or by implication have distinct infinite and reciprocal > bounds defined. (where the former seems simplest, although apparently > only suggested in jest earlier). Ehhh. Only half in jest. Most of these problems do go away if you provide inexact numbers as big and precise as your exact numbers; But general-purpose schemata can't really be expected to do so, since most of them want blazing speed out of inexact numbers and are perfectly happy with inexact precision limited to 64 bits. I think I'd be happy in a scheme that represented numbers in up to 1024 words of memory, whether exact or inexact, marked them "inexact" if that wasn't enough to hold the correct answer but was enough to hold an approximation within reasonable roundoff errors, and returned an error object if the result was actually out of range (beyond the highest/lowest representable number). But for certain kinds of calculations, you'd still want a way to specify a much lower "precision limit" in order to get wrong answers really really fast. An example is most iterative adaptive algorithms; you get closer to the correct answer by making more iterations, much faster rather than by carrying each iteration out to 1024 words of precision. And since those answers were doomed to be wrong anyway (since they usually home in on irrationals) and the correctness is not usually very critical within a small roundoff error, why *not* limit them to 4 words of precision? So, I think it's desirable to have a numeric system where inexacts have a range of different precisions, depending on the precision of the arguments to the procedures that produced them as results. But this is where we violate the principle of always using "the" closest representable inexact value to the mathematically correct result. Bear

**Follow-Ups**:**Re: inexactness vs. exactness***From:*Paul Schlie

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

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