I am getting the "unknown sort" error when trying to pose a fixed point query using the query keyword. For example, the following example from the fixed point tutorial, which works fine in the online version of Z3,
(declare-rel mc (Int Int))
(declare-var n Int)
(declare-var m Int)
(declare-var p Int)
(rule (=> (> m 100) (mc m (- m 10))))
(rule (=> (and (<= m 100) (mc (+ m 11) p) (mc p n)) (mc m n)))
(query (and (mc m n) (< n 91))
:print-certificate true)
returns:
(error "line 9 column 13: unknown sort 'mc'")
when I run it from the command line. I use Z3 version 4.4.2 compiled from the github repository on Linux. My command line is: z3 -smt2 example.smt
Are there some compilation flags I need to set to enable this functionality?
I recently changed the format of "query" to use a predicate only.
The tutorial will have to be updated.
(declare-rel q (Int Int))
(rule (=> (and (mc m n) (< n 91)) (q m n)))
(query q :print-certificate true)
Related
I have a program that runs Z3 version 4.8.8 - 64 bit, with incremental input: the program starts Z3 once, executes many rounds of input-output to Z3, and then stops Z3. For performance reasons, running Z3 without incremental input is not an option.
Each round, the program inputs some (assert ...) statements to Z3, inputs (check-sat) to Z3, then gets the output of (check-sat) from Z3.
I have two rounds of input-output: the first round of inputs is as in z3.sat:
(declare-fun f () Int)
(declare-fun n () Int)
(assert (< 1 n))
(assert (<= 2 f))
(assert (= (+ (+ 1 f) 1) (+ n n)))
(assert (not false))
(check-sat)
which means: f is an even Int greater or equals to 2.
And the second round of inputs is as in z3.unsat:
(declare-fun f () Int)
(declare-fun n () Int)
(assert (< 1 n))
(assert (<= 2 f))
(assert (= (+ (+ 1 f) 1) (+ n n)))
(assert (not (exists ((alpha Int)) (= (* 2 alpha) f))))
(check-sat)
which means: if f is an even Int greater or equals to 2, then there exists an alpha where alpha=f/2.
I assume that running Z3 with incremental input is similar to concatenating the two rounds of input, z3.sat and z3.unsat, into one input, as in z3.combined:
(declare-fun f () Int)
(declare-fun n () Int)
(assert (< 1 n))
(assert (<= 2 f))
(assert (= (+ (+ 1 f) 1) (+ n n)))
(assert (not false))
(check-sat)
(declare-fun f () Int)
(declare-fun n () Int)
(assert (< 1 n))
(assert (<= 2 f))
(assert (= (+ (+ 1 f) 1) (+ n n)))
(assert (not (exists ((alpha Int)) (= (* 2 alpha) f))))
(check-sat)
Running:
z3 -smt2 z3.sat outputs sat
z3 -smt2 z3.unsat outputs unsat
z3 -smt2 z3.combined outputs errors, because the (assert ...) statements from the first round do not disappear:
sat
(error "line 8 column 21: invalid declaration, constant 'f' (with the given signature) already declared")
(error "line 9 column 21: invalid declaration, constant 'n' (with the given signature) already declared")
unknown
So it seems (push 1) and (pop 1) statements are needed for Z3 to forget previous assertion sets, so I added these statements at the start and end of z3.sat and z3.unsat, and re-concatenated z3.pushpop.sat and z3.pushpop.unsat to get z3.pushpop.combined.
z3.pushpop.sat:
(push 1)
(declare-fun f () Int)
(declare-fun n () Int)
(assert (< 1 n))
(assert (<= 2 f))
(assert (= (+ (+ 1 f) 1) (+ n n)))
(assert (not false))
(check-sat)
(pop 1)
z3.pushpop.unsat:
(push 1)
(declare-fun f () Int)
(declare-fun n () Int)
(assert (< 1 n))
(assert (<= 2 f))
(assert (= (+ (+ 1 f) 1) (+ n n)))
(assert (not (exists ((alpha Int)) (= (* 2 alpha) f))))
(check-sat)
(pop 1)
z3.pushpop.combined:
(push 1)
(declare-fun f () Int)
(declare-fun n () Int)
(assert (< 1 n))
(assert (<= 2 f))
(assert (= (+ (+ 1 f) 1) (+ n n)))
(assert (not false))
(check-sat)
(pop 1)
(push 1)
(declare-fun f () Int)
(declare-fun n () Int)
(assert (< 1 n))
(assert (<= 2 f))
(assert (= (+ (+ 1 f) 1) (+ n n)))
(assert (not (exists ((alpha Int)) (= (* 2 alpha) f))))
(check-sat)
(pop 1)
However, now running:
z3 -smt2 z3.pushpop.sat outputs sat
z3 -smt2 z3.pushpop.unsat outputs unknown
z3 -smt2 z3.pushpop.combined outputs:
sat
unknown
Why does z3 -smt2 z3.pushpop.unsat output unknown?
As Malte mentioned, the presence of pus/pop triggers "weaker" solvers in z3. (There are many technical reasons for this, but I agree from an end-user view-point, the change in behavior is unfortunate and can be rather confusing.)
But there are commands that let you do what you want without resorting to push and pop. Instead of it, simply insert:
(reset)
when you want to "start" a new session, and this will make sure it'll all work. That is, drop the push/pop and when you concatenate, insert a (reset) in between.
A slightly better approach
While the above will work, in general you only want to forget assertions, but not definitions. That is, you want to "remember" that you have an f and an n in the environment. If this is your use case, then put the following at the top of your script:
(set-option :global-declarations true)
and when you want to "switch" to a new problem, issue:
(reset-assertions)
This way, you won't have to "repeat" the declarations each time. That is, your entire interaction should look like:
(set-option :global-declarations true)
(declare-fun f () Int)
(declare-fun n () Int)
(assert (< 1 n))
(assert (<= 2 f))
(assert (= (+ (+ 1 f) 1) (+ n n)))
(assert (not false))
(check-sat)
(reset-assertions)
(assert (< 1 n))
(assert (<= 2 f))
(assert (= (+ (+ 1 f) 1) (+ n n)))
(assert (not (exists ((alpha Int)) (= (* 2 alpha) f))))
(check-sat)
which produces:
sat
unsat
Reference
All of this is documented in the official SMTLib document. See Section 3.9, pg. 44, for the descripton of global-declarations, and Section 4.2.2, pg. 59, for the description of (reset-assertions).
Incremental mode forces Z3 to use different theory subsolvers, as explained by one of the developers in this SO answer. These "incremental mode" subsolvers are often less effective than the "regular" ones, or at least may behave differently. As far as I know, Z3 switches to incremental mode whenever an SMT program contains push-pop scopes or multiple check-sats.
You initially say that not using incremental mode is not an option, but at least your file z3.pushpop.combined looks easily splitable. Another option might be to reset Z3 (I think the SMT command (reset) exists for that purpose) in between, instead of having push-pop blocks. If what I claim above is correct, however, this wouldn't prevent Z3 from staying in non-incremental mode. You could consider asking the developers via a "question issue" on Z3's issue tracker.
I defined my own version of list concat based on Haskell as below:
(declare-datatypes ((MyList 1))
((par (T) ((cons (head T) (tail (MyList T))) (nil)))))
(declare-fun my-concat ( (MyList T1) (MyList T1) ) (MyList T1))
(assert (forall ((xs (MyList T1)) (ys (MyList T1)) (x T1))
(ite (= (as nil (MyList T1)) xs)
(= (my-concat xs ys) ys)
(= (my-concat (cons x xs) ys) (cons x (my-concat xs ys))))))
I am wondering why z3 is not able to reason about the following?
(assert (not (= (my-concat (cons 4 (as nil (MyList Int))) (as nil (MyList Int)))
(cons 4 (as nil (MyList Int))))))
(check-sat) ; runs forever
Loading your file
If I load your program to z3 as you've given it, it says:
(error "line 3 column 33: Parsing function declaration. Expecting sort list '(': unknown sort 'T1'")
(error "line 4 column 29: invalid sorted variables: unknown sort 'T1'")
(error "line 8 column 79: unknown function/constant my-concat")
That's because you cannot define "polymorphic" functions in SMTLib. At the user-level, only fully monomorphic functions are allowed. (Though internally SMTLib does provide polymorphic constants, there's no way for the user to actually create any polymorphic constants.)
So, I'm not sure how you got to load that file.
Monomorphisation
Looks like you only care about integer-lists anyhow, so let's just modify our program to work on lists of integers. This process is called monomorphisation, and is usually automatically done by some front-end tool before you even get to the SMT-solver, depending on what framework you're working in. That's just a fancy way of saying create instances of all your polymorphic constants at the mono-types they are used. (Since you mentioned Haskell, I'll just throw in that while monomorphisation is usually possible, it's not always feasible: There might be way too many variants to generate making it impractical. Also, if you have polymoprhic-recursion then monomorphisation doesn't work. But that's a digression for the time being.)
If I monomorphise your program to Int's only, I get:
(declare-datatypes ((MyList 1))
((par (T) ((cons (head T) (tail (MyList T))) (nil)))))
(declare-fun my-concat ( (MyList Int) (MyList Int) ) (MyList Int))
(assert (forall ((xs (MyList Int)) (ys (MyList Int)) (x Int))
(ite (= (as nil (MyList Int)) xs)
(= (my-concat xs ys) ys)
(= (my-concat (cons x xs) ys) (cons x (my-concat xs ys))))))
(assert (not (= (my-concat (cons 4 (as nil (MyList Int))) (as nil (MyList Int)))
(cons 4 (as nil (MyList Int))))))
(check-sat)
(get-info :reason-unknown)
When I run z3 on this, I get:
unknown
(:reason-unknown "smt tactic failed to show goal to be sat/unsat (incomplete quantifiers)")
So, it doesn't loop at all like you mentioned; but your file didn't really load in the first place. So maybe you were working with some other contents in the file as well, but that's a digression for the current question.
But it still doesn't prove it!
Of course, you wanted unsat for this trivial formula! But z3 said it's too hard for it to deal with. The reason-unknown is "incomplete quantifiers." What does that mean?
In short, SMTLib is essentially logic of many-sorted first order formulas. Solvers are "complete" for the quantifier-free fragment of this logic. But adding quantifiers makes the logic semi-decidable. What that means is that if you give enough resources, and if smart heuristics are in play, the solver will eventually say sat for a satisifiable formula, but it may loop forever if given an unsat one. (It might get lucky and say unsat as well, but most likely it'll loop.)
There are very good reasons why above is the case, but keep in mind that this has nothing to do with z3: First-order logic with quantifiers is semi-decidable. (Here's a good place to start reading: https://en.wikipedia.org/wiki/Decidability_(logic)#Semidecidability)
What usually happens in practice, however, is that the solver will not even answer sat, and will simply give up and say unknown as z3 did above. Quantifiers are simply beyond the means of SMT-solvers in general. You can try using patterns (search stack-overflow for quantifiers and pattern triggers), but that usually is futile as patterns and triggers are tricky to work with and they can be quite brittle.
What course of action do you have:
Honestly, this is one of those cases where "give up" is good advice. An SMT solver is just not a good fit for this sort of a problem. Use a theorem-prover like Isabelle, ACL2, Coq, HOL, HOL-Light, Lean, ... where you can express quantifiers and recursive functions and reason with them. They are built for this sort of thing. Don't expect your SMT solver to handle these sorts of queries. It's just not the right match.
Still, is there anything I can do?
You can try SMTLib's recursive-function definition facilities. You'd write:
(declare-datatypes ((MyList 1))
((par (T) ((cons (head T) (tail (MyList T))) (nil)))))
(define-fun-rec my-concat ((xs (MyList Int)) (ys (MyList Int))) (MyList Int)
(ite (= (as nil (MyList Int)) xs)
ys
(cons (head xs) (my-concat (tail xs) ys))))
(assert (not (= (my-concat (cons 4 (as nil (MyList Int))) (as nil (MyList Int)))
(cons 4 (as nil (MyList Int))))))
(check-sat)
Note the define-fun-rec construct, which allows for recursive definitions.
And voila, we get:
unsat
But this does not mean z3 will be able to prove arbitrary theorems regarding this concat function. If you try anything that requires induction, it'll either give up (saying unknown) or loop-forever. Of course, as the capabilities improve some induction-like proofs might be possible in z3 or other SMT-solvers, but that's really beyond what they're designed for. So, use with caution.
You can read more about recursive definitions in Section 4.2.3 of http://smtlib.cs.uiowa.edu/papers/smt-lib-reference-v2.6-r2017-07-18.pdf
To sum up
Do not use an SMT-solver for reasoning with quantified or recursive definitions. They just don't have the necessary power to deal with such problems, and it's unlikely they'll ever get there. Use a proper theorem prover for these tasks. Note that most theorem-provers use SMT-solvers as underlying tactics, so you get the best of both worlds: You can do some manual work to guide the inductive proof, and have the prover use an SMT-solver to handle most of the goals automatically for you. Here's a good paper to read to get you started on the details: https://people.mpi-inf.mpg.de/~jblanche/jar-smt.pdf
alias makes valid points, but I don't completely agree with the final conclusion to " not use an SMT-solver for reasoning with quantified or recursive definitions". In the end, it depends on which kind of properties you need to reason about, what kind of answers you need (is unsat/unknown OK, or do you need unsat/sat and a model?), and how much work you're willing to invest :-)
For example, SMT-based program verifiers such as Dafny and Viper quickly verify the following assertions about lists:
assert [4] + [] == [4]; // holds
assert [4,1] + [1,4] == [4,1,1,4]; // holds
assert [4] + [1] == [1,4]; // fails
Both tools can be used online, but the websites are rather slow and not terribly reliable. You can find the Dafny example here and the Viper example here.
Here is the relevant SMT code that Viper generates:
(set-option :auto_config false) ; Usually a good idea
(set-option :smt.mbqi false)
;; The following definitions are an excerpt of Viper's sequence axiomatisation,
;; which is based on Dafny's sequence axiomatisation.
;; See also:
;; https://github.com/dafny-lang/dafny
;; http://viper.ethz.ch
(declare-sort Seq<Int>) ;; Monomorphised sort of integer sequences
(declare-const Seq_empty Seq<Int>)
(declare-fun Seq_length (Seq<Int>) Int)
(declare-fun Seq_singleton (Int) Seq<Int>)
(declare-fun Seq_index (Seq<Int> Int) Int)
(declare-fun Seq_append (Seq<Int> Seq<Int>) Seq<Int>)
(declare-fun Seq_equal (Seq<Int> Seq<Int>) Bool)
(assert (forall ((s Seq<Int>)) (!
(<= 0 (Seq_length s))
:pattern ((Seq_length s))
)))
(assert (= (Seq_length (as Seq_empty Seq<Int>)) 0))
(assert (forall ((s1 Seq<Int>) (s2 Seq<Int>)) (!
(implies
(and
(not (= s1 (as Seq_empty Seq<Int>)))
(not (= s2 (as Seq_empty Seq<Int>))))
(= (Seq_length (Seq_append s1 s2)) (+ (Seq_length s1) (Seq_length s2))))
:pattern ((Seq_length (Seq_append s1 s2)))
)))
(assert (forall ((s Seq<Int>)) (!
(= (Seq_append (as Seq_empty Seq<Int>) s) s)
:pattern ((Seq_append (as Seq_empty Seq<Int>) s))
)))
(assert (forall ((s Seq<Int>)) (!
(= (Seq_append s (as Seq_empty Seq<Int>)) s)
:pattern ((Seq_append s (as Seq_empty Seq<Int>)))
)))
(assert (forall ((s1 Seq<Int>) (s2 Seq<Int>) (i Int)) (!
(implies
(and
(not (= s1 (as Seq_empty Seq<Int>)))
(not (= s2 (as Seq_empty Seq<Int>))))
(ite
(< i (Seq_length s1))
(= (Seq_index (Seq_append s1 s2) i) (Seq_index s1 i))
(= (Seq_index (Seq_append s1 s2) i) (Seq_index s2 (- i (Seq_length s1))))))
:pattern ((Seq_index (Seq_append s1 s2) i))
:pattern ((Seq_index s1 i) (Seq_append s1 s2))
)))
(assert (forall ((s1 Seq<Int>) (s2 Seq<Int>)) (!
(=
(Seq_equal s1 s2)
(and
(= (Seq_length s1) (Seq_length s2))
(forall ((i Int)) (!
(implies
(and (<= 0 i) (< i (Seq_length s1)))
(= (Seq_index s1 i) (Seq_index s2 i)))
:pattern ((Seq_index s1 i))
:pattern ((Seq_index s2 i))
))))
:pattern ((Seq_equal s1 s2))
)))
(assert (forall ((s1 Seq<Int>) (s2 Seq<Int>)) (!
(implies (Seq_equal s1 s2) (= s1 s2))
:pattern ((Seq_equal s1 s2))
)))
; ------------------------------------------------------------
; assert Seq(4) ++ Seq[Int]() == Seq(4)
(push)
(assert (not
(Seq_equal
(Seq_append (Seq_singleton 4) Seq_empty)
(Seq_singleton 4))))
(check-sat) ; unsat -- good!
(pop)
; assert Seq(4, 1) ++ Seq(1, 4) == Seq(4, 1, 1, 4)
(push)
(assert (not
(Seq_equal
(Seq_append
(Seq_append (Seq_singleton 4) (Seq_singleton 1))
(Seq_append (Seq_singleton 1) (Seq_singleton 4)))
(Seq_append
(Seq_append
(Seq_append (Seq_singleton 4) (Seq_singleton 1))
(Seq_singleton 1))
(Seq_singleton 4)))))
(check-sat) ; unsat -- good!
(pop)
; assert Seq(4) ++ Seq(1) == Seq(1, 4)
(push)
(assert (not (Seq_equal
(Seq_append (Seq_singleton 4) (Seq_singleton 1))
(Seq_append (Seq_singleton 1) (Seq_singleton 4)))))
(check-sat) ; unknown -- OK, since property doesn't hold
(pop)
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.
I'm using muZ engine of Z3. For all SAT cases I would like to see which rules where used in the derivation. Is there any way to extract this information?
For instance the input might look like this:
(declare-rel R1 (Int))
(declare-rel R2 (Int))
(declare-rel q (Int))
(declare-var n Int)
(rule (R1 n) rule_one)
(rule (=> (R1 n) (R2 n)) rule_two)
(rule (=> (and (R2 n) (< n 1)) (q n)) query)
(query q
:print-answer true
)
And I'd be glad to know which rules were triggered, something like
q is SAT, used rules: rule_one->rule_two->query
One can use the following option
(set-option :fixedpoint.generate_proof_trace true)
(set-option :smt.mbqi true)
(declare-fun R(Int) Int)
(declare-const a Int)
(assert (= (R 0) 0))
(assert (forall ((n Int)) (=> (> n 0) (= (R n ) (+ (R (- n 1)) 1)))))
(assert (not (= a 5)))
(assert (not (= (R a) 5)))
(check-sat)
I have tried the above code in Z3,But Z3 unable to answer.Can you please guide me where i have made the mistake ?
As a general pattern don't expect MBQI to produce models
involving functions that
only have an infinite range of different values.
If you really must, then you can use the define-fun-rec construct to define
a recursive function. Z3 currently trusts that the definition
is well-formed (e.g., that the equation corresponding to the function
definition is satisfiable).
(set-option :smt.mbqi true)
(declare-fun F (Int) Int)
(define-fun-rec R ((n Int)) Int
(if (= n 0) 0
(if (> n 0) (+ (R (- n 1)) 1)
(F n))))
(declare-const a Int)
(assert (not (= a 5)))
(assert (not (= (R a) 5)))
(check-sat)
(get-model)
Z3 uses recursively defined functions passively during search: whenever
there is a candidate model for the ground portion of the constraints, it
checks that the function graph is adequately defined on the values of the candidate model. If it isn't, then the function definition is instantiated on the selected values until it is well defined on the values that are relevant
to the ground constraints.