Overview

In the Logic chapter, we looked at several ways of writing propositions, including conjunction, disjunction, and quantifiers. In this chapter, we bring a new tool into the mix: inductive definitions. There were originally two chapters on inductive propositions: this chapter (IndProp) and IndProp2. But in the interests of covering other, important material, we've condensed the two into one file. The optional exercises here are especially worthwhile. We'll continue our implementation of natsets, too, proving that they actually represent sets. Recall that we have seen two ways of stating that a number n is even: We can say (1) evenb n = true, or (2) ∃ k, n = double k. Yet another possibility is to say that n is even if we can establish its evenness from the following rules:

• Rule ev_0: The number 0 is even.
• Rule ev_SS: If n is even, then S (S n) is even.

To illustrate how this definition of evenness works, let's imagine using it to show that 4 is even. By rule ev_SS, it suffices to show that 2 is even. This, in turn, is again guaranteed by rule ev_SS, as long as we can show that 0 is even. But this last fact follows directly from the ev_0 rule. We will see many definitions like this one during the rest of the course. For purposes of informal discussions, it is helpful to have a lightweight notation that makes them easy to read and write. Inference rules are one such notation:

	(ev_0)
ev 0

ev n	(ev_SS)
ev (S (S n))

Each of the textual rules above is reformatted here as an inference rule; the intended reading is that, if the premises above the line all hold, then the conclusion below the line follows. For example, the rule ev_SS says that, if n satisfies ev, then S (S n) also does. If a rule has no premises above the line, then its conclusion holds unconditionally. We can represent a proof using these rules by combining rule applications into a proof tree. Here's how we might transcribe the above proof that 4 is even:
                             ------ (ev_0)
                              ev 0
                             ------ (ev_SS)
                              ev 2
                             ------ (ev_SS)
                              ev 4

Why call this a "tree" (rather than a "stack", for example)? Because, in general, inference rules can have multiple premises. We will see examples of this below. Putting all of this together, we can translate the definition of evenness into a formal Coq definition using an Inductive declaration, where each constructor corresponds to an inference rule:

This definition is different in one crucial respect from previous uses of Inductive: its result is not a Type, but rather a function from nat to Prop -- that is, a property of numbers. Note that we've already seen other inductive definitions that result in functions, such as list, whose type is Type → Type. What is new here is that, because the nat argument of ev appears unnamed, to the right of the colon, it is allowed to take different values in the types of different constructors: 0 in the type of ev_0 and S (S n) in the type of ev_SS. In contrast, the definition of list names the X parameter globally, to the left of the colon, forcing the result of nil and cons to be the same (list X). Had we tried to bring nat to the left in defining ev, we would have seen an error:

("Parameter" here is Coq jargon for an argument on the left of the colon in an Inductive definition; "index" is used to refer to arguments on the right of the colon.) We can think of the definition of ev as defining a Coq property ev : nat → Prop, together with primitive theorems ev_0 : ev 0 and ev_SS : ∀ n, ev n → ev (S (S n)). Such "constructor theorems" have the same status as proven theorems. In particular, we can use Coq's apply tactic with the rule names to prove ev for particular numbers...

... or we can use function application syntax:

We can also prove theorems that have hypotheses involving ev.

More generally, we can show that any number multiplied by 2 is even:

Exercise: 1 star, standard (ev_double)

Using Evidence in Proofs

Besides constructing evidence that numbers are even, we can also reason about such evidence. Introducing ev with an Inductive declaration tells Coq not only that the constructors ev_0 and ev_SS are valid ways to build evidence that some number is even, but also that these two constructors are the only ways to build evidence that numbers are even (in the sense of ev). In other words, if someone gives us evidence E for the assertion ev n, then we know that E must have one of two shapes:

• E is ev_0 (and n is O), or
• E is ev_SS n' E' (and n is S (S n'), where E' is evidence for ev n').

This suggests that it should be possible to analyze a hypothesis of the form ev n much as we do inductively defined data structures; in particular, it should be possible to argue by induction and case analysis on such evidence. Let's look at a few examples to see what this means in practice.

Inversion on Evidence

Suppose we are proving some fact involving a number n, and we are given ev n as a hypothesis. We already know how to perform case analysis on n using the inversion tactic, generating separate subgoals for the case where n = O and the case where n = S n' for some n'. But for some proofs we may instead want to analyze the evidence that ev n directly. By the definition of ev, there are two cases to consider:

• If the evidence is of the form ev_0, we know that n = 0.
• Otherwise, the evidence must have the form ev_SS n' E', where n = S (S n') and E' is evidence for ev n'.

The following theorem can easily be proved using destruct on evidence.

However, this variation cannot easily be handled with just destruct.

Intuitively, we know that evidence for the hypothesis cannot consist just of the ev_0 constructor, since O and S are different constructors of the type nat; hence, ev_SS is the only case that applies. Unfortunately, destruct is not smart enough to realize this, and it still generates two subgoals. Even worse, in doing so, it keeps the final goal unchanged, failing to provide any useful information for completing the proof.

What happened, exactly? Calling destruct has the effect of replacing all occurrences of the property argument by the values that correspond to each constructor. This is enough in the case of ev_minus2 because that argument n is mentioned directly in the final goal. However, it doesn't help in the case of evSS_ev since the term that gets replaced (S (S n)) is not mentioned anywhere. But the proof is straightforward using our inversion lemma.

Note how both proofs produce two subgoals, which correspond to the two ways of proving ev. The first subgoal is a contradiction that is discharged with discriminate. The second subgoal makes use of injection and rewrite. Coq provides a handy tactic called inversion that factors out that common pattern. The inversion tactic can detect (1) that the first case (n = 0) does not apply and (2) that the n' that appears in the ev_SS case must be the same as n. It has an "as" variant similar to destruct, allowing us to assign names rather than have Coq choose them.

The inversion tactic can apply the principle of explosion to "obviously contradictory" hypotheses involving inductively defined properties, something that takes a bit more work using our inversion lemma. For example:

Exercise: 1 star, standard (SSSSev__even)

Prove the following result using inversion.

Exercise: 1 star, standard (ev5_nonsense)

Prove the following result using inversion.

The inversion tactic does quite a bit of work. For example, when applied to an equality assumption, it does the work of both discriminate and injection. In addition, it carries out the intros and rewrites that are typically necessary in the case of injection. It can also be applied, more generally, to analyze evidence for inductively defined propositions. As examples, we'll use it to reprove some theorems from chapter Tactics. (Here we are being a bit lazy by omitting the as clause from inversion, thereby asking Coq to choose names for the variables and hypotheses that it introduces.)

Here's how inversion works in general. Suppose the name H refers to an assumption P in the current context, where P has been defined by an Inductive declaration. Then, for each of the constructors of P, inversion H generates a subgoal in which H has been replaced by the exact, specific conditions under which this constructor could have been used to prove P. Some of these subgoals will be self-contradictory; inversion throws these away. The ones that are left represent the cases that must be proved to establish the original goal. For those, inversion adds all equations into the proof context that must hold of the arguments given to P (e.g., S (S n') = n in the proof of evSS_ev). The ev_double exercise above shows that our new notion of evenness is implied by the two earlier ones (since, by even_bool_prop in chapter Logic, we already know that those are equivalent to each other). To show that all three coincide, we just need the following lemma:

We could try to proceed by case analysis or induction on n. But since ev is mentioned in a premise, this strategy would probably lead to a dead end, as in the previous section. Thus, it seems better to first try inversion on the evidence for ev. Indeed, the first case can be solved trivially.

Unfortunately, the second case is harder. We need to show ∃ k, S (S n') = double k, but the only available assumption is E', which states that ev n' holds. Since this isn't directly useful, it seems that we are stuck and that performing case analysis on E was a waste of time. If we look more closely at our second goal, however, we can see that something interesting happened: By performing case analysis on E, we were able to reduce the original result to an similar one that involves a different piece of evidence for ev: E'. More formally, we can finish our proof by showing that
        ∃ k', n' = double k',

which is the same as the original statement, but with n' instead of n. Indeed, it is not difficult to convince Coq that this intermediate result suffices.

Induction on Evidence

If this looks familiar, it is no coincidence: We've encountered similar problems in the Induction chapter, when trying to use case analysis to prove results that required induction. And once again the solution is... induction! The behavior of induction on evidence is the same as its behavior on data: It causes Coq to generate one subgoal for each constructor that could have used to build that evidence, while providing an induction hypotheses for each recursive occurrence of the property in question. Let's try our current lemma again:

Here, we can see that Coq produced an IH that corresponds to E', the single recursive occurrence of ev in its own definition. Since E' mentions n', the induction hypothesis talks about n', as opposed to n or some other number. The equivalence between the second and third definitions of evenness now follows.

As we will see in later chapters, induction on evidence is a recurring technique across many areas. The following exercises provide simple examples of this technique, to help you familiarize yourself with it.

Exercise: 2 stars, standard (ev_sum)

Exercise: 4 stars, advanced, optional (ev'_ev)

In general, there may be multiple ways of defining a property inductively. For example, here's a (slightly contrived) alternative definition for ev:

Prove that this definition is logically equivalent to the old one. (You may want to look at the previous theorem when you get to the induction step.)

Exercise: 3 stars, advanced, recommended (ev_ev__ev)

Finding the appropriate thing to do induction on is a bit tricky here:

Exercise: 3 stars, standard, optional (ev_plus_plus)

This exercise just requires applying existing lemmas. No induction or even case analysis is needed, though some of the rewriting may be tedious.

Inductive Relations

A proposition parameterized by a number (such as ev) can be thought of as a property -- i.e., it defines a subset of nat, namely those numbers for which the proposition is provable. In the same way, a two-argument proposition can be thought of as a relation -- i.e., it defines a set of pairs for which the proposition is provable.

One useful example is the "less than or equal to" relation on numbers. The following definition should be fairly intuitive. It says that there are two ways to give evidence that one number is less than or equal to another: either observe that they are the same number, or give evidence that the first is less than or equal to the predecessor of the second.

Proofs of facts about ≤ using the constructors le_n and le_S follow the same patterns as proofs about properties, like ev above. We can apply the constructors to prove ≤ goals (e.g., to show that 3<=3 or 3<=6), and we can use tactics like inversion to extract information from ≤ hypotheses in the context (e.g., to prove that (2 ≤ 1) → 2+2=5.) Here are some sanity checks on the definition. (Notice that, although these are the same kind of simple "unit tests" as we gave for the testing functions we wrote in the first few lectures, we must construct their proofs explicitly -- simpl and reflexivity don't do the job, because the proofs aren't just a matter of simplifying computations.)

The "strictly less than" relation n < m can now be defined in terms of le.

Here are a few more simple relations on numbers:

Exercise: 2 stars, standard (total_relation)

Define (in Coq) an inductive binary relation total_relation that holds between every pair of natural numbers.

Exercise: 2 stars, standard, optional (empty_relation)

Define (in Coq) an inductive binary relation empty_relation (on numbers) that never holds.

Exercise: 3 stars, standard, optional (le_exercises)

Here are a number of facts about the ≤ and < relations that we are going to need later in the course. The proofs make good practice exercises.

Hint: The next one may be easiest to prove by induction on m.

Hint: This theorem can easily be proved without using induction.

Exercise: 2 stars, standard, optional (leb_iff)

We can define three-place relations, four-place relations, etc., in just the same way as binary relations. For example, consider the following three-place relation on numbers:

Exercise: 3 stars, standard (R_fact)

The relation R above actually encodes a familiar function. Figure out which function; then state and prove this equivalence in Coq? (Only do this problem after yo've done the corresponding problem about R in the informal work.)

Reasoning about minima

As practice with ≤, we'll prove some properties about min3 and argmin3. We'll need these properties in IndProp2, when we'll show that some edit functions are 'better' than others.

Exercise: 2 stars, standard (min3_min)

Exercise: 3 stars, standard (min3_leb)

Aside: Strong Induction

So far, we've worked with a conventional induction principle on naturals:

That is, to prove P n for any n, we need to show that:

• P 0 holds (the base case), and
• if P n' holds, then P (S n') holds (the inductive case).

But there are other ways of doing induction on the naturals! The most common alternative is what's called strong induction or course of values induction.

That is, to prove P n for any n, we:

• assume that P m holds for all m < n, and then
• show that P n holds.

This principle of induction is called "strong" induction because we get a stronger inductive hypothesis. In the "weak" induction we've been doing, our IH is that P n', which we use to prove P (S n'). In "strong" induction, to prove P (S n'), our IH is that P m for every m < (S n'). Metaphorically speaking, in weak induction we build a tower of proof just using the floor beneath us: to build the S nth floor, we assume that the nth floor is on solid ground. In strong induction, we build a tower of proof using all of the floors beneath us: to build the nth floor, we can rely on the mth floor for m < n. Suppose we define a function pow : nat → nat → nat as follows:
  pow(m,0) = 1
  pow(m,n) = if n is even
             then pow(m×m,n/2)
             else m × pow(m,n-1)

We use strong induction to prove that the informal function pow defined above behaves the same as exp from Basics.v.
    Fixpoint exp (base power : nat) : nat :=
      match power with
        | O ⇒ S O
        | S p ⇒ mult base (exp base p)
      end.

We'll assume that exp (m×m) ((S n')/2), is equal to exp m (S n').

• Theorem: forall m and n, pow(m,n) = exp base power.

Proof: By strong induction on n, leaving m general. Our IH is that for all n' < n, we have pow(m, n') = exp m n'; we must show pow(m, n) = exp m n. We go by cases on n.

• If n=0, then we have exp m 0 = 1 and pow(m,0) = 1 by definition.
• If n = S n', then we have exp m (S n') = m × exp m n'. We go by cases on the parity of n.
  + If n is even, then we have pow(m, n) = pow(m×m, n/2). But by the IH on n/2 < n, pow(m×m, n/2) is equal to exp (m×m) (n/2), which is itself equal to exp m n.
  + If n is odd, then we have pow(m, S n') = m × pow(m, n'); by the IH on n' < n, we know that pow(m, n') = exp(m, n'), and we are done.

Qed. A few things to note about this proof:

• We get the IH immediately!
• We manually do a case analysis as the first step of our proof.
• When n=0, our IH is useless: there is no n' < 0!
• Whenever we apply the IH, we have to show we're applying it to a smaller number.

Strong induction is at least as strong as weak induction: we can prove the principle of weak induction using the principle of strong induction. Do NOT use the induction tactic: instead we apply the strong induction principle.

Exercise: 2 stars, standard (strong_induction__weak_induction)

What may come as a surprise is that the weak induction principle is as strong as the strong induction principle: we can use it to prove the strong induction principle! Here we'll use the induction tactic in order to apply weak induction. Notice that we actually prove a more general property and then specialize it. Your job is to round out some of the detail.

Exercise: 3 stars, standard, recommended (strong_induction)

Case study: properties of set operations

We've already proved a number of properties about our natset operations in Logic, characterizing each operation in an "if and only if" logical description. There's an important set of properties that we haven't proved: that we maintain the natset invariant that each element appears at most once! Before we begin, we'll insert our own definitions of some operations you defined back in Poly.

We can characterize those natsets which are setlike using an inductive predicate.

Exercise: 2 stars, standard (setlike_egs)

Let's get a feel for the setlike predicate. It's always important to have positive examples---things that should satisfy the property, like setlike_eg₁---as well as negative examples---things that should not satisfy the property, like setlike_eg₂.

Exercise: 2 stars, standard (is_setlike__setlike)

We should, as always, double check our ideas. We have a setlike predicate on sets defined inductively and an is_setlike function defined recursively. Do these notions coincide?

Exercise: 2 stars, standard (insert_preserves_setlike)

Exercise: 2 stars, standard (union_preserves_setlike)

Exercise: 3 stars, standard, optional (remove_preserves_setlike)

Exercise: 2 stars, standard, optional (intersection_preserves_setlike)

Exercise: 4 stars, standard, optional (union_intersection_dist)

The setlike predicate isn't just useful for checking that we've implemented our operations correctly---sometimes we need to use setlike in proofs! Prove that intersection distributes over union. (You may be more familiar with distributivity from arithmetic: x × (y + z) = (x × y) + (x × z).)

Case study: optimality for Levenshtein edit distance

We've proven that our various edit-finding algorithms are correct. But which is best (for our notion of edit)? Levenshtein edit distance is optimal: it always produces the lowest cost edits possible. Now that we have a notion like ≤, we can prove that!

Exercise: 2 stars, standard (naive_sub_worse)

As a warm up, let's show that sub_edit is better than naive_sub_edit. The intuition here is that sub_edit and naive_sub_edit are more or less identical, except sub_edit sometimes produces a copy edit while naive_sub_edit always produces substitute. Since cost copy = 0 and cost (substitute b) = 1, using sub_edit should never be worse than naive_sub_edit.

Exercise: 2 stars, standard (add_empty_optimal)

For any edits from the empty strand to a given tgt strand, add_edit is optimal. Why? Well, you need to build the whole strand! Hint: the proof should go by induction on edits. You'll need to do some case analysis on the other edit and on tgt.

Exercise: 2 stars, standard, optional (delete_empty_optimal)

Similarly, delete_edit is optimal when editing a strand to empty.

Exercise: 3 stars, standard (levenshtein_optimal)

Prove that levenshtein is optimal. The following lemma will be helpful.

We've given you the structure of this (fairly challenging!) proof. Try not to be intimidated by the large formulae you might be given. Go slow and read everything. If you get confused, use a whiteboard.