Given the following input
(set-option :auto_config false)
(set-option :smt.mbqi false)
(declare-fun len (Int) Int)
(declare-fun idx (Int Int) Int)
(declare-const x Int)
(define-fun FOO () Bool
(forall ((i Int)) (!
(implies
(and (<= 0 i) (< i (len x)))
(exists ((j Int)) (!
(implies
(and (<= 0 j) (< j (len x)))
(> (idx x j) 0))))))))
(assert FOO)
; (push)
(assert (not FOO))
(check-sat)
; (pop)
; (push)
(assert (not FOO))
(check-sat)
; (pop)
Z3 4.3.2 x64 reports unsat for the first check-sat (as expected), but unknown for the second. If the commented push/pops are uncommented, both check-sats yield unknown.
My guess is that this is either a bug, or a consequence of Z3 switching to incremental mode when it reaches the second check-sat. The latter could also explain why both check-sats yield unknown if push/pop is used because Z3 will (as far as I understand) switch to incremental mode on first push.
Question: Is it a bug or an expected consequence?
Good example.
It is a limitation of how Z3 processes the formulas:
1. When using push/pop it does not detect the contradiction among the asserted formulas, instead it converts formulas to negation normal form and skolemizes quantified formulas.
2. When calling check-sat the second time, it does not keep track that the state was not retracted from a previous unsatisfiable state.
It isn't an unsoundness bug, but sure the behavior is not what a user would expect.
In addition to Nikolaj's answer: Yes, this is because Z3 switches to a different solver, which will give up earlier. We can get the same effect by setting (set-option :combined_solver.ignore_solver1 true).
Related
Running z3 on this
(assert (< (seq.nth (seq.unit 0) 0) 0))
(check-sat)
has UNSAT as a result
But running
(assert (exists ((x Int))
(< (seq.nth (seq.unit 0) x) 0)))
(check-sat)
(get-model)
is SAT. Looking at the model
(model
(define-fun seq.nth_u ((x!0 Seq) (x!1 Int)) Int
(- 1))
)
So, doesn't this mean that seq.nth is treated like a variable over a Function?
Shouldn't it be a constant function (returning always the indexed value of seq)?
I would expect the second case also to be UNSAT. In order to achieve that, how can I make seq.nth a non-variable-function?
Help appreciated...
The function seq.nth is underspecified. That is, if you query an element that is out-of-bounds (i.e., either at a negative index or at at an index that is larger than the last), then it is free to return whatever value the solver wants. (And the solver will always pick a value to make your query satisfiable.)
This is typical of SMTLib, where underspecified functions can simply take any value when given arguments that are not in the domain of their arguments. So, z3 is telling you that there is such a model by indexing out-of-bounds using the sequence (seq.unit 0). i.e., we can index it at some negative value, or at some index larger than 0.
Note that the value of seq.nth_u given in the model (note the _u suffix!) is indicative of how the underflow/overflow behavior is modeled. It should not be confused with the value of the function seq.nth.
You can actually get z3 to display the value of the index x if you make it a top-level existential:
(declare-fun x () Int)
(assert (< (seq.nth (seq.unit 0) x) 0))
(check-sat)
(get-value (x))
For this, z3 says:
sat
((x (- 1)))
that is, index at location -1. But do not confuse this with the -1 that you see in the interpretation of seq.nth_u. In fact, if we also add:
(assert (> x 0))
then z3 says:
sat
((x 1))
However, if we add:
(assert (>= x 0))
(assert (< x 1))
then we get unsat as expected. And when working with sequences, you should add these sorts of constraints (if possible!) to avoid out-of-bounds accesses.
I am using Z3 to solve my horn clauses. In the body of Horn clauses uninterpreted predicates should be positive. However, I need negation of some of uninterpreted predicates.
I have seen some examples in which negation works fine. For instance Z3 would return sat for the following example:
(set-logic HORN)
(declare-fun inv (Int) Bool)
(assert (inv 0))
(assert (forall ((k Int)) (or (> k 10) (not (inv k)) (inv (+ k 1)))))
(check-sat)
But my example looks like the following for which Z3 returns unknown.
(set-logic HORN)
(declare-fun inv (Int ) Bool)
(declare-fun s ( Int ) Bool)
(assert (forall ((k Int) (pc Int))(=>(and (= pc 1)(= k 0)) (inv k ))))
(assert (forall ((k Int)(k_p Int)(pc Int)(pc_p Int))
(=>(and (inv k )(= pc 1)(= pc_p 2)(= k_p (+ k 1))(not (s pc ))(s pc_p ))
(inv k_p ))))
(check-sat)
I wonder if there is a way to rewrite my clauses to Horn clause fragment of Z3.
Your clauses are not in the Horn fragment because the predicate s is used with both polarities in the last assertion. So there are two occurrences of a predicate with positive polarity (both (s pc) and (inv k_p) are positive polarity).
A basic method to avoid polarity issues is to introduce an extra argument to s of type Bool. Consequently, you would also have to say what is the specification of s using Horn clauses so it all makes sense. The typical scenario is that s encodes the behavior of a recursive procedure and the extra Boolean argument to s would be the return value of the procedure s. Of course this encoding doesn't ensure that s is total or functional.
There is a second approach, which is to add an extra argument to "inv", where you let 's' be an array. Then the occurrences (not (s pc)) becomes (not (select s pc)), etc.
It all depends on the intent of your encoding for what makes sense.
The following "minimal" program, distilled from a much larger program, is expected to yield unsat (and does). However, uncommenting the additional conjunct in the quantifier AX-1 changes the result to unknown (in Z3 4.5.0 x64 on Windows 10).
(set-option :auto_config false)
(set-option :smt.mbqi false)
(declare-fun foo (Int) Bool)
(declare-const k Real)
(assert (forall ((i Int)) (!
(and
(< 0.0 k)
; (implies (<= 0 i) (< 0.0 k)) ;;; ---- uncomment this line ----
)
:pattern ((foo i))
:qid |AX-1|)))
(assert (forall ((i Int)) (!
(foo i)
:pattern ((foo i))
:qid |AX-2|)))
(declare-const j Int)
(assert (< j 0))
; (push) ;;; doesn't make a difference
(assert (not
(ite
(foo j)
(< 0.0 k)
false)))
; (set-option :smt.qi.profile true)
(check-sat)
; (get-info :all-statistics)
; (pop)
The quantifier instantiation statistics show that AX-2 is instantiated in both cases, but AX-1 is only instantiated if the additional conjunct is not included. My assumption is that in the latter case, Z3 eliminates the quantifier since the quantified variable doesn't occur in the body.
However, I find it surprising that the version with the additional conjunct - in which Z3 presumably doesn't eliminate the quantifier - yields unknown, since the trigger for the quantifier ((foo j)) should be available.
Question: Is this behaviour expected - and if so, why?
Confirmed as a bug, see Github issue 935.
This is the reduction of a more interesting problem, in which the missing property was (for positive k,M and N), that ((k % M) * N) < M*N. Below is an encoding of the simpler problem that a <= b ==> (a*c) <= (b*c). Such a query succeeds (we get unsat), but if the expression b is replaced by b+1 (as in the second query below) then we get unknown, which seems surprising. Is this the expected behaviour? Are there options to improve the handling of such inequalities? I tried with and without configuration options, and various versions of Z3, including the current unstable branch. Any tips would be much appreciated!
(declare-const a Int)
(declare-const b Int)
(declare-const c Int)
(assert (> a 0))
(assert (> b 0))
(assert (> c 0))
(assert (<= a b))
(assert (not (<= (* a c) (* b c))))
(check-sat)
(assert (<= a (+ b 1)))
(assert (not (<= (* a c) (* (+ b 1) c))))
(check-sat)
This falls into nonlinear integer arithmetic (which has an undecidable decision problem, see, e.g., How does Z3 handle non-linear integer arithmetic? ), so it's actually not too surprising Z3 returns unknown for some examples, although I guess a bit surprising that it toggled between unsat and unknown for quite similar examples.
If it works for your application, you can try a type coercion: encode the constants as Real instead of Int. This will allow you to use Z3's complete solver for nonlinear real arithmetic and returns unsat with check-sat.
Alternatively, you can force Z3 to use the nonlinear solver even for the integer encoding with (check-sat-using qfnra-nlsat) as in the following based on your example (rise4fun link: http://rise4fun.com/Z3/87GW ):
(declare-const a Int)
(declare-const b Int)
(declare-const c Int)
(assert (> a 0))
(assert (> b 0))
(assert (> c 0))
(assert (<= a b))
(assert (not (<= (* a c) (* b c))))
;(check-sat)
(check-sat-using qfnra-nlsat) ; unsat
(assert (<= a (+ b 1)))
(assert (not (<= (* a c) (* (+ b 1) c))))
; (check-sat)
(check-sat-using qfnra-nlsat) ; unsat
Some more questions and answers on similar subjects:
Combining nonlinear Real with linear Int
z3 fails with this system of equations
Using Z3Py online to prove that n^5 <= 5 ^n for n >= 5
Can z3 always give result when handling nonlinear real arithmetic
Z3 Theorem Prover: Pythagorean Theorem (Non-Linear Artithmetic)
I'm writing some codes by calling Z3 to calculate division but I found the model result is not correct. Basically what I want to do is to the get value of a and b satisfying a/b == 1. So I manually wrote an input file like following to check whether it's my code's problem or Z3's.
(declare-const a Int)
(declare-const b Int)
(assert (= (div a b) 1))
(assert (not (= b 0)))
(check-sat)
(get-model)
Result from this in my machine is a =77 b = 39 instead of some equalized value of a and b. Is this a bug or did I do something wrong?
Using / instead of div will yield the desired behavior (rise4fun link: http://rise4fun.com/Z3/itdK ):
(declare-const a Int)
(declare-const b Int)
(assert (not (= b 0)))
(push)
(assert (= (div a b) 1)) ; gives a=2473,b=1237
(check-sat)
(get-model)
(pop)
(push)
(assert (= (/ a b) 1))
(check-sat)
(get-model) ; gives a=-1,b=-1
(pop)
However, there may be some confusion here, I didn't see / defined in the integer theory ( http://smtlib.cs.uiowa.edu/theories/Ints.smt2 ) only div (but it would appear to be assumed in the QF_NIA logic http://smtlib.cs.uiowa.edu/logics/QF_NIA.smt2 since / is mentioned to be excluded from QF_LIA http://smtlib.cs.uiowa.edu/logics/QF_LIA.smt2 ), so I was a little confused, or maybe it's related to the recent real/int typing issues brought up here: Why does 0 = 0.5?