Ilja, Paul, Degski, Thanks for your help. I think that Ilja's comment below explains what's going on: compilers don't strictly respect IEEE floating point when they have optimizations turned on (see also the explanation here: https://stackoverflow.com/questions/7517588/different-floating-point-result-...). @Degski: I am not actually interested in fractions. The background is that I am using the interval library to compare the numerical accuracy of various statistical algorithms in a setting where we know that some of the methods will run out of precision for large data sets, and I am getting incorrect intervals (that do not contain the correct answer) when compiling with clang, but everything works when compiling with gcc. When trying to debug this I found that the numerical results diverged right from the first interval calculations and I could not understand why. I think I have a better handle on this now. Best, Tim On 08/03/2018 09:49, Ilja Honkonen wrote:
Hello
My (somewhat naive) view of compilers is that they can only do optimization that has no visible effects on the behavior of the program.
I wouldn't be surprised if ieee floating point is an exception to that, especially with optimizations enabled.
What I meant is: double v1 = 1.0/3.0; printf("%f", v1); double computation = v1 * 3; Then the print statement will show the user some value for v1 that fits in a double. So I would expect that it is then no longer free to treat v1 as exactly 1/3, because the use has already observed a different value.
I think in order to show the number to the user it would have to be copied to memory or at least a regular register but further computation could continue to use the more accurate floating point register. And the compiler might still optimize the computation away and just show you the result of printf(..., 1.0/3.0). I don't know if writing constexpr double v1 = 1.0/3.0 would change anything, at least if particular optimizations are enabled and/or disabled.
Ilja
--
Tim van Erven