I have had Dijkstra's book for many years, and love it. It's a great read, and it should be reprinted or put into the public domain.
http://www.alibris.com/A-Discipline-of-Programming-Edward-W-...
I'm curious. Is this like a "supper vs dinner" or "pop vs soda" variation that depends on the region your university is located?
[1] http://cstheory.stackexchange.com/questions/1521/origins-and...
I admit I liked the recursive version of the author's example better, though, especially when he gets into "oldr" and "newr" to track the mutated state of things in each loop pass.
Along a similar line, I remember reading on my own about Eiffel and "class invariants" in the very early 90s.
Then came the internet gold rush to dumb things down, though. Now, we have King Java and its idiotic "bean" anti-pattern. Just make a useless crap object, whack on it enough (mutate it) until you hope it's in a useful state and slog onward! State of the art brain damage :-(
In the previous article, the closest thing to an explanation or definition of a loop invariant is, "We can make it less so by writing down a specific claim that applies to our particular loop. Such a claim is called a loop invariant." Not a very good description, and he doesn't try to do any better elsewhere.
I ended up having to do a bunch of googling after reading the articles to piece together what is trying to be explained, since I had never heard of loop invariants in that terminology either.
Simply put, a loop invariant is a condition or set of conditions that is true through the loop. This makes it akin to inductive proofs. The loop invariant must prove true for n and n+1 for it to be true for the entirety of the loop. Noting how similar this is to inductive reasoning, you can apply an inductive proof to a loop invariant to prove it.
The easiest way I've seen to explain it is in the body of the executing loop you ask yourself, "What has the loop done so far." An answer to that question should yield a loop invariant.