Gtjkyu

Floating point equality It is common knowledge that one has to be careful when comparing floating point values. Usually, instead of using == , we use some epsilon or ULP based equality testing. == However, I wonder, are there any cases, when using == is perfectly fine? == Look at this simple snippet, which cases are guaranteed to succeed? void fn(float a, float b) { float l1 = a/b; float l2 = a/b; if (l1==l1) { } // case a) if (l1==l2) { } // case b) if (l1==a/b) { } // case c) if (l1==5.0f/3.0f) { } // case d) } int main() { fn(5.0f, 3.0f); } Note: I've checked this and this, but they don't cover (all of) my cases. Note2: It seems that I have to add some plus information, so answers can be useful in practice: I'd like to know: This is the only relevant statement I found in the current draft standard: The value representation of floating-point types is implementation-defined. [ Note: This document imposes no requirements on t...

Strange issue with floating point accuracy on ARM64 I'm running into a really strange issue with floating point accuracy on ARM64. I have a very simple piece of C++ code that looks something like this: float sx = some_float_number_1; float sy = some_float_number_2; float ex = some_float_number_3; float ey = some_float_number_4; float px = ex; float py = ey; float d1 = (ex - sx) * (py - sy); float d2 = (px - sx) * (ey - sy); float d = d1 - d2; float t = (ex - sx) * (py - sy) - (px - sx) * (ey - sy); //32-bit output: d == t == 0 //64-bit output: d == 0, t != 0 In theory, d is supposed to be equal to t and equal to 0, and that's exactly what happened on 32-bit ARM. But for some odd reason, the output of t is not equal to 0 on 64-bit ARM while d is still correct. I have never seen any bug like this, so I have no idea what could've caused this kind of problem. EDIT: Some more info EDIT2: Here's the disassembly 4c: 52933348 mov w8, #0x999a // #39322 50: 72a...