3

Is there a smart way to define bounded integers in Z3?

For example, lets say I want to define an integer variable "x" that can take values from [1,4]. I can do the following (I am using the Java API)

IntExpr x = ctx.mkIntConst("x");
solver.add(ctx.mkGT(x, ctx.mkInt(0))); // (assert (> x 0))
solver.add(ctx.mkLT(x, ctx.mkInt(5))); // (assert (< x 5))

However, I wonder if there is a smarter way to do this? Something that can automatically put upper/lower bounds on variables upon declaration. I came accross enumerations, but I am not sure if that is the best choice.

Thanks

Mohammed
  • 134
  • 6

2 Answers2

2

If they are powers of two, just use bit-vectors. Otherwise there's no easy way to do it (i.e., you are doing it right).

Nuno Lopes
  • 868
  • 6
  • 13
1

Unfortunately there isn't a "good" way to model such constraints. Bitvectors go far, assuming you're OK with machine arithmetic (i.e. modular) and your range fits nicely, as previously stated. Here's a previous related discussion: Is there an UnsignedIntSort in Z3?.

To properly support what you want, one would need predicate-subtyping. Theorem provers such as PVS and older versions of Yices (pre SMTLib variants in the 1.X series) supported such fancy types, with varying degrees of automation. If you need to stick to a modern SMT solver, you've no choice but to pepper your code with lots of bound-constraints, unfortunately. It can get pretty ugly pretty quick, of course, since you'd have to check bounds after every operation and define what it means to over/underflow. A proper theorem prover might be a better choice if respecting the bounds is essential.

alias
  • 28,120
  • 2
  • 23
  • 40
  • Thanks Levent, my only concern was the search space. Adding the bound-constraints will diffidently help Z3 pruning out significant number of irrelevant solutions, but those solutions still there and at one point, Z3 considered them. I may be mistaken and it might be the same, but If bounded integers exist in Z3, then it may be the case that those irrelevant solution were never there from the beginning. Anyway, I will stick to bound-constraints for now. – Mohammed Jun 30 '17 at 17:07
  • @Mohammed adding *redundant* upper and lower bounds to variables or combination thereof, can speed-up the search quite a bit even when those *constraints* could be inferred from existing constraints (e.g. see [How to compute WCET ....](http://dl.acm.org/citation.cfm?id=2597817&dl=ACM&coll=DL&CFID=780316479&CFTOKEN=19429447)). Having said this, predicting the run-time of an *smt* solver in this case is like tossing a coin, there are several factors that come into play, included the structure of the problem being considered, *i.e. how the Boolean part interacts with the LAR constraints*. – Patrick Trentin Jun 30 '17 at 22:13