Renovating the SuperSorter

Confirming the diagnosis: what shellSort() does.

The existing code (lines 346–369 of sorterSketchOriginal.js):

function shellSort(){
    var done;
    if(jump > 1){
        jump /= 2;
        jump = Math.floor(jump);
        do{
            done = true;
            for(var m = 0; m < n-jump; m++){
                var j = m + jump;
                if (a < b) {            // a = arr[m].y, b = arr[j].y
                    swap(arr, m, j);    // ← adjacent swap, not insertion shift
                    done = false;
                }
            }
        }while(!done);    // ← loops until no swap found at this gap
    }else{
        wrapUpSort();
    }
}

This is unambiguously a Shell-Bubble Hybrid:

My perspective as an educator: keep both.
Replacing the hybrid with canonical Shell Sort would be technically correct but pedagogically inferior. Here is why:

The hybrid is not a mistake — it is the natural first attempt. If I asked a student to design Shell Sort after explaining only the gap idea, most would independently arrive at exactly this code: “I’ll use Shell’s gap sequence, and I’ll use Bubble Sort as the inner loop because I already know Bubble Sort.” That is rational. The question “but why doesn’t Shell Sort actually do that?” is one of the most instructive questions in the algorithm curriculum. Keeping the hybrid gives students something to compare, not just something to remember.

My perspective as a developer: keep both.
No working code is deleted. The hybrid’s function, dropdown entry, and test cases all remain. Adding canonical Shell Sort as option 11 is a small additive change: one new function (~14 lines), one new <option>, and two dispatch lines. The risk is near zero. The cost of doing it the other way — replacing the hybrid — would mean silently discarding a working algorithm and providing no way to run the comparison the markdown document recommends.

On the naming. “Shell Hybrid” is the right call. It is honest (not the standard algorithm), respectful (acknowledges its correctness and lineage), and informative (signals what it borrows). An alternative “Shell-Bubble” makes the two components maximally explicit, which is useful in a written explanation but awkward as a dropdown label. Use “Shell Hybrid” in the UI and the fuller description in the modal and chatlog.

Changes in scripts/superSorterSketch.js:

1. Added shellSortCanonical() immediately after shellSort(). Same gap halving as the hybrid; inner mechanism replaced with a single insertion-sort forward pass using element shifts. Local variables renamed si/sj to avoid collision with the outer scope’s i/j.
2. Updated dispatch in draw(): added if(sTechnique == 11) shellSortCanonical(); after the Bogo Sort block.
3. Updated getReadyToSort(): changed if(sTechnique == 6) to if(sTechnique == 6 || sTechnique == 11) so that canonical Shell Sort also unlocks the jumbo dot-count maximum.

The new function in full:

function shellSortCanonical() {
    if (jump > 1) {
        jump = Math.floor(jump / 2);
        // ONE insertion-sort forward pass at the current gap
        for (let si = jump; si < n; si++) {
            let key  = myDotField.arr[si];
            let keyY = key.posn.y;
            let sj   = si - jump;
            // shift smaller-y elements rightward (descending sort)
            while (sj >= 0 && myDotField.arr[sj].posn.y < keyY) {
                myDotField.arr[sj + jump] = myDotField.arr[sj];
                sj -= jump;
            }
            myDotField.arr[sj + jump] = key;
        }
    } else {
        wrapUpSort();
    }
    iInSrt++;
}

Changes in superSorterHome.html:

• Dropdown option 6: "Shell" → "Shell Hybrid"
• Dropdown option 11 added: "Shell Sort" (after Bogo Sort)
• Modal body: Shell description split into two entries — Shell Hybrid (explains the hybrid nature) and Shell Sort (canonical algorithm, with the “compare elapsed times at large n” prompt)
• Dot count description updated to name both Shell variants

Note on sorterSketchOriginal.js:

The directory contains a second sketch file, scripts/sorterSketchOriginal.js, which is a preserved copy. The HTML loads only scripts/superSorterSketch.js. The changes above were applied to the loaded file. See Session 2a below for the full account of how the two-file situation was discovered.

The algorithm count is now 11. The sorting curriculum the app teaches has been enriched in two ways: a mislabelled algorithm is now named correctly, and a correctly-implemented canonical algorithm exists for direct comparison. The app’s elapsed-time display means the comparison is immediately quantitative.

Recommended student experiment: Set dots to 2,000. Run Shell Hybrid. Note the elapsed time. Reload. Run Shell Sort. The canonical version should finish in fewer milliseconds because it makes far fewer comparisons at the large gap levels. If the time difference is not dramatic at 2,000, try 4,000. The gap grows with n.

Queued for future sessions:

Correct — and the error was mine. The HTML’s script tags are:

<script src="scripts/Dot.js"></script>
<script src="scripts/DotField.js"></script>
<script src="scripts/superSorterSketch.js"></script>

The app loads superSorterSketch.js. I applied all of Session 2’s changes to sorterSketchOriginal.js instead — a file that exists in the same directory but is not referenced by the HTML. The result was that the dropdown said “Shell Hybrid” and offered “Shell Sort” as option 11, but the running app had neither: it was still executing the unchanged original shellSort() for both options (and option 11 would have silently done nothing).

After the user’s question, the correct file was identified and the same three changes were applied to superSorterSketch.js: shellSortCanonical() added, dispatch updated for option 11, getReadyToSort() updated to treat option 11 the same as option 6 (jumbo dot-count range). The app now works as described.

The root cause: two files with similar names and nearly identical content exist in the same directory (scripts/sorterSketchOriginal.js and scripts/superSorterSketch.js). Without verifying which one the HTML actually loads, it is easy to edit the wrong one.

What the errors were.

All four were the same mistake in two different <pre> code blocks: raw < characters used as comparison operators in JavaScript code listings:

Why this happens. In HTML, the < character has a fixed meaning: it signals the start of a tag. This is true everywhere in the document — inside paragraphs, inside <pre> blocks, even inside <textarea> elements. The browser’s HTML parser sees < and begins looking for a tag name. When the character that follows is not a valid tag start (like a space, a digit, or in this case a letter that doesn’t match a known tag), the validator flags it as a parse error.

The fix. Escape any < that should be displayed as a literal less-than sign using the HTML entity <. The browser renders < as the visible character < in the page, so the listing looks correct to a reader. The fix is one change per occurrence.

The third <pre> block in this file (the one showing the HTML <script> tags in Session 2a) was already correct because it was written with < and > from the start.

The breadcrumb trail is not alarming — the sort completed correctly. The gap between sortMe and wrapUpSort #11 held 9 silent draw frames (gap sequence: 150 → 75 → 37 → 18 → 9 → 4 → 2 → 1 → done for n=300). No console output between them because shellSortCanonical() has no log statements inside the loop. Those 9 frames at 60 fps take about 150ms — fast enough to look instant. The sort was correct; it was just invisible.

The real bug: I moved dot objects. I should only move y-values.

The root cause required reading the swap() function to find:

function swap(arr, a, b) {
    let tempY = arr[a].posn.y;
    arr[a].posn.y = arr[b].posn.y;  // ← only posn.y is touched
    arr[b].posn.y = tempY;
}

swap() only exchanges .posn.y values — it never moves Dot objects between array positions. Every algorithm in this app follows the same rule:

Why moving objects broke everything. Each Dot stores its own posn.x. The x-position on the canvas is drawn directly from dot.posn.x — it is NOT computed from the dot’s array index. When I moved Dot objects around in the array, each dot carried its posn.x with it. The visual x-positions of all dots appeared unchanged (each dot was still drawn at its own stored x), but the array now had objects at wrong indices. When resetHeights() restored y-values, it assigned each position its original random y — but to the wrong object, the one that had been shuffled there. Subsequent sorts got correct y-values to compare but drew their circles at permanently scrambled x-positions. The diagonal line could never form again.

The fix: three changed lines. Save and shift .posn.y values only, never object references:

// BROKEN (moves objects):
let key = myDotField.arr[si];          // saves object reference
...
myDotField.arr[sj + jump] = myDotField.arr[sj];   // copies object reference
myDotField.arr[sj + jump] = key;       // places object

// FIXED (moves y-values only):
let keyY = myDotField.arr[si].posn.y;  // saves y-value only
...
myDotField.arr[sj + jump].posn.y = myDotField.arr[sj].posn.y;  // copies y-value
myDotField.arr[sj + jump].posn.y = keyY;  // places y-value

The corrected function is algorithmically identical to the broken one — same gap sequence, same one-pass-per-gap rule. The only change is that the “element” being shifted is now a number (posn.y), not a Dot object reference.

Does it surprise me? Not at all — and here is the precise reason.

Both algorithms use Shell’s n÷2 gap sequence. That means both run through the same number of gap levels: log⊂2;(n) + 1 frames. For n=300, that is 9 frames; for n=2,000, it is 11 frames. The number of animation steps you see is identical for both algorithms regardless of n.

The difference is in how much work happens per frame, not in the frame count. And for random data, the extra work the hybrid does is small:

On random data, the hybrid’s extra passes at large gaps are brief — pairs separated by 150 positions are rarely out of order by much, so the bubble inner loop converges in 1–2 passes. The difference in total comparisons between the two algorithms is small and runs in sub-millisecond time at n=300 or even n=2,000. The timer shows whole milliseconds; the difference is invisible.

What data would show a measurable difference? Two factors must combine: large n and pathological input.

Why reversed data is the key. Consider gap = n/2 = 5,000 on reversed data (n=10,000). Every pair of elements that are 5,000 apart in a reversed array is maximally out of order: the element on the left should be on the right, and vice versa. The hybrid’s bubble inner loop sees a swap on almost every comparison and must run many passes before it settles. The canonical makes one insertion-sort pass and moves on — it does not guarantee that gap level is fully settled, it just trusts that future passes will clean up what remains.

The deeper lesson. The algorithmic difference between Shell Hybrid and Shell Sort is real, but it belongs to a class of differences that only become measurable at scale or with adversarial input. This is common in algorithm education: the textbook says “O(n log n) is faster than O(n²)” but on 20 elements the O(n²) algorithm finishes in 2 microseconds and the O(n log n) one in 4 — and a student concludes the theory is wrong. It is not wrong; the scale is just too small for the asymptotic difference to dominate the constant factors. SuperSorter at 50,000 dots on reversed data is where the theory becomes visible.

Three files updated to move Shell Sort from option 11 to option 7:

The jumbo dot-count maximum (50,000 dots unlocked) now applies to options 6 and 7. Bogo Sort’s 8-dot cap moved from option 10 to option 11. The dispatch table in draw() and the getReadyToSort() slider logic were both updated. The modal description list already had Shell Sort adjacent to Shell Hybrid (it was placed there in Session 2), so no modal reordering was needed.

The short answer: no — and the reason is interesting.

Comb Sort and Shell Hybrid share the same inner mechanism (bubble swaps) but differ on both the gap sequence AND the passes-per-gap strategy. To see this clearly, it helps to put all four gap-based algorithms in a two-axis grid:

Shell Hybrid and Comb Sort are in different columns (different gap sequences) AND they also differ on passes-per-gap:

The key surprise: Comb Sort’s passes-per-gap strategy is actually identical to canonical Shell Sort’s — both do exactly one pass per gap level (except at gap=1 for Comb Sort). In that sense, Comb Sort is more like Shell Sort than like Shell Hybrid. The difference between Comb Sort and Shell Sort is just the inner mechanism (swaps vs. shifts) and the gap sequence (n÷1.3 vs. n÷2).

What does Comb Sort actually fix?
Comb Sort was designed specifically to address Bubble Sort’s “turtle” problem: a small value near the right end of the array can only move leftward by one position per pass. A value that belongs at position 0 but starts at position n−1 requires n−1 passes to reach its destination. Comb Sort’s large initial gap catches these turtles on the first pass — a single comparison can move a turtle from position n−1 to position 0 immediately if the gap equals n−1. Shell Sort addresses the same problem but with a different gap and a different inner mechanism.

Does this mean Comb Sort belongs in the curriculum?
It depends on what you want to teach. The honest assessment is:

• If the goal is to demonstrate gap strategies: Comb Sort adds the n÷1.3 gap to the collection. Comparing Shell Hybrid (n÷2, repeat) vs. Comb Sort (n÷1.3, one-pass) isolates the effect of the gap sequence alone, since the inner mechanism is the same (bubble swaps) but the pass strategy differs.
• If the goal is to keep the collection lean: Shell Hybrid and Shell Sort already cover the one-pass vs. repeat-until-settled contrast. The n÷1.3 gap is a footnote. Skipping Comb Sort is a reasonable curriculum decision.
• If the next algorithm is Timsort: Timsort is a qualitatively different kind of algorithm — it detects natural runs, adapts to existing order, and is the algorithm that Python and Java actually use. That is a far more interesting teaching target than adding a third gap-based sort.

Recommendation: skip Comb Sort and build Timsort instead. Not because Comb Sort is the same as Shell Hybrid (it is not), but because Timsort occupies a different corner of algorithm space entirely — one that is genuinely surprising and directly relevant to every programmer who has ever used Python or Java. That is a better use of menu space.

New menu (13 algorithms + Bogo):

Comb Sort implementation (combSort()):

One function, straightforward. Comb Sort state is cmbGap (initialized to n in resetSort(), reduced by ÷1.3 on each call) and cmbSorted (true if a full pass found no swaps, done signal when cmbGap === 1). Uses swap() which correctly exchanges only .posn.y values.

Timsort implementation (timsort()):

Two-phase state machine.

• Phase 1 — one chunk per frame: timChunkStart advances by timMinRun each frame. Each frame insertion-sorts one arr[timChunkStart .. timChunkStart + minRun - 1] chunk. Uses y-value shifts (never moves dot objects). After all chunks are sorted, sets timPhase = 2.
• Phase 2 — one merge round per frame: identical logic to the existing mergeSort() via mergeHalves(), but starting at timMergeWidth = timMinRun instead of 1. Produces log⊂2;(n / minRun) merge frames — fewer than Merge Sort’s log⊂2;(n).

computeTimMinRun(n) uses Python’s exact formula. For n=300, minRun = 38; for n=2,000, minRun ≈ 63. Phase 1 produces floor(n/minRun) frames; Phase 2 produces ceil(log⊂2;(n/minRun)) frames.

What the visualization shows distinctively: After Phase 1, the canvas shows a series of identical-width sorted diagonal stripes. This visual is unique among all 13 algorithms — it makes “divide into runs, then merge” visually self-evident before Phase 2 begins. No other algorithm in the collection produces this specific intermediate state.

Honest answer: it was an oversight, not a decision.

The dot-count slider has three tiers:

When Comb Sort (11) and Timsort (12) were added in Session 5, they were not explicitly added to the jumbo condition — they fell into the else branch by default and got the 5,000 cap. The fix is changing one condition line:

// Was (Shell Hybrid and Shell Sort only):
if(sTechnique == 6 || sTechnique == 7)

// Now (all four scalable O(n log n) algorithms):
if(sTechnique == 6 || sTechnique == 7 || sTechnique == 11 || sTechnique == 12)

Should Timsort have jumbo max? Yes — and there is an interesting wrinkle.

Timsort’s Phase 1 (chunk insertion sort) produces n ÷ minRun frames — roughly linear in n. At n=50,000, minRun ≈ 49, so Phase 1 = ≈ 1,020 frames. At 60 fps that is about 17 seconds of animation just for Phase 1.

Compare with Merge Sort at n=50,000: log⊂2;(50,000) ≈ 16 frames. Phase 2 of Timsort is also only about 10 frames.

This creates a pedagogically interesting situation: the animation appears to run for a long time (1,020+ frames), but each Phase 1 frame only sorts 49 elements — very little work per frame. The elapsed timer will likely show a shorter total time than Merge Sort’s 16 longer frames. Frame count is not algorithmic complexity. This is actually an excellent teaching demonstration at large n: run Timsort vs. Merge Sort at 20,000+ dots and compare elapsed times against frame counts.

Question 1: Why does it sit there and then instantly sort?

This is the Session 6 prediction landing in practice. Timsort has two visually very different phases:

At n=50,000, Phase 1 sorts 49 dots per frame out of 50,000 — 0.1% of the canvas. Even at 60 fps the eye cannot detect that change. The canvas looks frozen while ≈ 1,020 invisible frames execute. Then Phase 2 fires in ≈ 10 frames, each of which merges the entire array in one sweep. The sort appears to happen instantly because each Phase 2 frame changes the whole canvas.

This is a fundamental tension in visualizing Timsort: the algorithm’s insight is that Phase 1 is supposed to be cheap (fast, lightweight). In the real-world Timsort, Phase 1 detects natural runs that already exist, so it may do almost no work at all on partially-sorted data. In our implementation, Phase 1 insertion-sorts fixed-size chunks, which is more visible work. But the visualization model (one small chunk per frame) still renders it invisible at large n.

A future enhancement could highlight the current chunk being worked on (a different color stripe on the active chunk), making Phase 1 visible even at large n. For now, the behavior is expected — not a bug.

Question 2: Is Timsort recursive?

No — and neither is the Merge Sort already in SuperSorter.

The textbook presentation of Merge Sort is recursive:

function mergeSort(arr, left, right) {
    if (left < right) {
        let mid = Math.floor((left + right) / 2);
        mergeSort(arr, left, mid);         // ← recurse left
        mergeSort(arr, mid + 1, right);    // ← recurse right
        merge(arr, left, mid, right);      // ← combine
    }
}

This calls itself. For n=1,000, the call stack goes 10 levels deep (log⊂2;(1000) ≈ 10). For large n it can overflow the stack; for visualizations it fires all the work in one synchronous call, making animation impossible.

SuperSorter’s Merge Sort is iterative (bottom-up): start with sub-arrays of width 1, merge adjacent pairs, double the width, repeat. One complete pass per animation frame. No recursion, no call stack depth issue.

This implementation’s Timsort is also iterative: Phase 1 advances a timChunkStart index forward by timMinRun each frame. Phase 2 uses the exact same bottom-up merge logic as mergeSort(), starting at timMergeWidth = timMinRun instead of 1. No function calls itself at any point.

What about the real CPython Timsort? Also iterative. It uses an explicit stack of pending merge runs and applies merge policies (guaranteeing certain invariants about run-size ratios) to decide when to merge adjacent runs. The phrase “related to Merge Sort” is accurate — it uses a merge operation as its core primitive — but the outer structure is a while loop over a run stack, not a recursive function.

The recursion–iteration distinction matters practically: iterative Merge Sort and Timsort can handle arbitrarily large n without stack overflow; recursive Merge Sort cannot. For a JavaScript visualization running in the browser, this is not a hypothetical concern — deep recursion on large arrays is a real failure mode.

MergeSort: confirmed iterative. Reading the code directly, mergeSort() (line 482) uses a while loop over merge windows and never calls itself:

function mergeSort() {
    if (msWidth >= n) { wrapUpSort(); return; }

    while (msLeft < n - 1) {          // ← loop, not recursion
        mergeHalves(arr, msLeft, mid, right);
        msLeft += 2 * msWidth;
    }
    msWidth *= 2;   // double width for next frame
    msLeft = 0;
}

mergeHalves() is a helper that merges one window — it also does not call itself. 100% iterative.

QuickSort: the file already contains both the recursive attempt AND its replacement. There are two QuickSort implementations in superSorterSketch.js:

The original recursive attempt:

async function quickSort(arr, start, end) {
    let ndx = await partition(arr, start, end);
    await Promise.all([
        quickSort(arr, start, ndx - 1),   // ← recurses left
        quickSort(arr, ndx + 1, end)       // ← recurses right
    ]);
}

The comment already in the file explains exactly what went wrong (“all recursive calls fire and resolve in the same microtask batch before the next draw() frame”). Promise.all schedules both branches as microtasks, which JavaScript resolves before returning control to the browser’s rendering pipeline. The entire sort fires in one invisible burst; the animation never sees it.

The replacement, improvedQuickSort(), uses an explicit iqsStack array as a manual call stack: each draw() frame pops one {start, end} segment, partitions it, and pushes the two sub-problems back. When the stack empties the sort is done. Structurally recursive behavior, iteratively controlled.

There IS a way to demo recursive algorithms in p5.js — JavaScript generator functions.

async/await was the wrong tool. The right tool is a function* (generator) with yield. A generator is a function that can pause in the middle of its own execution and hand control back to the caller. That is exactly what a frame-by-frame animation needs:

// Recursive QuickSort as a generator — each yield = one animation frame
function* quickSortGen(arr, lo, hi) {
    if (lo >= hi) return;

    let pivot = partition(arr, lo, hi);   // partition this segment
    yield;                                // ← PAUSE here; draw() renders this frame

    yield* quickSortGen(arr, lo, pivot - 1);    // ← recurse left (also pauseable)
    yield* quickSortGen(arr, pivot + 1, hi);    // ← recurse right (also pauseable)
}

yield* delegates to another generator, preserving the recursive call structure. The caller (p5’s draw() loop) drives it with .next() once per frame:

// In setup(): initialise the generator
let gen = quickSortGen(myDotField.arr, 0, n - 1);

// In draw():
let result = gen.next();
if (result.done) wrapUpSort();

The generator IS structurally recursive — the call tree is the same as the textbook recursive QuickSort — but it pauses at each yield and resumes on the next draw() frame. The browser renders between each .next() call, so the animation is fully visible. This is the modern, correct solution for animating divide-and-conquer algorithms in p5.js.

Three new functions, one powerful comparison:

1. quickSortGenPartition(lo, hi) — The synchronous partition used by the generator. Identical logic to improvedPartition() — middle-element pivot, Lomuto scheme, descending y-order — but a plain function with no async, no await. It can be called directly from inside a generator without triggering microtask scheduling.

2. quickSortGenerator(lo, hi) — The generator function. Structure:

function* quickSortGenerator(lo, hi) {
    if (lo >= hi) return;                       // base case

    let pivotIdx = quickSortGenPartition(lo, hi); // partition
    yield;                                      // ← pause; draw() renders

    yield* quickSortGenerator(lo, pivotIdx - 1); // recurse left
    yield* quickSortGenerator(pivotIdx + 1, hi); // recurse right
}

This IS structurally recursive. The JavaScript call tree holds one frame of quickSortGenerator per recursion level. For n=300, that is about 9 suspended generator frames deep. Each one holds its own lo, hi, and pivotIdx on its own private execution stack.

3. quickSortRecursive() — The one-line driver called by draw() each frame: quickSortGen.next(). When result.done is true, the generator is exhausted and wrapUpSort() fires.

The DevTools demonstration. While QuickSort (Recursive) is running, open DevTools > Sources and pause on any frame. The call stack will show:

draw                              ← p5.js frame loop
quickSortRecursive                ← driver
quickSortGen.next (anonymous)     ← advancing the root generator
quickSortGenerator (generator)    ← root call: lo=0, hi=299
quickSortGenerator (generator)    ← left sub-call
quickSortGenerator (generator)    ← deeper left sub-call
...

That call stack IS the recursion tree, frozen mid-execution. QuickSort (Stack) at the same moment would show only: draw → improvedQuickSort and a flat array iqsStack in local variables. Same algorithm, completely different internal structure.

Yes — and the visual difference is the real teaching value.

Both Merge Sort (Bottom-Up) and Merge Sort (Recursive) sort the same data to the same result using the same mergeHalves() helper. The difference is visible:

The generator implementation:

function* mergeSortGenerator(lo, hi) {
    if (lo >= hi) return;                  // base case

    let mid = Math.floor((lo + hi) / 2);

    yield* mergeSortGenerator(lo, mid);    // sort left half (all frames)
    yield* mergeSortGenerator(mid+1, hi);  // sort right half (all frames)

    mergeHalves(myDotField.arr, lo, mid, hi); // merge
    yield;                                 // ← show merged result
}

The pseudocode every CS class writes on the whiteboard, translated almost verbatim into working animated JavaScript. mergeHalves() is reused from the iterative version — it was already correct, already handles y-values only, and handles the descending sort order. Nothing needed to change.

On the yield placement: yield appears AFTER the merge, not before. This means students see the result of each merge. An alternative (yield before AND after) would show the two sorted sub-arrays just before they merge, then the merged result — two frames per merge, more explicit but twice as many steps. Either choice is defensible; post-merge is cleaner for large n.

Complete algorithm inventory after Session 10:

SuperSorter now contains two algorithm pairs that demonstrate the same sort in iterative and recursive form: options 9/10 for Merge Sort and options 11/12 for QuickSort. Run them back-to-back on the same data at n=200–400 to observe both the structural difference in the code and the visual difference in the animation. The call stack in DevTools during options 10 and 12 will show live recursion; options 9 and 11 will show flat iterative state.

The theory is almost right — here is the precise refinement.

The p5.js draw loop is NOT slow. And the recursion is NOT running while the draw loop is running — the generator pauses the recursion completely at each yield. The frame renders, the browser is idle, then the next frame fires and the generator resumes. There is no conflict, no competition, no complication.

The real culprit is simpler and more fundamental: every animation frame costs exactly 1/60 of a second, regardless of how much algorithmic work happened in it.

Each algorithm in SuperSorter defines “one step” as one call from draw(). But one step means very different amounts of work:

Shell Sort looks fast because it does O(n) work per frame. It finishes in 9 frames. QuickSort looks slow because it does O(n/depth) work per frame and needs ~300 frames. At 60 fps, 9 frames = 0.15 seconds; 300 frames = 5 seconds. The TOTAL WORK is comparable — both are O(n log n). The WALL-CLOCK ANIMATION TIME reflects the frame count, not the total computation.

The Java applet comparison is exactly right. In a Java applet (or any native implementation without a frame cap), QuickSort ran without throttling. Its true advantages — small constant factors, excellent CPU cache performance due to sequential memory access in the partition step — made it genuinely faster than Shell Sort in wall-clock time. QuickSort is fast. SuperSorter’s animation model just happens to penalise fine-grained algorithms by giving them the same 1/60 second per step as coarse-grained ones.

The elapsed timer is also misleading at small n. For n=300, the timer shows Shell Sort ≈ 150ms and QuickSort ≈ 5,000ms. Both do about the same number of comparisons in microseconds. The timer is measuring frame overhead (canvas render time × frame count), not algorithmic computation time. At large n (where computation per frame starts to dominate the 16ms frame budget), the timer becomes more meaningful — but the frame-count difference still dominates.

Recursive vs. Bottom-Up Merge Sort: exactly the same phenomenon. Bottom-Up does all merges at the current width in ONE frame (O(n) work). Recursive does ONE merge per frame. Same total computation; 9 frames vs. 299 frames. The only difference is how much work gets batched into each frame.

The interpretation is incorrect — the limitation is the visualization model, not the platform.

p5.js is JavaScript running in the browser. JavaScript can execute millions of comparisons per second without any frame-rate involvement. The draw loop runs at 60 fps alongside JavaScript execution, not instead of it. The browser’s JavaScript engine and the rendering pipeline are separate concerns. p5.js’s noLoop() and loop() controls, and the fact that any code in a button handler or event listener runs at full CPU speed, confirm this.

The problem in the current SuperSorter is the design choice: one animated step per frame. A different design can show true relative speed. Here are three approaches, in order of engineering effort:

Approach 1: Benchmark Mode (lowest effort, highest accuracy)
Run each sort algorithm at full JavaScript speed — a plain for loop, no animation, no frame limit — on the same data using performance.now():

function benchmarkSort(sortFn, data) {
    let copy = [...data];              // sort a copy
    let t0 = performance.now();
    sortFn(copy);                      // full speed, no yield, no draw()
    return performance.now() - t0;     // elapsed milliseconds
}

Run this for every algorithm, display a bar chart or a table of milliseconds. At n=50,000: QuickSort finishes in ≈ 20ms, Bubble Sort in ≈ 8,000ms. The actual relative speeds are immediately visible and accurate. SuperSorter already has the Bogo Sort Estimator, which does a version of exactly this (theoretical estimate, no animation). A benchmark mode would do it empirically for every algorithm.

Approach 2: Time-Budgeted Batch Mode (medium effort)
Instead of one step per frame, each algorithm is given a fixed time budget per frame (e.g., 8ms out of the 16ms frame window). Within that budget it runs as many steps as it can:

function draw() {
    let budget = 8;                          // ms per frame
    let t0 = performance.now();
    while (performance.now() - t0 < budget && !isDone) {
        oneStep();                           // do one sort operation
    }
    renderCanvas();                          // draw current state
}

Algorithms that can execute many steps per millisecond (QuickSort, Shell Sort) will visually progress faster than those that cannot (Bubble Sort). The canvas becomes a real-time speed race: the algorithm whose diagonal line forms first is genuinely faster. This is closest to what the Java applets showed — a thread running at full speed with a periodic render.

Approach 3: Race Mode (highest visual impact)
Split the canvas vertically into N lanes, one per algorithm. Each lane sorts its own copy of the same random data simultaneously, using the time-budgeted batch approach. The algorithm whose lane shows a completed diagonal line first won the race — factually, in real time, on identical data.

This is the most pedagogically powerful version because it answers “which algorithm is faster?” with an image rather than a number. It is also the most engineering work: requires refactoring to support multiple independent DotField instances and canvases.

Strong agreement — and prominent placement at the top of the modal is the correct choice, not the bottom.

The reason placement matters: a misconception formed before reading the descriptions is much harder to dislodge than one prevented by a note at the top. A student who opens the About modal, sees the algorithm descriptions, runs the app, and observes that Shell Sort finishes in 0.15 seconds while QuickSort takes 5 seconds, has already concluded “Shell Sort is 30× faster.” A disclaimer at the bottom of that modal will not reach them. A disclaimer at the top does.

Three principles guided the wording:

1. Lead with what the app IS good at — not with a negative. “SuperSorter excels at showing how each algorithm works” comes before the limitation. This prevents the disclaimer from reading as an apology.
2. Name the specific limitation concisely — not a general “take with a grain of salt” but the exact mechanism: animations that finish in fewer frames are not necessarily faster algorithms, because different algorithms define “one step” differently.
3. Give the actionable rule of thumb — not just a warning but what to do instead: set dots to 10,000+, use Reverse Dots as worst-case input, compare the elapsed-time display.

The Bootstrap alert-warning (amber) with a Font Awesome triangle-exclamation icon was chosen because: amber signals “caution” without “danger” (the app is not broken — it just has a scope limitation); the icon pulls the eye before any text is read; and the d-flex gap-2 layout keeps the icon flush with the first line of text rather than floating separately.

Iterative — from the very beginning.

J.W.J. Williams published Heap Sort in 1964 as an iterative algorithm. His original description used sequential index arithmetic to navigate the implied binary tree stored in an array. Both phases are naturally iterative:

Why Heap Sort is NOT divide-and-conquer. Merge Sort and QuickSort are inherently recursive because their design is: split the problem into two independent sub-problems, solve each, combine. The “two independent sub-problems” is what makes recursion the natural expression.

Heap Sort has no such structure. It exploits a data structure — the heap — to efficiently locate the minimum (or maximum) element repeatedly. The heap is a global property of the entire array; there are no two independent halves being processed simultaneously. This makes it fundamentally non-recursive in its design intent.

The textbook nuance: CLRS presents heapify recursively. Introduction to Algorithms (Cormen, Leiserson, Rivest, Stein) — the most widely used algorithms textbook — presents MAX-HEAPIFY as a recursive procedure:

MAX-HEAPIFY(A, i):
    largest ← largest of A[i], A[left(i)], A[right(i)]
    if largest ≠ i:
        swap A[i] and A[largest]
        MAX-HEAPIFY(A, largest)    ← recursive call

But the OUTER algorithm — BUILD-MAX-HEAP and HEAPSORT — are both iterative loops that call MAX-HEAPIFY. The recursion depth of MAX-HEAPIFY is O(log n) — it follows one path from a node to a leaf — so it is easily converted to an iterative while loop (follow the path, swap as needed, stop when the heap property holds). Most production implementations use the iterative form to avoid even O(log n) call-stack depth.

Our implementation. SuperSorter’s minHeapify() follows the CLRS recursive presentation — it calls itself on the subtree of the largest child. The outer heapSort() is an iterative loop. This is correct and standard. The recursion in minHeapify is O(log n) deep — not the O(n) or O(n log n) depth that would require a generator for animation safety.

The key comparison for your students:
Merge Sort and QuickSort — recursion reflects the algorithm’s design. The recursive form is the canonical form; the iterative versions are conversions for practical reasons.
Heap Sort — iteration reflects the algorithm’s design. The heapify subroutine can be written recursively (and sometimes is, for clarity), but the recursion is incidental, not structural.

Recommendation: SPARK bar for all three pages — no separate explanation section needed.

The SPARK bar is the right placement for two reasons:

1. It is the navigation layer for the page. The SPARK bar in this ecosystem sits between the hero and the main content; it holds quick links to related pages and sections. Duck Sorter is a directly related page, not a random external site. It belongs there the same way “Compare Algorithms” belongs in Duck Sorter’s SPARK bar.
2. The title attribute is the explanation. The user asked: “if it’s anywhere else than the SPARK bar, we’ll need a brief explanation.” The link’s title tooltip delivers that explanation on hover, which is exactly the right amount of information at that level of navigation — more would clutter the bar.

Three pages updated:

Why comparingSortAlgorithms.html also gets the link: the comparison page covers the six Duck Sorter algorithms and their Big O complexity. A student reading about Shell Sort or Insertion Sort there has a natural next question: “what do these look like on 1,000 dots?” The SuperSorter link answers that question with one click, without burying the reference page in secondary content.

Icon choice: 🦆 (duck) for the Duck Sorter link — thematic and immediately recognisable. 📈 (chart trending up) for the SuperSorter links — it suggests “larger scale, more data” without competing with 📊 (bar chart) already used for “Compare Algorithms” in Duck Sorter.

Three files created:

Algorithm families and their color coding:

Code notation consistency: Bubble, Cocktail Shaker, Comb, Insertion, Selection, and Shell Sort snippets are verbatim copies from duckSortingSketch.js lines 98–570. The remaining five algorithms (Merge Sort, QuickSort, Heap Sort, Timsort, Bogo Sort) are written in exactly the same style: ascending sort, variable names arr, n, i, j, key, temp, comment format matching the duck sorter exactly.

The page reuses superSorterHomeStyles.css for the hero and SPARK bar (same sortingPic.jpg background, same machine-blue accent), so the Algorithms page looks native to the SuperSorter family while its algorithm cards use a distinct color vocabulary that makes family membership immediately visible.

Design question 1: Placement — next to Sort, or separate?

A button directly next to Sort has two risks: (1) a novice might click it instead of Sort and be confused when the canvas doesn’t animate; (2) it implies the benchmark runs “one algorithm” like Sort does, when in fact it runs all of them.

Recommendation: place it below the sliders as a clearly-labelled separate action, not in the primary Sort row. A horizontal rule and a brief label (“Algorithm Speed Comparison”) signals that this is a distinct mode. A single full-width button ⏱ Compare All Algorithms is unambiguous. The button can also note the current n: “Compare All (300 dots)” — dynamically updated as the dot-count slider changes. This sets expectations before the user clicks.

Design question 2: Which algorithms to benchmark?

The user correctly proposes omitting Bottom-Up Merge Sort (option 9) and QuickSort Stack (option 11). Here is a fuller algorithm selection with reasoning:

That gives 11 algorithms in the benchmark. The Shell Hybrid inclusion is worth defending: the whole teaching arc of Sessions 2–3 was building toward the empirical comparison. The benchmark is where that payoff lands.

Design question 3: Results modal format

A plain table of numbers is not engaging. A few additions make the results interpretable at a glance:

• Bar chart inside the table. A narrow inline bar (CSS width proportional to elapsed time) in the same row as the number makes the relative difference immediately scannable without reading every cell.
• Fastest row highlighted. Green background on the fastest row; amber on any result >10× the fastest; red on any result >100×. Students see the winner before reading a single number.
• Complexity reminder. A small “Expected: O(n²)” column alongside the actual time links the measured result to the theory from the visualisation and the Algorithm Reference page.
• Data set context header. “Benchmarked on 2,000 dots (reversed)” at the top of the modal — the input matters, and novices should know the result is data-dependent.
• Sorted by elapsed time, fastest first. Not alphabetical — the ranking IS the result.
• A link to the Algorithm Reference page at the bottom: “Why do these algorithms differ? → Sorting Algorithms Reference”

Implementation approach: where does the benchmark logic live?

The benchmark functions need to be:

• Pure JavaScript array sorts — take a plain number array, sort it, return it. No reference to myDotField, no posn.y, no frame state variables.
• Operating on copies — the canvas data must not be disturbed. Each algorithm receives [...data].
• Timed with performance.now() — the browser’s high-resolution timer, not Date.now(), which has only 1ms resolution. performance.now() resolves to microseconds.

The benchmark functions are already partially written: superSorterAlgorithmScript.js contains CODE_SNIPPETS with clean implementations of all 11 target algorithms in JavaScript. These implementations are the right ones to use — they are already well-commented, use standard variable names, and are tested. A thin benchmarkSort.js (or additions to the existing sketch) would extract those as callable functions and add the timing wrapper.

Session 18 deliverables would be: (1) benchmarkSort.js — 11 callable sort functions + a runBenchmark() driver; (2) additions to superSorterHome.html — the Compare All button and the results modal; (3) a brief connecting wire in superSorterSketch.js to expose the current canvas data as a plain array for benchmarking.

Changes made:

The benchmark bar chart is pedagogically intentional. A table of numbers is honest but not engaging. The inline bar chart makes the relative difference immediately scannable: a student who sees Dumb Bubble’s red bar spanning the full width while Timsort’s green bar occupies 1% of it has understood O(n²) vs. O(n log n) without reading a single number. The numbers are there for students who want precision; the bars are there for the instant gestalt.

The large-n guard (N_QUADRATIC_LIMIT = 5000): At n > 5,000, O(n²) algorithms (Dumb Bubble through Insertion Sort) are automatically skipped with a “would take minutes” note. This prevents the browser from freezing while ALSO teaching something: students see that Bubble Sort’s “skipped” row is itself a lesson in why algorithm choice matters at scale.

Root cause: two bugs working together.

Bug 1 — JIT warmup kills timing accuracy. On the first run, the browser’s JavaScript JIT compiler interprets the sort functions. On the second run, all twelve functions are JIT-compiled and execute in microseconds. performance.now() in modern browsers is quantised to 0.1–2 ms for security reasons. If the true elapsed time is < 0.1 ms, the returned value is 0. With all twelve functions returning 0, minTime = 0.

Bug 2 — Division by zero propagates to display. In buildBenchmarkModal():

var ratio = minTime > 0 ? r.time / minTime : 1;

When minTime = 0, every algorithm gets ratio = 1. Then:

if (ratio < 1.05) ratioStr = '🏆 fastest';

1 < 1.05 is true for every entry. All twelve rows get the trophy. The ratio ≤ 1.5 colour check also fires for all, making every row green. This is not a display state problem — it is a measurement problem feeding a display that has no safety net.

Fix 1 — Multi-run micro-benchmark timing. Standard technique: if a single run finishes in < 2 ms, run the algorithm 50 more times and divide by 50. The averaged result is accurate to the sub-millisecond level even after JIT warmup:

var t0      = performance.now();
algo.fn(copy);
var elapsed = performance.now() - t0;

if (elapsed < 2) {          // below browser quantisation threshold
    var t1 = performance.now();
    for (var rep = 0; rep < 50; rep++) {
        algo.fn(data.slice());
    }
    elapsed = (performance.now() - t1) / 50;
}

This adds < 1 second to the benchmark run (50 × ~1 ms for fast algorithms), which is invisible in practice.

Fix 2 — Trophy anchored to rank, not ratio. The trophy should belong to rank 1 regardless of what ratio arithmetic produces. Changed from:

if (ratio < 1.05)  ratioStr = '🏆 fastest';  // fires for ALL when ratio=1

to:

if (idx === 0)     ratioStr = '🏆 fastest';  // only rank 1, always correct

The green background highlight for the fastest row was also moved from ratio ≤ 1.5 to idx === 0 for the same reason.

Utility category decision: no. The benchmark feature does add a utility-like capability, but SuperSorter’s primary identity is educational/algorithmic visualization. “Utility” in the Explore taxonomy refers to service tools (formatters, converters, generators) that produce a practical output. SuperSorter produces understanding, not a deliverable. S.P.A.R.K. + Processing + Simulations correctly captures it.

Files changed: news.html — new entry news-2026-086 above Duck Sorting. explore.html — SuperSorter added to three category cards (S.P.A.R.K., Processing, Simulations) and their corresponding offcanvas panels.

Card item counts after update: S.P.A.R.K. card 6 → 7; Processing card 7 → 8; Simulations card 5 → 6. Processing and S.P.A.R.K. are now slightly above the 5–6 guideline. If the cards feel crowded, the oldest items can be moved to offcanvas-only; the offcanvas panels are the definitive complete lists.