IEEE-754 specifies that a NaN floating-point value is not equal to itself. Which law of an equivalence relation does that break, and how do different languages' hash containers and sorting routines cope with a value that is not equal to itself?

## The law and why it matters An equivalence relation must be reflexive, symmetric and transitive. Reflexivity is the quiet one: it is what guarantees that every value falls into exactly one equality class, and therefore that the relation *partitions* the value space. Symmetry and transitivity shape the classes; reflexivity is what guarantees they exist and cover everything. IEEE-754 deliberately violates it. NaN means "there is no value here", and every ordered comparison involving it is unordered, so equal-to, less-than and greater-than are all false and not-equal is true. A consequence worth internalising: with NaN present, less-than-or-equal is no longer the negation of greater-than, so an ordering built by negating a comparison silently becomes inconsistent. The downstream damage is structural rather than cosmetic. A hash container finds a candidate slot from the hash and then *confirms* the match with the equality relation. If a value is not equal to itself, the confirmation always fails: insertion succeeds, lookup fails, deletion fails, and repeated insertion of the same value keeps adding entries. A sorted container assumes a total (or at least strict weak) order; NaN makes the order partial, and a comparison-based sort given a partial order can do considerably worse than return the wrong sequence. ## Four strategies, named **Patch the container with a second relation.** JavaScript ships three equality relations at once. Strict equality follows IEEE, so NaN is not equal to NaN. `Map` and `Set` keys, and array containment, use SameValueZero, which declares NaN equal to itself so it can serve as a key, while still treating positive and negative zero as the same key. `Object.is` is the third: NaN equal to itself, but the two zeros distinct. The programmer must know which relation each API uses; nothing in the syntax says. **Patch it in the boxed type.** Several JVM- and CLR-family languages let the primitive comparison operator follow IEEE while the boxed type's equality method declares NaN equal to NaN and orders negative zero strictly below positive zero — precisely so hashed and sorted containers see a total order. The result is a wrapper type whose equality method deliberately disagrees with its own comparison operator on exactly two inputs. **Restore reflexivity with identity.** Python's containers test identity before equality: the same NaN object is found in a list, a set or as a dict key, while an equal-valued but distinct NaN object is not. This makes membership depend on object provenance, which is reproducible but surprising: building the key twice gives two different answers. **Refuse the type.** Rust encodes the violation in the type system instead of patching containers. Floats implement PartialEq (a symmetric, transitive, *not necessarily reflexive* relation) but not Eq, and the hash-map key bound requires Eq — so `HashMap<f64, _>` does not compile. Ordering follows the same split: floats have PartialOrd but not Ord, so the default sort is unavailable and you must opt into a partial comparison or an explicit IEEE total order. The programmer is forced to state which relation they meant. **Do nothing.** Go's `==` on floats follows IEEE and its maps have no user hook. A NaN key can be inserted; every subsequent lookup and delete misses; every insert adds another unreachable entry. It is a documented way to grow a map without bound, and clearing the map is the only removal. C++ adds a further wrinkle: ordered containers require a strict weak ordering, and the built-in less-than on floats with NaN present does not provide one. Violating that requirement is undefined behaviour, not merely a wrong result. C++20 makes the distinction explicit by giving the three-way comparison on floating point the *partial ordering* category, distinct from weak and strong. ## Negative zero, the second divergence The same fault line runs through positive and negative zero, in the opposite direction. IEEE and SameValueZero say the two zeros are equal; `Object.is` and the boxed-type equality methods say they differ. So a de-duplication pass over a set of measurements can return a different cardinality depending only on which relation the container happens to use — with no NaN anywhere in the data. ## The design lesson Two philosophies, and it is worth saying which you prefer and why. Patching the container keeps floats usable everywhere at the price of a language now having several equality relations that the programmer must track per API. Refusing the type keeps exactly one relation, at the price of louder code and explicit wrapper types when you genuinely want float keys. Either way, the practical rule for production data is the same: never key a container on a raw float. Canonicalise at the boundary — an integer, a fixed-point decimal, or a string with a fixed format — and reject or normalise NaN and signed zero there, where the decision is visible.