Hi all, I was reading the C++ FAQ at http://www.parashift.com/c++-faq-lite/ when I encountered an interesting curiosity in the "newbie questions" section. The FAQ warns against directly comparing floating point numbers and, in section 29.18, gives an example of code (see below) that produces behavior that seems unnatural to many (most?) programmers. (Below code copied from http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.18) #include <cmath> void foo(double x, double y) { if (cos(x) != cos(y)) { std::cout << "Huh?!?\n"; ← you might end up here when x == y!! } } int main() { foo(1.0, 1.0); return 0; } Basically, the reason given in the FAQ is that the result of cos(x) (intermediate, higher precision value) will be stored in a register and thus truncated. Then the result of cos(y) is directly compared with the truncated value located in a register, resulting in this strange (?) behavior. Now, my question is, why isn't gcc able to tell that it is about to compare two floating point numbers, one of which has been truncated, and then similarly truncate the second value before the comparison? (In fact, since the return type of cos() is double, shouldn't the intermediate value be truncated to fit a double in any case?) Second (this question might be even more naive than the previous one), if you are never, ever, supposed to compare floating point numbers using ==; if you are always supposed to check the difference of the numbers against an epsilon value; then how come the compiler can't automatically do this? Is it because analyzing the source code to track the accumulated floating point errors (to appropriately adjust epsilon) might be prohibitively difficult/slow? Or are there actually any situations where you'd want to compare two floating point numbers directly with each other? Thanks for taking the time to answer my "newbie questions" :) /Erik -- View this message in context: http://www.nabble.com/Floating-point-behavior-tp19304865p19304865.html Sent from the gcc - Help mailing list archive at Nabble.com.
