Seven elements, three comparisons: binary search as an animation

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.