According to the SMTLib doc here, we can check sat using check-sat-assuming and then one can determine the unsatisfiable assumptions using get-unsat-assumptions.
Reflecting that on Z3 in JavaAPI, I can see checkAssuming API doing the same thing as thecheck-sat-assuming but I can't seem to find anything that is doing something similar to get-unsat-assumptions, all I can find is getUnsatCore api.
So my question is, is there anyway that I can get unsat assumptions in Z3 using JavaAPI?
Much appreciated!
Looks like an oversight in the Java API. You might want to file a ticket (or better yet a pull-request) at their github site: https://github.com/Z3Prover/z3/issues
Related
I'm trying to debug a program that is using the Z3 API, and I'm wondering if there's a way, either from within the API or by giving Z3 a command, to print the current logical context, hopefully as if it had been read in an SMT-LIB file.
This question from 7 years ago seemed to indicate that there would be a way to do this, but I couldn't find it in the API docs.
Part of my motivation is that I'm trying to debug whether my program is slow because it's creating an SMT problem that's hard to solve, or whether the slowdown is elsewhere. Being able to view the current context as an SMT-LIB file, and run it in Z3 on the command line, would make this easier.
It's not quite clear what you mean by "logical context." If you mean all the assertions the user has given to the solver, then the command:
(get-assertions)
will return it as an S-expression like list; see Section 4.2.4 of http://smtlib.cs.uiowa.edu/papers/smt-lib-reference-v2.6-r2017-07-18.pdf
But this doesn't sound useful for your purposes; after all it is going to return precisely everything you yourself have asserted.
If you're looking for a dump of all the learned-lemmas, internal assertions the solver created etc; I'm afraid there's no way to do that from SMTLib. You probably can't even do that using the programmatic API either. (Though this needs to be checked.) That would only be possible by actually modifying the source code of z3 itself (which is open-source), and putting in relevant debug traces. But that would require a lot of study of the internals of z3 and would unlikely to help unless you're intimately knowledgeable about z3 code base itself.
I find that running z3 -v:10 can sometimes provide diagnostic info; if you see it repeatedly printing something, it's a good indication that something has gone wrong in that area. But again, what it prints and what it exactly means is guess work unless you study the source code itself.
Similar to #include in C in importing functions and axioms that are defined in another file. I wasn't able to find such functionality described in the SMTLIB documentation or from the online examples. Any hints?
SMTLib has no means of #include'ing or importing other files. This might look like a shortcoming, but it is quite rare for people to hand-write SMTLib files: It is almost always machine generated from a higher level language, and it is assumed that whoever generates the SMTLib can simply spit out one big file that includes everything you need.
Having said that, I think this would be a useful feature to have indeed. SMTLib standard is always evolving and such features are usually discussed in their mailing list:
https://groups.google.com/forum/#!forum/smt-lib
Feel free to join the discussion and make a request!
The release notes for z3 version 4.6 mention a new feature "issuing multiple (check-sat) calls until it returns unsat".
Is this an equivalent for ALLSAT?
Where can I find any further documentation or an example for this feature?
No, this was for addressing this issue: https://github.com/Z3Prover/z3/issues/1008
An ALLSAT command is not supported by z3; though it would be easy to code it using the "assert the negation of the previous model and re-check" loop. Most high-level interfaces provide this as a layer on top of what's possible using SMT-Lib2. If you do want support for this, it might be best to first convince the SMTLib folks (http://smtlib.cs.uiowa.edu/) so a standard way of doing so would be developed and can be implemented by multiple solvers.
I have been reading Nikolai's article on Engineering Theories with Z3 for how to interface a custom decision procedure with Z3. In there several methods such as AssertTheoryAxiom, NewAssignment, and FinalCheck etc are mentioned. However I have been unable to locate them in the most recent (new?) Z3 API at http://research.microsoft.com/en-us/um/redmond/projects/z3/namespace_microsoft_1_1_z3.html. Could someone let me know where they or their replacements are?
2. On a related note I see several new concepts in the interface such as Probes and Tactics. Are these described or explained anywhere?
The interface for custom decision procedure is currently deprecated. They can still be used with the old solver API. See the following posts for additional information:
Using theory plugins with solvers
Custom simplifiers
Here is the full list of deprecated APIs.
Regarding tactics and probes, see this article, and the Z3 tutorials (Python and SMT 2.0) about it.
After changing the order of assertions in unsat query it becomes sat.
The query structure is:
definitions1
assertions1
definitions2
bad_assertions
check-sat
I sort bad_assertions with Python's sorted function, and this makes Unsat query Sat.
Z3 versions 4.0, 4.1; Ubuntu 12.04
Unfortunately, queries are quite large which makes them difficult to debug,
so I can provide any other additional info if.
Here are originally unsat query with marked lines for mixing, and a simple python script to mix lines in the query.
I managed to reproduce the problem reported in your question. Both examples are satisfiable. The script that produces unsat is exposing a bug in the datatype theory. I fixed the bug, and the fix will be available in Z3 4.2. Since this is a soundness bug, we will release version 4.2 very soon. In the meantime, you can workaround the bug by using the option RELEVANCY=0 in the command line.
From your description it sounds like a bug.
sat/unsat should of course not depend on ordering.
If packaging up a repro is difficult, then one way to help us debug
the problem, once you have confidence in what triggers the bug,
is to use "open_log()" to dump a trace of all interactions with Z3.
You should use "open_log" before other calls to Z3.
We can then replay the log without your sources.