4.6 Quantification Optimisations
4.6.3 Moving Loop-invariant Expressions
In the previous subsection, we have seen that, thanks to common subexpression elimina- tion (Sec. 4.2), loop-invariant expressions in quantifications do not impair the constraint instance per se. Therefore, we are interested if there are cases, where moving a loop- invariant expressioninsidea quantification (and performing CSE) is preferable to moving it outside. Hence, we conduct a thorough comparison between the two equivalent represen- tations: the quantification where the loop-invariant expression is insidethe quantification (‘inside-representation’), and where the loop-invariant expression isoutsidethe quantifica- tion (‘outside-representation’). More formally, we compare ϕI.A⊕EI withA⊕! ϕI.EI
and determine which representation is preferable for specificϕ,⊕and⊕!.
In order to conduct a proper analysis, we need to consider the flatrepresentation of both expressions. The flat representation is obtained byflattening the expression to the propaga- tors provided by the target solver, which typically involves introducing auxiliary variables and additional constraints (see Sec. 3.3.2 for more details). Flattening is a strictly solver- dependent procedure, however, considering every possible combination of propagators in the target solver is out of scope of this analysis. Therefore, we restrict our analysis to solvers that provide n-ary conjunction, n-ary disjunction and n-ary summation propaga- tors, which holds for most constraint solvers. Furthermore, during flattening we need to take into account if the ‘to-be-flattened’ expressionE is nested in another expression: ifE is not nested in another constraint,E is flattened to a propagator (constraint), otherwise, if E is nested, e.g. in ‘A⇒ E’,E is flattened to an auxiliary variable. If an expressionE is flattened to a constraint, it is denoted by E, ifE is flattened to an auxiliary variable, it is denoted in lowercase, i.e.e.
Note, that the reformulation to the respective inside- and outside-representation is im- plemented in TAILORand performed during preprocessing as part of normalisation. This means that every quantifier that contains a loop-invariant expression can be reformulated either into the inside or outside representation. An empirical analysis of the differences in loop-invariant representations can be found in the Chapter on Experiments, in Sec. 8.5. Note, however, that only one kind of quantification optimisation fired to the large set of problem classes we consider. The remaining optimisations have each been tested on con- structed examples, but require a more thorough investigation in practical problems, which is an item of future work.
In summary, we compare the inside-representation with the outside-representation at flat level considering both the nested and unnested case, assuming that the target solver pro- vides n-ary conjunction, disjunction and summation propagators. Note, that we assume that all common subexpressions that result from theinside-representation are eliminated. We start our investigation with the universal quantifier.
Moving Loop-invariant Expressions in Universal Quantifications
We consider universal quantifications ∀IEI that can be combined with a loop-invariant
expressionA, such that
(∀IA⊕EI)≡A⊕!(∀IEI) (4.6)
which holds for operators⊕ =⊕! =∧, ⊕= ⊕! = ∨and⊕ =⊕! =⇒. In the following,
we compare both representations for each operator. Note, that it not necessary to consider the case (∀IEI ⊕A) ≡ (∀IEI)⊕! A since all operators for which this equation holds
(i.e. ∧ and ∨) are commutative and associative and thus covered by Equation 4.6. In
the following we consider all three cases and will see that the inside-representation can sometimes be preferable to theoutside-representation.
Case 1: (∀IA∧EI)≡A∧(∀IEI)
Since∀corresponds ton-ary conjunction, which is commutative and associative, Equation
4.6 holds for⊕=⊕! =∧. The flat representation in the unnested and nested case are given
in Tab. 4.1. Evidently, theinside- andoutside-representation yield practically the same flat constraints (the only difference being a permutation of arguments). Hence we conclude that it makes no difference if the loop-invariant expressionA is moved in- or outside the universal quantification with⊕=⊕! =∧.
Case 2: (∀IA∨EI)≡A∨(∀IEI)
The second case follows the law of distributivity of conjunction and disjunction, i.e. A∨
(B ∧C) ≡ (A∨B)∧(A∨C). Tab. 4.2 shows the flat representations for inside- and
∀-CASE 1 inside-representation outside-representation Original (∀IA∧EI) A∧(∀IEI) Unrolled (E1∧E2∧ · · · ∧Ek∧A) A∧(E1 ∧E2 ∧ · · · ∧Ek) Flat (unnested) E1 A E2 E1 . . . E2 Ek . . . A Ek
Flat (nested) auxq⇔(e1∧e2∧ · · · ∧ek∧a) auxq ⇔(a∧e1∧e2∧ · · · ∧ek)
Summary
unnested k+ 1constraints k+ 1constraints
nested 1 constraint, 1 aux. variable 1 constraint, 1 aux. variables Table 4.1: Case 1of comparinginside- andoutside-representation.
expressionAinsidethe quantification, yieldskbinary constraints, while movingAoutside the quantification yields onek-ary and one binary constraint, introducing one Boolean aux- iliary variable. Obviously, the number of constraints of theinside-representation increases linearly withkwhile the number of constraints of theoutside-representation is constant and only one constraint’s arity increases linearly with k. The choice of which representation is preferable is not obvious in the unnested case. In an empirical investigation on some constructed examples we have not observed a difference in the performance (wrt solving time and search space) of both representations.
In the nested case, theoutside-representation yields a constant number of constraints with respect to k: 2 constraints and 2 auxiliary variables, where only the constraint arity in- creases withk. On the other hand, with theinside-representation, the number of constraints and auxiliary variables increases linearly with k. Therefore, the outside-representation is preferable in the nested case for⊕=⊕! =∨.
Note, that if the loop-invariant expressionAis a constant expression, then both representa- tions are the same: ifAevaluates totrue, then both (∀Itrue∨EI)andtrue∨(∀IEI) evaluate
totrue. Otherwise, ifAis false, both (∀Ifalse∨EI)andfalse∨(∀IEI) evaluate to∀IEI.
∀-Case 3: (∀IA ⇒EI)≡A ⇒(∀IEI)
The third and last case considers⊕=⊕! =⇒, following from the fact thatA⇒(B∧C)≡
(A⇒B)∧(A⇒C). Tab. 4.3 depicts the flat representations for the unnested and nested case.
We start with the unnested case.
∀-CASE 2 inside-representation outside-representation Original (∀IA∨EI) A∨(∀IEI) Unrolled (A∨E1)∧ · · · ∧(A∨Ek) A∨(E1∧E2∧ · · · ∧Ek) Flat a∨e1 aux⇔(e1∧e2∧ · · · ∧ek) (unnested) a∨e2 a∨aux . . . a∨ek
Flat aux1 ⇔(a∨e1) aux1 ⇔(e1∧e2∧ · · · ∧ek)
(nested) aux2 ⇔(a∨e2) auxq ⇔(a∨aux1)
. . .
auxk⇔(a∨ek)
auxq⇔(aux1∧aux2∧ · · · ∧auxk)
Summary
unnested 0 aux. variables, 1 aux. variable,
k constraints 2 constraints
nested k+ 1aux. variables, 2 aux. variables,
k+ 1constraints 2 constraints
Table 4.2: ∀-Case 2of comparinginside- andoutside-representation.
tion, given in brackets ‘[’ and ‘]’, which we discuss separately below. The unnested case is similar to that in Case 2, where the more efficient representation is not straight forward. Theinside-representation yieldskbinary constraints; theoutside-representation yields one k-ary and one binary constraint, introducing one auxiliary variable. In our empirical evalu- ation theinside-representation clearly dominated theoutside-representation in solving time on the same search space.
In the alternative inside-representation, we have a ⇒ Ei instead of a ⇒ ei. Recall
the difference between Ei and ei: Ei corresponds to the flat constraint representing Ei,
while ei corresponds to the auxiliary variable representing Ei. Hence, Ei introduces
less overhead, since it does not introduce an additional auxiliary variable, as ei does.
Therefore, the alternative flat inside-representation, a ⇒ Ei, introduces k fewer auxil-
iary variables than a ⇒ ei, but also k fewer auxiliary variables than the corresponding outside-representation, which flattens all Ei to ei. Note, that the alternative represen-
tation is only available for constraint solvers that provide a ‘reify-imply’ propagator of the form var⇒propagator where propagator is an arbitrary propagator (e.g. the solver MINIONsupports reify-imply). Surprisingly, in our experimental evaluation, the alternative
inside-representation performs worse than the original inside-representation and slightly
better than the outside-representation. In summary, in the unnested case, our empiri- cal analysis (Sec. 8.5) suggests that the standard inside-representation is preferable for
∀-CASE 3 inside-representation outside-representation Original (∀IA⇒EI) A⇒(∀IEI) Unrolled (A⇒E1)∧ · · · ∧(A⇒Ek) A⇒(E1∧E2∧ · · · ∧Ek) Flat a⇒e1 [a ⇒E1] aux⇔e1∧e2∧ · · · ∧ek (unnested) a⇒e2 [a ⇒E2] a⇒aux . . . a⇒ek [a⇒Ek]
Flat aux1 ⇔(a⇒e1) [aux1 ⇔(a ⇒E1)] aux1 ⇔e1∧e2∧ · · · ∧ek
(nested) aux2 ⇔(a⇒e2) [aux2 ⇔(a ⇒E2)] auxq ⇔(a ⇒aux1)
. . .
auxk ⇔(a ⇒ek) [auxk⇔(a⇒Ek)]
auxq ⇔(aux1∧aux2∧ · · · ∧auxk)
Summary
unnested 0 aux. variables 1 aux. variable
kconstraints 2 constraints,
[saves up tok flat. variables]
nested k+ 1aux. variables 2aux. variables
k+ 1constraints, 2 constraints,
[saves up tok flat. variables]
Table 4.3: ∀-Case 3 of comparing inside- and outside-representation. The alternative
inside-representation is given in brackets ‘[’ and ‘]’, representing the special case when
the solver provides a ‘reify-imply’-propagator.
In the nested case, theoutside-representation yields a constant number of constraints with respect to k: 2 constraints and 2 auxiliary variables, where only the constraint arity in- creases withk. On the other hand, with theinside-representation, the number of constraints and auxiliary variables increases linearly with k. Therefore, the outside-representation is preferable in the nested case for⊕=⊕! =⇒.
Again, if loop-invariantA is a constant, then both theinside- and outside-representations are the same: ifAevaluates tofalsethen both representations evaluate totrue. Otherwise, ifAevaluates totrue, both (∀I true⇒EI)and (true⇒(∀IEI)) evaluate to∀IEI.
Loop-invariant Expressions in Existential Quantifications
Now we consider existential quantifications∃IEIthat can be combined with a loop-invariant
expressionA, such that
This equation holds for the operators ⊕ = ⊕! = ∨ and ⊕ = ⊕! = ∧. Note, that it
not necessary to consider the case (∃IEI ⊕ A) ≡ (∃IEI) ⊕! A since all operators for
which this equation holds,∧and∨, are commutative and associative, and thus covered by
Equation 4.7. In the following two case studies we will see that theoutside-representation is generally preferable or equivalent to theinside-representation.
∃-CASE 1 inside-representation outside-representation
Original (∃IA∨EI) A∨(∃IEI)
Unrolled (A∨E1∨E2∨ · · · ∨Ek) A∨(E1∨E2∨ · · · ∨Ek)
Flat (unnested) (e1∨e2∨ · · · ∨ek∨a) (a∨e1 ∨e2∨ · · · ∨ek)
Flat (nested) auxq⇔(e1∨e2∨ · · · ∨ek∨a) auxq⇔(a∨e1∨e2∨ · · · ∨ek)
Summary
unnested 1 constraint 1 constraints
nested 1 aux. variable, 1 constraint 1 aux. variable, 1 constraint Table 4.4: ∃-Case 1of comparinginside- andoutside-representation.
Case 1: (∃IA∨EI)≡A∨(∃IEI)
Since∃corresponds ton-ary disjunction, which is commutative and associative, Equation
4.6 holds for⊕=⊕! =∨. The flat representation in the unnested and nested case are given
in Tab. 4.4. Evidently, theinside- andoutside-representation yield practically the same flat constraints (the only difference being a permutation of arguments). Hence we conclude that it makes no difference if the loop-invariant expressionA is moved in- or outside the existential quantification with⊕=⊕! =∨.
Case 2: (∃IA∧EI)≡A∧(∃IEI)
The second case follows the law of distributivity of conjunction and disjunction, i.e. A∧
(B ∨C) ≡ (A∧B)∨(A∧C). Tab. 4.5 shows the flat representations for inside- and outside-representation.
First, we consider the unnested case. Moving the loop-invariant expressionA inside the quantification, yields k reification constraints and 1 disjunction, introducing k auxiliary variables, while movingAoutsidethe quantification only yields 2 constraints without in- troducing any auxiliary variables. Since theoutside-representation results in far less con- straints and auxiliary variables, it is preferable to theinside-representation. Furthermore, propagation behaves differently in the two representations: in theoutside-representation,A can be propagated straight away, however in theinside-representation,Ais not propagated before the variables in theEis are pruned such that the disjunction holds.
In the nested case, again theoutside-representation dominates theinside-representation; the former using only 2 reification constraints and 2 auxiliary variables while the latter requires
∃-CASE 2 inside-representation outside-representation Original (∃IA∧EI) A∧(∃IEI) Unrolled (A∧E1)∨ · · · ∨(A∧Ek) A∧(E1∨E2∨ · · · ∨Ek) Flat aux1 ⇔(a∧e1) A (unnested) aux2 ⇔(a∧e2) (e1∨e2 ∨ · · · ∨ek) . . . auxk⇔(a∧ek)
(aux1∨aux2∨ · · · ∨auxk)
Flat aux1 ⇔(a∧e1) aux1 ⇔(e1 ∨e2∨ · · · ∨ek)
(nested) aux2 ⇔(a∧e2) auxq ⇔(a∧aux1)
. . .
auxk⇔(a∧ek)
auxq ⇔(aux1∨aux2∨ · · · ∨auxk)
Summary
unnested kaux. variables, 0aux. variables,
k+ 1constraints 2 constraints
nested k+ 1aux. variables, 2aux. variables,
k+ 1constraints 2 constraints
Table 4.5: ∃-Case 2of comparinginside- andoutside-representation.
k+ 1reification constraints andk+ 1auxiliary variables.
Note, that if the loop-invariant expressionAis a constant expression, then both representa- tions are the same: ifAevaluates totrue, then both (∃Itrue∨EI)andtrue∨(∃IEI) evaluate
totrue. Otherwise, ifAis false, both (∃Ifalse∨EI)andfalse∨(∃IEI) evaluate to∃IEI. Loop-invariant Expressions in Quantified Sums
Now we consider quantified sums!IEI that can be combined with a loop-invariant ex-
pressionA, such that
($ I A⊕EI)≡A⊕!( $ I EI) (4.8)
where⊕and⊕! are arithmetic operators. Equation 4.8 holds only for operator ⊕= ⊕! = ∗. Note, that the case (!IEI ∗A) ≡ (!IEI)∗ A is covered by Equation 4.8, since
multiplication is associative and commutative.
-CASE inside-representation outside-representation Original (!IA∗EI) A∗(!IEI)
Unrolled (A∗E1) +· · ·+ (A∗Ek) A∗(E1+E2+· · ·+Ek)
Flat aux1 =a∗e1 aux1 =e1+e2 +· · ·+ek
(nested) aux2 =a∗e2 auxq =a∗aux1
. . .
auxk =a∗ek
auxq =aux1+aux2+· · ·+auxk
Summary k+ 1aux. variables, 2aux. variables,
k+ 1constraints 2 constraints
Table 4.6:!-Case 1of comparinginside- andoutside-representation.
sums, being integer expressions, arealwaysnested in another expression, so we only con- sider the nested flat case. Evidently, theoutside-representation is preferable to theinside- representation since it usesk−1less constraints and auxiliary variables. In our experiments
on constructed examples we even observe a drastic difference in propagation. Unfortu- nately, reasoning about the general propagation behaviour in such a case is very difficult and in some cases impossible due to the vast variety of propagators in constraint solvers.
Summary
In this subsection, we have seen that, against our expectations, there exist cases where it is beneficial to move a loop-invariant expression insidea quantification. However, we have also seen cases where moving loop-invariant expressions outsidethe quantification is far more beneficial. Hence, in general, neither representation dominates the other.
Unfortunately, it is not always clear which representation is preferable, in particular when they are not comparable with respect to propagation: solvers provide many different prop- agators that work differently, so in some cases our analysis remains empirical. Moreover, we expect the preferable representation to depend onotherexpressions in the instance: for example, if the first representation shares common subexpressions in the instance, but the other does not, then the former might provide better propagation if the common subex- pressions are eliminated. Investigating the presence of common subexpressions in other constraints, however, is infeasible on instance level: consider an instance with n quan- tifications involving loop-invariant expressions. To determine the representation with the
highest number of common subexpressions, 2n combinations need to be considered and
compared, which, at instance level, is too expensive in time and memory.
The observations from this study can be easily integrated into tailoring by reformulating quantifications involving loop-invariant expressions into the preferable representation. This step is best performed during preprocessing, before the quantifications are unrolled.
4.7 Summary
This chapter covered instance optimisations, i.e. automated approaches to enhance con- straint instances and introduces novel instance optimisation techniques that are cheap and easily integrable into tailoring.
First, we presented established instance optimisation techniques in the field of Constraint Programming and Compiler Construction, some of which have inspired the instance opti- misation techniques that we propose during tailoring.
Second, we discussed each technique, starting with the elimination of redundant con- straints, followed by the most successful enhancement technique, common subexpression elimination and finally, the enhancement of quantifications.
We stress again thatnoneof the techniques proposed in this chapter are routinely performed by constraint solvers or flattening tools at present, which the exception of the MiniZinc to FlatZinc converter that has recently included CSE. Many constraint systems could benefit from these optimisation techniques since almost all constraint tools or solvers perform some translation of their input, in which the proposed techniques could be easily integrated.
T
AILORING
P
ROBLEM
C
LASSES
In this chapter, we discuss how to extend tailoringinstancesto tailoring problem classes. Problem classes represent a whole family of instances, whereparametersscale the features of the problem such that a complete parameter instantiation yields a problem instance. Constraint problems are typically formulated as classes, but solved as instances.
There are two main reasons for flattening problem classes: first, to support solvers that take problem classes as input: solvers such as Gecode [80], ECLiPSe [87] or Choco [19] are libraries of programming languages, where problems are formulated as programs and parameters can be specified at runtime. Second, it can be more time-efficient to perform flattening and enhancement techniquesonceat class level instead ofseveral times, i.e. once per instance.
The main contribution of this Chapter stems from the novelty of tailoring problem classes which has barely been investigated. Tailoring tools in constraints, such as the MiniZinc- Flatzinc converter [44], or the internal flattener of ECLiPSe Prolog [87] are limited to tailoring instances. Wuille and Schrijvers [89] have recently presented a translation from constraint instances formulated in the functional programming language Haskell to solver Gecode’s C++ representation, which in future will include class translations. However, so far, TAILOR, is the only tool to perform tailoring of constraint problem classes to our knowledge.
In this chapter, we show how to extend the procedure of instance-wise tailoring to class- wise tailoring. First, we motivate the idea of class-wise tailoring by presenting different applications tailoring whole problem classes. Second, we discuss how to represent prob- lem classes by extending the notion of expression trees from Chapter 3 so as to include parametrised expressions (Sec. 5.2). Third, we discuss necessary extensions of the instance tailoring procedure in order to process problem classes in Sec. 5.3. This includes a dis- cussion on the current limitations of class tailoring. Finally, we wrap up and conclude in Sec. 5.5.
Figure 5.1: instance-wise(top) andclass-wisetailoring (bottom) to solveinstances
5.1 Applications of Problem Class Tailoring
In this section, we discuss when and how tailoring whole problem classes can be useful and applied in practice, as opposed to the approach of tailoring instances as presented in Chapter 3. More specifically, there are two ways in which tailoring problem classes can be employed.
First, tailoring problem classes can be used to generate input for solvers that allow problem classes as input. Such solvers are typically libraries of programming languages (e.g. solver Gecode [80] is a library of C++, ECLiPSe [87] of Prolog or Choco [19] of Java). As an example, consider tailoring a problem class to a C++ program tailored to solver Gecode, a C++ library. All library-based solvers take constraints in aflatformat, i.e. constraints are not nested within another. Some library-based solvers, such as Gecode or ECLiPSe, allow nesting of constraint expressions (in case of Gecode, only linear and Boolean constraints). However, though these nested expressions are typically normalised and flattened so as to match n-ary constraints, CSE and other enhancements are not performed on them up to date [74]. Therefore, we conclude that it is more beneficial to flatten and enhance problem classes during tailoring instead of pushing those tasks onto the solver.
Second, tailoring problem classes can also be used when tailoring to a solver that accepts only instances. Typically, such solvers receive input byinstance-wise-tailoring, as we have seen in Chapter 3: a class is first merged with a parameter specification, yielding an unflat- tened instance which is then flattened to a flat instance (Fig. 5.1, top). As an alternative approach, we propose class-wisetailoring (depicted in Fig. 5.1, bottom) that consists of two tailoring steps: first, the problem class is tailored to a flat class in intermediate format,