Why a sorting game?

How the game counts

Each garden is a row of stones with hidden whole-gram weights. One weighing reveals whether the left stone is lighter, heavier or the same. After every weighing the game computes the transitive closure of everything you know. A stone is settled when its order against every other stone is known. You win when every stone is settled.

"Tim" is the exact sequence of < comparisons that CPython's classic list.sort() performs on the same weights. For lists shorter than 64 items, that is count_run (find the first ascending or strictly descending run, reversing it if descending) followed by binary insertion of the rest. That's what Tim's code does for short lists. Merges and galloping only start at 64 items, so the Lab shows those.

Stars: ★ for sorting, ★★ for tying Python's count, ★★★ for beating it or hitting the unbeatable n−1 weighings.

What's simplified

• The game models the classic 2002 algorithm. Recent CPython versions have refined run detection (for example, how equal elements count in descending runs) and, since 3.11, use the powersort merge policy. Counts on today's Python may differ slightly on some inputs.
• Your balance gives three-way answers (lighter / equal / heavier). Python's sort only asks "less than?". This only matters in the Twins garden.
• The Lab's teaching minrun values (4, 8, 16) are smaller than Python's 32–64 so merges show up on small screens. With "Python's rule" selected, minrun is computed exactly as in CPython.
• The Lab's Timsort is a faithful JavaScript port with the 2015 merge_collapse fix: runs, binary insertion, merge_lo / merge_hi, and galloping with an adaptive min_gallop starting at 7.
• The data shapes in the Lab follow the benchmark names in listsort.txt (*sort, \sort, /sort, 3sort, +sort, %sort, ~sort, =sort) in spirit. The exact generators differ.