
In which the CPU changes my data under my nose - nonsince
http://troubles.md/posts/i-triple-equals/
======
perl4ever
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.

------
exikyut
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.

~~~
perl4ever
"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.

