When Z3 returns a model with an uninterpreted sort, say Q, it uses constants of the form Q!val!0.
However, if I create a query from scratch and refer to this symbol as an inhabitant of Q, then Z3 rightfully complains that Q!val!0 is an unknown constant.
Essentially, I'm trying to get Z3 to enumerate all the inhabitants of Q, by asking it to give me a model that's not the same as the previously returned one. Hence, in subsequent calls to Z3, I need to refer to these constants.
Is there a way to do this using the SMT-Lib2 interface?
Related
Using Z3's Horn clause solver:
If the answer is SAT, one can get a satisfying assignment to the unknown predicates (which, in most applications, correspond to inductive invariants of some kind of transition system or procedure call system).
If the answer is unsat, then this means the exists an unfolding of the Horn clauses and an assignment to the universally quantified variables in the Horn clauses such that at least one of the safety conditions (the clauses with a false head) is violated. This constitutes a concrete witness why the system had no solution.
I suspect that if Z3 can conclude unsat, then it has some form of such witness internally (and this anyway is the case in PDR, if I remember well). Is there a way to print it out?
Maybe I badly read the documentation, but I can't find a way. (get-proof) prints something unreadable, and, besides, (set-option :produce-proofs true) makes some problems intractable.
The refutation that Z3 produces for HORN logic problems is in the form of a tree of unit-resulting resolution steps. The counterexample you're looking for is hiding in the conclusions of the unit-resolution steps. These conclusions (the last arguments of the rules) are ground facts that correspond to program states (or procedure summaries or whatever) in the counterexample. The variable bindings that produce these facts can be found in "quant-inst" rules.
Obviously, this is not human readable, and actually is pretty hard to read by machine. For Boogie I implemented a more regular format, but it is currently only available with the duality engine and only for the fixedpoint format using "rule" and "query". You can get this using the following command.
(query :engine duality :print-certificate true)
As previously asked Z3 can not provide a model for recursive functions. However, is it possible to tell Z3 (preferably via the Java API) that a model without a definition for recursive functions is sufficient (or indeed choose the functions I am interested in, essentially I do not need a model for non-constant functions)? Obviously, that might lead to queries that return sat although some functions do not have a model. Basically, the user then has to ensure that these functions do have some model.
However, I would assume this is not really realizable the way Z3 or SMT solvers work, i.e., I would assume Z3 needs a (partial) model of recursive functions to evalutate expressions.
The MBQI implementation for quantifiers doesn't really work nicely with recursive functions.
There is one thing that might do the trick for you: replace recursive function definitions by bounded-recursive functions. You add an extra argument that counts the number of unfoldings you are willing to explore of the function. Whenever you apply the recursive function in the rest of the input, set the depth parameter. You can use either algebraic data-type Peano numbers or integers.
The symbolic automata toolkit uses this approach, for example.
I found one paper that explores the idea given in Nikolaj Bjorner's answer further: "Computing with an SMT solver" by Amin, Leino and Rompf (2014).
Furthermore, I found "Satisfiability Modulo Recursive Programs" by Suter, Köksal and Kuncak (2011) which unfolds calls to recursive functions successively until the satisfiability can be decided.
I'm playing with uninterpreted sorts and functions and cannot quite understand how quantified formulas interact with empty models. Here (also here http://rise4fun.com/Z3Py/6ets) are some simple examples that somewhat confuse me:
[∀v : False] is unsat, while "intuitively" it holds for an empty model.
Checking [∃v : v = v] yields an empty model while that does not have a satisfying assignment.
Some formulas, seemingly equivalent to [∃v : v = v], somehow prevent z3 from producing empty models. [∃v, v1 : v = v1] is one such example. E.g., if we add such formula to a solver and then try to create something resembling an allsat procedure (adding more and more constraints to rule out more and more models), we would run into unsat before getting an empty model.
So, could you please refer me to any documents/papers describing how z3 handles quantifiers and empty models?
Also, if I choose to restrict my attention to nonempty models only, what is the correct way to ask z3 for that? Things like [∃v, v1 : v = v1] seem to do the trick, but is there a better way?
Z3 does not consider empty models. This is a standard assumption in first-order logic. For more details search "first-order logic empty models", you will get many links explaining the motivation for this convention. The wikipedia page for first-order logic has a brief description (section "Empty domains").
Moreover, we should not confuse [] with the empty model. It is just saying that for satisfying the input formulas, Z3 does not need to assign an interpretation to any uninterpreted symbol in the input formula. Z3 displays only the interpretation of symbols that are needed to satisfy the formula. For example, the formula [∃v : v = v] does not contain any uninterpreted symbol, then Z3 just displays the empty assignment [].
A formula with quantifiers contains declaration of trans function. Z3 successfully finds the model and prints it. But it also prints models for functions like trans!1!4464, trans!7!4463 .. which are not used anywhere in the model. What is it? How can I disable this output?
Here is the query: http://dl.dropbox.com/u/444947/asyn_arbiter_bound_16.smt2
and here is Z3's output - http://dl.dropbox.com/u/444947/asyn_arbiter_bound_16_result.txt
Recall that the models returned by Z3 can be viewed as simple functional programs.
Your formula is in the UFBV fragment. Z3 uses several modules to decide this fragment. Each module converts a formula F into a "simpler" formula F', and produces a procedure that converts a model for F' into a model for F. We call these procedures: "model converters". Model converters will, for example, eliminate interpretations for auxiliary functions and constants introduced in the F to F' conversion. Some auxiliary definitions can't be removed seems they are used to give interpretation of other definitions. We should view them as "auxiliary functions". They also create an interpretation for symbols that have been eliminated..
In your example, the following happens: the last module produces a model that contains the trans!... and k!... symbols. This model is for a formula that does not even contain trans. The function trans has been eliminated. As we apply the model converters, the interpretation for trans is constructed based on the interpretation of all trans!.... At this point, trans!... and k!... symbols are still being used since the interpretation of trans has a reference to all trans!... symbols and the interpretation of the trans!... functions have references to the k!... function symbols. At this step, there are no unnecessary symbols in the model. However, in a later step, the interpretation of trans is simplified by unfolding the definitions of trans!... and k!.... So, after this simplification step, trans!... and k!... are essentially "dead code".
That being said, the model returned by Z3 is correct, that is, it is a model for your formula. I acknowledge that these extra symbols are annoying and unnecessary. To eliminate them, we have apply the equivalent of a "dead code" elimination step. We are really close to the next release. So, this feature will not be available in the next release, but I will add it for the release following the next one.
I know that Z3 cannot check the satisfiability of formulas that contain recursive functions. But, I wonder if Z3 can handle such formulas over bounded data structures. For example, I've defined a list of length at most two in my Z3 program and a function, called last, to return the last element of the list. However, Z3 does not terminate when asked to check the satisfiability of a formula that contains last.
Is there a way to use recursive functions over bounded lists in Z3?
(Note that this related to your other question as well.) We looked at such cases as part of the Leon verifier project. What we are doing there is avoiding the use of quantifiers and instead "unrolling" the recursive function definitions: if we see the term length(lst) in the formula, we expand it using the definition of length by introducing a new equality: length(lst) = if(isNil(lst)) 0 else 1 + length(tail(lst)). You can view this as a manual quantifier instantiation procedure.
If you're interested in lists of length at most two, doing the manual instantiation for all terms, then doing it once more for the new list terms should be enough, as long as you add the term:
isCons(lst) => ((isCons(tail(lst)) => isNil(tail(tail(lst))))
for each list. In practice you of course don't want to generate these equalities and implications manually; in our case, we wrote a program that is essentially a loop around Z3 adding more such axioms when needed.
A very interesting property (very related to your question) is that it turns out that for some functions (such as length), using successive unrollings will give you a complete decision procedure. Ie. even if you don't constrain the size of the datastructures, you will eventually be able to conclude SAT or UNSAT (for the quantifier-free case).
You can find more details in our paper Satisfiability Modulo Recursive Programs, or I'm happy to give more here.
You may be interested in the work of Erik Reeber on SULFA, the ``Subclass of Unrollable List Formulas in ACL2.'' He showed in his PhD thesis how a large class of list-oriented formulas can be proven by unrolling function definitions and applying SAT-based methods. He proved decidability for the SULFA class using these methods.
See, e.g., http://www.cs.utexas.edu/~reeber/IJCAR-2006.pdf .