Dar Is the behaviour of the following code fragment relevant to what you are after, or have I misread you?
set numberformat to "0.0" put .05 + .01 into x set numberformat to general put x -- produces zero, not 0.1 or 0.06 If, however, you are thinking that in future we must deliberately set a long precision to retain "best available" mathematical accuracy in sequential calculations, rather than that being the default, then I would not like it at all. regards David On Saturday, March 30, 2002, at 08:57 , Dar Scott wrote: > > Children and the computer naive should be able to use numbers in > Revolution without being confronted with unexpected behavior. Others > might find controlled precision useful. > > Because of that I make this recommendation to the Revolution engine, > that is, the MC engine. I realize this is a major overhaul. > > I think these constraints are reasonable: > > Boundary rules and precision rules concerning Revolution numbers > should be such that they never apply to everyday numerical > ranges and precisions. > > The change should be backward compatible, except in those > perverse cases where increased precision/accuracy is harmful. > > The total number of concepts should be minimal and borrow > from everyday math as much as possible. > > There should be no astonishment as to how long it takes > to calculate a value. > > Perhaps this is enough, but I thought I'd supply some detail that would > help in understanding what I mean. > > Recommendation: > > The core of my recommendation is this. The Transcript Dictionary says, > "The numberFormat property specifies how many digits before and after > the decimal point a computed number should have." Lets make that > exactly true. > > Here are the details... > > 1. All values are strings (ignoring arrays). (The implementation might > use some tricks underneath but no tests can reveal those.) > > 2. Some strings are numerals. Those numerals can be interpreted as > mathematical numbers (by the definition of numeral, I guess). Those > numerals can be interpreted as Revelation numbers. Those > interpretations are always exactly equal. (But, see an option below.) > > 3. The result of a math function always conforms to the local property > numberFormat (as modified by allowBigNumbers described below). The > precision/accuracy of the result is always such that the numerical > interpretation of the result is always within last digit truncation or > round of the exact mathematical answer, or a similar documented > constraint for interesting functions. > > 4. If the new local property allowBigNumbers (default = true) is false, > then the number of digits (of a result) to the left of the decimal > point is limited to the hashes and zeros to the left of the decimal > point in numberFormat. Should a result be beyond those limits, then > the result is replaced with the value in either of these constants: > tooBigPositive or tooBigNegative. The documentation states whether > "tooBigPositive is a number" is true or false or > either-but-not-defined. Same with tooBigNegative. It also should be > clear what it means to use these as an parameter to a mathematical > function. (See below for an alternative.) > > 5. If allowBigNumbers is false or would not affect the result, then the > time to compute any mathematical function is bound by the format in > numberFormat. If there are perverse cases in advanced functions that > depend on the actual values, then either this is documented, or > precision/accuracy is lost and this is documented. > > Here are some alternatives. I am uncomfortable with some of them, but > an implementer might be happier with them. Some add concepts. > > A. The numeric interpretation of a string when it is a parameter to a > mathematical function is filtered by numberFormat and allowBigNumbers. > (This may be needed for 5, above.) It is OK for this to affect "is a > number", but that should be documented. > > B. If allowBigNumbers is false and the digits of the mathematical > result goes beyond the left-of-decimal limits of numberFormat, then the > resulting string is the exact result with the upper digits cut off. > The overflowResult() function will return tooBigPositive, > tooBigNegative, or empty. > > C. The number of effective zeros or hashes to the right of the decimal > point in numberFormat is limited to, say, 25. A similar constraint > might also be applied to the left. Those must be well beyond everyday > arithmetic. > > There are some interesting implications: > > The result of everyday arithmetic is always exact. > > The combination of numberFormat and allowBigNumbers define a unique > numeral for a given number. > > Numbers are always wysiwyg. > > Dar Scott > > > > > _______________________________________________ > improve-revolution mailing list > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/improve-revolution > _______________________________________________ improve-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/improve-revolution
