Lectures

This page is the lecture archive and materials home for CARS. Use Schedule for the week-by-week view of what is happening when; use this page when you want the lecture-by-lecture record.

CARS meets every Tuesday evening (18:30-21:20) in CSE2 G10. Each lecture has three phases: Practice (hands-on solver-aided programming), Theory (algorithms and foundations), and Studio (guided exercises or reading discussion). As the quarter progresses, each lecture entry below links to its overview page and posted materials.

The lecture material in CARS draws extensively from Emina Torlak's CSE 507 course design, lecture notes, and demos. Her work is the foundation this course builds on.

Lecture 1: SAT: Foundations

Week 1 | Mar 30 – Apr 5

Engineers often need to know: does this property hold for every possible input, or does a counterexample exist? Does this function produce the same result as the reference implementation on all 32-bit inputs? Is this protocol safe against every possible interleaving? SAT and SMT solvers answer questions of exactly this form. You describe the property as a logical formula. The solver either finds an input that violates it or proves no such input exists. Tonight you see what solvers can do, learn the logic underneath them, and write your first Z3 programs.

Lecture 2: SAT: Solving and Applications

Week 2 | Apr 6 – Apr 12

Last week you saw solvers find bugs and prove correctness. This week: how do you encode a real engineering problem? We build a package manager in three versions, each asking a different question of the solver. Then we look under the hood at how modern SAT solvers actually work, and close with the first reading discussion.

Lecture 3: Solvers: Theories and Equality

Week 3 | Apr 13 – Apr 19

Last week you saw solvers encode and optimize real engineering problems. But everything fit into boolean variables and CNF. This week you find out that Z3 has been doing more than that all along. Theory solvers extend SAT with richer primitives: integers, bitvectors, arrays, equality. Your reductions can speak the language of your actual problem instead of decomposing everything into booleans. We open with two concrete payoffs (shorter encodings, better abstraction), then look inside one theory solver to see how it decides equality without knowing what the functions actually do.