Re: This calculation is just wrong / computer can't count!

And we have explained, over and over again, that it is impossible to achieve your goal
using floating-point arithmetic, and it is possible to achieve it using only using very
elaborate, and very slow, and/or very memory-intensive representations. BIGNUM rational
arithmetic will work up to but not including input and output, unless your input and
output are expressed as fractions with numerator and denominator. So there will be errors
on input and errors on output. Example: if your input is 1/3 then rational arithmetic
stores this as <1,3>. If you multiply it by 3, rational arithmetic stores it as <3,3> or
perhaps reduces the faction to <1,1>. So you get 1/3*3 = 1.000000000000. But if you type
ing 0.333333333333333 to ANY number of digits, you will NEVER get 1.0 when you multiply it
by 3; you will ALWAYS get 0.9999999999999999999999 to the limits of whatever precision you
have available.

Now, double-precision floating point cannot represent 0.33333333333333333. It cannot
represent 0.3333333333333333333333333333333333333. The closest the FPU can represent is
0.33333333333333331. But if you multiply 0.33333333333333331 by 3 you get PRECISELY
1.00000000000000000. This is because of how 64-bit floating point arithmetic works. So
if you claim that the 0.33333333333333331 is "wrong", then you have to explain how
multiplying it by 3 produces a value that is "right". But the point here is that the
conversion from decimal to binary introduces an error, and the conversion from binary to
decimal produces an error, and in this case the errors work properly, because if you type
in 0.33333333333333333 and convert it to FP, you will get 0.33333333333333331.

Similarly, if you convert a number for output, there will be an error. If you sit down
with paper and pencial and compute 2/3, what number do you write down? Both options are
wrong. 0.66 or 0.67 are both wrong. 0.666 and 0.667 are both wrong. This is because
there is no precise representation of these values in decimal arithmetic. So it is
unrealistic to expect that (2/3)*3 = 2. In fact, it is either
0.66666666666666666 * 3 = 1.9999999999999998
or
0.66666666666666667 * 3 = 2.0000000000000001

If you compute
(2/3)*3 - 2
using a pencil and paper, you will get either
-0.00000000000000001
or
0.00000000000000001

Now, if you write these numbers down in a columnar *** of paper with one character per
column, with the decimal points aligned, and place another *** of paper on top to mask
off the least significant digits, you will get either
-0.0
or
0.0

OK, so we've established that in the "real mathematics" of primary school, it is
impossible to have
(2/3)*3 - 2 = 0.00000000000000000
but if we use algebra, we note that this turns out to be

((2*3)/3) - 2
and we can cancel the numerator and denominator and get
2 - 2
and in integer arithmetic this does equal 0.

So you either have to store the numbers as fractions, or deal with certain errors. Note
that integers are the special case of the rational value <n, 1> for various integer values
n.

But note the in the IEEE-754 FPU, if we have

2.00000000000000000 / 3.0000000000000000 = 0.66666666666666663
but if we do
0.66666666666666663 * 3.0000000000000000
the answer is
2.00000000000000000

Now, this is cute, but largely accidental. Any finite precision arithmetic, whether it is
done in floating point binary, packed BCD, decimal characters, etc, will ALWAYS have
cumulative error. IEEE-754 has been carefully designed to MINIMIZE these errors, but it
is not perfect. Consequently, there will ALWAYS be computations which CANNOT be precisely
expressed in finite mathematics. Therefore, it is ALWAYS necessary to handle rounding and
significant digits yourself. In addition, during computations you will always have to be
aware that no matter what finite-precision arithmetic you use, these errors will change
the fundamental nature of your algorithms. This has been understood since John von
Neumann programmed the very first electronic computer, and had been understood since the
first mechanical calculator, and had been understood since the first arithmetic
computations were done (remember, the value of pi was first approximated in the 19th
century BC, and it was known to be precise only within certain limits). But given a
circle, of say, the diameter of Earth's orbit, do we really need to compute the precise
circumference to the Planck length (1.616252E-35 m)? So we look at the digits of
precision required to express the values needed and work within those bounds. Beyond the
precision we need, nothing matters. If you need two digits of precision then any value
greater than -0.001 and less than 0.001 is essentially 0. That's the reality of
finite-precision math.

Now the catch is that if you run a billion additions of 0.001 you don't get 0, even if the
value is logically 0. In fact, you are now off by a huge amount. If this were a space
probe, you've just missed Jupiter by a hundred million miles. So you have to look at the
impact of significant digits on cumulative error. This has always been true since
computation was invented (a few millenia ago). Note that prior to the invention of
decimal notation, values which were not integers were expressed computationally as
fractions, but it was known that even fractions were approximations and there were
inherent errors. Irrational numbers like pi (meaning, they cannot be expressed in terms
of fractions of integers) were understood and error bounds were given. Depending on the
precision required, So the Babylonians (see wikipedia) used 25/8, the Egyptians used
256/81, Archimedes estimated the value as being between 223/71 and 22/7. The Indians, in
the 5th century AD, used 62832/20000. So if you needed a quick check on the diameter of a
field, you could compute it more quickly using 22/7, but if you were doing somethat that
required more precision, you could use 62832/20000 which requires more computational
effort. Ultimately, values were expressed in some integer units, and the choice of
integer units was based upon the precision required. So we have units of inches, feet,
miles, etc., all of which introduce an error. If I compute a circumference to an integral
number of inches, but have to wrap 100,000 turns of wire around a very long rod, I'll end
up with either too much wire (if I rounded up) or too litle (if I rounded down). But if I
compute the diameter to 0.01 inches, I have a smaller error. If I compute the diameter to
0.0001 inches, I could be more precise, but then I have to worry about the air gap between
the wire and the rod, which might be > 0.0001 for some turns, so I might still end up
short if I compute the precise length to 0.0001 inches. And if I wrap it outdoors in
Minnesota in January, or outdoors in Phoenix in July, I'll end up with different results
for a different reason! Mathematical imprecision is a fact of daily life, and your
attempting to avoid it is ultimately doomed due to the very nature of reality.
joe

On Wed, 10 Oct 2007 11:01:44 +0100, "GT" <ContactGT_remove_@xxxxxxxxxxx> wrote:

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:7tcog39kbdohk5vu9ked5pueu91joojj9q@xxxxxxxxxx
Define "properly". Or is this one of those nonsensical statements about
values that
should or should not equal zero? We have already explained that you
cannot possibly,
ever, under any circumstances imaginable, expect that any floating point
computation will
produce a value equal to any other expressed floating point computation or
constant, and 0
is once such constant.

And I have asked you over and over and over - "So what will?"

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.