A float64 comparator returns 0 whenever either score is NaN; ordering the same leaderboard twice yields different results. Why?

## What the comparator actually claims The body under suspicion is the one nearly everybody writes first: ```go func byScore(a, b float64) int { if a < b { return -1 } if a > b { return 1 } return 0 } ``` For ordinary numbers this is correct. For a pair containing a NaN it is not, because IEEE-754 says every comparison against a NaN is false: `NaN < 12.5` is false, `NaN > 12.5` is false. Both tests fail, control reaches the last line, and the function reports `0`. `0` is not a neutral answer. In a three-way comparison contract it is a positive claim: *these two elements are equal, put them in either order.* So the function is asserting that a NaN equals 12.5, that the same NaN equals 3.0, and — since it is symmetric — nothing more. Meanwhile `byScore(12.5, 3.0)` returns `+1`. Equality is now non-transitive: `a == b` and `a == c` but `b != c`. ## Why non-transitivity produces different results on the same data An ordering routine does not compare every pair. It compares a subset chosen by its own strategy — partitioning around a pivot, small-range fallbacks, merge boundaries — and the subset it chooses depends on where elements start out. When the comparator is consistent, every valid subset leads to the same final arrangement, which is why an unstable algorithm still gives one right answer for distinct keys. When the comparator contradicts itself, that guarantee is gone. A NaN compared against the pivot says "equal, leave it", so it settles wherever it was first encountered — and where it was first encountered depends on the input order. Two shuffles of the same rows therefore produce two different outputs, and the real scores around the NaN can be dragged along, so the corruption is not confined to the bad rows. What the caller sees is *phantom ties*: rows that appear interchangeable in one run and firmly ordered in the next. The cousin symptom is worse: with a genuinely inconsistent comparator, some sorting implementations can read outside the range they were given or loop, because their invariants assumed a valid ordering. Go's implementation is defensive, but nothing can rescue a comparator that disagrees with itself. ## Confirming it rather than guessing The diagnostic that settles this in one commit is a property test: 1. Build a corpus that contains the values that break comparators: at least one `math.NaN()`, a negative zero from `math.Copysign(0, -1)`, several unset zeros, and ordinary scores including duplicates. 2. Order a copy and keep the result as the reference. 3. In a loop, shuffle a fresh copy, order it, and assert the result matches the reference — comparing element by element with `cmp.Compare(x, y) == 0`, so that a NaN in the reference matches a NaN in the run. The `==` operator would report those as different and give a false failure. A fixed-input test with a hand-written expected slice cannot find this bug: it passes for the one permutation you happened to write down. Order-independence is the property that is actually violated, so it is the property the test must assert. ## The fix Delete the hand-written body and call `cmp.Compare`. It defines exactly the two cases the operators leave open — a NaN is less than every non-NaN, and a NaN equals a NaN — and it treats negative zero as equal to positive zero. That restores reflexivity and transitivity, so the ordering becomes a total order and every permutation of the same multiset produces the same result. ```go func byScore(a, b float64) int { return cmp.Compare(a, b) } ``` If the ordering has more than one key, fold the comparisons with `cmp.Or`, whose first non-zero argument wins: a `0` from the first key means "tied, consult the next". ## The part the fix does not cover `cmp.Compare` guarantees a *defined* order, not a *correct* leaderboard. NaNs will now reliably occupy the top of the list, which is still wrong for the product. So the review should ask two further questions: - **Where did the NaN come from?** Usually a division by a zero count, a parse that silently produced a NaN, or an aggregate over an empty window. Fixing that removes the value rather than ordering it. - **What is the policy at the boundary?** Filter with `math.IsNaN` when the scores are ingested, count the rejects, and log or surface them. Data quality belongs at the edge; `cmp.Compare` is the safety net that stops one bad row from making the whole result non-deterministic. And note the near-miss: unset scores that are plain `0` are perfectly orderable and will sort at the bottom of an ascending order. They are a modelling problem, not a comparator problem, and conflating the two sends the investigation to the wrong place.