NaNs are distinguishable. /Which/ NaN you get doesn't commute.

I guess at the bit level, but not at the level of computation? Anything that relies on bit patterns of nans behaving in a certain way (like how they propagate) is in dangerous territory.

▲

addaon 2 hours ago | parent [-]

> Anything that relies on bit patterns of nans behaving in a certain way (like how they propagate) is in dangerous territory.

Why? This is well specified by IEEE 754. Many runtimes (e.g. for Javascript) use NaN boxing. Treating floats as a semi-arbitrary selection of rational numbers plus a handful of special values is /more/ correct than treating them as real numbers, but treating them as actually specified does give more flexibility and power.

	▲	ekelsen an hour ago \| parent [-]
		Can you show me where in the ieee spec this is guaranteed? My understanding is the exact opposite - that it allows implementations to return any NaN value at all. It need not be any that were inputs. It may be that JavaScript relies on it and that has become more binding than the actual spec, but I don't think the spec actually guarantees this. Edit: actually it turns out nan-boxing does not involve arithmetic, which is why it works. I think my original point stands, if you are doing something that relies on how bit values of NaNs are propagated during arithmetic, you are on shaky ground.