On Saturday, March 15, 2003, at 10:54 PM, curry wrote:
From trying it out with some operations, it looks like about 16 digits (whole or decimal) can be trusted. Using the 16th digit as a rounder, that would mean 15 digits usable answer.
My question is, can we trust about that number of digits for all types of calculations?
Yes. Use 14. (49 bits floating point) Use less if you need exact equality.
In many cases one can think of all values except arrays as strings. However, when you press limits like this, that may not be sufficient. The result of arithmetic is stored internally as floating point. It is still floating point when used in subsequent arithmetic, but a copy converted to a string is used in non-arithmetic operations.
A consequence is that you may also lose digits when a number is converted to string based on the numberFormat property. This happens when an operation needs a string. This includes concatenation (&) as well as a few operations that you might not realize are converting (such as send).
You might also see some interesting rounding in some arithmetic. This is because the rounding is based on a binary point. This is mitigated somewhat with a (standard) laxness in numerical equality. However, that laxness may also cause surprises.
Note that in some operations (such as base conversion and in bit-logical operations, I think), you are limited to 31 or 32 bits.
And are there any plans to change the way Revolution handles this?
I have no inside knowledge of this, so my comment is pure speculation.
I do not expect this will change any time soon. One reason is the natural inertia of such things. It works just fine for people who use Rev arithmetic, a group self-selected because the arithmetic does what they want. Another is compatible semantics among platforms; this is implemented using hardware (where I have used it) and the change (advance) should work across the primary platforms.
There are three directions a change might occur. The simplest is simply more precision. I think this most likely should a change occur. I wouldn't be surprised if representation changed from 8 byte fp to 16 byte fp in the next five years. The second is the use of a decimal point. This is not likely to occur if it involves a decrease in precision or a multifold decrease in speed. (It is commonly assumed that this requires a decimal internal representation such as BCD; this is not true.) The third is a paradigm shift such as indefinite precision. I doubt this will occur.
Since you can safely work with a 12 digit integer (say), you can use that as a building block to build other types of numbers. I would do this rather than wait for a change.
Dar Scott
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
