Seven elements, three comparisons: binary search as an animation

Nav — Fri, 28 Aug 2026 03:49:21 +0000

Binary search is one of those algorithms that everyone can describe and plenty of us still get wrong when we write it. The description is easy — halve the interval until you find the target. The details are where it goes sideways: whether the bound is inclusive, whether mid can overflow, whether the loop is < or <=, whether you return the index or the insertion point.

Here is the whole thing running on a seven-element array, searching for 16.

What the picture makes obvious

Reading the code, the halving is a claim you accept. Watching it, the halving is a thing you see happen.

Three moments stand out that I never noticed from the code alone:

Step 3 throws away four of seven elements after one comparison. values[3] = 12 is less than 16, so indices 0 through 3 are gone at once. Not one element — over half the array, from a single <. That is the entire algorithm in one frame, and it is the part the O(log n) notation hides rather than explains.

The interval, not the position, is the state. I used to think of binary search as "a pointer that jumps around." It is not. The state is [lo, hi], and mid is just a derived value you compute fresh each pass. Once the animation shows the window shrinking instead of a cursor moving, the off-by-one errors mostly stop, because you start asking "is my interval still correct?" instead of "is my index right?"

The last step is a comparison, not a discovery. At step 5 the interval is a single candidate. You still have to check it. Skipping that check is the classic bug where you return an index for a target that was never in the array.

Why seven elements matter

Seven is small enough to hold in your head and large enough to need three comparisons. A million-element array needs twenty. The animation is short, but the shape of what you are watching does not change as the input grows — that is the actual claim binary search makes, and it is easier to believe once you have watched the small version resolve.

What I am curious about

I have been building these step-by-step animations for data structures and algorithms, and I keep going back and forth on how much to show.

Is six steps the right pace, or does it move too slowly for something you already know?
Does the explanation text under each step help, or would you rather just watch the array and work it out?
Which algorithm is hardest for you to picture? I find graph traversals fine and dynamic programming almost impossible to animate usefully — the table fills in, but the reason each cell gets its value is invisible.

Genuinely curious what people think. If you have seen a visualisation that made something click for you, I would like to see it.

The full walkthrough with the code in Python, C++ and Java is at solvelogs.com/learn/binary-search — free, no signup.

What I learned writing 1,096 tests for algorithm animations

Nav — Fri, 28 Aug 2026 03:38:19 +0000

I spent the last few months building visual walkthroughs for data structures and algorithms. Not diagrams — step-by-step animations where you watch the pointers move, the stack grow, and the visited set fill in.

Somewhere in the middle of it I discovered the animations were lying to me. Here is what went wrong and what I did about it.

The problem with hand-written animation steps

My first version hardcoded every animation frame. A binary search page had a list of steps like this:

steps: [
  { lo: 0, hi: 9, mid: 4, note: "Check the middle" },
  { lo: 5, hi: 9, mid: 7, note: "Target is larger, go right" },
  // ...
]

This works right up until you change the input array. Then every frame after the first is quietly wrong, and nothing tells you. The animation still plays. It still looks convincing. It just teaches the wrong thing.

I found this the embarrassing way: a tree traversal page was animating the correct-looking sequence for a tree that no longer matched the diagram beside it. The picture said one thing, the animation said another, and both were rendered from different sources of truth.

Running the real algorithm instead

The fix was to stop writing the frames and start recording them. Each page now runs the actual algorithm and logs a snapshot at every meaningful state change:

function trace(arr, target) {
  const steps = [];
  let lo = 0, hi = arr.length - 1;

  while (lo <= hi) {
    const mid = (lo + hi) >> 1;
    steps.push({ lo, hi, mid, note: `Compare ${arr[mid]} against ${target}` });

    if (arr[mid] === target) return steps;
    if (arr[mid] < target) lo = mid + 1;
    else hi = mid - 1;
  }
  return steps;
}

The animation is now a byproduct of the algorithm, not a parallel description of it. Change the input and every frame updates. Break the algorithm and the animation breaks visibly, in the same way.

The part that actually mattered

The real win was that this made the animations testable. Once the steps come from running code, you can assert on the last one:

const steps = trace([1, 3, 5, 7, 9, 11], 7);
assert.equal(steps.at(-1).mid, 3);

I now have 1,096 of these assertions across every animation on the site. They run on every build. The suite has caught things I would never have noticed by watching:

A heap animation that showed the sift-down but stopped one swap early, so the final heap it displayed was not actually a valid heap.
Ten separate pages animating a linked list to explain a tree, because the generic fallback visual was easier than writing the right one.
Several tracers truncated at exactly seven steps — a number that had crept in as a default and then silently became the ceiling for operations that needed fourteen.

That last one is my favourite failure. Every one of those pages looked finished.

What I would tell my earlier self

If a visual explanation is not generated by the thing it explains, it will drift. Documentation drifts from code for exactly the same reason, and we have long since accepted that generated docs beat hand-written ones. Animations are no different — they are just documentation that moves.

Test the output, not the rendering. I do not screenshot-test the SVG. I assert on the final state of the trace. That catches the errors that matter (wrong algorithm) and ignores the ones that do not (a node moved three pixels).

A convincing wrong explanation is worse than no explanation. A learner who reads a static wrong sentence often catches it. A learner watching a smooth animation assumes the machine knows better than they do. Getting this right felt less like polish and more like an obligation.

The result

The site is SolveLog — worked LeetCode problems and data structure lessons, each with its own generated animation. A few where the tracer approach earns its keep:

Binary search — watch the search window actually collapse
AVL trees — the rebalance rotations are the whole point, and they are impossible to follow as static pictures
Backtracking — the call stack panel beside the tree is what made this click for me

It is free and there is no signup. I built it to learn this material properly myself, and the testing discipline above is the only reason I now trust it.

Happy to answer questions about the tracer architecture in the comments.

DEV Community: Nav