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.
On Tue, 9 Aug 2005, Aubrey Jaffer wrote: >Its time to wrap up SRFI-70. > >As with my other SRFIs, the Issues section generates no discussion, >even though it has the issues I consider unsettled. Yes, I consider them unsettled too - and largely unsettlable in the way this SRFI is attempting to do them. With some regrets, I think I also recommend withdrawal. Having a numeric-error object (such as nan) that propagates forward in calculations from a division by zero or other erroneous operation answers the requirements in the abstract far better than introducing and attempting to reason about "infinities." It allows people to avoid deeply nested checks for zero, instead testing whenever they like whether the most recent iteration of their algorithm has produced the error object. You can test for it and explicitly throw an exception if that's how you want to handle it, or you can make a substitution or correction explicitly and carry on. Given the usual vast differences in both absolute range and precision between exact and inexact notations, reasoning about "infinity" in exact and inexact forms is difficult and frequently produces transparently wrong answers when numbers of both exact and inexact forms are used. Given that, I'd have to regard numerics with nans as a superior choice mathematically and technically to numerics with infinities, for a language that distinguishes exact and inexact numbers. There is also (pardon me for saying this, but...) faint and fuzzy thinking in this SRFI about the properties of exactness and inexactness. Exact numbers, by definition, already denote a single mathematical number, with infinite precision. Some numbers cannot be represented exactly on any finite machine architecture because their representations would be too large to fit. "Precision" in the sense of representation length in exact numbers decides the size of the set of numbers we can represent, not the degree to which those numbers are precisely represented. The requirements you make of rouding for inexact numbers are reasonable-sounding, but cannot be carried forward through any level of abstraction. With an abstraction such as a procedure, we define a new mathematical operation in terms of one or more existing operations. Even if those existing (primitive) operations conform to your rounding requirement (simple connectivity), there is no way to assure that the composite operation represented by an abstraction also does so. For example, if I round two numbers up as I read them, and then add them and round the result of addition up, I have already reached a point where the "exact" result would be rounded to an inexact number which is not the number returned from the addition. Addition in this case is a composite operation because it subsumes the rounding errors of its arguments. The fact that it adds a rounding error of its own makes matters even more confused. So introducing the rounding requirements you do, without specifying exactly which primitive operations they apply to, does not permit any "ordinary" implementation of composite mathematical operations, because it is impossible to define a composite operation without making it subject to the same requirement, and also impossible to assure that it meets that requirement. The SRFI also proposes to repeal an implementation's power to return an exact number when it can prove that the result is exactly known. The specific example given in R5RS uses an exact zero as an example. This example is capital-T True, according to laws much deeper than the surface consistency on which grounds you object to it, because zero is a multiplicative identity element. Forbidding an implementation to return an exact zero in that situation is to ignore a fundamental law of mathematics and also forbid the implementation from providing true and potentially useful information to its user. > Given the vagueness of the term "flonum", the section 6.2.3 > paragraphs giving requirements for systems with flonums are not > dangerous in terms of preventing interesting implementations; > and SRFI-70 doesn't change them. It would be nice to improve > it; but converting exact to inexact is a thorny problem. Agreed fully, but.... I think this SRFI is like an attempt to hold jelly in place with nails; there's a good thought, and nails are a valid way to hold some things in place, but for this particular problem a different approach is likely to be better. Bear