improved local search for cp toolkits

Annals of Operations Research 115, 31–50, 2002 2002 Kluwer Academic Publishers. Manufactured in The Netherlands.

Improved Local Search for CP Toolkits

PAUL SHAW [email protected] S.A., Les Taissounieres HB2, 1681 Route des Dolines, 06560 Valbonne, France

BRUNO DE BACKER and VINCENT FURNON {bdebacker,vfurnon}@ilog.frILOG S.A., 9, rue de Verdun, BP 85, 94253 Gentilly Cedex, France

Abstract. Constraint programming and local search are two well known optimization technologies. Inrecent years, methods for combining these two technologies have been put forward, one of which advocatesthe use of constraint programming for searching the local neighborhood of the current solution. We presenta search technique which improves on the performance of this constraint programming-based local searchmethod and perform experiments on a variety of both simple and more complex combinatorial problems.We also demonstrate the benefit of combining local and complete search methods.

Keywords: local search, constraint progamming, hybrid methods

1. Introduction

Constraint programming (CP) is a paradigm for specifying and solving combinatorialproblems with complex constraints, and has grown out of the large body of work per-formed on constraint satisfaction problems [29]. CP toolkits (see [9] for a comparison)provide sophisticated and flexible modeling systems, which has resulted in them being amethod of choice for real-world applications [31].

CP search technology is based around enumerative tree-based search. Thus, CPcan provide guarantees of insolubility for problems with no solution, or proofs of opti-mality where there is a solution. As a CP search progresses down a search tree, searchstates are removed by domain reduction: domains are reduced from their original eitherby constraint propagation (inferred reductions) or by choices made in the search tree(heuristic commitments). The former cuts off search states which cannot be solutions,while the latter forms a branch in the search tree. CP toolkits (such as [6,14,30]) allowthe user to specify and solve their problem in a standard manner without resulting tohand crafted code.

Local search (see, e.g., [1]) is an incomplete search method based upon taking aninitial solution and applying small changes to this solution, looking for improvements.The search continues in this way until some stopping condition is reached (usually basedon elapsed time or the fact that a solution of a certain quality has been found). At theend of the local search process, the solution with the lowest cost found during the searchis reported. Local search methods have proven effective in providing good solutionsquickly for a wide variety of problems, often providing the actual optimum or solutions

32 SHAW, DE BACKER AND FURNON

within a few percent thereof in times much lower than complete methods. In contrastto CP, local search methods are generally implemented by ad-hoc codes, although somegeneric work has been carried out, for example [7,18,20].

Why try to unite these two different paradigms? One can look at such a questionfrom two standpoints: Can CP improve or ease the use of local search? and Can localsearch improve or ease the use of CP?

From the first standpoint, the modeling flexibility provided by constraint pro-gramming toolkits is unrivaled by any other optimization technology. CP toolkits alsocome with good methods of finding first feasible solutions, or proving than none ex-ist. Secondly, but perhaps less obviously, there can be advantages to mixing local andtree-based search methods (see section 4.5). This provides the motivation for the useof CP.

From the second standpoint, although CP has proved effective for the solution ofdecision problems, it is not as effective for optimization. This is because CP relies onpropagation mechanisms which can perform poorly when the problems are not very con-strained or the lower bound on the cost function is not tight. Unfortunately, computingtight lower bounds is also complicated in constraint programming, since the models thatcan be described are so general. Good heuristics, different exploration strategies, relax-ations of the model, and collaborations with linear programming codes can help, but arenot always possible, effective, or convenient. This provides the motivation for the use oflocal search which, although cannot provide proofs of optimality in general, can oftenprovide good solutions quickly.

The unification of CP and local search methods has been studied for several years.Essentially, three methods have been examined.

Localizer [19] is a local search engine which works on some of the principles ofCP, notably that domains of variables are recalculated when other domains on whichthey depend change. Unlike CP, Localizer only maintains values for variables, and usesinvariants instead of constraints to maintain the values of dependent variables. Speedsapproaching hand-crafted implementations have been attained. However, Localizer isnot integrated with a CP toolkit – it merely uses similar ideas.

Another approach is one we shall refer to as the large neighborhood method. Ex-amples can be found in [2,8,26]. This method works by iterated relaxation and re-optimization. First, assume that a representation s of a solution exists outside of theconstrained variables themselves. This allows the current solution to be kept in s re-gardless of the current domains of the constrained variables. Then, with all constrainedvariables having their initial domains, we instantiate a subset of them to their valuesin s. The remainder are instantiated via a CP tree-search procedure. This search couldlook for the optimal solution to the sub-problem, any solution which improves on thecurrent one, etc. If a better solution is found, it is ‘saved’ by copying values from theconstrained variables to s. The CP solver is then backtracked to the initial state, and theprocess repeated, choosing a different subset of variables. This method can be appliedwidely, both in single-point search, or in multi-point search, for example as a part of acrossover or repair operation in genetic algorithms [24].

IMPROVED LOCAL SEARCH FOR CP TOOLKITS 33

Yet another approach is to use a CP tree search to explore the neighborhood, as pro-posed by Pesant and Gendreau [21–23]. In spirit, this is the same technique used in thelarge neighborhood method, but there the neighborhood had to be of the ‘reconstruction’type. In contrast, in Pesant and Gendreau’s proposal, the neighborhood can be of anytype. For instance, for a routing problem, one may define a ‘two-opt’ neighborhood [17]where each leaf of the corresponding search tree corresponds to a legal two-opt from thecurrent solution. This technique is natural in a CP context as, for instance, depth firstbranch and bound can be used to select the best neighbor, and thus execute the best two-opt move. Likewise, we can restrict search to look for neighbors which only improvecost by imposing a constraint specifying that the cost variable must be less than the costof the current solution. Such operations are easily performed within CP toolkits.

Although this last approach is one which is attractive from a constraint program-ming standpoint, it suffers from performance problems. This paper describes a proposi-tion for improving the computational complexity of the exploration. Following this, weperform a set of simple experiments comparing performance, and then go on to describemore realistic examples, specifically, vehicle routing with soft deadlines and facility lo-cation.

2. Pesant and Gendreau’s exploration method

The idea presented in [21,22] is as follows. Given a model of the problem, this model isaugmented by adding two sets of objects. The first is a set of variables with (possibly)constraints acting between them. This constraint problem represents the neighborhoodto be explored (this will be elaborated upon in the following paragraphs). The secondis a set of constraints – termed interface constraints – which connect these new vari-ables with the original model variables. In this way, propagation can proceed betweenthe original model variables and the new ‘neighborhood’ variables. These interface con-straints depend on the current solution to the problem (held elsewhere, for instance inour structure s), and so have to be added anew to the constraint solver each time a localmove is accepted.

Thereafter, the neighborhood exploration proceeds by generating all possible as-signments to the neighborhood variables using a standard tree search. The interfaceconstraints interpret the assignments to the neighborhood variables, and perform the re-quired propagation into the model variables. When all neighborhood variables have beeninstantiated, the original model variables have values which correspond to the neighborof the current solution specified by the neighborhood variables. When one exploresthe whole tree of assignments to neighborhood variables, each leaf node comprises anassignment to model variables which corresponds to the neighbor in question.

For example, consider a neighborhood which swaps the values of any pair of vari-ables in an array x of size v. Further assume that the values of x in the current solutionare held in an array s. The neighborhood model is represented by two constrained vari-ables i and j with domains 1, . . . , v representing the indices of the variables whose


values are to be swapped. The constraint i < j is also added to avoid re-exploration ofsymmetrical swaps. The interface constraints are then:

x[i] = s[j ], x[j ] = s[i],

∀k ∈ {1, . . . , v}, k �= i ∧ k �= j ⇒ x[k] = s[k].The first line constrains the two variables whose values are to be swapped. The set ofconstraints represented by the second line constrain all variables which are not beingswapped at this neighbor to be their original values as specified in s. Normally, interfaceconstraints have this form: a section devoted to the change and a section devoted to a‘restoration’ of the unchanged part to its previous value.1 The neighborhood is exploredby generating all pairs of values for i and j in a search tree of depth 2, which in turninstantiates the model variables through the interface constraints.

Hereafter this method of neighborhood exploration by constraint programming willbe termed EXPLORE-I.

2.1. Complexity

It is stated in [21,22] that such an integration of CP and local search can outperformmore naive approaches which simply instantiate all the model variables according to thedesired move. It is argued that propagation between the model variables and the neigh-borhood variables (due to the interface constraints), can prune some illegal neighborsbefore they are explored. [22] shows this to be the case for 3- and 4-exchange neighbor-hoods for the TSP with time windows (TSPTW). For the TSPTW, this pruning can occurquite readily as instantiating a small part of the model (perhaps just one arc of the ex-change operator) can deduce inconsistency. For instance, imagine an situation where onecannot go from city a to b due to tight time constraints on the cities in question; when thearc (a, b) is ruled out, all 3-opts using this arc are immediately discarded. Unfortunately,for problems where such inconsistencies cannot be detected without a greater portion ofthe model variables being instantiated, or where the depth of the neighborhood searchtree is low (1 or 2), the method is inefficient.

The complexity of EXPLORE-I can be derived from the following argument. Con-sider a neighborhood of n neighbors and a model with v variables. We assume a neigh-borhood where either all neighbors are legal, or equally, that any illegal neighbors aredetected only after all variables in the neighborhood model have been instantiated (i.e.,no neighborhood pruning). Further assume that just before reaching each leaf node ofthe search tree, O(v) variables in the model remain uninstantiated. (The 1-max prob-lem in section 4.1 uses a neighborhood with all these properties.) Then, to reach eachleaf, O(v) assignments to constrained variables must be made. Since there are n leafnodes, we needO(nv) such assignments. This complexity is the same as a naive method

1 The term ‘restore’ will be used for a variable to signify that it takes the value that it has in the representationof the current solution.


which instantiates all v variables with values according to a neighbor to be examined,backtracking completely each time.

3. A new method

We wish to address the computational complexity of the EXPLORE-I method, whilepreserving its desirable properties: the natural integration with CP tree search and theability to explore any type of neighborhood. The natural integration comes from the factthat the exploration is done via a constraint programming goal. This means that the localsearch can be meshed with traditional tree search mechanisms. This is a useful property;often the local search may only solve a sub-problem of the complete problem, or as is thecase in section 4.5, the local search can be the master search, with sub-problems beingsolved by subordinate goals.

We now describe a method of reducing the complexity of neighborhood explorationusing CP. We call the resulting search method EXPLORE-II. First we give an intuitivedescription of the method for a particular type of neighborhood. We then describe thegeneral algorithm, and prove its complexity in terms of number of assignments made toconstrained variables. EXPLORE-II can be implemented as a standard constraint pro-gramming goal and can explore any type of neighborhood; we thus retain the desirableaspects of EXPLORE-I.

3.1. Intuitive description

Consider a vector x = {A,B,C,D,E,F } of 0–1 decision variables, and a neigh-borhood which is to change the value of one of these variables (a ‘flip’) – a neigh-borhood commonly used by local search methods. The current solution is repre-sented by the solution vector s. The function value(s, xi ) delivers the value of xi inthe solution s. For the purposes of the example, assume that the current solution iss = {1, 0, 1, 0, 1, 1}. The set of neighbors we wish to examine can be represented bythe set {A = 0, B = 1, C = 0,D = 1, E = 0, F = 0}. The idea is that we recur-sively split the set of neighbors in two, and at each stage instantiate any variable y thatis not mentioned by any neighbor to its previous value value(s, y). Figure 1 describesthe search diagrammatically. Each arc is labelled with the assignments to constrainedvariables that are made when the search moves down this arc. For example, at the toplevel of the tree, movement down the left arc restricts the set of neighbors to be exploredto {A = 0, B = 1, C = 0}. Accordingly, since neither D, E, nor F are changed in thissub-tree, their values are set to those in s. This splitting continues until only a singleneighbor remains. At this point, the variable corresponding to the neighbor is given itsnew value. For ‘flip’ neighborhoods with v variables, the complexity of EXPLORE-II interms of the number of assignments required is O(v log v), whereas EXPLORE-I has acomplexity of O(v2).


Figure 1. EXPLORE-II on the ‘flip’ neighborhood of ABCDEF = 101011.

3.2. General algorithm

Assume in addition to the representation s of the current solution, the existence of anarray of similar structures, each of which represents a proposed change to s; in localsearch terminology, a neighbor of s. We refer to such a proposed change as a ‘solutiondelta’ or simply ‘delta’, as it describes the difference between the current solution andthe new one. Each of these deltas contains only the assignments to the variables whichwill (potentially) change.

Given a current solution s, and a neighborhood to explore as given by an array ofdeltas deltas, figure 2 describes a CP search goal which performs the exploration. Theidea of the algorithm is twofold. First, at any point in the exploration, we set the values ofany variables not changed by the set of deltas to their values in s. Second, we continuallysubdivide the set of deltas being considered, and explore each half on separate branchesof the search tree.

Theorem 1. For a model with v variables, and a neighborhood made up of n deltas, eachof which mentions k variables, the complexity of the number of assignments A made byEXPLORE-II is O(A) = nk log(v/k).

Sketch of proof. Observe that down any path in the search tree generated byEXPLORE-II, each variable is assigned exactly once. If at any node, a variable hasnot been assigned, and will not be assigned at the current node, it can be assigned two ormore times below this point. That is, making assignments as high up in the tree as pos-sible minimizes the number of assignments. With this is mind, to derive the worst casecomplexity, we imagine the inverse situation where assignments are carried out as lowas possible in the tree. At each of the leaves of the tree, we examine one solution deltaand make the k new assignments; we also restore to their old values up to k variableswhich resulted from the splitting of a set of two deltas one level up in the tree. Sincethere are potentially n leaf nodes in the tree, the entire base level of the tree makes upto 2nk assignments. The level above the base makes up to 2k assignments at each node


EXPLORE-II(assignment s, array of assignment deltas)– Restore variables not mentioned in deltascreate a vector of booleans mention,

with one element for each member of sinitialize mention to all false valuesforeach delta in deltas

foreach var in delta with value(delta, var) �= value(s, var)mention[var] := true

create a new empty assignment tforeach var in s

if mention[var]add {var, value(s, var)} to t

elseassign value(s, var) to the constrained variable var

– Solve sub-problemsif |deltas| = 1

foreach var in deltas[1]assign value(deltas[1], var) to the constrained variable var

elsem := |deltas|/2�branch

left: EXPLORE-II(t, deltas[1 . . . m])right: EXPLORE-II(t, deltas[(m+ 1) . . . |deltas|])

Figure 2. The EXPLORE-II procedure.

to restore the values of variables resulting from a split of four deltas. There exist n/2such nodes in the tree, and so this level makes nk assignments. In like manner, eachnode of the next higher level makes 4k assignments in restoring variables. This levelhas n/4 nodes, again giving a total of nk assignments. We continue this reasoning upthe tree until we come to a level where no more restorations take place as delta splittingat that level results in a set of deltas which still mentions all variables. Observe that upany path in the tree, we restore the values of k, 2k, 4k etc. variables. We thus reach thelevel where no more restorations take place after O(v/k) steps. Combining this withthe result that each level makes O(nk) assignments, we have the required result thatO(A) = nk log(v/k).

3.2.1. Practical considerationsThe complexity of EXPLORE-II in terms of number of primitive operations (discountingassignments to constrained variables) has not been analyzed. In fact, it has a complexityof O(nk log n), which is normally greater than or equal to O(A). One may be con-cerned that execution speeds will be restricted by the execution of EXPLORE-II and not


the number of assignments performed. There are two reasons why this is not so in prac-tice. First, n is nearly always polynomially related to v/k, meaning that in such a case,there is no complexity difference – only a constant factor results. Second, when a con-strained variable is assigned, propagation rules are activated which require a time whichis significantly larger the primitive operations of EXPLORE-II. We have found that thisoverhead far outweighs the small additional factor log n/ log(v/k) implied by the abovecomplexity result.

We would like to mention two points on the space complexity of EXPLORE-II.First, the algorithm builds an assignment t at each level of recursion, incurring a potentialoverhead of O(vn) in the worst case. The description given is a purely functional oneintended to be easily understood and a basis for the derivation of a complexity result. Inreality, the variable t does not exist: the incoming solution s is manipulated by removingthe restored variables. These removals are undone when the recursion unwinds. Theoverhead is thus negligible in practice.

Second, the space complexity incurred by EXPLORE-II is O(nk) as this space isrequired to hold all deltas. This may seem to be a significant drawback to the use ofEXPLORE-II, especially if the neighborhood size grows quadratically or more in thenumber of variables. This problem can be circumvented by generating the deltas inchunks and exploring them independently. Importantly, this does not change the com-plexity of the algorithm so long as each chunk is large enough to ‘cover’ all variables;that is, each variable should be mentioned at least once in the set of deltas comprisingthe chunk.2 If one considers, for example, the ‘swap’ neighborhood described at thebeginning of this section, this condition is met when the chunk size c = O(v). This‘chunking’ has another important advantage: not all neighbors need to be defined beforeexploration begins. This can be very advantageous when we are interested in the firstfeasible neighbor rather than the best one; the overheads of defining all deltas when onlya few need perhaps be examined can be considerable.

The practical considerations outlined above have all been included within ILOGSolver [14], which uses a pragmatic version of EXPLORE-II for its local search. Solveralso includes a user friendly programming interface so that the user does not have toworry about issues such as chunking or memory management.

3.2.2. Ease of useWe argue that the process of designing a neighborhood search around the EXPLORE-IIalgorithm is simpler than for EXPLORE-I. This is principally due to the different typesof structures one deals with in each. In EXPLORE-I, one deals with a neighborhoodmodel and interface constraints; in EXPLORE-II, one deals with deltas. The ‘delta’ sys-tem is in fact very close to the system used by practitioners when they write standardlocal search codes – for each neighbor in the neighborhood, specify the change to thevalues of some variables. The delta mechanism simply structures this reasoning. Thus,there is only a very small intellectual gap to overcome if one is already used to writing

2 The proof sketch given is consistent with this view.


local search codes. By contrast, for EXPLORE-I, interface constraints are used, normallymeaning that consideration of a single neighbor and which assignments it will changeis no longer possible. Instead, one has to think of the neighborhood exploration as awhole. This is not so much of a problem for simple, structured neighborhoods. How-ever, when neighborhoods are less structured or more complex, writing down the correctinterface constraints becomes much more intellectually demanding. This is further com-pounded by the fact that custom-written, tailored interface constraints often have muchbetter performance than using standard constraints provided by the CP toolkit (see sec-tion 4.6). Hence, if maximum performance is desired, the user may have to write theirown interface constraint – a very specialized task.

3.3. Improved complexity for some neighborhoods

For some particular neighborhood structures and orderings, the complexity ofEXPLORE-II can be improved upon. Consider a model with v variables, each with d+1values, and a neighborhood of size vd which is to explore each single value change pos-sible. The complexity in number of assignments for the exploration of this neighborhoodfor EXPLORE-II is O(vd log v). However, without too much trouble, one can achieve acomplexity of O(v(d + log v)). To attain this improvement, we need only make a slightchange to the EXPLORE-II algorithm: solution deltas can hold more information thansimply variable values. The ‘value’ of a variable can in fact be something more general;any domain reduction. In the limit case the ‘restoration of a value’ may in fact do noth-ing if the domain has been set to be completely open in the delta.3 We make use of thisability to arrive at the reduced complexity for the described neighborhood.

Assume we have at our disposal a ‘relax one variable’ neighborhood. In this neigh-borhood, the delta corresponding to neighbor i stores an unbounded domain for vari-able i, for instance by storing its new range as (−∞, . . . ,∞). Each leaf node generatedby EXPLORE-II will thus have one variable unassigned, but appropriately constrainedby any constraints incident upon it. By executing another goal after EXPLORE-II to in-stantiate the remaining variable (a simple matter in CP toolkits), a complete search of thedesired neighborhood is effected. The complexity of the number of assignments madeby EXPLORE-II in this setup isO(v log v). The subordinate goal makes vd assignments.The total complexity is thus reduced to O(v(d + log v)).

3.4. Support for the large neighborhood method

Allowing ‘restoration’ of a variable to perform something more general than a simpleassignment to a variable supports the large neighborhood paradigm discussed in theintroduction. One simply adds the variables to be relaxed to the delta, giving these

3 We assume efficient ways to encode large and unrestricted domains in the deltas; one simple possibilityis to store only the minimum and maximum values of the domain, assuming that all values between themare present.


variables a new domain which is open. Then, EXPLORE-II will generate a leaf node withthe appropriate set of variables relaxed, which can then be reassigned using a subordinategoal.

4. Experiments

In this section, we evaluate the performance of EXPLORE-II. To begin, we present twoextreme cases, one of which favors EXPLORE-II, the other which favors EXPLORE-I.We then examine another typical problem.

We then go on to two more complex problems: vehicle routing with soft deadlinesand capacitated facility location. The EXPLORE-II algorithm is implemented in ILOGSolver’s local search methods. Unless otherwise stated, all tests were performed usingILOG Solver 5.2 [14] on a 400 MHz Pentium-II PC running Linux.

4.1. A 1-max problem

An augmented 1-max problem is described as follows. Maximize c · x where x is avector of 0–1 variables, and c is a vector of natural numbers. The optimal is achievedwhen x is a vector of 1s. The values of c are chosen randomly in the range [1, . . . , 100].We perform a local search from a initial solution composed entirely of zero values tothe optimal solution using a flip neighborhood which can change the value of any 0–1variable. We make the most profitable move at each step.

We compared the performance of EXPLORE-I and EXPLORE-II. For EXPLORE-Iwe have a single variable i in the neighborhood model: the index of the 0–1 variable tobe flipped. Assuming a solution vector s, the interface constraints for this model are:

x[i] = 1 − s[i],

∀k ∈ {1, . . . , v}, k �= i ⇒ x[k] = s[k].For efficiency, the interface constraints were not used as described above: instead

a single custom-written interface constraint with the same semantics was used. Thisavoids the need to work with conditional constraints, and leads to better performance.4

We will revisit this issue in section 4.6. The results are shown in figure 3. We can clearlysee the difference in algorithmic complexity between the two methods. This problemcould be considered a ‘worst case’ for EXPLORE-I method as the neighborhood cannotbe effectively pruned. For this case, at 100 variables EXPLORE-II is 3.5 times faster, andat 1000 variables, is over 11 times faster.

4 In all our codings of EXPLORE-I for the different problems addressed in this paper, we used a custom-written interface constraint to give maximum performance.


Figure 3. CPU time per best flip move for the 1-max problem.

4.2. 3-opt for the TSP with time windows

We examine a case for which EXPLORE-I has shown to be efficient: 3-opt exchanges forthe traveling salesman problem with time windows. [22] reports that the use of constraintprogramming incurred only a factor of 4 overhead over a custom implementation. Theefficiency of the method is due to a significant amount of neighborhood pruning.

In [22], traveling salesman problems with time windows (TSPTW) derivedfrom [27] are optimized via 3-opt and 100 iterations of tabu search, where the lowestcost non-tabu move is taken at each iteration. The size of the problems varies fromaround 20–40 cities. We perform the same test using EXPLORE-II.5 Results are shownin table 1. Shown are the mean times for performing 100 iterations of tabu search overeach tour in the named problem. In the ‘Normalized’ column, we divide the CPU timesreported in [22] by 6 (an estimation of the speed difference between the machines used).We see that the two methods solve these problems at approximately the same speed,which is encouraging for the EXPLORE-II algorithm as this a case where it may be ex-pected to perform poorly as it cannot not effectively prune neighbors near the top of thesearch tree as can EXPLORE-I.

4.3. Magic square

A magic square is an n× n table filled with the integers 1, . . . , n2 such that the sums ofall rows, columns, and the two diagonals are equal to σ = n(n2 + 1)/2. We transformthe decision problem of finding a magic square into an optimization problem where oneminimizes the sum of the ‘errors’ of each row, column and diagonal, where the error is

5 In [22] explicit lower bound calculations of neighbors are added to accelerate the search. We have donethe same.


Table 1CPU times 100 iterations of tabu search for TSPTW.

Problem EXPLORE-I EXPLORE-II RatioOriginal Normalized EXPLORE-II/EXPLORE-I

RC201 61.6 10.27 14.38 1.40RC202 71.2 11.87 10.45 0.88RC203 172.1 28.68 17.62 0.61RC204 160.1 26.68 21.03 0.66RC205 64.0 10.67 11.50 1.08RC206 108.8 18.13 18.20 1.00RC207 103.8 17.30 24.95 1.44RC208 134.7 22.45 12.75 0.57

Mean 109.54 18.25 16.36 0.90

Figure 4. CPU time per move for the magic square problem.

defined as the absolute difference between the sum and σ . A solution with σ = 0 is asolution to the original magic square.

We implemented a swap neighborhood in the EXPLORE-I style (using a custominterface constraint with semantics as described in section 2) and compared its perfor-mance with that of EXPLORE-II. We start from an initial randomly generated solutionand perform a greedy local search using both methods. Both searches take the first swapof the values of two cells that decreases the cost, stopping when no swap will decreasethe cost. The results are shown in figure 4. We again see the performance differencebetween the two methods.


4.4. Vehicle routing with soft deadlines

We examine the construction of a solution to a vehicle routing problem with capacityconstraints and soft delivery deadlines. Although solution construction may appear tobe unrelated to local search, construction by insertion can be viewed as being carried outby local search. Assume a model based on the ‘next/previous’ paradigm. That is, eachcustomer visit has two constrained variables associated with it which represent the nextand previous visits in the route. Two special visits per vehicle start and end the vehicle’sroute. Given these variables, appropriate constraints can then maintain and constrainthe arrival time at each visit and the load on each vehicle at each of its visits. Otherconstraints maintain bounds on the cost variable.

We assume that in our model, that if the next and previous variables of a visit pointto the visit itself, this visit is said to be ‘unperformed’, and can exist outside a route.We use this facility to view insertion as a local search procedure. In the initial solution,all customer visits start off in the ‘unperformed’ state and all vehicles go directly fromtheir first to their last visits. The neighborhood we then examine is one which takesan unperformed visit and inserts it between two connected visits. We insert a visit atits cheapest position merely by making the lowest cost local search move. Each deltamentions four variables: to insert visit v between u and w, we must set next(v) = w,prev(v) = u, next(u) = v, and prev(w) = v. A simple scan of the routes is enough togenerate the deltas.

The cost function is the sum of the total travel distance, plus a cost for each deliverythat is late, the cost incurred being proportional to the lateness. (We refer the readerto [28] for a full treatment of this problem.) Such ‘soft constraints’ make it difficultto use classic routing techniques to pre-filter infeasible neighbors (for example due topredicted time window violations [16,25]). The extra penalty term also complicatescomputation of a lower bound on the cost of each neighbor, and in fact, we do notattempt to make such a computation here.

We compare computation times for inserting all visits using EXPLORE-II againstthe time taken using the more naive approach of instantiating all constrained variableseach time an insertion needs to be evaluated. (This naive approach still filters moveswhich would violate capacity constraints [3].) Both approaches also filter neighborsusing a lower bound based on only the travel distance.

Insertion using EXPLORE-II is implemented in ILOG Dispatcher 2.1 [13], whereasthe more naive version was used in version 2.0. This experiment therefore comparesthe difference between the two product versions, but also two algorithms. Results overa range of problems sizes are shown in table 2. As problems become large, the newapproach can be seen to be vastly superior.

4.5. Facility location

This section does not make an algorithmic comparison as in the previous sections, butattempts to show the importance of being able to naturally combine local and completesearch methods. We demonstrate this through the solution of facility location problems.


Table 2Comparison of insertion methods on a soft deadline problem.

Problem size Run time (s) Speed upCustomers Vehicles Dispatcher 2.0 Dispatcher 2.1

20 4 0.26 0.16 1.650 8 1.29 0.63 2.0

100 14 5.21 2.19 2.2200 21 41.56 9.43 4.4

1000 100 3209.12 249.45 12.9

Facility location problems are of significant practical importance in transportationlogistics. They concern the allocation of customers to facilities in a cost-effective man-ner. The facilities perform some service to the customers, be it supply of goods, pickupof goods, maintenance of equipment at the customer site etc. Associated with each pair(c, f ) of customer and facility is a cost cost(c, f ) which is an estimate of the cost ofservice over some fixed time period (say one year) of servicing c from f . We considerhere the capacitated version of the problem which states that from each customer c,there is a demand dc, which corresponds to the amount of service required. For eachfacility f there is a capacity Cf . The sum of the demands of all customers being servedby a facility f must be no greater than Cf . Finally, in the variant of the facility locationproblem we consider, each customer must be served by exactly one facility. Moreover,if at least one customer is served by a facility, the facility is said to be open, otherwiseit is closed. Any open facility incurs an additional fixed cost Of for being open. Thusthe optimization is a balance between reducing the opening costs and service costs. Theformer is best done by opening few facilities, whereas the latter is best done by open-ing many, such that distances from customer to facility are reduced. Throughout, thecapacity restrictions on the facilities must be upheld.

We represent a solution to the above problem by a vector of variables x. We as-sume a variable xc holds the facility serving customer c. Given such a representation,the constraint that each customer must be served from exactly one facility need not bemodeled explicitly. The model can be expressed mathematically as:

minimize:∑

c

cost(c, xc)+∑

{f |∃c: xc=f }Of

subject to: ∀f∑

{c|xc=f }dc � Cf .

This translates relatively straightforwardly into a constraint programming model.However, when we apply complete search to it, the results are relatively disappointing.Local search seems an obvious candidate, using a neighborhood which changes the fa-cility that will serve a particular customer.

Unfortunately, this local search mechanism, even coupled with meta-heuristics,performs worse than complete search. Analyzing the movements of such a local searchprocedure shows that it can be relatively difficult for a local search based on such moves


to make bulk transfers of customers from one facility to another (or from two largerones to three smaller ones for example.) This is because the benefits of such a bulktransferral lie relatively far away in terms of number of moves, while there are great costdisadvantages on the way there, notably because of the fixed cost of the depots. On thelocal search trajectory for such a transfer, more depots are open than necessary, and thisincreases the cost. These reasons make the landscape difficult to negotiate for a searchprocedure which performs simple movements or swaps of customers.

There are standard techniques for diversifying the search (for instance see a rangeof techniques in [10]), such as the use of frequency memory, searching outside the fea-sible region, penalties and inducements, strategic oscillation, and so on. However, thebreadth of available techniques make even such a investigation costly. We instead lookedat a different approach for improving the local search – we examined a hybrid method.

Using a CP toolkit, we can exploit the inherent structure in the problem. Althoughan assignment of facility to each customer is enough to determine a solution, we canlook upon the problem as being two-tiered. There is first the problem of determiningwhich depots should be open, and then there is the secondary problem of determiningwhich open facility should be assigned to each customer. If both of these problems areteased apart somewhat, a two-level search can be effected.

The idea is as follows: we perform a local search only over the state (open orclosed) of the facilities, without considering the specific assignments of facilities to cus-tomers. After each such move, there is therefore some work left to do. However, theassignment possibilities have been reduced over those presented by the complete prob-lem as some facilities are closed. The remaining assignments are carried out here usinga more traditional constraint programming goal which executes at each leaf of the treegenerated by EXPLORE-II.6 Figure 5 exemplifies this procedure for a problem with fourfacilities; four leaf nodes are generated by EXPLORE-II corresponding to the opening orclosing of a single facility. Below each of these leaf nodes another constraint program-ming goal, described later, makes specific assignments of facilities to customers. Thisfinally results in a much larger neighborhood tree than that generated by EXPLORE-II,but it can still be regarded as a neighborhood. Constraint programming systems treatthe whole search uniformly: there is fundamentally no difference between the top andbottom portions. Thus, for instance, we can use selection mechanisms to choose the bestleaf node of the entire tree as the next neighbor to move to.

How can this hybrid search process perform better than the simpler local searchover assignments of facilities to customers? We pointed out that the simpler local searchlacked the ability to make bulk transfers of customers from one facility to another.Furthermore, the chances of such a bulk transfer happening by unit transfers are low,given the cost disadvantages on the way. By using a local search mechanism whichmakes major changes to the solution (opening or closing a depot) we can make largerjumps in the search space. When a depot is closed for instance, all the customers that

6 One could also use a integer linear programming technique to find the optimal assignment, given that onlysome warehouses can be used.


Figure 5. Complete goal for making one move for the facility location problem. In this example, there arefour neighbors in the open/close local search neighborhood. EXPLORE-II executes the goal in top half of

the figure; the remaining exploration is done using traditional goals.

it served must be relocated elsewhere: the change in the solution can be quite signifi-cant.

We took all the capacitated problems in OR-Library [4,5] of up to 50 customersand 50 facilities, and ran three different experiments. The first uses tabu search over theassignment of facilities to customers. The second used limited discrepancy search [12]over the same assignments. The third uses tabu search over the ‘openness’ of the facil-ities, with a limited discrepancy search over the assignment of facilities to customers ateach move.7 For all the tree-based searches we used a heuristic which attempts to assignthe best facility to each customer. The heuristic chooses first the customer c who hasnot been assigned a facility, but has the most limited choice of facilities (the typical CSPfail-first heuristic [11]). Once c has been chosen, we must assign a facility to it. Wechoose a facility f which will keep the global cost as low as possible. This means thatwe will choose the least costly facility, including any cost which would be incurred toopen the facility if it does not already serve any other customers. On backtrack, we statethat f cannot serve c.

We set a time limit of two minutes on our experiments. For the local search ap-proaches, the initial solution is the first one generated by the complete search technique,and so all methods begin search at the same cost value. Figure 6 shows run time againstan average of the quality of the solution, averaged over each of the location problems.The average was formed as the geometric mean of ratios of cost to optimal cost. Thisaverage was then represented as a percentage by subtracting 1 and multiplying by 100.

We immediately see the benefit of using the hybrid approach. It produces solutionsaround 0.2% above optimal after around one minute, whereas the other two methods donot attain the 2% mark in that time. It is clear that the tabu search over the assignmentof facilities to customers quickly stagnates, despite our efforts to improve this state of

7 For solving this sub-problem, the discrepancy limit was set to 2.


Figure 6. Comparison of different search methods on facility location problems.

affairs by using a varying tabu tenure. Complete search using limited discrepancy searchworks better, but its improvement tails off at near 1.5% from optimal. What we believe isimportant in this result is that the hybrid method required minimal tuning. For instance,it was still significantly better than the other two methods regardless of whether we usedlimited discrepancy search or depth first search to perform the final assignments. Wespent significantly more time attempting to improve the performance of the other twomethods. Also significant is that such a hybrid search method would probably neverhave come about without the ability to simply integrate local and complete search usinga constraint programming toolkit.

4.6. Improvements to Explore-I

Since the publication of the first version of this paper in CP-AI-OR 2000 [15] (March2000), Pesant and Gendreau have suggested performing a search similar to EXPLORE-IIusing the EXPLORE-I framework. Instead of simply instantiating the neighborhoodvariables in the normal manner, one creates a deeper tree by continually splitting thedomain of a neighborhood variable in two until the variable is instantiated. One thenmoves on to the next neighborhood variable. This improves the complexity to that ofEXPLORE-II for structured neighborhoods. This also results in almost identical run-times to EXPLORE-II, but often only when custom-written interface constraints are used.

We illustrate this last point by returning to our first example: that of the augmented1-max problem. Recall that in that in section 4.1, we used a custom-written constraintto interface the neighborhood model with the model of the problem. Now we look atdifferent combinations of interface constraint implementations and domain splitting inmore detail. We reran our 1-max experiments with the following algorithms:


Figure 7. CPU time per best flip move for the 1-max problem.

Explore-I, std iface: The EXPLORE-I algorithm with ‘standard’ interface constraintsas described in section 4.1. The interface constraints were written using the standardconstraints provided by the CP toolkit. This is significantly simpler that writing acustom interface constraint.

Explore-I, custom iface: The EXPLORE-I algorithm with a custom-written interfaceconstraint.

Explore-I, std iface, split: As Explore-I, std iface, but the exploration is done by re-cursively splitting the domain of the index variable.

Explore-I, custom iface, split: As Explore-I, custom iface, but the exploration is doneby recursively splitting the domain of the index variable.

Explore-II: The EXPLORE-II algorithm.

Figure 7 shows the results of running the same experiments as described in sec-tion 4.1 using all algorithms. The algorithms are listed in order of increasing perfor-mance in the key. It can be seen that the three best performing algorithms are thosewhich use a neighborhood splitting technique. However, the worst of these three whichuses standard interface constraints is significantly slower than the other two, incurring anoverhead of a factor of 2 at the left of the graph and over 3 at the right. Of the two poorestalgorithms, EXPLORE-I with standard interface constraints performs worst, followed byEXPLORE-I with the custom interface constraint. Comparing these two algorithms, anoverhead of a factor 2.5–4 is incurred by the use of standard interface constraints.

In conclusion, the algorithms which use neighborhood subdivision methods arethe most efficient, although in the case of EXPLORE-I, only if custom-written interfaceconstraints are used. A point of interest is the ratio of the run times for the best andworst algorithms: around 10 for the 100 variables problem and 50 for the 1000 variablesproblem.


5. Conclusion

We have described improvements to the algorithmic complexity of neighborhood ex-ploration using constraint programming. The new method maintains the advantages ofthe technique proposed by Pesant and Gendreau while being simpler to use. In partic-ular complex neighborhoods can be described by specifying the change to the solutionthat each neighbor makes, without the need to write potentially quite complex interfaceconstraints.

Experiments on more complex real-world problems show that our method im-proves considerably on what could be done before with constraint programming ap-proaches. We have also demonstrated the benefits of using local and complete search inconjunction. Our experiments on the facility location problem indicate that large gainscan be achieved via a judicious decomposition of the problem, with the appropriatesearch method being used for each part.

The methods described in this paper have been implemented in ILOG Solver, alongwith a completely open local search system where one may specify one’s local searchalgorithms in a natural manner. The library can also be extended by writing one’s ownneighborhoods and meta-heuristics.

References

[1] E.H.L. Aarts and J.K. Lenstra (eds.), Local Search in Combinatorial Optimization (Wiley, Chichester,1997).

[2] D. Applegate and W. Cook, A computational study of the Job-Shop Scheduling problem, ORSAJournal on Computing 3 (1991) 149–156.

[3] B.D. Backer, V. Furnon, P. Kilby, P. Prosser and P. Shaw, Solving vehicle routing problems withconstraint programming and meta-heuristics, Journal of Heuristics 6(4) (2000) 501–524.

[4] J.E. Beasley, An algorithm for solving large capacitated warehouse location problems, European Jour-nal of Operational Research 33 (1988) 314–325.

[5] J.E. Beasley, OR-library: distributing test problems by electronic mail, Journal of the OperationalResearch Society 41(11) (1990) 1069–1072.

[6] Y. Caseau and F. Laburthe, The CLAIRE documentation, Technical Report LIENS Report 96-15,École Normale Supérieure (1995).

[7] Y. Caseau and F. Laburthe, SALSA: A language for search algorithms, in: Proceedings of the FourthInternational Conference on Principles and Practice of Constraint Programming (CP ’98), eds.M. Maher and J.-F. Puget (Springer, Berlin, 1998) pp. 310–324.

[8] L.L. et M. Lemaître, LNS/VSP: une méthode de recherche locale pour la résolution de VCSP en con-texte interruptible. Presented at the 5ièmes Journées Nationales sur la Résolution Pratique de Prob-lèmes NP-Complets (1999).

[9] A. Fernandez and P. Hill, A comparative study of eight constraint programming languages over theBoolean and finite domains, Constraints 5(3) (2000) 275–301.

[10] F.W. Glover and M. Laguna, Tabu Search (Kluwer Academic, Dordrecht, 1997).[11] R. Haralick and G. Elliott, Increasing tree search efficiency for constraint satisfaction problems, Arti-

ficial Intelligence 14 (1980) 263–313.[12] W.D. Harvey and M.L. Ginsberg, Limited discrepancy search, in: Proceedings of the 14th IJCAI

(Morgan Kaufmann, San Mateo, CA, 1995) pp. 607–615.


[13] ILOG, ILOG Dispatcher Reference Manual, Version 2.1, ILOG S.A., 9, Rue de Verdun, Gentilly,France (1999).

[14] ILOG, ILOG Solver Reference Manual, Version 5.2, ILOG S.A., 9, Rue de Verdun, Gentilly, France(2001).

[15] U. Junker, S.E. Karisch and T. Fahle (eds.), Proceedings of CP-AI-OR 2000, published as TechnicalReport TR-001-2000, Paderborn Center for Parallel Computing (2000).

[16] G.A.P. Kindervater and M.W.P. Savelsbergh, Vehicle routing: handling edge exchanges, in: LocalSearch in Combinatorial Optimization, eds. E.H.L. Aarts and J.K. Lenstra (Wiley, Chichester, 1997)pp. 337–360.

[17] S. Lin, Computer solutions of the traveling salesman problem, Bell Systems Technology Journal 44(1965) 2245–2269.

[18] L. Michel and P. van Hentenryck, Localizer, Constraints 5 (2000) 41–82.[19] L. Michel and P. van Hentenryck, Localizer: A modeling language for local search, in: Proceedings of

the Third International Conference on Principles and Practice of Constraint Programming (CP ’97),ed. G. Smolka (Springer, Berlin, 1997) pp. 237–251.

[20] S. Minton, M.D. Johnston, A.B. Philips and P. Laird, Minimizing conflicts: a heuristic repair methodfor constraint satisfaction and scheduling problems, Artificial Intelligence 58 (1992) 161–205.

[21] G. Pesant and M. Gendreau, A view of local search in constraint programming, in: Proceedings of theSecond International Conference on Principles and Practice of Constraint Programming (CP ’96),ed. E.C. Freuder (Springer, Berlin, 1996) pp. 353–366.

[22] G. Pesant and M. Gendreau, A constraint programming framework for local search methods, Journalof Heuristics 5 (1999) 255–279.

[23] G. Pesant, M. Gendreau and J.-M. Rousseau, GENIUS-CP: A generic single-vehicle routing algo-rithm, in: Proceedings of the Third International Conference on Principles and Practice of ConstraintProgramming (CP ’97), ed. G. Smolka (Springer, Berlin, 1997).

[24] L.-M. Rousseau, G. Pesant and M. Gendreau, A hybrid algorithm to solve a physician rostering prob-lem, in: Proceedings of CP-AI-OR 2000, eds. U. Junker, S.E. Karisch and T. Fahle, published asTechnical Report TR-001-2000, Paderborn Center for Parallel Computing (2000), pp. 145–152.

[25] M.W.P. Savelsbergh, Local search in routing problems with time windows, Annals of OperationsResearch 4 (1985) 285–305.

[26] P. Shaw, Using constraint programming and local search methods to solve vehicle routing problems,in: Fourth International Conference on Principles and Practice of Constraint Programming (CP ’98),eds. M. Maher and J.-F. Puget (Springer, Berlin, 1998) pp. 417–431.

[27] M.M. Solomon, Algorithms for the vehicle routing and scheduling problem with time window con-straints, Operations Research 35 (1987) 254–265.

[28] E. Taillard, P. Badeau, M. Gendreau, F. Guertain and J.-Y. Potvin, A tabu search heuristic for thevehicle routing problem with soft time windows, Transportation Science 32(2) (1997).

[29] E. Tsang, Foundations of Constraint Satisfaction (Academic Press, New York, 1993).[30] P. van Hentenryck, Constraint Satisfaction in Logic Programming (The MIT Press, Cambridge, MA,

1989).[31] M. Wallace, Practical applications of constraint programming, Constraints 1 (1996) 139–168.

improved local search for cp toolkits

Documents