Consistency of Constraint Reifications by Reformulation

IT 14 043

Examensarbete 15 hp Juli 2014

Consistency of Constraint Reifications by Reformulation

Valentina Chapovalova

Institutionen för informationsteknologi

Teknisk- naturvetenskaplig fakultet UTH-enheten

Besöksadress:

Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0

Postadress:

Box 536 751 21 Uppsala

Telefon:

018 – 471 30 03

Telefax:

018 – 471 30 00

Hemsida:

http://www.teknat.uu.se/student

Abstract

Consistency of Constraint Reifications by Reformulation

Valentina Chapovalova

Many combinatorial problems can be formulated via constraints, i.e., relations between variables’ values to be satisfied in order for them to count as a solution for the problem. A lot of these combinatorial relations can be applied to an arbitrary number of arguments, these constraints are called global. Most global constraints (at least 82% in the Global Constraint Catalogue [1]) can be reformulated as a

conjunction of total functions together with a constraint which can be directly reified.

The reifications are useful in modelling several kinds of combinatorial problems, e.g., when there is a known number of satisfied constraints, but the exact set of satisfied constraints is a priori unknown.

In this thesis, we apply different methods in order to determine the consistency level (domain or bounds consistency) of the known reifications, in order to estimate whether the reifications would prune effectively if they were implemented.

Examinator: Olle Gällmo

Ämnesgranskare: Justin Pearson

Handledare: Pierre Flener

Contents

1 Introduction 7

2 Background 8

2.1 Constraints . . . . 8

2.2 Consistency Level . . . . 8

2.3 Reification . . . . 8

2.4 Reification Categories . . . . 11

2.4.1 TF . . . . 11

2.4.2 Sort . . . . 12

2.4.3 RIC . . . . 12

2.4.4 RSC . . . . 12

2.4.5 Logic . . . . 13

2.4.6 QLogic . . . . 13

2.4.7 Conj . . . . 13

2.4.8 GenPat . . . . 13

2.5 Modelling Constraints with Automata . . . . 14

2.6 Reification of Automata . . . . 14

2.6.1 Auto(0, 0) . . . . 16

2.6.2 Auto(0, j), j > 0 . . . . 16

2.6.3 Auto(i, j), i > 0 . . . . 17

2.7 Hypergraph . . . . 17

2.7.1 Types of Cycles . . . . 20

2.7.2 Summary . . . . 20

2.8 Restrictions . . . . 21

2.9 Compressed Reifications . . . . 21

3 Results 22 3.1 TF . . . . 22

3.2 Sort . . . . 24

3.3 RIC and RSC . . . . 26

3.4 Logic . . . . 27

3.4.1 General Results . . . . 27

3.4.2 Same Sign . . . . 29

3.5 QLogic . . . . 29

3.6 Conj . . . . 29

3.7 GenPat . . . . 30

3.8 Auto(i, j) . . . . 33

3.8.1 Auto(0, j) . . . . 33

3.8.2 Auto(i > 0, j) . . . . 34

3.9 Low-up Category . . . . 36

4 Conclusions 39 4.1 Summary . . . . 39

4.2 Future Work . . . . 39

4.2.1 Taking Restrictions into Consideration . . . . 39

4.2.2 Automata with More than One Counter . . . . 40

4.2.3 Low-up Propagator . . . . 40

4.2.4 Tractability . . . . 40

4.2.5 Bounds Consistency . . . . 40

4.2.6 QLogic . . . . 40

4.2.7 Unknown Reification . . . . 41

4.2.8 Implementation . . . . 41

A Consistency in the TF Category 42

B Consistency in the Logic Category 45

C Consistency in the Conj Category 46

D Consistency in the GenPat Category 47

E Consistency in Auto(i, j) 49

1 Introduction

A combinatorial problem is often modelled as a conjunction of constraints, i.e. relations posed between the problem’s variables. Traditionally, to solve a constraint satisfaction problem means to determine one or all possible values for the variables, such that all constraints are satisfied [9].

For some constraint satisfaction problem models, it is convenient to use the reification of a constraint C, that is the constraint C ⇔ b, where b is a Boolean (0 or 1) decision variable such that b = 1 if and only if C is satisfied.

The reifications of global constraints are useful, for instance, when the number of satisfied constraints from a set of constraints is known, but not which ones. This would be very useful if propagators for the reified con- straints are time-efficient (or, at least, not significally worse than the combi- nation of the constraints’ usual propagators and brute-force search.)

The hitch is that propagators for the reifications of most constraints are not available in most CP solvers, including for the Distinct constraint. This is why we want to examine the reifications and see whether it is possible to theoretically filter the old and new variables to domain or bounds consistency.

That would be an indicator for the existence of a time-efficient propagator for the reification and that the reifications for that specific constraint could improve performance in models of the kind described above.

In this work we try to determine the consistency level for the known reifications of as many global constraints as possible. First and foremost, we consider the reification categories described below. The tools of hypergraphs and automata constructions could help in finding reifications that are domain consistent. Bounds consistency has no described tools but will be discussed below.

In some cases, we can see constraints maintaining domain consistency when reified and in some cases we need to alter the standard reification [3]

slightly in order to make it domain consistent. However, for some categories we cannot prove that domain consistency can be achieved in the general case, with the methods we use.

In this work, we assume that the reader is familiar with the specifications

for all the global constraints. In any case, it is possible to consult the Global

Constraint Catalogue [1] online.

2 Background

2.1 Constraints

Definition 1. A constraint C(A) on arguments A is a relation of arity n (where n is the number of the variables) over the Cartesian product of the variables’ domains. A solution to C(A) is an assignment of values to the set of variables of A (from their respective domains), such that the constraint holds.

Definition 2. A global constraint is a constraint where the corresponding relation can have arbitrary arity.

We say that a value, assigned to a particular variable, participates in a solution if all the other variables could be assigned in such a way that the constraint holds.

In this work we consider only global constraints.

2.2 Consistency Level

There are different levels of consistency that can be achieved at a fixpoint for a propagator (i.e., an algorithm that eliminates impossible solutions).

Definition 3. If every value of every domain participates in a solution, then we say that domain consistency is achieved.

Definition 4. If every lower bound and upper bound of the domain of every variable participates in solution, then we have achieved bounds consistency.

From the definitions follows that domain consistency always implies bounds consistency, but the opposite does not generally hold. Thus, proving domain consistency is a stronger result for any propagator.

Through this work, we use the terms “propagator” and “constraint” syn- onymously, since the global constraints defined in the field so far all have (some) known propagators. When we say that a constraint or propagator is

“tractable”, we mean that, given a partial solution, a solution to the whole problem can be obtained by backtrack-free search.

2.3 Reification

Definition 5. The reified version of a global constraint GC(A) is a con- junction R(A) ∧ (C(A) ⇔ b), where R(A) ∧ C(A) is logically equivalent to GC(A). R(A) denotes restrictions on the variables, e.g., on the variables’

domains, C(A) is a condition on the arguments, and b is a Boolean variable.

Example 6. The constraint nequivalence n, m, hvi ^{`</sup>
, where n and hvi <sup>`} are the variables, is satisfied if and only if n is the number of distinct re- mainders obtained by dividing the variables of the collection hvi ^` by m [1].

For example, nequivalence(2, 3, (var −3, var −2, var −5, var −6, var − 15, var − 3, var − 3) is satisfied, since:

(mod 3) 3 ≡ 0, 2 ≡ 2, 5 ≡ 2, 6 ≡ 0, 15 ≡ 0, 3 ≡ 0, 3 ≡ 0, and the array (0, 2, 2, 0, 0, 0, 0) contains two distinct values, which is equal to the value of n.

The constraint has several restrictions (in addition to the restrictions on the types of some of the variables), otherwise it can never be satisfied:

• n ≥ min(1, `)

• n ≤ min(m, `)

• m > 0

The restriction m > 0 can be checked before propagation, since m is a fixed integer. The other two are included in the reification:

R(n, m, hvi <sup>`</sup> ) = n ≥ min(1, `) ∧ n ≤ min(m, `)

In this case, the restrictions can be checked in constant time, if ` and n are given. Both of them are simple tractable constraints. The restrictions of a constraint should be satisfied even if the negation of the constraint holds, and that is why R(n, m, hvi <sup>`</sup> ) is separated from the reified part, i.e., the part C involved in the equivalence with the Boolean b.

The conditions on the variables express the meaning of the constraint. In this case, the condition is the nequivalence constraint itself, since it is tractable given the arguments (i.e., a TF constraint, see Definition 8). We get the reification:

C(n, m, hvi <sup>`</sup> ) = nequivalence(num, m, (w 1 , w <sub>2</sub> , . . . , w <sub>`</sub> ))∧(num = n) ⇔ c ∧ (w 1 = v 1 ) ⇔ b 1 ∧ · · · ∧ (w ` = v ` ) ⇔ b ` ∧ (c ∧ b 1 ∧ · · · ∧ b ` ) ⇔ b

In general, C is often reformulated as a conjunction of a number of tractable and one core reifiable constraints. In [3], the restriction part is omitted from the reification formulations, which is why later we use the term reification meaning only the conditions’ part.

It seems that reifications only make constraints more complicated, and

that is true in some cases. The point is that we want to be able to propagate

the variables’ domains even if we do not know whether the constraint holds.

For example, we could know that two out of five given constraints hold, and try to propagate from there, including propagation on the auxiliary Boolean variables. With reifications, we can negate constraints (i.e., state that they do not hold, by enforcing b = 0). Since we aim for the conditions to be tractable, the reifications facilitate checking satisfiability, if the Boolean has a given value.

Definition 7. A core reifiable constraint can be written as a Boolean ex- pression containing linear equalities, inequalities and logical expressions of Boolean variables.

Definition 8. A constraint is a total function (TF)m when one or more of the constraint’s variables can be uniquely computed if all its other variables are assigned.

Example 9. alldifferent is not TF, since the property that all values are distinct is not functionally expressible.

Example 10. sort is TF, since if all variables in the first array are given, then there is a unique array which is equal as a set to the first one, but is also sorted.

Definition 11. A global constraint GC(A) has the reification

R(A) ∧ CF ₁ (A ₁ , V ₁ ) ∧ CF ₂ (A ₂ , V ₂ ) ∧ · · · ∧ CF _p (A _p , V _p ) ∧ (CN (A _p+1 ) ⇔ b) if and only if the following conditions hold [3]:

• R(A) implies that CF i (A i , V i ) is a TF for 1 ≤ i ≤ p.

• For 1 ≤ i ≤ p, V _i are variables that do not occur in A.

• CN (A _p+1 ) is a core reifiable constraint.

• For 2 ≤ i ≤ p, V _i and V ₁ ∪ V ₂ ∪ · · · ∪ V _i−1 are disjoint, i.e., V _i represents the newly introduced variables.

• For 1 ≤ i ≤ p, V _i is a non-empty subset of A _i+1 ∪ · · · ∪ A _p+1 , i.e., all newly introduced variables are used at least once later on.

• For 1 ≤ i ≤ p + 1, A _i ⊆ A ∪ V ₁ ∪ · · · ∪ V _i−1 for 1 ≤ i ≤ p + 1, i.e., if

the original arguments A and the introduced variables V 1 , . . . , V i−1 get

fixed, then A _i is fixed as well.

The formal definition of reification gives us a very useful tool of prop- agating global constraints. Every constraint is decomposed into other TF constraints, in such a way that variable assignment can be done in a canon- ical order.

Reifications of global constraints can be divided into different categories, depending on the final structure of the reification. Of course, the reification for each global constraint is not uniquely defined, i.e., a constraint can belong to several different categories at the same time. The categories below are present in the reifications defined in [2].

2.4 Reification Categories

2.4.1 TF

A TF constraint is often used in the reification itself. Such constraints could also have implied conditions, which do not constitute any part of the de- pendency function. These implied conditions are expressed using auxiliary variables and are directly reifiable.

Example 12. The constraint GCC(hx 1 , . . . , x _n i, hv ₁ o ₁ , . . . , v _m o _m i) has no implied conditions and can be reified as follows:

GCC(hx 1 , . . . , x _n i, hv ₁ p ₁ , . . . , v _m p _m i) ∧ (o ₁ = p ₁ ∧ · · · ∧ o _m = p _m ) ⇔ b Example 13. The TF constraint

graph crossing(ncross, hsucc i 1 , x ₁ , y ₁ , . . . , succ i _n , x _n , y _n i) has several im- plied conditions, therefore the reification contains other parts than the con- straint itself and the Boolean condition on the variable equalities.

Implied conditions and restrictions for graph crossing(ncross, nodes):

• ncross ≥ 0 (we assume this is true, a prerequisite for posing the constraint).

• ∀i : succ _i [x, y] ∈ nodes

• ∀i : nodes.succ i ≥ 1

• ∀i : nodes.succ ⁱ ≤ |nodes|

Reification:

graph crossing(a, hsucc j 1 , z ₁ , w ₁ , . . . , succ j _n , z _n , w _n i) ∧ (a = ncross) ⇔ b 1 ∧

sort lex ((x 1 , y 1 ), . . . , (x n , y n )) = ((z 1 , w 1 ), . . . , (z n , w n )) ∧ ((z ₁ , w ₁ ) < _lex (z ₂ , w ₂ ) < _lex · · · < _lex (z _n , w _n )) ⇔ b ₂ ∧ ( ^

k,`

(j _k = i _{`</sub> ⇔ (z <sub>k</sub> = x <sub>`} ∧ w _k = y _` ))) ⇔ b ₃ ∧ sort(hi 1 , . . . , i _n i, hm ₁ , . . . , m _n i) ∧

(m 1 ≥ 1) ⇔ b 4 ∧ (m _n ≤ n) ⇔ b ₅ ∧

(b ₁ ∧ b ₂ ∧ b ₃ ∧ b ₄ ∧ b ₅ ) ⇔ b 2.4.2 Sort

Constraints that use the TF constraint sort in the reification. Often used when there is an implied non-TF condition about the differences of some variables’ values.

Example 14. The constraint alldifferent(hv 1 , . . . , v _n i) is reified via sort in the following way:

sort(hv 1 , . . . , v _n i, hw ₁ , . . . , w _n i) ∧ (w ₁ < w ₂ ∧ · · · ∧ w _n−1 < w _n ) ⇔ b 2.4.3 RIC

Directly reifiable integer constraints, meaning that there is a built-in propa- gator for these integer constraints in any solver.

Example 15. leq(x, y) is directly reifiable:

(x ≤ y) ⇔ b 2.4.4 RSC

Directly reifiable set constraints, meaning that there is a built-in propagator for these constraints in any solver.

Example 16. The reification for in set is built-in:

(in set(val, set)) ⇔ b

2.4.5 Logic

A constraint that can be written as a logical expression of only built-in reifiable constraints.

Example 17. In the reification of all equal(hvi ⁿ ) we use different auxil- iary variables for different instances of the built-in reifiable constraint eq:

(v ₁ = v ₂ ) ⇔ b ₁ ∧(v ₂ = v ₃ ) ⇔ b ₂ ∧· · ·∧(v _n−1 = v _n ) ⇔ b _n−1 ∧(b ₁ ∧· · ·∧b _n−1 ) ⇔ b 2.4.6 QLogic

Constraints in this category enforce n-dimensional objects to not overlap.

The no-overlapping condition is a conjunction of built-in reifiable constraints, and the extra conditions can be expressed with core reifiable constraints as well.

2.4.7 Conj

Constraints that can be expressed as a conjunction of already reified con- straints. The conjunction can have varying length, depending on the number of arguments of the original constraint.

Example 18. k alldifferent(hhvi ^m

i ⁿ ) is reified as a conjunction of n alldifferent constraints:

n

^

i=1

alldifferent(hvi ^m

) ⇔ b _i

!

∧ (b ₁ ∧ · · · ∧ b _n ) ⇔ b

2.4.8 GenPat

Follows the general pattern of reification, but does not fall into any of the categories above (and neither can be reified via automata, see below).

Example 19. max index(imax, hi, vi ⁿ ) is reified in a straightforward way via two TF constraints. It does not belong to the Conj category, due to the last condition (max = val) ⇔ b, which does not only involve Booleans.

maximum(max, hvi ⁿ ) ∧ element(himax, vali, hi, vi ⁿ ) ∧ (max = val ⇔ b)

2.5 Modelling Constraints with Automata

A constraint can sometimes be modelled with a finite deterministic automa- ton, such that instead of accepting regular expressions it accepts sequences of so-called signature variables. Definitions of the different kinds of automata can be found in [7].

Example 20. The increasing([x 1 , . . . , x _n ]) constraint implies x ₁ ≤ x ₂ , x ₂ ≤ x ₃ , . . . x _n−1 ≤ x _n . If the signature constraints are (x ₁ ≤ x ₂ ) ⇔ s ₁ , (x ₂ ≤ x ₃ ) ⇔ s ₂ , . . . , (x _n−1 ≤ x _n ) ⇔ s _n−1 then increasing can be modelled with the automaton in Figure 1.

The constraint holds if and only if the automaton finishes in the accepting state leq.

leq gt

s i

¬s _i s _i

¬s _i

Figure 1: Automaton for the increasing constraint.

If a signature variable depends on j consecutive variables in the array, then the signature constraints are j-ary. In Example 20 we have j = 2.

Sometimes it is useful to implement automata with counters, i.e., variables with start values, that are updated during transitions.

Example 21. An automaton for the among constraint has one counter and is shown in Figure 2.

2.6 Reification of Automata

In order to reify a constraint, that can be modelled with an automaton A without counters, a new automaton is constructed. First, we construct an automaton, which is the negation of A, that has the same transitional constraints as A. This is done by copying the automaton (including the transitions to a non-state) and making all non-accepting states accepting and vice versa. There are other ways to construct a negation of an automation, especially when Boolean variables are involved (for example, see Figure 3).

After ¬A is constructed, the reification variable b connects A and ¬A in

the following way: in the start state, if b = 1, we follow a transition to A,

and if b = 0 we follow a transition to ¬A.

s : nvar = C {C ← 0}

in(var i , values){C ← C + 1}

not in(var i , values)

Figure 2: Automaton with one counter of the among constraint. The only state is accepting if and only if the value of the counter C is equal to nvar.

This automaton accepts the reification of the constraint modelled by A.

There is an alternative construction, where b is checked in the end instead of the beginning. In each accepting state an auxiliary variable b is set to 1 and in each non-accepting state it is set to 0. Then we change the automaton so that all the states are made accepting.

In this work, we implement both of the ways of automaton reification, to see if one of them has any advantages over the other.

If we have to reify an automaton with one or more counters, then we do something similar to the second way. We introduce the auxiliary counter c which is assigned to 1 in accepting and 0 in non-accepting states, and afterwards all states are made accepting. Then, if the expected values of other counters c 1 , . . . , c i are v 1 , . . . , v i then we conjugate the reification with the following condition:

(w 1 = v 1 ∧ · · · ∧ w i = v i ∧ c = 1) ⇔ b

where w ₁ , . . . , w _i are the values of the respective counters in the state where the automaton stops.

Therefore, we get several more categories that global constraint reifica-

tions can fall into:

2.6.1 Auto(0, 0)

The reification uses an automaton without counters and without signatures.

Example 22. XOR can be reified with the automaton in Figure 3. The reification holds if and only if the automaton path ends in an accepting state.

s

s ₁

i k

t ₁

j l

s ₂

w y

t ₂

x z

b = 0 b = 1

v = 0

v = 1

v ₁ = 0

v ₁ = 1

v ₂ = 0

v ₁ = 0 v ₁ = 1

v ₂ = 1

v = 0

v = 1

v 1 = 0

v 1 = 1

v ₂ = 1

v 1 = 0 v 1 = 1

v ₂ = 0

Figure 3: Automaton for the reification of the constraint xor.

(xor(v, v 1 , v ₂ ) is satisfied whenever v = (v ₁ 6= v ₂ )).

2.6.2 Auto(0, j), j > 0

The reification involves signature constraints of arity j > 0, but no counters.

The signature constraints are TFs and the rest of the constraint is modelled via an Auto(0, 0).

Example 23. The reification for the increasing constraint with the au-

tomaton A described in Example 20 is as follows. Construct the automaton

A ⁰ by adjoining A and ¬A with a reification variable b (see Figure 4).

Then the reification can be expressed as V n−1

i=1 (x _i ≤ x _i+1 ) ⇔ s _i
∧ A ⁰ , containing n − 1 TF signature constraints and the reified automaton.

s

leq ₁ gt ₁

leq ₂ gt ₂

b = 1

b = 0

s _i

¬s _i s _i

¬s _i

s i

¬s _i s _i

¬s _i

Figure 4: Automaton A ⁰ used in the reification of the increasing constraint.

2.6.3 Auto(i, j), i > 0

Several constraints use automata with i > 0 counters. As described above, we construct a new automaton with an extra counter so that if the constraint holds, the counters attain expected values, and they do not otherwise.

Example 24. An automaton A for the reification (according to the process described above) of the among constraint is found in Figure 5. The reifi- cation for the among constraint also includes signature constraints and the Boolean reification variable:

^

i

var i ∈ values ⇔ s ⁱ ∧Auto∧(C = nvar) ⇔ b ¹ ∧(w = 1) ⇔ b 2 ∧(b 1 ∧b 2 ) ⇔ b

2.7 Hypergraph

Definition 25. A hypergraph is a pair (V, E), where V is a set of vertices, and E is a set of edges, such that each edge is a (non-empty) subset of V [8].

Hypergraphs relate to constraints by the following construction. Consider

a reification of a constraint and build a hypergraph by representing all the

variables with corresponding nodes. If there is a TF or a directly reifiable

s

{C ← 0, w ← 0}

t

s _i = 1, {w ← 0} s _i = 0, {w ← 0}

{C = nvar, w ← 1}

Figure 5: Automaton for the reification of the among constraint. Both states are accepting, but the constraint is satisfied if and only if the value of the auxiliary counter w is equal to 1.

logical constraint present, then all variables included in it form an edge. If we have a conjunction of several tractable constraints, then this corresponds to several edges in the hypergraph.

Example 26. The reification of the constraint nequivalence is expressed in Example 6. Each TF or core reifiable constraint in the conjunction yields an edge of the hypergraph in Figure 6.

Figure 6: The hypergraph of the reification of the nequivalence constraint.

Definition 27. A Berge cycle is a sequence E ₁ , v ₁ , E ₂ , v ₂ , . . . , E _n , V _n , E _n+1

in a hypergraph H such that E 1 , . . . , E n are distinct edges of H, v 1 , v 2 , . . . , v n

are distinct vertices of H, E _n+1 = E ₁ and for all i between 1 and n we have v _i ∈ E _i ∩ E _i+1 [5].

If a hypergraph contains a Berge cycle, it is called Berge cyclic, otherwise it is called Berge acyclic. Berge acyclicity (and also α-acyclicity, defined below) means that the graph can be said to have a tree structure, i.e., that the corresponding constraint is tractable [4]. In other words, by beginning assigning variables in a suitable order, we can assign all of them so that the constraint is satisfied. This is valid for all values in the current domains of all corresponding variables, i.e., we have domain consistency.

A cycle in the hypergraph means that the reified constraint cannot be said to be domain consistent for sure. By this we mean that domain consistency is not guaranteed, i.e., for each edge every value of every domain participates in a solution which satisfies the condition corresponding to that particular edge, but in total this does not mean that every value of every domain participates in a solution (i.e., all edges satisfied). This happens because if a value for a variable participating in a cycle is fixed, we cannot guarantee that selecting values along different paths in the hypergraph afterwards does not end in a contradiction when the paths meet again.

If vertices in a graph can in some sense be ordered, without the graph necessarily being a tree, we call it α-acyclic. The precise definition is as follows.

Definition 28. Consider the following process done to a hypergraph:

1. Remove all vertices in the hypergraph that belong to at most one edge.

2. Remove edges, one at a time, if they are a subset of some other edge.

Repeat the steps in the process until nothing can be removed. If the result is an empty graph, the original hypergraph is called α-acyclic or just acyclic.

A Berge cyclic hypergraph can still be α-acyclic, see an example in Fig- ure 7.

Example 29. The hypergraph of the reification of the nequivalence con-

straint is α-cyclic, since the steps of the algorithm described above reduce

the graph to a (non-empty) hypergraph (see Figure 8). This indicates that

the reification cannot be guaranteed to achieve domain consistency, since the

hypergraph is not simply tractable.

Figure 7: A Berge cyclic hypergraph that is α-acyclic. One line is dashed only for the hyperedge to be clearly visible.

2.7.1 Types of Cycles

The background in this subsection is introduced for the first time in this work and cannot be found elsewhere.

The constraint reifications’ hypergraphs often contain particular sub- structures. For convenience, we define several types of such subhypergraphs.

If a hypergraph has three vertices such that each pair of them is con- tained in a separate edge, we call the subhypergraph consisting of the three variables and the three edges restricted to those variables a triangular cycle (for example, see Figure 10 where the edges and the variables b ₁ , b ₂ and v ₁ constitute a triangular cycle). Similarly, if such a cycle in the hypergraph consists of four vertices and four edges, we call it a square-like cycle (for example, several square-like cycles are present in Figure 9). Five edges in a similar way give pentagon-like cycles.

Completely analogously to the corresponding graph terms we use the terms tree, bipartite graph, and complete subgraph.

2.7.2 Summary

More than 80% of the global constraints in the Global Constraint Catalogue

(GCC) can be reified using the strategies described. Exactly how many of

each type can be found in [2] and is summarised in Table 1.

Figure 8: The reduced hypergraph of the reification of the nequivalence constraint.

2.8 Restrictions

In several reification categories we notice that the restriction part R(A) often is omitted from the hypergraph. In general the restriction of the constraint is satisfied as soon as it is posed, regardless whether the constraint should be satisfied or not. The restrictions that occur are often of the type var ≥ 0, that is domain-reducing. Thus we consider restrictions being part of domain predefinitions of the constraints’ variables.

2.9 Compressed Reifications

Notice that in [2] we are provided with constraint reformulations which some- times are in a condensed form (as in Example 18) and cannot be translated into a hypergraph directly. The condensed versions sometimes use constraints that are neither core reifiable nor TF, which is not allowed by Definition 11.

In such cases we consider only the expanded version (one that satisfies the

definition) of the reification.

Reification type Number of constraints in the GCC

TF 89

Sort 33

RIC 14

RSC 2

Logic 33

QLogic 17

Conj 21

GenPat 45

Auto(0, 0) 19

Auto(0, j > 0) 41

Auto(i > 0, j) 30

Table 1: The number of global constraints with reifications, by category.

3 Results

We study all the constraints in the Global Constraint Catalogue that have known reifications. For convenience, the results are presented one or two categories at a time, with one exception where we consider a special type of constraints separately (in Section 3.9). In all categories, we present all the constraints which are proved to achieve domain consistency or explain why there are none.

In this section, when we say that a constraint maintains domain consis- tency, we mean that the reification of the given constraint maintains domain consistency.

3.1 TF

A constraint falls into the TF category if one or more variables can be func- tionally dependent on others. In 67 out of 89 TF constraints we can prove that domain consistency is achieved. Namely, this happens when exactly one of the constraints’ variables is functionally expressed from others in the reification. The proof of this is as follows: in those cases we always get a Berge-acyclic graph with exactly two edges, one edge for the TF constraint and one for the reification of an equality, where the functionally dependent variable constitutes the intersection of these two edges.

Example 30. The constraint balance is reified via itself in the following

way:

balance(v, hx 1 , x ₂ , . . . , x _n i) = balance(w, hx 1 , x ₂ , . . . , x _n i) ∧ (v = w) ⇔ b The hypergraph of the reification then consists of two edges with one com- mon vertex w, thus it is Berge acyclic.

The complete list of constraints with this property can be found in Ap- pendix A. There are 67 TF constraints which have domain consistent reifi- cations due to this property.

As soon as two or more variables are functionally dependent on others, we get an alpha-cyclic hypergraph. These reifications thus have undetermined consistency, regardless of their structure aside from functional dependency.

Two of those constraints, namely among diff 0 and among interval, have other reifications that, after modification, attain domain consistency (see Section 3.8 and Table 8).

Example 31. The constraint map has two variables that are functionally dependent on others:

map(c, t, hi 1 , i ₂ , . . . , i _n , s ₁ , s ₂ , . . . , s _n , i) = map(c ⁰ , t ⁰ , hi ₁ , i ₂ , . . . , i _n , s ₁ , s ₂ , . . . , s _n , i)

∧((c = c ⁰ ) ⇔ b ₁ ) ∧ ((t = t ⁰ ) ⇔ b ₂ ) ∧ ((b ₁ ∧ b ₂ ) ⇔ b)

Figure 9: The cyclic part of the map hypergraph.

This yields a square-like cycle (see Figure 9) in the hypergraph of the

reification, thus it is neither Berge acyclic nor α-acyclic.

3.2 Sort

For the constraints in the Sort category our methods do not in general de- termine domain consistency. The constraints in the Sort reification category use the TF constraint sort. This is done for example in order to make sure that a set of variables attain different values (see Example 14). The variable array is sorted and also some condition is checked for each neighbouring pair of variables in the sorted array. The conjunction of these conditions, which mostly are strict inequalities (either “<” or “>”) or equalities, is reified. Be- low we show what happens in case of the condition being “<” (e.g., for the constraint alldifferent) and then, more generally, with any relation rel.

In general, the array to be sorted is of arbitrary size n, which depends on the number of arguments of the original constraint. But if the number of variables is at least three, then we get at least two Booleans expressing the truth value of the inequalities:

(v 1 < v 2 ) ⇔ b 1 ∧ (v 2 < v 3 ) ⇔ b 2

These Booleans are later used for expressing the reification variable b:

(b ₁ ∧ b ₂ ∧ . . . ) ⇔ b

Similarly, when we do not directly condition strict ordering, the variables next to each other still often are compared in this category, but possibly with some other relation:

(v ₁ rel v ₂ ) ⇔ b ₁ ∧ (v ₂ rel v ₃ ) ⇔ b ₂

Considering only these conditions, we already can deduce that a cycle appears in the hypergraph of this constraint’s reification, see Figure 10.

Therefore, we cannot determine the level of consistency for this reification with our methods.

We show one example of a constraint with a subgraph as in Figure 10 and explain why this kind of constraints is not guaranteed to achieve domain consistency. It is enough to provide a counterexample.

Example 32. Consider a small conjunction of constraints:

(v ₁ < v ₂ ) ⇔ b ₁ ∧ (v ₂ < v ₃ ) ⇔ b ₂ ∧ (b ₁ ∧ b ₂ ) ⇔ b with the following domains:

v ₁ ∈ {1, 2}, v ₂ ∈ {1, 2}, v ₃ ∈ {1, 2}, b ₁ ∈ {0, 1}, b ₂ ∈ {0, 1}, b ∈ {0, 1}

Figure 10: The cycle in the hypergraph of the majority of constraints in Sort category.

We see that the constraint problem is unsatisfiable, i.e., b can never achieve value 1. But that value (or any other value for that matter) cannot be pruned as a consequence of only the constraints of type v _i ∈ {1, 2}. This means that b = 1 does not participate in a solution, i.e., the constraint does not achieve domain consistency.

The rest of the constraints in the category Sort, namely allperm, in- comparable, same, those similar to same, k same, those similar to k same and permutation, have cyclic hypergraphs but for different reasons.

The constraints allperm, k same and those similar to k same contain a cycle of the same shape as the Sort constraints we have described in the beginning of this section. The case k same(hhvi ^m i ⁿ ) reified as

n

^

i=1

sort(hv i i ^m , hs i i ^m )

!

∧

n−1

^

i=1 m

^

j=1

s i,j = s i+1,j

!

⇔ b

is especially similar, since any projection onto the s _i s for a fixed j gives a cyclic triangle in the hypergraph, i.e., one for j = 1 in Figure 11.

The constraint allperm(hhvi ^m i ⁿ ) reified as

sort(hv 2 i ^m , hs ₂ i ^m )∧· · ·∧sort(hv n i ^m , hs _n i ^m )∧lex lesseq(hv 1 i ^m , hs ₂ i ^m ) ⇔ b ₂ ∧

· · · ∧ lex lesseq(hv 1 i ^m , hs _n i ^m ) ⇔ b _n ∧ (b ₂ ∧ · · · ∧ b _n ) ⇔ b

has a similar cycle because the whole arrays are compared (see Figure 12).

The constraints incomparable, same, those similar to same and per-

mutation have hypergraphs with many square-like cycles. This happens

because the reification of those constraints contains is either a comparison

of two arrays, one index at a time (and then the results of the comparisons

Figure 11: One of the many cycles in the reification hypergraph of k same.

Figure 12: One of the many cycles in the reification hypergraph of k same.

are adjoined by the final reification constraint containing the variable b), or, in case of permutation, just contain single conditions on each element of an array. The cycles appear because the whole array(s) are adjoined with an edge coming from the Sort condition.

Hence, none of the constraints in the Sort category can be proved to achieve domain consistency with our methods.

Similar issues occur with many of the constraints in the GenPat category, which we will discuss in Section 3.7.

3.3 RIC and RSC

Since RIC and RSC constraints are built-in to most solvers, and they are very easy to reify. The constraint C(A) of that type is reified as C(A) ⇔ b, since there are no restrictions (except in a few cases), on the variables’ domains.

C(A) for this category is a singe condition on all the arguments, thus the

hypergraph of the reification always has exactly one edge. This means Berge

acyclicity for the graph and domain consistency for the reifications in the RIC and RSC categories. There are 16 constraints of these two types in the Global Constraint Catalogue.

3.4 Logic

3.4.1 General Results

The constraints in the Logic category mostly have cyclic hypergraphs due to the complex logical formulas in the reification. The constraint calendar is not reified with a fixed logical formula, but from its description in [1] we can see that many subexpressions yield hypergraph edges that intersect due to variable sharing.

But there are several exceptions in the category. The constraints in Ap- pendix B all have Berge acyclic reification hypergraphs and thus achieve domain consistency.

All other constraints in the category have parts in their reification that yield at least one cycle in the hypergraph. Some cycles do not even depend on reification at all and appear in the original constraint hypergraph (we see this in cases where b is not present). In Table 2 we list logical expressions appearing in all of the constraints in the Logic category (with the exceptions of four constraints described in the appendix). Every expression gives at least one cycle in the reification hypergraph.

Notation: v i s, w i s and var i s denote constraint variables, not necessarily following the notation in [2]. rel stands for some relation (often equality or inequality). V here could in every case be replaced by W. (v, w) where v and w are variables means that these two variables are connected, possibly not by one edge but by a path of edges. The reification variable is as usual denoted by b, and other Boolean variables are denoted by b _i .

Part of reification Part of hypergraph structure V

i

V

j

v _i rel v _j or V

i

V

j

(v _i , v _j ) complete graph

 V

i

v _i rel v _i+1



⇔ b or

 V

i

(v _i , v _i+1 )



⇔ b

triangular cycles

 V

i

v _i rel var



⇔ b triangular cycles V

i

(v i , var 1 ) ∧

 P

i

v i rel var 2



triangular cycles

Part of reification Part of hypergraph structure V

i

V

j

(v _i , w _j ) complete bipartite graph P

i,j

(v _i , v _j )

!

⇔ b triangular cycles

Low-up structure (Sec- tion 3.9)

triangular cycles E.g. ((v, w, b ₁ ) ∧ (v, w, b ₂ )) ∧

(b ₁ ∨ b ₂ ) ⇔ b

triangular cycle(s), similar to the ones appearing for constraints in the Sort category.

E.g. (v ₁ rel w ₂ ) ∧ (v ₂ rel w ₁ ) ∧ (w 1 rel w 2 ) ∧ (v 1 rel v 2 )

square-like cycles

Table 2: Structures appearing in the hypergraphs of non-domain consistent global constraints in the Logic category

Every structure gives at least one cycle, but often their number is at least linear in the number of the variables, since in many cases the variable v _i is involved in a small cycle for each i.

Example 33. The step-by-step reification of the constraint cumulative(hs 1 d ₁ e ₁ r ₁ , . . . , s _n d _n e _n r _n i , limit) is described in [3]. For proof that our methods do not determine the consistency of the reification, we only need one of the steps (the last logical expression is omitted):

- For i 6= j: ((s _j ≤ s _i ∧ e _j > s _i ∧ s _i < e _i ) ∧ (r _ij = r _j )) ∨ (. . . )

Even here we can extract one small part of the conjunction that will be enough:

- For i 6= j: ((s _j ≤ s _i ) which means V

i6=j

(s j rel s i ) could be translated into a hypergraph which is a subgraph of the whole reification. This is represented by a general structure V

i

V

j

v _i rel v _j in Table 2, even though we do not consider cases where i = j.

The cyclicity of the structure arises from different edges connecting each pair of different s _i , s _j and does not depend on whether i could be equal to j or not.

Thus it is not important for our conclusion.

3.4.2 Same Sign

The constraint same sign(v 1 , v ₂ ) is listed in [2] as being in the Logic category and reified as:

((v ₁ ≥ 0 ∧ v ₂ ≥ 0) ∨ (v ₁ ≤ 0 ∧ v ₂ ≤ 0)) ⇔ b

Expanding the disjunction we see that v ₁ , b ₁ and b ₂ are involved in a cycle of edges (v ₁ , v ₂ , b ₁ ), (v ₁ , v ₂ , b ₂ ) and (b ₁ , b ₂ , b) (we do not even expand the conjunctions):

((v ₁ ≥ 0 ∧ v ₂ ≥ 0) ⇔ b ₁ ) ∧ ((v ₁ ≤ 0 ∧ v ₂ ≤ 0) ⇔ b ₂ ) ∧ (b ₁ ∨ b ₂ ) ⇔ b This makes the reification hypergraph Berge cyclic giving us a non-result.

This can be avoided with a different reification.

We can reify same sign instead with the help of the RIC constraint product ctr:

(product ctr(v 1 , v ₂ ) = w) ∧ (w ≥ 0) ⇔ b

which is equivalent to the previous reification since the product of two num- bers is non-negative if and only if they have the same sign (the number zero is considered having both signs which is evident in the original reification).

We transfer the constraint same sign into the Conj reification category, thus making one more constraint reification of this group domain consistent.

3.5 QLogic

QLogic is a category of constraints defined via a special language [6]. In this work we do not study constraints falling into that category, although we can state a hypothesis that all such constraints may achieve domain consistency due to the property described in Section 2.4.6, i.e., that its parts are expressed via core reifiable constraints.

3.6 Conj

Due to the complex structure of Conj constraints, we were not able to deduce domain consistency for any constraint, except increasing sum. Since there are only 21 constraints, we list the reasons for each one (for details, see Table 5) of the reifications yielding a cyclic hypergraph.

Each constraint in the Conj category falls under one of the following cases:

• The constraint increasing sum is a conjunction of a single sum ctr constraint (the “increasing” part being one of the restrictions). Thus it achieves the same consistency as sum ctr, which is domain consis- tency.

• The constraint is a conjunction of constraints where one or several of the conjunction terms have a reification with undetermined consistency.

The inheritance of cyclicity happens due to the fact that a reification of a conjunction is logically equivalent to a conjunction of reifications.

This means that one particular reification causing a cycle in its own hypergraph will cause a cycle in the whole structure.

• The constraint among seq resembles some constraints from the Logic category and has a hypergraph with triangular cycles for s ≥ 2, i.e., in general.

• The reification of the constraint consists of two automata (one for each array) connected by a third constraint. Since we reify both automata and then impose a logical expression involving both of the Booleans and the reification variable b, we connect the two automata with a new edge, causing a square-like cycle to appear.

• The constraint is a conjunction of several automata, with automata sharing variables. Then at least one cycle is bound to arise in the reification hypergraph. The situation is similar to the previous case, but here we omit the edge connecting the automata – instead they are connected by variable sharing. But the automata are connected with a reification edge as well, causing the hypergraph to contain a cycle.

The classification of the constraint reifications in this category is pre- sented in Appendix C.

3.7 GenPat

The constraints from the GenPat category cannot be placed into any other

category by definition, but follow the general pattern of reification. There-

fore, we can often find structures (e.g., logical formulae) in their reifications

similar to the ones described in the previous categories. Mostly these struc-

tures found in a part of a reification give the non-result about domain consis-

tency of a constraint. There are several exceptions, and in those cases we still

can refer to a previously described category. One can say that in GenPat we

do not find anything new, up to a couple of examples which we will mention

below.

All GenPat constraints fall into one of the following cases:

• Constraints, where a part of the reification is similar to ones present in the reifications from Logic, showing we have undetermined consistency with our methods.

• Constraints, similar to TFs. Either one or several functionally depen- dent variables are reified, yielding domain consistency in the first case and undetermined consistency in the second. These constraints are not in the TF category, since they do not follow the corresponding pattern exactly. Instead, the reification often consists of a conjunction of a TF constraint and another constraint of a different type (often logical but not just variable equality) where the latter one is reified.

• A conjunction of a Sort constraint, the related reification of a group of inequalities and some other constraint(s). This gives us constraints with undetermined consistency level for the same reasons as almost everything in the Sort category.

• Constraint which are very similar to RIC. There are two such con- straints (sum cubes ctr and sum squares ctr). These are of course domain consistent.

• Constraints in the low-up category (Section 3.9).

• Constraint with a special structure: correspondence, see Exam- ple 35.

In the cases mentioned above we do not always find identical structures to ones found in the categories described earlier, but by a kind of reduction we can prove that they still yield the same kind of cyclicity in a hypergraph.

Example 34. In the case of indexed sum the reification contains a part which reminds of the Logic category:

n

^

i=1

(s _i =

m

X

j=1

(ind _i = k _j ) · w _j ) ∧ . . .

This is similar to a structure that can be written as V

i

(s _i , P

j

k _j ) which in turn is similar to V

i

V

j

(s _i , k _j ). The final expression is equivalent to the structure V

i

V

j

(v _i , w _j ) in Table 2.

In each step the complexity of the hypergraph corresponding to the logical expression was the same or reduced. In the end we got an α-cyclic hypergraph, in this way yielding a non-result about domain consistency of the original constraint.

Example 35. The constraint correspondence has a unique reification.

The hypergraph has cycles but not of the types encountered before. The con- straint is reified in the following way:

n

^

i=1

element(p i , hti ⁿ , v _i )

!

∧ (f ₁ = v ₁ ∧ · · · ∧ f _n = v _n ) ⇔ b

When we expand the reification bracket to

(f ₁ = v ₁ ) ⇔ b ₁ ∧ · · · ∧ (f _n = v _n ) ⇔ b _n ∧ (b ₁ ∧ · · · ∧ b _n ) ⇔ b

it becomes evident that for each pair i, j the hypergraph contains a pentagon- like cycle, see Figure 13. Therefore, we cannot say for sure whether the constraint achieves domain consistency.

Figure 13: Cycles in the hypergraph of the correspondence constraint.

The different kinds of GenPat constraints as well as domain consistency

results are summarised in Appendix D.

3.8 Auto(i, j)

In general we cannot predict whether the reification of a constraint from Auto(i, j) category certainly attains domain consistency judging only from i and j. Even if i > 0, i.e., there are one or several counters and the hypergraph of the automaton already is Berge cyclic even without the reification, we can in some cases alter the reification hypergraph slightly in order to attain Berge acyclicity.

In each case, the hypergraph of the constraint reification can be con- structed by slightly altering the hypergraph of the automaton of the original constraint. In this section we study two examples from Section 2.6: the constraints xor and among.

3.8.1 Auto(0, j)

As we saw in Examples 22 and 23, the automaton for the reification of the constraint doubles its size when there are no counters. This happens due to the negation of the original automaton now being part of the whole automa- ton structure. We choose to place the reification variable b before both start states. Its value determines which half of the automaton will be relevant.

With this choice we will get the result in Proposition 37.

The reification hypergraph only needs one additional edge, concerning the reification variable. Simultaneously, all the state variables get larger domains (one value for the original automaton A and one value for the corresponding state in ¬A). In particular, we need to consider more possibilities for the values of the accepting states. The arity j of the signature constraints is irrelevant for the changes, since the corresponding part of the hypergraph stays exactly the same after reification.

In some cases, as with the constraint int value precede chain the automaton has variably many states. This case is in practice no different from others when we reify, since the number of states is determined when the constraint is posed. Thus the automaton has fixed size that is doubled, just like in the other cases, and the reified automaton hypergraph has a predetermined size as well.

Example 36. In the case of the constraint xor we can see that the hyper- graph is Berge acyclic before as well as after the reification (see Figures 14 and 15).

Proposition 37. The reification of a constraint from the category Auto(0, j) inherits the determined consistency level of the original constraint.

Constraint consistencies following from the proposition are presented in

Table 7.

Figure 14: The hypergraph of the xor constraint modelled by an automaton.

Figure 15: The hypergraph of the reified xor constraint.

3.8.2 Auto(i > 0, j)

Automata with counters are relatively easy to reify, if we do it in another way than the one described in Section 2.6.3. The satisfiability of the constraint depends only on the end value of the counters. Thus the idea is to involve the reification Boolean b only with the counters, posing the condition

b ⇔ ((C ₁ = V ALU E ₁ ) ∧ · · · ∧ (C _i = V ALU E _i ))

where C 1 , . . . , C i are the counters and V ALU E 1 , . . . , V ALU E i are their cor- responding values if the constraint is satisfied. The condition is enough to determine constraint satisfiability, so we ignore which states are accepting, because they are irrelevant for the reification.

Suppose there is exactly one counter. The described reification process

alters the hypergraph of the constraint only by addition of one edge, involving

the reification variable b and the counter. The reification process described

in Section 2.6.3 would have added one additional counter to the automaton

(regardless of the number of original counter), yielding at least one additional

edge of the same type and possibly many more edges involving the additional counter. Thus we do not consider that construction in Auto(1, j).

This strategy does not work with two or more counters (this concerns only the constraints arith sliding, ith pos different from 0 and sliding card skip0), since at least one square-like cycle is formed in the hypergraph of the reification. Instead, the old reification strategy could work better, but we leave this for future research.

Proposition 38. Hypergraphs of the constraints from the category Auto(1, j) inherit cyclicity when reified.

Proof. The inheritance is due to the fact that the hypergraph is extended by only one edge with two vertices, involving one new variable. No cycles can appear in this way, but the rest of the hypergraph structure is preserved.

Constraints with inherited cyclicity are listed in Table 8.

We have found no constraints in Auto(i > 0, j) which are Berge acyclic, only α-acyclic, so the latter property is preserved in several cases. We can modify the reification in order to make the corresponding hypergraph Berge acyclic, as in Example 39. All constraints that can be modified in such way in order to achieve domain consistency are presented in Table 8.

Example 39. Let us consider the example of the among constraint with the automaton in Figure 2. The hypergraph for the reification constraint is α-acyclic, but Berge cyclic:

Figure 16: A Berge cyclic hypergraph of the reified among constraint.

The cyclicity arises due to transition conditions sharing both the state and the counter. Let us reify the automaton in a slightly different way. This is possible since the automaton for the original constraint has only one state.

The reification will be Auto ∧ (c = nvar) ⇔ b, where A is the original automaton, but we also set the value of the state to be equal to s (the only state). Since the state is constantly s, we do not need to check that condition in the transitions, so the expressions with the state can be removed from the hypergraph.

Then the hypergraph for the reification becomes Berge-acyclic, i.e., the reification for the among constraint achieves domain consistency, see Fig- ure 17.

Figure 17: A reduced and Berge-acyclic hypergraph of the reified among constraint.

This result naturally holds for constraints modelled by automata with only one state, one counter and originally a Berge acyclic hypergraph. The reification alters the hypergraph only by introducing the Boolean b and con- necting it with an edge with the only counter variable. This step cannot introduce any cycles.

3.9 Low-up Category

We have already seen that there are similarities in the structures of con-

straints from different categories. We find, for instance, the same types of

structures in the hypergraphs of some Logic and Sort constraints, which gives us the non-result regarding domain consistency.

Since categories of reifications were meant to appear while dividing global constraints into groups with similar structure, we can invent ones of our own if we encounter some structure often enough.

In this section, we consider constraints with variables we call low and up, and conditions low rel x and x rel up with rel equal to < or ≤. We call constraints having that type of subconditions belonging to the Low-up category. Sometimes it could be one of the conjunction terms containing that structure (and none of the other terms), nevertheless we consider it being in the category.

Example 40. The constraint in intervals(v, hl, ui ⁿ ) is reified as ((v ≥ ` <sub>1</sub> ∧ v ≤ u <sub>1</sub> ) ∨ · · · ∨ (v ≥ ` _n ∧ v ≤ u _n )) ⇔ b

i.e., there are n subconditions equivalent to the type “low rel x and x rel up”

and no other terms. Hence, it belongs to the low-up category.

Example 41. The constraint gcc low up(hxi ⁿ , hv, l, ui ^m ) is reified as gcc(hxi ⁿ , hv _i , o _i i ^m _i=1 ) ∧ (` <sub>1</sub> ≤ o <sub>1</sub> ∧ o <sub>1</sub> ≤ u <sub>1</sub> ∧ · · · ∧ ` _m ≤ o _m ∧ o _m ≤ u _m ) ⇔ b There is one term which uses the TF constraint gcc, all other m terms are equivalent to the type “low rel x and x rel up”. Hence, it belongs to the low-up category.

This category consists of one Auto(i, j) constraint (among low up), three Logic constraints (domain, in intervals, relaxed sliding sum), one Conj constraint (among seq), and five GenPat constraints (gcc low up, gcc low up no loop, same and gcc low up, sliding distribution, sliding sum). That is in total 10 constraints.

Those constraints are not guaranteed to achieve domain consistency. As soon as we have the conditions described above and reify them, we get a triangular cycle in the reification hypergraph. As we have seen before, as in Example 32, it is impossible to propagate any values and we cannot guaran- tee that every value participates in a solution. Any example in the low-up category would be analogous.

But discovering a small common structure in different types of constraints

could potentially give positive results. It is possible to write a new propagator

especially for this low-up-condition. Theoretically, we can always write a

propagator which is domain consistent (but in general it would be a program

that uses a lot of time or memory, going through the lists of possible values).

If we were to construct a good propagator for a low-up constraint, then we

could improve consistency level of some of the constraints in this category, for

example among low up, which has a hypergraph that is non-cyclic aside

from the low-up part.

4 Conclusions

4.1 Summary

We can conclude that in general, a constraint reification is not guaranteed to achieve domain consistency even when the original constraint achieves that level of consistency. That is, we cannot prove the results with the tools we had available in this work.

We have proven that many constraint reifications have Berge acyclic hy- pergraphs and thus achieve domain consistency. These are the 70 constraints in the TF category where exactly one variable can be expressed from others, the 16 constraints in the RIC and RSC categories, 4 constraints in the Logic category, 1 constraint in the Conj category, one more constraint that was moved from the Logic to the Conj category, 11 constraints in the GenPat category, as well as 40 constraints in the Auto(i, j) category (for more exten- sive results, see the appendices). 10 constraints belonging to two categories attain domain consistency with both reifications.

The constraints proven to achieve domain consistency in this work are 132 global constraints or approximately 38% of all the constraints in the Global Constraint Catalogue (or almost half of the global constraints in the catalogue with known reifications).

4.2 Future Work

This research is by far not complete. From this work we can continue in several different directions, to continue answering the original question.

4.2.1 Taking Restrictions into Consideration

Many of the restrictions that we have not taken into account yet actually do not alter the level of consistency. If a variable’s domain for example is re- stricted with constant values, only one extra edge is added to the hypergraph of the reification, and that edge would contain only one vertex. Whether a hypergraph is Berge acyclic or α-acyclic, per definition, adding singleton edges does not alter that acyclicity.

Restrictions concerning two or more variables can however alter the hy-

pergraph structure significantly. For this, we have to study each constraint

separately with regard to the restrictions.

4.2.2 Automata with More than One Counter

In this work, we have not studied the three constraints from the Auto(i > 1, j) category from the point of view of the reification process described in Sec- tion 2.6.3. It is possible we would have achieved better results with that kind of reification.

4.2.3 Low-up Propagator

As mentioned in Section 3.9, we could benefit from a new propagator for the conditions that have the low-up-structure. There are at least 10 constraints on which solvers would probably give better performance, if such a propa- gator existed. It is even possible that some of them would achieve domain consistency, which is one of our goals with reifications.

4.2.4 Tractability

Due to the non-result regarding the Sort category, what we can do is to determine the tractability level for the constraints. One way to measure tractability in these cases is to search for minimal width and minimal wedge tree [9] of the corresponding hypergraph. But in general we have a situation where at least the edge of the hypergraph corresponding to the sort con- straint is of size 2n, i.e., the value of the minimal width cannot be constant, which is not promising.

4.2.5 Bounds Consistency

In this work we have not determined any reifications attaining bounds consis- tency. That is still to be done, but most importantly, we would benefit from methods regarding bounds consistency. To this date, the constraints have to be considered one by one in order to determine whether this weaker consis- tency level is achieved. We are left with two thirds of the constraints in the Global Constraint Catalogue to study, due to the proof that the reification of one third of them achieves domain consistency.

4.2.6 QLogic

The constraints in the category QLogic do not have explicit formulae to work

with. Instead, we deal with theoretical reification, where the expressions are

described via another language. The study of the consistency level of these

constraints requires more research about reifications than done in [6].

4.2.7 Unknown Reification

Approximately 18% of the constraints in the Global Constraint Catalogue had until today no known reifications. The field would gain both from discov- ering any reifications for those constraints, or from improvement, regarding simplicity, of the constraints of already known (one or several) reifications (in this work, the latter was done to the same sign constraint in Section 3.4.2).

This would require work where we study in detail what the combinatorial constraints actually do.

4.2.8 Implementation

It would be interesting to implement new ways of reification of particular

constraints and compare to the ones in use. Would reifications proved to

achieve domain consistency outperform others (the ones with no determined

consistency level)? I.e., would the propagator for the former run faster or use

less space than the latter for the same constraint? We can also expreriment

with data in order do check the level of consistency (for given instances) for

the propagators of known reifications.

A Consistency in the TF Category

Global Constraint Consistency

abs value DC

among DC

among diff 0 among interval

among modulo DC

among var DC

and DC

balance DC

balance interval DC

balance modulo DC

balance partition DC

cardinality atleast DC

cardinality atmost DC

cardinality atmost partition DC

change DC

change pair DC

change partition DC

change vectors DC

circular change DC

colored matrix common

common interval common modulo common partition

crossing DC

cyclic change DC

cyclic change joker DC

discrepancy DC

distance DC

distance between DC

distance change DC

elem

element DC

element product DC

elements

eq, also in RIC category DC