The problem is just like what Charlie was posting about -- it's simply the nature of floating point imprecision at work.
Computers store values in binary format (Base 2). <-- This is an immutable fact of how computers perform.
Now, as base 2 values, our values are stored via bits.
1001 < this is the bit value to represent 9. That first one is in the (2 ^ 3) position, and that last one is in the (2 ^ 0) position, representing a total value of 9. In case you've never seen the binary values before, let's count in binary from 0 to 10.
0000 <-- Represents 0
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010 <-- Represents 10
Each digit is an increase in the power of 2, as you can see from above. The rightmost bit represents (2^0), and in this case, the leftmost bit represents (2 ^ 3).
(2 ^ 3) + (2 ^ 2) + (2 ^ 1) + (2 ^ 0) is what those 4 bits represent.
But, let's now add decimals to our system! What would 0001.1001 represent??
(2 ^ 3) + (2 ^ 2) + (2 ^ 1) + (2 ^ 0) + <decimal point placement for reference> + (2 ^ -1) + (2 ^ -2) + (2 ^ -3) + (2 ^ -4)
So the leftmost 1 represents a value of (2 ^ 0), or 1.
The 1 right after the decimal represents a value of (2 ^ -1), or 0.5.
And that last 1 on the far right represents a value of (2 ^ -4), or 0.0625.
Our total says that 0001.1001 represents a decimal value of 1.5625.
Now, here's a logic exercise for you: Try to add up powers of two until they equal 0.1 (one tenth).
1/2 is too large.
1/4 is too large.
1/8 is too large.
1/16 is too small. (0.0625) We have to add more onto it...
But at this point, we've now hit a basic mathematical enigma: How do we take infinite halves and add them together to get to 1??
We can't!
1/2 + 1/4 + 1/8 + 1/16 + 1/32 + 1/64 + 1/128 + 1/256 + 1/2^n... will never add up to 1! You just can't do it! It'll endlessly approach 1, but you can never get that value back *exactly*...
And that's what's going on when a PC tries to represent 0.1 internally as a binary, floating point number. It *CAN'T* store that number perfectly -- there's no way to perfectly represent 0.1 in binary format, just as there's no way to perfectly represent 1/3 in decimal format. 1/3, in decimal, is 0.33333333333333333333333333*** with an infinite number of 3s involved! 1/10, in binary, hits the exact same issue -- it simply *CAN'T* be represented properly!
And so, floating point math has rounding errors.
And the more you add, subtract, or work with those values, the more those rounding errors compound and add up over time, until they become glaringly obvious like in your code.
The fix??
In this case, I simply wouldn't use floating point values. Using LONGs instead.
total = 0
T = 0
Print Str$(total
/ 100) + " plus " + t$
+ " equals ";
total = total + T
We're working with integer values. Storing integer values. Adding and subtracting integer values. There's no floating point involved here -- UNTIL we get to the display.
Need absolute precision?
Don't work with floating point variables! ;)
