A loop invariant is a condition that is necessarily true immediately before and immediately after each iteration of a loop. (Note that this says nothing about its truth or falsity part way through an iteration.)

For example, in Java, a `while` loop has the following form, where
`B` is a boolean expression (that we shall call the **guard**
of the loop) and `S` is a sequence of commands/instructions
(that we shall call the **body** of the loop).

while (B) { S }

A flow chart that indicates the steps taken in executing such a loop is as follows:

+-------+ | start | +-------+ | | <--- Q (the precondition) holds here (assumption) | +-------------------------> | <--- P (the invariant) holds here (every time) | | | | | / \ | / \ | true / B \ false | +<------ \ / -------->+ | P & B ---->| \ / | | holds | \ / | <---- P & !B holds here | here v | | +---+ | <---- R (postcondition) | | S | v is to hold here | +---+ +------+ | | | stop | | | +------+ +<--------------+

**Note:** In what follows, we assume that evaluation of `B` has no
"side effects" (i.e., results in no changes to values of variables in the
program). **End of note.**

The flow chart is annotated to indicate the "locations" at which

- we assume that the precondition Q holds,
- we want the postcondition R to hold, and
- we want the loop invariant P to hold.

(i.e., the truth of `P` together with the falsity of the loop's guard,
`B`, guarantees the truth of `R`). Why? Because then we can
be sure that, when the loop terminates (at which point `P&!B`
must hold), `R`, too, must hold, as desired.

**How do you show that an invariant really is one?**

A question that may have occurred to you is this: How do you show that a
chosen `P` is actually true every time execution reaches the
critical location? Usually, it is done as follows:

First, you show that `Q ==> P` (i.e., the truth of the precondition
guarantees the truth of `P`), from which you may conclude that
`P` holds the first time execution reaches the critical location.

Second, you show that `P` holds each subsequent time the critical
location is reached. To accomplish this, it suffices to show that,
if `S` (the loop body) is executed beginning in a state in which
`P&B` holds, then `P` will necessarily hold when
`S` is finished executing. (Of course, this corresponds to
showing that `{P & B} S {P}` is a valid Hoare Triple.)

In effect, this amounts to a proof by mathematical induction on the number
of loop iterations executed. The first step is the base case, which shows
that `P` holds the first time execution reaches the critical location
(i.e., after zero iterations). The second step is the inductive step,
in which it is shown that, if, for any positive number *n*,
`P` holds the *n*-th time execution reaches the critical spot
(i.e., after the *(n-1)*-st iteration), then it must also hold the
(*n+1*)-st time (i.e., after the *n*-th iteration).

**How do you show that a loop terminates?**

To show that a loop terminates after finitely many iterations, we show that
each iteration *makes progress towards termination* in some way.
Technically, this amounts to showing that there is some integer function of
the program variables that

- decreases on each iteration and
- is such that the function's value must be greater than zero
in order for another loop iteration to occur (or, equivalently,
the truth of
`P&B`guarantees that the function's value is greater than zero).

For example, take the following loop:

Then, taking *g* to be the function defined by the expression
`n-i`, we have that the value of *g* decreases on
each iteration (due to the fact that `i` increases on
each iteration but `n` stays the same).
We also have, as required, that the truth of the loop guard,
`i<n`, guarantees that the value of *g* exceeds zero.

To illustrate the usefulness of the loop invariant concept, we discuss a few amusing puzzles.

while (# of marbles in the jar > 1) { choose (any) two marbles from the jar; if (the two marbles are of the same color) { toss them aside; place a RED marble into the jar; } else { // one marble of each color was chosen toss the chosen RED marble aside; place the chosen BLUE marble back into the jar; } }By examining the procedure, you can easily verify that the number of marbles in the jar decreases by exactly one on each iteration of the loop. Thus, if initially the jar contained N marbles, then after N-1 iterations of the loop, exactly one marble will remain. What we have just done is to make a persuasive, but informal, argument that the loop terminates after finitely many iterations. To be a bit more precise, we could explicitly define

Suppose we know how many RED and BLUE marbles were in the jar, initially. Armed with that information, can we predict, with certainty, the color of the last marble remaining in the jar? (Note that, by virtue of the assumption that the jar was initially non-empty and the fact that the number of marbles decreases by exactly one on each iteration, it is not possible to end up with an empty jar.)

To state it more formally:

Does there exist a function *f*: N × N --> {BLUE, RED}
(meaning that the domain of *f* is the set of ordered pairs of
natural numbers and the range is the set {BLUE, RED}) that satisfies
the following condition:

For allKandM(such that at least one of them is non-zero), if we begin withKRED marbles andMBLUE marbles in the jar, then the last marble remaining in the jar is necessarily of colorf(K,M).

It turns out that such a function exists! The key to identifying it is to first identify an invariant of the loop having to do with the number of BLUE marbles in the jar.

Consider the effect that a single iteration of the loop has upon the number of BLUE marbles in the jar. In the case that both marbles chosen were of the same color, the number of BLUE marbles either decreases by two (if both marbles chosen were BLUE) or stays the same (if both marbles chosen were RED). In the case that the marbles chosen were of different colors, the number of BLUE marbles remains the same.

It follows that a single loop iteration has no effect upon whether the number
of BLUE marbles is odd or even. (That is, the number of BLUE marbles in the
jar either remains odd or remains even as a result of the execution of a
single iteration of the loop.) But then the same property holds with
respect to any number of iterations of the loop.
Letting *M* and *m* denote,
respectively, the number of BLUE marbles occupying the jar originally and
currently, respectively, we conclude that

is an invariant of the loop. In case you find it easier to comprehend, a different way of expressing this loop invariant is

Suppose that, initially, the number of BLUE marbles in the jar,
*M*, were odd, and that the loop has just terminated.
(And recall that, because a loop invariant holds at the end of every
iteration, it holds, in particular, at the end of the last iteration.)
Then the lone marble remaining in the jar must be BLUE, because otherwise
we'd have *m = 0*, which is even.
By a similar argument, we conclude that, if *M* were even, then
the remaining marble must be RED, because otherwise we'd have
*m = 1*, which is odd.

Thus, the function *f* mentioned above is as follows:

Interestingly, the color of the last remaining marble does not depend at all upon the number of RED marbles initially in the jar.f(K,M)= { RED ifMis even { BLUE otherwise (i.e., ifMis odd)

6 . . . . . . . 5 . . . . . . . 4 . . . . . . . 3 . . . . . . . 2 . . . . . . . 1 . . . . . . . 1 2 3 4 5 6 7The rows and columns have been numbered so that we can refer to the point in row i and column j using the ordered pair (i,j).

Red and Blue take alternating turns, with Red going first. Red takes a turn by drawing a red line segment, either horizontal or vertical, connecting any two adjacent points on the grid that are not yet connected by any line segment. Blue takes a turn by doing the same thing, except that the line segment drawn is blue. Red's goal is to form a closed curve (i.e., a sequence of (three or more) distinct line segments starting at some point and returning to that point) comprised entirely of red line segments. Blue's goal is to prevent Red from doing so. The game ends when either Red has formed a closed curve or there are no more line segments to draw.

Making an analogy with a computer program, we can view the game as follows:

while (more line segments can be drawn) { Red draws line segment; Blue draws line segment; }(For simplicity, we have assumed that the # of possible line segments is even; otherwise the game might end with a RED line being drawn.)

**Question:** Does either Red or Blue have a "winning strategy", i.e., a
game plan that, if followed faithfully, guarantees victory?

**Answer:** Yes! Blue is guaranteed to win the game by responding to each
turn by Red in the following manner:

if (Red drew a horizontal line segment) { let i and j be such that Red's line segment connects (i,j) with (i,j+1) if (i>1) { draw a vertical line segment connecting (i-1,j+1) with (i,j+1) } else { draw a line segment anywhere } } else // Red drew a vertical line segment let i and j be such that Red's line segment connects (i,j) with (i+1,j) if (j>1) { draw a horizontal line segment connecting (i+1,j-1) with (i+1,j) } else { draw a line segment anywhere } }Informally, Blue responds to Red by making sure that the line segment just drawn by Red can never occur as one of the two line segments forming an "upper right corner" of a closed curve of red segments. Note that any closed curve of red line segments must include at least one such corner. Thus, if Blue adheres to this strategy, Red can never form a closed curve!

Assuming that Blue follows this strategy, the following statement is true after each step in the playing of the game:

There does not exist on the grid a pair of red line segments that form an upper right corner.

That is, the above statement is an invariant (assuming Blue follows the specified strategy) with respect to the playing of the game.

Of course, there is nothing special about upper right corners. Blue could have just as easily chosen to prevent Red from forming any of the other three kinds of corners instead. Significantly, when the game ends (i.e., the loop terminates), the invariant will hold, and Red will not have formed an upper right corner. Which means that Red must not have won, so Blue must have won.

**Question:** Does either player have a winning strategy?

**Answer:** Left as an exercise for the reader.

Now for some examples that come from computer programming.

Very often, an effective approach for writing a program with postcondition
`R` is to develop a loop having as an invariant an expression
`P`, where `P` is obtained from `R` by
replacing a constant by a variable. In this example, we might replace
`n` (which is a constant in the sense that it is an input
value not subject to being changed) by `k`,
thereby obtaining as a (candidate) loop invariant

The idea is to develop a loop, having `P` as an invariant,
in which `k` will be modified so that it eventually reaches
the same value as `n`. By making `k!=n`
the guard of the loop, we design it so that at the point when `k`'s
value becomes equal to `n`, the loop will terminate with both
`P` and `k=n` being true, guaranteeing that
`R` will be true, too.
Why? Because if both

are true, then so must be

(This is just an instance of the general rule that says from
`A` and `x=y` we can conclude `A'`,
where `A'` is `A` with one or more occurrences of
`x` replaced by `y`.)

Before giving the first version of our program, we introduce the notion of
**textual substitution**: For expressions `E` and `F`
and a variable `x`, we use the notation

to refer to the expression we get by replacing every (free) occurrence of
`x` in `E` by `F`. For example,

Our "program skeleton" is as follows:

// {precondition: n >= 0, where n is the input value} k = 0; < code to establish P(k:=0): sum == 1 + ... + 0 > // {loop invariant P: sum == 1 + 2 + ... + k} while (k != n) { < code to establish P(k := k+1): sum == 1 + ... + k + (k+1) > k = k+1; // increment k to re-establish P : sum == 1 + 2 + ... + k } // {postcondition: sum = 1 + 2 + ... + n}

We chose to increment `k` at the end of the loop body rather than at
the beginning. Sometimes one choice works better than the other; sometimes
it makes little difference.

To establish `P(k:=0)` is easy: simply initialize `sum` to
`0`.

In order to establish `P(k:=k+1)` (i.e.,
`sum = 1 + 2 + ... + k + (k+1)`) inside the loop,
it suffices to add `k+1` to `sum`.
(The invariant tells us that the value of `sum` is already
`1 + 2 + ... + k`, so to make `sum` equal to
`1 + 2 + ... + k + (k+1)` requires adding `k+1` to it!)

Having established `P(k:=k+1)`, in order to re-establish
`P` it suffices to increment `k` (so that `k`
takes on the value that immediately before had been one more than
`k`).

The resulting program is as follows:

// {precondition: n >= 0} k = 0; sum = 0; // {loop invariant P: sum == 1 + ... + k} while (k != n) { sum = sum + (k+1); // {sum == 1 + ... + k + (k+1) (i.e., P(k:=k+1))} k = k+1; // {sum == 1 + ... + k (i.e., P)} } // {k = n & sum == 1 + 2 + ... + k} // {postcondition: sum == 1 + 2 + ... + n (follows from line above)}

This illustrates the fact that the best solution is often not
the most obvious one!
**End of note.**

Suppose we have an array `a[0..n-1]` (where `n>0`)
of, say, integers, and we want to determine the maximum among the values
in `a[]`. Using `maxVal` as the output variable,
the desired postcondition is

For brevity, henceforth we shall abbreviate the array segment
`<a[0], a[1], ..., a[k]>` by `a[0..k]`.)
Using the approach described above, we replace "constant" `n`
in the postcondition by variable `k` in order to obtain
`P: maxVal == Max(a[0..k-1])` as a candidate for a loop
invariant. This leads us to propose the following program skeleton:

// {precondition: a.length > 0} k = 1; < code to establish P(k:=1): maxVal == Max(a[0..0]) > // {loop invariant P: maxVal == Max(a[0..k-1])} while ( k != n ) { < code to establish P(k:=k+1): maxVal == Max(a[0..k]) > k = k+1; // re-establishes P } // { maxVal == Max(a[0..k-1]) & k == n } // {postcondition R: maxVal == Max(a[0..n-1]) follows from above}

Having set `k` to `1`, to establish `P(k:=1)`
requires simply that `maxVal` be initialized to the maximum of
`a[0..0]`, which is obviously `a[0]` itself.

As for establishing `P(k:=k+1)` inside the loop before incrementing
`k`, consider that, at this point, we have `P`
(i.e., `maxVal == Max(a[0..k-1])`) and that we want to change
`maxVal` to establish `maxVal == Max(a[0..k])`.

How are `Max(a[0..k-1])` and `Max(a[0..k])` related?
Given that `a[0..k-1]` and `a[0..k]` are the same,
except for the latter containing one extra element,
---namely, `a[k]`---
clearly the only difference is this: if `a[k]` is bigger
than the maximum element in `a[0..k-1]`,
it is the maximum of `a[0..k]`;
otherwise, the maximum of the two array segments is the same.
So we refine our program to get

k = 1; maxVal = a[0]; // {P(k:=1): maxVal == Max(a[0..0])} // {loop invariant P: maxVal == Max(a[0..k-1])} while (k != n) { if ( a[k] > Max(a[0..k-1]) ) { maxVal = a[k]; } else { maxVal = Max(a[0..k-1]); } // {P(k:=k+1): maxVal == Max(a[0..k])} k = k+1; // {P: maxVal == Max(a[0..k-1])} } // { maxVal == Max(a[0..k-1]) & k == n } // {postcondition: maxVal == Max(a[0..n-1])}By the fact that

k = 1; maxVal = a[0]; // {loop invariant P: maxVal == Max(a[0..k-1]) } while (k != n) { if ( a[k] > maxVal ) { maxVal = a[k]; } else { maxVal = maxVal; } // {P(k:=k+1): maxVal == Max(a[0..k])} k = k+1; // re-establishes P } // {maxVal == Max(a[0..k-1]) & k == n} // {postcondition: maxVal == Max(a[0..n-1]) (follows from above)}

Because the body of the else part has no net effect, we can omit it (or
replace it by a statement that has no effect, such as `{ }` in Java),
giving us as the final program:

k = 1; maxVal = a[0]; // {loop invariant P: maxVal == Max(a[0..k-1])} while (k != n) { if (a[k] > maxVal) { maxVal = a[k]; } // {P(k:=k+1): maxVal == Max(a[0..k])} k = k+1; // re-establishes P } // { maxVal == Max(a[0..k-1]) & k == n } // {postcondition: maxVal == Max(a[0..n-1]) }

Given an array `a[0..N-1]` each of whose elements can be classified
as either RED or BLUE, rearrange `a[]`'s elements (via swapping,
but no other operation) so that all occurrences of RED come before all
occurrences of BLUE and so that the variable `k` indicates the
boundary between the RED and BLUE regions.

In picture form, the desired postcondition `R` is

0 k N +-----------------+----------------+ a | all RED | all BLUE | +-----------------+----------------+That is,

It is fairly obvious that any solution will involve a loop.
In order to obtain candidates for the loop's invariant and guard, we
first rewrite the postcondition `R` as the slightly stronger

Note that `R'` is obtained from `R` simply by replacing
`N` by `m` in the second conjunct and adding
`m = N` as a new third conjunct. It should be clear to the reader
that any state satisfying `R'` also satisfies `R`.

As a loop guard `B`, we propose using `m != N`, which is simply
the negation of the third conjunct of `R'`.
As a loop invariant `P`, we propose using the rest of `R'`
(i.e., its first two conjuncts).
That gives us

which, as a picture, looks like this:

0 k m n +------------+-------------+-----------+ a | all RED | all BLUE | ? | +------------+-------------+-----------+

Notice how these choices for `P` (the loop invariant) and
`B` (the loop guard) automatically give us

which is vital in showing that, when the loop terminates, the postcondition holds.

Notice also that `P` says nothing about the contents of array segment
`a[m..n-1]`, which is why we label it in the picture by **?**
(which is supposed to suggest that we don't know what's there).

Given the above, we sketch our solution as follows:

k = ?; m = ?; // initialize k and m to truthify P // { invariant P : a[0..k-1] is all RED & a[k..m-1] is all BLUE } while ( m != N ) { < code to preserve P while also making progress toward termination > } // { P & m == n, from which R' follows, from which R follows }

As is true in our example, almost every loop is immediately preceded by a small segment of code in which one or more variables must be initialized. The aim of such a code segment is to ensure that, after it has executed, the loop invariant will have been truthified (i.e., been made true).

So let us consider to which values our variables `k` and
`m` should be initialized.
Recall that the loop invariant requires that all elements in the
segment `a[0..k-1]` be RED and that all elements in
`a[k..m-1]` be BLUE. As we have no way of knowing
---before examining any of the array's elements---
which colors they might have, the only way that we can ensure
that every element in these two segments is of the right color
is to give values to `k` and `m` making those segments
empty!!

To make `a[0..k-1]` empty, we set `k` to zero.
Given that choice, in order to make `a[k..m-1]` empty we
have little choice but to set `m` to zero as well.
(The result, of course, is that the RED and BLUE segments are empty
and the ? segment occupies the entire array!)

Our still rather sketchy solution has advanced to:

k = 0; m = 0; // initialize k and m to truthify P // { invariant P : a[0..k-1] is all RED & a[k..m-1] is all BLUE } while ( m != N ) { < code to preserve P while also making progress toward termination > } // { P & m == n, from which R' follows, from which R follows }

At this point we observe that, since `m` is initialized to zero
and must finish with value `N` (in order to falsify the loop guard,
thereby causing it to terminate), it would seem that a reasonable way
to achieve the goal of "making progress toward termination" on each iteration
would be for the body of the loop to cause `m`'s value to increase.
The most obvious way to increase `m`'s value is to increment it.
Assuming (as is often the case) that this is done as the last step in the
body of the loop, we get:

k = 0; m = 0; // initialize k and m to truthify P // { invariant P : a[0..k-1] is all RED & a[k..m-1] is all BLUE } while ( m != N ) { < code to establish P(m:=m+1) : a[0..k-1] is all RED & a[k..m] is all BLUE > m = m+1; } // { P & m == n, from which R' follows, from which R follows }

**Question:** How to establish `P(m:=m+1)` before incrementing
`m`?

**Answer:** Examine `a[m]`. If it is BLUE, we conclude
that `a[k..m]` is all BLUE. (Recall that the invariant tells us
that `a[k..m-1]` is all BLUE.) The loop invariant also tells us
that `a[0..k-1]` is all RED. But these two facts together are
simply `P(m:=m+1)`, which is to say that `P(m:=m+1)`
already holds and hence in this case we need do nothing.

If, on the other hand, `a[m]` is RED,
swap `a[k]` with `a[m]` (so that `a[m]` gets
put alongside other RED elements), the effect of which is to extend
the RED region to the right one position and to shift the BLUE region
one position to the right. That is, this leaves us with
`a[0..k]` being RED and `a[k+1..m]` being BLUE,
which corresponds to `P(k,m := k+1,m+1)`.
By incrementing `k`, we establish `P(m:=m+1)`,
as desired.

Assuming the existence of a static method called `swap` whereby
the call `swap(b,i,j)` swaps the values of `b[i]` and
`b[j]`, we get this final solution:

m = 0; k = 0; // initialize k to establish P(m:=0) // { invariant P: a[0..k-1] is all RED & a[k..m-1] is all BLUE } while (m != N) { if (a[m] is BLUE) { } else { // a[m] is RED swap(a,k,m); k = k+1; } // { P(m:=m+1) } m = m+1; // re-establishes P } // { P & m == n, from which R' follows, from which R follows }