Red-black trees are a kind of balanced binary search tree (BST). Keeping the tree balanced ensures that the worst-case running time of operations is logarithmic rather than linear. This chapter uses Okasaki's algorithms for red-black trees. If you don't recall those or haven't seem them in a while, read one of the following:

• Red-Black Trees in a Functional Setting, by Chris Okasaki. Journal of Functional Programming, 9(4):471-477, July 1999. Available from https://doi.org/10.1017/S0956796899003494. Archived at http://www.eecs.usma.edu/webs/people/okasaki/jfp99.ps">class="inlineref" https://web.archive.org/web/20070926220746/http://www.eecs.usma.edu/webs/people/okasaki/jfp99.ps.
• Purely Functional Data Structures, by Chris Okasaki. Section 3.3. Cambridge University Press, 1998.

You can also consult Wikipedia or other standard textbooks, though they are likely to use different, imperative implementations. This chapter is based on the Coq standard library module MSetRBT, which can be found at https://coq.inria.fr/distrib/current/stdlib/Coq.MSets.MSetRBT.html. The design decisions for that module are described in the following paper:

• Efficient Verified Red-Black Trees, by Andrew W. Appel, September 2011. Available from http://www.cs.princeton.edu/~appel/papers/redblack.pdf.

Implementation

We use the int type axiomatized in Extract as the key type.

The lookup implementation for red-black trees is exactly the same as the lookup for BSTs, except that the T constructor carries a color component that is ignored.

We won't explain the insert algorithm here; read Okasaki's work if you want to understand it. In fact, you'll need very little understanding of it to follow along with the verification below. It uses balance and ins as helpers:

• ins recurses down the tree to find where to insert, and is mostly the same as the BST insert algorithm.
• balance takes care of rebalancing the tree on the way back up.

The elements implementation is the same as for BSTs, except that it ignores colors.

Sedgewick has proposed left-leaning red-black trees, which have a simpler balance function but a more complicated representation invariant. He does this in order to make the proof of correctness easier: there are fewer cases in the balance function, and therefore fewer cases in the case-analysis of the proof of correctness of balance. But as you will see, our proofs about balance will have automated case analyses, so we don't care how many cases there are!

Case-Analysis Automation

Before verifying the correctness of our red-black tree implementation, let's warm up by proving that the result of any insert is a nonempty tree.

This automation of case analysis will be quite useful in the rest of our development.

The BST Invariant

The BST invariant is mostly the same for red-black trees as it was for ordinary BSTs as defined in SearchTree. We adapt it by ignoring the color of each node, and changing from nat keys to int. ForallT P t holds if P k v holds for every (k, v) node of tree t.

Let's show that insert preserves the BST invariant, that is:

It will take quite a bit of work, but automation will help. First, we show that if a non-empty tree would be a BST, then the balanced version of it is also a BST:

Let's use some of what we discovered above to automate. Whenever we have a subgoal of the form
    ForallT _ (T _ _ _ _ _) we can split it. Whenever we have a hypothesis of the form
    BST (T _ _ _ _ _) we can invert it. And with a hypothesis
    ForallT _ (T _ _ _ _ _) we can simplify then destruct it. Actually, the simplification is optional -- Coq will do the destruct without needing the simplification. Anything else seems able to be finished with constructor, auto, and lia. Let's see how far that can take us...

41 cases remain. It's a little disappointing that we didn't clear more of them. Let's look at why are we stuck. All the remaining subgoals appear to be about proving an inequality over all the nodes of a subtree. For example, the first subgoal follows from the hypotheses:
    ForallT (fun (k' : int) (_ : V) ⇒ Abs k' > Abs k₀) r₂
    Abs k₁ < Abs k₀ The other goals look similar.

To make progress, we can set up some helper lemmas.

Now we can return to automating the proof.

Exercise: 2 stars, standard (balanceP)

Prove that balance preserves ForallT P. Use proof automation with match goal and/or all:.

Exercise: 2 stars, standard (insP)

Prove that ins preserves ForallT P. Hint: proceed by induction on t. Use the previous lemma. There's no need for automated case analysis.

Exercise: 3 stars, standard (ins_BST)

Prove that ins maintains BST. Proceed by induction on t. You don't need any automated case analysis.

Exercise: 2 stars, standard (insert_BST)

Prove the main theorem: insert preserves BST. You do not need induction.

Verification

We now verify that the equational specification of maps holds for red-black trees:
        lookup d k empty_tree = d
        lookup d k (insert k v t) = v
        lookup d k' (insert k v t) = lookup d k' t if k ≠ k' The first equation is trivial to verify.

The next two equations are more challenging because of balance.

Exercise: 4 stars, standard (balance_lookup)

Prove that balance preserves the result of lookup on non-empty trees. Use the same proof technique as in balance_BST.

Exercise: 3 stars, standard (lookup_ins_eq)

Verify the second equation, though for ins rather than insert. Proceed by induction on the evidence that t is a BST. Note that precondition BST t will be essential in your proof, unlike the ordinary BST's we saw in SearchTree. Hint: no automation of case analysis is needed; rely on the lemmas we've already proved above about balance and ins.

Exercise: 3 stars, standard (lookup_ins_neq)

Verify the third equation, again for ins instead of insert. The same hints as for the second equation hold.

Finish verifying the second and third equations. The proofs are almost identical to each other. No induction is needed.

Exercise: 2 stars, standard (lookup_insert)

That concludes the verification of the map equations for red-black trees. We have proved these main theorems:

We could now proceed to reprove all the facts about elements that we developed in SearchTree. But since elements does not not pay attention to colors, and does not rebalance the tree, these proofs should be a simple copy-paste from that chapter, with only minor edits. This would be an uninteresting exercise, so we don't pursue it here.

Efficiency

Red-black trees are more efficient than ordinary search trees, because red-black trees stay balanced. The insert operation ensures that these red-black invariants hold:

• Local Invariant: No red node has a red child.
  • Global Invariant: Every path from the root to a leaf has the same number of black nodes.

Together these invariants guarantee that no leaf is more than twice as deep as another leaf, a property that we will here call approximately balanced. The maximum depth of a node is therefore 2 log N, so the running-time of insert and lookup is O(log N), where N is the number of nodes in the tree. Coq does not have a formal time--cost model for its execution, so we cannot verify that logarithmic running time in Coq. But we can prove that the trees are approximately balanced. These ensure that the tree remains approximately balanced. Relation RB, below, formalizes the red-black invariants. Proposition RB t c n holds when t satisfies the red-black invariants, assuming that c is the color of t's parent, and n is the black height that t is supposed to have. If t happens to have no parent (i.e., it is the entire tree), then it will be colored black by insert, so it won't actually matter what color its (non-existent) parent might purportedly have: whether red or black, it can't violate the local invariant. If t is a leaf, then it likewise won't matter what its parent color is, and its black height must be zero.

Exercise: 1 star, standard (RB_blacken_parent)

Prove that blackening a parent would preserve the red-black invariants.

Relation NearlyRB expresses, "the tree is a red-black tree, except that it's nonempty and it is permitted to have two consecutive red nodes at the root only."

Exercise: 4 stars, standard (ins_RB)

Prove that ins creates a tree that is either red-black or nearly so, depending on what the parent's color was. The proof is already completed for you, except for the tactic prove_RB. Replace the provided admit with your own proof automation. Use a technique similar to ins_not_E and balance_lookup -- that is, write a repeat match goal that finds opportunities to use tactics such as bdestruct, destruct, inv, and constructor; as well as previously proved lemmas and auto.

Therefore, ins produces a red-black tree when given one as input though the parent color changes.

Exercise: 1 star, standard (RB_blacken_root)

Prove that blackening a subtree root (whose hypothetical parent is black) would preserve the red-black invariants, though the black height of the subtree might change (and the color of the parent would need to become red).

Exercise: 1 star, standard (insert_RB)

Prove that insert produces a red-black tree when given one as input. This can be done entirely with lemmas already proved.

Exercise: 4 stars, advanced (redblack_bound)

To confirm that red-black trees are approximately balanced, define functions to compute the height (i.e., maximum depth) and minimum depth of a red-black tree, and prove that the height is bounded by twice the minimum depth, plus 1. Hints:

• The standard library has min and max functions for nat.
• Note that RB does not require the root to be Black.
• Prove two auxiliary lemmas, one about an upper bound on the number of black nodes in a path, and another about a lower bound. Combine those lemmas to prove the main theorem.
• All of the proofs can be quite short. The challenge is to invent helpful lemmas.

Performance of Extracted Code

We can extract the red-black tree implementation:

Run it in the OCaml top level with these commands:

    #use "redblack.ml";;
    #use "test_searchtree.ml";;

On a recent machine with a 2.9 GHz Intel Core i₉ that prints:

    Insert and lookup 1000000 random integers in 0.860663 seconds.
    Insert and lookup 20000 random integers in 0.007908 seconds.
    Insert and lookup 20000 consecutive integers in 0.004668 seconds.

That execution uses the bytecode interpreter. The native compiler will have better performance:

      $ ocamlopt -c redblack.mli redblack.ml
      $ ocamlopt redblack.cmx -open Redblack test_searchtree.ml -o test_redblack
      $ ./test_redblack

On the same machine that prints,

    Insert and lookup 1000000 random integers in 0.475669 seconds.
    Insert and lookup 20000 random integers in 0.00312 seconds.
    Insert and lookup 20000 consecutive integers in 0.001183 seconds.

The benchmark measurements above (and in Extract) demonstrate the following:

• On random insertions, red-black trees are about the same as ordinary BSTs.
• On consecutive insertions, red-black trees are much faster than ordinary BSTs.
• Red-black trees are about as fast on consecutive insertions as on random.