Facebook
Google
GitHub
Linkedin
Greg,
Now you see why the code sample I provided did what it did. cout rounded the value of sum when it displayed it. (BTW, the precision for a float is a bit more -- 5 or 6 places after the decimal point, IIRC.)
Something else that's interesting (at least to me) is that the imprecision you saw in the loop doesn't always occur.
If we changed the code like so:
this time we would get output that indicates "right answer".
If the two examples I've provided seem to produce unpredictable results, it's because of how floating point numbers are stored internally. Some floating point numbers have exact representations, but for some, the representations are only approximate. It's similar to the way that some fractions, such as 1/10, have decimal fraction representations that are short and sweet (0.1), while others have representations that go on endlessly (1/9 = 0.1111111111111111.....). The only thing different is that computer representations of floating point numbers are binary-based, rather than decimal-based. A base-2 representation of 1/2 would be .1 --1 * 2 ^(-1)-- while a base-2 representation of 1/4 would be .01 -- 0 * 2 ^(-1) + 1 * 2 ^(-2). Unfortunately for us humans with 10 fingers, fractions such as 1/10 have infinitely long binary representations. Since computers can't deal with infinitely long strings of digits, they truncate all but a few and call that good.
The loop in the original example I provided exploited the fact that 0.1 + 0.1 + ... + 0.1 (ten of them) isn't exactly equal to 1.0.
Mark
Now you see why the code sample I provided did what it did. cout rounded the value of sum when it displayed it. (BTW, the precision for a float is a bit more -- 5 or 6 places after the decimal point, IIRC.)
Something else that's interesting (at least to me) is that the imprecision you saw in the loop doesn't always occur.
If we changed the code like so:
Rich (BB code):
float x = 0.125; // or 1/8
for (i = 0; i < 8; i++)
sum = sum + x;
if (sum == 1.0) cout<< "right answer";
else cout<< "huh?";If the two examples I've provided seem to produce unpredictable results, it's because of how floating point numbers are stored internally. Some floating point numbers have exact representations, but for some, the representations are only approximate. It's similar to the way that some fractions, such as 1/10, have decimal fraction representations that are short and sweet (0.1), while others have representations that go on endlessly (1/9 = 0.1111111111111111.....). The only thing different is that computer representations of floating point numbers are binary-based, rather than decimal-based. A base-2 representation of 1/2 would be .1 --1 * 2 ^(-1)-- while a base-2 representation of 1/4 would be .01 -- 0 * 2 ^(-1) + 1 * 2 ^(-2). Unfortunately for us humans with 10 fingers, fractions such as 1/10 have infinitely long binary representations. Since computers can't deal with infinitely long strings of digits, they truncate all but a few and call that good.
The loop in the original example I provided exploited the fact that 0.1 + 0.1 + ... + 0.1 (ten of them) isn't exactly equal to 1.0.
Mark
