Are there specific tactics I should consider for quantifier-free sequence problems? I am getting unknown satisfiability solving problems like the one below (find a sequence containing one value but not another).
I am using version 4.8.5.0 of z3.
(declare-const l (Seq Int))
(declare-const x Int)
(declare-const y Int)
(assert (not (seq.contains l (seq.unit y))))
(assert (seq.contains l (seq.unit x)))
(check-sat)
[result is unknown]
Sequence logic recently went through a bunch of changes. When I try your benchmark with a fresh build of z3 from their github sources, it successfully reports sat. See here: https://github.com/Z3Prover/z3
Before reaching out for new tactics, would be great if you can use the github version.
Related
I want to use Z3 to proof validity of statements like this:
∀ a b: ℤ, ~ b = 0 -> (a / b) ^ 2. = (a * a) / (b * b)
Or in SMT-LIB format:
(declare-fun b () Int)
(declare-fun a () Int)
(assert (=> (= b 0) false))
(assert (let ((a!1 (= (^ (/ (to_real a) (to_real b)) 2.0)
(/ (to_real (* a a)) (to_real (* b b))))))
(not a!1)))
(check-sat)
But I get timeout with the default tactic. I guess Z3 is wasting its time trying to instantiate numbers in order to find a solution. But I'm only interested in unsat output since the problem is generalized and a sat output doesn't mean anything. What combination of tactics I should use to find validity of simple algebraic statements like this?
When I run your script, I get unsat pretty quickly:
$ time z3 a.smt2
unsat
z3 a.smt2 0.17s user 0.01s system 97% cpu 0.191 total
Perhaps your z3 is too old? Here's the version I have:
$ z3 --version
Z3 version 4.12.0 - 64 bit
Try upgrading, I think the latest released version is 4.12.1.
If the issue persists and you have the latest z3, you should report this as a regression at https://github.com/Z3Prover/z3/issues
The following code
(declare-fun f (Int) Real)
(declare-fun g (Int) Real)
(declare-const x Int)
(declare-const y Int)
(assert (= (* (f x) (g y)) 1.0))
(check-sat)
(get-model)
returns "unknown", even though there is an obvious solution. Eliminating arguments to f and g (effectively making them constants?) results in "sat" with expected assignments. I guess, my question is: what is special about arithmetic with uninterpreted functions?
BTW, replacing * with + also results in "sat", so the issue is not about uninterpreted functions, per se, but about how they are combined.
Additional thoughts
Making the domain (very) finite does not help, e.g.,
(declare-fun f (Bool) Real)
(declare-fun g (Bool) Real)
(declare-const x Bool)
(declare-const y Bool)
(assert (= (* (f x) (g y)) 1.0))
(check-sat)
(get-model)
returns "unknown". This is odd given that f:Bool->Real is essentially just two variables f(False) and f(True) (of course, the solver has to recognize this).
Inability to handle non-linear arithmetic over real-valued uninterpreted functions is a very severe limitation because arrays are implemented as uninterpreted functions. So, for example,
(declare-const a (Array Int Real))
(assert (= (* (select a 1) (select a 1)) 1))
(check-sat)
(get-model)
returns "unknown". In other words, any non-linear algebraic expression on real array elements involving multiplication is unsolvable:'(
It's the non-liearity introduced by the multiplication that makes the problem hard to solve, not the uninterpreted functions. In fact, you can ask the solvers why by using the get-info command:
(set-logic QF_UFNIRA)
(declare-fun f (Int) Real)
(declare-fun g (Int) Real)
(declare-const x Int)
(declare-const y Int)
(assert (= (* (f x) (g y)) 1.0))
(check-sat)
(get-info :reason-unknown)
Here're some responses I got from various solvers:
Z3:
(:reason-unknown smt tactic failed to show goal to be sat/unsat (incomplete (theory arithmetic)))
CVC4:
(:reason-unknown incomplete)
MathSAT:
(error "sat, but with non-linear terms")
So, as the solvers themselves improve and start handling more nonliear arithmetic, you might get models eventually. But, in general, nonlinear problems will always be problematic as they are undecidable when integers are involved. (Since you can code Diophantine equations using non-linear terms.)
See also How does Z3 handle non-linear integer arithmetic? for a relevant discussion from 2012.
Removing uninterpreted functions
Even if you get rid of the uninterpreted functions, you'd still be in the unknown land, so long as you mix Int and Real types and non-linear terms:
(set-logic QF_NIRA)
(declare-const f Real)
(declare-const g Real)
(declare-const x Int)
(declare-const y Int)
(assert (= (+ (* f g) (to_real (+ x y))) 1.0))
(check-sat)
(get-info :reason-unknown)
Z3 says:
(:reason-unknown "smt tactic failed to show goal to be sat/unsat (incomplete (theory arithmetic))")
So, the issue would arise with mixed types and non-linear terms.
Here is the input
Example 1
(declare-var a Int)
(declare-var b Int)
(declare-var n Int)
(assert (= b (* a a)))
(assert (not (= b (^ a 2))))
(check-sat)
Example 2
(declare-var a Int)
(declare-var b Int)
(declare-var n Int)
(assert (= b (* (^ a n) a)))
(assert (not (= b (^ a (+ n 1)))))
(check-sat)
It returns unknown almost instantaneously.
Your problem falls into the fragment known as non-linear integer arithmetic, which is undecidable. That is, there is no decision procedure to determine the satisfiability of your query. (Non-linear means, basically, there is a multiplicative term involving at least two variables.)
Having said that, most solvers do have heuristics to answer queries involving non-linear arithmetic, and Z3 is no exception. Of course, being a heuristic, it may or may not produce an answer. This is what you are observing, alas it appears the default tactics Z3 uses is just not sufficient for your problems.
As a common trick, you can try Z3's non-linear real-arithmetic solver for these sorts of problems. Instead of check-sat, use:
(check-sat-using qfnra-nlsat)
In this case, Z3 tries to solve the benchmark assuming the inputs are reals, and sees if the solution is actually integer. This trick can successfully resolve some integer-nonlinear arithmetic queries, though of course not always. For instance, if you try qfnra-nlsat on your first example you'll see that it successfully solves it, but it still answers unknown for the second one.
For details on non-linear integer arithmetic and Z3, see here: How does Z3 handle non-linear integer arithmetic?
In Non-linear arithmetic and uninterpreted functions, Leonardo de Moura states that the qfnra-nlsat tactic hasn't been fully integrated with the rest of Z3 yet. I thought that the situation has changed in two years, but apparently the integration is still not very complete.
In the example below, I use datatypes purely for "software engineering" purposes: to organize my data into records. Even though there are no uninterpreted functions, Z3 still fails to give me a solution:
(declare-datatypes () (
(Point (point (point-x Real) (point-y Real)))
(Line (line (line-a Real) (line-b Real) (line-c Real)))))
(define-fun point-line-subst ((p Point) (l Line)) Real
(+ (* (line-a l) (point-x p)) (* (line-b l) (point-y p)) (line-c l)))
(declare-const p Point)
(declare-const l Line)
(assert (> (point-y p) 20.0))
(assert (= 0.0 (point-line-subst p l)))
(check-sat-using qfnra-nlsat)
(get-model)
> unknown
(model
)
However, if I manually inline all the functions, Z3 finds a model instantly:
(declare-const x Real)
(declare-const y Real)
(declare-const a Real)
(declare-const b Real)
(declare-const c Real)
(assert (> y 20.0))
(assert (= 0.0 (+ (* a x) (* b y) c)))
(check-sat-using qfnra-nlsat)
(get-model)
> sat
(model
(define-fun y () Real
21.0)
(define-fun a () Real
0.0)
(define-fun x () Real
0.0)
(define-fun b () Real
0.0)
(define-fun c () Real
0.0)
)
My question is, is there a way to perform such an inlining automatically? I'm fine with either one of these workflows:
Launch Z3 with a tactic that says "Inline first, then apply qfnra-nlsat. I haven't found a way to do so, but maybe I wasn't looking well enough.
Launch Z3 using some version of simplify to do the inlining. Launch Z3 the second time on the result of the first invocation (the inlined version).
In other words, how to make qfnra-nlsat work with tuples?
Thank you!
That's correct, the NLSAT solver is still not integrated with the other theories. At the moment, we can only use it if we eliminate all datatypes (or elements of other theories) before running it. I believe there is no useful existing tactic inside of Z3 at the moment though, so this would have to be done beforehand. In general it's not hard to compose tactics, e.g., like this:
(check-sat-using (and-then simplify qfnra-nlsat))
but the simplifier is not strong enough to eliminate the datatype constants in this problem. (The respective implementation files are datatype_rewriter.cpp and datatype_simplifier_plugin.cpp.)
how do I display the result of quantifier elimination ?
z3 seems to be happy with the following input
(set-option :elim-quantifiers true)
(declare-fun y () Real)
(simplify (exists ((x Real)) (>= x y)))
but it returns it the same as output.
Thanks
Z3 3.x has a new front-end for the SMT-LIB 2.0 input format.
In the new front-end, the command simplify is not an “umbrella” for all simplifications and pre-processing steps available in Z3.
The “do-all” approach used in Z3 2.x had several problems.
So, in Z3 3.x, we started using a fine-grain approach where the user can specify tactics/strategies for solving and/or simplifying formulas.
For example, one can write:
(declare-const x Int)
(assert (not (or (<= x 0) (<= x 2))))
(apply (and-then simplify propagate-bounds))
This new infrastructure is working in progress.
For example, Z3 3.2 does not have commands/tactics for eliminating quantifiers in the new front-end.
The commands/tactics for quantifier elimination will be available in Z3 3.3.
In the meantime, you can use the old SMT-LIB front-end for eliminating quantifiers.
You must provide the command line option -smtc to force Z3 to use the old front-end.
Moreover, the old front-end is not fully compliant with SMT-LIB 2.0. So, you must write:
(set-option ELIM_QUANTIFIERS true)
(declare-fun y () Real)
(simplify (exists ((x Real)) (>= x y)))