Oh, @avi_shor, is that your problem? Floating point errors?
"Error" is a misnomer for these results. Every floating point numeral represents a range of actual numbers, and so when you do floating point arithmetic, both the inputs and the outputs are ranges of numbers. The string of digits you see displayed is one of the numbers in that range. I believe it's theoretically possible to determine the simplest rational number (smallest numerator and denominator) in that range, and yeah, we could find a way to print that, and maybe that would be the answer you wanted.
Having said that, it is possible to get actual errors in floating point computation because of the limited precision. Recall that you get around 15 decimal digits of precision, but there's a huge range of representable numbers because of scientific notation. So, pretend for a moment that the internal representation actually used decimal digits. (There were computers like that, in my youth.) We can compute a very small number:
Now add that to 1:
That's not a roundoff error in the display of the value; the floating point format really can't represent
1.000...(40 zeros)...0001
so the computed result really is exactly 1. So far, this still isn't an error; it's just a limitation of the precision of the representation. But what if you do this:
Don't try this; it'll take forever. But suppose you had a very fast computer. What answer would you get? You'd get 1, because each CHANGE wouldn't actually change the floating point value A. But, the answer you should get, mathematically, is 2, right? And in fact you would get 2 if you reordered the computation to start with the small values:
(Actually, I'm not sure, you might get less than 2 because some of the intermediate additions might have the same problem about adding a large number and a small number. But you'd definitely get more than 1!)
So that actually is an error; two mathematically equivalent computations give different results. In other words, floating point addition isn't associative.
The particular example with small powers of ten is artificial, but this general problem comes up in practice a lot. When you are computing a power series for 𝜋 or something like that, the terms in the series get smaller and smaller, and so if you add them in the natural order, you get the wrong answer.
The assumption here is that f(1) > f(2) > f(3) > f(4) ... so eventually adding the next term doesn't change the floating point result, and that's when you report the current value. You have to do the computation from large to small in order for the end test to work. But if you do it this way, you'll probably get a floating point roundoff error. Instead you have to decide ahead of time how many terms you're going to compute, and add them up small to large:
You now know everything I know about numerical analysis.