2

For the same reasons than described here (user defined uninterpreted function) I want to define my own uninterpreted function

bvredxnor() : xnor over the bits of a given bitvector.

If I follow the example given here (example of universal quantifiers with C API) I don't know what sort to provide to the argument of my function (a bitvector)

I could create a bitvector sort of a given length, but I would like to have it for bitvectors of any length.

Looking at bitvector functions available in the C API, I noticed that the type of all arguments is Z3_ast, so I was thinking I could use the same generic type. But there is no function in the API that generate a Z3_ast sort... (writing this I feel i am touching the difference between types and sorts, but it is still a bit unclear)

Is the solution to use uninterpreted sorts? And if so, in doing that, wouldn't I loose some precision in my model by enlarging the type too much, while this artefact is only for debugging purpose? I mean, if I apply this function to a bitvector, will this work?

Thank you in advance,

AG.

Community
  • 1
  • 1
Heyji
  • 1,113
  • 8
  • 26
  • I finally ended up with a solution described here: http://stackoverflow.com/questions/7740556/equivalent-of-define-fun-in-z3-api/15145457#15145457 – Heyji May 05 '13 at 13:56

1 Answers1

2

SMTLib does not allow bit-vectors with variable lengths. That is, you cannot express problems that are parameterized over the bitvector lengths. The reason for this is that properties about bit-vectors do not necessarily hold parametrically over lengths, due to cardinality issues. To wit, consider:

exists x0, x1, x2, x3, x4. distinct [x0, x1, x2, x3, x4]

This property says there are at least 5 distinct bit-vector values. That is true if the domain of x has length at least 3, but not otherwise. So, the validity of the statement depends on the domain. You can also view this as a limitation of the first-order nature of SMTLib in general.

Of course, the above applies to SMTLib, and not necessarily to Z3. Leo and co have always been ahead of the curve, and Z3 does have many tricks that go beyond what SMTLib calls for. It'd be a pleasant surprise if Z3 does support some notion of parametric bit-vector problems in the way you are describing.

alias
  • 28,120
  • 2
  • 23
  • 40
  • Well, Z3_mk_bvredor() exists in the API and is independant of the length of the bitvectors. I simply want the same for xnor, which does not exists...and if I can do that, it should simplify the way my constraints look, which is easier to debugg. If I can do it for this function, I could apply the same principle to other functions as well – Heyji Apr 26 '12 at 18:42
  • I see. You don't actually want to prove things parametrically about varying-length bitvectors, but have a generic way of constructing such expressions. Looks like I misunderstood your question. – alias Apr 26 '12 at 22:36
  • @Heyji: I know it's a late response, but I think what you're asking for is a higher-order function that maps `n` to `_ BitVector n`. Z3 does not (currently) support higher-order functions. – GManNickG Oct 27 '12 at 18:42