Not millions. Not thousands. Thirty-three. (2³³ ≈ 8.59 billion — the math isn't rounded up for effect; it's exact.)

Now here's the part that made me respect this algorithm instead of just tolerating it as an interview topic: the standard way almost every textbook teaches you to write binary search contains a bug so subtle it sat in Java's own standard library for about nine years before anyone noticed. It was found by Joshua Bloch — the engineer who wrote much of Java's Collections framework — and it traces back even further to Jon Bentley's original binary search implementation in his 1986 book Programming Pearls, which carried the same flaw undetected for two decades.

If a bug like that can hide in code written by some of the most scrutinized engineers in the industry, "I already know binary search" is a more dangerous sentence than it sounds. I'm a second-year CS student, not an expert — but this is the algorithm that first made me feel like I understood why something worked instead of just memorizing that it did. I want to hand you that same feeling, bug included.

First, Let's Actually Trace It

Forget the theory for a second. Say we have this sorted array and we're hunting for 23 :

index: 0 1 2 3 4 5 6 7

value: 2 5 8 12 16 23 38 45

• low = 0 , high = 7 → mid = 3 → arr[3] = 12 . That's less than 23, so 23 must live in the right half. We just eliminated indices 0–3 without ever looking at them again.

• low = 4 , high = 7 → mid = 5 → arr[5] = 23 . Found it. Two comparisons. Total.

A linear scan would've taken up to 8 comparisons. Binary search took 2. Scale that array up to a million elements, and linear search takes up to a million comparisons — binary search still takes about 20.

The Idea Underneath the Code

The reason this works isn't "we check the middle." It's this: every comparison lets you discard half the remaining data with mathematical certainty, not a guess. Because the array is sorted, whenarr[mid] < target, you don't need to check anything to the left of mid — sorted order has already proven it's irrelevant. You're not searching faster. You're refusing to search places that logically cannot contain the answer.

That's the whole algorithm. Everything below is just implementation detail.

The Code (C++)

#include <iostream>
#include <vector>
using namespace std;
int binarySearch(const vector<int>& arr, int target) {
    int low = 0, high = arr.size() - 1;
while (low <= high) {
        int mid = low + (high - low) / 2;   // see note below

        if (arr[mid] == target)
            return mid;
        else if (arr[mid] < target)
            low = mid + 1;    // discard left half
        else
            high = mid - 1;   // discard right half
    }
    return -1;   // not found
}
int main() {
    vector<int> arr = {2, 5, 8, 12, 16, 23, 38, 45};
    int target = 23;

    int result = binarySearch(arr, target);
    if (result != -1)
        cout << "Found at index: " << result << endl;
    else
        cout << "Not found." << endl;
 return 0;
}

Run it. Change target to something not in the array and watch it correctly return -1. This isn't pseudocode — it's a complete, compilable program you can paste into any C++ compiler right now.

Why It's O(log n), Properly Explained

Every iteration cuts the search space in half. Starting from n elements, after k iterations, you have n / 2^k elements left. The loop ends when that shrinks to 1, so:

n / 2^k = 1 → 2^k = n → k = log₂(n)

That's not hand-waving — that's the actual derivation. For n = 8,000,000,000, log₂(n) ≈ 33. That's where the number at the top of this blog came from.

Space complexity: the iterative version above uses O(1) extra space — just a few variables. A recursive version would use O(log n) space instead, because of the call stack building up with each recursive call. Worth knowing, because interviewers will ask which version you wrote and why.

The Bug That's Humbled Professional Engineers

Look at this line again:

int mid = low + (high - low) / 2;

Most people first write it as (low + high) / 2 instead. It looks identical mathematically — and it's wrong. If low and high are both large, low + high can exceed the maximum value an int can hold and overflow, silently wrapping around into a negative number, which sends mid somewhere nonsensical.

This is the exact bug Joshua Bloch wrote about in his 2006 post, "Extra, Extra – Read All About It: Nearly All Binary Searches and Mergesorts are Broken." He found it because the binary search he'd written for the JDK itself had it — and it had been quietly shipping for close to nine years before someone's program broke and the report reached him. If it can slip past that level of scrutiny for nearly a decade, it's not a "beginner mistake" — it's a reminder that simple-looking code deserves careful reading.

You Probably Don't Need to Write This By Hand

Here's something they don't always tell beginners: in real C++ code, you rarely hand-roll binary search. The Standard Library already has it:

#include <algorithm>

bool exists = binary_search(arr.begin(), arr.end(), 23);        // true/false
auto it = lower_bound(arr.begin(), arr.end(), 23);              // first position >= 23
auto it2 = upper_bound(arr.begin(), arr.end(), 23);             // first position > 23

lower_bound and upper_bound matter more than people expect — they're how you handle duplicate values in the array, which plain binary search doesn't deal with cleanly on its own. If you're prepping for interviews, know both the hand-written version and these — interviewers use hand-rolled to test understanding, but production code uses STL.

When Binary Search Quietly Fails You

It's not a universal upgrade. It breaks down when:

• The data isn't sorted — and sorting it first costs O(n log n), which can erase the benefit if you're only searching once.

• You're working with a linked list — binary search needs random access (jumping straight to index mid)which arrays give you and linked lists don't.

• The dataset changes constantly — frequent insertions/deletions can make maintaining sorted order more expensive than the search savings.

Knowing when not to use an algorithm is as much a sign of understanding it as knowing when to use it.

Where This Idea Runs the World

Once you see the pattern, it's everywhere:

• git bisect Binary searches your commit history to find which commit introduced a bug.

• Database indexes (B-Trees) use the same halving principle to avoid scanning entire tables.

• Rate-limiting and capacity planning in systems design often use binary-search-style thinking to find a breaking point efficiently.

It's less "an algorithm for arrays" and more "a strategy for eliminating half of any problem, fast."

Where I'm At

I'm writing this as a second-year student a few weeks into serious DSA practice — not as someone who's mastered it. But I've found that the topics I initially found hardest are the ones I can now explain most clearly, precisely because I had to slow down and actually understand them instead of pattern-matching my way through. If any part of this saved you the slow version of that process, it did its job.

First post in what I'm hoping becomes a habit: writing about the small ideas in computer science that turn out to be bigger than they look.