Advancing Tabu and Restart in Local Search for Maximum Weight Cliques

04/22/2018 ∙ by Yi Fan, et al. ∙ Temple University Griffith University 0

The tabu and restart are two fundamental strategies for local search. In this paper, we improve the local search algorithms for solving the Maximum Weight Clique (MWC) problem by introducing new tabu and restart strategies. Both the tabu and restart strategies proposed are based on the notion of a local search scenario, which involves not only a candidate solution but also the tabu status and unlocking relationship. Compared to the strategy of configuration checking, our tabu mechanism discourages forming a cycle of unlocking operations. Our new restart strategy is based on the re-occurrence of a local search scenario instead of that of a candidate solution. Experimental results show that the resulting MWC solver outperforms several state-of-the-art solvers on the DIMACS, BHOSLIB, and two benchmarks from practical applications.



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

The maximum weight clique (MWC) problem is defined on a simple undirected graph where is the vertex set, an edge is a 2-element subset of , and is a weighting function on . A clique is a subset of such that each pair of vertices in is mutually adjacent. The MWC problem is to find a clique with the greatest total weight. This problem exists in many real-world applications like [Brendel and Todorovic2010, Brendel et al.2011, Li and Latecki2012].

Currently there are two types of algorithms for solving the MWC problem: complete ones [Yamaguchi and Masuda2008, Shimizu et al.2012, Fang et al.2016, Jiang et al.2017] and incomplete ones [Pullan2008, Wu et al.2012, Cai and Lin2016, Zhou et al.2017, Nogueira et al.2017]. The incomplete algorithms are designed to find a “good” clique within reasonable time periods. In this paper, our focus is on local search, a widely accepted approach for the incomplete MWC algorithms.

1.1 Tabu and Restart in Local Search for MWC

Local search, however, often suffers from the cycling problem, i.e., a candidate solution may be visited repeatedly. To deal with the cycling problem, we may adopt the tabu strategy [Wu et al.2012]. The idea is that if the search flips a vertex’s state (i.e., puts the vertex into current candidate solution or moves it out), then the vertex should be forbidden to return to its previous state for a certain period of search steps. A crucial issue here is when to relieve such a forbidding or tabu on the vertex. Configuration Checking (CC) is an effective strategy to resolve this issue and has been widely used in state-of-the-art MWC solvers [Wang et al.2016, Fan et al.2017a, Fan et al.2017b]. The idea of CC is that the tabu on a vertex may be relieved if one of its neighbors is flipped. In this case, we say that the flipped neighbor unlocks the vertex. Note that the unlocking operations among vertices may form a small cycle, which may lead a CC-based local search being stuck in a cycle. To escape from such a cycle, a CC-based local search usually needs some other diversifying strategies like constraint weighting [Hoos and Stützle2007], which is time-consuming and impractical for large and dense graphs. This calls for a new tabu strategy which discourages the unlocking cycles and allows the local search to move in a greater area.

Restart is another strategy [Battiti and Protasi2001] for resolving the cycling problem. Recently [Fan et al.2017a] proposed a revisiting based restart strategy. They proposed the notion of first growing step and set the triggering condition for a restart as revisiting a candidate solution at the first growing step. However, the local search with this restart triggering condition may restart too early to explore intensively. Therefore, we need to strengthen the triggering condition. To do so, we propose the notion of local search scenario, which involves not only the current candidate solution but also the tabu status and the unlocking relationship. Intuitively, when the current search revisits a candidate solution, it may be differentiated in the next step due to the different tabu status from before, and it does not need a restart. Moreover, when the current search revisits a candidate solution with the same tabu status, its tabu status may be differentiated in the next step due to the different unlocking relationship, and it does not need a restart either. Thus, to avoid restarting too early, the triggering condition should be based on the re-occurrence of a local search scenario.

1.2 Our Contributions

As discussed above, we propose new tabu and restart strategies based on the notion of a local search scenario. By using the tabu and the restart strategies, we develop an MWC solver named TRSC (Tabu and Restart with Scenario Checking). Similar to the CC strategy, the proposed tabu mechanism may relieve the tabu on a vertex by flipping a neighbor of the vertex, i.e., the vertex can be unlocked by its neighbor, but this cannot be done by the same neighbor twice in a row. Our new restart strategy is based on the re-occurrence of a local search scenario instead of that of a candidate solution; in other words, if a candidate solution is revisited together with the same tabu status and unlocking relationships as before, the search needs a restart.

We are the first to use the notion of local search scenario for both the tabu and restart strategies. For implementing a tabu strategy, this work maintains a local search scenario, while previous approaches do not consider the unlocking relationship. For the restart purpose, this work computes the hash value of local search scenarios, while previous approaches do the hash of visited candidate solutions. Moreover, our tabu and restart strategy interact and cooperate well. Since we employ a tabu strategy which is more restrictive than the strong configuration checking (SCC) strategy [Wang et al.2016], our local search can travel in a loop bigger than before. So if we still use the previous restart strategies like those in [Fan et al.2017a] and [Fan et al.2017b], the search will restart before a loop is visited completely, which we think is too early.

To show the effectiveness of our approach, we compare our solver with state-of-the-art ones: LSCC [Wang et al.2016], RRWL [Fan et al.2017a] and TSM-MWC [Jiang et al.2018] on the DIMACS [Johnson and Trick1996] and BHOSLIB [Xu et al.2005] benchmarks111, which were used in a wide range of recent papers. We also compare these solvers on some graphs from real-world applications, i.e., the Winner Determination Problem (WDP) [Leyton-Brown et al.2000, Lau and Goh2002, Sandholm2002]333, the Error-correcting Codes (ECC) [Östergård2001], the Kidney-exchange Schemes (KES) and the Research Excellence Framework (REF) [McCreesh et al.2017]444 Experimental results show that our solver outperforms several state-of-the-art solvers on the DIMACS, BHOSLIB, and some benchmarks from practical applications. Furthermore, it is comparable with state-of-the-art on the remaining benchmarks.

2 Preliminaries

We say that and are neighbors, or and are adjacent to each other, if there is an edge . Also we use to denote , the set of ’s neighbors. A maximal clique is a clique which is not a subset of any other clique. Given a weighting function , the weight of a clique , denoted by , is defined to be . We use to denote the number of steps since last time changed its state (inside or outside the candidate clique). Given two vertices and where , we say if . Let be a bijection , which gives each edge an integer id between and . Therefore, given two vertices and , denotes the id of the edge which connects and .

2.1 The Benchmark

As to the DIMACS and the BHOSLIB benchmarks, we first obtain the Maximum Clique instances or convert the Maximum Independent Set instances into the complement graphs. Then we use the method in [Pullan2008] to generate the vertex weights, i.e., for the -th vertex , . Also, we compare state-of-the-art MWC solvers on a list of benchmarks from practical applications.

2.2 Multi-neighborhood Search

In order to find a good clique, the local search usually moves from one clique to another until the cutoff arrives, then it returns the best clique that has been found. There are three operators: add, swap and drop, which guide the local search to move in the clique space. In [Fan et al.2016] two sets were defined as below which ensures that the clique property is preserved:

For simplicity we will write and in short for and respectively. We use , and to denote the increase of for the operations add, swap and drop respectively. Obviously, we have (1) for a vertex , ; (2) for a vertex , ; (3) for a vertex pair , .

2.3 The Strong Configuration Checking Strategy

Recently, [Cai et al.2011] proposed the configuration checking (CC) strategy to reduce cycling. The CC strategy works as follows. If a vertex is removed out of the candidate set, it is forbidden to be added back into the candidate set until its configuration has been changed. Typically, the configuration of a vertex refers to the state of its neighboring vertices.

The CC strategy is usually implemented with a Boolean array named , where means that ’s configuration has changed since last time it was removed, and otherwise.

Later [Wang et al.2016] modified CC into a more restrictive version, which is called strong configuration checking (SCC), to deal with the MWC problem. The main idea of the SCC strategy is as follows: after a vertex is dropped from or swapped from , it can be added or swapped back into only if one of its neighbors is added into .

In details, the SCC strategy works as follows. (1) Initially is set to 1 for each vertex ; (2) When is added, is set to 1 for all ; (3) When is dropped, is set to 0; (4) When are swapped, is set to 0. Lastly is also referred to as ’s tabu status.

2.4 A Fast Hashing Function

[Fan et al.2017a] proposed a fast hashing function as below which detects revisiting both efficiently and effectively.

Definition 1

Given a clique and a prime number , we define the hash value of , denoted by , as , which maps a clique to its hash entry .

At the beginning, they calculate iteratively with different values of , based on the proposition below.

Proposition 1


These values are then saved in an array for later references. Hence, in Theorem 2 below, the subformulas can be computed in constant complexity. So the hash value of the current clique can be updated in complexity as well.

Theorem 2

Let be the current clique, then we have

  1. ;

  2. .

2.5 Review of LSCC

LSCC consists of two procedures: randomly generating a maximal clique and improving in a deterministic way. In each local move, LSCC selects the neighboring clique with the greatest weight according to the SCC criterion. Every steps, the search is restarted.

[Fan et al.2017b] showed that without restarts, LSCC may fall into a dead loop, , no matter how many steps it performs, it always miss the optimal solution (See Example 1). Here we cite their example graph. In the next section, we will explain why LSCC is misled and propose a new tabu strategy to deal with this case.

Example 1

Consider the graph , where for any and . Obviously the optimal solution in is .

  1. Initially at Step 1, . Suppose we select as the first vertex and put it into , then LSCC obtains a clique . Meanwhile for all .

  2. Next the local search reaches at Step 9. At the same time for all .

  3. Then the local search moves back to at Step 14. Meanwhile for all .

Then the local search repeats the steps above and is restricted in a cycle, without finding the optimal solution.

3 Tabu and Restart with Scenario Checking

We propose a tabu strategy and a restart strategy based on the notion of a local search scenario. The two strategies coordinate with each other.

3.1 Forbidding Repeated Unlocking

We say that vertex is unlocked by its neighbor if the tabu on is relieved just after is flipped. Note that a vertex can be unlocked by different vertices in different steps. We use to denote the last vertex which unlocks . We use to denote the unlocking relation, i.e., . Therefore given , it can be read as was unlocked by last time.

3.1.1 Unlocking Graph

Based on Example 1, we have a graph below, which is called unlocking graph. It describes the unlocking operations during the local search dead loop. For instance, at Step 8 unlocks , and at Step 9 unlocks and . Each time the search traverses the local search dead loop, each unlocking operation in the graph will be performed once.

Step 9

Step 14

Step 9

Step 14

Step 13

Step 8

In this unlocking graph, we observe that there are two unlocking cycles: and

. These unlocking cycles and the best-picking heuristic together lead the search back to a visited solution, with the tabu status the same as before. So the local search is restricted in a dead loop.

3.1.2 Our Strategy

In this situation, we need to delete some of the directed edges in the unlocking graph so that the local search can escape. So we propose a tabu management strategy as below, which is called Forbidding Repeated Unlocking (FRU).

  1. Initially and ;

  2. When is added into ,

    1. is set to ,

    2. s.t. and , and ;

  3. When is dropped or swapped from , .

Initially when all vertices are free, none of the vertices has been unlocked, so is set to for all . In Item (b), can be unlocked by only if was not unlocked by last time, i.e., cannot be unlocked by twice in a row. Item (a) is tricky and will be explained in Section 3.2. We use denote the set of free vertices, and is also referred to as ’s tabu status.

3.2 Considering Tabu in the Restart Strategy

We use local search scenario to describe the solution, the tabu status and the unlocking relation as a whole in a given step.

Definition 2

The local search scenario in Step , denoted by , is defined as a tuple which consists of the solution , the tabu status and the unlocking relation in Step , i.e., .

So a local search scenario depicts much information which will determine the following local search steps to a great extent. In other words, if a local search scenario re-occurs, the search may probably be restricted in a cycle. For simplicity, we write a local search scenario as


3.2.1 An Extended Hash Function

We use a hash table to approximately detect the re-occurrence of a local search scenario. Since the collisions, i.e., different scenarios may share the same hash entry, are rare in our settings, we do not resolve them. Below we define a hash function where is a prime number.

So far as we know, all previous hashing strategies compute the hash value of a candidate solution, e.g., [Battiti and Protasi2001], and we are the first time to compute the hash value of a local search scenario. During the search, we will use the methods in Section 2.4 to maintain the hash value of the current local search scenario, and we set . With this prime number , our hash table consumes around 1 GB memory. In our experiments, our solver performs less than steps in any run. Therefore given the hash entries, the number of collisions is negligible.

Now we return to Item (a) in our tabu rules. In usual local search solvers, a vertex is always allowed to be removed. In this sense, whether or does not matter, hence, we always set to be so that this unimportant difference will not affect the hash value.

4 The TRSC Algorithm

The top level algorithm is shown in Algorithm 1, where the localMove() procedure is shown in Algorithm 2.

input : A graph and the cutoff
output : The best clique that was found
1 ; ; for all ;
2 while elapsed time cutoff do  localMove() ;
return ;
Algorithm 1 TRSC
1 if  then
2       add a random vertex into ;
3       while  do  add a random vertex from ;
4       true;
5 a vertex in such that with the biggest ; otherwise ;
6 a pair in such that with the biggest ; otherwise ;
7 if  then
8       if or then ; else ;
9       true;
10 else
11       if  or  then
12             if  true then
13                   if  then ;
14                   if  is marked then
15                         drop all vertices in ; ++; return;
16                  mark ;
17             false;
18      else
19             true;
20       a vertex in with the biggest ;
21       if or then ; else ;
apply FRU rules; ++;
Algorithm 2 localMove

In Algorithm 2, the arguments of the functions are explicit from the context and thus omitted. All ties are broken in favor of the oldest one just like LSCC. We employ a predicate s.t. true iff the clique weight was increased in the last step. Then we use to identify local optima. When both the conditions in Lines 2 and 2 hold, a local optimum is reached. We will mark and detect the occurrence of a local search scenario only at local optima, because we desire to decrease the number of hash entries that need to be marked. So the hash collisions hardly exist.

Now we run TRSC on the graph in Example 1 as below.

Example 2
  1. Initially . Like Example 1, suppose we select as the first vertex, then TRSC obtains a clique which is a local optimum. At this time . Meanwhile and for all , so . We denote this local search scenario by .

  2. Then we will perform steps just like those in Example 1. More specifically the local search moves to , which is also a local optimum, and we denote this local search scenario as . Then the local search moves back to . At this time, for all , and , , , . We denote this local search scenario by . Notice that not only has the solution been revisited in this step, the tabu status has also become the same as before. However, the unlocking relation is not the same as before, so , i.e., this current local search scenario has not occurred before. Hence, our solver does not restart.

  3. Next the local search moves to again, and the last vertex which enters is . However, things are different at this time because of the FRU strategy. Since and was unlocked by last time, neither of them can be unlocked by this time. That is, still holds at this time, which will prevent the local search from moving back to . We denote this current local search scenario by . Notice that .

  4. So the local search changes its direction and move to which is the optimal solution.

So we see that TRSC can search a local area more thoroughly than LSCC. Notice that if we adopted previous restart strategies like those in [Fan et al.2017a] and [Fan et al.2017b], the search would restart before the occurrence of . In this case the FRU strategy behaves simply the same as the SCC strategy.

5 Implementations

In this section we will show how to implement the tabu and the restart strategy when a vertex is added (See Algorithm 3).

In Algorithm 3, Lines 3, 3, 3, 3, 3 and 3 show how to update the hash value of the current local search scenario, while the other lines implement our proposed tabu strategy. Notice Line 3. If a vertex is unlocked for the first time, then no vertices have ever unlocked it, so we do not delete the respective tuple.

In the Algorithm 3, our solver will need to compute the value of . It will do this just as what CERS555 [Fan et al.2017b] does when solving the maximum edge weight clique problem, so we have

Proposition 3

Computing in Algorithm 3 can be done in complexity.

Considering that for has been computed and stored in an array before, we have

Proposition 4

In any local search step,
, and can all be computed in complexity.

So all the lines which update the hash value of a local search scenario can be executed in complexity. For example Line 3 can be implemented as follows. if , and otherwise. On the other hand, Line 3 can be implemented as follows. if , and otherwise. Therefore we have

Theorem 5
  1. The complexity of maintaining the hash value of a local search scenario wrt to add and drop is , where is the degree of .

  2. The respective complexity for swap is .

1 update wrt. add into ;
2 if  then
3       ;
4       update wrt. unlock ;
5foreach  do
6       if  or  then  continue ;
7       if  then
8             update wrt. delete ;
9      ; ;
10       update wrt. insert ;
11       update wrt. unlock ;
Algorithm 3 add()

6 Empirical Evaluations

We compare our solver to state-of-the-art complete and incomplete solvers including TSM-MWC, RRWL and LSCC.

6.1 Experimental Protocol

For LSCC, the search depth was set to 4,000 as is in [Wang et al.2016]. TSM-MWC was compiled by gcc 6.3.0 with -O3 option and all other solvers were compiled by g++ 4.7.3 with -O3 option. The experiments were conducted on a cluster equipped with Intel(R) Xeon(R) CPUs X5650 @2.67GHz with 16GB RAM, running Red Hat Santiago OS. Since TSM-MWC is an exact solver, it was executed on each instance only once. Each other solver was executed on each instance with seeds from 1 to 100. The cutoff was set to 3,600s for each solver on each instance.

In each table, we report the maximum weight (“”) and averaged weight (“”) of the cliques found by the algorithms. As to TSM-MWC, if it is able to confirm the optimality of the returned solution, we mark * in the respective table entry; otherwise, we report that best-found solution within the cutoff. Also since TSM-MWC was executed on each instance only once, we used the weight of the returned solution as both the and the values. In each table, we only list those graphs on which all solvers did not find the same or values. For the sake of space, we abbreviate some instance names.

6.2 The Benchmarks

We considered two types of datasets: (1) the DIMACS and the BHOSLIB benchmarks; (2) the benchmarks from practical applications including Winner Determination Problem (WDP), Error-correcting Codes (ECC), Research Excellence Framework (REF) and Kidney-exchange Schemes (KES).

In details, the WDP instances are divided into three test sets. (1) The first set contains 499 relatively easy instances provided by [Lau and Goh2002] with up to 1500 items and 1500 bids. These instances are divided into 5 different groups, each group labeled as REL--, where is the number of items and is the number of bids. (2) The second set contains 20 challenging instances obtained from a generator provided by [Sandholm2002] (SAND). (3) The third set contains 10 challenging instances generated randomly by the program combinatorial auction test suite (CATS) generator developed by [Leyton-Brown et al.2000]. Furthermore the REF instances are divided into two test sets. (1) The first one (GOLD-RAG-REF) contains 100 relatively easy instances. (2) The second one (RAG-REF) contains 29 challenging instances. Lastly the KES dataset contains 100 instances named from 001.wclq to 100.wclq. We only used those 50 challenging instances named from 051.wclq to 100.wclq, since the first 50 instances are easy to solve. Lastly the ECC benchmark contains 15 instances which are all relatively easy.

In each group of the relatively easy instances, the solutions returned by TRSC were all proved to be optimal by TSM-MWC, i.e., it found the optimal solution in any run. In Table 1, we present the averaged time (seconds) needed to locate the respective solutions for each solver in each group (“LocateTime”). Since TSM-MWC is able to confirm the optimality of the returned solution, we also report the time needed to find and prove the optimal solution (“ConfirmTime”).

LocateTime ConfirmTime LocateTime
REL-500-1000 18.53 23.86 27.37
REL-1000-1000 0.7 0.95 3.06
REL-1000-500 0.02 0.03 0.23
REL-1000-1500 0.57 0.8 3.54
REL-1500-1500 0.98 1.32 3.99
ECC 4.34 13.65 0.07
GOLD-RAG-REF 0.02 1.59 0.01
Table 1: Experimental Results on Relatively Easy Graphs
frb56-25-1 3693 5886(5834.58) 5916(5841.13) 5916(5850.63)
frb56-25-2 4470 5886(5826.08) 5886(5827.72) 5882(5842.6)
frb56-25-3 3958 5844(5792.07) 5842(5795.35) 5854(5805.8)
frb56-25-4 4609 5873(5833.78) 5877(5830.09) 5877(5840.62)
frb56-25-5 4023 5817(5766.64) 5810(5774.23) 5843(5785.52)
frb59-26-1 4469 6591(6548.68) 6591(6539.59) 6591(6554.16)
frb59-26-2 5105 6645(6558.62) 6645(6552.96) 6645(6568.67)
frb59-26-3 4373 6576(6523.49) 6606(6532.8) 6606(6542.24)
frb59-26-4 4916 6592(6501.58) 6592(6505.26) 6592(6518.74)
frb59-26-5 5038 6584(6527.69) 6569(6523.45) 6581(6533.69)
frb65-28-1 5208 7410(7319.63) 7405(7353.08) 7432(7377.73)
frb65-28-2 4788 7421(7369.89) 7425(7365.99) 7441(7380.56)
frb65-28-3 4857 7449(7359.52) 7434(7361.07) 7445(7377.62)
frb65-28-4 4587 7433(7366.07) 7438(7366.83) 7448(7381.88)
frb65-28-5 4881 7451(7354.89) 7451(7354.73) 7451(7374.99)
frb70-30-1 5125 7717(7597.72) 7688(7600.97) 7772(7617.76)
frb70-30-2 5159 7749(7668.98) 7734(7667.96) 7777(7689.7)
frb70-30-3 4635 7678(7622.72) 7733(7620.69) 7696(7638.95)
frb70-30-4 4918 7739(7680.75) 7750(7684.43) 7766(7703.22)
frb70-30-5 5402 7749(7669.0) 7725(7666.93) 7740(7683.99)
frb75-32-1 5168 8615(8537.8) 8637(8532.98) 8621(8556.81)
frb75-32-2 5820 8644(8569.07) 8657(8570.63) 8667(8583.37)
frb75-32-3 5928 8619(8506.95) 8565(8496.14) 8600(8528.81)
frb75-32-4 6315 8714(8589.85) 8688(8590.29) 8692(8607.74)
frb75-32-5 5393 8663(8590.24) 8655(8591.12) 8644(8602.52)
frb80-33-1 5819 9353(9249.81) 9461(9242.11) 9407(9294.27)
frb80-33-2 5783 9343(9251.12) 9390(9248.75) 9387(9293.51)
frb80-33-3 5954 7449(7359.52) 7434(7361.07) 7445(7377.62)
frb80-33-4 6655 9387(9305.08) 9430(9301.91) 9408(9332.44)
frb80-33-5 6167 9413(9337.37) 9415(9341.21) 9478(9360.45)
C2000.9 8338 10999(10942.27) 10999(10951.67) 10999(10965.43)
C4000.5 2438 2792(2792.0) 2792(2792.0) 2792(2792.0)
hamming10-4 4828 5129(5129.0) 5129(5129.0) 5129(5129.0)
keller6 4793 8062(7841.39) 8062(7891.05) 8062(7961.9)
MANN_a45 34265 34254(34244.51) 34263(34254.75) 34262(34254.18)
MANN_a81 110037 111126(111093.81) 111346(111306.32) 111356(111305.79)
Table 2: Results on Vertex-weighted BHOSLIB and DIMACS
Decay_100 84535100(83250072.0) 85281200(84059567.0) 85510000(84706031.0)
Decay_200 149346900(145222082.0) 151127500(146679501.0) 151727300(147776429.0)
Decay_300 210276200(206690975.0) 212143900(207974912.0) 214579300(208712490.0)
Decay_400 255183300(249843205.0) 257921100(251010990.0) 258063500(251908678.0)
Decay_500 313889900(309658340.0) 316621400(311568688.0) 321463500(311769095.0)
uni_500_10 26564200(26555349.0) 26564200(26558697.0) 26564200(26553017.0)
arbi_40 40460122(39971566.63) 40460122(40460122.0) 40460122(40460122.0)
arbi_100 88001917(85989964.79) 89310479(87487330.5) 89772104(87617454.9)
matc_80 5083256(5075016.11) 5083256(5072696.82) 5081870(5070041.87)
paths_40 248514(247878.71) 248236(247799.52) 248236(247778.48)
paths_100 363213(360159.01) 363449(361218.25) 364972(361397.42)
regi_40 45588953(45430691.25) 45588953(45588953.0) 45588953(45558663.1)
regi_100 92940074(91648450.48) 93650192(92642163.28) 93682151(92599864.2)
Table 3: Results on SAND and CATS against Incomplete Solvers
Decay_100 86372100 85510000(84706031.0) arbi_40 40460122 40460122(40460122.0)
Decay_200 159676600 151727300(147776429.0) arbi_100 89772104 89772104(87617454.9)
Decay_300 222341300 214579300(208712490.0) matc_80 4544376 5081870(5070041.87)
Decay_400 267417100 258063500(251908678.0) path_40 248707 248236(247778.48)
Decay_500 326151300 321463500(311769095.0) path_100 367045 364972(361397.42)
uni_200_10 11668500 12242300(12242300.0) regi_40 45588953 45588953(45558663.1)
uni_300_10 14745800 17201100(17201100.0) regi_100 94017022 93682151(92599864.2)
uni_400_10 16872700 22022300(22022300.0) sche_40 546928 826022(826022.0)
uni_500_10 20499200 26564200(26553017.0) sche_100 1537860 1672303(1672303.0)
Table 4: Results on SAND and CATS againt Complete Solvers
081.wclq 1650240634894 1650240634895 (1650240634894.14)
091.wclq 1306441900045 1306441900046 (1306441900045.87)
092.wclq 1581403750408 1581403750408 (1569034576044.46)
095.wclq 1375228477453 1375245246480 (1375245246479.88)
096.wclq 1306374823942 1375094325251 (1357914449924.0)
097.wclq 1375144632329 1375144632330 (1375144632329.29)
099.wclq 1237722398734 1237722398735 (1237722398735.0)
100.wclq 1512701018123 1512701018124 (1512701018123.9)
Table 5: Results on Kidney Exchange Schemes
ref-60-230-0.clq 502 505(504.66) ref-60-500-0.clq 651 696(696.0)
ref-60-230-1.clq 501 506(505.0) ref-60-500-1.clq 681 709(709.0)
ref-60-230-2.clq 492 524(523.98) ref-60-500-2.clq 650 701(694.07)
ref-60-230-3.clq 492 502(502.0) ref-60-500-3.clq 673 716(716.0)
ref-60-230-4.clq 502 504(503.57) ref-60-500-4.clq 627 690(689.99)
ref-60-230-5.clq 500 503(502.81) ref-60-500-5.clq 660 714(714.0)
ref-60-230-6.clq 503 505(505.0) ref-60-500-6.clq 669 715(715.0)
ref-60-230-7.clq 503 506(504.94) ref-60-500-7.clq 657 692(692.0)
ref-60-230-8.clq 489 494(493.89) ref-60-500-8.clq 659 714(713.99)
ref-60-230-9.clq 481 526(525.66) ref-60-500-9.clq 642 704(696.72)
ref-60-300.clq 590 599(599.0) ref-60-500.clq 679 704(704.0)

Table 6: Results on RAG-REF Graphs

As to the other instances, our evaluation results are divided into two parts:

  1. DIMACS and BHOSLIB graphs (97 instances);

  2. a list of challenging graphs including: (1) WDP graphs from the SAND and the CATS groups (30 instances), (2) KES graphs (50 instances) and (3) REF graphs from the RAG-REF group (29 instances).

6.3 DIMACS and BHOSLIB Graphs

Experimental results show that TRSC significantly outperforms TSM-MWC, LSCC and RRWL in terms of average solution quality. For the sake of space, we exclude those graphs containing less than 1,400 vertices, but we keep one graph MANN_a45 which contains less than 1,400 vertices, because TSM-MWC outperforms TRSC on this instance. The detailed results are shown in Table 2.

In order to show the gap between TSM-MWC and TRSC, we extended the cutoff to be 72 hours and tested TSM-MWC again. The solution quality of TSM-MWC on most instances in this table still falls behind that of TRSC significantly.

6.4 Challenging Graphs

Judging by recent SAT/MaxSAT Competitions666;, there is a prevailing hypothesis that exact solvers perform better on benchmarks from real-world applications. Moreover, TSM-MWC has proved to be state-of-the-art over the graphs from practical applications [Jiang et al.2018]. So we mainly compare our solver with TSM-MWC here. Considering that the SAND and CATS benchmarks have not been used often, we also tested LSCC and RRWL on them.

6.4.1 SAND and CATS

Table 3 shows the comparisons between TRSC and state-of-the-art incomplete solvers. Table 4 shows the comparisons between TRSC and TSM-MWC. From these tables, we can see that TRSC significantly outperforms LSCC and RRWL. Also TRSC is complementary with TSM-MWC. Both solvers perform as well as each other.

6.4.2 KES and REF

Tables 5 shows the comparisons between TRSC and TSM-MWC on Kidney-exchange Schemes, and Tables 6 shows respective results on Research Excellence Framework. From these tables, we can see that TRSC significantly outperforms TSM-MWC. Moreover, these results refute the prevailing hypothesis that local search algorithms are less well suited for application instances.

6.5 Restart Periods

We selected 8 instances from different benchmarks, and evaluated the restart periods of LSCC, RRWL and TRSC. We used 3600s as the cutoff and seeds from 1 to 10. The results are in Table 7. For instance, on 100.wclq in the Kidney-Exchange Schemes benchmark, RRWL restarts every 29,033 steps while TRSC restarts every 34,685 steps on average. Notice that LSCC always restarts every 4,000 steps simply because of its default parameter setting [Wang et al.2016]. In Table 7, we can find that:

  1. the restart periods of RRWL and TRSC vary significantly from instance to instance;

  2. TRSC usually has a longer restart period than RRWL, i.e., TRSC usually restarts less frequently than RRWL.

This is consistent with our expectations since TRSC employ stronger tabu and more conservative restart strategies.

100.wclq 4,000 29,033 34,685
arbitrary_40.txt 4,000 52 234
Decay2000_500.txt 4,000 952 1,424
frb-80-33-5.clq 4,000 1,289 2,313
MANN_a81.clq 4,000 40,055 157,602
ref-60-500.clq 4,000 3,060 2,988
scheduling_100.txt 4,000 1,389 8,663
uniform2000_500_10.txt 4,000 425 608
Table 7: Restart Periods of LSCC, RRWL and TRSC

7 Conclusions and Future Work

In this paper, we advanced both tabu and restart strategies based on the notion of a local search scenario, and developed a local search search MWC solver called TRSC. TRSC outperforms several state-of-the-art solvers by extensive experiments including those on the two influential benchmarks of BHOSLIB and DIMACS. Moreover, the reported results refute the prevailing hypothesis that local search algorithms are less well suited for application graphs.

As for future work, we will study variants of the tabu and restart strategies in other combinatorial optimization problems like maximum satisfiability and minimum vertex cover, as these two strategies are fundamental ones for local search. Currently we are investigating whether these strategy are also effective in the classic maximum clique problem.


  • [Battiti and Protasi2001] Roberto Battiti and Marco Protasi. Reactive local search for the maximum clique problem. Algorithmica, 29(4):610–637, 2001.
  • [Brendel and Todorovic2010] William Brendel and Sinisa Todorovic. Segmentation as maximum-weight independent set. In Advances in Neural Information Processing Systems 23: 24th Annual Conference on Neural Information Processing Systems 2010. Proceedings of a meeting held 6-9 December 2010, Vancouver, British Columbia, Canada., pages 307–315, 2010.
  • [Brendel et al.2011] William Brendel, Mohamed R. Amer, and Sinisa Todorovic. Multiobject tracking as maximum weight independent set. In

    The 24th IEEE Conference on Computer Vision and Pattern Recognition, CVPR 2011, Colorado Springs, CO, USA, 20-25 June 2011

    , pages 1273–1280, 2011.
  • [Cai and Lin2016] Shaowei Cai and Jinkun Lin. Fast solving maximum weight clique problem in massive graphs. In

    Proceedings of the Twenty-Fifth International Joint Conference on Artificial Intelligence, IJCAI 2016, New York, NY, USA, 9-15 July 2016

    , pages 568–574, 2016.
  • [Cai et al.2011] Shaowei Cai, Kaile Su, and Abdul Sattar. Local search with edge weighting and configuration checking heuristics for minimum vertex cover. Artif. Intell., 175(9-10):1672–1696, 2011.
  • [Fan et al.2016] Yi Fan, Chengqian Li, Zongjie Ma, Lian Wen, Abdul Sattar, and Kaile Su. Local search for maximum vertex weight clique on large sparse graphs with efficient data structures. In AI 2016: Advances in Artificial Intelligence - 29th Australasian Joint Conference, Hobart, TAS, Australia, December 5-8, 2016, Proceedings, pages 255–267, 2016.
  • [Fan et al.2017a] Yi Fan, Nan Li, Chengqian Li, Zongjie Ma, Longin Jan Latecki, and Kaile Su. Restart and random walk in local search for maximum vertex weight cliques with evaluations in clustering aggregation. In Proceedings of the Twenty-Sixth International Joint Conference on Artificial Intelligence, IJCAI 2017, Melbourne, Australia, August 19-25, 2017, pages 622–630, 2017.
  • [Fan et al.2017b] Yi Fan, Zongjie Ma, Kaile Su, Chengqian Li, Cong Rao, Ren-Hau Liu, and Longin Jan Latecki. Efficient local search for maximum weight cliques in large graphs. In 2017 IEEE 29th International Conference on Tools with Artificial Intelligence, Boston, MA, USA, November 6-8, 2017, page to appear, 2017.
  • [Fang et al.2016] Zhiwen Fang, Chu-Min Li, and Ke Xu. An exact algorithm based on maxsat reasoning for the maximum weight clique problem. J. Artif. Intell. Res., 55:799–833, 2016.
  • [Hoos and Stützle2007] Holger H. Hoos and Thomas Stützle. Stochastic local search. In Handbook of Approximation Algorithms and Metaheuristics. 2007.
  • [Jiang et al.2017] Hua Jiang, Chu-Min Li, and Felip Manyà. An exact algorithm for the maximum weight clique problem in large graphs. In Proceedings of the Thirty-First AAAI Conference on Artificial Intelligence, February 4-9, 2017, San Francisco, California, USA., pages 830–838, 2017.
  • [Jiang et al.2018] Hua Jiang, Chu-Min Li, and Felip Manyà Yanli Liu. A two-stage maxsat reasoning approach for the maximum weight clique problem. In Proceedings of the Thirty-Second AAAI Conference on Artificial Intelligence, February 2-7, 2018, New Orleans, Louisiana, USA., page To appear, 2018.
  • [Johnson and Trick1996] David J. Johnson and Michael A. Trick, editors. Cliques, Coloring, and Satisfiability: Second DIMACS Implementation Challenge, Workshop, October 11-13, 1993. American Mathematical Society, Boston, MA, USA, 1996.
  • [Lau and Goh2002] Hoong Chuin Lau and Yam Guan Goh. An intelligent brokering system to support multi-agent web-based 4th-party logistics. In 14th IEEE International Conference on Tools with Artificial Intelligence (ICTAI 2002), 4-6 November 2002, Washington, DC, USA, page 154, 2002.
  • [Leyton-Brown et al.2000] Kevin Leyton-Brown, Mark Pearson, and Yoav Shoham. Towards a universal test suite for combinatorial auction algorithms. In EC, pages 66–76, 2000.
  • [Li and Latecki2012] Nan Li and Longin Jan Latecki. Clustering aggregation as maximum-weight independent set. In Advances in Neural Information Processing Systems 25: 26th Annual Conference on Neural Information Processing Systems 2012. Proceedings of a meeting held December 3-6, 2012, Lake Tahoe, Nevada, United States., pages 791–799, 2012.
  • [McCreesh et al.2017] Ciaran McCreesh, Patrick Prosser, Kyle Simpson, and James Trimble. On maximum weight clique algorithms, and how they are evaluated. In Principles and Practice of Constraint Programming - 23rd International Conference, CP 2017, Melbourne, VIC, Australia, August 28 - September 1, 2017, Proceedings, pages 206–225, 2017.
  • [Nogueira et al.2017] Bruno Nogueira, Rian G. S. Pinheiro, and Anand Subramanian. A hybrid iterated local search heuristic for the maximum weight independent set problem. Optimization Letters, Mar 2017.
  • [Östergård2001] Patric R. J. Östergård. A new algorithm for the maximum-weight clique problem. Nordic J. of Computing, 8(4):424–436, December 2001.
  • [Pullan2008] Wayne J. Pullan. Approximating the maximum vertex/edge weighted clique using local search. J. Heuristics, 14(2):117–134, 2008.
  • [Sandholm2002] Tuomas Sandholm. Algorithm for optimal winner determination in combinatorial auctions. Artif. Intell., 135(1-2):1–54, 2002.
  • [Shimizu et al.2012] Satoshi Shimizu, Kazuaki Yamaguchi, Toshiki Saitoh, and Sumio Masuda. Some improvements on kumlander’s maximum weight clique extraction algorithm. In Proceedings of World Academy of Science, Engineering and Technology, number 72, page 948. World Academy of Science, Engineering and Technology (WASET), 2012.
  • [Wang et al.2016] Yiyuan Wang, Shaowei Cai, and Minghao Yin. Two efficient local search algorithms for maximum weight clique problem. In Proceedings of the Thirtieth AAAI Conference on Artificial Intelligence, February 12-17, 2016, Phoenix, Arizona, USA., pages 805–811, 2016.
  • [Wu et al.2012] Qinghua Wu, Jin-Kao Hao, and Fred Glover. Multi-neighborhood tabu search for the maximum weight clique problem. Annals OR, 196(1):611–634, 2012.
  • [Xu et al.2005] Ke Xu, Frédéric Boussemart, Fred Hemery, and Christophe Lecoutre. A simple model to generate hard satisfiable instances. In IJCAI-05, Proceedings of the Nineteenth International Joint Conference on Artificial Intelligence, Edinburgh, Scotland, UK, July 30 - August 5, 2005, pages 337–342, 2005.
  • [Yamaguchi and Masuda2008] Kazuaki Yamaguchi and Sumio Masuda. A new exact algorithm for the maximum weight clique problem. ITC-CSCC: 2008, pages 317–320, 2008.
  • [Zhou et al.2017] Yi Zhou, Jin-Kao Hao, and Adrien Goëffon. PUSH: A generalized operator for the maximum vertex weight clique problem. European Journal of Operational Research, 257(1):41–54, 2017.