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

*To*: srfi-77@xxxxxxxxxxxxxxxxx*Subject*: Re: Exactness*From*: Marcin 'Qrczak' Kowalczyk <qrczak@xxxxxxxxxx>*Date*: Fri, 21 Oct 2005 04:08:31 +0200*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <Pine.LNX.4.58.0510201408480.6745@xxxxxxxxxxxxxx> (bear@xxxxxxxxx's message of "Thu, 20 Oct 2005 15:08:57 -0700 (PDT)")*Mail-followup-to*: srfi-77@xxxxxxxxxxxxxxxxx*References*: <87wtk9qro1.fsf@xxxxxxxxxxxxx> <20051019191720.GA24703@xxxxxxxxxxxxxxxx> <87fyqxb6i6.fsf@xxxxxxxxxxxxx> <20051019220800.GF24703@xxxxxxxxxxxxxxxx> <Pine.LNX.4.58.0510191726410.13819@xxxxxxxxxxxxxx> <87ach45z5v.fsf@xxxxxxxxxxxxx> <Pine.LNX.4.58.0510201408480.6745@xxxxxxxxxxxxxx>*Sender*: Marcin 'Qrczak' Kowalczyk <qrczak@xxxxxxxxxx>*User-agent*: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

bear <bear@xxxxxxxxx> writes: >> Suppose we have two flonums tagged as exact. You divide them, and the >> result is not a finite binary fraction, so the implementation can't >> use the same representation for the result. What should it do? >> >> a) Represent it in a flonum tagged as inexact. >> b) Represent it as an exact ratio of two integers. > > c) consult settings or dynamic variables to see what the program > or user wants it to do. > d) give an exact result if the representation width needed for > it is allowed, otherwise give an inexact result with the > maximum representation width allowed by the current settings. > e) store a promise rather than an explicit numeric representation, > allowing the user to decide later how much precision they want > and propagating demands for precision into the branches of the > promise as necessary. > f) ... something else you haven't thought of. > g) ... something else *I* haven't thought of. In other words a portable program can't predict what will happen and can't state its requirements. This is bad. I know what to expect from IEEE floats. I know for example that calculations in a certain range of integers are exact. Or that numbers have the same relative precision but different absolute precision, for a wide range of magnitudes. Or that certain primitive operations take constant time, and a number uses a fixed amount of memory - it doesn't keep growing precision. I should be able to know more in Scheme - for example that by default a flonum overflow will not be fatal but will yield +inf.0, which will compare as greater than any other number except itself and +nan.0. I know what to expect from ratios. I don't know what to expect from inexact real numbers. Do they behave like floats, or like ratios with inexactness bit? It does matter! >> And that's good, it's not orthogonal. If it was, using different >> representations for numbers of the same value and the same precision >> would be redundant. R5RS even specifies that such numbers would be >> indistinguishable (even more: the precision is not compared but the >> exactness only, which is wrong if there are several possible amounts >> of inexact precision, and SRFI-77 fixes that). > > Yes. They *should* be indistinguishable. What if they have different precisions? Imagine a Scheme implementation with two flonum formats, where (= 3s0 3L0) is #t but (= (/ 3s0) (/ 3L0)) is #f; this behavior should't be surprising. What should be (eqv? 3s0 3L0)? >> I presume then that since (factorial 100) preserves all 158 digits, >> you want (factorial 100.0) to produce a result with 158 digits but >> tagged as inexact, right? > > If there is a presumption in effect that inexact numbers in source > whose precision isn't given explicitly are known to 158 digits or more, > then yes, I'd want the result to 158 digits. If the presumption is > that inexact numbers in source whose precision isn't given explicitly > are known to just 20 digits, then I'd want the first 20 digits and > the magnitude. If the number was read as 100.0, how many digits are accurate? The person who entered the data into a file didn't specify the precision; usually you can't assume that only these 4 digits are accurate. You propose that the programmer can't be sure what will happen. if it was obtained by (exact->inexact 100), then all digits are accurate. You propose that the programmer should not be able to apply exact->inexact to inputs to ensure that the result will be obtained numerically while keeping time and space of individual operations constant. > Remember that R5RS' full numeric syntax, which virtually nobody takes > full advantage of, allows explicitly *telling* the system how much > precision a number has. It's not enough. How many digits will #i1/3 store? You propose that the programmer can't know whether there is a fixed number of digits at all. If somebody implements fancy numeric types with dynamically settable precision or with lazily computed digits, I want to use them explicitly - I don't want them to take over the syntax that virtually all other languages use for IEEE floating point. I want the precision and efficiency of computation to be predictable. >> Are there any implementations where it is? > > MITScheme, for one. There are probably a few others. Huh? Judging from the sources it doesn't do anyhting like this. For example exact->inexact converts everything to flonums or a complex of flonums. -- __("< Marcin Kowalczyk \__/ qrczak@xxxxxxxxxx ^^ http://qrnik.knm.org.pl/~qrczak/

**Follow-Ups**:**Re: Exactness***From:*Thomas Bushnell BSG

**References**:**My comments***From:*Marcin 'Qrczak' Kowalczyk

**Re: My comments***From:*Bradd W. Szonye

**Re: My comments***From:*Marcin 'Qrczak' Kowalczyk

**Re: My comments***From:*Bradd W. Szonye

**Exactness (was Re: My comments)***From:*bear

**Re: Exactness***From:*Marcin 'Qrczak' Kowalczyk

**Re: Exactness***From:*bear

- Prev by Date:
**Re: Exactness** - Next by Date:
**Re: Exactness** - Previous by thread:
**Re: Exactness** - Next by thread:
**Re: Exactness** - Index(es):