CS1950Y Lecture 21: SMT
April 2, 2018

Final Project Logistics

Design check 1 needs to be done by Thursday at the latest. This design check is to check in to make sure you have started your spec, in order to make sure you are asking the important questions. For example, in alloy, what sort of bounds are you considering? Are they enough?

Are the design checks going to be graded?
They will be worth something like 5% of your grade. This will be based on whether you showed up, and whether you started or not.

Please please please start early!

The World of SAT Solvers

What things do our SAT Solvers not give us?

The "next button"!
If I have something like:
x1 = True
x2 = False
Then my instance is something like x₁ ∧ not x₂, and then to get the "next" instance alloy does something like not x₁ ∨ x₂.

What about integers?
What about functions?
If we want to reason about a mathmatical problem, we need real integers.
If we want to reason about what happens in a computer, for example when integers overflow, we want this idea of bit vectors.

We want to take all of these things that alloy doesn't understand and reason about them. We have all of these different algorithmic methods for solving problems that come to us from mathmatics or operations research, and we want to integrate these high level ideas and integrate them with our SAT Solver.

SMT Solvers

SMT stands for 'Satisfiability Modulo Theories'

SMT solvers are a natural extension of SAT solvers.

Using z3, we saw we could create a solver by saying s = Solver and we can create variables by saying p = Bool('p'). We can add clauses to our solver by saying s.add(Or(p, q)) and we can see a model by saying m = s.model(). Here, m is going to contain bindings for p and q.

Do you have to call check before you call model?
Yes!

When we look at the binary relation "less than" in our live coding example, what is the interpretation of "less than"? Is there any baggage with "less than"?

We haven't added any constraints that say that "less than" is an ordering, or what it's an ordering over. "Less than" here is an interpreted relation. It has meaning baked into it that z3 assumes. "Less than" when you use it, really is over integers. Even if you have a constraint that defines an ordering over something else (such as classes or students), you cannot use "less than" unless you are dealing with integers. You would need to define your own relation instead.

To create a real number, we can say x = Real('x'). If we say x squared is greater than four and x squared is less than 9, what must be true of x? It won't be an integer! This is something alloy isn't good at, but z3 works!

What about irrational numbers? If we say x squared is equal to 2, then the result should be the square root of two. z3 gave us -1.4142135623?. The question mark represents a margin for error. It's an inexact answer because it only shows you up to a certain number of decimals.

In example 4, we printed out whether s.check() passes or not, and we got "unknown." In some sense this is more honest than alloy, because alloy only checks up to a bound whether something holds. We can't ask alloy for an answer without any bounds. But, z3 is doing this, and without these bounds, sometimes you are going to run into this unknown issue, because the search for the instance is not finite.

What symbols are we using that are not explicitely defined and are rather implied (like the example of less than from before)?
2, **, ...