Loop invariants

A loop invariant is a condition that is true at the beginning and end of every iteration of a loop. The concept is similar to a class invariant, which must be true at the beginning and end of every public method. When you write a loop that works correctly, you are at least implicitly relying on a loop invariant. Knowing what a loop invariant is and thinking explicitly about loop invariants will help you write correct, efficient code that implements tricky algorithms.

Binary search via iteration

Suppose we want to find an element in a sorted array. We can do much better than scanning from left to right: we can use binary search. Here is the binary search algorithm, written as a loop.

binary_search.java

Conceptually, this algorithm is simple. But it is deceptively tricky to get exactly right. How do we know we got the computation of m right? Why is it k <= a[m] and not k < a[m]? Why m and m+1 in the two updates to r and l respectively? If we change any of these decisions, the algorithm is incorrect and will sometimes fail to find the correct element.

Binary search loop invariant

To convince ourselves that we wrote the correct code, we need a loop invariant that describes the conditions that we want the loop body to preserve. For this example, our loop invariant has three clauses:

1. The array a is sorted in ascending order.
2. 0 ≤ l ≤ r ≤ a.length-1
3. k ∈ a[l..r]

We use the notation i..j to denote the set or sequence {x | i ≤ x ≤ j} or (i,i+1,...,j-1,j). We use the notation a[i..j] to denote the subsequence of the array a starting from a[i] and continuing up to and including a[j].

If we have a loop and we know what the loop invariant is for that loop, it is often a good idea to document it. In fact, we can document it in a checkable way by using an assert statement that is executed on every loop iteration.

Using loop invariants to show code is correct

Loop invariants can help us convince ourselves that our code, especially tricky code, is correct. They also help us develop code that is correct in the first place, and they help us write efficient code.

To use a loop invariant to argue that code does what we want, we use the following steps:

1. Establishment (aka Initialization). Show that the loop invariant is true just after loop initialization. For while loops while (guard) { body }, the invariant must be true before entering the loop body. For for loops for (init; guard; incr) { body }, the invariant mmust be true just after executing init.
2. Preservation. Show that whenever both the loop invariant and the guard are true just before executing the loop body, then the loop invariant is true just after executing the loop body. Note that the loop invariant may fail to be true at intermediate steps during the execution of the loop body, as long as it is reestablished by the end. (For for loops, the loop body also includes the increment incr.)
3. Postcondition. Show that if the guard is false (so the loop exits) and the loop invariant holds, then the desired result of the loop has been achieved.

Other than coming up with the loop invariant in the first place, the Preservation step is typically the most challenging. The Postcondition step is a crucial step too. If the chosen loop invariant is too weak, this step will not be possible. Defining a too-weak invariant is a common mistake, so it is good to try the Postcondition step early.

These three steps allow us to conclude that the loop satisfies partial correctness, which means that if the loop terminates, it will succeed. To show total correctness, we must show in addition that the loop eventually terminates. To show this, there is a fourth step:

4. Termination. Assuming the loop invariant holds at the start of each iteration, show that some quantity strictly decreases, and that it cannot decrease indefinitely. This quantity is called the decrementing function or loop variant. If we call the decrementing function DF, we need to show that if the loop guard is true, then the value of DF after the loop body (call it DF') is strictly less than it was at the beginning: DF' < DF. Further, we need to come up with some minimal value DF₀ such that if DF < DF₀, then either the loop guard or the loop invariant is false. Since DF decreases on every step, it will eventually be less than DF₀, and in that case the loop cannot still be running.

Let's try these four steps on the binary search algorithm.

1. Initialization.

   The loop invariant has three clauses; we can argue that each one holds:

   1. That array a is sorted is in the precondition of search.
   2. Since a.length is at least 1 by the precondition that k is in the array, and since initially l = 0 and r = a.length-1, we have 0 ≤ l ≤ r ≤ a.length-1.
   3. k ∈ a[l..r] because that is the whole array and the precondition guarantees that k is there.

2. Preservation.

   Since the loop doesn't change the array, clearly the first clause of the invariant is preserved. Arguing the remaining clauses is a bit trickier.

   We use l', r' to represent the values of l, r at the end of the loop. We want to show that if the invariant is true at the beginning of the loop body, that is, if 0 ≤ l ≤ r ≤ a.length-1 and k ∈ a[l..r], then clauses 2 and 3 are true at the end of the loop body, that is, 0 ≤ l' ≤ r' ≤ a.length-1 and k ∈ a[l'..r'].

   Note that m is the average of l and r, rounded down. So we know that l ≤ m ≤ r. In fact, because the loop guard l < r is true and the value of m is rounded down, we know something stronger: l ≤ m < r.

   How the loop body executes depends on the outcome of the test k <= a[m]. There are two cases to consider: either k <= a[m] or k > a[m]. We analyze the two cases separately.

   • Case k <= a[m]:

     In this case we have l' = l and r' = m. Since we have 0 ≤ l ≤ m < r ≤ a.length-1 as just argued, clause 2 is preserved: 0 ≤ l' ≤ r' ≤ a.length-1.

     How about clause 3? By the loop invariant, we know that k occurs at least once in a[l..r]. Since k <= a[m], it must occur at or before index m. Therefore we have k∈a[l..m] = a[l'..r'], as required.

   • Case k > a[m]:

     Clause 2. In this case, the loop body sets r' = r and l' = m+1. We know m < r, so l' = m + 1 ≤ r = r'. Therefore, we have 0 ≤ l' ≤ r' ≤ a.length-1

     Clause 3. Since the array is sorted, k cannot be located in a[l..m]. But according to the invariant, it is in a[l..r]. Therefore, k is in a[m+1..r] = a[l'..r'], as required.

3. Postcondition.

   For the algorithm to be correct, we need a[l] = k. If the loop guard is false, we know l ≥ r. But the invariant (2) guarantees l ≤ r, so we must have l = r. We know from the invariant (3) that k ∈ a[l..r], which has been reduced to a single element, so that must be where k is.

4. Termination.

   The value DF = r − l is guaranteed by the invariant (1) to be nonnegative: we can choose DF₀ = 0. In the case where k ∈ a[l..m], we know m < r, so r' − l' < r − l. In the other case, we know l < m+1, so again, r' − l' < r − l. Thus the quantity r − l gets strictly smaller on every loop iteration as long as l < r. Therefore, the loop eventually terminates.

In this case, the loop invariant has three clauses, but it is easy to leave things out of the loop invariant. If clauses are omitted, the invariant may be too weak: Initialization is easier to argue, but it becomes impossible to show Preservation or Postcondition. On the other hand, if the loop invariant is too strong because it contains clauses that shouldn't be there, then Initialization or Preservation become impossible to show.

Let's consider what would have happened had we omitted any of the three clauses from the binary search loop invariant:

1. If we didn't know the array was sorted, our reasoning about where the element k was would fail.

2. l ≤ r
   Without this clause, we don't know that we are going to the correct side when we split on m. The Termination argument also fails because the decrementing function is no longer guaranteed to be nonnegative.

3. k ∈ a[l..r]
   Without this clause, we don't know that the loop has found anything when it terminates, so Postcondition fails.

Example: Exponentiation by squaring and multiplication

Here is an implementation of exponentiation that is efficient but whose correctness is not immediately apparent.

Pow.java

Intuitively, this algorithm converts the exponent e into a binary representation, which we can think of as a sum of powers of 2. So e = 2^k₁ + 2^k₂ + ··· and x^e = x^{2k₁+2k₂+···} = x^2k₁·x^2k₂···. (Note that x^2k always means x^(2k), never (x²)^k.)

For example, if e = 11010 in binary, then x^e = x¹¹⁰¹⁰ = x^{10000+1000+10} = x¹⁰⁰⁰⁰·x¹⁰⁰⁰·x¹⁰.

By repeatedly halving y and inspecting the resulting parity, the algorithm finds each of the “1 digits” in the binary representation of e, corresponding to the terms 2^k_i, and for such a digit at position k, multiplies into r the appropriate factor x^2k. That is the intuition, but the loop invariant will help convince us that it really does work. The loop invariant captures that part of the final result has been transferred into r and what remains to be multiplied into the result is b^y.

Let's consider the four steps outlined above.

1. Establishment.

   Initially, r=1, b=x and y=e, so trivially we have r·b^y = x^e. Also y ≥ 0 since initially y = e and e ≥ 0 as a precondition.

2. Preservation.

   Let us use y', b', and r' to refer to the values of these variables at the end of the loop. We need to show that if y > 0 and r·b^y = x^e at the beginning of the loop body, then y' ≥ 0 and r'·b'^y' = x^e at the end of the loop body. It suffices to show that if y > 0, then r'·b'^y' = r·b^y and y' ≥ 0. There are two cases to consider:

   • Case: y is even. In this case, r' = r, y' = y/2, and b'= b². Therefore, r'·b'^y' = r·(b²)^y/2 = r·b^y, as desired.

   • Case: y is odd. Here we have r'=r·b, y' = (y-1)/2, and b' = b². Therefore, r'·b'^y' = r·b·(b²)^(y-1)/2 = r·b·b^y-1 = r·b^y, again.

   In either case, y' ≥ 0, since halving a positive number cannot make it negative.

3. Postcondition.

   If the loop guard is false, then y = 0, since y ≥ 0 and not y > 0. But if y = 0, then r = r·b^y = x^e, and that is the return value.

4. Termination.

   Dividing by two makes the quantity y strictly smaller on every loop iteration, because it is always nonnegative (this is a part of the loop invariant). It can never become negative, so eventually it will become zero and the loop will terminate.

Therefore, the loop terminates and returns the correct value of x^e.

Example: Insertion sort

insertion_sort.java

There are two loops, hence two loop invariants. These loop invariants can be visualized with the following diagram:

Notice that the loop invariant holds in for loops at the point when the loop guard (i.e., i < a.length) is evaluated, and not necessarily at the point when the for statement starts executing. That is, the initialization expression in the for statement can help establish the loop invariant.

Debugging and choosing loop invariants

There are two things that typically go wrong when choosing a loop invariant. The most common error is to define a loop invariant that is too weak. This error usually shows up when trying to take the Postcondition step. If the loop invariant is too weak, we can't argue that the loop achieves whatever it is supposed to. Alternatively, sometimes a too-weak invariant will show up in the Preservation step, because the too-weak loop invariant does not restrict the state enough to show that even it is preserved by the loop.

If a loop invariant is too strong, that error typically shows up when one tries to prove Preservation: the strong loop invariant simply isn't preserved by executing the loop body. It is also possible for this error to show up in the Establishment step, if the putative loop invariant doesn't even hold at the start of the loop.

Choosing loop invariants is a bit of an art, but becomes easier with practice. The key is that a loop invariant really does capture the core reason why the loop works. So imagine trying to explain to someone why the loop works, and write down conditions that capture that explanation.

Recall that the loop invariant must be implied by the loop precondition and it must imply the loop postcondition; another way to think about the loop invariant is that it interpolates between the precondition and postcondition. It can be helpful to write down both the precondition and the postcondition together, and then to try to come up with a logical statement that captures both of them. It should generalize both the precondition and the postcondition, but be close to the precondition as the loop starts and close to the postcondition when it ends. For example, in the binary search algorithm, that we want k = a[l] at the end and we have k ∈ a[0..a.length-1] at the beginning. The statement k ∈ a[l..r] generalizes both of these assertions.

Loop invariants in software engineering

Loop invariants capture key facts that explain why code works. If you write code in which the loop invariant is not obvious, you should add a comment that gives the loop invariant. This helps other programmers understand the code, and helps keep them (and you!) from accidentally breaking the invariant with future changes.

It also makes sense to add assert statements that for every iteration check the parts of the loop invariant that are easy to check. Such assertions will catch errors early and expose problems with your understanding of why the code works.