I do not particularly enjoy learning an algorithm by memorizing its final implementation. When I come across a mathematical formula or a programming technique, my instinct is to ask why it is valid in the first place. How would I arrive at the same idea if nobody told me its name?

That is how this exploration began. I did not want to be handed a binary-search problem, shown a loop, and asked to remember which pointer moves. I wanted to start with a situation, make decisions based on the information available, question those decisions, and see which algorithm emerged.

What started as finding one number in an ordered sequence eventually led to questions about worst-case reasoning, unknown distributions, integer overflow, duplicates, Boolean predicates, vacuous truth, loop invariants, and the limits of binary search itself. This is not a transcript of the conversation. It is my reasoning from that discussion, reconstructed as one continuous exploration—including places where I was uncertain or where an apparently obvious conclusion needed a proof.

A hundred numbers, and very little information

Imagine a piece of paper containing 100 numbers in strictly increasing order. I need to find the number 73. I am allowed to reveal the number at any position, but only one position at a time.

Where would I look first?

Knowing the numbers are strictly increasing is important, but I would not immediately assume that they form a familiar sequence. They might increase linearly, quadratically, exponentially, follow a polynomial of some unknown degree, or follow no simple formula at all. In particular, the value 73 gives me no reliable clue about its position. There is no reason it must sit near position 73, or anywhere else in particular.

My practical instinct is to inspect the middle, around the 50th position.

But the justification matters. I am not choosing the middle because the target is likely to be there. I am choosing it because I do not know how values are distributed, and the midpoint gives me a useful worst-case decision. If the revealed number is smaller than 73, ordering excludes the entire left portion; if it is larger, ordering excludes the entire right portion. Neither outcome leaves me with an overwhelmingly larger region to search.

The midpoint is not a prediction of where the answer lies. It is a way to limit how many possibilities could remain after a single observation.

That distinction turned out to matter throughout the discussion.

One observation eliminates positions I have never inspected

Suppose I reveal position 50 and find 120.

I want 73. Since the sequence is strictly increasing, every number after position 50 is larger than 120. Position 50 itself is also not 73. I can therefore discard positions 50 through 100, leaving positions 1 through 49.

There was a small but useful question here: should the 50th position remain in the range? No. We already inspected it, and we know it is not the target. The new interval is 1–49, not 1–50.

With 49 candidates left, I inspect position 25 and find 40. Now I know the target, if it exists, lies somewhere in positions 26 through 49.

At this point, could I make a smarter guess using the two observations?

position 25 → value 40
position 50 → value 120
target      → value 73

It is tempting to draw a straight line between the observed values and interpolate the position of 73. But where did the assumption of a straight line come from? The sequence could be linear, quadratic, exponential, a higher-degree polynomial, or irregular. Two observations are consistent with infinitely many possible ways of filling in the unobserved positions, subject to increasing order.

Even after inspecting three or four positions, I still would not know the generating rule. A few observed points could suggest a model, but they do not establish it. A different polynomial could fit those points; a monotonic sequence might not follow any useful polynomial at all. There is a difference between finding a model that fits observations and proving that the model describes the unseen data.

So my current best decision remains the same: take the middle of the remaining candidate positions, not the middle of the numerical values.

This is not a claim that interpolation can never be useful. If I have trustworthy information about the distribution, an estimate-based search may do better on some inputs. But with ordering as my only guarantee, splitting the possible positions in half gives a reliable bound on the worst case.

What does “half” actually mean?

I initially described the search space as shrinking by half, or perhaps half minus one. That phrasing seemed plausible until I examined even and odd ranges.

Start with positions 1 through 100. Using position 50 as the middle:

1 .............. 49 | 50 | 51 ................ 100
       49             1             50

If the target is smaller than the value at position 50, we keep 49 candidates. If it is larger, we keep 50. In the worst case, the remaining number is 50, not 49.

For 25 candidates, however, the middle has 12 candidates on either side. So the number remaining is 12 in the worst case.

More generally, if an inclusive interval contains N candidate positions and I inspect one of its middle positions, the largest side remaining is:

[ \left\lfloor\frac{N}{2}\right\rfloor ]

The worst-case sizes from 100 candidates go like this:

100 → 50 → 25 → 12 → 6 → 3 → 1 → 0

Notice what happened: the reduction is not exactly N/2 at every step, because the number of elements is an integer and the inspected element is excluded. But it is tightly bounded by halving.

Now imagine 1,000,000 candidate positions. How many inspections might be needed?

If after k halvings I have roughly N / 2^k candidates, the number of halvings needed to reach around one candidate satisfies:

[ \frac{N}{2^k}\approx 1 ]

Rearranging:

[ 2^k\approx N \qquad\Longrightarrow\qquad k\approx\log_2 N ]

That is where the logarithm comes from. It is not a complexity label attached to the algorithm by convention; it emerges from how quickly the logical candidate space shrinks. With one million positions, this search requires at most 20 midpoint inspections in the worst case.

For a nonempty interval of size N, an exact upper bound for this implementation's number of inspections is floor(log₂ N) + 1. The approximation helped discover the logarithm; the integer bounds make the statement precise.

Before coding: where exactly is the middle?

A new question emerged while trying ranges whose lower position was not 1. If my current candidates run from L to H, how do I calculate the midpoint without repeatedly thinking about whether the number of candidates is even or odd?

For an inclusive integer range, the left-middle position is:

[ M_{\text{left}}=\left\lfloor\frac{L+H}{2}\right\rfloor ]

The floor notation means to round down. For example:

L = 1,  H = 49   → midpoint 25
L = 1,  H = 50   → midpoint 25
L = 26, H = 49   → midpoint 37
L = 2,  H = 13   → midpoint 7

An even-sized interval has two middle positions; choosing the left one is a convention, not a logical necessity.

But there is an implementation issue: the expression L + H can overflow a fixed-width integer even if both indices are individually valid.

Consider an 8-bit signed integer, whose range is -128 through 127. Both 125 and 126 fit. Their sum, 251, does not. Computing (L + H) / 2 through that intermediate sum may therefore be wrong, despite the mathematical midpoint being representable.

My first instinct was to use the distance between the boundaries instead of adding the boundaries. In fact, I was thinking of this expression:

[ M_{\text{right}}=H-\left\lfloor\frac{H-L}{2}\right\rfloor ]

It starts from the upper boundary and moves left by half the interval's distance. Another common expression starts from the lower boundary:

[ M_{\text{left}}=L+\left\lfloor\frac{H-L}{2}\right\rfloor ]

The conversation took a useful detour here because I was initially misunderstood: I had suggested H - (H - L) / 2, not simply (H - L) / 2. Those are very different expressions. The latter is only an offset; the former is an actual midpoint position.

Both complete formulas avoid the large L + H intermediate under the usual assumptions 0 ≤ L ≤ H, with valid representable indices. But do they return the same middle? Rather than taking that on trust, I wanted to prove the difference.

Let:

[ d=H-L ]

If d is even, write d = 2q. Then:

[ M_{\text{left}}=L+q ]

[ M_{\text{right}}=(L+2q)-q=L+q ]

They coincide.

If d is odd, write d = 2q + 1. Then:

[ M_{\text{left}}=L+q ]

[ M_{\text{right}}=(L+2q+1)-q=L+q+1 ]

So the right-middle formula returns exactly one position after the left-middle formula when the number of candidates is even. When the number of candidates is odd, both choose the same position.

That gave me a more satisfying conclusion than simply memorizing one midpoint expression: either convention is valid, as long as the interval updates are consistent and always make progress.

For an exact-value search on a sorted ascending sequence, if the midpoint value is smaller than the target, we set L = M + 1; if it is larger, H = M - 1. We exclude the midpoint because we have already ruled it out.

Here is the basic implementation, now derived rather than presented at the beginning:

func Find(a []int, target int) int {
    low, high := 0, len(a)-1

    for low <= high {
        mid := low + (high-low)/2

        if a[mid] == target {
            return mid
        }
        if a[mid] < target {
            low = mid + 1
        } else {
            high = mid - 1
        }
    }

    return -1
}

This finds an occurrence or returns -1 if none exists. That qualification became important next.

Duplicates: finding a value is not the same as finding where it begins

Until this point I had assumed strictly increasing values. What if the numbers are merely non-decreasing, so duplicates are allowed?

index:  0  1  2  3  4  5  6  7  8
value:  2  4  4  4  4  4  7  9 11

Suppose the goal is not to find any 4 but to find its first occurrence.

If I inspect index 4 and see 4, stopping immediately is no longer correct. It could be the first 4, but there could also be more copies to its left.

My first approach was straightforward: save the index as a candidate, then continue searching the left portion. If I find another 4, update the candidate and keep going left. If the inspected value is smaller, I search right, because the first 4 must be to the right of that smaller value.

For example:

index 4 → 4  : remember 4, search left
index 1 → 4  : remember 1, search left
index 0 → 2  : search right
stop         : first 4 is at index 1

That works. But a different question made the idea much cleaner.

What if, instead of looking for equality with 4, I ask at each position:

Is this value greater than or equal to 4?

The answers form a Boolean sequence:

index:       0  1  2  3  4  5  6  7  8
value:       2  4  4  4  4  4  7  9 11
value >= 4:  F  T  T  T  T  T  T  T  T

Now I can forget about equality during the search itself. I only need to find the first position where the condition becomes True.

This was the conceptual shift. The search was no longer about encountering the number 4. It was about locating a transition boundary.

What is monotonicity doing for us?

A monotonic sequence moves in one direction without reversing. A non-decreasing numeric sequence can contain equal values, but its values never decrease.

A Boolean sequence can have a similar structure:

F F F F T T T T T

Here, once the condition becomes True, it stays True. There is at most one False-to-True transition. All-False and all-True sequences also satisfy this property, even though the transition lies outside the represented positions.

With an ascending sorted array, conditions such as a[i] >= x or a[i] > x produce exactly that structure. The crucial object is the predicate—the condition evaluated at a position—not the original numeric array by itself.

For the first True boundary, the reasoning is simple:

• If the midpoint is False, every position at or before it must also be False. The answer, if it exists, lies to the right.

• If the midpoint is True, that position may be the first True, or the first True may lie to its left. The answer cannot be strictly to its right.

Using inclusive search boundaries, we can move L = M + 1 for False and H = M - 1 for True. This second update initially seemed slightly suspicious: we have discarded a True midpoint that might itself be the answer. How can that still work?

That question led to the most interesting proof in the discussion.

An unsettling result: why can I return L after the search becomes empty?

Imagine this Boolean sequence:

index:  0  1  2  3  4  5  6  7
value:  F  F  F  T  T  T  T  T

Using inclusive bounds, a left midpoint, and the updates above:

The search ends with L = 3, which is exactly the first True position.

At first, that looked like an observation, not an explanation. What if I did not inspect L directly? How can an empty interval tell me something so definite about a boundary? I wanted a justification that did not depend on a few convenient examples.

The explanation comes from two guarantees that hold before the search, after each update, and at the end:

1. Every valid position strictly before L is False.

2. Every valid position strictly after H is True.

Why do those guarantees hold?

Initially, L = 0 and H = n - 1. There are no valid array positions before zero or after the last index, so neither statement can be violated. The guarantees are true before we inspect anything.

If the midpoint is False, monotonicity tells us all positions up to that midpoint are False. Moving L to M + 1 extends the portion already known to be False.

If the midpoint is True, monotonicity tells us all positions from that midpoint onward are True. Moving H to M - 1 extends the portion already known to be True.

This also answers the worry about throwing away a possible answer. We are not merely discarding positions; we are classifying them. A True midpoint excluded from the active interval remains in the region known to be True. The eventual boundary can sit exactly at the edge of those classified regions.

When the search finishes, there are no unresolved candidate positions, and because we always move across an inspected position, the boundaries meet in this relationship:

[ L=H+1 ]

The first guarantee says:

[ i<L\implies P(i)=\text{False} ]

The second says:

[ i>H\implies P(i)=\text{True} ]

But H = L - 1. Therefore:

[ i> L-1\quad\Longleftrightarrow\quad i\ge L ]

So at termination:

[ \boxed{\ i<L\Rightarrow P(i)=\text{False},\qquad i\ge L\Rightarrow P(i)=\text{True}\ } ]

These statements refer to valid positions within the array. They describe exactly what it means for L to be the first True position.

If L = n, there is no valid index at or after L: that means no True exists, and n acts as a sentinel immediately beyond the array.

I found one distinction especially clarifying: when L > H, it does not mean we have inspected every element. It means we have exhausted the logical search space. Every possibility has either been inspected or eliminated by a proof based on monotonicity.

The two guarantees are examples of loop invariants—statements preserved throughout execution. Rather than treating the final value of L as a trick, the invariants make it a consequence.

A detour into logic: vacuous truth

There was a moment when the first invariant seemed intuitive but the second did not. If H is already at the final position, how can I claim that everything strictly after H is True? There is nothing after H!

That led to the idea of vacuous truth.

Take an empty classroom. Consider these statements:

Every student in the classroom passed.

Every student in the classroom failed.

Surprisingly, in classical logic, both are true when there are no students in the classroom.

That does not mean a student simultaneously passed and failed. Neither statement claims that a student exists. Each is a universal claim about all members of a set; when the set is empty, there is no member that violates either claim.

Formally, the statement

[ \forall x\in S,\ P(x) ]

is true for an empty set S. But the claim that there exists an element satisfying P is false for an empty set.

This is easy to misinterpret as “if I have not found a counterexample, a statement is true.” That is not generally valid. For a nonempty, unexamined set, we simply do not know. The special point here is that the set is known to be empty, so a counterexample is impossible.

Returning to the algorithm: when H = n - 1, the set of valid positions strictly after H is empty. Therefore, “every valid position after H is True” holds at initialization without requiring any True elements to exist.

And if the entire Boolean sequence is False, the search ends with L = n and H = n - 1. Everything before L is False. Everything after H is True only vacuously, because there is no such valid position. The same invariant handles the missing-boundary case cleanly.

This detour did not feel unrelated to algorithms. It explained precisely why an invariant can be true at the beginning of a loop even when it appears to assert knowledge about positions we have never examined.

The reusable operation we discovered

Once the invariant is clear, the implementation follows naturally:

// FirstTrue returns the first index where pred(i) is true.
// It returns n if all positions are false.
// pred must have the shape: F ... F T ... T.
func FirstTrue(n int, pred func(int) bool) int {
    low, high := 0, n-1

    for low <= high {
        mid := low + (high-low)/2
        if pred(mid) {
            high = mid - 1
        } else {
            low = mid + 1
        }
    }

    return low
}

There is something appealing about how little this function knows. It does not know whether we are searching for a number, an insertion position, or something else. It only asks a Boolean question about a position and relies on the promised False-to-True order.

The predicate constructs the Boolean search space. The algorithm finds its boundary.

Go already provides a closely related operation, sort.Search, which returns the first index satisfying a monotonic predicate. Using the standard library does not eliminate the need to justify monotonicity; it merely packages the search loop.

Finding the last occurrence required another change of perspective

After understanding the first occurrence, I did not want to move immediately to unrelated applications. What about the last occurrence of a value?

Consider:

index:  0  1  2  3  4  5  6  7  8
value:  2  3  5  5  5  5  5  8 10

The first 5 is at index 2, and the last is at index 6.

For the first occurrence we used a[i] >= 5, which has the shape F ... F T ... T.

For the last occurrence, I considered the condition a[i] <= 5, which has the reverse shape:

value <= 5: T  T  T  T  T  T  T  F  F

Now a True midpoint tells me that the last True must be at that midpoint or somewhere to its right, so I move L = M + 1. A False midpoint moves H = M - 1.

The invariants reverse:

[ i<L\implies P(i)=\text{True} ]

[ i>H\implies P(i)=\text{False} ]

At termination, L = H + 1. Therefore, L is the first False position, and H = L - 1 is the last True position.

So I can find the last index satisfying a[i] <= 5 by returning L - 1.

But that is not automatically the last occurrence of 5. Suppose the array is [1, 2, 3, 4, 7, 9] and the target is 5. The last element <= 5 is 4, not 5. The boundary exists even when the target does not.

The missing piece is just a final check: is the candidate index valid, and does the value at that index actually equal the target? If not, the target is absent.

The same caution applies when searching for a first occurrence: the first value >= target might be larger than the target.

Two boundary searches, one reusable algorithm

I wondered whether finding the first and last occurrences separately was unnecessary work. Couldn't one search find both?

Suppose we inspect a middle position containing the target. We learn something, but not enough to discard both sides: the first occurrence might still be to the left, and the last occurrence might still be to the right.

We can organize a single procedure that explores both sides after finding a match, but that is different from finding both boundaries by following only one chain of midpoint decisions. Two dedicated searches still take O(log n) + O(log n) = O(log n) time overall.

A useful observation is that neither search needs to find the target as its first midpoint value. We can search for two neighboring transitions:

• lowerBound(x): the first index with a[i] >= x.

• upperBound(x): the first index with a[i] > x.

On the array:

index:     0  1  2  3  4  5  6  7  8
value:     1  2  3  3  3  3  3  5  7
>= 3:      F  F  T  T  T  T  T  T  T
>  3:      F  F  F  F  F  F  F  T  T

The lower boundary is 2. The upper boundary is 7. Everything from 2 up to—but not including—7 equals 3.

That immediately gives the number of occurrences:

[ \boxed{\text{count}(x)=\operatorname{upperBound}(x)-\operatorname{lowerBound}(x)} ]

What if the value is absent? Take [1, 2, 4, 4, 4, 7, 9] and target 5. Both boundaries are index 5, the position of 7. Their difference is zero, which correctly says there are no 5s.

And what if every value equals the target? In [2, 2, 2, 2, 2], the lower boundary is 0 and the upper boundary is 5. Index 5 is not a valid element, but it is a perfectly meaningful boundary after the array. The count is 5 - 0 = 5.

The two boundaries also give insertion positions: lower bound inserts before existing equal elements; upper bound inserts after them.

At first these looked like separate tasks—first occurrence, last occurrence, count, insertion point. But they are consequences of identifying where a monotonic condition changes.

Here is the implementation using one generalized search function:

func LowerBound(a []int, target int) int {
    return FirstTrue(len(a), func(i int) bool {
        return a[i] >= target
    })
}

func UpperBound(a []int, target int) int {
    return FirstTrue(len(a), func(i int) bool {
        return a[i] > target
    })
}

func FirstOccurrence(a []int, target int) int {
    i := LowerBound(a, target)
    if i == len(a) || a[i] != target {
        return -1
    }
    return i
}

func LastOccurrence(a []int, target int) int {
    i := UpperBound(a, target) - 1
    if i < 0 || a[i] != target {
        return -1
    }
    return i
}

func CountOccurrences(a []int, target int) int {
    return UpperBound(a, target) - LowerBound(a, target)
}

One small disagreement in the conversation was actually clarifying. I initially said the two tasks could share a search function. My concern was that they generated different Boolean spaces. Both statements are compatible: the predicate changes; the algorithm does not. We can pass either predicate to the same first-True search.

Do the original numbers even need to be sorted?

This was the next natural question. At the beginning I used sorting to justify discarding half of an array. But by this stage, the correctness proof no longer referred to numerical sorting directly. It referred to a Boolean predicate with a False-to-True pattern.

So the input values themselves do not necessarily need to be sorted. What matters is whether the condition we are searching over is monotonic.

A Boolean predicate might be derived from a numerical sequence, from some calculation, or even from a yes/no feasibility test. As long as its answers across an ordered candidate space have the shape

F F F F F T T T T

we can search for the transition.

But this is a requirement to prove, not something that follows merely because a function returns Boolean values. A predicate can just as easily produce F T F T, in which case a midpoint answer cannot safely eliminate an entire side.

We explored that distinction with prefix sums.

An unsorted array whose predicate is still monotonic

Consider this array:

[4, 2, 7, 1, 8, 3, 6]

It is not sorted. Define a question for each prefix length k:

Is the sum of the first k elements at least 12?

For the nonempty prefixes:

k:          1   2   3   4   5   6   7
prefix sum: 4   6  13  14  22  25  31
>= 12:     F   F   T   T   T   T   T

The array is unsorted, yet the predicate has a clean False-to-True transition. Why?

Every element in this particular array is positive. Extending a prefix can only increase its sum. Once a prefix reaches 12, every longer prefix also reaches 12.

The mathematical guarantee is:

[ S(k+1)=S(k)+a[k] ]

With positive elements, S(k+1) > S(k). Even nonnegative elements would be sufficient for a non-decreasing prefix sum. The values' original ordering is irrelevant.

This example made the generalization concrete: binary search relies on the ordering of the answers to a question, not necessarily on the ordering of the underlying data.

Negative numbers: a broken guarantee, but not always a broken predicate

Now allow negative numbers:

[4, 9, -8, 2, 10, -5, 3]

The prefix sums are:

k:          1   2   3   4   5   6   7
prefix sum: 4  13   5   7  17  12  15
>= 12:     F   T   F   F   T   T   T

This is not monotonic. A prefix can reach the target and then fall below it after adding a negative number. Consequently, an observation at one position no longer proves that all later positions behave the same way. Our boundary-search proof is invalid here.

But the presence of a negative number does not, by itself, prove that every threshold predicate is nonmonotonic.

Consider:

array:      [10, -2, 5, -1, 4]
prefix sum:  10   8  13  12  16

For target 8, the predicate is:

T T T T T

It is monotonic even though the sums dip. For target 9, however, it becomes:

T F T T T

and monotonicity fails.

That distinction matters. A property of the underlying sequence may be sufficient to guarantee monotonicity for many predicates, but it is not always necessary for a particular predicate. The same underlying data can generate a monotonic Boolean space for one threshold and a nonmonotonic one for another.

It would be incorrect to argue “there is a negative number, therefore binary search can never work.” The precise question is whether the predicate for the current problem has the required transition structure. It may be monotonic accidentally for one input, but if the algorithm is meant to work for arbitrary inputs, we need a guarantee from the problem's assumptions, not a lucky example.

When binary search is no longer justified, what should I do?

We then changed the task. Given arbitrary positive and negative integers, find the smallest prefix length whose sum reaches a target.

I first clarified what “prefix” means. A prefix begins at the start of the array (index 0 in a zero-indexed array). A contiguous sequence beginning later is a subarray, not necessarily a prefix. The empty prefix is also permitted by some definitions, but for this particular exercise we considered nonempty prefixes.

With no monotonicity guarantee, binary search is not justified. But the task has an uncomplicated property of its own: if I examine prefix lengths in increasing order, the first qualifying prefix must be the shortest qualifying prefix.

So I can scan once, maintain a running sum, and stop as soon as it reaches the threshold:

// SmallestPrefixAtLeast returns the length of the shortest
// nonempty prefix whose sum is at least target, or -1.
func SmallestPrefixAtLeast(a []int, target int) int {
    sum := 0
    for i, x := range a {
        sum += x
        if sum >= target {
            return i + 1
        }
    }
    return -1
}

For [4, 9, -8, 2, 10, -5, 3] and target 12, the prefix sum at length 1 is 4; at length 2 it is 13. We can stop at length 2. Even if the sum drops below 12 later, no later prefix can have a smaller length than 2.

This takes O(n) time in the worst case and O(1) extra space. It does not rely on a monotonic threshold predicate; it relies on examining candidate prefix lengths in increasing order.

The lesson was not that we had failed to use binary search. It was that a correct simple solution is better than forcing a favored technique onto a problem that does not satisfy its assumptions.

A final variation, and where we paused

Before stopping, we considered a closely related problem: find the largest prefix length whose sum is at least the target.

My first answer was to keep scanning the whole array, update the best prefix length whenever the running sum reaches the target, and return the largest qualifying length. That works in O(n) time and O(1) extra space. Unlike the smallest-prefix scan, it cannot stop at the first match, because a longer qualifying prefix may appear later.

Then another possibility came up: what if I begin with the entire array and work backward? The full-array sum is the longest prefix sum. If it qualifies, I am done immediately. If it does not, I can remove the final element from the running sum to obtain the next-shorter prefix sum, without recomputing each prefix from scratch.

That was the next direction to explore, but we stopped there. I want to leave it as the point where the discussion actually paused, rather than manufacture a more elaborate discovery we had not yet worked through together.

What I am taking away

The most useful part of this exploration was not the Go code. It was watching the meaning of the problem change as I questioned what the search actually needed.

At first, I had an ordered list and wanted to find a number. I chose the middle because I had no justified model for the numerical distribution—even after observing several values. Then I quantified the worst-case reduction, derived the logarithm, and examined how midpoint arithmetic behaves on fixed-width integers.

Duplicates forced me to distinguish “I found a matching value” from “I found where matching values begin.” That led to monotonic Boolean conditions and transition boundaries. Returning L after the search interval became empty felt strange until loop invariants made the result inevitable. Even the detour into vacuous truth mattered, because it explained why those invariants held before the very first inspection.

Finding the last occurrence revealed the reverse boundary. First and last occurrences, insertion positions, and counts turned out to be different questions answered by the same boundary-search mechanism with different predicates.

Finally, unsorted arrays and negative prefix sums revealed both the power and the limit of the abstraction. Sorting is one way to obtain the necessary structure, but not the essence of the method. The essence is a predicate whose behavior lets an observation rule out an entire region with certainty. When that proof is missing, we should not use the search simply because its code is familiar.

I started with a number and a midpoint. I ended up thinking in terms of information, elimination, invariants, and boundaries.

That feels like a more durable understanding of binary search than memorizing any one implementation.