On Tue, Aug 18, 2009 at 11:41 PM, Ryan McConnehey
I think it is just representing it in full accuracy now where it did not used to.
Isn't 1111.10999999999 less accurate than 1111.11?
Ryan _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
1111.11 cannot be represented in base2 IEEE-754 float representation. You can represent it in a double, but not a float. If you store 1111.11 in a float is saves it as: Hex: 448AE385 Now, bit 31 is the sign, bits 30-23 are the exponent, and 22-0 are the significand, thus that means that when you convert that back without rounding, that is 1.0850683 for the significand, 1024 for the exponent, so you get 1111.1099392 exactly. Let's also look at the hex value of 1111.10999999999: Hex: 448AE385 So yes, what it is doing is perfectly correct. 1111.11 cannot possibly exist in a float, if you must have 1111.11, then use a double (which, although has a greater range, still has the same aspects of floats, still compare using epsilons, some numbers may be different yet identical, etc). Why do you think fixed-point numbers are so popular in the financial world, because using floating-point in your money programs will start to screw you over after doing a few million calculations, you could be many cents, potentially dollars off. If you want to see how floating point numbers are actually stored and why their numbers seem odd, look at the wikipedia article at http://en.wikipedia.org/wiki/Single_precision . P.S. I have no clue why it stores it as 1111.10999999999, I would think it should be 1111.1099392, but maybe it thinks that number is different or something, no clue... Regardless, 1111.11 is wrong in any case as an output number, it is fine as an input number. Float's are weird, I try not to use them if possible, tend to stick to fixed-point numbers.