THE STABILITY same keys, same order kept — the property two correct sorts can differ on
A sort is stable if it keeps elements with equal keys in their original relative order. It is the rare sorting property that is not pinned by the output: the spec “sort by key” leaves ties unordered, so two correct sorts of the same keys can produce different outputs — a stable one preserves input order among equals, an unstable one may scramble them. Encode items as key×256 + originalIndex (key = x >> 8): with keys [2,2,1] (indices 0,1,2) → items [512,513,258], a stable sort by key gives [258, 512, 513] — the two key-2 items keep input order — while an unstable selection sort gives [258, 513, 512], reversing them. Two correct sorts, different output: that difference is stability. It is what lets radix sort work and what keeps a spreadsheet’s prior sort intact under a new one. This dart is the batch’s keeper shot.
THE TECHNIQUE equal keys keep input order — a loose-spec property mechanisms differ on
The demo sorts items with keys [2,2,1] two ways — a stable sort keeps the key-2 items in input order, an unstable one reverses them: live demo
HISTORY & CREDIT sorting stability · the tie-order property
“A correct sort has one output.” — not when keys tie: the spec leaves ties free, so correct sorts can differ — that difference is stability. cited
the definition · equal keys keep their input order — a property of which valid ordering you pick. the freedom · “sort by key” leaves ties unpinned; two correct sorts can DIFFER on tie-order. the payoff · stability makes radix sort work (dart 506) and preserves a prior sort under a new key.
Ties kept in the order they arrived — the one sorting property the output does not force, that correct mechanisms can differ on. loose-spec
RECOMMEND FOR I-13 stable vs unstable, on the compiler
On the canonical compiler, keys [2,2,1] (encoded key×256+index): the stable sort keeps the key-2 items in order [512,513]; the unstable one reverses them to [513,512] — two correct sorts, different output:
$ i13 run or_stability.i13 # stable insertion vs unstable selection, by key
RUN OK · 534 step(s) · peak stack 6 · call depth 5
stable = [258, 512, 513] -- key-2 items keep input order (0,1)
unstable = [258, 513, 512] -- key-2 items reversed (1,0)
stable_keeps_order = 1 unstable_reverses = 1 two_correct_sorts_differ = 1
Recommend as the batch’s keeper shot — the strongest loose-spec bid since the phase channel. Stability is genuinely different: the sort spec pins the output only up to tie-order, so a stable and an unstable sort are two correct mechanisms that differ on a deterministic structural property — the exact B45/B47 shape, and the regime where the seated keepers computed-not-stored and confluence live. The honest counter for the panel: is “preserve input order among equals” a NEW axis, or (a) a tie-breaking convention — use the original index as a secondary key — which is an ordering/encoding choice (B44); or (b) do stable and unstable sorts compute different functions on tied inputs (the approximation line that gated bloom)? My lean is B44 (stability = adjoining the index as a hidden second key), but this is the realest test the sorting domain offers — to the full panel.