I know parseSMTLIB2File Java API ignores certain commands in an SMT2 file. However, is there a way around it? I am generating smt2 files and use parseSMTLIB2File and solver.check() to parse and solve the constraints.
Now, I would like to use the unsat cores from the solver for some computation. I know I probably can do it using std in and out (here). However, this will be very inefficient for running the algorithms. Further, it is also not ideal to change the entire code base to switch every constraint generation through Z3 Java APIs.
Since the native C++ interface handles options and (tracked) assertions well. Hence, is there any way around it? How can I do this programmatically and efficiently?
Do other C++/C/Python parseSMTLIB2File APIs perform the same thing as Java's or they may read in additional things.
is there a way around it?
No. parseSMTLIB2File is not a complete interface to the solver, and it's not intended to be. The only options are to switch to the full API interface, or to the full text interface by emitting .smt2 files and passing those to Z3. The latter can be done via pipes instead of actual files, and many users are happy with the performance of that.
Related
Consider the following smt2 file generated with the help of Klee.
I am trying to evaluate it using z3. However, z3 hangs forever. Specifically, when the formula is UNSAT, z3 runs for ever and does not produce any result.
Is formula size is big?
Is there any issue while using logic theory AUFBV?
May I get some suggestions to improve the z3 performance.
Each assert statement having some common subexpression. Is it possible to improve the z3 performance by solving subexpression separately?
This is going to be impossible to answer as the SMT-lib file you've linked is undecipherable for a non-KLEE user. I recommend asking KLEE folks directly using your original program that gave rise to this. Failing that, try to reduce the SMT2Lib to a minimum and see if you can at least hand-annotate to see what it's trying to do.
Regarding your question for common subexpressions: You have to experiment to find out. But the way most such solvers are constructed, they /will/ discover common subexpressions themselves and reuse lemmas about them automatically as they convert your input to an internal representation. So, it'd surprise me if it helped in any significant way to do this by hand; unless the input is really massive. (The example you linked isn't really that big so I doubt that's an issue.)
When writing proofs I noticed that Agda's auto proof search frequently wouldn't find solutions that seem obvious to me. Unfortunately coming up with a small example, that illustrates the problem seems to be hard, so I try to describe the most common patterns instead.
I forgot to add -m to the hole to make Agda look at the module scope. Can I make that flag the default? What downsides would that have?
Often the current hole can be filled by a parameter of the function I am about to implement. Even when adding -m, Agda will not consider function parameters or symbols introduced in let or where clauses though. Is there something wrong with simply trying all of them?
When viewing a goal, symbols introduced in let or where clauses are not even displayed. Why?
What other habits can make using auto more effective?
Agda's auto proof search is hardwired into the compiler. That makes it fast,
but limits the amount of customization you can do. One alternative approach
would be to implement a similar proof search procedure using Agda's
reflection mechanism. With the recent beefed up version of reflection using
the TC monad,
you no longer need to implement your own unification procedure.
Carlos
Tome's been working on reimplementing these ideas (check out his code
https://github.com/carlostome/AutoInAgda ). He's been working on several
versions that try to use information from the context, print debugging info,
etc. Hope this helps!
I am using z3py I have a predicate over two integers that needs to be evaluated using a custom algorithm. I have been trying to get it implemented, without much success. Apparently, what I need is a procedural attachment, which is now deprecated. Could anybody tell me how I might impelement this in z3py? I understand that it involves use of Tactics, but I am afraid I haven't managed to figure out how to use them. I wouldn't mind using the deprecated way either, as long as it works.
There is no procedural attachment tactic. All tactics are implemented inside of Z3;
you can compose tactics from outside.
Previous versions of Z3 exposed a way to register a "user theory".
This was deprecated since (1) the source of Z3 is now available so users can compile with their custom theories directly, (2) the user-theory abstraction lacked proper support
for model generation. You can of course try previous versions of Z3 that have the user theory extension, but it is not supported.
Data and functions in Rascal can scatter in different source files, and when imported are merged accordingly. In other words, Rascal supports open data and open functions. So Rascal solves the expression problem? Is it designed so as to do?
I think to write that Rascal "solves" the expression problem, is a bit strong, but you could say that you can easily write openly extensible implementations of expression grammars in it. It was designed exactly for this, see http://www.rascal-mpl.org/from-functions-to-term-rewriting-and-back/
On the one hand, one can write programs which do not suffer from the expression problem in Rascal, precisely for the reason you said: both data and functions are openly extensible, and they work together via dynamically dispatching via pattern matching.
On the other hand, It is pretty easy to write non-extensible implementations as well in Rascal. In particular when using the current visit or switch statements, which are not openly extensible. Also if you write a set of mutually recursive functions, it may be pretty hard to extend them in an unforeseen manner. We are also working on language features to cover extending those kinds of designs. That is for the future.
Is it possible to serialize/deserialize a Z3 context (from C#)?
If not, is this feature planned ?
I think this feature is important for real world applications.
This is not directly supported in the current API. The next release will support multiple solvers, and we will provide commands for copying the assertions from one solver to another, and retrieving the assertions. With these commands, one can implement serialization by dumping the expressions in a file (in SMT 2.0 format). To deserialize, we just read the file back.
Note that, this solution can already be implemented using the current API if you keep track of the assertions you asserted into the logical context.
That being said, I've seen the following approach used in many projects that use Z3. They have their own representation for formulas. When they invoke Z3, they translate their representation into Z3's representation. In most cases the performance overhead is minimal. This approach gives them a lot of flexibility. Serialization is a good example. Some programming environment (e.g., Python) already provide some built-in support for serialization.