My program creates a log of all z3 interactions with Z3_open_log(). Then in another program, I read it back with Z3_parse_z3_file(). It gives me the conjuction of all asserts made on the input. Let say I have two asserts: a1 and a2. Then by parsing the z3 file, I get (and a1 a2).
I would like to test (and (not a1) a2). How can I do that provided that I only get the conjuction of the two asserts, not a pair of asserts ? I could not find any function in the API that allows me to navigate into an AST, see if it is a conjunction and iterate over it.
If it is not the way I should go, what way would you recommand?
Thanks in advance,
AG.
As Pad already described in the comment above, you can use the API to traverse Z3 ASTs.
That being said, I have a couple of comments.
The logging is meant for debugging purposes. They are mainly used to report problematic traces. We have a new logging mechanism in Z3 4.0. It records all APIs, and allow us to have a faithful reproduction of the interaction between the host application and Z3.
The Z3 low level and Simplify formats are deprecated in Z3 4.0. Z3 still have some limited support for them.
Z3 4.0 has new C, C++, .NET and Python APIs. The C API is backward compatible, but I marked several procedures as deprecated. It is much easier to traverse and manipulate ASTs using the new APIs. Python API is already available online. Here is one example:
http://rise4fun.com/Z3Py/Cp
Here is another example that builds (and a1 a2), extract each children, and builds (and (not a1) a2).
http://rise4fun.com/Z3Py/8h
The following tutorial covers the new Z3 API:
http://rise4fun.com/Z3Py/tutorial/guide
Z3 4.0 will be released soon.
Related
I came across with a new dynamic language. I would like to create a coverage tool for that language. I started reading the source code of Perl 5 and Python coverage modules but it got complicated. It's a dynamic scripting language so I guess that source code of static languages (like Java & C++) won't help me here. Also, as I understand, each language was built in a different way and the same ideas won't work. But, the big concepts could be similar.
My question is as follows: how do I "attack" this task? What is the proper workflow I need to follow? What I need to investigate? Are there any books or blogs I can read about those kind of stuff?
There are two kinds of coverage collection mechanisms:
1) Real-time sampling of the program counter, typically by a clock running at 1-10ms. Difficulties: a) mapping an actual PC value back to a source line, b) sampling means you might not see execution of a rarely used bit of code, so your coverage reporting is inaccurate. Because of these issues, this approach isn't used very often.
2) Instrumenting the program so that it collects coverage as it runs. This is hard to do with object code... a) you have to decode the instructions to see where to put probes, and this can be very hard to do right, b) you have patch the source code to include the probes (this can be really awkward; a "probe" might consist of a 5 byte subroutine call but the probe has replace a single-byte instruction). c) you still have to figure out how to map a probe location back to a source code line. A more effective way is to instrument the source code, which requires pretty sophisticated machinery to read source, make probe patches, and regenerate the instrumented code for execution/compilation.
My technical paper Branch Coverage for Arbitrary Languages Made Easy provides explicit detail for how to do this in a general way. My company has built commercial test coverage tools for a wide variety of languages (C, Python, PHP, COBOL, Java, C++, C#, ProC,....) using this approach. This covers most static and dynamic languages. Some dynamic mechanisms are extremely difficult to instrument, e.g., eval() but that is true of every approach.
In addition to Ira's answer, there is a third coverage collection mechanism: the language implementation provides a callback that can inform you about program events. For example, Python has sys.settrace: you provide it a function, and Python calls your function for every function called or returned, and every line executed.
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.
This is with reference to a code suggested by Image Analyst given here. I am trying to generate C code for the algorithm. According to the document "Functions and Objects Supported for C and C++ Code Generation", MATLAB functions bwconhull and bwareaopen aren't readily supported for C / C++ code generation. What are the alternative functions I can use?
As you say, "bwconnhull" and "bwareaopen" aren't directly supported, but there are a number of foundational morphological functions that are available. Unfortunately, it's a bit of work to recreate those two routines using the smaller subset of functions (such as bwperim, bwselect, bwtraceboundary, and bwmorph). I believe it is actually possible, but the implementation will depend a bit on how exactly the routines are being used in your code.
A good guide to morphological operations and their relationship to each other is given in Gonzales and Woods (http://www.amazon.com/Digital-Image-Processing-3rd-Edition/dp/013168728X). In my old copy, it's in Chapter 8 under Morphology, but I think it's in Chapter 9 in newer editions.
Sadly, I know of no drop-in replacement, and you'll end up writing new ones and testing them in your application. On the plus side, morphological operations are very well explained and defined, and they relate to each other in an elegant way, so you should have all the tools you need in those other functions.
I have found the support for anonymous functions (lambda expressions) in Yices to be extremely helpful. I am now trying to use Z3 to implement a tool, but I have not been able to figure out if this feature is supported. I am invoking the tool using the -smt2 flag. thanks for your help.
AFAIK, lambda expressions are neither supported by Z3 (see this answer by Nikolaj Bjorner, one of the main Z3 developers), nor are they part of the SMTLib2 standard. Solvers that support lambda expressions, for example, Yices or veriT, support them as a custom extension to the SMTLib2 standard.
Depending on your needs (which you might want to illustrate by adding an example to your questions) you could try Z3 macros (define-fun), or a front-end like Z3Py that, compared with writing SMTLib code manually, simplifies working with Z3 a lot.
Back in the old days (ie. last year), we used to be able to use theory plugins as a hack to implement custom simplifiers. The Z3 doc even contained an example of "procedural attachments".
My question is very simple; is there any way to achieve the same goal with Z3 4.x?
In particular, I'm interested in a way to provide Z3 with externally computed evaluations for ground terms.
The theory plugins are currently marked as deprecated in Z3 4.x. So, although they can still be used to implement custom simplifier, the user would be forced to use deprecated APIs.
In Z3 4.x, custom simplifiers should be implemented as Tactics. The new build system makes it fairly easy to extend the set of available tactics.
I will try to write a tutorial on how to write tactics inside the Z3 code base.
Of course, in this approach, we have to write C++ code. The main advantage is that the tactic will be available in all front-ends (C, C++, .Net, Java, Python, OCaml, SMT2). Moreover, external developers can contribute their tactics to the Z3 codebase and they will be available for all Z3 users.
We also plan to support an API for creating a simplifier tactic based on callbacks provided by the user. This API would allow users to write "custom simplifiers" in their favorite programming language. This new API is conceptually simple, but there is a lot of "hacking" needed to make it available in every front-end (C++, .Net, Java, Python, OCaml) . It would be great if some external developer is interested in implementing and maintaining this feature. I'm sure it would benefit many users.