3 ms·

The other case it doesn't work is that x + 0.0 is defined to quiet an sNaN (because almost every fp operation turns sNaN to qNaN)... except even generally stric

The other case it doesn't work is that x + 0.0 is defined to quiet an sNaN (because almost every fp operation turns sNaN to qNaN)... except even generally strict floating-point models generally say "fuck you" to sNaN and treat sNaN and qNaN as interchangeable. (Speaking of fast math, my planned blog post title if I ever write all this up into a blog post is "Floating Point, or How I Learned to Start Worrying and Hate Fast Math.")

eesmith 4y ago
I deliberately added a !isnan() to my tests. There be dragons there. ;) More precisely, my test compared the bit-patterns directly: i = 0 .. 2^32-1 memcpy(&x, &i, 4); y = x + 0.0f; memcpy(&j, &y, 4) if (i != j) {printf("%f + 0.0 -> %f\n", x, y); and I'm pretty sure that NaN addition, while resulting in a NaN, does not need to preserve the original bit pattern. Regarding fast-not-so-math - Praise Kahan!
- jcranmer 4y ago
  > and I'm pretty sure that NaN addition, while resulting in a NaN, does not need to preserve the original bit pattern. "it be complicated" Except for certain operations (fneg, fcopysign, and fabs are all defined to only affect the sign bit, to the point that they're an exception to the sNaN-always-signals rule; and there are a few operations defined to operate on the NaN payload information), IEEE 754 generally says no more than a qNaN is generated. There's a recommendation that NaN payloads propagate, and most hardware does do that, but compilers actually typically don't even guarantee that sNaNs are not produced by operations.
  - eesmith 4y ago
    > There's a recommendation that NaN payloads propagate I looked more closely, and yes, the signalling NaN + 0.0 always changed the bit pattern, and the quiet NaN + 0.0 always stayed the same. Thank you for your informative details about IEEE 754.

3 ms·

The other case it doesn't work is that x + 0.0 is defined to quiet an sNaN (because almost every fp operation turns sNaN to qNaN)... except even generally stric

by jcranmer 4y ago

eesmith 4y ago
I deliberately added a !isnan() to my tests. There be dragons there. ;) More precisely, my test compared the bit-patterns directly: i = 0 .. 2^32-1 memcpy(&x, &i, 4); y = x + 0.0f; memcpy(&j, &y, 4) if (i != j) {printf("%f + 0.0 -> %f\n", x, y); and I'm pretty sure that NaN addition, while resulting in a NaN, does not need to preserve the original bit pattern. Regarding fast-not-so-math - Praise Kahan!
- jcranmer 4y ago
  > and I'm pretty sure that NaN addition, while resulting in a NaN, does not need to preserve the original bit pattern. "it be complicated" Except for certain operations (fneg, fcopysign, and fabs are all defined to only affect the sign bit, to the point that they're an exception to the sNaN-always-signals rule; and there are a few operations defined to operate on the NaN payload information), IEEE 754 generally says no more than a qNaN is generated. There's a recommendation that NaN payloads propagate, and most hardware does do that, but compilers actually typically don't even guarantee that sNaNs are not produced by operations.
  - eesmith 4y ago
    > There's a recommendation that NaN payloads propagate I looked more closely, and yes, the signalling NaN + 0.0 always changed the bit pattern, and the quiet NaN + 0.0 always stayed the same. Thank you for your informative details about IEEE 754.