3 comments

[ 4.6 ms ] story [ 13.2 ms ] thread
So, let me get this straight.

Is this saying that, on the one hand,

> [A]s far as I can tell x86 and ARM never generate sNaNs, ...

but the CPU can still generate the other kind?

> There we go, that’s a quiet NaN.

It's proving a little hard for me to follow along. My understanding is that this is happening from a floating point number being converted to an integer, back to floating point, then back to an integer again? I think I'm wrong.

"but the CPU can still generate the other kind?"

I think the point is you can't get the silent bit turned off except by the extreme method of casting arbitrary non-float data. If you deal with floats in the normal way, they are never signalling.

"My understanding is that this is happening from a floating point number being converted to an integer, back to floating point, then back to an integer again?"

The example seems to be integer -> float. The integer is just a bit pattern that happens to mean "signalling NaN" and the author is trying to convert it to a float and unhappy with the "silent" bit/flag changing. I come back to my other comment, that the bit is not really part of the value, so I feel like the concept of equality for the test is what should be fixed.

My first reaction is that the test is wrong, if it's comparing a bit that the processor changes whenever it wants. Isn't this telling you don't do that? I'm wondering if this is a case of a leaky abstraction or just fighting the abstraction instead of going with the flow.

Conceptually, the quiet bit is not part of the value. However, I may be missing something obvious about why the writer was trying to control its value.