Browsing Z3 source code, I came across a bunch of files referring to QF_FPA, which seems to stand for quantifier-free, floating-point-arithmetic. However, I don't seem to be able to locate any documentation regarding its state, or how it can be used via various front-ends (in particular SMT-Lib2). Is this an encoding of IEEE-754 FP? If so, which precisions/operations are supported? Any documentation would be most helpful..
Yes, Z3 supports floating point arithmetic as proposed by Ruemmer and Wahl in a recent SMT-workshop paper. At the current stage, there is no official FPA theory, and Z3's support is very basic (only a bit-blaster). We're not actively advertising this yet, but it can be used exactly as proposed in the paper by Ruemmer/Wahl (setting logics QF_FPA and QF_FPABV). At the moment, we are working on a new decision procedure for FPA, but it will be some time until that is available.
Here's a brief example of what an FPA SMT2 formula could look like:
(set-logic QF_FPA)
(declare-const x (_ FP 11 53))
(declare-const y (_ FP 11 53))
(declare-const r (_ FP 11 53))
(assert (and
(= x ((_ asFloat 11 53) roundTowardZero 0.5 0))
(= y ((_ asFloat 11 53) roundTowardZero 0.5 0))
(= r (+ roundTowardZero x y))
))
(check-sat)
The floating point logics are named QF_FP and QF_FPBV in v4.4.2. The link to the description of the theory in RELEASE_NOTES is broken. The correct page is http://smtlib.cs.uiowa.edu/theories-FloatingPoint.shtml. The proposed example above should be
(set-logic QF_FP)
(declare-const x (_ FloatingPoint 11 53))
(declare-const y (_ FloatingPoint 11 53))
(declare-const r (_ FloatingPoint 11 53))
(assert (and
(= x (fp #b0 #b00000000010 #b0000000000000000000000000000000000000000000000000010))
(= y (fp #b0 #b00000000010 #b0000000000000000000000000000000000000000000000000010))
(= r (fp.add roundTowardZero x y))
))
(check-sat)
Related
I am using the inbuilt interpolation feature on the latest (unstable branch) version of Z3. It works fine with SMT2 formulas containing integers. It does however, throw a iz3proof_itp::proof_error and a subsequent iz3translate::unsupported error (See Below) for the following SMT2 program -
(set-option :produce-models true)
(set-logic QF_AUFBV)
(declare-fun a () (_ BitVec 32))
(declare-fun b () (_ BitVec 32))
(declare-fun x1 () (_ BitVec 32))
(declare-fun x2 () (_ BitVec 32))
(declare-fun x3 () (_ BitVec 32))
(declare-fun y1 () (_ BitVec 32))
(declare-fun y2 () (_ BitVec 32))
(compute-interpolant
(= a (_ bv0 32))
(= b (bvneg (_ bv2 32)))
(= x1 (_ bv1 32))
(= y1 (_ bv0 32))
(= x2 (bvadd x1 a))
(= x3 (bvadd x2 b))
(= y2 (bvadd y1 a))
(bvsge x3 (_ bv0 32))
)
I tried it on the online version on rise4fun, and it worked fine. So after a bit of debugging, I found that the error is thrown from inside the function find_congruence_position in file iz3proof_itp.cpp.
So I made the following simple (maybe dangerous) change to the function to take care of the proof_error atleast for now -
Changing if(x == arg(arg(con,0),i) && (y == arg(arg(con,1),i)) at line 2431
to if((x == arg(arg(con,0),i) && (y == arg(arg(con,1),i))) || (y == arg(arg(con,0),i) && (x == arg(arg(con,1),i))))
I simply or'd the condition with its copy where x and y are interchanged - I had found that x and y sometimes have their values interchanged, maybe due to some proof techniques.
This did take care of the problem, I found that using equality and non-equality, along with bvadd or bvneg with BitVecs while computing interpolants worked. For example the following file worked -
(set-option :produce-models true)
(set-logic QF_AUFBV)
(declare-fun a () (_ BitVec 32))
(declare-fun b () (_ BitVec 32))
(compute-interpolant
(= a (_ bv0 32))
(= b (bvadd a (_ bv1 32)))
(= b (_ bv0 32))
)
But then I tried using relational operators, like bvsgt or bvsge, and it threw a new error -
terminate called after throwing an instance of 'iz3translation::unsupported'
I looked more into it, found out that the expression causing the problem was -
(not ((_ bit2bool 2) x2)) - it was assigned a PR_TH_LEMMA type and the UNKNOWN_THEORY kind. It seems that there is no support for such operations.
Since the online version is working, I'd like to know if it's possible to obtain that version. I read the previous questions and answers on StackOverflow, and I'm a bit confused. Some say BitVec theory is not supported (Although these posts are old), but then how is the online version working? Or am I doing something wrong? Any help is highly appreciated.
Actually, interpolation for bit vector arithmetic is not supported. It's interesting that it works on the web version. That version is quite old, however, and I think it predates the source-available version of Z3. I can think of two possible reasons why it works:
1) That version of interpolating Z3 used the "foci" prover as a backup. Whenever it encountered a part of the proof it didn't understand, it would package that part up as a lemma and reprove it using foci. The current version does not use foci (which is a third-party tool not available in source) and relies entirely on the proof generated by Z3.
2) The older version might have been doing bit-blasting in a different way. If all the non-local proof steps are purely propositional (using just the resolution rule) then it is easy to compute an interpolant.
As far as I understand it, however, computing interpolants from an efficient bit-vector solver (using all the known pre-processing tricks) is an open problem.
In fact, does the SMT-LIB standard have a rational (not just real) sort? Going by its website, it does not.
If x is a rational and we have a constraint x^2 = 2, then we should get back ``unsatisfiable''. The closest I could get to encoding that constraint is the following:
;;(set-logic QF_NRA) ;; intentionally commented out
(declare-const x Real)
(assert (= (* x x) 2.0))
(check-sat)
(get-model)
for which z3 returns a solution, as there is a solution (irrational) in the reals. I do understand that z3 has its own rational library, which it uses, for instance, when solving QF_LRA constraints using an adaptation of the Simplex algorithm. On a related note, is there an SMT solver that supports rationals at the input level?
I'm sure it's possible to define a Rational sort using two integers as suggested by Nikolaj -- I would be interested to see that. It might be easier to just use the Real sort, and any time you want a rational, assert that it's equal to the ratio of two Ints. For example:
(set-option :pp.decimal true)
(declare-const x Real)
(declare-const p Int)
(declare-const q Int)
(assert (> q 0))
(assert (= x (/ p q)))
(assert (= x 0.5))
(check-sat)
(get-value (x p q))
This quickly comes back with
sat
((x 0.5)
(p 1)
(q 2))
How does one use the 'repeat' and 'rotate_left' bitvector operations?
More generally, where can I find detailed documentation of bitvector operations in the SMT2 scripting format used by Z3?
Everything I find seems to just go to tutorials, or broken links:
https://github.com/Z3Prover/z3/wiki/Documentation
http://research.microsoft.com/en-us/um/redmond/projects/z3/old/documentation.html
Trying to understand "repeat", "rotate_left", and "rotate_right" by guessing has been frustating. I cannot figure out how to use them. For example
(display (repeat #b01))
(display (repeat #b01 3))
(display (repeat 3))
(display (rotate_left #b0001 2))
gives
"repeat expects one non-zero integer parameter"
"repeat expects one argument"
"operator is applied to arguments of the wrong sort"
"rotate left expects one argument"
Where is the documentation? Hoping they didn't explain because all of this is standard, I also looked at smt-lib.org but that doesn't list these details either. So frustrating.
In addition to dejvuth's answer:
The SMT language is well documented (see smt-lib.org), for this particular issue the FixedSizeBitVectors theory and the QF_BV logic definition are relevant. The latter contains the definition for repeat:
((_ repeat i) (_ BitVec m) (_ BitVec i*m))
- ((_ repeat i) x) means concatenate i copies of x
Apart from those, David Cok wrote an excellent SMT2 tutorial.
The names of functions in the Z3 API is the same as in SMT2 where syntax permits, in this case prefixed with Z3_mk_ to indicate that they are functions that construct Z3 expressions.
For your example, you should write something like this
(declare-const a (_ BitVec 2))
(declare-const b (_ BitVec 6))
(assert (= a #b01))
(assert (= b ((_ repeat 3) a)))
(declare-const c (_ BitVec 4))
(declare-const d (_ BitVec 4))
(assert (= c #b0001))
(assert (= d ((_ rotate_left 2) c)))
(check-sat)
(get-model)
You will get
sat
(model
(define-fun d () (_ BitVec 4)
#x4)
(define-fun c () (_ BitVec 4)
#x1)
(define-fun b () (_ BitVec 6)
#b010101)
(define-fun a () (_ BitVec 2)
#b01)
)
A good document that I usually use is its API.
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.)
I wrote z3 query in SMT2 format using QF_FPABV logic (quantifier-free floating-point arithmetic and bit-vector logic??).
The query is shown as follows:
(set-logic QF_FPABV)
(set-option :produce-models true)
(declare-fun f0 () (_ FP 8 24))
(declare-fun f1 () (_ FP 8 24))
(declare-fun f2 () (_ FP 8 24))
(assert (= f2 (* roundNearestTiesToEven f0 f1)))
(assert (>= f2 ((_ asFloat 8 24) roundNearestTiesToEven 3.0 0)))
(check-sat)
; (check-sat-using (then simplify solve-eqs bit-blast smt))
(get-model)
With
(check-sat),
I acquired the result and the model as:
sat
(model
(define-fun f2 () (_ FP 8 24)
(as +1.44919359683990478515625p127 (_ FP 8 24)))
(define-fun f1 () (_ FP 8 24)
(as +1.476345062255859375p0 (_ FP 8 24)))
(define-fun f0 () (_ FP 8 24)
(as +1.9632179737091064453125p126 (_ FP 8 24)))
)
This is what I expect.
However, if I use
(check-sat-using (then simplify solve-eqs bit-blast smt))
instead, I acquired:
sat
(model
;; universe for RoundingMode:
;; RoundingMode!val!0
;; -----------
;; definitions for universe elements:
(declare-fun RoundingMode!val!0 () RoundingMode)
;; cardinality constraint:
(forall ((x RoundingMode)) (= x RoundingMode!val!0))
;; -----------
;; universe for (_ FP 8 24):
;; FP!val!0 FP!val!1 FP!val!2 FP!val!3
;; -----------
;; definitions for universe elements:
(declare-fun FP!val!0 () (_ FP 8 24))
(declare-fun FP!val!1 () (_ FP 8 24))
(declare-fun FP!val!2 () (_ FP 8 24))
(declare-fun FP!val!3 () (_ FP 8 24))
;; cardinality constraint:
(forall ((x (_ FP 8 24)))
(or (= x FP!val!0) (= x FP!val!1) (= x FP!val!2) (= x FP!val!3)))
;; -----------
(define-fun f1 () (_ FP 8 24)
FP!val!2)
(define-fun f0 () (_ FP 8 24)
FP!val!1)
(define-fun f2 () (_ FP 8 24)
(* roundNearestTiesToEven FP!val!1 FP!val!2))
)
This model is not trivial to interpret...
For this simple example, I can just use (check-sat) to acquire human-readable results.
For some complex examples which contains non-linear operations,
I need to use (check-sat-using (then simplify solve-eqs bit-blast smt))
to avoid getting "Unknown" from z3...
Is there any document which can teach me to interpret such non-human-readable model?
The problem here is that the floating-point theory is not fully integrated with the SMT kernel of Z3 yet (I'm working on that in a separate branch). Because of that, the kernel treats all floating-point sorts as uninterpreted and therefore the model contains definitions of those sorts (the universes). At the moment, the best way to get around that is to call the fpa2bv tactic directly, e.g., change
(check-sat-using (then simplify solve-eqs bit-blast smt))
to
(check-sat-using (then simplify fpa2bv simplify solve-eqs bit-blast smt))
It is necessary to call the simplify tactic before calling fpa2bv and it is also necessary to call the simplifier before the bit-blast tactic, because those tactics rely on the simplifier to eliminate some particular expressions.
I think this is an issue with the model-completion code in Z3. There was a similar bug quite a while ago: Z3 FP logic: produces unexpected model
I thought the issue was already addressed and the code sample in that ticket now works correctly with z3 4.3.2, but apparently the code fragment you presented here triggers a similar problem that's not quite addressed yet.