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 Mon, 18 Jul 2005, Aubrey Jaffer wrote: > | Date: Mon, 18 Jul 2005 08:50:50 -0700 (PDT) > | From: bear <bear@xxxxxxxxx> > | > | This draft effectively eliminates certain properties of > | inexactness vs. exactness, > >SRFI-70 sharpens the distinction between inexacts and exacts. It requires inexact numbers in many situations where exact numbers can be produced. >From >the R5RS notation of inexacts it deduces their nature as real >neighborhoods. A point on which we disagree. I don't think any such nature was inherent in R5RS. > Because exact numbers in Scheme designate single > mathematical numbers, the idea of exactness as a superficial attribute > of numbers must be jettisoned. A conclusion based on the point on which we disagree. It is not at all surprising that we disagree about this conclusion also. Inexactness denotes that we cannot be certain that the specific, precise number is the correct specific precise number; it does not transform the number into a numeric neighborhood. Exact and inexact numbers, except for this sole quality, denote exactly the same thing. > Inexactness is as much a property of calculation as it is of data > sources. A language having latent types does not obviate the > programmer's expectation that a calculation involving transcendental > functions should return an inexact result. But if error-free results happen to be available, we should therefore disregard them? What?! > An operation may, however, return an exact result if it can > prove that the value of the result is unaffected by the > inexactness of its arguments. For example, multiplication of > any number by an exact zero may produce an exact zero result, > even if the other argument is inexact. > > By those sentences, inexactness is a contagious property of all > numbers; except 0, the only number whose exactness is contagious! > This conflicts with the statement earlier in 6.2.2: No... by those sentences, inexactness in the sense of possible error propagates forward from arguments into results wherever we cannot prove that the inexactness doesn't introduce the possibility of error in results. A multiplication by an exact zero is only one of many possibilities here. > | and in doing so it creates a type distinction where none was > | before. > > Is exactness this "type distinction"? Yep. What you're doing is declaring that in some circumstances we have to pretend we are uncertain of our results even though there is a mathematical certainty that they are correct. The sole purpose for this is to fulfill an expectation that inexact results will be returned; you are valuing numeric type above reporting correct answers. > | In the dialect spec'd by R5RS, there was never any situation > | where an inexact number was required and an exact one would > | not do; thus it was entirely correct for implementations to > | return exact numbers whenever the opportunity presented > | itself. > >Implementations like Elk, Gambit, and Mzscheme signal errors for >division by exact zero, but return infinities for division by inexact >zero. This is a "situation where an inexact number was required and >an exact one would not do". That wasn't behavior specified by R5RS, was it? That was the decision of a few implementors, who created an inconsistency and a type distinction. This inconsistency was not created by the standard, and does not need to be "fixed" in the standard. > This created the contradiction noted above. With exact 0 being > stronger than inexact 0.0, it also leads to the opaque practice of > controlling the behavior of EXPT and `/' at 0 by coercing the > exactness of its arguments. "strength" has nothing to do with it. It is merely a mathematical fact. Any number may be multiplied by zero to get zero. If there is no uncertainty that the zero is the correct value (ie, if it's an "exact" zero in R5RS parlance) it does not matter a bit whether there is certainty about the other operand. Differences in the value of the other operand do not introduce any mathematical uncertainty (inexactness) that the result of zero is correct. Infinity in the sense of "some number too large to represent" is no exception to this rule; Infinity in the sense of a true mathematical infinity is, but the result of such a multiplication is neither exact nor inexact; it is a NaN. > I have authority to propose whatever I want. And the R6RS editors > have the authority to accept it, modify it, or ignore it. Yes, I suppose that's what it comes down to. I hope to see better treatment of numeric error objects than you propose. > I do a lot of numerical computing (near-field optics lately). > Division by zero happens. If SIN of some complicated expression > returns an exact zero .001% of the time, then .001% of the time I will > get an exception from the division taking that expression as a divisor > rather than an infinity which lets the program continue. This problem belongs to your implementation, not to R5RS. It would be perfectly compliant with R5RS and consistent treatment of numbers if your system raised an exception in both cases or returned an error object (such as an infinity or a NaN) in both cases. >That is broken behavior; but that is what R5RS-compliant Mzscheme 205 >does; and probably other implementations also. I don't argue with you that it is broken behavior; but I don't see the point in predicating changes to the standard based on a few implementations' inconsistent treatment of exact and inexact numbers. The situation is that you have a headache because you don't know whether the results will be exact or inexact, *and* the implementations you're using happen to treat exact and inexact numbers inconsistently; Inconsistency && Uncertainty -> Headache. You want this headache to go away, so do the ordinary boolean math, and you get... !Headache -> !Inconsistency || !Uncertainty In other words, this headache goes away if you know whether the results will be exact or inexact, *or* it goes away if implementations treat exact and inexact numbers consistently. Since the former involves pretending there is a possibility of error even where there is none and we can prove it, and thus discards useful information, why not ask for the latter instead? Isn't the inconsistent treatment (one continues and one signals an error) your problem? Why not call that incorrect behavior instead of calling an occasional blessing of extra information about the accuracy of the answer incorrect behavior? Bear