Hacker News Reader

Comment by saagarjha | Hacker News Reader

> Compilers, or more specifically buggy optimization passes, assume that floating point numbers can be treated as a field – you know, associativity, distributivity, the works.

Of course, this largely depends on how "YOLO" your compiler is. I believe GCC and Clang try reasonably hard to follow IEEE 754, which ICC is much more lax.

View on HN

Compilers do no such thing: they do not assume that floating point + and * are associative, because they most definitely aren't. Roundoff errors are different, and the effect of this can be huge.

Consider (a+b)+c vs a+(b+c). Now suppose a is 1, b is 2.0^60, c is -b. The first expression evaluates to 0, the second evaluates to 1.

Scientific and engineering code is carefully designed for numerical stability and compilers must not mess this up.

gcc has a "fast math" flag you can use if you don't care about the accuracy of your results.

I don't understand your example, why would

(1 + 2.060) - 2.060 == 0

while

1 + (2.060 - 2.060) == 1?

Am I just misunderstanding what you wrote?

No, the site messed up my comment. b is supposed to be 2 raised to the 60th power. The two asterisks were removed. Let's try ^, b is 2^60, c is minus b. I edited my original comment.

There are flags for this no? At least msvc has.

Most code survives being sloppy around this, some doesn't. We had some code which relied on the propagation of infinities, so had to fiddle with some compiler options for that file to ensure the compiler wasn't being too clever.

Yeah, this is exactly the sort of thing I'd expect to get if I use the "fun, safe math optimizations" flag.

https://gcc.gnu.org/wiki/FloatingPointMath

Reply on news.ycombinator.com