Although my question is not 100% OpenGL related, I stumbled across this problem when modifying example code from NeHe’s tutorials.
Using Visual C++ 6 (SP4) I decremented a GLfloat variable (initialized with 1.0f) by 0.1f until it is 0.0f. When the variable was 0.2f and then was decremented by 0.1f, the result was 0.999999f (and not 0.1f as it should have been).
Has anyone a hint or a workaround for this? Should I round the result (how?).
When dealing with floating point numbers you should NEVER do equality tests (==). Always use <= or >= . eg. if(f_vlaue <= 0.0f)
Because floats store values in binary, any non power of 2 number representation is only an approximation, so comparing it to a precise value like 0 is bound to fail lots.
>> any non power of 2 number representation is only an approximation
What I know, this isn’t entirely correct. Consider the number 0.75f. This one is not a power of two, but it is a sum of 0.5f and 0.25f, which in turn is, all of them, a power of two. So this number CAN be represented exactly, even though it isn’t a power of two. But the number 0.1f, howerver, is an approximation. 0.1f can’t be split up in only power-of-two-components, and therefore isn’t exact. This has probably something to to with why elvin’s program “fails”. Because of roundoff errors or whatever. When it comes to comparsions, it’s always a good habit to do what Nutty says, by as often as possible comparig with a >= or <=, whatever datatype you are using.
Hmm, not sure about what that code is supposed to do/prove. Maybe it sounds strange, but can you explain in case I misunderstood the whole thing?
Note: Not trying to be rude or anything. And I do understand what you meant. Hope you understand me correct aswell.
First, when running the code, I can see that 0.75 (=3F000000), 0.5 (=3F400000) and 0.25 (=3E800000) is represented as exact numbers (and you said they couldn’t), and I get these numbers by altering the startnumber to 0.5 and 0.25 respectively, and recompile and run the program. However, when running it with 0.75 as startnumber, 0.5 and 0.25 (the theoretical values) is not exact represented. And this is becaues 0.05 isn’t representable exatly, and therfore you get roundoff errors while decrementing, and you never get an exact zero because the error gets too large.