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
