SPACE: reshuffle and race again A: switch between the six-way race and a single full-screen algorithm 1-6: bubble / insertion / selection / quicksort / merge / heap, full screen Up / Down: array size (12-96) Left / Right: playback speed, in operations per frame Bar colour tracks value, so a sorted array is a clean spectrum sweep. White bars are the read/write head - whatever the algorithm touched most recently. C counts comparisons, M counts moves.
Six sorting algorithms racing the same shuffled array, with comparison and move counters per lane. RECORD, THEN REPLAY. Each algorithm runs to completion inside a `func` and emits a trace of compare/swap/write operations. Playback then hands every lane the same ops-per-frame budget. That is what makes the race fair: if the algorithms ran live they would each be throttled by whatever Scratch's scheduler gave them that frame, and you would be watching a scheduling artefact rather than an algorithmic difference. Decoupling the two means a lane's speed is exactly its operation count and nothing else. NO RECURSION ANYWHERE. goboscript's `local` is undefined behaviour inside recursive procedures, so quicksort uses an explicit partition stack, merge sort is bottom-up, and heap sift-down is iterative. All three are the standard iterative formulations, not hacks. COUNTING MOVES FAIRLY: a swap is one move and a single write is also one move. That is the only honest way to score merge sort, which never swaps at all - it only writes. Counting swaps alone would show merge sort doing zero work. Verified against textbook figures: bubble and selection each perform exactly n(n-1)/2 = 1128 comparisons at n=48; quicksort 265 on the same input. All six confirmed to produce correctly sorted output. HONEST: at the maximum array size of 96, generating the traces is around 20,000 operations and 60,000 list appends, which is a visible sub-second hitch when you reshuffle. All original - code, art and sound. See Inside is open.
