decomposition can be implemented in many solvers using disjunctions of membership constraints: or(notmember(Xi, [d1, .., dm]), Bi **= 1) and** or(member(Xi, [d1, .., dm]), Bi **= 0).**
Unfortunately, Ilog Solver does not appear to achieve GAC on such **disjunctions of primitives because the negated membership constraint** notmember(Xi, [d1, .., dm**]) is activated**
only if Xiis instantiated with a value in [d1, .., dm**] whereas it should be as soon as**
D(Xi) ⊆ [d1**, .., d**m].

We report results for the following representative models:
- Alld-Gcc-Sum **uses only Ilog Solver primitives;**

- Alld-Gcc-Roots where Among is encoded using **Roots**; - Alld-**Roots**-Sum where Gcc is encoded using **Roots**;
- **Range**-Gcc-Sum where AllDifferent is encoded using **Range**;
- Alld-Roots-Roots where Among and Gcc are encoded using **Roots**;
Note that Among encoded as Roots **uses the decomposition presented in Section**
6.2.2, the Gcc uses the decomposition presented in Section 6.2.1, and **AllDifferent**
uses the decomposition presented in Section 6.1.1.

We study the following important questions:

- How does the Roots decomposition of the Among constraint compare to the Sum decomposition in terms of pruning and run-times?

- Does the decomposition of Gcc using Roots **lead to a reasonable and acceptable**
loss in performance?

- Does the decomposition of AllDifferent using Range **lead to a reasonable and**
acceptable loss in performance?

- **Do we gain in performance by branching on the set variables introduced by the**
Roots **decomposition?**
To answer the first question, we will compare the model Alld-Gcc-Sum **against the**
model Alld-Gcc-Roots**. To answer the second question, we will compare the model**
Alld-Gcc-Sum **against the model** Alld-**Roots**-Sum**. To answer the third question, we**
will compare the model Alld-Gcc-Sum against the model **Range**-Gcc-Sum**. To answer**
the fourth question, we will compare Alld-Gcc-Sum **against the model** Alld-Roots-Roots **that branches on the set variables.**
The instances we use in the experiments are generated as follows. For each number of salesladies s ∈ {10, 15, 20, 25, 30, 35}, we generate ⌈(s + 2/4) ∗ 4⌉ **shoppers, 4 visits.**
Furthermore, to determine the partitioning of the outlets, we bound the number of salesladies per outlet between a lower bound and an upper bound and **generate all possible** partitions within these bounds. The number of instances for each class is as follows; for 10 salesladies we have 10 instances, for 15 salesladies we have 52 instances, for 20 salesladies we have 35 instances, for 25 salesladies we have 20 instances, for 30 salesladies we have 10 instances, and for 35 salesladies we have 56 instances.

We also tested two variable and value ordering heuristics: