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.
Related
I have created a grammar to read a file of equations then created AST nodes for each rule.My question is how can I do simplification or substitute vales on the equations that the parser is able to read correctly. in which stage? before creating AST nodes or after?
Please provide me with ideas or tutorials to follow.
Thank you.
I'm assuming you equations are something like simple polynomials over real-value variables, like X^2+3*Y^2
You ask for two different solutions to two different problems that start with having an AST for at least one equation:
How to "substitute values" into the equation and compute the resulting value, e.g, for X==3 and Y=2, substitute into the AST for the formula above and compute 3^2+3*2^2 --> 21
How to do simplification: I assume you mean algebraic simplification.
The first problem of substituting values is fairly easy if yuo already have the AST. (If not, parse the equation to produce the AST first!) Then all you have to do is walk the AST, replacing every leaf node containing a variable name with the corresponding value, and then doing arithmetic on any parent nodes whose children now happen to be numbers; you repeat this until no more nodes can be arithmetically evaluated. Basically you wire simple arithmetic into a tree evaluation scheme.
Sometimes your evaluation will reduce the tree to a single value as in the example, and you can print the numeric result My SO answer shows how do that in detail. You can easily implement this yourself in a small project, even using JavaCC/JJTree appropriately adapted.
Sometimes the formula will end up in a state where no further arithmetic on it is possible, e.g., 1+x+y with x==0 and nothing known about y; then the result of such a subsitution/arithmetic evaluation process will be 1+y. Unfortunately, you will only have this as an AST... now you need to print out the resulting AST in order for the user to see the result. This is harder; see my SO answer on how to prettyprint a tree. This is considerably more work; if you restrict your tree to just polynomials over expressions, you can still do this in small project. JavaCC will help you with parsing, but provides zero help with prettyprinting.
The second problem is much harder, because you must not only accomplish variable substitution and arithmetic evaluation as above, but you have to somehow encode knowledge of algebraic laws, and how to match those laws to complex trees. You might hardwire one or two algebraic laws (e.g., x+0 -> x; y-y -> 0) but hardwiring many laws this way will produce an impossible mess because of how they interact.
JavaCC might form part of such an answer, but only a small part; the rest of the solution is hard enough so you are better off looking for an alternative rather than trying to build it all on top of JavaCC.
You need a more organized approach for this: a Program Transformation System (PTS). A typical PTS will allow you specify
a grammar for an arbitrary language (in your case, simply polynomials),
automatically parses instance to ASTs and can regenerate valid text from the AST. A good PTS will let you write source-to-source transformation rules that the PTS will apply automatically the instance AST; in your case you'd write down the algebraic laws as source-to-source rules and then the PTS does all the work.
An example is too long to provide here. But here I describe how to define formulas suitable for early calculus classes, and how to define algebraic rules that simply such formulas including applying some class calculus derivative laws.
With sufficient/significant effort, you can build your own PTS on top of JavaCC/JJTree. This is likely to take a few man-years. Easier to get a PTS rather than repeat all that work.
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)
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 [].
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?
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 .