Logical error performed by the Optimization of double to float conversion. about emscripten-fastcomp HOT 6 CLOSED

You can use four backticks to properly escape multiline code like that.

I assume the issue is that sometimes optimizations end up avoiding a store to memory. When stored to f32, rounding occurs, but when still in a variable, it doesn't. Yes, this can be surprising.

The only real solution is to enable PRECISE_F32, which as you mention works. Disabling llvm opts on the specific file you see the issue on can also be a workaround. But if your code is this sensitive to floating point values, I think enabling PRECISE_F32 is the best solution by far. It should be quite fast in modern browsers, but not always in older ones.

from emscripten-fastcomp.

Thank you for the fast answer.

My solution for now will be to enable PRECISE_F32 and disable it only where performances will be potentially an issue.

from emscripten-fastcomp.

You can find more about this behavior in floating point and the nonguarantees there from http://gcc.gnu.org/wiki/x87note , which discusses the same behavior in native x87 fpu. Instead of 80bit vs 32/64bit issue in native, in Emscripten when compiling without PRECISE_F32, the "cpu register" contains a 64bit float, and the memory contains a 32bit float. That behavior is valid by the IEEE floating point spec, although it is extremely unintuitive and difficult to reason about. A good rule of thumb to avoid these issues is to follow these rules:

• comparing floats for equality or inequality with == or != is undefined, except in the special case where the float was first explicitly assigned a small integer literal value (float f = 0;), and the comparison is afterwards done against that same literal value (if (f == 0)) without having done any computation on it in between.
• any two sequences of operations (float <-> double cast being an operation as well) that are mathematically the same, but where the operations are permuted or reordered, will not be guaranteed to give the same result. This means that the commutativity, associativity and transitivity rules don't apply.
• when comparing floats that are a result of computation instead of direct assignment of a small integer value, always compare against an epsilon threshold.

It seems that these rules, although being quite on the strict side of assumptions, avoid the float issues in practice.

from emscripten-fastcomp.

Perhaps we should add this (or a link to this) to the FAQ?

from emscripten-fastcomp.

I agree that this would be very useful to have in a FAQ.

from emscripten-fastcomp.

Yeah agreed. I'll write a note about this, since this does seem to come up quite often.

from emscripten-fastcomp.