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.
On Thu, 20 Oct 2005, Marcin 'Qrczak' Kowalczyk wrote: > I disagree. The problem is that R5RS tries to describe it as one of > two fields of a number, the other being its value - while in reality > it's a predicate about the representation of the value, not > independently settable. Well, as you said, you disagree. I don't think there's a non-repetitive argument to be made, but I consider it to be different than you. > 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. Don't present a false dilemma, when there are many many possible choices. > I claim that the practical utility of numbers represented as fixnums, > bignums or ratios but tagged as inexact is close to zero, and similarly > for flonums tagged as exact. I claim that this is not so. > 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. The abstraction R5RS describes is numbers, not representations. SRFI-77 messes that up and breaks a proper abstraction barrier. > 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. Remember that R5RS' full numeric syntax, which virtually nobody takes full advantage of, allows explicitly *telling* the system how much precision a number has. When we write 2.00000# we're telling our scheme that we know this value to only 6 significant figures; it could save time and increase cache hits by using single-precision floats for subsequent calculations. When we tell it we know something to 36 decimals, say by typing 100.000000000000000000000000000000000#, I think it is best to use a flonum format that preserves at least 36-decimal accuracy until some calculation gives a less-known result, or else report an implementation limitation if flonum representation of at least that accuracy is not supported. >> should exactness remain part of the standard? > It should be described as a property which can be inferred from the > representation, not as an independently settable field. Well, as you said -- we disagree. If that were all it was, I'd be in favor of just chucking it entirely because if that's all it is, then it's plainly useless (or redundant). > Are there any implementations where it is? MITScheme, for one. There are probably a few others. > Indeed. If everybody ignores something in the standard, it's should > raise suspections that the standard has made an unfortunate decision. Or at the very least a sign that many implementors have different aims and goals and purposes than the members of the standards committee. Which may be the same thing. Sigh. Numeric issues, and the ubiquity and limitations of this representation-type shortcut, were one of several reasons I started working on my own lisp (the other big ones were character and string handling and first-order functions). If R6RS adopts the proposals of SRFI-77, that will just be another point of divergence. Bear