Here is an easier alternate.
On Friday, March 29, 2002, at 02:57 PM, Dar Scott wrote:
> 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.
I might add...
For everyday numbers, under the default numberFormat, formatting
is exact; that is, (x & empty) = x.
I think there might be a way to meet these goals that can be
implemented quicker than the other suggestion and would meet less
problems in backward compatibility. It might be easier to accept
all around.
As it is numbers are binary floating point and are limited in
precision to about 15 digits. Integers can be represented exactly
for 15+ digits. Equality (=) is accurate to 14 digits. Values can
have one meaning as a number and another as a string; there are
values for which (x & empty) = x is not true.
There might be a simple way to make numbers easier for kids and
everyday work. "Everyday numbers" behave in a simple, easily
predictable way. Numbers outside that might behave in a way that
is harder to predict or requires computer insight.
Exactly what "everyday numbers" are depends on the exact
implementation. They must be easy to describe. This might be
defined as any number that can be written in 14 digits. Or this
might be defined as any number with 20 or less digits to the left
of the decimal point and 8 or less digits to the right. There
might be lots of ways to come up with "everyday numbers" that are
easy to describe.
I suggest that for "everyday numbers", things change so that these
are true:
1. Arithmetic among everyday numbers is exact. That is, if the
arguments to a function are everyday and the result is everyday,
then the function is exact. Also, equality is exact between any
two "everyday numbers".
2. (Optional, but nice) Formatting for "everyday numbers" is exact
(with the default numberFormat). That is, the display of a number
will show exactly what number it represents.
One or both of these might be true for lots of numbers outside of
the range of "everyday numbers; the definition of everyday numbers
is kept simple, though.
The second one above might require that the everyday number
definition be related to the default numberFormat. For example,
the default numberFormat is "0.######". A compatible description
of everyday numbers might be those who have numerals with less than
10 digits to the left of the decimal and less than 6 digits to the
right. The 6 digits requirement matches the six #'s.
Unlike the other recommendation, this one allows floating point or
scientific notation.
Here are a couple approaches that might be used.
1. Go to a larger floating point representation (say, 16-byte) and
scale numbers by a power of ten such as 1000000. (The number of
zeros in the scaler is equal to or greater than the 0's and #'s to
the right of the decimal point in the default numberFormat.) The
value of the Revolution number .000001 might be stored as 1 in the
floating point notation. The floating point representation is
large enough so that old apps using 15 digit whole numbers and 14
digit equality still work. Everyday numbers are those with up to
14 digits to the left and up to 6 digits to the right of the
decimal.
2. Go to IEEE-854 or similar. This is the floating point standard
with a decimal exponent.
In one sense, the current "everyday numbers" are those with 14
digits to the left and zero to the right.
I beat this enough.
Dar Scott
_______________________________________________
improve-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/improve-revolution
