Does z3 provide a cross product function for two lists? If not is it possible to define one without using higher order functions or using the provided list functions? I have been having trouble trying to define one. I know how to define one using map but I don't think that is supported in z3.
You can declare the cross product function in SMT 2.0.
However, any non-trivial property will require a proof by induction. Z3 currently does not support proofs by induction. Thus, it will only be able to prove very simple facts.
BTW, by cross-product of lists, I'm assuming you want a function that given the lists [a, b] and [c, d] returns the list or pairs [(a, c), (a, d), (b, c), (b, d)].
Here is a script that defines the product function.
The script also demonstrates some limitations of the SMT 2.0 language. For example, SMT 2.0 does not support the definition of parametric axioms or functions. So, I used uninterpreted sorts to "simulate" that. I also had to define the auxiliary functions append and product-aux. You can try this example online at: http://rise4fun.com/Z3/QahiP
The example also proves the following trivial fact that if l = product([a], [b]), then first(head(l)) must be a.
If you are insterested in proving non-trivial properties. I see two options. We can try to prove the base case and inductive cases using Z3. The main disadvantage in this approach is that we have to manually create these cases, and mistakes can be made. Another option is to use an interactive theorem prover such as Isabelle. BTW, Isabelle has a much richer input language, and provides tactics for invoking Z3.
For more information about algebraic datatypes in Z3, go to the online tutorial http://rise4fun.com/Z3/tutorial/guide (Section Datatypes).
;; List is a builtin datatype in Z3
;; It has the constructors insert and nil
;; Declaring Pair type using algebraic datatypes
(declare-datatypes (T1 T2) ((Pair (mk-pair (first T1) (second T2)))))
;; SMT 2.0 does not support parametric function definitions.
;; So, I'm using two uninterpreted sorts.
(declare-sort T1)
(declare-sort T2)
;; Remark: We can "instantiate" these sorts to interpreted sorts (Int, Real) by replacing the declarations above
;; with the definitions
;; (define-sort T1 () Int)
;; (define-sort T2 () Real)
(declare-fun append ((List (Pair T1 T2)) (List (Pair T1 T2))) (List (Pair T1 T2)))
;; Remark: I'm using (as nil (Pair T1 T2)) because nil is overloaded. So, I must tell which one I want.
(assert (forall ((l (List (Pair T1 T2))))
(= (append (as nil (List (Pair T1 T2))) l) l)))
(assert (forall ((h (Pair T1 T2)) (t (List (Pair T1 T2))) (l (List (Pair T1 T2))))
(= (append (insert h t) l) (insert h (append t l)))))
;; Auxiliary definition
;; Given [a, b, c], d returns [(a, d), (b, d), (c, d)]
(declare-fun product-aux ((List T1) T2) (List (Pair T1 T2)))
(assert (forall ((v T2))
(= (product-aux (as nil (List T1)) v)
(as nil (List (Pair T1 T2))))))
(assert (forall ((h T1) (t (List T1)) (v T2))
(= (product-aux (insert h t) v)
(insert (mk-pair h v) (product-aux t v)))))
(declare-fun product ((List T1) (List T2)) (List (Pair T1 T2)))
(assert (forall ((l (List T1)))
(= (product l (as nil (List T2))) (as nil (List (Pair T1 T2))))))
(assert (forall ((l (List T1)) (h T2) (t (List T2)))
(= (product l (insert h t))
(append (product-aux l h) (product l t)))))
(declare-const a T1)
(declare-const b T2)
(declare-const l (List (Pair T1 T2)))
(assert (= (product (insert a (as nil (List T1))) (insert b (as nil (List T2))))
l))
(assert (not (= (first (head l)) a)))
(check-sat)
There isn't an #include directive for the smt-lib format.
Z3 provides several other ways to provide input.
The Python input format leverages all of Python, so importing files is naturally supported.
There is a tutorial on Z3Py on http://rise4fun.com/z3py
Related
I have a z3 model written in the smt2-lib format. I noticed that when I use:
(declare-const flat1 (Seq Dummy))
(assert (= flat1 (unroll dummyFormula1)))
The model is sat, while when I use:
(define-fun flat1 () (Seq Dummy) (unroll dummyFormula1))
the model is reported as unknown.
Why is the difference important? If it helps, I can produce a minimal version of my model.
Edit #1 - A minimal example
Be sure to run it using z3 from github master because of this bug. You can swap between the two versions I indicated with A) and B) below.
(set-option :produce-models true)
; --------------- Basic Definitions -------------------
(declare-datatype Dummy (A B))
(declare-datatype Formula
((Base (forB Dummy))
(And (andB1 Formula) (andB2 Formula))
(Or (orB1 Formula) (orB2 Formula))
(Not (notB Formula))))
(declare-const dummyFormula1 Formula)
(assert (= dummyFormula1 (Base A)))
(declare-const dummyFormula2 Formula)
(assert (= dummyFormula2 (And (Base A) (Base A))))
; --------------- Some functions -----------------------
(define-fun
in_list ((o Dummy) (l (Seq Dummy))) Bool
(seq.contains l (seq.unit o)))
(define-fun
permutation ((l1 (Seq Dummy)) (l2 (Seq Dummy))) Bool
(forall ((o Dummy)) (= (in_list o l1) (in_list o l2))))
(define-fun-rec unroll ((f Formula)) (Seq Dummy)
(match f
(((Base j) (seq.unit j))
((And f1 f2) (seq.++ (unroll f1) (unroll f2)))
((Or f1 f2) (seq.++ (unroll f1) (unroll f2)))
((Not f1) (unroll f1)))))
; -------------- The question -------------------------
;; Here are two versions that should express the same idea, but try commenting
;; the first one and uncommenting the second one!
;; A)
(declare-const flat1 (Seq Dummy))
(assert (= flat1 (unroll dummyFormula1)))
;; B)
; (define-fun flat1 () (Seq Dummy) (unroll dummyFormula1))
; -----------------------------------------------------
(declare-const flat2 (Seq Dummy))
(assert (= flat2 (unroll dummyFormula2)))
(assert (permutation flat1 flat2))
; --------------- Verify -------------------
(check-sat)
(get-model)
Hard to say without looking at the internals of z3. But I want to point out that while the two constructs are very similar, there's a subtle difference.
If you look at page 62 of the standard (http://smtlib.cs.uiowa.edu/papers/smt-lib-reference-v2.6-r2017-07-18.pdf), it says:
(define-fun f ((x1 σ1) · · · (xn σn)) σ t)
with n ≥ 0 and t not containing f is semantically equivalent to the command sequence
(declare-fun f (σ1 · · · σn) σ)
(assert (forall ((x1 σ1) · · · (xn σn)) (= ( f x1 · · · xn) t)).
So, when you use the define-fun form, you are explicitly putting in a quantified formula. When you use the declare-const/assert as you did manually, this quantification does not exist.
Now you can argue that there are no parameters in your case, so there should be no difference, and I'd agree with you. But you're also using quite new features like match, define-fun-rec etc., so obviously z3 is tripping over something here. Since you have a minimal example already, why not post it to the z3 github issues site and get some feedback there. I suspect perhaps the macro-finder is missing a case and can't instantiate this particular case, but really hard to say and there might also be a good reason for it.
If you do post there and get a good answer, please update this question so we know what's going on!
Given a typical list datatype:
(declare-datatypes (X)(
(Lst
(nil)
(insert
(head X)
(tail Lst)))))
I'm trying to create a function that returns whether a given element is in a given list. It looks like I have to use an uninterpreted function. I've tried different approaches without success. For example:
(declare-fun is-in-lst ((Int)(Lst Int)) Bool)
(assert (forall((elem Int)(lst (Lst Int)))
(=
(is-in-lst elem lst)
(and
(is-insert lst)
(or
(= elem (head lst))
(is-in-lst elem (tail lst)))))))
(declare-const l1 (Lst Int))
(assert (is-in-lst 6 l1))
(assert (is-in-lst 5 l1))
Is this doable in Z3? If so, what would be the best way to address the problem?
Thank you
The latest SMTLib standard allows for recursive definitions. Also List is predefined in Z3, so you don't need to define it yourself. You can code your function as:
(define-fun-rec elem ((e Int) (l (List Int))) Bool
(ite (= l nil) false (or (= e (head l)) (elem e (tail l)))))
(declare-const l1 (List Int))
(assert (elem 6 l1))
(assert (elem 5 l1))
(check-sat)
(get-value (l1))
For this, z3 responds:
sat
((l1 (let ((a!1 (insert 6 (insert 4 (insert 7 (insert 5 nil))))))
(insert 0 (insert 1 (insert 3 (insert 2 a!1)))))))
You might have to get a recent version of Z3 from their nightly builds, as support for recursive-functions is rather new and thus the latest official release (4.6.0) may or may not work with this. (You can get nightly builds from https://github.com/Z3Prover/bin/tree/master/nightly.)
The following Z3 code times out on the online repl:
; I want a function
(declare-fun f (Int) Int)
; I want it to be linear
(assert (forall ((a Int) (b Int)) (
= (+ (f a) (f b)) (f (+ a b))
)))
; I want f(2) == 4
(assert (= (f 2) 4))
; TIMEOUT :(
(check-sat)
So does this version, where it is looking for a function on the reals:
(declare-fun f (Real) Real)
(assert (forall ((a Real) (b Real)) (
= (+ (f a) (f b)) (f (+ a b))
)))
(assert (= (f 2) 4))
(check-sat)
It's faster when I give it a contradiction:
(declare-fun f (Real) Real)
(assert (forall ((a Real) (b Real)) (
= (+ (f a) (f b)) (f (+ a b))
)))
(assert (= (f 2) 4))
(assert (= (f 4) 7))
(check-sat)
I'm quite unknowledgeable about theorem provers. What is so slow here? Is the prover just having lots of trouble proving that linear functions with f(2) = 4 exist?
The slowness is most likely due to too many quantifier instantiations, caused by problematic patterns/triggers. If you don't know about these yet, have a look at the corresponding section of the Z3 guide.
Bottom line: patterns are a syntactic heuristic, indicating to the SMT solver when to instantiate the quantifier. Patterns must cover all quantified variables and interpreted functions such as addition (+) are not allowed in patterns. A matching loop is a situation in which every quantifier instantiation gives rise to further quantifier instantiations.
In your case, Z3 probably picks the pattern set :pattern ((f a) (f b)) (since you don't explicitly provide patterns). This suggests Z3 to instantiate the quantifier for every a, b for which the ground terms (f a) and (f b) have already occurred in the current proof search. Initially, the proof search contains (f 2); hence, the quantifier can be instantiated with a, b bound to 2, 2. This yields (f (+ 2 2)), which can be used to instantiate the quantifier once more (and also in combination with (f 2)). Z3 is thus stuck in a matching loop.
Here is a snippet arguing my point:
(set-option :smt.qi.profile true)
(declare-fun f (Int) Int)
(declare-fun T (Int Int) Bool) ; A dummy trigger function
(assert (forall ((a Int) (b Int)) (!
(= (+ (f a) (f b)) (f (+ a b)))
:pattern ((f a) (f b))
; :pattern ((T a b))
)))
(assert (= (f 2) 4))
(set-option :timeout 5000) ; 5s is enough
(check-sat)
(get-info :reason-unknown)
(get-info :all-statistics)
With the explicitly provided pattern you'll get your original behaviour (modulo the specified timeout). Moreover, the statistics report lots of instantiations of the quantifier (and more still if you increase the timeout).
If you comment the first pattern and uncomment the second, i.e. if you "guard" the quantifier with a dummy trigger that won't show up in the proof search, then Z3 terminates immediately. Z3 will still report unknown, though, because it "knowns" that it did not account for the quantified constraint (which would be a requirement for sat; and it also cannot show unsat).
It is sometimes possible to rewrite quantifiers in order to have better triggering behaviour. The Z3 guide, for example, illustrates that in the context of injective functions/inverse functions. Maybe you'll be able to perform a similar transformation here.
Is there a way to concat two lists in z3? Similar to the # operator in ML? I was thinking of defining it myself but I don't think z3 supports recursive function definitions, i.e.,
define-fun concat ( (List l1) (List l2) List
(ite (isNil l1) (l2) (concat (tail l1) (insert (head l1) l2)) )
)
2021 Update
Below answer was written in 2012; 9 years ago. It largely remains still correct; except SMTLib now explicitly allows for recursive-function definitions, via define-fun-rec construct. However, solver support is still very weak, and most properties of interest regarding such functions can still not be proven out-of-the-box. Bottom line remains that such recursive definitions lead to inductive proofs, and SMT-solvers are simply not equipped to do induction. Perhaps in another 9 years they will be able to do so, presumably allowing users to specify their own invariants. For the time being, theorem-provers such as Isabelle, Coq, ACL2, HOL, Lean, etc., remain the best tools to handle these sorts of problems.
Answer from 2012
You are correct that SMT-Lib2 does not allow recursive function definitions. (In SMT-Lib2, function definitions are more like macros, they are good for abbreviations.)
The usual trick is to declare such symbols as uninterpreted functions, and then assert the defining equations as quantified axioms. Of course, as soon as quantifiers come into play the solver can start returning unknown or timeout for "difficult" queries. However, Z3 is pretty good at many goals arising from typical software verification tasks, so it should be able to prove many properties of interest.
Here's an example illustrating how you can define len and append over lists, and then prove some theorems about them. Note that if a proof requires induction, then Z3 is likely to time-out (as in the second example below), but future versions of Z3 might be able to handle inductive proofs as well.
Here's the permalink for this example on the Z3 web-site if you'd like to play around: http://rise4fun.com/Z3/RYmx
; declare len as an uninterpreted function
(declare-fun len ((List Int)) Int)
; assert defining equations for len as an axiom
(assert (forall ((xs (List Int)))
(ite (= nil xs)
(= 0 (len xs))
(= (+ 1 (len (tail xs))) (len xs)))))
; declare append as an uninterpreted function
(declare-fun append ((List Int) (List Int)) (List Int))
; assert defining equations for append as an axiom
(assert (forall ((xs (List Int)) (ys (List Int)))
(ite (= nil xs)
(= (append xs ys) ys)
(= (append xs ys) (insert (head xs) (append (tail xs) ys))))))
; declare some existential constants
(declare-fun x () Int)
(declare-fun xs () (List Int))
(declare-fun ys () (List Int))
; prove len (insert x xs) = 1 + len xs
; note that we assert the negation, so unsat means the theorem is valid
(push)
(assert (not (= (+ 1 (len xs)) (len (insert x xs)))))
(check-sat)
(pop)
; prove (len (append xs ys)) = len xs + len ys
; note that Z3 will time out since this proof requires induction
; future versions might very well be able to deal with it..
(push)
(assert (not (= (len (append xs ys)) (+ (len xs) (len ys)))))
(check-sat)
(pop)
While Levent's code works, if you're willing to set a bound on the recursion depth, Z3 normally has much less trouble with your assertions. You don't even need to rely on MBQI, which often takes far too much time to be practical. Conceptually, you'll want to do:
; the macro finder can figure out when universal declarations are macros
(set-option :macro-finder true)
(declare-fun len0 ((List Int)) Int)
(assert (forall ((xs (List Int))) (= (len0 xs) 0)))
(declare-fun len1 ((List Int)) Int)
(assert (forall ((xs (List Int))) (ite (= xs nil)
0
(+ 1 (len0 (tail xs))))))
(declare-fun len2 ((List Int)) Int)
(assert (forall ((xs (List Int))) (ite (= xs nil)
0
(+ 1 (len1 (tail xs))))))
... and so on. Writing all of this down manually will probably be a pain, so I'd recommend using a programmatic API. (Shameless plug: I've been working on Racket bindings and here's how you'd do it there.)
how can I make a datatype that contains a set of another objects. Basically, I am doing the following code:
(define-sort Set(T) (Array Int T))
(declare-datatypes () ((A f1 (cons (value Int) (b (Set B))))
(B f2 (cons (id Int) (a (Set A))))
))
But Z3 tells me unknown sort for A and B. If I remove "Set" it works just as the guide states.
I was trying to use List instead but it does not work. Anyone knows how to make it work?
You are addressing a question that comes up on a regular basis:
how can I mix data-types and arrays (as sets, multi-sets or
data-types in the range)?
As stated above Z3 does not support mixing data-types
and arrays in a single declaration.
A solution is to develop a custom solver for the
mixed datatype + array theory. Z3 contains programmatic
APIs for developing custom solvers.
It is still useful to develop this example
to illustrate the capabilities and limitations
of encoding theories with quantifiers and triggers.
Let me simplify your example by just using A.
As a work-around you can define an auxiliary sort.
The workaround is not ideal, though. It illustrates some
axiom 'hacking'. It relies on the operational semantics
of how quantifiers are instantiated during search.
(set-option :model true) ; We are going to display models.
(set-option :auto-config false)
(set-option :mbqi false) ; Model-based quantifier instantiation is too powerful here
(declare-sort SetA) ; Declare a custom fresh sort SetA
(declare-datatypes () ((A f1 (cons (value Int) (a SetA)))))
(define-sort Set (T) (Array T Bool))
Then define bijections between (Set A), SetA.
(declare-fun injSA ((Set A)) SetA)
(declare-fun projSA (SetA) (Set A))
(assert (forall ((x SetA)) (= (injSA (projSA x)) x)))
(assert (forall ((x (Set A))) (= (projSA (injSA x)) x)))
This is almost what the data-type declaration states.
To enforce well-foundedness you can associate an ordinal with members of A
and enforce that members of SetA are smaller in the well-founded ordering:
(declare-const v Int)
(declare-const s1 SetA)
(declare-const a1 A)
(declare-const sa1 (Set A))
(declare-const s2 SetA)
(declare-const a2 A)
(declare-const sa2 (Set A))
With the axioms so far, a1 can be a member of itself.
(push)
(assert (select sa1 a1))
(assert (= s1 (injSA sa1)))
(assert (= a1 (cons v s1)))
(check-sat)
(get-model)
(pop)
We now associate an ordinal number with the members of A.
(declare-fun ord (A) Int)
(assert (forall ((x SetA) (v Int) (a A))
(=> (select (projSA x) a)
(> (ord (cons v x)) (ord a)))))
(assert (forall ((x A)) (> (ord x) 0)))
By default quantifier instantiation in Z3 is pattern-based.
The first quantified assert above will not be instantiated on all
relevant instances. One can instead assert:
(assert (forall ((x1 SetA) (x2 (Set A)) (v Int) (a A))
(! (=> (and (= (projSA x1) x2) (select x2 a))
(> (ord (cons v x1)) (ord a)))
:pattern ((select x2 a) (cons v x1)))))
Axioms like these, that use two patterns (called a multi-pattern)
are quite expensive. They produce instantiations for every pair
of (select x2 a) and (cons v x1)
The membership constraint from before is now unsatisfiable.
(push)
(assert (select sa1 a1))
(assert (= s1 (injSA sa1)))
(assert (= a1 (cons v s1)))
(check-sat)
(pop)
but models are not necessarily well formed yet.
the default value of the set is 'true', which
would mean that the model implies there is a membership cycle
when there isn't one.
(push)
(assert (not (= (cons v s1) a1)))
(assert (= (projSA s1) sa1))
(assert (select sa1 a1))
(check-sat)
(get-model)
(pop)
We can approximate more faithful models by using
the following approach to enforce that sets that are
used in data-types are finite.
For example, whenever there is a membership check on a set x2,
we enforce that the 'default' value of the set is 'false'.
(assert (forall ((x2 (Set A)) (a A))
(! (not (default x2))
:pattern ((select x2 a)))))
Alternatively, whenever a set occurs in a data-type constructor
it is finite
(assert (forall ((v Int) (x1 SetA))
(! (not (default (projSA x1)))
:pattern ((cons v x1)))))
(push)
(assert (not (= (cons v s1) a1)))
(assert (= (projSA s1) sa1))
(assert (select sa1 a1))
(check-sat)
(get-model)
(pop)
Throughout the inclusion of additional axioms,
Z3 produces the answer 'unknown' and furthermore
the model that is produced indicates that the domain SetA
is finite (a singleton). So while we could patch the defaults
this model still does not satisfy the axioms. It satisfies
the axioms modulo instantiation only.
This is not supported in Z3. You can use arrays in datatype declarations, but they can't contain "references" to the datatypes you are declaring. For example, it is ok to use (Set Int).