Lecture 4: Solvers: Arithmetic, Arrays, and Bitvectors

Week 4 | Apr 20 – Apr 26

Last week you opened one theory solver and traced congruence closure by hand on an equation over uninterpreted functions. Z3 has more theory solvers. This week we meet four: linear real arithmetic, linear integer arithmetic, bitvectors, and arrays. Each is the right reach for some class of engineering problem and the wrong reach for others, and the wrong reach silently gives you a correct answer to a different question. Practice picks one engineering problem per theory and works it out concretely. Theory opens each solver and shows how it decides its fragment, ending with arrays and a callback to last week. Studio is the Reading Reflection 2 small-group discussion.

What We Cover

Practice takes four engineering problems and solves each with the theory built for it. A cafeteria blending problem wants LRA and Optimize; use Int and the feasible region collapses to whole ingredients. A compiler loop-reordering problem wants LIA; use the LP relaxation and the solver invents phantom dependences at fractional iteration counts. Josh Bloch's 2006 binary-search midpoint bug wants BV at 32 bits; use Int and the real overflow slips through silently. A memory-update ordering question wants arrays; bit-blasting memory as a flat BitVec is correct in principle and unusable in practice. Four demos, four ways the wrong theory gives a correct answer to a different question.

Theory opens each of the four solvers. LRA gets the fullest treatment, with a convex polytope in variable space and simplex walking its corners toward the optimum. LIA adds integer-lattice refinement on top of simplex (branch-and-bound). BV compiles bitvectors down to boolean circuits and hands them to the CDCL engine from Week 2. Arrays is the payoff: the decision procedure rewrites select/store terms until only uninterpreted functions remain, then runs the same congruence closure algorithm you traced by hand last week. The procedure we built for one theory already solves another.

Studio is a small-group discussion of Reading Reflection 2. The theme is "The Evidence Is In?" Three practitioners report on what formal methods look like inside real projects: Dodds at Galois arguing that complete specifications do not exist, Helwer writing a retrospective on a TLA+ contract that did not live past his departure, and the Alive team using SMT-backed peephole optimizations to find real bugs in LLVM. Groups share what they read, debate what the evidence actually shows, and post each group's takeaway to Ed.