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

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.

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