constraints on set variables for constraint-based local...

IT 11 068

Examensarbete 30 hpSeptember 2011

Constraints on Set Variables for Constraint-based Local Search

Rodrigo Ronald Gumucio Escobar

Institutionen för informationsteknologiDepartment of Information Technology

IT 11 068

Examensarbete 30 hpSeptember 2011

Constraints on Set Variables for Constraint-based Local Search

Rodrigo Ronald Gumucio Escobar

Institutionen för informationsteknologiDepartment of Information Technology

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student

Abstract

Constraints on Set Variables for CBLS

Rodrigo R. Gumucio E.

This MSc thesis demonstrates the same effect of set variables for Constraint-BasedLocal Search (CBLS) as was already shown for classical Constraint Programming(under systematic search), namely that set variables are not only a convenience forfaster and higher-level modeling, but also sometimes necessary because probleminstances with integer variables would not fit into memory or take much more timeto be solved.

Several experiments have been carried out to this end using the Comet programminglanguage by extending its CBLS back-end to support constraints on set variables. Theexperiments consist in solving hard combinatorial problems. All measurements aregiven together with the source code.

Tryckt av: Reprocentralen ITCIT 11 068Examinator: Anders JanssonÄmnesgranskare: Justin PearsonHandledare: Pierre Flener









Abstract

Constraints on Set Variables for CBLS

con cariño, a mis padres Karla y Jorge

Preface

This report is the result of my MSc thesis project carried on at the ASTRA re-search group on Constraint Programming in the Dept of Information Technol-ogy at Uppsala University (http://www.it.uu.se/research/group/astra).

For more information or constructive comments please send me an e-mail. I’lltry to keep my contact information updated and available at http://home.student.uu.se/rogu1637/.

http://www.it.uu.se/research/group/astra


http://home.student.uu.se/rogu1637/

http://home.student.uu.se/rogu1637/

Acknowledgements

I was recently introduced to Constraint Programming and it was amazing tosee both how elegantly it manages the complexity of many hard problemsand how quickly it finds (optimal) solutions to them. Programming shoulddefinitely be declarative and go in that direction: once (easily) expressed theproblem, let the computer efficiently find the solution for you.

I’d like to thank very much to Pierre Flener who, after hearing my interestin set variables and set constraints, showed to me a couple of potential top-ics to work on, then supervised my progress, and finally kindly arranged abrief discussion with Pascal Van Hentenryck once I finished my project. Anespecial thanks to Pascal for his useful comments. Studying Constraint-basedLocal Search has widened my horizon way beyond I expected!

A preliminary study pursuing the same objectives of this thesis was madeby Loïc Blet (during an internship at ASTRA1 in the summer of 2010). I’d liketo thank Loïc for passing me the torch and offering advice. His report togetherwith some pieces of advice he forwarded to me have constituted a very goodstarting point. These useful advices turned out to be actually the result of athree-way discussion between Pierre, Loïc, and Vianney Le Clément.

Perhaps I should also mention here that, curiously, after meeting Loïc inthe Autumn 2009 Logic Programming course, was precisely he who gaveme good references about the Constraint Programming course in a course in-formation fair held at Uppsala University. I’m now glad to have picked thatcourse!

Thanks also to Farshid Hassani Bijarbooneh for helping me with some prac-tical details when dealing with ASTRA’s experiment server.

I’ve been studying over so many years now that it is a must to thank all ofmy teachers both here at Uppsala and there at Cochabamba. A special thanksto them for teaching me how to learn by myself.

Finally, thank to my family for their support and to all those of you whohave helped me when I was facing the surprisingly challenging task that endedup to be for me coming here to study. Everything has been worth it.

1ASTRA Group on Constraint Programming http://www.it.uu.se/research/group/astra



Reading guide

This thesis report is meant to be self-contained. To this end, it provides allthe necessary definitions behind Constraint-based Local Search in Part I aswell as a description of the architecture of the Comet system and its localsearch structures in Part II. The main matter of this thesis is then divided inthree parts. First, Part III explains how the CBLS (Constraint-based LocalSearch) back-end of Comet was extended to support set constraints; second,Part IV presents three experiments contrasting CBLS using constraints on setvariables against CBLS using constraints on integer variables; finally, Part Vshows another two experiments made only with exploration purposes. Con-clusions are given in Part VI together with the contributions made with thiswork, a recommendation for further work, and the list of references.

To the reader:

• Even though Chapter 2 is not essential, Part I is meant to be read sequen-tially. A reader familiar with CBLS can safely skip this part.

• Part II does not explore the Comet language itself, it rather describes the ar-chitecture of Comet and those structures that are later extended in Part III.A reader who is familiar with Comet’s architecture or maybe a reader whois only interested in the results and theoretical content of this thesis mayskip this part. Nevertheless, a reader who would like to explore the appen-dices and perhaps perform further experimentation is encouraged to readit.

• Parts III and IV constitute the backbone of this thesis. The main resultsare given in Part IV. A reader who would like to make experiments withset-CBLS in Comet might be particularly interested in Part III.

• Part V can be safely skipped, but Part VI is, of course, recommended.

All the chapters for the experiments stand on its own, so they can be readin any order. Furthermore, each experiment have an associated appendix con-taining its implementation.

Contents

Part I: Constraint Based Local Search (CBLS)1 Constraint Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1 Integer and Set variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Constraints and set constraints . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.1 Global Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.2 Implicit Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3 Constraint Satisfaction Problems (CSP) and Set-CSP . . . . . . . . 82 Constraint Programming (CP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Constraints for CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 Constraint Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3 Constructive Systematic Search . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.1 Search Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.2 Exploration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4 Symmetry Breaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Constraint-based Local Search (CBLS) . . . . . . . . . . . . . . . . . . . . . 27

3.1 Moves and Neighborhoods . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1.1 Moves and Neighborhoods for Integer Variables . . . . . . . 303.1.2 Moves and Neighborhoods for Set Variables . . . . . . . . . . 31

3.2 Constraints for Local Search . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3 Local Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3.1 Properties of Neighborhoods . . . . . . . . . . . . . . . . . . . . . . 393.3.2 Heuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.3.3 Meta-Heuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.4 Constraint-based Local Search . . . . . . . . . . . . . . . . . . . . . . . . . 493.4.1 Incremental Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 513.4.2 Differentiation Functions . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.5 Symmetry Breaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Part II: CBLS in Comet4 The Comet System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.1.1 Incremental Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.1.2 Invariants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.1.3 Differentiable Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.1.4 Heuristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.2 The Comet Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5 Local Search Structures in Comet . . . . . . . . . . . . . . . . . . . . . . . . . 635.1 Incremental Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.2 Invariants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.4 Constraint Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.5 Generic Search Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Part III: Adding Set Constraints to Comet’s CBLS Back-End6 Extending the CBLS Back-End of Comet . . . . . . . . . . . . . . . . . . . 71

6.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716.2 Set Constraints for Comet’s CBLS Back-End . . . . . . . . . . . . . 726.3 Set Constraint System for Comet’s CBLS Back-End . . . . . . . . 78

Part IV: Effect of Set Variables and Set Constraints for CBLS7 The Social Golfer Problem (golf-g-s-w) . . . . . . . . . . . . . . . . . 91

7.1 The Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927.1.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927.1.2 Search Heuristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977.1.3 Setup of the Experiment . . . . . . . . . . . . . . . . . . . . . . . . . 102

7.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057.2.1 Integer Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067.2.2 Set Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087.2.3 Comparison Between the Integer and Set Approaches . . . 1117.2.4 Solved Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

7.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1148 Steiner Triple Systems (sts-v) . . . . . . . . . . . . . . . . . . . . . . . . . . 115


8.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248.2.1 Integer Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248.2.2 Set Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1288.2.3 Comparison Between the Integer and Set Approaches . . . 1308.2.4 Solved Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

8.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1389 Schur’s Lemma (schur-k-n) . . . . . . . . . . . . . . . . . . . . . . . . . . . 139


9.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1489.2.1 Integer Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1499.2.2 Set Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

9.2.3 Comparison Between the Integer and Set Approaches . . . 1499.2.4 Solved Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

9.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Part V: Other Experiments with Comet and Set-CBLS10 The Scene Allocation Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

10.1 The Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15610.1.1 Objective Functions in Local Search . . . . . . . . . . . . . . . . 15610.1.2 Set Objective Functions for Comet CBLS’s Back-End . . 15810.1.3 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15910.1.4 Objective Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15910.1.5 Search Heuristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16010.1.6 Setup of the Experiment . . . . . . . . . . . . . . . . . . . . . . . . . 164

10.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16510.2.1 Integer Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16510.2.2 Set Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16610.2.3 Comparison Between the Integer and Set Approaches . . . 166

10.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16811 Balanced Incomplete Block Designs (BIBD-v-b-r-k-lambda) 169

11.1 The Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17011.1.1 A Different Approach to Local Search . . . . . . . . . . . . . . . 17011.1.2 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17011.1.3 Search Heuristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17211.1.4 Setup of the Experiment . . . . . . . . . . . . . . . . . . . . . . . . . 174

11.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17411.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Part VI: Conclusions and References12 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17913 Contributions and Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

13.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18113.2 Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

14 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18515 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

AppendicesImplementation of golf-g-s-w . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

15.1 Integer Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19315.2 Set Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Implementation of sts-v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21115.3 Integer Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21115.4 Set Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Implementation of schur-k-n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22715.5 Integer Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

15.6 Set Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Implementation of the Scene Allocation Problem . . . . . . . . . . . . . . . . . 239

15.7 Set Objective Functions for Comet’s CBLS Back-End . . . . . . 23915.8 Integer Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24015.9 Set Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Implementation of BIBD-v-b-r-k-lambda . . . . . . . . . . . . . . . . . . 249Colophon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

List of Figures

1.1 Solution and configuration examples for 4-queens . . . . . . . 10

2.1 A solution for 4-queens using CP . . . . . . . . . . . . . . . . . . . . 122.2 DFA for an specific instance of the regular constraint . . . . . . . 152.3 Propagator for the regular constraint . . . . . . . . . . . . . . . . . . . . 162.4 Constraint propagation algorithm . . . . . . . . . . . . . . . . . . . . . . 182.5 A Sudoku puzzle instance . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.6 Constraint propagation for a Sudoku puzzle instance . . . . . . . 192.7 Search tree example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.8 Depth-first exploration algorithm . . . . . . . . . . . . . . . . . . . . . . 232.9 Left-most branch-and-bound tree example . . . . . . . . . . . . . . . 242.10 Branch-and-bound algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 252.11 Symmetric solutions for 4-queens and unique solution to

the magic hexagon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1 Local search for 5-queens . . . . . . . . . . . . . . . . . . . . . . . . . 283.2 Simple local search algorithm . . . . . . . . . . . . . . . . . . . . . . . . 373.3 Local search for graph partitioning . . . . . . . . . . . . . . . . . . . . . 383.4 Generic local search algorithm . . . . . . . . . . . . . . . . . . . . . . . . 413.5 Best-improvement local search algorithm . . . . . . . . . . . . . . . . 423.6 First-improvement local search algorithm . . . . . . . . . . . . . . . . 423.7 Random-improvement local search algorithm . . . . . . . . . . . . . 433.8 Random-nonWorsening local search algorithm . . . . . . . . . . . . 433.9 Restarts local search meta-heuristic algorithm . . . . . . . . . . . . 443.10 Simulated annealing algorithm . . . . . . . . . . . . . . . . . . . . . . . . 453.11 Generalized generic local search algorithm . . . . . . . . . . . . . . . 453.12 First approximation to tabu-search algorithm . . . . . . . . . . . . . 463.13 Local search: simple intensification algorithm . . . . . . . . . . . . 483.14 CBLS algorithm for n-queens . . . . . . . . . . . . . . . . . . . . . . 503.15 Initial configuration and solution for 8-queens . . . . . . . . . . 513.16 Effect of an assign differentiation function . . . . . . . . . . . . . . . 533.17 CBLS iterations for 8-queens . . . . . . . . . . . . . . . . . . . . . . . 54

4.1 Comet’s architecture for CBLS . . . . . . . . . . . . . . . . . . . . . . . 58

6.1 Set constraints for Comet’s CBLS back-end . . . . . . . . . . . . . 72

7.1 CBLS integer approach to the Social Golfer Problem . . . . . . . 987.2 CBLS set approach to the Social Golfer Problem . . . . . . . . . . 100

8.1 CBLS integer approach to find a Steiner Triple System . . . . . . 1198.2 CBLS set approach to find a Steiner triple system . . . . . . . . . . 122

9.1 CBLS integer approach to Schur’s problem . . . . . . . . . . . . . . 1439.2 CBLS set approach to Schur’s problem . . . . . . . . . . . . . . . . . . 1469.3 Set invariants for Comet’s CBLS back-end . . . . . . . . . . . . . . 148

10.1 Set objective functions for Comet’s CBLS back-end . . . . . . . 15710.2 CBLS integer approach to the Scene Allocation problem . . . . 16110.3 CBLS set approach to the Scene Allocation problem . . . . . . . 163

11.1 Alternative local search approach to 5-queens . . . . . . . . . . 17111.2 Set-CBLS approach to BIBD . . . . . . . . . . . . . . . . . . . . . . . . . 173

List of Tables

6.1 Results for the set approach to Kirkman’s Schoolgirl Problem 88

7.1 A solution to golf-5-3-7 . . . . . . . . . . . . . . . . . . . . . . . . . 917.2 Instances for golf-g-s-w (reference) . . . . . . . . . . . . . . . . . 1037.3 Instances for golf-g-s-w . . . . . . . . . . . . . . . . . . . . . . . . . . 1037.4 Results for the integer approach to golf-g-s-w . . . . . . . . . 1067.5 Results for the greedy integer approach to golf-g-s-w . . . 1077.6 Run-time for both integer approaches to golf-g-s-w . . . . . 1077.7 Nb. of iterations for both integer approaches to golf-g-s-w 1087.8 Results for the set approach to golf-g-s-w . . . . . . . . . . . . 1097.9 Results for the greedy set approach to golf-g-s-w . . . . . . . 1097.10 Run-time for both set approaches to golf-g-s-w . . . . . . . . 1107.11 Nb. of iterations for both set approaches to golf-g-s-w . . . 1107.12 Run-time for both approaches to golf-g-s-w . . . . . . . . . . . 1127.13 Nb. of iterations for both approaches to golf-g-s-w . . . . . 1127.14 Run-time for both greedy approaches to golf-g-s-w . . . . . 1137.15 Nb. of iterations for both greedy approaches to golf-g-s-w 1137.16 Solved instances for golf-g-s-w . . . . . . . . . . . . . . . . . . . . 114

8.1 Results for the integer approach to sts-v . . . . . . . . . . . . . . . 1248.2 Results for the integer approach to sts-v (cont.) . . . . . . . . . 1248.3 Results for the integer approach to sts-v w/global constraint 1258.4 Results for the integer approach to sts-vw/global constraint

(cont.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258.5 Run-time for both integer approaches to sts-v . . . . . . . . . . . 1268.6 Nb. of iterations for both integer approaches to sts-v . . . . . 1268.7 Iterations per second for both integer approaches to sts-v . . 1268.8 GC-memory for both integer approaches to sts-v . . . . . . . . 1278.9 VM-memory for both integer approaches to sts-v . . . . . . . . 1278.10 Results for the set approach to sts-v . . . . . . . . . . . . . . . . . . 1278.11 Results for the set approach to sts-v (cont.) . . . . . . . . . . . . 1288.12 Results for the set approach to sts-v w/global constraint . . . 1298.13 Results for the set approach to sts-v w/global constraint

(cont.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1298.14 Run-time for both set approaches to sts-v . . . . . . . . . . . . . . 1308.15 Nb. of iterations for both set approaches to sts-v . . . . . . . . . 131

8.16 Iterations per second for both set approaches to sts-v . . . . . 1318.17 GC-memory for both set approaches to sts-v . . . . . . . . . . . 1328.18 VM-memory for both set approaches to sts-v . . . . . . . . . . . 1328.19 Run-time for sts-v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1338.20 Nb. of iterations for sts-v . . . . . . . . . . . . . . . . . . . . . . . . . . 1338.21 Iterations per second for sts-v . . . . . . . . . . . . . . . . . . . . . . . 1348.22 GC-memory for sts-v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1348.23 VM-memory for sts-v . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1358.24 Run-time for sts-v with a global constraint . . . . . . . . . . . . . 1368.25 Nb. of iterations for sts-v with a global constraint . . . . . . . . 1368.26 Iterations per second for sts-v with a global constraint . . . . 1378.27 GC-memory for sts-v with a global constraint . . . . . . . . . . 1378.28 VM-memory for sts-v with a global constraint . . . . . . . . . . 138

9.1 Results for the integer approach to schur-k-n . . . . . . . . . . 1499.2 Results for the integer approach to schur-k-n (cont.) . . . . . 1499.3 Results for the set approach to schur-k-n . . . . . . . . . . . . . 1509.4 Results for the set approach to schur-k-n (cont.) . . . . . . . . 1509.5 Run-time for both approaches to schur-k-n . . . . . . . . . . . . 1509.6 Nb. of iterations for both approaches to schur-k-n . . . . . . . 1509.7 Iterations per second for both approaches to schur-k-n . . . 1519.8 GC-memory for both approaches to schur-k-n . . . . . . . . . 1519.9 VM-memory for both approaches to schur-k-n . . . . . . . . . 1529.10 Nb. of restarts for both approaches to schur-k-n . . . . . . . . 152

10.1 Actors and their daily fees for the Scene Allocation problem . 15510.2 Scenes for the Scene Allocation problem . . . . . . . . . . . . . . . . 15610.3 Results for the integer approach to the Scene Allocation problem16510.4 Results for the integer approach to the Scene Allocation prob-

lem (cont.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16610.5 Results for the set approach to the Scene Allocation problem . 16610.6 Results for the set approach to the S. Allocation problem (cont.)16610.7 Run-time for both approaches to the Scene Allocation problem 16710.8 Nb. of iterations for both approaches to the Scene Allocation . 16710.9 Rate of iterations for both approaches to the Scene Allocation

problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16710.10GC-memory for both approaches to the S. Allocation problem 16710.11VM-memory for both approaches to the S. Allocation problem 16710.12Nb. of restarts for both approaches to the S. Allocation problem 167

11.1 Results for the set approach to find BIBDs (part 1) . . . . . . . . . 17511.2 Results for the set approach to find BIBDs (part 1, cont.) . . . . 17511.3 Results for the set approach to find BIBDs (part 2) . . . . . . . . . 17611.4 Results for the set approach to find BIBDs (part 2, cont.) . . . . 176

Listings

5.1 var{int} class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.2 var{set{int}} class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.3 Invariant<LS> interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.4 Constraint<LS> interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.1 SetConstraint<LS> interface . . . . . . . . . . . . . . . . . . . . . . . . 726.2 UserSetConstraint<LS> interface . . . . . . . . . . . . . . . . . . . . . 736.3 PairAtMost1<LS> set constraint . . . . . . . . . . . . . . . . . . . . . . . 756.4 SetConstraintSystem<LS> class . . . . . . . . . . . . . . . . . . . . . . 796.5 Kirkman’s Schoolgirl Problem . . . . . . . . . . . . . . . . . . . . . . . . 8310.1 Function<LS> interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15710.2 SetObjectiveFunction<LS> interface . . . . . . . . . . . . . . . . . . 15815.1 CBLS integer approach to the Social Golfer Problem . . . . . . . 19315.2 User-defined SocialTournament constraint . . . . . . . . . . . . . . 19515.3 User-defined invariant Meet . . . . . . . . . . . . . . . . . . . . . . . . . . 19715.4 CBLS greedy integer approach to the Social Golfer Problem . 19815.5 CBLS set approach to the Social Golfer Problem . . . . . . . . . . 20115.6 User-defined GlobalAtMost1<LS> constraint . . . . . . . . . . . . . 20315.7 User-defined invariant MeetSet . . . . . . . . . . . . . . . . . . . . . . . 20515.8 CBLS greedy set approach to the Social Golfer Problem . . . . 20815.9 CBLS integer approach to find a Steiner triple system . . . . . . 21115.10User-defined PairDifferent constraint . . . . . . . . . . . . . . . . . 21415.11A better CBLS integer approach to find a Steiner triple system 21515.12User-defined GlobalPairDifferent constraint . . . . . . . . . . . 21815.13User-defined invariant MeetPair . . . . . . . . . . . . . . . . . . . . . . 21915.14CBLS set approach to find a Steiner triple system . . . . . . . . . . 22115.15A better CBLS set approach to find a Steiner triple system . . . 22415.16CBLS integer approach to Schur’s lemma . . . . . . . . . . . . . . . . 22715.17CBLS set approach to Schur’s lemma . . . . . . . . . . . . . . . . . . . 22915.18User-defined SetSumFree<LS> constraint . . . . . . . . . . . . . . . . 23215.19User-defined invariant SetSumSet . . . . . . . . . . . . . . . . . . . . . 23315.20UserSetObjectiveFunction<LS> abstract class . . . . . . . . . . . 23915.21CBLS integer approach to the Scene Allocation problem . . . . 24015.22CBLS set approach to the Scene Allocation problem . . . . . . . 24215.23User-defined SceneAllocationObjective<LS> set objective

function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24415.24User-defined ActorsSet invariant . . . . . . . . . . . . . . . . . . . . . 246

15.25CBLS set approach to design BIBDs . . . . . . . . . . . . . . . . . . . 24915.26User-defined BIBDObjective<LS> set objective function . . . . 25015.27User-defined SetObjects invariant . . . . . . . . . . . . . . . . . . . . . 253

Part I:

Constraint Based Local Search (CBLS)

1. Constraint Modeling

Constraint Programming and Constraint-Based Local Search have emerged asnovel sets of techniques and tools for modeling and efficiently solving (hard)combinatorial problems. Many of these problems are not merely academic asthey can be found in very diverse settings: they do arise in many applicationdomains (e.g., artificial intelligence, databases, combinatorial optimization,etc.) and are ubiquitous in our society (e.g., scheduling, timetabling, resourceallocation, etc.). These kind of problems, which can be modeled in terms ofconstraints, are called constraint problems and solving them requires that allof their constraints are satisfied and, optionally, some cost (or benefit) is min-imized (or maximized).

Intuitively, a constraint is the encapsulation of a widely applicable inter-esting subproblem (hence constraints usually compose constraint problemsnaturally capturing their essence compactly). Choosing the right constraintswhen modeling a constraint problem is a very important task as there is morethan one possible model for the same problem. Modeling is a flexible process,where constraints can be added, removed, or modified.

The concept of constraint is older than those of Constraint Programmingand Constraint-based Local Search. Informally, a constraint is a sequence ofvariables together with the allowed combinations of values for that sequence.Both Constraint Programming and Constraint-based Local Search are tech-niques aimed to compute solutions to constraint problems by reasoning on theconstraints the problem is defined on, the variables the constraints are definedon, and the domains of these variables.

It is possible to classify variables according to the type of values takenby their domains: variables ranging over finite domains are scalar variables(e.g., variables ranging over {0, 1} are scalar boolean variables) and variablesranging over (finite) set values are set variables. Likewise, constraints can beclassified according to the type of variables they are defined on: constraintsdefined on integer variables are integer constraints and constraints defined onset variables are set constraints.

Another important classifications of constraints, as discussed later, is thedistinction between non-global and global constraints. Informally, a globalconstraint is one defined on a non-fixed number of variables. Most of the suc-cess of Constraint Programming is due to the discovery of global constraintsand they have proved their efficiency in Constraint-based Local Search too.

3

Some constraints can be further classified as implicit, implied or even re-dundant. A constraint is said to be implicit when it can never be violated,is said to be implied (or derived) when it logically follows from other con-straints and is said to be redundant when it can be dismissed without negativeconsequences.

Constraint modeling is still more an Art than a Science and in this spiritother kind of constraints exist as well (e.g channeling and higher-order con-straints).

1.1 Integer and Set variablesThere are several approaches to solving combinatorial problems handling vari-ables whose domains are simply sets of scalars, such as finite integer domains(i.e., integer variables) or finite enumerations. Following the concept of finiteinteger domains, the notion of set domain has been introduced. set variablesare not new in this sense, they have already been proposed (e.g., [12]) as ahigher-level modeling device and even implemented in some programminglanguages with features aimed to solve constraint problems. Later anotherkind of higher-order variables have been proposed too (e.g., tree and graphvariables in [7]).

Constraint Programming was the first, and possibly only, approach to solv-ing combinatorial problems handling set variables. Set constraints for Con-straint Programming have been both designed and successfully implemented.For instance, set variables are supported in the constraint programming mod-ule of Comet1 together with several set constraints; similarly, set variablesand set constraints are available in the GECODE2 software library for Con-straint Programming.

Constraint-based Local Search has now been also introduced to the set ap-proach (e.g., [3]). The main theoretical study on the subject was made in [2]and set constraints have not been used for local search in a full scale program-ming environment yet. For example, at this moment Comet does not supportconstraints on set variables for local search; nevertheless, it does provide sup-port for invariants over set variables which are of great help to handcraft setconstraints.

Set variables take as value a subset, rather than an element, from its do-main. The elements of a set domain are thus known sets and the set domainitself represents a powerset. This dispenses with the low-level modeling idiomof having a boolean decision variable for each element of the domain (indi-cating whether or not it is in the set), or having a list (of length m where the

1free of charge for academic purposes at http://dynadec.com/2free and open source under a permissive licence, available at http://www.gecode.org/

4

http://dynadec.com/

http://www.gecode.org/

cardinality of the set is known to be m) of integer variables taking their valuesfrom a finite set of integers (of cardinality n where m ≤ n).

Set variables thus range over set domains. A set domain could be defined asa fixed collection of known sets of arbitrary elements, but for practical reasonsthey are better represented by a set interval [a, b] specified by its upper andlower bounds, b and a respectively (a ⊆ b), guaranteeing that a partial order(by set inclusion) exists. More formally, given a set s such that s ∈ [a, b], itspossible elements are those contained in the least upper bound b which are notin a and its definite elements are only those contained a. A set variable s issaid to range over a set domain [a, b] if and only if s ∈ [a, b].

This is illustrated in the way Comet currently represents set variables [1]:a pair of integer sets (R,P ) together with an integer variable c. R and Prepresent, respectively, the set of required elements and the set of possibleelements of the set variable, and c its cardinality. Hence for a set variable S,its domain is the set of sets defined by D(S) = {s | R ⊆ s ⊆ P ∧ |s| = c}.Note that, if U denotes the set of all possible elements (so called “universe”)and E the set of elements excluded by the set variable, then P = U \ E.

1.2 Constraints and set constraintsThe only big difference between constraints and set constraints is that whilethe former are defined on scalar (integer) variables, the latter are defined onset variables. The precise definition of a constraint is straightforward. Fromnow on definitions are given formally.

Definition (Constraint). Let X be a finite sequence of variables 〈x1, . . . , xm〉where m > 0, with respective domains 〈D1, . . . , Dm〉 associated with them(so each variable xi ranges over the domain Di). A constraint c on X is thena set of allowed combinations of values for 〈x1, . . . , xm〉 which means c ⊆D1×· · ·×Dm. The sequence 〈x1, . . . , xm〉 over which c is defined is referredto by vars(c), and a sequence of values 〈v1, . . . , vm〉 is said to satisfy theconstraint c if and only if 〈v1, . . . , vm〉 ∈ c. By default, 〈x1, . . . , xm〉 arescalar variables.

The previous definition is based on the one given in [4]. Examples of con-straints are:

• pairDifferent(X,Y ), which is satisfied if and only if the pair of integervariables X and Y take different values.

• relation(X,∼r, Y ), which is satisfied if and only if X ∼r Y holds for thevalues assigned to the pair of integer variables X and Y , where ∼r is abinary relation on Z. Clearly, this constraint is the same as pairDifferentwhen ∼r is 6=.

5

Definition (Set constraint). A constraint c is a set constraint if and only ifvars(c) is a sequence of set variables.

Examples of set constraints are:

• Partition(X), which is satisfied if and only if all set variables in X aredisjoint and their union equals a given set U .

• |S| ≤ s (respectively |S| = s and |S| ≥ s), i.e., cardinality constraint,which is satisfied if and only if the size of the set variable S is at most agiven value s (respectively exactly s and at least s).

• PairAtMost1 (X,Y ), which is satisfied if and only if the pair of set vari-ables X and Y have at most one common element.

Next, two important types of constraints are distinguished: global constraintsand implicit constraints.

1.2.1 Global ConstraintsGlobal constraint is the name given to describe constraints with a variable(i.e., non-fixed) number of variables. These capture common combinatorialstructures and have been around for a long time (witness the Global ConstraintCatalogue).3

Definition (Global constraint). A global constraint is a constraint c with itsnumber of variables specified as a parameter. A global constraint is hencedenoted by c(n) where n = |vars(c)|.

A typical example of a global constraint is the allDifferent(n) constraint:

• allDifferent(n)(X1, . . . , Xn) is satisfied if and only if every pair of integervariables Xi and Yj take different values for i 6= j (i, j ∈ [1, n]).

When modeling, global constraints typically can alternatively be expressedas the conjunction of several non-global constraints. However, global con-straints play an important role when finding solutions to problems becausethey provide a better view of the structure of the problem and make the pro-cess far more efficient. Consequently, modeling by means of global constraintsis highly desirable.

Consider, for instance, an attempt to find solutions to a constraint problemby means of narrowing the domains of the variables (reasoning on them usingthe available constraints) until all constraints are satisfied or until finding thatno solution exists. Given three integer variables X,Y and Z with respectivedomains {1, 2} , {1, 2} , {1, 2, 3}; with three constraints pairDifferent(X,Y ),pairDifferent(Y,Z) and pairDifferent(X,Z), it is not possible to infer any-thing about the solution (so it is necessary to immediately resort to search).

3available at http://www.emn.fr/z-info/sdemasse/gccat/

6

http://www.emn.fr/z-info/sdemasse/gccat/

Conversely, given the same three variables with the same domains and the onesingle allDifferent(3 )(X,Y, Z) global constraint, it is possible to infer that asolution exists and Z = 3.

1.2.2 Implicit ConstraintsAfter modeling a constraint problem, could be that some of its constraintsare already satisfied and furthermore never violated during the computationof a solution. These constraints are called implicit for the constraint problem.This can happen for several reasons, for example due to the way variables arechosen when modeling the solution or due to the way the search procedureinteract with the variables and its domains when trying to find a solution.

Consider, for example, the probably most known constraint problem: then-queens problem.

Place n queens on a n × n board, with n ≥ 3, so that no twoqueens attack each other following chess rules.

The appropriate constraints for this problem are:

• no two queens lie on the same column,

• no two queens lie on the same row,

• no two queens lie on the same north-west to south-east diagonal, and

• no two queens lie on the same north-east to south-west diagonal.

One possible representation of this constraint problem [4] uses n integer vari-ables, X1, . . . , Xn, each with the domain [1, n]. The idea is that Xi denotesthe position, i.e., the row, of the queen placed in the ith column of the board.The constraints can then be formulated as:

• allDifferent(n)(X1, . . . , Xn),

• allDifferent(n)(∀i ∈ [1, n] : Xi − i),4 and

• allDifferent(n)(∀i ∈ [1, n] : Xi + i).

In this representation, the constraint that no two queens lie on the same col-umn is implicit (and hence not present in the previous list of constraints). Sincewe have n queens and n rows, and no two queens can lie on the same column,each column must contain exactly one queen. As a consequence one variablewas created for each column, the values taken by these variables represent therow of the column’s queen, and therefore there is no need for explicitly ensur-ing that queens do not attack each other vertically. An implicit constraint willnever be violated and is hard in this sense.

Note that all previous allDifferent(n) constraints could also be expressed asthe conjunction of several non-global pairDifferent constraints. For instance,

4∀i ∈ [1, n] : (Xi− i) denotes a sequence of variables Yi such that Yi = Xi− i and i ∈ [1, n].

7

the constraint ensuring that no two queens attack each other horizontally couldbe expressed with a conjunction of n·(n−1)

2 pairDifferent constraints. Namely,a conjunction of pairDifferent(Xi, Xj) constraints for all i ∈ [1, n − 1] andj ∈ [i+1, n]. Anyway, the use of global constraints is strongly recommended.

1.3 Constraint Satisfaction Problems (CSP) and Set-CSPA combinatorial problem formally modeled as a constraint problem is calledconstraint satisfaction problem (CSP). The concept of CSP is not new sinceaccording to [4] it was also formulated in the seventies by researches in theartificial intelligence (AI). Informally, a constraint satisfaction problem is aspecification of combinatorial problem which defines its variables, values andconstraints. From now on all problems are modeled as CSPs.

Definition (CSP). A constraint satisfaction problem (CSP) is a three-tuple〈V,D,C〉 where

• V is a finite set of variables,

• D is the set of possible values for the variables in V , i.e., its domain;and

• C is a finite set of constraints.

Each constraint c in C is defined such that each variable in vars(c) is alsoin V . All variables in V share the same domain D which in turn is a subset ofa finite set of scalar values U (sometimes called the “universe”).

Note it is always possible to specify smaller domains for particular vari-ables with additional membership constraints so there is no loss of generalityrequiring all variables share the same domain. Likewise, the set U itself couldcontain set values but only scalar values are considered here.

As an example, the CSP for the n-queens problem presented in the pre-vious section follows.

• V = {Queen1 , . . . ,Queenn}• D = {1, . . . , n}• C =

{allDifferent(n)(Queen1 , . . . ,Queenn),

allDifferent(n)(Queen1 − 1, . . . ,Queenn − n),

allDifferent(n)(Queen1 + 1, . . . ,Queenn + n)}

Following the definition of CSPs, set constraint satisfaction problems caneasily be introduced.

Definition (set-CSP). A Set constraint satisfaction problem (set-CSP) is aCSP 〈V,D,C〉 where D is the power set of values P(U).

8

As an example of a set-CSP, consider the Social Golfer Problem:5

Schedule g · s golfers into g groups of s players over w weekssuch that no two golfers plays in the same group more than once.

Let us take natural numbers to represent golfers (U ⊂ N) and let the setsW and G represent the ranges of weeks and groups respectively. Golfers aremeant to play in |G| groups of size s. The set-CSP model is given by:

• V ={S(w,g) | w ∈W ∧ g ∈ G

},

• D = P(U); and

• C =⋃w∈W

{Partition

({S(w,g) | g ∈ G

})}∪⋃w∈Wg∈G

{∣∣S(w,g)

∣∣ = s}

∪⋃

w1,w2∈Wg1,g2∈G

{PairAtMost1

(S(w1,g1), S(w2,g2)

)| w1 < w2

}where a set variable S(w,g) denotes the group of golfers playing together asgroup g during week w. The partition constraints ensure all golfers play inexactly one group in each week, the cardinality constraints ensure all groupsare of size s and the PairAtMost1 constraints ensure no two golfers meet inthe same group more than once.

It is now necessary to define the crucial notion of a solution to a (set-)CSPand differentiate it from the notion of configuration. Be aware that sometimes“CSP” is used to denote either CSP or set-CSP. Intuitively, a solution to aCSP is a legal sequence of values for all of its variables such that all of itsconstraints are satisfied. A more precise definition follows.

Definition (Configuration and solution). Let C = 〈V,D,C〉 be a CSP.

• A configuration is a function k : V → D.

• The set of all configurations for C is denoted KC .

• A configuration k is a solution to a constraint c ∈ C (or k satisfies c,or c is satisfied under k) if and only if 〈x1, ..., xm〉 = vars(c) implies〈k(x1), ..., k(xm)〉 is one of the allowed combinations of values, for thatsequence, specified by c (i.e., 〈k(x1), ..., k(xm)〉 ∈ c).

• A configuration k is a solution to C if and only if k is a solution to allconstraints in C.

• The set of all solutions for C is denoted SC and defined asSC = {k ∈ KC | ∀c ∈ C : 〈x1, ..., xm〉 = vars(c)→

〈k(x1), ..., k(xm)〉 ∈ c}

5problem 10 at http://www.csplib.org/

9

http://www.csplib.org/

Figure 1.1: A solution configuration (left) and a non-solution configuration (right) tothe 4-queens problem.

Should be clear now that a configuration is an assignment of values to allvariables in V , and that a configuration is a solution when each variable se-quence of c for all c in C under that configuration takes an allowed combina-tion of values specified by c. For example, a solution to golf-3-3-4 is:

Week1 = {Group1 = {1, 2, 3} ,Group2 = {4, 5, 6} ,Group3 = {7, 8, 9}}Week2 = {Group1 = {1, 4, 7} ,Group2 = {2, 5, 8} ,Group3 = {3, 6, 9}}Week3 = {Group1 = {1, 6, 8} ,Group2 = {2, 4, 9} ,Group3 = {3, 5, 7}}Week4 = {Group1 = {1, 5, 9} ,Group2 = {2, 6, 7} ,Group3 = {3, 4, 8}}

whereas a (non-solution) configuration to golf-3-3-4 is:

Week1 = {Group1 = {8, 4, 5} ,Group2 = {6, 3, 7} ,Group3 = {1, 2, 9}}Week2 = {Group1 = {2, 6, 3} ,Group2 = {4, 9, 1} ,Group3 = {5, 8, 7}}Week3 = {Group1 = {2, 1, 5} ,Group2 = {4, 3, 7} ,Group3 = {6, 9, 8}}Week4 = {Group1 = {1, 2, 7} ,Group2 = {9, 4, 8} ,Group3 = {6, 3, 5}}

In both of the previous configurations, each set variable S(w,g) maps to the setGroupg ∈ Weekw (obviously neither solutions nor configurations need to beunique).

Similarly, a solution and a (non-solution) configuration to 4-queens aredepicted in Figure 1.1. They correspond to:

{Queen1 7→ 3,Queen2 7→ 1,Queen3 7→ 4,Queen4 7→ 2} ; and{Queen1 7→ 2,Queen2 7→ 3,Queen3 7→ 1,Queen4 7→ 4} respectively.

All definitions on this section are based on those given in [2]. CSPs (and set-CSPs) are a modeling tool for combinatorial problems (which can also be seenas declarative specifications since they implicitly define a set of solutions).Constraint Programming and Constraint-based Local Search are two differenttechniques for finding solutions to CSPs. These two techniques are discussedseparately in the following two chapters.

10

2. Constraint Programming (CP)

When problems are modeled as CSPs, several methods or techniques exist tosolve them. These methods aim to find a solution (or all solutions, if more thanone solution exists for the problems’ chosen representations) or alternativelyan optimal solution (or all optimal solutions) such that some cost (or benefit)is minimized (or maximized). Constraint programming (CP) is one of suchtechniques. This chapter is included because even though the concept of con-straint stands on its own, it is very tight bound to CP. Constraint-based LocalSearch is said to be the integration of CP and Local Search [2].

CP is a general method to solve CSPs (general methods are concerned withthe ways of reducing the search space and with specific search methods). Moreprecisely, CP is a complete search technique for CSPs which means that thewhole search space is explored. A naïve version of such complete search tech-nique would enumerating all possible configurations of the CSP in question.However, as the search space can be as huge as one can imagine (or evenmore), this is clearly not practical. The beauty of constraint programming liesin the ability (in most cases) to avoid enumerating each possible configuration[2] by means of constraint propagation.

The algorithms that deal with the search space reduction are usually calledconstraint propagation algorithms [4]; and the common theme of such propa-gation algorithms is to exploit necessary conditions of constraints and to rec-ognize values that, if taken, would violate some necessary condition [2]. Theonly purpose of a constraint propagation algorithm is then to simplify theproblem being solved to another yet equivalent one.

A key notion for a constraint propagation algorithms is the one of consis-tency. Constraint propagation algorithms narrow the domains of variables ac-cording to some level of consistency. Recall the classical problem given as anexample in Section 1.2.1: three variablesX , Y andZ with respective domains,{1, 2}, {1, 2}, and {1, 2, 3}, were given together with the three pairDifferentconstraints: X 6= Y , Y 6= Z, and X 6= Z. If either Z = 1 or Z = 2, thenit would be impossible to assign distinct values to X and Y and hence no so-lution would exist. This means that the domain of Z can be narrowed to {3}.Anyway, considering the three X 6= Y , Y 6= Z, and X 6= Z constraints, itwas not possible to infer this; conversely, the deduction was possible using theone single allDifferent(3 )(X,Y, Z) global constraint instead. Thus the levelof consistency of allDifferent(3 ) can be higher than the level of consistencywhen using the three pairDifferent constraints.

11

Figure 2.1: Constraint programming approach to find a solution for the 4-queensproblem using forward checking and backtrack search.

The search methods used by constraint programming combine several formsof constraint propagation with the customary backtrack and branch and boundsearchs [4]. To get a feeling of how CP operates, consider an attempt to find asolution for the n-queens problem (presented in section 1.2.2) with n = 4,using a forward checking propagation algorithm for the allDifferent(3 ) con-straint together with backtracking search. This example and the definition offorward consistency was taken from [10].

Informally, forward checking consistency for a constraint c is achievedwhen whenever a value is tried for some variable, any conflicting values ac-cording to c are removed from the domains of the remaining variables. Con-sider, for instance, allDifferent(3 )(X,Y, Z) with X ∈ {1, 2}, Y ∈ {1, 2, 3}and Z ∈ {2, 3}; if the decision X = 2 is tried, then forward checking con-sistency gives X ∈ {2}, Y ∈ {1, 3} and Z ∈ {3}. The search for a solutionto 4-queens using forward checking and backtrack search is depicted inFigure 2.1 (which is meant to be self explanatory).

12

2.1 Constraints for CPWhen solving combinatorial problems with CP, constraints are implementedas propagators. A propagator is a function that performs constraint propa-gation [22]. Propagators compute with sets of possible values for variables.Hence it is necessary to introduce the notion of constraint stores, which infor-mally are functions mapping variables to sets of values. The following defini-tion also highlights the connection between stores and configurations.

Definition (Constraint store and its link with configurations). Let C be theCSP given by 〈V,D,C〉.

• A constraint store is a function s : V → P(D).

• A configuration k : V → D is contained in a store s : V → P(D),denoted k ∈ s, if and only if for each variable x in V : k(x) ∈ s(x).

• The set of all constraint stores for C is denoted TC .

From now on, when introducing a new concept, in order to avoid beingverbose, instead of explicitly naming a CSP (“let C = 〈V,D,C〉 be a CSP”),a CSP C will be assumed to be in the current context. As a result, KC willbe often written as K, TC as T , etc. Similarly, when reasoning about a valuev or a variable x, or a constraint c, or a configuration k, and so on, it will bealways implicit that v ∈ D, x ∈ V , c ∈ C, k ∈ K, and so on. Likewise, takefrom now on store as a short name for constraint store.

Propagators narrow the domains of variables by removing impossible val-ues for its variables according to the constraint they implement. Normally, astore will be stronger after performing constraint propagation.

Definition ((Strictly) stronger stores). Let s1 and s2 be two constraint stores.s1 is stronger than s2, denoted s1 � s2 (� ⊂ T × T ), if and only if, for allvariables x, s1(x) ⊆ s2(x). Moreover, s1 is strictly stronger than s2, denoteds1 ≺ s2, when, in addition to be stronger, s1(x) ⊂ s2(x) for at least onevariable x.

Given two stores s1 and s2 such that s1 � s2 (s1 ≺ s2), it is alternativelysaid that s2 is weaker (strictly weaker) than s1. Should be clear that (s1 ≺s2) → (s1 � s2 ∧ s1 6= s2). In the same manner, it is straightforwardto show that � is reflexive, antisymmetric, and transitive. Thus (T,�) is apartial order.

Definition (Configuration stores and store for a configuration).

• A store s is a configuration store when |s(x)| = 1 for all variables x.

• The store for a configuration k is defined as Store(k)(x) = {k(x)}.

Note that, by construction, Store(k) is a configuration store.

13

Proposition. Given a configuration k and a store s: k ∈ s ↔ Store(k) � s.This relation holds due to the previous definitions:

k ∈ s↔ ∀x ∈ V : k(x) ∈ s(x)↔ ∀x ∈ V : {k(x)} ⊆ s(x)↔ ∀x ∈ V : Store(k)(x) ⊆ s(x)↔ Store(k) � s

So far a propagator p has been defined as a function which performs con-straint propagation, which means a propagator is a function from stores tostores (i.e., p : T → T ). As propagators narrow the domains of variables, apropagator p must be contracting, i.e., for all s in T : p(s) � s, which meansthat a propagator never adds values. Indeed, propagators are only allowed toremove values from constraint stores without removing solutions of the con-straints they implement. Thus p

(Store(k)

)= Store(k), given a solution k of a

constraint c.Finally, given any store s (not necessarily a configuration store), if s con-

tains a solution k of a constraint c, then the propagator p implementing c is notallowed to remove k by propagation. Therefore, for a solution k, k ∈ s→ k ∈p(s) should hold. From the previous proposition k ∈ s ↔ Store(k) � s, andk ∈ p(s)↔ Store(k) � p(s). The property of a propagator that will guaranteeStore(k) � s→ Store(k) � p(s) is monotonicity.

Definition (Propagator). A propagator is a function p : T → T which is:

• contracting, i.e., ∀s ∈ T : p(s) � s,

• monotonic, i.e., ∀s1, s2 ∈ T : s1 � s2 → p(s1) � p(s2); and

• solution distinguisher, i.e., if k is a solution to the constraint imple-mented by p, then p

(Store(k)

)= Store(k).

The notion of propagator as implementation of a constraint is formalized now.

Definition (Implementation of a constraint). A propagator, denoted pc, is theimplementation of a constraint c with 〈x1, . . . , xm〉 = vars(c) if and only iffor any configuration k: 〈k(x1), . . . , k(xm)〉 ∈ c↔ pc(Store(k)) = Store(k).

From the above definition, given a configuration k that is not a solutionof c, pc(Store(k)) 6= Store(k) holds. Since pc is contracting, pc(Store(k)) ≺Store(k). This means that there exists a variable x such that pc(Store(k))(x) ⊂Store(k)(x). As Store(k)(x) contains one single element, there is no otherchoice to pc(Store(k))(x) than to be an empty set. Stores mapping a variableto an empty set do not contain any solution at all.

Definition (Failed store). A constraint store s is failed, if there exists a vari-able x such that s(x) = ∅. A propagator pc fails on a store s, if pc(s) is failed.

As an example, consider the propagator p≤ for the relation(X,≤, Y ) con-straint. Given V = {X,Y, Z} and D = [0, 5], p≤ can be defined as follows:

14

Figure 2.2: DFA for an specific instance of the regular constraint

p≤(s)(X) = {n ∈ s(X) | n ≤ max(s(Y ))}p≤(s)(Y ) = {n ∈ s(Y ) | n ≥ min(s(X))}p≤(s)(Z) = s(Z)

Hence, for a constraint store s = {X 7→ {3, 4, 5} , Y 7→ {0, 1, 2, 3} , Z 7→{1, 5}} the propagator p≤ computes s = {X 7→ {n ∈ s(X) | n ≤ 3} , y 7→{n ∈ s(Y ) | n ≥ 3} , Z 7→ s(Z)} = {X 7→ {3} , Y 7→ {3} , Z 7→ {1, 5}}.Note that propagators distinguish between solutions and non-solutions.

Proposition (Implementation of a constraint). Given a propagator pc anda solution configuration k. For all stores s ∈ T : k ∈ s → k ∈ pc(s).As discussed earlier, k ∈ s implies Store(k) � s; since pc is monotonic,pc(Store(k)) � pc(s); pc distinguishes solutions, so Store(k) � pc(s), which,again by the previous proposition, implies k ∈ pc(s).

Note that solution-configuration stores for a constraint c are fix-points of pcwhereas pc fails on non-solution-configuration constraint-stores. The previousexample was taken from [22] and all the definitions on this and the next twosections of this chapter are based on those given in the same source.

Implementing propagators can be a creative and challenging task. Consider,for instance, the regular(n)(x0, . . . , xn−1, r) constraint c which is satisfied ifand only if the string 〈x0, . . . , xn−1〉 = vars(c) forms a word from the lan-guage of the regular expression r. Since regular expressions are implementedas finite automata, the equivalent, regular(n)(x0, . . . , xn−1, d) constraint issatisfied if and only if the string 〈x0, . . . , xn−1〉 is accepted by the DFA d.A configuration k is then a solution of c if and only if there is an acceptingpath s0

v0−→ . . .vn−1−→ sn for

⟨v0 = k(x0), . . . , v(n−1) = k(xn−1)

⟩in d where

s0 is a start state and sn is a final state.Figure 2.3 shows the idea behind the algorithm implementing the propaga-

tor for the regular(4 )(x0, x1, x2, x3, d) constraint where d is the DFA shown inFigure 2.2 and the initial stores are s(x0) = s(x1) = s(x2) = s(x3) = {0, 1}.The previous example on the regular constraint was taken from [21].

The core concept of CP is constraint propagation which relies in propaga-tors. This notion is discussed next.

15

Figure 2.3: Layered graph construction: idea behind the algorithm implementing apropagator for the regular constraint

16

2.2 Constraint PropagationWhile propagators implement constraints, constraint programming modelsimplement CSPs. Here, instead of requiring a one-to-one correspondence be-tween propagators and constraints, constraint programming models featuringseveral propagators implement constraint satisfaction problems featuring sev-eral constraints. CSPs can be seen as specifications for constraint program-ming models.

Definition (Constraint programming model). Given a CSP 〈V,D,C〉, a con-straint programming model is given by the triple 〈V,D, P 〉, where P is a finiteset of propagators implementing the constraints in C.

Definition (Propagator solutions). The set of solutions to a propagator p isreferred to by sols(p) and defined as

{k ∈ K | p

(Store(k)

)= Store(k)

}.

Definition (Constraint programming model solutions). The set of solutionsfor a constraint programming model M is denoted by SM and defined as⋂p∈P

sols(p).

Now the notion of constraint programming models as implementations ofCSPs is formalized.

Definition (Implementation of a CSP by a CP model). A constraint program-ming model M implements a constraint satisfaction problem C , if SM = SC .

Since constraint propagation starts with some initial store sinit , the solu-tions that can be obtained from sinit are those stronger than sinit .

Definition (Constraint programming model solutions for s). The set of so-lutions to a constraint programming model M for a store s is SM (s) ={k ∈ SM | Store(k) � s

}. Clearly, SM (s) ⊆ K.

The next proposition highlights an important fact already known.

Proposition (Propagators preserve solutions). Given a constraint program-ming model M and a store s, for all propagators p in P : SM (s) = SM (p(s))

Finally, constraint propagation is given as a function in Models × T → T ,taking a constraint programming model M and a constraint store s as inputand returning a new store on which constraint propagation has been performed[22]. Given a constraint programming model 〈V,D, P 〉, a basic algorithm forconstraint propagation is shown in Figure 2.4. This basic constraint propaga-tion algorithm has the following properties:

• Constraint propagation always terminates.

• If PROPAGATE(M ,s) = s′, then SM (s) = SM (s′).

17

PROPAGATE(〈V,D, P 〉, s)1 while exists p ∈ P with p(s) 6= s2 s← p(s)3 return s

Figure 2.4: Basic algorithm for constraint propagation.

Figure 2.5: Model for a Sudoku puzzle (left). The initial store for this easy instancehas some variables already assigned (right).

• If PROPAGATE(M ,s) = s′, then s′ is the weakest (largest) simultaneousfix-point of all propagators in P :

• s′ is simultaneous fix-point: p(s′) = s′ for all p in P .

• s′ is the weakest largest simultaneous fix-point stronger than s (s′ �s): any other simultaneous fix-point t of P is stronger than s′ (t � s′).

A proof showing that the previous properties hold can be found in [22]: thetwo main properties are direct consequences of properties of the individualpropagators, and the algorithm terminates because propagators are contract-ing. Clearly, this basic algorithm is naïve and can be further improved andoptimized (see, for instance, [22]); anyway, this task goes beyond the purposeof this chapter. An important consequence of these properties is that propa-gators can be invoked in any order, i.e., the order in which propagators areapplied does not affect the result of constraint propagation.

As an example, consider the well-known Sudoku puzzle which is often pub-lished in newspapers and magazines.

18

Figure 2.6: Solving of the Sudoku puzzle shown in Figure 2.5 by constraint propaga-tion.

Place digits on a 9×9 board composed of 9 adjacent 3×3 blocks,so that each column, row and block contains distinct digits from1 to 9.

The problem can be modeled with a matrix of 9 · 9 integer variables withdomains [1, 9] and 9 + 9 + 9 allDifferent(9 ) constraints. The correspondingCSP is then constituted by:

• V ={M(i,j) | i, j ∈ [1, 9]

}• D = {1, . . . , 9}• C =

{∀i ∈ [1, 9] : allDifferent(9 )

(∀j ∈ [1, 9] : M(i,j)

),

∀j ∈ [1, 9] : allDifferent(9 )

(∀i ∈ [1, 9] : M(i,j)

),

∀b ∈ Blocks : allDifferent(9 )

(∀(i, j) ∈ b : M(i,j)

)}Figure 2.6 illustrates the process of (mechanically) solving an (easy) in-

stance of this problem, shown in Figure 2.5, where some variables of the ma-trix are already assigned in the initial store. As the example shows, sometimesa solution can be found by means of constraint propagation only. However, inmost cases pure constraint propagation is not enough and therefore it is nec-essary to resort to search. For instance, it is said that the hardest published

19

Sudoku puzzles can be solved using CP in a very little time but with a fewbacktracks. Search is discussed in the following section.

2.3 Constructive Systematic SearchWhen constraint propagation is not enough to solve a problem by its own,CP resorts to search. Search in CP is by no means constraint propagationfree though, as constraint propagation is performed after each search step.Once determined pure constraint propagation can not find a solution, progresstowards the solution can be made by splitting the problem into smaller orsimpler subproblems. Constraint propagation is performed then again on thesesubproblems. The general pattern, therefore, consists of an alternating use ofconstraint propagation and splitting [4].

Typically a search algorithm requires both a search tree and an explorationalgorithm. Here branchers are in charge of defining the search tree whileexploration algorithms incrementally constructs the search tree until a firstsolved node has been found (alternatively until all solved nodes have beenfound or the best solved node has been found). Exploration algorithms do notalways make all the right decisions (leading immediately to solutions), theysometimes make bad choices from where it is necessary to learn and redo.

2.3.1 Search TreeThe shape of the search tree is defined by branchers which are studied inthe context of constraint programming models where splitting is defined interms of propagators instead of constraints. The purpose of a branching is tosuggest new constraints to split the problem by making an informed decisionaccording to some heuristic. Usually, a heuristic will require the branching hasaccess to at least the store (e.g., to determine which is the variable with thesmallest current domain) and the propagator set (e.g., to find the variable onwhich the largest number of propagators depend).

For instance, a possible brancher with a simple heuristic would select froma problem both a variable X with a non-singleton domain and a value n fromsuch domain, and then suggest the constraint X = n to split the problem intwo: one obtained by adding pX=n and the other by adding pX 6=n. This naïvestrategy is typical improved to the so called first-fail heuristic, which consistson selecting the variable with the smallest domain.

A branching must be well behaved [22]:

• the search tree should remain finite,

• no solutions should be lost during search, and

• solutions should not be duplicated (desirable).

20

Definition (Branching). Consider a constraint programming model M =〈V,D, P 〉 together with its set of all stores TM .

A branching b for M is a function mapping set of propagators Q ⊂ TM →TM and a store s ∈ TM to a n-tuple 〈Q1, . . . , Qn〉 of sets of propagatorsQi ⊆ TM → TM . The set of propagators Qi is called the ith alternative.

Asume now that A = S〈V,D,Q〉(s) and Ai = S〈V,D,Q ∪ Qi〉(s) for 1 ≤ i ≤n. Then a branching b must be:

• complete, i.e.,⋃

1≤i≤nAi = A,

• non-overlapping, i.e., Ai ∩Aj = ∅ for 1 ≤ i, j ≤ n with i 6= j, and

• decreasing, i.e., PROPAGATE(〈V,D,Q ∪ Qi〉 , s) ≺ s.

Given a branching b, completeness guarantees that no solutions are lost; theoverlapping property guarantees no solution appears twice in the search treeconstructed for a branching; and the decreasing property ensures the suggestedpropagators will trigger further constraint propagation. Hence the search treewill be finite [22]. These properties yield well-behaved search trees. The def-inition of search tree follows.

Definition (Search tree). A search tree for a model 〈V,D, P 〉 and a branchingb is a tree with the nodes labeled with pairs 〈Q, s〉 where Q is a set of prop-agators and s the result of performing constraint propagation with respect toQ. Hence,

• the root of the tree is labeled with 〈P, s〉, where s is obtained performingPROPAGATE(〈V,D, P 〉 , sinit );

• for all leaves 〈Q, s〉, either

– s is failed, and therefore the leaf itself is called failed or

– b(Q, s) = 〈〉, and therefore the leaf is calles solved; finally

• for any inner node 〈Q, s〉, b(Q, s) = 〈Q1, . . . , Qn〉 with n ≥ 1 and thestore s is not failed. Therefore the inner node has n children where theith node is labeled 〈Q ∪ Qi, PROPAGATE(〈V,D,Q ∪ Qi〉 , s)〉 with(1 ≤ i ≤ n).

By construction, for a node 〈Q, s〉 in the search tree, s is a simultaneousfix-point of Q. Also, due to the decreasing property of branchings, given twonodes 〈Q1, s1〉 and 〈Q2, s2〉: if the former is in the same path but below thelatter then s1 ≺ s2.

Notice the difference between a solved node and a solution of a problem.As a solution of a problem we consider a leaf node where the store is anassignment store. This means that for a branching resulting in solved nodes

21

Figure 2.7: Search tree example, only stores for non-failed stores are shown.

which feature assignment stores, the branching needs to assign all variables(or there must be the guarantee that those variables not directly assigned by abranching are assigned by constraint propagation) [22].

Exploration is discussed next. While the shape of the search tree is definedby branching, exploration defines the strategy of how to explore parts of thesearch tree. Anyway, during exploration the tree’s shape can also be modi-fied (for example, during branch-and-bound best solution search by addingpropagators).

2.3.2 ExplorationExploration is the process of constructing the search tree until: the first so-lution is found, a certain number of solutions are found, all solutions arefound or even until the best solution is found (with respect to some qualitymeasure). Typical strategies are depth-first and branch-and-bound exploration.Consider, for instance, the CSP (which features arithmetic constraints) givenby V = {X,Y }, D = {1, . . . , 6}, and C = {X + Y = Z,X · Y = Z}.

Figure 2.7 shows the search tree for this problem where the naïve branchingpresented in Section 2.3.1 is used. In the search trees shown in this section, a◦ (circle) represents a node with a non-singleton domain, a � (square) repre-sents a failed leaf and a � (diamond) a solved leaf.

Many times, the interest is only in finding the first solution. For simplicity,restrict the attention to the case where branching either returns the empty tuple〈〉 or a pair 〈Q1, Q2〉 (instead of an n-tuple). Figure 2.8 shows an algorithmfor depth-first exploration [22] which for a set of propagators P and a store sreturns a possible failed store.

When trying to find the best solution with respect to some quality measure,the naïve approach of computing all solutions and then select the one mini-mizing some cost (or maximizing some benefit) becomes infeasible because itis well known that, in combinatorial (hard) problems, the number of solutions

22

DFE(〈V,D, P 〉, s)1 s′ ← PROPAGATE(〈V,D, P 〉, s)2 if s′ failed3 return s′4 else case b(P, s′)5 of 〈〉6 return s′7 of 〈P1, P2〉8 s′′ ← DFE(〈V,D, P ∪ P1〉, s′)9 if s′′ failed

10 return DFE(〈V,D, P ∪ P2〉, s′)11 else return s′′

Figure 2.8: Algorithm for Depth-first Exploration

grows exponentially with respect to the problem size (and even in the case thenumber of solutions remains manageable, one can do it better [20]).

Branch-and-bound is a strategy used for solving such optimization prob-lems, the search is performed in a modified version of the depth-first explo-ration strategy. The idea is to employ information from an already computedsolution to narrow the search space. This information is expressed in termsof constraints: whenever a solution has been found, an additional constraintallowing only better solutions is added to the model. With this additional con-straint, the search tree can become considerable smaller.

Consider, for instance, the CSP problem given by V = 〈X,Y, Z〉, D ={1, 2, 3} and C = {X ≥ Z, Y ≥ Z}. The goal is to find a solution with thelargest possible value for Z. Again, using the naïve branching presented inSection 2.3.1, Figure 2.9 shows the search tree for the best solution of thisproblem. First, the first solution is found using left-most depth-first strategy.The value of Z for this first solution is 1, therefore a new constraint Z >1 is injected. After the injection, node 5 fails because X ≥ Z propagatesZ = 1, and node 3 propagates Z = 2. Later, splitting node 3, two new nodesare created: node 6 and 7. Node 6 is a new and better solution with Z = 2,therefore the constraint Z > 2 is injected to Node 7 which leads to a failure.Finally, the best solution is X = 2, Y = 3 and Z = 2.

Notice that with this approach the search tree is not only determined bybranching, the search tree for best-solution is also determined by the orderin which the nodes of the search tree are explored. The last two exampleshave been taken from [20]. Another classical example to illustrate searchstrategies is the so called cryptarithmetic Send More Money problem whichasks to replace each letter by a different digit such that the sum SEND +

23

Figure 2.9: Search tree example for left-most branch-and-bound-search. First, untilthe first solved node (and hence solution) is found (up), and then until the best solutionis found (down).

MORE = MONEY is correct [4] (leading zeros are not allowed). An op-timization version of this problem asks to find such numbers for SEND +MOST = MONEY such that MONEY (i.e., 104 ·M + 103 ·O+ 100 ·N +10 ·E+Y ) is the largest possible value. Implementations of solutions to theseproblems can be found, for example, with the distribution of GECODE.

Figure 2.10 shows an algorithm for branch-and-bound search which aimsto return the best solution (and store it in k∗, if a solution exists). The maindifference with the previous algorithm (Figure 2.8) is that, here, if the firstalternative returns a better solution, then the search on the second alternativeis constrained to yield an even better solution.

CP then solves problems by (implicitly) exploring the (whole) search spaceof a CSP in some systematic way (backtracking when necessary), giving riseto a search tree where constraint propagation is performed at every node.Constraint-based Local Search, another technique discussed in the next chap-ter, sacrifices for speed the guaranteed optimality of solutions found by sys-tematic search.

Symmetries in problems modeled as CSPs have been an active field of re-search. This issue is briefly discussed in the next section.

24

BABE(〈V,D, P 〉, s, k∗)1 s′ ← PROPAGATE(〈V,D, P 〉, s)2 if s′ failed3 return 〈s′,FAIL〉4 else case b(P, s′)5 of 〈〉6 k ← SOLUTION(V)7 k∗ ← is k better than k∗ ? k : k∗

8 return 〈s′, k∗〉9 of 〈P1, P2〉

10 〈s′′, k∗∗〉 ← BABE(〈V,D, P ∪ P1〉, s′, k∗)11 if k∗∗ is FAIL12 return BABE(〈V,D, P ∪ P2〉, s′, k∗)13 else14 return BABE(〈V,D, P ∪ P2 ∪ {pk∗∗}〉, s′′, k∗∗)

Figure 2.10: Algorithm for branch-and-bound exploration

2.4 Symmetry BreakingSymmetries appear in several CSPs in many different forms. For instance,there are rotation symmetries (e.g., the 90◦ rotations of the chessboard in then-queens problem), reflection symmetries (e.g., the reflection of the chess-board along one of its diagonals), and permutation symmetries (e.g., the in-terchange of equally skilled personnel in nurse rostering) [9]. Indeed, the twosolutions to the 4-queens problem (see Section 1.3) are symmetric to eachother (see Figure 2.11). Problems may have many symmetries at once, forinstance, the Magic Hexagon problem:1

1Problem number 23 at http://www.csplib.org/

Figure 2.11: The two solutions for 4-queens are symmetric (left). The solution for theMagic Hexagon is unique (right).

25


Arrange the numbers 1 to 19 in a diameter-5 hexagonal patternsuch that all diagonals add up to the same sum (i.e., add up to38).

has a unique solution disregarding rotations and reflections. Another prob-lem with a high degree of symmetry, which has become one of the standardbenchmarks for evaluating symmetry-breaking schemes, is the Social GolferProblem (golf-g-s-w) modeled as a three dimensional matrix of integervariables (see Section 7.1.1.1): weeks, groups, slots, and golfers of a socialgolfer schedule are not distinguishable. This means,

• the weeks can be permuted (w! symmetries),

• the groups can be permuted within a week (g!w symmetries),

• the slots of a group can be permuted (s!w·g symmetries), and

• the golfer names can also be permuted ((g · s)! symmetries).

Note the distinction between slots and golfers which highlights the differencebetween value and variable symmetries. A naïve model would have w! · g!w ·s!w·g · (g · s)! symmetries! However, in general, the number of symmetries isnot an indicator of the difficulty of breaking them. Notice symmetries can beintroduced by the model: modeling groups as sets there is no notion of slot.

Symmetries must be handled in order to avoid wasting time visiting sym-metric solutions or visiting many search states that are symmetric to thosealready visited [9]. One well known method for breaking any type of sym-metry consist in posting ordering constraints to ensure that the final solutionis lexicographical less than any symmetric re-ordering of the variables. Thatis, select the “lex leader” solution configuration. In theory, this eliminates allsymmetric solutions and prunes many symmetric states [9]. Unfortunately, thenumber of symmetries might be exponentially large.

A general classification of symmetry breaking techniques distinguishes be-tween static symmetry breaking and dynamic symmetry breaking. On the onehand, static symmetry breaking is about adding ordering constraints to themodel exploiting the combinatorial structure of it (to avoid adding unneces-sary symmetry breaking constraints). Unfortunately, one known drawback ofthis approach is that it can have a negative interaction with the search proce-dure: solutions that were discovered early on during the search may disappearwhen including the new constraints [1]; this means it may take longer time todiscover the first solution with the symmetry breaking constraints rather thanwithout them. On the other hand, dynamic symmetry breaking is about addingconstraints by the search procedure or implementing problem-specific searchprocedures. For example, it is possible to explote the combinatorial structureof some problems to design symmetry-free search procedures to break valuesymmetries in constant time and space [24]. A working example of dynamicsymmetry breaking during search can be found in [1] as an implementation ofa solution to the Scene Allocation optimization problem.

26

3. Constraint-based Local Search(CBLS)

An important alternative to systematic search (see Section 2.3) is the so-calledlocal search which trades completeness and quality for speed. On the onehand, systematic search will find a solution (if one exists) and moreover eitherproof its optimality (if required) or give a proof of unfeasibility (albeit possi-bly after a long time). On the other hand, local search may give a solution butcan never guarantee its optimality; and it is also unable to give a proof of un-feasibility. This might sound pretty bad but is due to the fact that local searchonly explores parts of the search space of a CSP. The key great advantage oflocal search is speed: it often scales well to large instances and finds solutionsmuch faster. Moreover, the solutions given are usually of very high quality inproblems where other methods fail.

Local search starts from an initial configuration (obtained by another tech-nique or randomly otherwise), without concern whether some constraints areviolated. It then tries to find a better configuration, with respect to some qual-ity measure, making a small change, called move, to the current configuration.Before making a move though, local search evaluates many possible moves.Each examined move, if applied, would lead to a new configuration. The set ofthese possible next configurations (that would result from examined moves)constitutes the neighborhood of the current configuration. This iterates un-der suitable heuristics until a sufficiently good configuration has been found,or until some allocated resource (such as running time or number of itera-tions) has been exhausted. This is a very simple process that, unfortunately,may get stuck in local optima where the so far best solution can not be fur-ther improved. To deal with this problem, heuristics are extended with meta-heuristics (e.g., random restarts, tabu-search, simulated annealing, etc.) whichaim to diversify the search enough to find a global optimum (i.e., a, hopefullyoptimal, solution).

To get a feeling of how local search operates, consider an attempt to find asolution to the 5-queens problem (the n-queens problem was presentedin section 1.2.2) by means of local search. This example was taken from [4](a constraint satisfaction problem for n-queens was stated in section 1.3).

First, the five queens are placed (possibly randomly) on the board as shownin Figure 3.1 (a). Search starts from this initial configuration where all queensare violating some of the allDifferent(5 ) constraints for the diagonals (as theyare attacking at least two other queens in that directions). The neighborhood

27

Figure 3.1: Local search 5-queens. (a) Initial configuration. (b) A move. (c) Asolution. (d) A local minimum. (e) Escape from the local minimum.

taken into consideration is the set of configurations that can be gotten per-forming a single transposition move. A transposition move is a small changewhich corresponds to an exchange of the row positions of two queens. Thequality measure is defined as the number of pairs of queens attacking eachother in the configuration.

Then, a better configuration (i.e., a neighbor) is searched in the neighbor-hood. As the quality of the initial configuration is 6 while the quality of theneighbor shown in Figure 3.1 (b) is 2, the move leading to this neighborconfiguration is a potential candidate. Actually, a solution to the 5-queensproblem can obtained making this move from the initial configuration to theconfiguration shown in Figure 3.1 (b), and from there moving to the configu-ration shown in Figure 3.1 (c).

To finish with this example, consider the situation where the search getsstuck in local minima. This scenario is shown in Figure 3.1 (d). Indeed, theconfigurations’ quality is 2 and the quality of any of its neighborhoods is atleast 2. However, if now, for instance, the last queen is selected and movedto another row that minimizes the number of violated constraints, then the re-sult would be the configuration depicted in Figure 3.1 (e): the search wouldhave escaped from the local optima. Note how finding a solution using this ap-proach differs from the approach shown in Figure 2.1. Another nice examplecontrasting constructive search with local search, in the context of coloring amap of the Nordic countries, can be found in [2].

An important and well known meta-heuristic for local search is Tabu-searchwhich basically consists on selecting the best neighbor without concern whetherit can be worse than the current configuration. This approach does allow

28

the search to scape from local optima, but unfortunately can cause cyclingamong a set of configurations. To prevent cycling the so-called tabu-list ismaintained, which is a (possible variable length) list of forbidden moves.This meta-heuristic is sometimes further enhanced with an aspiration crite-ria which allows the tabu-status of some moves to be overridden under someparticular circumstances (for example, if the move leads to a significantly bet-ter configuration).

Typically, a local search algorithm is tailored to a specific combinatorialproblem which implies that the amount of theory and code reuse betweentwo different problems might be minimal, and that a significant amount ofprogramming work must be done to solve a new problem with local search[2]. Furthermore, many times local search algorithms are presented informallyor using low-level implementation details.

CBLS aims to reduce the amount of work when a new problem is to besolved with local search. Problems are modeled as CSPs, but instead of thecomplete search technique that CP offers, where constraints are used to nar-row domains of variables, in CBLS constraints are used mainly to both guidethe local search towards promising regions in the search space and determinewhen a given configuration is regarded as a solution.

Constraints for CBLS are discussed after formally introducing moves andneighborhoods. Most of the definitions given in this section as well as theexamples and algorithms are based or directly taken from [2].

3.1 Moves and NeighborhoodsIn order to find solutions, a local search algorithm starts from a (possiblyrandom) initial configuration and iteratively moves between configurations.

Definition (Move and neighbor). A move is a function

m : K → K

Given a configuration k, m(k) is a move from k, or a neighbor of k.

Before making a move, local search examines many candidate moves. Aconfiguration m(k) for an examined move k is a neighbor and, in this sense,all neighbors constitute the neighborhood of the current configuration.

Definition (Neighborhood). A neighborhood is a function

n : K → P(K)

Given a configuration k, the set of configurations n(k) is called a neighbor-hood of k (and each element thereof a neighbor of k).

29

Sometimes, it is necessary to reason about the moves from a configurationwhere only a particular variable may have changed. This is captured by thevariable-specific neighborhood under a configuration.

Definition (Variable-specific neighborhood). The variable-specific neighbor-hood of a variable x under a configuration k is the set of all configurationsthat differ from k for at most x:

{` ∈ K | ∀y ∈ V : y 6= x→ k(y) = `(y)}

In CBLS, constraints are used to navigate between configurations in thesearch space. Therefore they are implemented in terms of penalties and con-flicts which are estimates on how much the constraints are violated respec-tively how much particular variables contribute to those constraint violations.These constraint measures, which have also been called violation functions,are presented in the next section. Examples of moves and neighborhood forinteger and set variables follows.

3.1.1 Moves and Neighborhoods for Integer VariablesTwo typical moves for integer variables are assign and swap. Consider twointeger-variables x and y, and a value v.

Definition (Assign move). An assign(x,v) move function is defined by:

assign(x,v)(k) = k ⊕ {x 7→ v}

Hence, the move assign(x,v) differs from k (at most) in the binding for x,which is now bound to v.

The operator⊕ stands for binding replacement: f⊕g is the union of f and gwhere (f⊕g)(x) = g(x) for any x ∈ domain(f) ∩ domain(g). For example,assuming that k = {x 7→ a, y 7→ b}, assign(x, b) = {x 7→ b, y 7→ b}.

Definition (Swap move). A swap(x,v) move function is defined by:

swap(x,y)(k) = k ⊕ {x 7→ k(y), y 7→ k(x)}

Hence, the move swap(x,y) differs from k in the bindings for x and y, whichhave been exchanged.

For example, assuming that k = {x 7→ a, y 7→ b}, swap(x,y) = {x 7→b, y 7→ a}.

Definition (Assign neighborhood). The ASSIGN (X) neighborhood is de-fined by:

ASSIGN (X)(k) ={

assign(x,v)(k) | x ∈ X ∧ v ∈ D}

30

Hence, the neighborhood ASSIGN (X) is the set of all possible assign movesfor the variables in X .

For example, considering k = {x 7→ a, y 7→ b} and D = {a, b}:

ASSIGN (X)(k) =

{assign(x,a)(k), assign(x,b)(k),assign(y,a)(k), assign(y,b)(k)

}={

assign(x,a)(k), assign(x,b)(k), assign(y,a)(k)}

= {k, {x 7→ b, y 7→ b} , {x 7→ a, y 7→ a}}

In the following definition, consider now two set of variables X and Y anda configuration k.

Definition (Swap neighborhood). The SWAP (X,Y ) neighborhood is definedby:

SWAP (X,Y )(k) ={

swap(x,y)(k) | x ∈ X ∧ y ∈ Y}

Hence, the neighborhood SWAP (X,Y ) is the set of all possible swap movesbetween the variables in X and Y .

3.1.2 Moves and Neighborhoods for Set VariablesTypical moves for set variables are add , drop, flip, transfer , and swap.

Definition (Add, drop, flip, transfer, and swap moves). Given two set-variablesS and T , and two scalar values u and v. Assuming the feasibility conditionu ∈ k(S) ∧ u ∈ k(T ) ∧ v ∈ k(S) ∧ v ∈ k(T ) holds. The add, drop, flip,transfer, and swap moves are defined as:

• add (S,v) which adds v to S is defined by:

add (S,v)(k) = k ⊕ {S 7→ k(S) ∪ {v}}

• drop(S,u) which drops u from S is defined by:

drop(S,u)(k) = k ⊕ {S 7→ k(S) \ {u}}

• flip(S,u,v) which replaces u in S by v is defined by:

flip(S,u,v)(k) = k ⊕ {S 7→ (k(S) \ {u}) ∪ {v}}

• transfer (S,u,T ) which transfers u from S to T is defined by:

transfer (S,u,T )(k) = k ⊕ {S 7→ k(S) \ {u} , T 7→ k(T ) ∪ {u}}

31

• swap(S,u,v,T ) which swaps u of S with v of T is defined by:

swap(S,u,v,T )(k) = k ⊕

{S 7→ (k(S) \ {u}) ∪ {v} ,T 7→ (k(T ) \ {v}) ∪ {u}

}

In the previous, the only two essential moves are add and drop as the rest ofthem can be defined in terms on these two [2]. The corresponding definitionsfor the neighborhoods functions for set-CSPs follows.

Definition (Add, drop, flip, transfer, and swap neighborhoods). Given twosets of set-variables X and Y , and a configuration k. These moves are definedas:

• ADD(X ) returns the set of all add moves with respect toX , it is defined

by: ADD (X)(k) ={

add (S,v)(k) | S ∈ X ∧ v ∈ k(S)}

• DROP(X ) returns the set of all drop moves with respect to X , it is

defined by: DROP (X)(k) ={

drop(S,u)(k) | S ∈ X ∧ u ∈ k(S)}

• FLIP(X ) returns the set of all flip moves with respect toX , it is defined

by: FLIP (X)(k) ={

flip(S,u,v)(k) | S ∈ X ∧ u ∈ k(S) ∧ v ∈ k(S)}

• TRANSFER(X ,Y ) returns the set of all transfer moves betweenX andY , it is defined by:

TRANSFER(X,Y )(k) =

transfer (S,u,T ) such that:S ∈ X ∧ T ∈ Y ∧ S 6= T

∧ u ∈ k(S) ∧ u ∈ k(T )

• SWAP(X ,Y ) returns the set of all swap moves between X and Y , it is

defined by:

SWAP (X,Y )(k) =

swap(S,u,v,T ) such that:S ∈ X ∧ T ∈ Y ∧ S 6= T ∧ u ∈ k(S)∧ v ∈ k(S) ∧ v ∈ k(T ) ∧ u ∈ k(T )

As an example, consider the set variables in {S, T} and assume that U ={a, b}. Given a configuration k such that k(S) = {a} and k(T ) = ∅:

32

ADD ({S,T})(k) ={

add (S,b)(k), add (T,a)(k), add (T,b)(k)}

=

{S 7→ {a, b} , T 7→ ∅} ,{S 7→ {a} , T 7→ {a}} ,{S 7→ {a} , T 7→ {b}}

DROP ({S,T})(k) =

{drop(S,a)(k)

}= {{S 7→ ∅, T 7→ ∅}}

FLIP ({S,T})(k) ={

flip(S,a,b)(k)}

= {{S 7→ {b} , T 7→ ∅}}

TRANSFER({S,T},{S,T})(k) ={

transfer (S,a,T )(k)}

= {{S 7→ ∅, T 7→ {a}}}SWAP ({S,T},{S,T})(k) = ∅

3.2 Constraints for Local SearchLocal search algorithms by themselves are hard to reuse. Constraints intro-duce reusable components to local search and gives birth to Constraint-basedlocal search. When solving (hard) combinatorial problems with Local Search,constraints are implemented in terms of constraint measures. Constraint mea-sures are functions which estimates on how much the constraints are violatedor how much particular variables contribute to those constraint violations.

Definition (Constraint measure). A constraint-measure is a pair of functions℘ = 〈penalty , conflict〉 such that:

• penalty is a function inK → N which measures how violating a config-uration is (a more “violating” configuration is associated with a highermeasure value compared to a “less” violating configuration).

• conflict is a function in V × K → N which measures how much thepenalty decrease for a given configuration changing a particular vari-able.

Note that the conflict function defined in ℘ takes into account the particularpenalty function defined also in ℘. Next, the notion of constraint measures asimplementation of constraints is formalized.

33

Definition (Implementation of a constraint). A constraint-measure, denoted℘c =

⟨penalty(c), conflict (c)

⟩, is the implementation of a constraint c with

〈x1, . . . , xm〉 = vars(c) when, given a configuration k:

• 〈k(x1), . . . , k(xm)〉 ∈ c if and only if penalty(c)(k) = 0. The penaltyof c under k is penalty(c)(k).

• If conflict (c)(x, k) = 0 then penalty(c)(k) ≤ penalty(c)(`), for eachconfiguration ` in the variable-specific neighborhood of x under k. Thevariable-conflict of x with respect to c under k is conflict (c)(x, k).

Variable-conflict functions can be used to identify conflicting variables, i.e.,variables that if changed, may imply a penalty decrease; and they play an im-portant role when it comes to making the local search algorithm more efficient:they allow one to discard many moves in a given neighborhood that would notbe considered anyway [2].

There are many different alternative constraint measures for a given con-straints. Some of them will not perform well in the local search algorithm andhence it is very important that both penalty and conflict functions reflect thesemantics of the constraint in a natural way. This is further discussed in [2].

As an example, consider the allDifferent(n) constraint and assume the penaltyfunction aims to reflect the least number of variables that must change for theconstraint to be satisfied, while the variable-conflict function aims to reflectthe maximum penalty decrease possible by only changing the given variable.First, such a penalty function can be defined as:

penalty(allDifferent(n))(k) = n−∣∣∣{k(x) | x ∈ vars

(allDifferent (n)

)}∣∣∣Second, such a variable-conflict function can be defined as:

conflict(allDifferent(n))(x, k) =

1, if x ∈

(S = vars

(allDifferent (n)

))and |{y 6= x ∈ S | k(x) = k(y)}| ≥ 1;

0, otherwise.

This means the conflict of the given variable x is one if there exists anothervariable with the same value, and zero otherwise.

Finally, ℘(allDifferent(n)) =⟨

penalty(allDifferent(n)), conflict(allDifferent(n))⟩

.Assuming, for instance, that k = {w 7→ a, x 7→ b, y 7→ b, z 7→ b}, the valuegiven by penalty(allDifferent(4)(w ,x ,y,z ))(k) is 2; and similarly

34

conflict(allDifferent(4)(w ,x ,y,z ))(w, k) = 0,

conflict(allDifferent(4)(w ,x ,y,z ))(x, k) = 1,

conflict(allDifferent(4)(w ,x ,y,z ))(y, k) = 1,

conflict(allDifferent(4)(w ,x ,y,z ))(z, k) = 1.

Indeed,

• at least two variables must be changed in order to satisfy the constraint (e.g.,y and z changing the values its values to to c and d respectively); and

• the penalty may be decreased by changing any of the variables x, y, and z,but not w: the variables x, y and z all take the same value under k, while noother variables takes the value of w.

It should also hold that, given that the variable-conflict of w is zero,

penalty(allDifferent(4)(w ,x ,y,z ))(k) ≤ penalty(allDifferent(4)(w ,x ,y,z ))(`)

for each configuration ` in the variable-specific neighborhood of w under k.Indeed, the variable-specific neighbor of w under k is the set of configurations

k0 = k,

k1 = {w 7→ b, x 7→ b, y 7→ b, z 7→ b} ,k2 = {w 7→ c, x 7→ b, y 7→ b, z 7→ b} ,k3 = {w 7→ d, x 7→ b, y 7→ b, z 7→ b}

which implies that:

penalty(allDifferent(4)(w ,x ,y,z ))(k0) = 2,



penalty(allDifferent(4)(w ,x ,y,z ))(k3) = 2.

3.3 Local SearchLocal search gives an alternative to the systematic tree search approach ofother techniques (e.g., Constraint Programming): it sacrifices for speed theguaranteed optimality of solutions found by systematic search. Local searchis particularly useful for large-scale problems where other techniques fail orwhere solutions must be found within reasonable resource constraints. It starts

35

from an initial configuration and iteratively moves between configurations (inthe hope of improving the current configuration with respect to some qual-ity measure) until either a (probably sub-optimal but good enough) solutionhas been found or an allocated resource (such as running time or number ofiterations) has been exhausted.

As now exits a differentiation between an optimal and a sub-optimal solu-tions, the notion of optimal solution needs to be introduced.

Definition (Optimal solution). An optimal solution is a solution configurationof the best quality. Given a penalty function in K → N which measures thequality of a configuration, such that the lower returned value the better thequality, the set of all optimal solutions is defined as

S∗ ={k ∈ S | penalty(k) = min

k′∈Spenalty(k′)

}When evaluating a move from one configuration k to another, some of the

neighbors in n(k) may be either legal (in which case they may be selected)or forbidden. Once the legal neighbors are identified, by a LEGAL operation,the local search selects, by a SELECT operation, one of them and decideswhether to move to this neighbor or to stay at k [25]. Implementations ofthese operations can vary from very trivial ones (like making all moves legal,e.g., LEGAL-ALL(n(k), k) = n(k)) to very complex ones (perhaps relying onsophisticated data structures and algorithms). Examples of LEGAL operationare [11]:

• LEGAL-IMPROVING(n(k), k) = {k′ ∈ n(k) | penalty(k′) < penalty(k)}

• LEGAL-NONWORSENING(n(k), k) ={k′ ∈ n(k) | penalty(k′) ≤ penalty(k)

}• LEGAL-CONFLICTINGVAR(n(k), k) ={

k′ ∈ n(k) | k′(x) 6= k(x) for a conflicting variable x}

likewise, examples of SELECT operation are

• SELECT-FIRST(L, k) = the first element in L

• SELECT-BEST(L, k) =

RANDOM

({` ∈ L | penalty(`) = min

t∈Lpenalty(t)

})• SELECT-RANDOMIMPROVING(L, k) =

(penalty(`) < penalty(k))? ` : k; where ` = RANDOM(L)

36

LOCALSEARCH()1 k ← GENERATEINITIALCONFIGURATION()2 k∗ ← k // k∗ is the so far best configuration3 for i = 1 to MaxIterations4 k ← SELECT(LEGAL(n(k), k), k)5 if penalty(k) < penalty(k∗)6 k∗ ← k7 return k∗

Figure 3.2: Simple algorithm for Local Search.

Figure 3.2 depicts a simple algorithm taken from [11]. As a running exam-ple, let us take the graph partitioning example presented in [11]:

Given a graph G = (V,E) find a balanced partition 〈V1, V2〉 ofits vertices that minimizes the number of edges with end-points inboth V1 and V2. A balanced partition 〈V1, V2〉 of V satisfies bothV1 ∪ V2 = V and |V1| = |V2| = |V |

2 .

In order to run the simple algorithm, the following definitions are neces-sary.

• GENERATEINITIALCONFIGURATION() returns a random balanced parti-tion k〈V1,V2〉 for G.

• penalty(〈V1, V2〉) = penalty(k〈V1,V2〉

)is the number of edges with one

end-point in each set, i.e., |{(v, w) ∈ E | v ∈ V1 ∧ w ∈ V2}|.• n

(k〈V1,V2〉

)={k〈V1\{a} ∪ {b},V2\{b} ∪ {a}〉 | a ∈ V1 ∧ b ∈ V2

}, i.e., the ex-

amined moves are swap moves between two vertices.

• LEGAL(N, k) = LEGAL-IMPROVING(N, k)

• LEGAL(L, k) = SELECT-BEST(L, k)

Figure 3.3 depicts how the algorithm would find a solution for this prob-lem. Notice the fundamental property of the chosen neighborhood: if a con-figuration k〈V1,V2〉 is a balanced partition, then each partition in n

(k〈V1,V2〉

)is also balanced. As a consequence, any local search starting from a balancedpartition explores only balanced partitions, which means that only solutionconfigurations are considered during search (including the initial one). There-fore the balancing constraint becomes implicit. The size of the neighborhood

is(|V |2

)2. Notice also the algorithm becomes greedy as it selects always the

best legal neighbor.Many local search algorithms consider only a subset of configurations. This

set of configurations over which the algorithm is defined is called the (local)

37

Figure 3.3: The simple local search algorithm run for graph partitioning.

search space. This notion as well as the notions of local neighborhood andtransition graph are central in local search and hence also introduced here.The rest of the definitions in this section are taken from [25].

Definition (Local search space). A local search space is a set K− ⊆ K suchthat elements of K− often satisfy a subset C− of C, i.e.,

∀k ∈ K− :(∀c ∈ C− : 〈x1, . . . , xm〉 = vars(c)→ 〈k(x1), . . . , k(xm)〉 ∈ c

)Definition (Local neighborhood). A local neighborhood is a pair 〈K−, n−〉where K− is a (local) search space and n− a function in K− → P(K−) thatdefines, for each configuration k, the neighbor configurations n−(k) ⊆ K−.Whenever the relation k ∈ n−(k′) ↔ k′ ∈ n−(k) holds, the neighborhood issaid to be symmetric.

Definition (Transition graph). The transition graphG (K−, n−) associated toa neighborhood 〈K−, n−〉 is the graph whose nodes are configurations in K−

and where an edge a −→ b exists if b ∈ n−(a). The reflexive and transitiveclosure of −→ is denoted ∗−→.

A configuration is locally optimal if none of its neighbors have a betterquality measure. This is formalized in the following definition, note that localoptimality is always defined with respect to a specific neighborhood function.

38

Definition (Local optimal configuration). A configuration k is local optimalwith respect to n if

penalty(k) ≤ mink′∈n(k)

penalty(k′)

The set of all local optimal solutions with respect to n is denoted S+.

One of the critical issues in local search is to scape local minima, which iswhy local search algorithms typically feature interesting LEGAL and SELECToperations. This notions can now be formalized.

Definition (Legal and select). A LEGAL(N, k) operation is a functionP(K−)×K− → P(K−) that narrows sets of configurations from the search space.Similarly, a SELECT (L, k) operation is a function in P(K−)×K− → K−

that selects an element from L according to some strategy and decides to ac-cept it or to select the current configuration k instead.

Definition (Local search algorithm). A local search algorithm is a path:

k0 −→ k1 −→ · · · −→ kt

in the transition graph G (K−, n−) such that

ki+1 = SELECT (LEGAL(n−(ki), ki), ki) (0 ≤ i < t)

Typically, such a search produces a final computation state kt that belongsto S+ (for a given neighborhood function). The role of heuristics and meta-heuristics is to drive the search toward high-quality local optima and, ideally,those in S∗. Before discussing heuristics and meta-heuristics separately, someproperties of neighborhoods are reviewed next. Another nice example of localsearch in the context of the Traveling Salesperson problem can be found in[11].

3.3.1 Properties of NeighborhoodsThe effectiveness of a local search algorithm critically depends upon its neigh-borhood [25] properties; mainly: its size, connectivity, and constraints.

Definition (Size of a neighborhood). The size of a neighborhood n− for aconfiguration k is the cardinality of n−(k).

There is a trade-off between the length of the paths and exploration time:large neighborhoods induce shorter paths to high quality solutions but requirealso more exploration time [25]. As a consequence the size of the neighbor-hood is a key design decision: sometimes it is preferable to select a linearneighborhood (in the size of the problem) over a quadratic neighborhood, even

39

if the resulting path is longer; sometimes, however, the resulting neighbor-hood is not large enough to produce high-quality solutions within a reasonableamount of time.

Connectivity is the property that ensures that a neighborhood is strongenough to reach optimal solutions (although the heuristic and meta-heuristicmay prevent the algorithm from reaching them in practice. The formalizationof this notion follows).

Definition (Weakly connected neighborhood). A neighborhood n− is weaklyconnected if and only if, for each configuration k, there exists a path k ∗−→ k∗

to an optimal solution k∗.

Definition (Optimally connected neighborhood). A neighborhood n− is op-timally connected if and only if, for each pair of configurations k1, k2, thereexists a path k1

∗−→ k2.

Even though there are very effective local searches based on neighborhoodsthat are not connected, using (weakly) connected neighborhoods bring severaladvantages [25]:

• Local search algorithms typically do not need a restarting strategy to reachoptimal solutions, since there exist paths leading from each solution to anoptimal solution.• Randomized heuristics, where there is a nonzero probability of accepting

a neighbor k ∈ n−(k) for each configuration k, may be guaranteed (undercertain conditions) to reach a global optimum (in the limit). In other words,connectivity is a requirement for the convergence proofs of meta-heuristicssuch as simulated annealing.

Finally, one of the critical issues in local search is to determine how to com-bine feasibility and optimality requirements. The simplest option is to main-tain feasibility at all times by exploring only solution configurations in theneighborhood search. This is the approach taken by the neighborhood in thegraph partitioning problem presented in Section 3.3: the balancing constraintbecomes implicit while performing the search (it starts with a balanced parti-tion and the neighbor configurations are always balanced partitions as well).

In some applications, however, it is preferable to relax a subset of the con-straints and explore a larger search space [25]. Consider, for instance, theneighborhood n′ for graph partitioning, where a single vertex is reallocated:

n′(k〈V1,V2〉) ={k〈V1\{a},V2 ∪ {a}〉 | a ∈ V1

}∪{k〈V1 ∪ {b},V2\{b}〉 | b ∈ V2

}This neighborhood, n′, induces the local search to explore non-solution con-figurations (i.e., unbalanced partitions). It is thus important to drive the searchtowards both feasibility and high-quality solutions. This entails to design apenalty function that combines both feasibility and optimality:

penalty(k) = α · feasibility(k) + β · optimality(k)

40

LOCALSEARCH(penalty , LEGAL, SELECT, n, k)1 k∗ ← k2 for i = 1 to MaxIterations3 k ← SELECT(LEGAL(n(k), k), k)4 if penalty(k) < penalty(k∗)5 k∗ ← k6 return k∗

Figure 3.4: Generic algorithm for Local Search.

For instance, for a neighborhood n′ in the graph partitioning problem, thealgorithm may use the penalty:

penalty(k〈V1,V2〉

)= α ·

(|{(v, w) ∈ E | v ∈ V1}| −

|V |2

)2

+

β · |{(v, w) ∈ E | v ∈ V1 ∧ w ∈ V2}|

for some well chosen values of α and β. The feasibility component penal-izes the imbalance while the optimality component, as before, penalizes thenumber of edges with one end-point in each partition.

3.3.2 HeuristicsThis subsection aims to introduce, as examples, a couple of the several heuris-tics available in the literature. Heuristics typically choose the next neighborbased on local information, namely the current configuration and its neigh-borhood. Consider a generic parameterized version of the simple local searchalgorithm shown in Figure 3.2. Such a generic algorithm parameterizes thepenalty function as well as the LEGAL and SELECT operations. Further-more, it removes the generation of the initial configuration so the meta-heuristicscan apply the template from different initial configurations. This new version,shown in Figure 3.4, is used to explain both heuristics and meta-heuristics

Heuristics focus on choosing the next neighbor to move to. They are typi-cally specified by instantiations of the selection and legality operations. For in-stance, improvement heuristics can be formulated using a LEGAL-IMPROVINGoperator or using LEGAL-NONWORSENING when plateau moves are allowed(see Section 3.3); similarly, other heuristics might potentially consider allneighbors, in which case the legality operation becomes LEGAL-ALL. Manyclassifications for heuristics exist, here they are distinguished between sys-tematic and randomized.

41

BESTIMPROVEMENT(k)1 return LOCALSEARCH( penalty , LEGAL-IMPROVING,

SELECT-BEST, n, k)

Figure 3.5: Best-improvement heuristic for Local Search.

FIRSTIMPROVEMENT(k)1 return LOCALSEARCH( penalty , LEGAL-IMPROVING,

SELECT-FIRST, n, k)

Figure 3.6: First-improvement heuristic for Local Search.

3.3.2.1 Systematic HeuristicsSystematic heuristics perform a (possible partial) exploration of the neighbor-hood to determine the next configuration [25]. The best neighbor heuristic,for instance, consists of choosing the neighbor with the best evaluation andhence uses the SELECT-BEST operator. A best-improvement local search canthen be specified as shown in Figure 3.5 which is, clearly, an instantiation ofthe generic local search algorithm.

The best-improvement heuristic requires a complete scan of the neighbor-hood, which may be too costly when the neighborhood is large. On the otherside, for instance, the first-improvement heuristic simply selects the first movethat improves the current configuration, i.e., uses the SELECT-BEST operatorwhich, without lost of generality, may choose the “first” element with respectto some specified lexicographic order (for example by some lex function)while scanning the neighborhood. A first-improvement local search can thenbe specified as the instantiation of the generic local search algorithm shownin Figure 3.6.

3.3.2.2 Randomized HeuristicsWhile systematic heuristics perform a (possibly partial) exploration of theneighborhood to select the next configuration, random-walk heuristics selectan element of the neighborhood randomly and decide whether to accept itas next configuration, i.e., uses the SELECT-RANDOMIMPROVING operator.This randomized nature is sometimes critical to reach high-quality solutions[25]. A random-improvement walk is thus specified as the instantiation of thegeneric local search algorithm shown in Figure 3.7.

An interesting extension of the random improving heuristic is the Metropo-lis heuristic, in which some moves degrading the penalty value are allowed.

42

RANDOMIMPROVEMENT(k)1 return LOCALSEARCH( penalty , LEGAL-ALL,

SELECT-RANDOMIMPROVING, n, k)

Figure 3.7: Random-improvement heuristic for Local Search.

RANDOMNONWORSENING(k)1 return LOCALSEARCH( penalty , LEGAL-ALL,

SELECT-RANDOMNONWORSENINGt, n, k)

Figure 3.8: Random-nonWorsening heuristic for Local Search.

The Metropolis algorithm selects a random neighbor k′; if k′ does not degradethe current configuration, i.e., penalty(k′) ≤ penalty(k), it is accepted as thenext configuration. If it degrades the objective value, the Metropolis algorithmaccepts the move with a small probability

exp(− (penalty(k′)− penalty(k))

t

)(metropolis probability)

that dependes on the distance between penalty(k′) and penalty(s) and a pa-rameter t (called the temperature). More precisely:

SELECT-METROPOLISt(L, k) = SELECT-RANDOMNONWORSENINGt(L, k)= If (penalty(`) ≤ penalty(k)) Then ` Else RANDOM(t, k, `)

where ` = RANDOM(L) selects ` uniformly at random and RANDOM(t, k, `)selects ` with probability t. A random-nonWorsening walk is thus specified asthe instantiation of the generic local search algorithm shown in Figure 3.8.

3.3.3 Meta-HeuristicsLocal Search heuristics typically drive the search toward local optima (or localminima in the case of minimization problems) because they make decisionsbased on local information (on the quality of the neighbors). Conversely, meta-heuristics collect global information and its objective is primarily to scapefrom local optima and drive the search toward global optima. In this sense,heuristics typically include some form of memory or learning. There are sev-eral meta-heuristics available in the literature, this subsection aims to intro-duce a couple of them.

43

RESTARTS(penalty , LEGAL, SELECT, n)1 k ← GENERATEINITIALCONFIGURATION()2 k∗ ← k3 for i = 1 to MaxSearches4 k ← LOCALSEARCH(penalty , LEGAL, SELECT, n, k)5 if penalty(k) < penalty(k∗)6 k∗ ← k7 k ← GENERATENEWCONFIGURATION(k)8 return k∗

Figure 3.9: Restarts meta-heuristic heuristic for Local Search.

One ubiquitous meta-heuristic is (random) restarts which iterates a specificlocal search from different starting points (for instance, totally new config-urations) in order to sample various regions of the search space and avoidreturning to low-quality local optimum. This idea can be further refined bygenerating a new start point from the local optimum last returned by the localsearch (for instance, by perturbing it). The algorithm for restarts is shown inFigure 3.9. Notice that as there are no restrictions in the embedded local searchused in line 4, this meta-heuristic can be naturally composed with others.

Two well-known and popular meta-heuristics are presented next and thenConstraint-based local search is (finally) discussed.

3.3.3.1 Simulated AnnealingSimulated Annealing is a meta-heuristic based on the Metropolis, randomnon-worsening, heuristic. Recall this heuristic accepts a non-improving movefrom k to k′ with the metropolis probability (see Section 3.3.2.2) where t is aparameter of the heuristic.

The key idea underlying simulated annealing is to iterate the Metropolisalgorithm with a sequence of decreasing temperatures [25]:

t0, t1, . . . , ti, . . . (tk+1 ≤ tk)

and the goal is to accept many moves initially in order to sample the searchspace widely (large values of tk) and to move progressively toward small val-ues of tk, thus converging toward random improvement and, hopefully, a high-quality local optimal when ti → 0. The algorithm for simulated annealing isshown in Figure 3.10.

Two critical procedures in the simulated annealing algorithm are the choiceof the initial temperature (line 2) and the cooling schedule (line 8) which spec-ifies how to decrease the temperature. Both of these can be chosen experi-mentally or can be derived for specific instances [25]. In particular, the initial

44

SIMULATEDANNEALING(penalty , n)1 k ← GENERATEINITIALCONFIGURATION()2 t0 ← INITTEMPERATURE(k)3 k∗ ← k4 for i = 0 to MaxSearches − 15 k ← LOCALSEARCH( penalty , LEGAL-ALL,

SELECT-RANDOMNONWORSENINGt, n, k)6 if penalty(k) < penalty(k∗)7 k∗ ← k8 ti+1 ← UPDATETEMPERATURE(k, ti)9 return k∗

Figure 3.10: Simulated annealing algorithm for Local Search.

LOCALSEARCH(penalty , LEGAL, SELECT, n, k0)1 k∗ ← k0

2 τ ← 〈k0〉3 for i = 0 to MaxIterations − 14 if penalty(ki) < penalty(k∗)5 k∗ ← ki6 ki+1 ← SELECT(LEGAL(n(ki), τ), τ)7 τ ← τ :: ki+1

8 return k∗

Figure 3.11: Generalized generic algorithm for Local Search.

temperature and the cooling schedule can be derived by performing randomwalks at different temperatures.

3.3.3.2 Tabu-SearchTabu-search is a meta-heuristic which encompasses a great variety of tech-niques (a couple of them are presented here as in [25]). In order to understandthe intuition underlying tabu-search and formalize it concisely, it is better todiscuss it under a generalized version of the generic local search already pre-sented in Figure 3.4. The new version, shown in Figure 3.11, differs mainlyin maintaining the sequence τ = 〈k0, . . . , ki−1, ki〉 of configurations exploredso far.

The sequence τ is initialized with k0 in line 2 and extended in line 7 byappending configuration ki+1. Notice the LEGAL and SELECT operations

45

TABUSEARCH(k)1 return LOCALSEARCH( penalty , LEGAL-NOTTABU,

SELECT-BEST, n, k)

Figure 3.12: First approximation to the tabu-search algorithm.

are also generalized to take sequences of configurations instead of single con-figurations. All algorithms presented so far can be naturally extended to thenew generic algorithm by working on the last configuration in the sequence.

As a first approximation, given the sequence 〈k0, . . . , ki−1, ki〉, the tabu-search meta-heuristic selects ki+1 to be the best neighbor in n(ki) that has notbeen yet visited; as a consequence, tabu-search can be viewed as the combi-nation of a greedy strategy with a definition of legal moves ensuring that aconfiguration is never visited more than once. This approximation is shown inFigure 3.12, where

LEGAL-NONTABU(n(k), τ) ={k′ ∈ n(k) | k′ /∈ τ

}Two interesting features:

• the definition of legal moves imposes no restriction on the penalty value sothe select moves non-improving the quality of the current configuration areallowed and thus is possible to scape from local optima;

• the greedy nature of the algorithm ensures the penalty does not degrade toomuch at any step as the best neighbor is always chosen.

The problem: this definition needs to keep track of all visited configura-tions! Therefore the memory requirements become prohibitive. The solution:use short-term memory to prevent the search from returning to recently vis-ited configurations. This will not prevent the local search from revisiting con-figurations entirely, but it is often combined with other, (long-term memory)techniques (described shortly) to compensate.

The simplest way to implement short-term memory is to maintain only asmall suffix of the sequence (i.e., the recently visited configurations). How-ever, even such an implementation may be too costly in space and time, sinceit requires the search to compare configurations [25]. As a consequence, tabu-search algorithms typically maintain an abstraction τ of the sequence suffix.

This abstraction is often problem-dependent, albeit many guidelines areavailable for its specification. For example, since moves only involve a fewvariables in general, a popular technique is the transition abstraction whichstores the transitions instead of the configurations. The tabu-neighbors are

46

then defined as those configurations obtained through the inverse of storedtransitions.

For instance, consider again the graph partitioning example presented insection 3.3 and a transition k1 −→ k2 based on a neighborhood n. It followsthere exist two vertices v and w such that k2 is the partition k1 in which v andw have been swapped, i.e., k2 = swap(v,w)(k1). As a result, the transition canbe abstracted by remembering the pair of vertices (v, w) to avoid swappingthem again in the near future.More generally, a sequence

k0 −→ . . . −→ kt

can be abstracted by a sequence of pairs

(v0, w0), . . . , (vt−1, wt−1)

such that ki+1 = swap(vi,wi)(ki). A configuration k′ ∈ n(ki) is then definedas tabu (or taboo) if can be obtained from ki by swapping a pair (vi, wi) (thatis, if there exists i 0 ≤ i < t) such that k′ = swap(vi,wi)(ki).

Intuitively, this means the local search cannot swap two vertices that havebeen swapped recently. Moreover, each iteration of the local search appends anew pair but drops an old one as well. In tabu search, the abstract sequence τ isthe so-called tabu-list and may contain the transitions, the inverse transitions,or both. The legal moves are then specified as:

LEGAL-NONTABU(n(k), τ) ={k′ ∈ n(k) | ¬tabu(k′, τ)

}where, informally, tabu(k′, τ) holds if the neighbor is tabu with respect to thetabu-list τ . More formally,

tabu(k′, τ) ≡ ∃τ ∈ γ(τ) : k′ ∈ τ

where γ(τ) is the set of sequences abstracted by τ .Transition abstractions are at the same time too week and too strong [25].

On the one hand, they are too weak because they cannot prevent the tabu-search from revisiting configurations (only a sequence suffix is abstracted).On the other hand, they are too strong because they forbid moves that shouldbe allowed. Indeed, a transition abstraction τ represents a set of sequencesγ(τ) that may be very different from τ but cannot swap the vertices in thetabu-list.

Transition abstractions do not abstract any information about the config-urations of a transition. Therefore, the problem is that, they may forbid toomany moves to unvisited configurations and prevent the search from reachinghigh-quality solutions. Nevertheless, it is possible to be more discriminatingby storing information about the configurations as well. For instance, in thegraph partitioning example, the tabu search may abstract the configurations

47

INTENSIFIEDLOCALSEARCH(penalty , LEGAL, SELECT, n)1 k ← GENERATEINITIALCONFIGURATION()2 k∗ ← k3 for i = 1 to MaxSearches4 k ← LOCALSEARCH(penalty , LEGAL, SELECT, n, k)5 if penalty(k) < penalty(k∗)6 k∗ ← k7 k ← k∗

8 return k∗

Figure 3.13: Simple intensification of a Local Search.

by their penalty values and store quadruples (penalty1, penalty2, v1, w1) tocapture a transition k1 −→ k2 where

k2 = swap(v1,w1)(k1) ∧ penalty(k1) = penalty1 ∧ penalty(k2) = penalty2

As a result, a move k −→ k′ is tabu if it reverses an earlier move:

k′ = swap(w1,v1)(k) ∧ penalty(k) = penalty2 ∧ penalty(k′) = penalty1

In order to deal with the problem that tabu-search stores sequence abstrac-tions and not the sequences themselves (and therefore may forbid moves k1 −→k2 where k2 has not been visited before and is highly desirable, for instance,when s2 would be the best solution found so far, i.e., penalty(k2) < penalty(k∗)),tabu search algorithms often feature an aspiration criterion that specifies whenthe tabu status may be overridden. The simplest and most widely used aspi-ration criterion overrides the tabu status of those moves that improve the bestsolution found so far and hence:

LEGAL-NONTABU-ASP(n(k), τ) ={k′ ∈ n(k) | ¬tabu(k′, τ) ∨ penalty(k′) < penalty(k∗)

}Finally, in order to deal with the problem that tabu-lists abstracts a small

suffix of the configuration sequence and cannot capture long-term informa-tion (and thus cannot prevent the search from taking long walks whose con-figurations have low-quality penalty values or spending too much time in thesame region) many tabu-search algorithms are further improved with addi-tional long-term memory structures to intensify and diversify the search.

Intensification entails storing high-quality solutions (e.g., the best solutionfound so far) during the search and returning to them periodically. An inten-sification algorithm for local search is shown in Figure 3.13 where the inten-sification takes place in line 7. This makes it possible to explore extensively

48

the region of the search space where the best solution found so far has beenfound. Diversification entails directing the search towards other regions of thesearch space. There are many ways to achieve this (for instance, using (ran-dom) restarts).

3.4 Constraint-based Local SearchSo far the implementation of a constraint c for Local Search is given by aconstraint-measure specified by a pair ℘c =

⟨penalty(c), conflict (c)

⟩. While

CP models implement CSPs for constraint programming (see Section 2.2),CBLS models implement CSPs for Constraint-based Local Search. Instead ofrequiring a one-to-one correspondence between constraint-measures and con-straints, CBLS models featuring several constraint-measures implement CSPsfeaturing several constraints.

Definition (CBLS model). Given a CSP 〈V,D,C〉, a CBLS model is givenby the triple 〈V,D,M〉, where M is a finite set of constraint-measures imple-menting the constraints in C.

Definition (Constraint-measure solutions). The set of solutions of a constraint-measure ℘ is referred to by sols(℘) and defined as {k ∈ K | penalty(k) = 0}.Definition (CBLS model solutions). The set of solutions for a CBLS modelL is denoted by SL and defined as

⋂℘∈M

sols(℘).

The notion of CBLS models as implementations of CSPs can now be for-malized.

Definition (Implementation of a CSP by a CBLS model). A CBLS model Limplements a constraint satisfaction problem C , if SL = SC .

Definition (CBLS model penalty). The penalty of a CBLS model L = 〈V,D,M〉under k is given by penaltyL (k) =

∑c∈C

penalty(c)(k) and therefore

SL =

{k ∈ K |

∑c∈C

penalty(c)(k) = 0

}

Definition (CBLS model conflict). The variable conflict of x with respect toL = 〈V,D,M〉 and k is the sum

conflictL (x, k) =∑c∈C

conflict (c)(x, k)

Penalty and conflict functions are central in local search together with dif-ferentiation functions (described shortly). These functions are mainly used toguide the local search [11]:

49

CBLS-N-QUEENS(n)1 L ← 〈V,D,M〉 ← N-QUEENS-CBLS-MODEL(n)2 k ← GENERATEINITIALCONFIGURATION(V )3 k∗ ← k4 for i = 1 to MaxIterations5 k ← SELECT-BEST

(LEGAL-MAXCONF.VAR

(ASSIGN (V )(k), k

), k)

6 if penaltyL (k) < penaltyL (k∗)7 k∗ ← k8 return k∗

Figure 3.14: A greedy CBLS algorithm for the n-queens problem

• penalty functions help to select a promising constraint for selecting vari-able(s) to change in a move,

• conflict functions help to select promising variables(s) to change in a move,and

• differentiation functions help to make a move in the good direction for aconstraint or variable

Consider again, the CSP for the n-queens problem given in Section 1.3.A greedy local search algorithm for this problem is presented in Figure 3.14,where

LEGAL-MAXCONFLICTINGVAR(n(k), k) ={k′ ∈ n(k) | ∃x ∈ V : k′(x) 6= k(x) ∧

conflictL (x, k) = maxx′∈V

conflictL (x′, k) > 0

}

Figure 3.15 depicts both an initial and a solution configuration for 8-queens.The numbers at the bottom of the board represent the values of the variableconflicts, i.e., the number below column i represents conflictL (Queeni, k).These values have been computed with the penalty and conflict functions de-fined for the allDifferent (n) constraint in Section 3.2: the variable-conflictfunction reflects the maximum penalty decrease possible by only changingthe given variable, and the penalty function reflects the least number of vari-ables that must be change for the constraint to be satisfied. Keep in mind thereare three allDifferent (n) constraints in C.

In the initial configuration, Queen8 has a variable conflict of 0 because it isnot attacking any other queen; on the other side, Queen4 has a variable con-flict of 3 because it is attacking 3 other queens in different directions. HenceQueen4 is selected as the most conflicting variable.

50

Figure 3.15: Initial configuration (left) and solution (right) for 8-queens.

Notice the bolded number in the lower right corners stands for the penaltyvalue, i.e., penaltyL (k). Naturally, the solution configuration has a penaltyvalue of zero, while the penalty for the initial configuration is 2 + 2 + 3 = 7:

• for allDifferent(8 )(Queen1 , . . . ,Queen8 ) the penalty ofallDifferent(8 )(8, 5, 4, 5, 1, 2, 1, 6) is 2;

• for allDifferent(8 )(Queen1 − 1, . . . ,Queen8 − 8) the penalty ofallDifferent(8 )(7, 3, 1, 1,−4,−4,−6,−2) is 2; and

• for allDifferent(8 )(Queen1 + 1, . . . ,Queen8 + 8) the penalty ofallDifferent(8 )(9, 7, 7, 9, 6, 8, 8, 14) is 3.

Now one queen to move has been selected (and therefore the possible moveshave been determined) together with the place this queen is going to be movedto. The heuristic asks to select the best move, i.e., the move which leads tothe minimum penalty value. This requires to somehow evaluate all possiblemoves and then select the best among them. To this end the implementation ofconstraints for CBLS also include differentiation functions. A differentiationfunction computes the increase in the penalty by performing a move. Thevalue returned by a differentiation function is usually called delta (and denotedby δ). This value is negative upon a decrease of the penalty, so the smaller thevalue the better. This example was taken from [11] and it is further explainedin Section 3.4.2.

3.4.1 Incremental AlgorithmsA local search algorithm may perform many moves. To select each move, alarge number of candidates moves may be evaluated in terms of their effecton penaltyL . As a consequence, the effort of evaluating each move must behighly effective in terms of time (and space) since, otherwise, the performanceof the local search algorithm may be very poor [2]. The effort of evaluating

51

each move must be low then, and this is usually achieved using incrementalalgorithms.

Consider a constraint ℘c =⟨

penalty(c), conflict (c)

⟩in the context of a

CBLS model L = 〈V,D,M〉. Given two configurations k and ` in K, as-sume that x ∈ vars(c). Warning: the definition of an incremental algorithmfor ℘c is rather loose. Such an incremental algorithm would consist of twoparts: an initialize part and an update part, operating over a data structureD(c)[2]. The data structure D(c) is used to maintain incrementally penalty(c) andconflict (c) and has (at least) the fieldsD(c).penalty (an integer, initially zero)and D(c).conflict (an array of integers indexed by vars(c), initially contain-ing only zeros). Given this, after a call initialize(D(c))(k):

D(c).penalty = penalty(c)(k)

D(c).conflict [x] = conflict (c)(x, k)

Similarly, assuming D(c).penalty = penalty(c)(k) and D(c).conflict [x] =conflict (c)(x, k), after a call update(D(c))(k, `):

D(c).penalty = penalty(c)(`)

D(c).conflict [x] = conflict (c)(x, `)

A nice example of an incremental algorithm for allDifferent (n) can befound in [2] (the source of this section).

3.4.2 Differentiation FunctionsAs differentiation functions become necessary, here they are introduced for-mally.

Definition (Differentiation function). A differentiation function for a con-straint c with respect to a move M is a function δ-M (c) in K ×K → Z suchthat given two configurations k andM(k) = `, δ-M (c)(k, `) gives the increaseδ in penalty(c) by performing a moveM ; that is δ = penalty(`)−penalty(k).

In this sense, a swap differentiation function for a constraint c, δ-Swap(c),gives the delta in penalty(c) upon swapping the values of two variables; or,in the case of set variables, the delta upon swapping two elements of two setvariables. Likewise, a δ-Assign(c) differentiation function gives the delta inpenalty(c) upon an assignment of a variable x ∈ vars(c).

Consider, for instance, an evaluation of assigning row 6 to Queen4 in theinitial configuration for 8-queens depicted in Figure 3.15. Initially, thepenalties are 2, 2, and 3 for

• allDifferent(8 )(Queen1 , . . . ,Queen8 ),

• allDifferent(8 )(Queen1 − 1, . . . ,Queen8 − 8), and

52

Figure 3.16: Effect of an assign differentiation function for allDifferent(8). To the leftthe allDifferent(8)(Queen1 , . . . ,Queen8 ) constraint (delta = 0), and to the right theallDifferent(8)(Queen1 − 1, . . . ,Queen8 − 8) constraint (delta = −1).

• allDifferent(8 )(Queen1 + 1, . . . ,Queen8 + 8) respectively.

Figure 3.16 shows what happens with the first two of these constraints whenmoving Queen4 to row 6. In the first case two pair of variables are assigned(each pair) to a same value. Queen4 belongs to one of these pairs; however,after the assignment two pair of variables are assigned to a same value again(Queen4 now takes the same value with Queen8): the effects are canceledand δ = 0. Conversely, in the second case (for allDifferent(8 )(Queen1 −1, . . . ,Queen8 −8)), two pair of variables are assigned to a same value beforethe assignment, but after the assignment Queen4 does not share a value withany other variable: now there is only one pair of variables assigned to thesame value and hence δ = −1. Delta values are negative upon a decrease ofthe penalty. The third case is analogous and gives δ = −1.

The implementation of a constraint for CBLS needs then to be extended toinclude differentiation functions.

Definition (Implementation of a constraint – extension). A differentiable con-straint is the implementation of a constraint c as a constraint-measure ℘c,augmented with a set of differentiation functions ∆(c):

℘+c =

⟨penalty(c), conflict (c),∆(c)

⟩53

Figure 3.17: CBLS iterations for 8-queens.

Definition (CBLS model differentiation). The delta for a CBLS model Lwith respect to a move M from k to M(k) = ` is given by

δL =∑c∈C

δ-M (c)(k, `)

For instance, delta value for assigning row 6 to Queen4 in the initial con-figuration for 8-queens, depicted in Figure 3.15, is 0 + (−1) + (−1) = −2.In the figure, the values at the right of the rows are the CBLS model differ-entiation delta values for moving the selected variable to the respective rows.Figure 3.17 depicts two more iterations for the CBLS approach to this prob-lem. Differentiation in CBLS is the counterpart of propagation in CP.

3.5 Symmetry BreakingSymmetries are inherent to many CSPs. They can sometimes be managedwhen modeling, i.e., by creating yet equivalents model with less (ideally with-out) symmetries, but in the rest of the cases the solving technique (e.g., CP orCBLS) has to deal with them.

In local search symmetries are rather ignored. Instead of doing somethingabout them to make the search space smaller, the typical strategy is doingnothing. However, some experiments have been made in order to lesser theinfluence of a high number of symmetries in a problem. For instance, [6]presents a Memetic Evolutionary Programming approach to the Social GolferProblem.

54

Part II:

CBLS in Comet

4. The Comet System

The inherent complexity of combinatorial optimization problems often giverise to complex and intricate pieces of software which are large and tediousto design, implement, and maintain. The Comet system offers an object-oriented garbage-collected language supporting a layered constraint-based ar-chitecture for local search which cleanly separates modeling and search. Inthe kernel of this architecture resides the concept of invariants which makesComet a powerful tool.

Although this chapter discusses Comet in the context of CBLS, the Cometsystem has also CP (systematic search with propagation) and MIP (mixedinteger linear programming) back-ends. Typically, techniques for optimizationtools aimed to find solutions to CSPs (as CP, CBLS, or MIP) are realizedas a library for a general purpose programming language (e.g., GECODE forC++), as an extension of an existing language (e.g., ECLiPSe or SICStusProlog as an extension of Prolog), or, as in the case of Comet, as a systemwith its own dedicated language.

The Comet programming language is very rich: it provides incrementalvariables, built-in invariants, constraints, and objectives, as well as severalnovel control abstractions for local search. Both tasks modeling and searchare largely simplified then mainly due to both the provided constraints andobjective functions for declarative expressing CSPs and the high-level con-structs for specifying (potentially generic) search procedures. As a result, lo-cal search programs are often both short and concise with a clear separationbetween the model and the search (i.e., between the model and the heuristictogether with its respective meta-heuristics).

Concerning efficiency, Comet and CBLS in general introduce several lev-els of indirection compared to low-level implementations [25]. In some par-ticular applications in which the basic operations are extremely simple, theinduced overhead may be significant when very high performance is desired.Typically, however, for complex applications with heterogenous and peculiarconstraints, and complex neighborhoods, the overhead is small. Furthermore,this small overhead may become irrelevant by the reduction in developmenttime or ease in experimentation. Comet is indeed a great language for exper-imentation!

Comparisons between implementations in Comet and lower level languageshave been made. For instance, [17] describes an implementation of a frame-work for using graphs and tree constraints in Comet. They find the imple-

57

Figure 4.1: Comet’s architecture for Constraint-Based local search.

mentation in Comet around 2.5 times slower than the counterpart in C++, butthey also point out the facility gained when using Comet.

Unfortunately, Comet is not open source. Nevertheless (and good enough),Comet is free of charge for academic purposes and provides an open archi-tecture allowing user-defined extensions. The mechanism to add user-definedinvariants, for instance, was particularly useful for this thesis project.

4.1 ArchitectureComet architecture for Constraint-based Local Search (depicted in Figure 4.1)consists of three layers (around incremental variables) separating the model-ing and the search components [25]. The outermost layer stands for the localsearch itself (i.e., heuristics and meta-heuristics) while the two innermost, in-variants and differentiable objects, are instrumental in specifying the modelingcomponent of local search algorithms.

This separation of concerns is clearly reflected in Comet programs: al-though both model and search components often interact in complex waysduring execution, they both appear physically separated in the source code.Thus is easy to modify one of them without affecting the other. For example,the search procedure can be replaced or modified without affecting the modeland, likewise, the model can be modified or upgraded without touching thesearch procedure.

A great advantage of Comet’s CBLS back-end is its open architecture thatallows user-defined extensions for both modeling and search:

• At the model level, new differentiable objects (e.g., constraints) can be de-fined and then treated exactly like other non-user-defined differentiable ob-jects. The implementation of these is greatly simplified by the availabilityof invariants which maintain (possible complex) algebraic and set expres-

58

sions incrementally under changes in the incremental variables. Further-more, user-defined invariants can also be defined.

• At the search level, the availability of closures and continuations as the en-abling technology for new control structures makes possible to simplify thespecification of complex search algorithms. Similarly, non-deterministic in-structions are parameterized making it easy to specify new search strate-gies and new implementation schemes. Furthermore, events are availableto separate the heuristics from meta-heuristic and make the source codeeven more clean.

Next, each part of the layered architecture is briefly discussed.

4.1.1 Incremental VariablesIncremental variables are the heart of Comet’s architecture as they are theunderlying basis of it [1]. Informally, incremental variables are a generalizedversion of typed variables with extra functionality. They are typically associ-ated with a domain (i.e., its possible values) and every change in their valuetypically triggers a propagation step that updates any other object affected.

Invariants (described shortly) are expressed in terms of incremental vari-ables and specify a relation that must be maintained under assignments of newvalues to its variables. Incremental variables are thus the building blocks forforming all kinds of differentiable objects: expressions, invariants, constraints,and objective functions.

It is Comet responsibility (through local solvers) to manage dependen-cies between variables that belong to the same differential object (e.g., to thesame constraint), and for updating the evaluation of differential objects afterchanges in the incremental variable’s values: the implementation can deter-mine a topological order in which to update the invariants in order to achievea high performance.

Currently, there are four types of incremental variables supported by Comet:integer, floating point, boolean, and set over integers. The first three are ob-jects of class var{int} and the incremental set over integer variables (“in-cremental set variables” from now on) are objects of class var{set{int}}.A nice feature of incremental variables is their support for different kind ofevents. For instance, incremental set variables support the @insert(int i)

and @remove(int i) events to notify whenever a value i has been added orremoved.

Generally speaking, objects of class var{int} implement integer variablesand objects of class var{set{int}} implement set variables. Constraints andset-constraints are respectively defined on these.

59

4.1.2 InvariantsInvariants are the kernel (i.e., the most important and central part) of theComet architecture. They provide declarative specifications of incremen-tal algorithms that are fundamental in obtaining high performance for localsearch [25]: they specify what to maintain incrementally and not how to doso (which is Comet’s responsibility). More specifically, an invariant is an as-signment of the form:

v � exp

where v is a incremental variable and exp an expression. Comet guaranteesthat, at any time during the computation, the value of variable v will be equalto the value of the expression exp [1]: every time a new value is assigned to avariable in exp, the value of v is updated accordingly in constant time.

Currently, there are three types of invariants supported by Comet: numeri-cal, combinatorial, and set invariants. Furthermore there is a mechanism avail-able to add user-defined invariants by implementing the Invariant<LS> inter-face. User-defined invariants can then be treated exactly like other non-user-defined invariants.

Invariants provide a fundamental abstraction layer for the implementationof differentiable objects (e.g., constraints). Thereby, constraints are indepen-dent of each other and interact only through incremental variables. This givesflexibility and greatly simplifies the definition of new constraints since thedifferentiable objects can be implemented in isolation. This also makes easyadding constraints in a model without affecting the rest of the model and thesearch.

Finally, invariants are also useful for maintaining various neighborhoodsincrementally (e.g., when it is more convenient to maintain parts of the neigh-borhood incrementally rather than recomputing them at each iteration).

4.1.3 Differentiable ObjectsDifferentiable objects in general encapsulate efficient incremental algorithmswhich arise in many applications and are the core of the modeling component.Once invariants are available, it becomes natural to support this fundamentalconcept [15]. Differentiable objects maintain a number of properties (typicallyusing invariants) and can be queried to evaluate the effect of local moves onthese properties. They are fundamental because many local search algorithmsevaluate the effect of various moves before selecting the next neighbor to visitand this could become very expensive.

Currently, there are three types of differentiable objects in Comet: con-straints, objective functions, and first-class expressions:

• A differentiable constraint maintains its constraint measures, i.e., its penaltyand conflict functions, as well as a set of differentiation functions that en-

60

ables the constraint to be queried to evaluate the effect of local moves (e.g.,assignments and swaps) on its measures.

• A differentiable function maintains the value of a (possibly) complex func-tion and it can also be queried to evaluate the variation in the function valueunder local moves.

• A differentiable expression is an expression that can be queried to evaluatethe effect on its value given a local move. What makes first-class expres-sions special is that both constraint and objective functions can also be de-fined over them (not only over incremental variables). Therefore, first-classexpressions can also be viewed as a generalized version of incremental vari-ables.

Differentiable objects capture combinatorial substructures (arising in manyapplications) and are appealing for two main reasons [15]. First, they are high-level modeling tools which can be composed naturally to build complex localsearch algorithms; and second, they are amenable to efficient incremental al-gorithms that exploit their combinatorial properties.

In Comet, by design, all constraints implement the same Constraint<LS>

interface, which mainly specify methods for the constraint measures and thedifferentiation functions. However, user-defined constraints need to extend theUserConstraint<LS> class (which in turn implements the Constraint<LS>

interface). Currently, Comet provides (and supports) numerical and combi-natorial constraints. It also allows to build complex constraints by combin-ing simpler ones using different kinds of constraint-combinators (e.g., Con-straint Systems). Indeed, compositionality and reuse are the reasons of whyconstraints (and objectives as well) are required to implement the same inter-face.

Similarly, by design, all objective functions implement the (same) interfaceFunction<LS>, which mainly specify a method to evaluate the value of theobjective function (which is maintained incrementally) and methods for therespective differentiation functions (i.e., methods to evaluate the effect of amove on the evaluation). Differentiable functions, in the same way as con-straints, are mainly used to guide the search towards optimal solutions. User-defined objective functions need to extend the UserFunction<LS> class andimplement the necessary methods.

Finally, first-class expressions, the last significant class of differentiableobject, are constructed from incremental variables and constants using arith-metic, logical, and relational operators. For example, a declaration of the formexpr{int} defines a first-class integer expression. These can effectively bequeried to determine the impact of local moves on their values. First-class ex-pressions significantly increase the modeling power of the language becauseconstraints and objectives can be defined over these differentiable objects too.

61

4.1.4 HeuristicThe search component does not prescribe any specific heuristic or meta-heuristic;rather, it features high-level constructs and abstractions aimed to foster and in-crease separations of concerns, and to simplify both neighborhood explorationand the implementation of meta-heuristics.

The search layer features, for instance, multidimensional selectors as wellas a variety of abstractions to express neighborhood exploration concisely andto control the graph exploration [15]. The more advanced control structuresimply the use of closures and continuations.

4.1.4.1 Separation Between Heuristics and Meta-HeuristicsA useful abstraction of Comet are events which give a mechanism to de-compose different parts of an implementation and in general improve codereadability by making it more modular. In particular, events are beneficial formodularity and separation of concerns in constraint-based local search as theyare, in many cases, sufficient to separate the search heuristic from the meta-heuristics (e.g., restarts or tabu search).

For instance, the restarting component of a local search algorithm can beentirely separated from the model and from the search heuristic. Thus boththe model and the heuristic can be modified without affecting the restartingcomponent. This is very useful for experimentation with meta-heuristics. Anexample in the context of the n-queens problem can be found in [25].

Many events are already defined in Comet and the most useful ones aredefined on incremental variables [1]. It is also possible to create user-definedevents.

4.2 The Comet LanguageThis chapter about Comet was by no means meant to be comprehensive butrather introductory to the main concepts behind Comet’s CBLS architectureand their intuitions. A lot of illustrative working examples using Comet’sCBLS module together with detailed explanations can be found in either [25]or [1] (the latter is, naturally, a very good source to learn the Comet language:Part I explains the Comet language by example and, likewise, Part III explainsCBLS using the Comet’s CBLS module in detail).

Most of the material presented in Chapter 5 is taken from [25] and theversion of Comet used for this thesis is 2.1.

62

5. Local Search Structures in Comet

This chapter describes the most common local search structures for CBLSusing Comet (i.e., incremental variables, invariants, and constraints). The de-scriptions are aimed to be technical. For a conceptual treatment of CBLS andComet’s CBLS back-end see Chapters 3 and 4.

5.1 Incremental VariablesIncremental variables are a sort of generalized version of typed variables withextra functionality. They are defined with respect to a local solver and a do-main (associated either explicitly or automatically). A local solver is an objectof class Solver<LS> which is in charge of managing dependencies betweenvariables that belong to the same differentiable object, and of updating theevaluation of differential objects after changes in the values of incrementalvariables.

All integer incremental variables are objects of class var{int}. The inter-face for this class is partially shown in Listing 5.1.

1 class var{int} {2 Solver<LS> getLocalSolver();3 int getId();45 void exclude();6 void includ();78 set{int} getDomain();9 void setDomain(set{int});

1011 ...12 }

Listing 5.1: var{int} class

The method getLocalSolver() returns the local solver the variable be-longs to. Likewise, the getDomain() method returns the domain of the incre-mental variable. This domain can be set with the setDomain(s) method. Theexclude() method excludes the variable from any solution obtained by thelocal solver; complementary, the includ() method includes the variable inany solution obtained by the local solver (which is the default behavior). The

63

variable’s id in the range [0, N ], where N is the number of variables in themodel, can be obtained with the getId() method.

The APIs for float incremental variables (var{float}) and boolean incre-mental variables (var{bool}) are basically restricted version of the var{int}

class. Conversely, the API for incremental set variables include some set-specific methods like insert(v), delete(u), getSize() with the functional-ity described by its names. Incremental set variables are objects of the var{set{int}}class. The interface for this class is partially shown in Listing 5.2.

1 class var{set{int}} {2 Solver<LS> getLocalSolver();3 int getId();45 void exclude();6 void includ();78 set{int} getSize();9

10 void insert(int);11 void delete(int);12 ...13 }

Listing 5.2: var{set{int}} class

All incremental variables support different kinds of events (although someevents may not be supported by all types of incremental variables, see ??).

5.2 InvariantsInvariants are a sort of “one way constraints” expressed in terms of incremen-tal variables and expressions. They have a declarative nature: once specifiedan algebraic or set expression with an invariant (i.e., the “what”), is the systemthat is in charge of maintain it incrementally under assignments of new valuesto its variables (i.e., the “how”). In Comet an invariant is an instruction ofthe form v <-exp where v is an incremental variable and exp an expression:Comet guarantees the value of v will be equal at all times to the value of theevaluation of exp.

Note that Comet does provide (at least partially) support for invariants overset expressions. For example, one can use union, intersection, or set differ-ence operators to form such expressions, or even use operators like card andmember to maintain set cardinality and membership information as invariants.Expressions over integer variables can typically be arbitrarily complex, butthere are limitations in the case of expressions over set variables. For example,in the development of the experiments for this thesis, many times the invari-ants had to be expressed in alternative ways due to this problem which (un-fortunately) could only be detected at run-time. For instance, some attempts

64

to define creative invariants ended with error messages like executionerror: Dynamic expression inside a fully dynamic invariantor Internal Error: void LocASTVisitor::applyASTMapof(LocASTMapof*n).

Fortunately, when it is not possible to create directly an invariant from acomplex expression or when a new (possibly complex) invariant not avail-able in Comet is required, there is a mechanism to add user-defined invari-ants through the Invariant<LS> interface. This interface is partially shown inListing 5.3.1 interface Invariant<LS> {2 Solver<LS> getLocalSolver();3 void post(InvariantPlanner<LS>);4 void initPropagation();5 void propagateInt();6 void propagateRemoveIntSet(bool,var{set{int}},int);7 void propagateInsertIntSet(bool,var{set{int}},int);8 ...9 }

Listing 5.3: Invariant<LS> interface

A class implementing the Invariant<LS> interface defines a user-definedinvariant. A user-defined invariant can be created and posted to the local solverlike any other invariant. The methods of the interface include:

• The getLocalSolver() method which simply returns the local solver theinvariant is defined on.

• The post(ip) method used for posting the invariant inside a constraintsystem (see Section 5.5). Its only parameter, of type InvariantPlanner<LS> is a planner that should be used during posting to state any dependenciesbetween the input variables and output variables. In this sense, two veryimportant methods of the planner are:

• addSource(v) used to report the invariant dependes on an input in-cremental variable v, i.e., to report the source variables; and• addTarget(v) used to report that the the value of an incremental vari-

able v depends on the invariant, i.e., to report the target variables.

• The initPropagation() method is called automatically during planifica-tion and allows the invariant to properly initialize its internal state.

• Finally, the methods propagateInt(b,x), propagateRemoveIntSet(b,s,u) and propagateInsertIntSet(b,s,v) are automatically called everytime there is a respective change to the value of an incremental source vari-able.

An interesting type of invariants provided by Comet are combinatorial in-variants (e.g., element, count, and distribute invariants) which maintain re-lationships of a combinatorial nature between input and output variables and

65

their implementations are meant to be highly effective in time and space. Notethat invariants are not allowed to form cycles.

5.3 ConstraintsConstraints in Comet’s CBLS module are objects of classes implementingthe Constraint<LS> interface which is partially shown in Listing 5.4.

1 interface Constraint<LS> {2 Solver<LS> getLocalSolver();3 var{int}[] getVariables();45 var{bool} isTrue();6 var{int} violations();7 var{int} violations(var{int});8 var{int} decrease(var{int});9

10 int getAssignDelta(var{int},int);11 int getAssignDelta(var{int},int,var{int},int);12 int getAssignDelta(var{int}[],int[]);13 int getSwapDelta(var{int},var{int});14 int getSwapDelta(var{int},var{int},var{int},var{int});1516 void post();1718 ...19 }

Listing 5.4: Constraint<LS> interface

This interface mainly requires the implementation of a constraint c to pro-vide:

• a penalty(c) function through the violations() method,

• a conflict (c) function through the violations(x) method and

• differentiation functions for assign(x,v) and swap(x,y) moves, basically throughthe getAssignDelta(x,v) and getSwapDelta(x,y) methods. Should notbe confusing to have more than one method for both δ-assign(c) and δ-swap(c)

functions (Lines 10 to 14) as they are just useful overloaded methods con-sidering more than one variable or pair of variables simultaneously in therespective move.

Other methods required by the interface include:

• a getVariables() method to get the vars(c) variables,

• a isTrue() method to check wether the constraint is satisfied under thecurrent configuration , and

• the method post() for adding a constraint to a constraint system.

66

The method decrease(x) has the same semantics as the method violations

(x) and returns the maximum decrease in the constraint’s penalty by assigningthe incremental variable x to any other value in its domain.

5.4 Constraint SystemsIn Comet, it is possible to combine simpler constraints and build complexones through constraint combinators. As this feature is fundamental, thereexist several kinds of constraint combinator and all of them give as a result aconstraint complying with the Constraint<LS> interface (often allowing forgeneric solution approaches). For instance, simpler constraints can composecomplex ones using logical connectives or a constraint system.

A constraint system is a composite type of constraint formed by a con-junction of individual constraints added to it using the post method. Since aconstraint system is essentially a conjunction of constraints:

• the penalty of a constraint system is equal to the sum of penalties of theconstituent individual constraints posted into it, and

• the same hold for the constituent variables.

A constraint system is thus an appropriate tool to implement a CBLS modelL where

penaltyL (k) =∑c∈C

penalty(c)(k)

for a current configuration k and, similarly, a variable x ∈ vars(c)

conflictL (x, k) =∑c∈C

conflict (c)(x, k)

Note constraint systems are constraints themselves and therefore it suf-fices, for example, to query the isTrue method in order to check whetherthe CSP is satisfied (which normally means to check if penaltyL (k) = 0).Likewise, given a participating variable x, the violations(x) method givesconflictL (x, k) for a current configuration k. It is worthwhile to rememberhere that the penalty of a single constraint is not necessarily equal to the sumof the conflicts of its individual variables.

Notice that since constraint systems fully implement the Constraint<LS>

interface, they are also differentiable objects and therefore can assess the localsearch procedures evaluating the impact of making a move. A key advantage isthat the system’s architecture allows these queries to be performed in constanttime.

67

Actually, constraint systems do not only implement the Constraint<LS>

interface but moreover enhance it with methods that allow one individualaccess to the constituent constraints. For example,

• the getRange() method returns the range of constraints;

• the getConstraint(i) method returns the constraint of index i within theconstraint system; and

• the getCstrViolations() method returns an array with the penalties of allthe constituent constraints.

The most important aspect of constraint systems is that they allow one tocombine all kinds of heterogeneous constraints in a transparent fashion. Theyalso provide a transparent way of adding constraints into the model (with-out affecting the search component). Constraint systems are fundamental con-straint combinators and thereby a constraint system for set constraints wasimplemented before starting with the experiments. This implementation is de-scribed in Chapter 6.

5.5 Generic Search ProceduresComet’s selectors allow one to choose an element from a set or a range eitherrandomly or according to a probability distribution or evaluation function.Moreover, the selection can be done so that only elements satisfying a setof given conditions are considered for selection. Selectors automate (someof the) tedious aspects of local search algorithms and hence greatly simplifythe process of expressing search heuristics. Furthermore, as they expose thestructure of search algorithms, they facilitate the creation of generic searchprocedures. There are different levels of determinism in Comet’s selectors:

• Level 1: selectFirst and selectCircular are deterministic selectors.The former selects the lexicographically smallest element, and the latter isa selector with state which offers a more diversified selection as it considerselements in a circular way in successive executions.

• Level 2: selectMin and selectMax which select the respectively the min-imum and maximum element according to an evaluation function. Theyintroduce some randomness as ties are broken randomly and they give alsothe option of selecting at random among the k smallest or largest elements.

• Level 3: select and selectPr are completely randomized selectors. Theformer selects uniformly at random while the latter selects according toprobability density function.

Finally, it is worth to mention that Comet also provides neighbour selectorsto select moves when neighborhoods are composed of several different sub-neighborhoods.

68

Part III:

Adding Set Constraints to Comet’sCBLS Back-End

6. Extending the CBLS Back-End ofComet

To the date of writing (July 2011), the last available version of Comet (i.e., theversion chosen for all programs written for the experiments) is 2.1 (releasedon April 2010). In this version, set constraints are (unfortunately) not sup-ported in the CBLS module. Fortunately, Comet’s invariants do support setvariables and thus it is possible to handcraft set constraints. A major problemarises when becomes necessary to combine set constraints because there is nostraightforward way of doing so (e.g., there is no constraint system supportingset constraints). Comet is an ongoing project and it is evolving over the years(for example, on June of this year it was announced that “Comet 2.2 is com-ing”). The author who is writing this document does not known whether ornot the new release will bring any extensions for the CBLS module, howeverthis thesis does require an extension of Comet 2.1 before writing the code forthe experiments. This chapter describes such an extension.

6.1 ArchitectureIn order to introduce set constraints to Comet’s CBLS back-end (fortunately)it is only necessary to extend the differentiable objects layer (see Figure 4.1).This is due to the existing incremental set variables and invariants over them.As a result two new features (explained separately in the next two sections)are needed: support for user-defined set constraints and support for a meansto combine such constraints (i.e., one or more constraint combinators). Theprovided constraint combinator is a set constraint system which is a compositetype of set constraint and therefore the key task is to provide support for user-defined set constraints.

Notice although the extension is needed only in one layer, for the experi-ments, programming is actually done in all of the three layers (Figure 6.1):

• the provided invariants are not enough so the implementation of user-definedinvariants (at layer 1) become necessary;

• all the set constraints are (of course) implemented (at layer 2) as user-defined set constraints;

• the search procedures are now driven by set constraints and hence writtenaccordingly (at layer 3).

71

Figure 6.1: Set constraints for Comet’s Constraint-Based local search back-end.

6.2 Set Constraints for Comet’s CBLS Back-EndIn order to define set constraints in Comet’s CBLS module, a new interfacenamed SetConstraint<LS> is defined as shown in Listing 6.1. By design, allset constraints will be required to implement this interface.1 interface SetConstraint<LS> {2 Solver<LS> getLocalSolver();3 var{set{int}}[] getSetVariables();45 var{bool} isTrue();6 var{int} violations();7 var{int} violations(var{set{int}} s);89 int getAddDelta(var{set{int}} s, int v);

10 int getDropDelta(var{set{int}} s, int u);11 int getFlipDelta(var{set{int}} s, int u, int v);12 int getTransferDelta(var{set{int}} s, int u,13 var{set{int}} t);14 int getSwapDelta(var{set{int}} s, int u, int v,15 var{set{int}} t);1617 void post();18 }

Listing 6.1: SetConstraint_LS_.co: SetConstraint<LS> interface.

Note how similar this interface is with respect to the Constraint<LS> in-terface provided by Comet which is shown in Listing 5.4. Basically, the maindifferences are that:

• a constraint c implementing SetConstraint<LS> is defined on var{set{int}}

incremental variables (instead of var{int} incremental variables) and henceis a set constraint;

• the differentiation functions have been replaced with those defined on setvariables, i.e., instead of differentiation functions for assign(x,v) and swap(x,y)

72

moves, the interface require methods implementing the δ-add (c), δ-drop(c),δ-flip(c), δ-transfer (c) and δ-swap(c) functions (Lines 9 to 15). This is be-cause moves (and neighborhoods) for set variables are different from moves(and neighborhoods) for integer variables.

Other differences are that the method decrease(x) is not included (as nopractical purpose has been found to it); and, likewise, there are no overloadedversions of the differentiation functions. This implementation also followsComet’s terminology naming violation to functions implementing constraintmeasures.

One more time analogous to Comet’s design, which requires all user-definedconstraints extend the UserConstraint<LS> class, all set constraints will ex-tend the UserSetConstraint<LS> class which in turn implements the meth-ods defined in the SetConstraint<LS> interface.

The implementation of the UserSetConstraint<LS> abstract class followsin Listing 6.2.

1 include "SetConstraint_LS_";23 abstract class UserSetConstraint<LS>4 implements SetConstraint<LS> {56 Solver<LS> _ls;7 var{bool} _isSatisfied;8 var{int} _zero;9 var{set{int}}[] _empty;

10 bool _posted;1112 UserSetConstraint<LS>(Solver<LS> ls) {13 _ls = ls;14 _zero = new var{int}(_ls) := 0;15 _isSatisfied = new var{bool}(_ls) := true;16 _empty = new var{set{int}}[1..0];17 _posted = false;18 }1920 Solver<LS> getLocalSolver() {21 return _ls; }22 var{set{int}}[] getSetVariables() {23 return _empty; }2425 var{bool} isTrue() {26 return _isSatisfied; }27 var{int} violations() {28 return _zero; }29 var{int} violations(var{set{int}} s) {30 return _zero; }3132 int getAddDelta(var{set{int}} s, int v) {33 return 0; }

73

34 int getDropDelta(var{set{int}} s, int u) {35 return 0; }36 int getFlipDelta(var{set{int}} s, int u, int v) {37 return 0; }38 int getTransferDelta(var{set{int}} s, int u,39 var{set{int}} t) {40 return 0; }41 int getSwapDelta(var{set{int}} s, int u, int v,42 var{set{int}} t) {43 return 0; }4445 void post() {}46 }

Listing 6.2: UserSetConstraint_LS_.co: UserSetConstraint<LS> class.

Basically, this class provides a trivial default implementations for the meth-ods specified by the SetConstraint<LS> interface. This is useful, for exam-ple, to avoid compiler errors when some constraint does not implement oneof the methods defined in the interface (for instance, sometimes it is not nec-essary to implement all of the five differentiation functions). The _posted

member is a flag used when implementing a constraint to ensure that the post

() method is called only once, i.e., the post() method will be executed onlywhen the flag is down (and the flag will be up as soon as the method has beenexecuted for the first time).

Next section presents the implementation of a constraint system on setvariables. However, before moving on, the design and implementation of thePairAtMost1 (X,Y ) set constraint is discussed next as an illustration of howto implement individual constraints. The set constraint system will be used tocombine such individual set constraints.

Recall that given two set variables X and Y , the PairAtMost1 (X,Y ) con-straint is satisfied if and only ifX and Y have at most one element in common.In order to define PairAtMost1 as a differentiable constraint, ℘+

PairAtMost1 , itis necessary to define the components of the triple⟨

penalty(PairAtMost1 ), conflict (PairAtMost1 ),∆(PairAtMost1 )

⟩That is, its constraint measures and also its differentiation functions.

Let us begin with penalty(PairAtMost1 ), this function returns for a config-uration k the number of “extra elements” in the intersection of the two sets.Since the two variables X and Y in vars(PairAtMost1 ) are allowed to haveat most one element in common, any extra element adds 1 to the value ofpenalty(PairAtMost1 )(k). This means:

penalty(PairAtMost1 )(k) = max (1, |k(X) ∩ k(Y )|)− 1

Now, consider conflict (PairAtMost1 ). In this version of the constraint theconflict of a variable in the constraint is equal to the number penalty of the

74

constraint, i.e.,

conflict (PairAtMost1 )(X, k) = conflict (PairAtMost1 )(Y, k)

= penalty(PairAtMost1 )(k)

Recall the penalty of a constraint is not necessarily equal to the sum of con-flicts of the constituent variables.

At last, this version of the constraint properly defines differentiation func-tions for both δ-add (c) and δ-drop(c), and the rest in terms of these first two.δ-add (c) returns 1 if the added element constitutes a new extra element inthe intersection of the two sets; and, likewise, δ-drop(c) returns -1 when thedropped element was an extra element in the intersection of the two sets. Thismeans:

δ-add (c)(k, àdd ) = |(àdd (X) ∩ àdd (Y ))| − |(k(X) ∩ k(Y ))|δ-drop(c)(k, `drop) = |(`drop(X) ∩ `drop(Y ))| − |(k(X) ∩ k(Y ))|

In general, in the context of set variables, the add (S,v) and drop(S,u) movescan be regarded as atomic moves which composed give birth to the othermoves [2]. Indeed, any number of atomic moves may be composed into onemove function called compound move function which is symmetric up to or-dering (for a proof of this proposition see [2]). This notion is briefly formal-ized in the following.

Definition (Atomic and compound move). An atomic move function is eitheradd (S,v) or drop(S,u). Given atomic move functions m1, . . . ,mn, where eachvariable-and-value pair (S, u) is used in at most one atomic move functionmi, the move function M = m1 ◦ . . . ◦mn is a compound move function.

For example, considering the move functions given in Section 3.1.2, theother moves can be defines as:

flip(S,u,v) = add (S,v) ◦ drop(S,u)

transfer (S,u,T ) = add (T,u) ◦ drop(S,u)

swap(S,u,v,T ) = add (T,u) ◦ drop(T,v) ◦ add (S,v) ◦ drop(S,u)

As a result, should not be surprising to see that δ-flip(c), δ-transfer (c) andδ-swap(c) are implemented in terms of δ-add (c) and δ-drop(c). The completeimplementation of this constraint is shown in Listing 6.3.1 include "UserSetConstraint_LS_";23 class PairAtMost1<LS> extends UserSetConstraint<LS> {45 var{set{int}} _s1;6 var{set{int}} _s2;7

75

8 var{int} _penalty;9 var{int} _cardInter;

10 var{set{int}} _inter;1112 PairAtMost1<LS>(var{set{int}} s1, var{set{int}} s2)13 : UserSetConstraint<LS>(s1.getLocalSolver()){14 _s1 = s1;15 _s2 = s2;16 post();17 }1819 var{set{int}}[] getSetVariables() {20 var{set{int}} vars[0..1] = [_s1, _s2];21 return vars;22 }2324 var{int} violations() {25 return _penalty; }26 var{int} violations(var{set{int}} s) {27 return (s === _s1 || s === _s2)? _penalty : _zero; }28 }2930 void PairAtMost1<LS>::post() {31 if(!_posted) {32 _inter = new var{set{int}}(_ls) <- _s1 inter _s2;33 _cardInter = new var{int}(_ls) <- card(_inter);34 _penalty = new var{int}(_ls) <- max(1, _cardInter) - 1;35 _isSatisfied = new var{bool}(_ls) <- _penalty == 0;36 _posted = true;37 }38 }3940 int PairAtMost1<LS>::getAddDelta(var{set{int}} s, int v) {41 if(_cardInter == 0 || member(v, _inter))42 return 0;43 if((s === _s1) && member(v, _s2) ||44 (s === _s2) && member(v, _s1))45 return 1;46 return 0;47 }4849 int PairAtMost1<LS>::getDropDelta(var{set{int}} s, int u) {50 if(_cardInter <= 1)51 return 0;52 if(((s === _s1) || (s === _s2)) && member(u,_inter))53 return -1;54 return 0;55 }5657 int PairAtMost1<LS>::getFlipDelta(var{set{int}} s, int u,58 int v) {59 if(u == v)

76

60 return 0;61 if((s === _s1) || (s === _s2))62 return getDropDelta(s,u) + getAddDelta(s,v);63 return 0;64 }6566 int PairAtMost1<LS>::getTransferDelta(var{set{int}} s,int u,67 var{set{int}} t) {68 if(((s === _s1) && (t === _s2))69 || ((t === _s1) && (s === _s2)))70 return getDropDelta(s, u) + getAddDelta(t, u);71 if((s === _s1) || (s === _s2))72 return getDropDelta(s, u);73 if((t === _s1) || (t === _s2))74 return getAddDelta(t, u);75 return 0;76 }7778 int PairAtMost1<LS>::getSwapDelta(var{set{int}} s, int u,79 int v, var{set{int}} t) {80 if(u == v)81 return 0;82 if((s === _s1) || (s === _s2))83 return getDropDelta(s, u) + getAddDelta(s, v);84 if((t === _s1) || (t === _s2))85 return getAddDelta(t, u) + getDropDelta(t, v);86 return 0;87 }

Listing 6.3: PairAtMost1_LS_.co: Implementation of the PairAtMost1 (X,Y )set constraint.

Note there are four invariants maintained by the constraint:

inter � X ∩ Y

cardInter � |inter |penalty � max(1, cardInter − 1)

isSatisfied � is penalty equal to 0 ? TRUE : FALSE

A set invariant maintains incrementally the intersection between the two setsand another set invariant defined on top of the first one incrementally main-tains the cardinality of the intersection (i.e., the number of elements that bothsets have in common). Similarly, the values for the penalty and state of theconstraint are maintained as invariants. This make the implementation bothsimpler and more efficient.

Finally, note that the PairAtMost1<LS> constraint extends UserSetConstraint<LS> and implements all methods defined by the SetConstraint<LS> inter-

77

face except isTrue (Line 5) and getLocalSolver (Line 2) since it uses theprovided default implementation for them.

6.3 Set Constraint System for Comet’s CBLS Back-EndConstraint combinators are mechanisms to build complex constraints by com-bining simpler ones. A constraint system (as discussed in Section 5.5) is aconstraint combinator (which is a constraint itself) augmented with meth-ods that allow one individual access to the constituent constraints. Moreover,the semantics of a constraint system shows that it is essentially a conjunc-tion of constraints. Generally speaking then, a set constraint system is a setconstraint formed by a conjunction of individual set constraints (which canbe accessed individually). Thus both constraint measures and differentiationfunctions need to be defined for the set constraint system.

The penalty and conflict functions for constraint systems are very closeto the constraint measures of CBLS models. However, (unfortunately) some-times happens that constraint measures are not balanced (e.g., some con-straints may be easier to satisfy than others) and therefore the local search al-gorithm may not get enough guidance from the constraints and perform poorly(e.g., guiding always to local optima). As a result, some times it is necessaryto assign more weight to some specific constraints and therefore a constraintsystem should provide the possibility of posting weighted constraints (as wellas non-weighted constraints which are weighted constraints with weight equalto 1).

A weighted constraint is then simply a constraint c associated with a naturalnumber weight(c) representing its weight (which defaults to 1 as shown inthe constructor on Line 79 in Listing 6.4). The idea is that the penalty of theweighted constraint (which holds every time the corresponding non-weightedconstraint holds) will be the product of weight(c) times the penalty of theoriginal non-weighted constraint. Similarly, for every variable in vars(c), theconflict will be the product of this weight times the conflict of the variable inthe non-weighted constraint.

The constraint measures for a set constraint system S , given a configura-tion k and a variable x ∈ vars(S ), are defined as:

penaltyS (k) =∑

∀c∈cstrs(S )

weight(c) · penalty(c)(k)

conflictS (x, k) =∑

∀c∈cstrs(S )

weight(c) · conflict (c)(x, k)

where the set of constraints posted to S is referred to by cstrs(S ).

78

Similarly, the differentiation functions for a given move mv is defined as:

δ-mv (S )(k, `) =∑

∀c∈cstrs(S )

weight(c) · δ-mv (c)(k, `)

The complete implementation of the set constraint system for Comet’sCBLS back-end follows in Listing 6.4.

1 include "UserSetConstraint_LS_";23 tuple Weight_Index{int w; int i;}45 class SetConstraintSystem<LS>6 extends UserSetConstraint<LS> {7 //varibles for construction8 dict{int->SetConstraint<LS>} _constraint_;9 dict{SetConstraint<LS>->Weight_Index} _weight_idx_;

1011 dict{int->var{set{int}}} _vars_;12 dict{var{set{int}}->set{SetConstraint<LS>}} _cstrsVars_;1314 //actual variables15 int _ticketCstr;16 SetConstraint<LS>[] _constraint;17 int[] _weight;1819 int _ticketVars;20 var{set{int}}[] _vars;21 dict{var{set{int}}->int} _mapVar;22 set{int}[] _cstrsVars;2324 //invariants25 var{int}[] _cstrsPenalty;26 var{int}[] _conflict;27 var{int} _penalty;2829 SetConstraintSystem<LS>(Solver<LS> ls)30 : UserSetConstraint<LS>(ls) {31 _ticketCstr = 0;32 _constraint_ = new dict{int->SetConstraint<LS>}();33 _weight_idx_ = new dict{SetConstraint<LS>->34 Weight_Index}();35 _ticketVars = 0;36 _cstrsVars_ = new dict{var{set{int}}->37 set{SetConstraint<LS>}}();38 _vars_ = new dict{int->var{set{int}}}();39 _mapVar = new dict{var{set{int}}->int}();40 }4142 var{set{int}}[] getSetVariables(){ return _vars; }4344 range getRange(){ return 1.._ticketCstr; }

79

45 SetConstraint<LS> getSetConstraint(int k) {46 return _constraint[k]; }47 var{int}[] getSetCstrViolations(){48 return _cstrsPenalty; }4950 //constraint measures51 var{int} violations(){ return _penalty; }52 var{int} violations(var{set{int}} s){53 return _conflict[_mapVar{s}]; }5455 //differentiation functions56 int getAddDelta(var{set{int}} s, int v){57 return sum(c in _cstrsVars[_mapVar{s}])58 _weight[c] * _constraint[c].getAddDelta(s,v); }59 int getDropDelta(var{set{int}} s, int u){60 return sum(c in _cstrsVars[_mapVar{s}])61 _weight[c] * _constraint[c].getDropDelta(s,u); }62 int getFlipDelta(var{set{int}} s, int u, int v){63 return sum(c in _cstrsVars[_mapVar{s}])64 _weight[c] * _constraint[c].getFlipDelta(s,u,v); }65 int getTransferDelta(var{set{int}} s, int u,66 var{set{int}} t) {67 return sum(c in _cstrsVars[_mapVar{s}])68 _weight[c] * _constraint[c].getTransferDelta(s,u,t) +69 sum(c in _cstrsVars[_mapVar{t}])70 _weight[c] * _constraint[c].getTransferDelta(s,u,t); }71 int getSwapDelta(var{set{int}} s, int u,72 int v, var{set{int}} t) {73 return sum(c in _cstrsVars[_mapVar{s}])74 _weight[c] * _constraint[c].getSwapDelta(s,u,v,t) +75 sum(c in _cstrsVars[_mapVar{t}])76 _weight[c] * _constraint[c].getSwapDelta(s,u,v,t); }7778 //add constraints to the constraint system79 void post(SetConstraint<LS> c) { post(c, 1); }80 void post(SetConstraint<LS> c, int w);8182 void close(); //to create invariants83 }8485 void SetConstraintSystem<LS>::post(SetConstraint<LS> c,86 int w) {87 int ticketCstr = ++_ticketCstr;88 _constraint_{ticketCstr} = c;89 _weight_idx_{c} = Weight_Index(w,_ticketCstr);9091 var{set{int}}[] cVariables = c.getSetVariables();92 forall(i in cVariables.getRange())93 if(!_cstrsVars_.hasKey(cVariables[i])) {94 int ticketVar = ++_ticketVars;95 _vars_{ticketVar} = cVariables[i];96 _mapVar{cVariables[i]} = ticketVar;

80

97 _cstrsVars_{cVariables[i]} = {c};98 }99 else

100 _cstrsVars_{cVariables[i]}.insert(c);101 }102103 void SetConstraintSystem<LS>::close() {104 //create actual variables and close the system105 range _Cstrs = 1.._ticketCstr;106 _constraint = new SetConstraint<LS>[_Cstrs];107 _weight = new int[_Cstrs];108 forall(i in _Cstrs) {109 _constraint[i] = _constraint_{i};110 _weight[i] = _weight_idx_{_constraint[i]}.w;111 }112113 range _Vars = 1.._ticketVars;114 _vars = new var{set{int}}[_Vars];115 _cstrsVars = new set{int}[_Vars];116 forall(i in _Vars) {117 _vars[i] = _vars_{i};118 set{int} cstrs();119 forall(cstr in _cstrsVars_{_vars[i]})120 cstrs.insert(_weight_idx_{cstr}.i);121 _cstrsVars[i] = cstrs;122 }123124 //should no longer be used125 _weight_idx_ = null;126 _constraint_ = null;127 _vars_ = null;128 _cstrsVars_ = null;129130 //create invariants131 _cstrsPenalty = new var{int}[i in _Cstrs](_ls)132 <- (_weight[i]) * (_constraint[i].violations());133 _penalty = new var{int}(_ls)134 <- sum(i in _Cstrs) _cstrsPenalty[i];135136 _isSatisfied = new var{bool}(_ls) <- _penalty == 0;137138 int[][] w = all(i in _Vars) (all(c in _cstrsVars[i]) c);139 var{int}[][] v = all(i in w.getRange())140 (all(j in w[i].getRange()) (141 _constraint[w[i][j]].violations(_vars[i])));142 _conflict = new var{int}[i in _Vars](_ls)143 <- sum(j in v[i].getRange()) v[i][j] * _weight[w[i][j]];144 }

Listing 6.4: SetConstraintSystem_LS_.co: SetConstraintSystem<LS>

class.

81

Both the variables defined for construction purposes (Lines 8 to 12) andthe new close() method require an explanation. The difficulty is that, on theone hand, in Comet, by design, an array is always associated with a rangewhich specifies the valid indices for retrieving or modifying array entries. Therange of an array is thus specified at its creation and cannot be modified later(indeed ranges are, in general, immutable objects). As a consequence, no newrange can be given as a valid indexing structure of the array and thus an arraycannot be extended or reduced in size. On the other hand, it is not good to fixthe number of set constraints that can be posted to a set constraint system. Thedesirable behavior is that the user can post as many constraints as he or shewants.

One solution is to use one of the alternative data structures provided byComet that support the required functionality such as set, stack or queue.For example, an implementation using Comet’s dictionaries (dict) is verystraightforward but the run-time performance is lower than expected. Anotherseemingly good alternative is using stacks as they offer instant array-like ac-cess. However, there is no way to know for sure if stacks are implemented asarrays (or, for instance, as linked lists instead): Comet’s source code is notavailable to the public.

The solution given here is to use dictionaries at construction time (i.e., whileposting the constraints) and later require the user to call the close() methodbefore starting to query the set constraint system. Hence the dictionaries de-clared for construction purposes. When the close() method is called the ac-tual variables, i.e., the arrays, are created from the dictionaries. Nevertheless,the purpose of the close() method goes beyond this preprocessing of vari-ables: it also initialized all of the invariants. The drawback of this approach isthat a user will not be able to add set constraints to the set constraint system dy-namically, for example, during search. The big advantage is the performancegained by array access.The invariants maintained by the constraint are:

∀v ∈ vars(S ) : conflict [v] �∑∀c∈C(v)

weight(c) · conflict (c)(v)

where C(v) = {x ∈ cstrs(S ) | v ∈ vars(x)}∀c ∈ cstrs(S ) : cstrsPenalty [c] � weight(c) · penalty(c)

penalty �∑

∀c∈cstrs(S )

cstrsPenalty [c]

state � penalty = 0?satisfied : not-satisfied

which basically maintain incrementally the constraint measures of the set con-straint system.

Since this chapter was closely related to Comet, all the source code wasgiven within the chapter. From the next chapter, where the explanations of the

82

experiments begin, all the source code is given in the appendices. Finally, be-fore starting with the experiments, and to close this chapter, an application ofthe set constraint system is shown by solving Kirkman’s schoolgirl problem.

In 1850, the Reverend Thomas P. Kirkman (Bolton 1806 – 1895 Bowdon)posed the question [5]:

Fifteen young ladies in a school walk out three abreast for sevendays in succession: it is required to arrange them daily so that notwo walk twice abreast.

This problem is equivalent to schedule fifteen golfers into five groups ofthree players over seven weeks. This means Thomas Kirkman’s SchoolgirlProblem is equivalent to golf-5-3-7. The problem is solved in the contextof the set-CSP given in Section 1.3. Both partition and cardinality constraintswill be implicit as they will be satisfied by the initial configuration and swapmoves will be selected such that these constraints are preserved during localsearch.

A complete working implementation for this problem is shown in List-ing 6.5 which features a tabu-search meta-heuristic enhanced with an aspi-ration criterion, intensification and restarts. This section aims to illustrate anddescribe the implementation of a solution to a problem using the extendedComet’s CBLS back-end, the Social Golfer Problem is discussed in moredetail next in Chapter 7.1 import cotls;23 include "SetConstraintSystem_LS_";4 include "PairAtMost1_LS_";56 int nbGolfers = 15;7 int nbGroups = 5;8 int nbWeeks = 7;9

10 range Golfers = 1..nbGolfers;11 range Groups = 1..nbGroups;12 range Slots = 1..(nbGolfers/nbGroups);13 range Weeks = 1..nbWeeks;1415 ///MODEL16 Solver<LS> m();1718 var{set{int}} group[Weeks,Groups] = new var{set{int}}(m);19 SetConstraintSystem<LS> cs(m);20 forall(i in Weeks, j in Groups,21 k in Weeks, l in Groups : i < k)22 cs.post(PairAtMost1<LS>(group[i, j], group[k, l]));23 cs.close();2425 m.close();26

83

27 ///SEARCH28 Counter it(m,0);29 Integer t0(0);30 Integer nbRestarts(0);31 Integer nbRestores(0);3233 function void init(range Weeks, range Golfers, range Groups,34 range Slots, var{set{int}}[,] group){35 forall(w in Weeks){36 RandomPermutation perm(Golfers);37 forall(g in Groups){38 set{int} golfers = group[w,g];39 forall(e in golfers.copy())40 group[w,g].delete(e);41 forall(k in Slots)42 group[w,g].insert(perm.get());43 }44 }45 }4647 init(Weeks,Golfers,Groups,Slots,group);4849 var{int} violations = cs.violations();50 var{int} groupViolations[w in Weeks, g in Groups] =51 cs.violations(group[w, g]);5253 //Meta-heuristics54 Integer tabuLength(20);55 Integer tabu[Weeks,Golfers,Golfers](-1);5657 forall(w in Weeks, g in Groups) {58 whenever group[w,g]@remove(int s1)59 when group[w,g]@insert(int s2)60 tabu[w,s1,s2] := it + tabuLength;61 }6263 Integer minViolations(0) := violations;64 Solution bestSolution[1..1](m);65 Counter improvingSteps(m,0);66 Counter nonImprovingSteps(m,0);67 int maxNonImprovingSteps = 1000;68 int restartFreq = 20000;6970 function void shake(range Weeks, range Groups,71 var{set{int}}[,] group,72 var{int}[,] groupViolations) {73 forall(i in Weeks)74 select(w in Weeks)75 forall(j in Groups)76 select(g1 in Groups : groupViolations[w,g1] > 0,77 g2 in Groups : g1 != g2,78 e1 in group[w,g1], e2 in group[w,g2]) {

84

79 group[w,g1].delete(e1); group[w,g1].insert(e2);80 group[w,g2].delete(e2); group[w,g2].insert(e1);81 }82 }8384 whenever nonImprovingSteps@changes(int oldV, int newV) {85 if(oldV > maxNonImprovingSteps) {86 bestSolution[1].restore();87 shake(Weeks,Groups,group,groupViolations);88 forall(w in Weeks, g1 in Golfers, g2 in Golfers)89 tabu[w,g1,g2] := -1;90 minViolations:= violations;91 nonImprovingSteps := 0;92 nbRestores++;93 }94 }9596 whenever improvingSteps@changes() {97 bestSolution[1] = new Solution(m);98 minViolations := violations;99 nonImprovingSteps := 0;

100 }101102 whenever it@changes() {103 if((it % restartFreq == 0) && (minViolations > 0)) {104 with delay(m)105 init(Weeks,Golfers,Groups,Slots,group);106 minViolations := violations;107 bestSolution[1] = new Solution(m);108 forall(w in Weeks, g1 in Golfers, g2 in Golfers)109 tabu[w,g1,g2] := -1;110 nbRestarts++;111 }112 }113114 //Heuristic115 t0 := System.getCPUTime();116 while(violations > 0) {117 selectMin(w in Weeks,118 g1 in Groups: groupViolations[w,g1] > 0,119 g2 in Groups: g2 != g1,120 s1 in Golfers: member(s1, group[w,g1]),121 s2 in Golfers: member(s2, group[w,g2]),122 delta = cs.getSwapDelta(group[w,g1], s1,123 s2, group[w,g2]):124 (tabu[w,s1,s2] < it ||125 violations + delta < minViolations))126 (delta) {127 group[w,g1].delete(s1); group[w,g2].insert(s1);128 group[w,g2].delete(s2); group[w,g1].insert(s2);129130 if(violations < minViolations)

85

131 improvingSteps++;132 else133 nonImprovingSteps++;134135 it++;136 }137 }138139 int t2 = System.getCPUTime() - t0;140 cout<<endl<<"Solution found!"<<endl141 <<"violations: "<<violations<<endl142 <<" time: "<<t2<<"ms. ("<<t2/1000<<" sec.)"<<endl143 <<"iterations: "<<it<<endl144 <<"# restores: "<<nbRestores<<endl145 <<"# restarts: "<<nbRestarts<<endl;

Listing 6.5: kirkmans-schoolgirl.co: CBLS for Thomas Kirkman’sSchoolgirl Problem.

The programs developed for the experiments (provided in the appendices)follow the same structure of this program. The code, after the import andinclude instructions, is structured in four parts:

• Part 1: input (Lines 6 to 13), to collect and setup the input for the problem(e.g., in this case the input is hardcoded, but in most cases the input is gottenfrom the command line or a file);

• Part 2: model (Lines 16 to 25), to specify the model of the problem (i.e., topost the chosen constraints);

• Part 3: search (Lines 28 to 137), to specify the local search algorithm (i.e.,the heuristics and meta-heuristics); and

• Part 4: output (Lines 139 to 145), to collect and provide the solution of theproblem (if any) (e.g., in this case only a success message is given in thescreen, in other cases, for instance, the output is written to a file).

Notice the search part is actually further divided in two parts, one for theheuristic and another for the meta-heuristics. This clear program structurewith a nice separation of concerns is possible thanks to Comet’s architecture(depicted in Figure 4.1) and the events mechanism provided by the Comet’slanguage.

The extended Comet’s CBLS back-end can be seen in action in the mod-eling part. A set constraint system (developed in Section 6.3) is declared inLine 19, then all the PairAtMost1 constraints are posted to it in Line 22 andthen it is finally closed in the next line.

The search part starts assigning a random initial configuration to the incre-mental variables in Line 47 using the function defined in Line 34. The init

function basically initializes groups of size 3 within each week to random val-ues that it gets from a generated random permutation of the golfers. This wayboth cardinality and partition constraints hold in the initial configuration.

86

Next, the meta-heuristics are specified through events.

• First, a tabu list of length 20 is maintained. This tabu list is based on tuplesof the form 〈w, g1, g2〉 indicating that swapping the two golfers g1 and g2in week w is tabu. In order to forbid the swapping of such pair of golfers,an entry in tabu[w,g1,g2] represents the earliest iteration it from whichgolfers s1 and s2 will no longer be tabu in week w.

• Second, the so far best solution configuration is kept in a variable of typeSolution together with its penalty value stored in the minViolations vari-able. Whenever a better solution is found, both the so far best solution andthe value of minViolations are updated. Then, during search, if swappingtwo golfers would lead to a a better solution than the so far best solution,the move is carried on regardless of its tabu status. That is, in effect, anaspiration criterion.

• Third, the so far best solution is also useful to perform intensification mak-ing the search return to it after maxNonImprovingSteps iterations. More-over, this intensification component also introduces some degree of ran-domization to ensure that a different search path is followed after each re-turn to the best solution found so far. Hence, just after restoring the so farbest solution in Line 86 the shake function (defined in Line 70) is invoked.This function basically make some swap moves randomly.

• Finally, as a last resource, a diversification component is implemented throughrestarts to direct the search towards other regions of the search space if nec-essary. After restartFreq iterations, a new initial configuration is givencalling the init function (and the tabu list is reset to start again with thesearch).

The heuristic consists in selecting two different golfers from two differentgroups (one of the groups must be in conflict, i.e., have at least one elementviolating the constraint that two elements are in the same group at most once)in the same week, such that swapping the two golfers gives the minimum in-crease in the penalty value by performing the move. A swap move is thenperformed by deleting and inserting the corresponding elements on the se-lected groups (note deletion always need to be performed before insertionwhen swapping due to way the events have been defined).

An important aspect of the heuristic is that swap moves consider only golferswithin the same week. As a result the partition and cardinality constraints(which hold initially) will never be violated making these constraints hard.The random moves performed by the shake function also have this property.

The search procedure iterates under this heuristic and meta-heuristics untila solution is found (i.e., until the value of the penalty is zero). Since the so-lution to this problem is known to exist (and not being particularly hard) thisrepresents no problem. However, many times the search procedure iterates un-

87

Set modelinstance time (miliseconds) iterations iterations per second rest-g-s-w average min. max. std.dev. average min. max. std.dev. average min. max. std.dev. ores/arts

5-3-7 143156.64 2545 502645 122444.94 16843.52 266 60114 14503.54 116.71 104.52 126.76 5.59 640/105-4-5 12626.48 610 53488 13887.42 1848.80 36 7741 2110.17 129.53 59.02 171.69 27.57 64/05-5-6 124437.08 7598 672694 135792.52 2148.40 129 11773 2374.88 17.13 16.29 18.30 0.60 72/0

Table 6.1: Run-time (in milliseconds), number of iterations, and rate of iterations persecond for the set approach to Kirkman’s Schoolgirl Problem.

til some allocated resource is exhausted (such as running time or number ofiterations) or even until a good enough configuration has been found.

Notice the program presented in Listing 6.5 is actually a general implemen-tation that may work for any instance of the Social Golfer Problem (not onlygolf-5-3-7). However, one drawback is the pairwise approach that impliesthe use of many PairAtMost1 constraints in the model.

Performance for this program is presented in Table 6.1 for 3 instances ofthe Social Golfer Problem (the first one corresponds to Kirkman’s SchoolgirlProblem) in terms of run-time (in milliseconds), number of iterations and rateof iterations per second. All values are computed over 25 (successful) runs.The last column shows the number of times the algorithm had to restore theso-far best solution or actually restart. A better performance can be achieved,for example, using a “tournament” constraint as explained in the next chapter.

Solving Kirkman’s Schoolgirl Problem is also equivalent to finding a Kirk-man triple system of order 15, i.e., a resolution of some Steiner triple systemof order 15 [5]. The existence of Kirkman triple systems was a celebratedopen problem throughout the period 1850–1970. In general, it is curious tosee how combinatorial problems can be so hard to solve even though they canbe formulated so concisely.

88

Part IV:

Effect of Set Variables and Set Constraintsfor CBLS

7. The Social Golfer Problem(golf-g-s-w)

The well-known social golfer problem1 has attracted significant interest sinceit was posted for the first time on sci.op-research in May 1998 [8]. Itcan be formulated concisely:

In a local golf club, g · s golfers meet every week to play golf ing groups of the same size s: schedule a tournament over w weekssuch that two different golfers play in the same group at mostonce.

An instance of this problem is denoted by golf-g-s-w and specified bya triplet 〈g, s, w〉. For example, a solution to golf-5-3-7 is given in Table7.1 where groups are modeled using sets of integers.

The original question (back in 1998) was to determine for how many weeks(the more the better) can 32 = g · s golfers be scheduled playing in groups ofsize 4 = s (so that no two golfers play in the same group more than once).As there is no solution to golf-8-4-11, the challenge was actually to finda solution to golf-8-4-10 (a particularly hard problem).

Even though the social golfer problem still draws attention since, for exam-ple, it has become a standard benchmark for evaluating symmetry-breakingtechniques, a classical tabu-search meta-heuristic is used here without incor-porating any symmetry-breaking schemes.

1CSPLib is a library of test problems for constraint solvers and the Social Golfer Problem isproblem number 10 at http://www.csplib.org/

Weeks Group 1 Group 2 Group 3 Group 4 Group 5Week 1 {1, 3, 13} {4, 10, 14} {6, 7, 9} {11, 12, 15} {2, 5, 8}Week 2 {1, 5, 11} {2, 4, 9} {7, 14, 15} {3, 10, 12} {6, 8, 13}Week 3 {1, 9, 14} {3, 5, 6} {4, 8, 12} {2, 7, 11} {10, 13, 15}Week 4 {1, 7, 12} {5, 13, 14} {2, 6, 15} {8, 9, 10} {3, 4, 11}Week 5 {1, 4, 6} {5, 7, 10} {2, 12, 13} {3, 9, 15} {8, 11, 14}Week 6 {1, 2, 10} {4, 5, 15} {9, 11, 13} {3, 7, 8} {6, 12, 14}Week 7 {1, 8, 15} {5, 9, 12} {4, 7, 13} {2, 3, 14} {6, 10, 11}

Table 7.1: A solution to the social golfer problem with g = 5, s = 3 and w = 7

91


7.1 The ExperimentThe experiment aims to demonstrate, by solving several instances of this prob-lem, that the effect of set variables for CBLS is not only a convenience forfaster and higher-level modeling but it could also lead to better search heuris-tics requiring less search time.

Two different approaches are compared: one using an integer model of theproblem and the other using a set model of the problem. The implementationfor a CBLS solution to the integer model was taken from [1] and correspondsto the one in [27] and the implementation for the CBLS solution to the setmodel was developed from scratch.

7.1.1 ModelThe social golfer problem is modeled both as a CSP and a set-CSP. TheSocialTournament constraint (abbreviated as S .T .) is introduced as in [8].Then a new version of this constraint, named GlobalAtMost1 , is defined forthe set approach.

7.1.1.1 CSPLet us take natural numbers to represent golfers

U = {n | n ∈ N ∧ 1 ≤ n ≤ g · s} = [1, g · s]

Given:

• a set of groups indexed by Ng = [1, g],

• a set of weeks indexed by Nw = [1, w], and

• slots indexed by Ns = [1, s]

the CSP for golf-g-s-w is given by:

• V ={M(m,n,n) | m ∈ Nw, n ∈ Ng ∧ n ∈ Ns

};

• D = U ; and

• C = {SocialTournament(Nw,Ng,Ns, U, V )}where M(m,n,n) denotes the golfer playing in week m, group n, and slot n ofgroup n. Note a group has as many slots as the fixed size of each group. In themodel, the group size (known in advance) is kept as an implicit (cardinality)constraint as well as the requirement that each golfer plays (exactly) once perweek (i.e., partition constraint). This means that in the initial configuration allgroups will have the same size s and also all the g · s golfers will play onceper week. Local moves will ensure these implicit constraints always hold.

The constraint measures for the SocialTournament constraint are given bythe functions conflict (S .T .) : V × K → N and penalty(S .T .) : K → N asdefined in [1] such that:

92

• given a golfer a = M(m,n,n) and a configuration k, conflict (S .T .)(a, k) isequal to the number of golfers placed in slots different from n of group nduring week m that golfer a meets in weeks other than m; for example,if a is together with b and c in group g during week m, the violation forM(m,n,n) under k is 1 if a meets either b or c in another week, 2 if a meetsboth b and c in any other weeks, and zero otherwise.

• given a configuration k, penalty(S .T .) associates to k the sum, over all pairof golfers, of the number of times a pair is placed in the same group afterthe first allowed time happens. For instance, if two golfers appear in thesame group three times, then it counts as two violations; if they are eithernot grouped at all or grouped only once, then it counts as zero violations.

7.1.1.2 SocialTournament ConstraintGiven two golfers a and b, and a configuration k; let us denote by #k(a, b) thenumber of times a and b meet according to k, i.e,

#k(a, b) =∣∣{(w, g) | ∃p, p′ : k

(M(w,g,p)

)= a ∧ k

(M(w,g,p′)

)= b}∣∣

In order to define the constraint measures for this constraint, it is necessaryto count the number of times a and b meet beyond their allowed meeting. Letus denote this number by #′k(a, b), hence:

#′k(a, b) = max (0,#k(a, b)− 1)

as this value is actually incrementally maintained by an invariant and could beused in the search heuristic.

The conflict function gives then for a variable M(w,g,s) and a configurationk the number of golfers placed in slots different from s of group g during weekw that golfer k

(M(w,g,s)

)meets in weeks other than w, i.e,

conflict (S .T .)

(M(w,g,s), k

)=∑p 6=s

[#′k(k(M(w,g,s)

), k(M(w,g,p)

))6= 0]

where [·]2 is defined as [x] =

{1, if true = x

0, otherwiseused with reification pur-

poses. Likewise, the penalty function gives for a configuration k the numberof times any two golfers are placed in the same group after the first allowedtime:

penalty(S .T .) (k) =∑

a<b∈U#′k(a, b)

The only differentiation function defined here for the SocialTournamentconstraint is δ = δ-swap(S .T .) which given a configuration k gives the in-

2known as the Iverson bracket

93

crease in penalty(S .T .) by swapping two golfers a = k(M(w,g1,s1)

)and

b = k(M(w,g2,s2)

)of different groups (g1 6= g2) of the same week w (so

that a = `(M(w,g2,s2)

)and b = `

(M(w,g1,s1)

)in the new configuration `).

The value δ can be computed as follows:

δ =∑s∈

Ns\{s1}

([#k

(b, k

(M(w,g1,s)

))≥ 1]−[#k

(a, k

(M(w,g1,s)

))≥ 2])

+

∑s∈

Ns\{s2}

([#k

(a, k

(M(w,g2,s)

))≥ 1]−[#k

(b, k

(M(w,g2,s)

))≥ 2])

When #k(a, c) ≥ 1 golfers a and c already play together at least once,so placing golfer a in the same group as c will increase the penalty by 1.Similarly, when #k(b, c) ≥ 2 golfers b and c already contribute at least oneto the penalty value. Thereby, replacing b with a will reduce the number oftimes b and c play together and consequently decrease the penalty by 1. As theeffect in both cases is plus/minus one, both conditions are reified to computethe effect on the increase δ.

7.1.1.3 Set-CSPA set-CSP for the Social Golfer problem was already given in Section 1.3 in-spired in [27]. However, the pairwise approach adopted when posting manyPairAtMost1 constraints decreases the performance of the local search al-gorithm. Thus such a model is not competitive with the CSP given in Sec-tion 7.1.1.1 where the SocialTournament constraint serves as a global con-straint. This can be illustrated with the following example. Consider threegroups of size 3: group1 = {g1, g2, g4}, group2 = {g2, g3, g4} and group3 ={g2, g4, g5}. Clearly,

|group1 ∩ group2| = |{g2, g4}| = 2|group2 ∩ group3| = |{g2, g4}| = 2|group3 ∩ group3| = |{g2, g4}| = 2

which means the two golfers g2 and g4 play in the three groups. As they shouldplay in at most one group, this should count as two violations for the pair, butunfortunately this would count as three (= 3 · (2 − 1)) violations instead. Inthis case, the impact of overestimation is a poorer drive of the local search. Asa result, a new GlobalAtMost1 constraint is defined with this issue in mind,and the new set-CSP for golf-g-s-w is hence given by:

• V ={S(w,g) | w ∈ Nw, g ∈ Ng

};

• D = P(U); and

• C = {GlobalAtMost1 (Nw,Ng, U, V )}

94

where

• Ng = [1, g] is a set indexing the groups,

• Nw = [1, w] is a set indexing the weeks, and

• U is the set of golfers represented by natural numbers (i.e, U = Ng·s).

In the model, a set S(w,g) denotes the group of golfers playing together asgroup g in week w. Note that even though |Nw| = w and |Ng| = g, sometimesw and g are used to represent any element of the sets Nw and Ng respectively(rather than the last elements of the cardinalities of these sets).

While both partition and cardinality constraints are implicit in this problem,the GlobalAtMost1 constraint ensures that no two golfers meet in the samegroup more than once.

The constraint measures for the GlobalAtMost1 constraint are given by thefunctions conflict (GlobalAtMost1) : V ×K → N and penalty(GlobalAtMost1) :K → N such that:

• given a group s = S(w,g) and a configuration k, conflict (GlobalAtMost1)(s, k)is equal to the sum of the number of pairs of golfers inside the group thatare in conflict. Two golfers inside a group are said to have (and hence eachof them to be in) a conflict if they meet again in another group (in anotherweek). If a group has two members who have a conflict, the group has beenviolated and thereby the group is called a violated group;

• given a configuration k, penalty(GlobalAtMost1) associates to k the sum, overall groups, of the number of conflicts for each pair of golfers inside eachgroup. Note the number of conflicts for a pair of golfers is actually thenumber of groups where they play together in addition to the allowed one.

Finally note that, comparing with the CSP given in Section 7.1.1.1, whenusing sets for modeling there is no notion of slot. Also notice that both CSPand set-CSP feature one single constraint and therefore no constraint combi-nator is required in the implementation.

7.1.1.4 GlobalAtMost1 Set ConstraintGiven two golfers a and b, and a configuration k; let us denote bymk(a, b) theset of groups where golfers a and b meet according to k over all weeks, i.e,

mk(a, b) ={

(w, g) | a ∈ k(S(w,g)

)∧ b ∈ k

(S(w,g)

)}These sets are incrementally maintained by an invariant and hence they

could be used in the search heuristic. Since for any pair of golfers a and b itis desired that

∣∣m(a,b)

∣∣ ≤ 1, a group is called violated whenever it has twomembers a and b such that

∣∣m(a,b)

∣∣ > 1.

95

The conflict function gives for a variable S(w,g) and a configuration k thesum of the number of conflicts for each pair of golfers inside the group, i.e,

conflict (AtMost1 )

(S(w,g), k

)=

∑a<b∈

k(S(w,g))

|mk(a, b) \ {(w, g)}|

where GlobalAtMost1 is abbreviated AtMost1 and (as previously stated) twogolfers are said to have a conflict if they meet again in another group (inanother week).

Closely related, the penalty function gives the sum over all groups (w, g) ofthe number of conflicts of each pair of golfers inside each group, i.e,

penalty(AtMost1 )(k) =∑w∈Nw,g∈Ng

∑a<b∈

k(S(w,g))

∣∣m(a,b) \ {(w, g)}∣∣

The only differentiation function defined here for the GlobalAtMost1 con-straint is δ = δ-swap(AtMost1 ) which given a configuration k gives the in-crease in penalty(AtMost1 ) by swapping two golfers u ∈ k

(S(w,g1)

)and

v ∈ k(S(w,g2)

)of different groups, g1 6= g2, of the same week w (so that

u ∈ `(S(w,g2)

)and v ∈ `

(S(w,g1)

)in the new configuration `).

This value δ can be computed as the sum of the difference in violations byreplacing golfer u with golfer v in S(w,g1) plus the difference in violations byreplacing golfer v with golfer u in S(w,g2) in the current configuration k, i.e,

δ =∑s∈

k(S(w,g1))\{u}

([∣∣m(v,s)

∣∣ ≥ 1]−[∣∣m(u,s)

∣∣ ≥ 2])

+

∑s∈

k(S(w,g2))\{v}

([∣∣m(u,s)

∣∣ ≥ 1]−[∣∣m(v,s)

∣∣ ≥ 2])

If a pair of golfers x and y already play together in at least one group,then placing golfer x in the same group as y will increase the penalty by one.Likewise, if the pair of golfers x and y already contribute at least one violationto the total, the penalty is reduced by one when placing golfer x in the samegroup as y. As the effect in both cases is plus/minus one, both conditions arereified to compute the effect on the increase δ.

7.1.1.5 Link between the GlobalAtMost1 and the SocialTournamentConstraintsThe essence of both the GlobalAtMost1 and the SocialTournamentconstraints is the same. Recall that, on the one hand, #k(a, b) denotes thenumber of times golfers a and b meet according to k and #′k(a, b) counts

96

the the number of times a and b meet beyond their allowed meeting. On theother hand, mk(a, b) holds the groups a and b meet according to k. Hence|mk(a, b)| = #k(a, b).

The link between these two constraints should be clear analyzing its conflictfunctions. For the set approach, it is defined as:

conflict (AtMost1 )

(S(w,g), k

)=

∑a<b∈

k(S(w,g))

|mk(a, b) \ {(w, g)}|

and gives for a variable S(w,g) and a configuration k the sum of the number ofconflicts for each ordered pair of golfers inside the group, which means:

conflict (AtMost1 )

(S(w,g), k

)=∑p<s

#′k(k(M(w,g,s)

), k(M(w,g,p)

))

7.1.2 Search HeuristicSince the social golfer problem was modeled both as a CSP and a set-CSP,one CBLS algorithm is needed for each approach. The CBLS algorithm forthe integer approach is taken from [8] and based on it a new algorithm isproposed for the set approach.

7.1.2.1 CBLS for the Integer ApproachThe basic idea of the search procedure for the integer approach is:

1 while the SocialTournament constraint is not satisfied2 select two golfers of two different groups in the same week such that

the increase in violations by swapping them is minimum (at least onegolfer should be in conflict inside his/her group).

3 swap these two golfers

which is enhanced with variable-length tabu list, aspiration criteria and restarts.The search heuristic, based in [8], is shown in Figure 7.1. Both the neighbor-hood and the meta-heuristics used by this local search algorithm are explainedbelow as in [8].

7.1.2.1.1 NeighborhoodThe neighborhood of the local search is the set of moves consists of swapsbetween two golfers corresponding to two different groups g1 and g2 in thesame week w:

S(k) ={

swap(M(w,g1,s1),M(w,g2,s2))(k) | g1 6= g2

}Note that the neighborhood is connected since a solution, if one exists, canalways be obtained by swapping golfers in the same week [8]. Restricting the

97

INT-SOCIAL-GOLFERS-LS(Nw,Ng,Ns)1 forall w ∈ Nw

2 tabu[w]← ∅3 k∗ ← k ← initial configuration4 it ← n← 05 maxNonImproving ← 150006 while penalty(S .T .)(k) > 0 ∧ timeout not expired

7 select swap(M(w,g1,s1),M(w,g2,s2))(k) ∈(

SWAPt(V )(k, it) ∪

SWAP∗(V )(k, k∗))

8 minimizing penalty(S .T .)

(swap(M(w,g1,s1),M(w,g2,s2))(k)

)9 τ ← RANDOM([4,20])

10 tabu[w]← tabu[w] ∪{⟨k(M(w,g1,s1)), k(M(w,g2,s2)), it + τ

⟩}11 k ← swap(M(w,g1,s1),M(w,g2,s2))(k)12 if penalty(S .T .)(k) < penalty(S .T .)(k∗)13 k∗ ← k14 n← 015 elseif n > maxNonImproving16 k ← new random configuration17 n← 018 forall w ∈ Nw

19 tabu[w]← ∅20 else21 n← n+ 122 it ← it+ 1

Figure 7.1: CBLS algorithm for the integer approach to the Social Golfer Problem.

attention to swaps involving at least one golfer in conflict with another golferin the same group, the neighborhood becomes:

S′(k) ={

swap(M1,M2)(k) | swap(M1,M2)(k) ∈ S(k)

∧ conflict (S .T .) (M1, k) > 0}

which ensures that the algorithm focuses on swaps which may decrease thenumber of violations. The neighborhood is then:

SWAP (V )(k) ={

swap(M1,M2)(k) | swap(M1,M2)(k) ∈ S′(k)

∧M1,M2 ∈ V }

98

7.1.2.1.2 Meta-HeuristicsFirst, since swaps consider golfers only in the same week, the tabu componentof the algorithm features a variable-length tabu list distributed across the vari-ous weeks. Each week w has an associated tabu list tabu[w], and each of theselists maintains triplets 〈a, b, j〉where a and b are golfers while j represents thefirst iteration where golfers a and b can be swapped again in week w. The tabulist is said to be of variable length because the value of j (i.e, the time a pairof golfers stay in the tabu-list) is dynamically given by a random generatedvalue in the interval [4, 20].

The fact that swapping golfers a and b at iteration it is forbidden is denotedby tabu[w](a, b, it) and therefore tabu[w](a, b, it) ↔ 〈a, b, j〉 ∈ tabu[w] ∧j ≤ it. As a result, given a configuration k and iteration i, the neighborhoodis actually:

SWAP t(V )(k, i) =

{swap(M(w,g1,s1),M(w,g2,s2))(k) |

swap(M(w,g1,s1),M(w,g2,s2))(k) ∈ SWAP (V )(k)

∧ ¬tabu[w](k(M(w,g1,s1)

), k(M(w,g2,s2)

), i)}

Second, in addition to the non-tabu moves, the neighborhood in the searchprocedure also considers moves that improve the so far best solution givenby:

SWAP∗(V )(k, k∗) =

{swap(k) | swap(k) ∈ SWAP (V )(k)

∧ penalty(S .T .) (swap(k)) < penalty(S .T .) (k∗)}

Finally, the restarting component reinitializes the search from a randomconfiguration whenever the best schedule found so far has not been improvedupon a maximum number of non-improving iterations. Notice the swap movescannot lead to a schedule in which some golfers play more than once in thesame week.

7.1.2.2 CBLS for the Set ApproachThe basic idea of the search procedure for the set approach is:

1 while the GlobalAtMost1 constraint is not satisfied2 select two golfers from two different groups in the same week such that

the increase in violations by swapping them is minimum (at least onegolfer should be in conflict inside his/her group and thus belong to agroup with more than one golfer in conflict).


which is enhanced with variable-length tabu list, aspiration criteria, and restarts.The search heuristic is shown in Figure 7.2. Both the neighborhood and themeta-heuristics used by this local search algorithm are explained below.

99

SET-SOCIAL-GOLFERS-LS(Nw,Ng)1 forall w ∈ Nw

2 tabu[w]← ∅3 k∗ ← k ← initial configuration4 it ← n← 05 maxNonImproving ← 150006 while penalty(AtMost1 )(k) > 0 ∧ timeout not expired

7 select swap(S(w,g1),u,v,S(w,g2))(k) ∈(

SWAPt(V )(k, it) ∪

SWAP∗(V )(k, k∗))

8 minimizing penalty(AtMost1 )

(swap(S(w,g1),u,v,S(w,g2))(k)

)9 τ ← RANDOM([4,20])

10 tabu[w]← tabu[w] ∪ {〈u, v, it + τ〉}11 k ← swap(S(w,g1),u,v,S(w,g2))(k)12 if penalty(AtMost1 )(k) < penalty(AtMost1 )(k∗)13 k∗ ← k14 n← 015 elseif n > maxNonImproving16 k ← new random configuration17 n← 018 forall w ∈ Nw

19 tabu[w]← ∅20 else21 n← n+ 122 it ← it + 1

Figure 7.2: CBLS algorithm for the set approach to the Social Golfer Problem.

7.1.2.2.1 NeighborhoodThe neighborhood of the local search is the set of swap moves between twogolfers in two different groups of the same week:

M(k) ={

swap(S(w,g1),u,v,S(w,g2))(k) | u ∈ k(S(w,g1)

)∧

v ∈ k(S(w,g2)

)∧ g1 6= g2

}Restricting the attention to only those swaps involving one violated group, theneighborhood becomes:

M ′(k) ={

swap(S1,u,v,S2)(k) | swap(S1,u,v,S2) ∈M(k)

∧ conflict (AtMost1 ) (S1, k) > 0}

100

Furthermore, restricting attention to only those golfers in conflict with an-other golfer inside the violated group, the neighborhood becomes:

M ′′(k) ={

swap(S1,u,v,S2)(k) | swap(S1,u,v,S2) ∈M ′(k)

∧ ∃u′ ∈ k (S1) :∣∣m(u,u′)

∣∣ > 1}

which ensures that the algorithm focuses on swaps which may decrease thenumber of violations. The neighborhood is then:

SWAP (V )(k) ={

swap(S1,u,v,S2)(k) | swap(S1,u,v,S2)(k) ∈M ′′(k)

∧ S1, S2 ∈ V }

7.1.2.2.2 Meta-HeuristicsAnalogous to the meta-heuristics for the integer approach, the algorithm fea-tures a variable-length tabu list distributed across the various weeks. Eachweek w has an associated tabu-list tabu[w] and each of these lists maintainstriplets 〈u, v, j〉 where u and v are golfers while j represents the first iterationwhere golfers u and v can be swapped again in week w. In this sense the tabu-list is golfer-based and a group-based tabu-list could also be introduced (notuseful here though). The time a pair of golfers stay in a tabu-list is given by arandom generated value in the interval [4, 20].

The fact that swapping golfers a and b at iteration it is forbidden is denotedby tabu[w](a, b, it) and therefore tabu[w](a, b, it) ↔ 〈a, b, j〉 ∈ tabu[w] ∧j ≤ it. As a result, given a configuration k and iteration i, the neighborhoodis actually:

SWAP t(V )(k, i) =

{swap(S1,u,v,S2)(k) such that both

swap(S1,u,v,S2)(k) ∈ SWAP (V )(k) ∧ ¬tabu[w] (u, v, i)}

Note that when writing swap(S1,u,v,S2) it is taken for granted that u ∈ k (S1)and v ∈ k (S2). The algorithm also features an aspiration criterion consider-ing, in addition to the non-tabu moves, those moves that improve the so farbest solution, i.e, the neighborhood:

SWAP∗(V )(k, k∗) =

{swap(k) | swap(k) ∈ SWAP (V )(k) ∧

penalty(AtMost1 ) (swap(k)) < penalty(AtMost1 ) (k∗)}

Finally, the restarting component reinitializes the search from a possiblyrandom configuration whenever the best schedule found so far has not beenimproved upon a maximum number of non-improving iterations. Notice theswap moves cannot lead to a schedule in which some golfers plays more thanonce in the same week.

101

7.1.2.3 Attempt to Improve the CBLS AlgorithmsIt is possible to make an attempt to enhance the search algorithm of the setapproach by adding a greedy component to the meta-heuristics. Instead ofconsidering all weeks when selecting two golfers from to different groups (inthe same week) such that the increase in violations by swapping them is min-imum, just choose these two golfers directly from groups of the week withthe greatest number of violated groups. The meta-heuristic consists in switch-ing between a greedy and a non-greedy behavior after each restart. When thegreedy-behavior is switched on, the heuristic becomes:

1 while GlobalAtMost1 constraint is not satisfied2 select two golfers from two different groups in the week with the

greatest number of violated groups such that the increase inviolations by swapping them is minimum (at least one golfer shouldbe in conflict inside his/her group and thus belong to a group withmore than one golfer in conflict).


It is also possible to add such a greedy component to the meta-heuristicsin the integer approach. Instead of considering all weeks when selecting twogolfers from two different groups (in the same week) such that the increaseby swapping them is minimum, just choose these golfers directly from groupsof the week with the greatest number of violated groups. The meta-heuristicconsists in switching between a greedy and a non-greedy behavior after eachrestart. When the greedy-behavior is switched on, the heuristic becomes:

1 while the SocialTournament constraint is not satisfied2 select two golfers of two different groups in the week with the

greatest number of violated groups such that the increase inviolations by swapping them is minimum (at least one golfer shouldbe in conflict inside his/her group).


7.1.3 Setup of the Experiment7.1.3.1 Problem Instances and Initial ConfigurationsTo compare between the two approaches, the instances given in Table 6 in [8]are taken as reference and shown here in Table 7.2 (i.e, the instances solvedby the proposed local search algorithm for Social Golfers in [8] using the con-structive heuristic). Notice not all best known solutions are shown in the table,for example a solution to golf-8-4-9 is known to have been found by CPwith set variables and even though a solution for golf-8-4-10 was con-structed by hand (to our knowledge) it has been never found by a computer.3

3The existence of such a solution was an open question for several years. It was AlejandroAguado who constructed an explicit solution in 2004 using a result by Colbourn.

102

s = 3 s = 4 s = 5 s = 6 s = 7 s = 8 s = 9 s = 10g w w w w w w w w

6 8 6 6 3 - - - -7 9 7 7 5 8 - - -8 10 8 6 8 4 9 - -9 12 9 7 9 5 4 10 -

10 13 10 8 6 5 4 4 3

Table 7.2: Instances for the Social Golfer problem taken as reference.

s = 3 s = 4 s = 5 s = 6 s = 7 s = 8 s = 9 s = 10g w w w w w w w w

6 8 6 6 3 - - - -7 9 7 6 4 8 - - -8 10 8 6 5 4 5 - -9 12 9 7 6 5 4 5 -

10 13 10 8 7 5 5 4 3

Table 7.3: Instances for the Social Golfer problem.

However, to the best of our knowledge, these are the best results known todayfor this kind of approach to the Social Golfer Problem.4

Be aware that, for a given group size S and a given number of groups G, thedifficulty of finding a solution for golf-G-S-w increases with the numberof weeks w. That is, the greater the value w the more more difficult to satisfythe constraint that any pair of golfers play together at most once.

The results given Table 6 in [8] were obtained with a custom implementa-tion of the algorithm in C. Unfortunately, using this implementation writtenin Comet (for the known integer approach), the number of weeks for some ofthe instances shown in Table 7.2 could not be reached within a timeout of 30minutes.

Nevertheless, the author of this thesis aimed to find a solution configurationwith the largest possible number of weeks for all instances shown in Table 7.2(using either the integer or set approach). As a result, the instances shown inthe tables in Section 7.2 are those shown in Table 7.3.

When running the experiment, in both approaches the search starts from thesame initial configuration generated using the constructive heuristic describedalso in [8]. As explained there, this constructive heuristic simply aims at ex-ploiting the fact that all golfers in a group for a given week must be assignedto different groups in subsequent weeks. That is, given the golfers in a groupfor a given week, the heuristic attempts to distribute these golfers in differ-ent groups in subsequent weeks. Results in [8] show that the combination of

4The current statuses of the instances solved by Constraint Programming techniques (quitedifferent from CBLS) was known to be maintained in Warwick Harvey’s web page, cur-rently accesible at http://web.archive.org/web/20050308115423/http://www.icparc.ic.ac.uk/~wh/golf/

103

http://web.archive.org/web/20050308115423/http://www.icparc.ic.ac.uk/~wh/golf/

http://web.archive.org/web/20050308115423/http://www.icparc.ic.ac.uk/~wh/golf/

local search with a good starting point is very effective on the Social Golferproblem.

7.1.3.2 The ImplementationAs there are two local search algorithms, one for the integer approach andanother for the set approach, two different implementations are needed.

7.1.3.2.1 CBLS for the Integer ApproachOn the one hand, the implementation of the CBLS algorithm for the integerapproach was directly taken from the distribution of Comet (i.e., [1]). Thissolution implements the ideas described in [8] and thereby it implements thealgorithm shown in 7.1. The source code for this implementation is given inSection 15.1. However, in order to have a better control over both the inputand the output, some slight extensions to the original program as well as someminor additions had to be made.

The changes in the code shown in Listing 15.1 with respect to the originalcode are:

• Some required include statements are added in Lines 2 and 3. One for theinput/output functions and the other for the SocialTorunament constraint.

• Lines 5 to 10 are added to handle the input. More precisely:

• Three new variables: nbWeeks, nbGroups and nbSlots, are added torespectively hold the w, g and s parameters of a golf-g-s-w prob-lem. These variables are used then to initialize the Weeks, Groups,Slots and Golfers ranges.• A new array problemFiles of size two is added to (possibly) hold the

names of the input and output files.• All the variables above are meant to be initialized using a getInput

function called in Line 10.

• Since now there exists the possibility of having an input file specifyingthe problem instance, there also exists the possibility of getting the initialconfiguration from the input file instead of generating it randomly. This isuseful, for example, to generate initial configurations in advance and thenrun the local search with both integer and set approaches starting from thesame initial configuration. An if statement was introduced to this end inLines 21 to 25.

• In Line 43 the initial configuration is saved in a variable calling a functionnamed getSchedule. This is done just for documentation purposes (forinstance, to be able to show which was the initial configuration when asolution was found quickly).

• A new integer variable nbRestarts is declared in Line 50 to count the num-ber of times the search algorithm actually restarts. This variable is updatedin Line 81.

104

• Similarly, three new integer variables timeout, t0 and time are declared re-spectively in Lines 54, 55, and 89. The first one is used to define a timeoutvalue, the second one is used to keep track of how much time the search al-gorithm is taking, and the last one stores the total time the search algorithmruns. The timeout is added to the condition of the while loop in Line 58.

• Finally, a setOuput function is called in Line 90 to handle the output.

In the code shown in Listing 15.2 the only change with respect to the originalcode (note the original code is actually shown in Listings 15.1, 15.2 and 15.3)is the introduction of the golfersInConflict incremental variable in Line 16.This is done in order to implement the greedy-component described in Section7.1.2.3. This variable is defined through an invariant in Line 52, and a gettermethod for it is defined in Line 35. No changes are made in the code shownin Listing 15.3 with respect to the original code.

The implementation introducing the attempt to improve the integer ap-proach described in Section 7.1.2.3 is shown in Listing 15.4.

7.1.3.2.2 CBLS for the Set ApproachOn the other hand, the implementation of the CBLS algorithm for the set ap-proach was developed from scratch (taking the implementation of the integerapproach as reference). This required the implementation of the proposed newGlobalPairAtmost1 constraint which in turn required the implementation ofa user-defined invariant on set variables (see Listing 15.7).

The source code for this implementation is given in Section 15.2. Unlike theimplementation for the integer approach, this approach uses Comet’s eventsmechanism to keep separated the heuristic from the meta-heuristics (with-out degenerating the performance and increasing readability and separation ofconcerns).

Finally, the implementation introducing the attempt to improve the set ap-proach described in Section 7.1.2.3 is shown in Listing 15.8.

7.1.3.3 The MachineAll programs were run on ASTRA’s experiment server ghoul, a machinewith an Intel Core i7-950 processor and 3 gigabytes of RAM. A timeout of 30minutes per instance was set and each instance was run 25 times.

7.2 ResultsIn this section results are given in terms of number of successful runs, run-time (in milliseconds) and number of iterations for each of the four proposedsolutions. Comparisons are made to contrast between the integer and set ap-proaches. At the end the solved instances (with the greater possible number ofweeks) are summarized.

105

Integer modelinstance time (miliseconds) iterations rest-g-s-w n average min. max. std.dev. average min. max. std.dev. arts6-3-8 25 166367.08 7447 549890 152743.43 183315.92 9229 499857 164197.58 2266-4-6 25 72048.84 2958 229617 61596.19 55936.72 2532 180515 45892.67 666-5-6 0 > timeout - - - - - - - -6-6-3 25 - - - - - - - - -7-3-9 25 7847.88 780 24463 5118.96 8450.76 454 32400 6965.92 77-4-7 24 352799.88 1907 831812 205866.61 177378.50 1121 411199 91618.91 2147-5-6 0 > timeout - - - - - - - -7-6-4 25 85.80 65 126 26.44 22.00 22 22 0.00 07-7-8 25 - - - - - - - - -

8-3-10 25 1100.08 444 2834 502.67 394.76 100 1840 441.47 08-4-8 25 694801.16 17162 1306108 512511.30 282582.08 8707 498503 210383.01 3508-5-6 25 357.84 166 1237 286.40 209.36 77 870 208.05 08-6-5 25 2622.16 678 8278 1870.69 800.36 101 2463 635.33 08-7-4 25 443.28 197 1016 226.10 172.36 43 479 121.73 08-8-5 0 > timeout - - - - - - - -

9-3-12 5 815324.00 28589 1577964 574503.40 470903.60 17989 944548 340021.52 1159-4-9 25 347040.68 111125 1136076 268002.54 119696.60 37805 426453 86697.98 1439-5-7 25 8130.24 686 25774 7055.40 2206.68 65 6985 1862.98 09-6-6 25 245999.64 20040 875592 238568.03 45887.92 4057 144720 41400.08 549-7-5 25 23233.52 20090 38746 4959.37 4314.00 4314 4314 0.00 09-8-4 25 2325.52 1857 3563 584.27 491.00 491 491 0.00 09-9-5 3 496988.00 44865 748887 392401.56 14160.67 1210 21458 11245.69 0

10-3-13 25 35562.04 4894 188130 42931.09 18193.12 2369 78577 19449.62 1710-4-10 25 960130.00 42674 1591866 535777.30 313236.16 13292 425955 170413.23 38410-5-8 25 125212.08 9853 626327 158165.31 34078.24 2630 171195 42738.78 3810-6-7 0 > timeout - - - - - - - -10-7-5 25 435.32 429 446 4.59 37.00 37 37 0.00 010-8-5 2 950746.50 616029 1285464 473362.03 94291.50 62317 126266 45218.77 810-9-4 25 26255.20 1860 143770 30612.23 4326.72 220 22129 4896.43 1

10-10-3 25 - - - - - - - - -

Table 7.4: Run-time (in milliseconds) and number of iterations for the integer ap-proach to the Social Golfer Problem.

7.2.1 Integer ApproachThis section presents:

• Results for the integer approach to golf-g-s-w in Table 7.4.

• Results for the greedy integer approach to golf-g-s-w in Table 7.5.

• A comparison between both non-greedy and greedy integer approaches togolf-g-s-w in terms of run-time (in milliseconds) and number of itera-tions in Tables 7.6 and 7.7.

The integer approach solved all the tried instances except four (namely,golf-6-5-6, golf-7-5-6, golf-8-8-5 and golf-10-6-7) and theinstances golf-9-3-12, golf-9-9-5 and golf-10-8-5were hard forthis approach as they were solved less than 6 (of 25) times. Some instances(namely golf-6-6-3, golf-7-7-8 and golf-10-10-3) required 0 it-erations since the constructive heuristic to generate the initial configurationseemed to be enough to actually find a solution configuration for them.

Likewise, the greedy approach solved all the tried instances except four(namely, golf-7-5-6, golf-9-9-5, golf-10-6-7 and golf-10-8-5)and the instances golf-8-8-5 and golf-9-3-12 were hard for this ap-proach as they were solved less than 7 (of 25) times. Note the greedy ap-proach solved two instances that the non-greedy approach could not solve:

106

Integer model (greedy approach)instance time (miliseconds) iterations rest-g-s-w n average min. max. std.dev. average min. max. std.dev. arts6-3-8 25 343028.72 5417 1203179 340759.94 504512.00 7942 1712112 499861.92 7066-4-6 25 248377.76 3827 1235336 273223.53 246776.36 3348 1084118 262037.90 3406-5-6 19 678081.16 4269 1655477 519430.32 291178.42 1098 744215 218330.32 2686-6-3 25 - - - - - - - - -7-3-9 25 5618.16 1009 25150 5520.18 8018.60 1069 41916 9739.49 47-4-7 23 523191.65 182671 1420936 283510.37 393089.83 126661 1073481 214864.86 4737-5-6 0 > timeout - - - - - - - -7-6-4 25 120.08 98 129 9.78 22.00 22 22 0.00 07-7-8 25 - - - - - - - - -

8-3-10 25 1364.52 817 2787 609.24 646.92 114 1961 579.63 08-4-8 25 645228.72 34335 1728147 557400.35 362702.00 10331 991350 312743.58 4538-5-6 25 514.32 141 1868 448.47 325.76 54 1359 334.92 08-6-5 25 3267.40 737 9910 2052.95 963.28 89 2743 798.72 08-7-4 25 387.68 318 628 99.58 117.00 117 117 0.00 08-8-5 1 360850.00 360850 360850 - 12983.00 12983 12983 - 0

9-3-12 7 666491.29 25422 1651481 555930.77 529810.86 16595 1310132 473111.38 1969-4-9 22 617761.77 130294 1730155 408524.24 306456.14 73460 789029 194273.69 3349-5-7 25 6592.60 539 25473 6710.49 2429.68 114 9954 2559.48 09-6-6 25 172858.84 9311 623561 146588.23 49404.48 1241 165534 42640.43 539-7-5 25 140637.88 1416 399217 136093.74 36275.92 198 104898 36195.72 409-8-4 25 3038.52 523 13720 2770.35 833.08 87 4005 826.88 09-9-5 0 > timeout - - - - - - - -

10-3-13 25 26084.48 2556 147100 33926.09 23460.68 768 154428 36257.06 2410-4-10 25 623633.80 7978 1621904 499936.50 300694.04 2244 853477 238369.53 36210-5-8 25 50607.92 4903 248753 64582.17 17857.28 1200 103464 26219.29 1510-6-7 0 > timeout - - - - - - - -10-7-5 25 432.84 427 453 5.09 37.40 36 47 2.24 010-8-5 0 > timeout - - - - - - - -10-9-4 25 48836.48 48434 49487 241.94 8274.00 8274 8274 0.00 0

10-10-3 25 - - - - - - - - -

Table 7.5: Run-time (in milliseconds) and number of iterations for the greedy integerapproach to the Social Golfer Problem.

Run time (miliseconds)instance integer model integer model (greedy approach)g-s-w n average min. max. std.dev. n average min. max. std.dev.6-3-8 25 166367.08 7447 549890 152743.43 25 343028.72 5417 1203179 340759.946-4-6 25 72048.84 2958 229617 61596.19 25 248377.76 3827 1235336 273223.536-5-6 0 > timeout - - - 19 678081.16 4269 1655477 519430.326-6-3 25 - - - - 25 - - - -7-3-9 25 7847.88 780 24463 5118.96 25 5618.16 1009 25150 5520.187-4-7 24 352799.88 1907 831812 205866.61 23 523191.65 182671 1420936 283510.377-5-6 0 > timeout - - - 0 > timeout - - -7-6-4 25 85.80 65 126 26.44 25 120.08 98 129 9.787-7-8 25 - - - - 25 - - - -

8-3-10 25 1100.08 444 2834 502.67 25 1364.52 817 2787 609.248-4-8 25 694801.16 17162 1306108 512511.30 25 645228.72 34335 1728147 557400.358-5-6 25 357.84 166 1237 286.40 25 514.32 141 1868 448.478-6-5 25 2622.16 678 8278 1870.69 25 3267.40 737 9910 2052.958-7-4 25 443.28 197 1016 226.10 25 387.68 318 628 99.588-8-5 0 > timeout - - - 1 360850.00 360850 360850 -

9-3-12 5 815324.00 28589 1577964 574503.40 7 666491.29 25422 1651481 555930.779-4-9 25 347040.68 111125 1136076 268002.54 22 617761.77 130294 1730155 408524.249-5-7 25 8130.24 686 25774 7055.40 25 6592.60 539 25473 6710.499-6-6 25 245999.64 20040 875592 238568.03 25 172858.84 9311 623561 146588.239-7-5 25 23233.52 20090 38746 4959.37 25 140637.88 1416 399217 136093.749-8-4 25 2325.52 1857 3563 584.27 25 3038.52 523 13720 2770.359-9-5 3 496988.00 44865 748887 392401.56 0 > timeout - - -

10-3-13 25 35562.04 4894 188130 42931.09 25 26084.48 2556 147100 33926.0910-4-10 25 960130.00 42674 1591866 535777.30 25 623633.80 7978 1621904 499936.5010-5-8 25 125212.08 9853 626327 158165.31 25 50607.92 4903 248753 64582.1710-6-7 0 > timeout - - - 0 > timeout - - -10-7-5 25 435.32 429 446 4.59 25 432.84 427 453 5.0910-8-5 2 950746.50 616029 1285464 473362.03 0 > timeout - - -10-9-4 25 26255.20 1860 143770 30612.23 25 48836.48 48434 49487 241.94

10-10-3 25 - - - - 25 - - - -

Table 7.6: Run-time (in milliseconds) for both greedy and non-greedy integer ap-proaches to the Social Golfer Problem.

107

Number of iterationsinstance integer model integer model (greedy approach)g-s-w n average min. max. std.dev. n average min. max. std.dev.6-3-8 25 183315.92 9229 499857 164197.58 25 504512.00 7942 1712112 499861.926-4-6 25 55936.72 2532 180515 45892.67 25 246776.36 3348 1084118 262037.906-5-6 0 - - - - 19 291178.42 1098 744215 218330.326-6-3 25 - - - - 25 - - - -7-3-9 25 8450.76 454 32400 6965.92 25 8018.60 1069 41916 9739.497-4-7 24 177378.50 1121 411199 91618.91 23 393089.83 126661 1073481 214864.867-5-6 0 - - - - 0 - - - -7-6-4 25 22.00 22 22 0.00 25 22.00 22 22 0.007-7-8 25 - - - - 25 - - - -

8-3-10 25 394.76 100 1840 441.47 25 646.92 114 1961 579.638-4-8 25 282582.08 8707 498503 210383.01 25 362702.00 10331 991350 312743.588-5-6 25 209.36 77 870 208.05 25 325.76 54 1359 334.928-6-5 25 800.36 101 2463 635.33 25 963.28 89 2743 798.728-7-4 25 172.36 43 479 121.73 25 117.00 117 117 0.008-8-5 0 - - - - 1 12983.00 12983 12983 -

9-3-12 5 470903.60 17989 944548 340021.52 7 529810.86 16595 1310132 473111.389-4-9 25 119696.60 37805 426453 86697.98 22 306456.14 73460 789029 194273.699-5-7 25 2206.68 65 6985 1862.98 25 2429.68 114 9954 2559.489-6-6 25 45887.92 4057 144720 41400.08 25 49404.48 1241 165534 42640.439-7-5 25 4314.00 4314 4314 0.00 25 36275.92 198 104898 36195.729-8-4 25 491.00 491 491 0.00 25 833.08 87 4005 826.889-9-5 3 14160.67 1210 21458 11245.69 0 - - - -

10-3-13 25 18193.12 2369 78577 19449.62 25 23460.68 768 154428 36257.0610-4-10 25 313236.16 13292 425955 170413.23 25 300694.04 2244 853477 238369.5310-5-8 25 34078.24 2630 171195 42738.78 25 17857.28 1200 103464 26219.2910-6-7 0 - - - - 0 - - - -10-7-5 25 37.00 37 37 0.00 25 37.40 36 47 2.2410-8-5 2 94291.50 62317 126266 45218.77 0 - - - -10-9-4 25 4326.72 220 22129 4896.43 25 8274.00 8274 8274 0.00

10-10-3 25 - - - - 25 - - - -

Table 7.7: Number of iterations for both greedy and non-greedy integer approaches tothe Social Golfer Problem.

golf-6-5-6 and golf-8-8-5. Conversely, the non-greedy approach solvedone instance that the non-greedy approach could not solve: golf-10-8-5.

There is no clear pattern showing a run-time improvement on the CBLS al-gorithm by introducing the greedy component. For some instances the greedyapproach is faster but for some other instances the non-greedy approach wins.Similarly, there is no pattern showing a clear improvement on the number ofiterations.

7.2.2 Set ApproachThis section presents:

• Results for the set approach to golf-g-s-w in Table 7.8.

• Results for the greedy set approach to golf-g-s-w in Table 7.9.

• A comparison between both non-greedy and greedy set approaches to theSocial Golfer problem in terms of run-time and number of iterations inTables 7.10 and 7.11.

The set approach solved all the tried instances except two of them (namely,golf-7-5-6 and golf-9-9-5) and the instances that were hard here are

108

Set modelinstance time (miliseconds) iterations rest-g-s-w n average min. max. std.dev. average min. max. std.dev. arts6-3-8 24 378689.79 64166 1165813 324722.24 895059.29 165678 2509979 738328.65 21946-4-6 25 49789.28 16503 190741 50348.29 73642.04 28727 298001 74885.46 1966-5-6 3 360961.33 2291 714505 356134.68 117930.67 810 222298 111293.39 326-6-3 25 - - - - - - - - -7-3-9 25 3134.92 2685 5575 802.60 7246.28 7004 7677 329.70 07-4-7 25 196922.04 3726 423436 127522.16 202962.12 5136 339169 127621.67 5287-5-6 0 > timeout - - - - - - - -7-6-4 25 71.12 69 80 2.63 37.00 37 37 0.00 07-7-8 25 - - - - - - - - -

8-3-10 25 348.64 286 490 38.19 336.48 137 865 139.73 08-4-8 25 73475.88 1680 319205 76351.06 60505.28 1564 212393 59896.71 1548-5-6 25 167.80 73 441 104.77 101.40 32 402 101.31 08-6-5 25 1491.72 619 2788 469.61 821.76 144 850 141.20 08-7-4 25 451.96 283 1221 225.39 100.84 41 302 73.09 08-8-5 8 30385.25 6668 188221 63817.12 1805.12 289 12418 4288.25 0

9-3-12 23 791874.87 6454 1659081 544002.65 978301.39 11808 2292965 680777.79 21969-4-9 25 38815.56 6211 66977 15127.62 21787.52 3163 33198 5969.11 449-5-7 25 1129.12 1099 1183 19.26 803.00 803 803 0.00 09-6-6 25 16756.64 4404 43071 10762.36 5295.28 686 12952 3930.87 09-7-5 25 20025.24 1550 91299 28131.22 4831.00 378 18367 6460.77 49-8-4 25 3205.56 432 7740 2588.93 1191.96 56 2720 1038.31 09-9-5 0 > timeout - - - - - - - -

10-3-13 25 7534.56 1312 36976 10748.78 7939.08 613 37217 14940.85 2010-4-10 25 33905.04 2254 121984 34411.04 18882.76 429 80849 20620.38 3610-5-8 25 5563.68 1815 24087 5322.64 2392.16 494 10836 2225.48 010-6-7 6 710276.33 198163 1705522 624786.04 158595.17 45479 384488 145307.16 8210-7-5 25 405.76 394 438 12.04 45.48 45 57 2.40 010-8-5 12 729656.17 41395 1633916 489606.14 99362.25 3313 249348 71241.51 10010-9-4 25 17792.92 1431 49714 13697.91 3225.08 108 6500 2571.06 0

10-10-3 25 - - - - - - - - -

Table 7.8: Run-time (in milliseconds) and number of iterations for the set approach tothe Social Golfer Problem.

Set modelinstance time (miliseconds) iterations rest-g-s-w n average min. max. std.dev. average min. max. std.dev. arts6-3-8 25 409077.88 20126 996948 261510.46 954759.16 57931 2410209 613809.97 24986-4-6 25 28732.48 3282 352723 68187.31 38773.80 4725 476238 92094.63 1026-5-6 4 624445.00 31530 889773 398173.31 251618.50 11756 394891 166077.20 866-6-3 25 - - - - - - - - -7-3-9 25 4379.16 221 18972 4071.95 10033.92 229 51986 11260.62 147-4-7 25 71771.64 2115 231242 61783.66 68268.76 2293 221724 56013.79 1407-5-6 3 356182.67 24491 763700 375392.64 167681.00 14671 359625 175741.88 447-6-4 25 94.52 71 177 32.48 65.40 37 180 44.62 07-7-8 25 - - - - - - - - -

8-3-10 25 357.44 326 567 58.51 347.16 268 1049 185.93 08-4-8 25 73378.20 1702 128244 35064.88 60503.64 1471 87704 25582.39 1288-5-6 25 150.12 88 478 81.42 63.00 52 312 51.96 08-6-5 25 1599.56 709 3398 623.58 314.28 160 990 196.25 08-7-4 25 623.28 612 627 3.79 137.00 137 137 0.00 08-8-5 4 110801.75 17216 231488 108721.69 5180.75 382 11075 5530.55 0

9-3-12 23 1255300.13 141441 1665287 504523.94 1669180.70 200238 1973517 678278.30 36909-4-9 25 88757.84 5757 221349 79629.57 61914.48 4761 171076 53676.16 1609-5-7 25 2436.80 367 2752 620.87 1827.20 111 2060 528.97 09-6-6 25 21835.44 3554 80217 18336.29 7364.84 421 25694 6963.25 89-7-5 25 27098.72 11100 219599 40335.29 5575.64 4137 40103 7193.20 49-8-4 25 2346.60 1100 8075 1370.04 741.00 195 1845 374.21 09-9-5 0 > timeout - - - - - - - -

10-3-13 25 5236.48 5028 6245 366.57 7887.00 7887 7887 0.00 010-4-10 25 35370.16 5106 188993 43631.80 19753.96 2809 90708 22953.83 3410-5-8 25 2552.92 1507 13054 2298.79 672.24 501 3837 660.03 010-6-7 2 690095.00 400290 979900 409846.16 143685.50 104037 183334 56071.45 2610-7-5 25 571.12 440 810 131.34 44.12 43 45 1.01 010-8-5 6 649583.50 56880 1700091 645722.96 109929.83 9652 284892 108454.83 5810-9-4 25 8606.80 1210 31984 7252.18 2077.08 114 8369 1854.68 0

10-10-3 25 - - - - - - - - -

Table 7.9: Run-time (in milliseconds) and number of iterations for the greedy setapproach to the Social Golfer Problem.

109

Run time (miliseconds)instance set model set model (greedy approach)g-s-w n average min. max. std.dev. n average min. max. std.dev.6-3-8 24 378689.79 64166 1165813 324722.24 25 409077.88 20126 996948 261510.466-4-6 25 49789.28 16503 190741 50348.29 25 28732.48 3282 352723 68187.316-5-6 3 360961.33 2291 714505 356134.68 4 624445.00 31530 889773 398173.316-6-3 25 - - - - 25 - - - -7-3-9 25 3134.92 2685 5575 802.60 25 4379.16 221 18972 4071.957-4-7 25 196922.04 3726 423436 127522.16 25 71771.64 2115 231242 61783.667-5-6 0 > timeout - - - 3 356182.67 24491 763700 375392.647-6-4 25 71.12 69 80 2.63 25 94.52 71 177 32.487-7-8 25 - - - - 25 - - - -

8-3-10 25 348.64 286 490 38.19 25 357.44 326 567 58.518-4-8 25 73475.88 1680 319205 76351.06 25 73378.20 1702 128244 35064.888-5-6 25 167.80 73 441 104.77 25 150.12 88 478 81.428-6-5 25 1491.72 619 2788 469.61 25 1599.56 709 3398 623.588-7-4 25 451.96 283 1221 225.39 25 623.28 612 627 3.798-8-5 8 30385.25 6668 188221 63817.12 4 110801.75 17216 231488 108721.69

9-3-12 23 791874.87 6454 1659081 544002.65 23 1255300.13 141441 1665287 504523.949-4-9 25 38815.56 6211 66977 15127.62 25 88757.84 5757 221349 79629.579-5-7 25 1129.12 1099 1183 19.26 25 2436.80 367 2752 620.879-6-6 25 16756.64 4404 43071 10762.36 25 21835.44 3554 80217 18336.299-7-5 25 20025.24 1550 91299 28131.22 25 27098.72 11100 219599 40335.299-8-4 25 3205.56 432 7740 2588.93 25 2346.60 1100 8075 1370.049-9-5 0 > timeout - - - 0 > timeout - - -

10-3-13 25 7534.56 1312 36976 10748.78 25 5236.48 5028 6245 366.5710-4-10 25 33905.04 2254 121984 34411.04 25 35370.16 5106 188993 43631.8010-5-8 25 5563.68 1815 24087 5322.64 25 2552.92 1507 13054 2298.7910-6-7 6 710276.33 198163 1705522 624786.04 2 690095.00 400290 979900 409846.1610-7-5 25 405.76 394 438 12.04 25 571.12 440 810 131.3410-8-5 12 729656.17 41395 1633916 489606.14 6 649583.50 56880 1700091 645722.9610-9-4 25 17792.92 1431 49714 13697.91 25 8606.80 1210 31984 7252.18

10-10-3 25 - - - - 25 - - - -

Table 7.10: Run-time (in milliseconds) for both greedy and non-greedy set approachesto the Social Golfer Problem.

Number of iterationsinstance set model set model (greedy approach)g-s-w n average min. max. std.dev. n average min. max. std.dev.6-3-8 24 895059.29 165678 2509979 738328.65 25 954759.16 57931 2410209 613809.976-4-6 25 73642.04 28727 298001 74885.46 25 38773.80 4725 476238 92094.636-5-6 3 117930.67 810 222298 111293.39 4 251618.50 11756 394891 166077.206-6-3 25 - - - - 25 - - - -7-3-9 25 7246.28 7004 7677 329.70 25 10033.92 229 51986 11260.627-4-7 25 202962.12 5136 339169 127621.67 25 68268.76 2293 221724 56013.797-5-6 0 - - - - 3 167681.00 14671 359625 175741.887-6-4 25 37.00 37 37 0.00 25 65.40 37 180 44.627-7-8 25 - - - - 25 - - - -

8-3-10 25 336.48 137 865 139.73 25 347.16 268 1049 185.938-4-8 25 60505.28 1564 212393 59896.71 25 60503.64 1471 87704 25582.398-5-6 25 101.40 32 402 101.31 25 63.00 52 312 51.968-6-5 25 821.76 144 850 141.20 25 314.28 160 990 196.258-7-4 25 100.84 41 302 73.09 25 137.00 137 137 0.008-8-5 8 1805.12 289 12418 4288.25 4 5180.75 382 11075 5530.55

9-3-12 23 978301.39 11808 2292965 680777.79 23 1669180.70 200238 1973517 678278.309-4-9 25 21787.52 3163 33198 5969.11 25 61914.48 4761 171076 53676.169-5-7 25 803.00 803 803 0.00 25 1827.20 111 2060 528.979-6-6 25 5295.28 686 12952 3930.87 25 7364.84 421 25694 6963.259-7-5 25 4831.00 378 18367 6460.77 25 5575.64 4137 40103 7193.209-8-4 25 1191.96 56 2720 1038.31 25 741.00 195 1845 374.219-9-5 0 - - - - 0 - - - -

10-3-13 25 7939.08 613 37217 14940.85 25 7887.00 7887 7887 0.0010-4-10 25 18882.76 429 80849 20620.38 25 19753.96 2809 90708 22953.8310-5-8 25 2392.16 494 10836 2225.48 25 672.24 501 3837 660.0310-6-7 6 158595.17 45479 384488 145307.16 2 143685.50 104037 183334 56071.4510-7-5 25 45.48 45 57 2.40 25 44.12 43 45 1.0110-8-5 12 99362.25 3313 249348 71241.51 6 109929.83 9652 284892 108454.8310-9-4 25 3225.08 108 6500 2571.06 25 2077.08 114 8369 1854.68

10-10-3 25 - - - - 25 - - - -

Table 7.11: Number of iterations for both greedy and non-greedy set approaches tothe Social Golfer Problem.

110

golf-6-5-6, golf-8-8-5, golf-10-6-7 and golf-10-8-5 as theywere solved less than 12 (of 25) times.

Likewise, the greedy set approach solved all the tried instances except one(namely, golf-9-9-5) and the instances that were hard for this approachare golf-6-5-6 and golf-7-5-6, golf-8-8-5, golf-10-6-7 andgolf-10-8-5 as they were solved less than 6 (of 25) times. Note the greedyapproach solved one of the instances that the non-greedy approach could notsolve: golf-7-5-6. However, neither of the set approaches could solvegolf-9-9-5.

There is no clear pattern showing a run-time improvement on the CBLS al-gorithm by introducing the greedy component. For some instances the greedyapproach is faster but for some other instances the non-greedy approach wins.Similarly, there is no pattern showing a clear improvement on the number ofiterations.

7.2.3 Comparison Between the Integer and Set ApproachesThis section presents:

• A comparison between both integer and set approaches to the Social Golferproblem in terms of run-time (in milliseconds) and number of iterations inTables 7.12 and 7.13.

• A comparison between both greedy integer and set approaches to the So-cial Golfer problem in terms of run-time (in milliseconds) and number ofiterations in Tables 7.14 and 7.15.

The set approach solved all the instances solved by the integer approach ex-cept one (namely, golf-9-9-5), and except for the two instances golf-9-9-5and golf-6-3-8 the set approach succeeded more (or equal number of)times (over the 25 runs). In all instances, except 3, the set approach was in av-erage faster and most of the solved instances reported a better minimum timewith the set approach. Table 7.14 clearly shows a run-time improvement ofthe set approach over the integer approach. However, there is not such a clearimprovement pattern when comparing the number of iterations.

The scenario is similar with the greedy approaches. The greedy set ap-proach solved all the instances the greedy integer approach solved (exceptfor the instance golf-9-9-5) and even more (instances golf-7-5-6,golf-10-6-7 and golf-10-8-5 were solved by the greedy set approachbut not by the greedy integer approach). There is clearly and improvement inthe run-time of the greedy set approach over the greedy integer approach andin average it also required less iterations.

111

Run time (miliseconds)instance integer model set modelg-s-w n average min. max. std.dev. n average min. max. std.dev.6-3-8 25 166367.08 7447 549890 152743.43 24 378689.79 64166 1165813 324722.246-4-6 25 72048.84 2958 229617 61596.19 25 49789.28 16503 190741 50348.296-5-6 0 > timeout - - - 3 360961.33 2291 714505 356134.686-6-3 25 - - - - 25 - - - -7-3-9 25 7847.88 780 24463 5118.96 25 3134.92 2685 5575 802.607-4-7 24 352799.88 1907 831812 205866.61 25 196922.04 3726 423436 127522.167-5-6 0 > timeout - - - 0 > timeout - - -7-6-4 25 85.80 65 126 26.44 25 71.12 69 80 2.637-7-8 25 - - - - 25 - - - -

8-3-10 25 1100.08 444 2834 502.67 25 348.64 286 490 38.198-4-8 25 694801.16 17162 1306108 512511.30 25 73475.88 1680 319205 76351.068-5-6 25 357.84 166 1237 286.40 25 167.80 73 441 104.778-6-5 25 2622.16 678 8278 1870.69 25 1491.72 619 2788 469.618-7-4 25 443.28 197 1016 226.10 25 451.96 283 1221 225.398-8-5 0 > timeout - - - 8 30385.25 6668 188221 63817.12

9-3-12 5 815324.00 28589 1577964 574503.40 23 791874.87 6454 1659081 544002.659-4-9 25 347040.68 111125 1136076 268002.54 25 38815.56 6211 66977 15127.629-5-7 25 8130.24 686 25774 7055.40 25 1129.12 1099 1183 19.269-6-6 25 245999.64 20040 875592 238568.03 25 16756.64 4404 43071 10762.369-7-5 25 23233.52 20090 38746 4959.37 25 20025.24 1550 91299 28131.229-8-4 25 2325.52 1857 3563 584.27 25 3205.56 432 7740 2588.939-9-5 3 496988.00 44865 748887 392401.56 0 > timeout - - -

10-3-13 25 35562.04 4894 188130 42931.09 25 7534.56 1312 36976 10748.7810-4-10 25 960130.00 42674 1591866 535777.30 25 33905.04 2254 121984 34411.0410-5-8 25 125212.08 9853 626327 158165.31 25 5563.68 1815 24087 5322.6410-6-7 0 > timeout - - - 6 710276.33 198163 1705522 624786.0410-7-5 25 435.32 429 446 4.59 25 405.76 394 438 12.0410-8-5 2 950746.50 616029 1285464 473362.03 12 729656.17 41395 1633916 489606.1410-9-4 25 26255.20 1860 143770 30612.23 25 17792.92 1431 49714 13697.91

10-10-3 25 - - - - 25 - - - -

Table 7.12: Run-time (in milliseconds) for both integer and set approaches to theSocial Golfer Problem.

Number of iterationsinstance integer model set modelg-s-w n average min. max. std.dev. n average min. max. std.dev.6-3-8 25 183315.92 9229 499857 164197.58 24 895059.29 165678 2509979 738328.656-4-6 25 55936.72 2532 180515 45892.67 25 73642.04 28727 298001 74885.466-5-6 0 - - - - 3 117930.67 810 222298 111293.396-6-3 25 - - - - 25 - - - -7-3-9 25 8450.76 454 32400 6965.92 25 7246.28 7004 7677 329.707-4-7 24 177378.50 1121 411199 91618.91 25 202962.12 5136 339169 127621.677-5-6 0 - - - - 0 - - - -7-6-4 25 22.00 22 22 0.00 25 37.00 37 37 0.007-7-8 25 - - - - 25 - - - -

8-3-10 25 394.76 100 1840 441.47 25 336.48 137 865 139.738-4-8 25 282582.08 8707 498503 210383.01 25 60505.28 1564 212393 59896.718-5-6 25 209.36 77 870 208.05 25 101.40 32 402 101.318-6-5 25 800.36 101 2463 635.33 25 821.76 144 850 141.208-7-4 25 172.36 43 479 121.73 25 100.84 41 302 73.098-8-5 0 - - - - 8 1805.12 289 12418 4288.25

9-3-12 5 470903.60 17989 944548 340021.52 23 978301.39 11808 2292965 680777.799-4-9 25 119696.60 37805 426453 86697.98 25 21787.52 3163 33198 5969.119-5-7 25 2206.68 65 6985 1862.98 25 803.00 803 803 0.009-6-6 25 45887.92 4057 144720 41400.08 25 5295.28 686 12952 3930.879-7-5 25 4314.00 4314 4314 0.00 25 4831.00 378 18367 6460.779-8-4 25 491.00 491 491 0.00 25 1191.96 56 2720 1038.319-9-5 3 14160.67 1210 21458 11245.69 0 - - - -

10-3-13 25 18193.12 2369 78577 19449.62 25 7939.08 613 37217 14940.8510-4-10 25 313236.16 13292 425955 170413.23 25 18882.76 429 80849 20620.3810-5-8 25 34078.24 2630 171195 42738.78 25 2392.16 494 10836 2225.4810-6-7 0 - - - - 6 158595.17 45479 384488 145307.1610-7-5 25 37.00 37 37 0.00 25 45.48 45 57 2.4010-8-5 2 94291.50 62317 126266 45218.77 12 99362.25 3313 249348 71241.5110-9-4 25 4326.72 220 22129 4896.43 25 3225.08 108 6500 2571.06

10-10-3 25 - - - - 25 - - - -

Table 7.13: Number of iterations for both integer and set approaches to the SocialGolfer Problem.

112

Run time (miliseconds)instance integer model set modelg-s-w n average min. max. std.dev. n average min. max. std.dev.6-3-8 25 343028.72 5417 1203179 340759.94 25 409077.88 20126 996948 261510.466-4-6 25 248377.76 3827 1235336 273223.53 25 28732.48 3282 352723 68187.316-5-6 19 678081.16 4269 1655477 519430.32 4 624445.00 31530 889773 398173.316-6-3 25 - - - - 25 - - - -7-3-9 25 5618.16 1009 25150 5520.18 25 4379.16 221 18972 4071.957-4-7 23 523191.65 182671 1420936 283510.37 25 71771.64 2115 231242 61783.667-5-6 0 > timeout - - - 3 356182.67 24491 763700 375392.647-6-4 25 120.08 98 129 9.78 25 94.52 71 177 32.487-7-8 25 - - - - 25 - - - -

8-3-10 25 1364.52 817 2787 609.24 25 357.44 326 567 58.518-4-8 25 645228.72 34335 1728147 557400.35 25 73378.20 1702 128244 35064.888-5-6 25 514.32 141 1868 448.47 25 150.12 88 478 81.428-6-5 25 3267.40 737 9910 2052.95 25 1599.56 709 3398 623.588-7-4 25 387.68 318 628 99.58 25 623.28 612 627 3.798-8-5 1 360850.00 360850 360850 - 4 110801.75 17216 231488 108721.69

9-3-12 7 666491.29 25422 1651481 555930.77 23 1255300.13 141441 1665287 504523.949-4-9 22 617761.77 130294 1730155 408524.24 25 88757.84 5757 221349 79629.579-5-7 25 6592.60 539 25473 6710.49 25 2436.80 367 2752 620.879-6-6 25 172858.84 9311 623561 146588.23 25 21835.44 3554 80217 18336.299-7-5 25 140637.88 1416 399217 136093.74 25 27098.72 11100 219599 40335.299-8-4 25 3038.52 523 13720 2770.35 25 2346.60 1100 8075 1370.049-9-5 0 > timeout - - - 0 > timeout - - -

10-3-13 25 26084.48 2556 147100 33926.09 25 5236.48 5028 6245 366.5710-4-10 25 623633.80 7978 1621904 499936.50 25 35370.16 5106 188993 43631.8010-5-8 25 50607.92 4903 248753 64582.17 25 2552.92 1507 13054 2298.7910-6-7 0 > timeout - - - 2 690095.00 400290 979900 409846.1610-7-5 25 432.84 427 453 5.09 25 571.12 440 810 131.3410-8-5 0 > timeout - - - 6 649583.50 56880 1700091 645722.9610-9-4 25 48836.48 48434 49487 241.94 25 8606.80 1210 31984 7252.18

10-10-3 25 - - - - 25 - - - -

Table 7.14: Run-time (in milliseconds) for both greedy integer and set approaches tothe Social Golfer Problem.

Number of iterationsinstance integer model set modelg-s-w n average min. max. std.dev. n average min. max. std.dev.6-3-8 25 504512.00 7942 1712112 499861.92 25 954759.16 57931 2410209 613809.976-4-6 25 246776.36 3348 1084118 262037.90 25 38773.80 4725 476238 92094.636-5-6 19 291178.42 1098 744215 218330.32 4 251618.50 11756 394891 166077.206-6-3 25 - - - - 25 - - - -7-3-9 25 8018.60 1069 41916 9739.49 25 10033.92 229 51986 11260.627-4-7 23 393089.83 126661 1073481 214864.86 25 68268.76 2293 221724 56013.797-5-6 0 - - - - 3 167681.00 14671 359625 175741.887-6-4 25 22.00 22 22 0.00 25 65.40 37 180 44.627-7-8 25 - - - - 25 - - - -

8-3-10 25 646.92 114 1961 579.63 25 347.16 268 1049 185.938-4-8 25 362702.00 10331 991350 312743.58 25 60503.64 1471 87704 25582.398-5-6 25 325.76 54 1359 334.92 25 63.00 52 312 51.968-6-5 25 963.28 89 2743 798.72 25 314.28 160 990 196.258-7-4 25 117.00 117 117 0.00 25 137.00 137 137 0.008-8-5 1 12983.00 12983 12983 - 4 5180.75 382 11075 5530.55

9-3-12 7 529810.86 16595 1310132 473111.38 23 1669180.70 200238 1973517 678278.309-4-9 22 306456.14 73460 789029 194273.69 25 61914.48 4761 171076 53676.169-5-7 25 2429.68 114 9954 2559.48 25 1827.20 111 2060 528.979-6-6 25 49404.48 1241 165534 42640.43 25 7364.84 421 25694 6963.259-7-5 25 36275.92 198 104898 36195.72 25 5575.64 4137 40103 7193.209-8-4 25 833.08 87 4005 826.88 25 741.00 195 1845 374.219-9-5 0 - - - - 0 - - - -

10-3-13 25 23460.68 768 154428 36257.06 25 7887.00 7887 7887 0.0010-4-10 25 300694.04 2244 853477 238369.53 25 19753.96 2809 90708 22953.8310-5-8 25 17857.28 1200 103464 26219.29 25 672.24 501 3837 660.0310-6-7 0 - - - - 2 143685.50 104037 183334 56071.4510-7-5 25 37.40 36 47 2.24 25 44.12 43 45 1.0110-8-5 0 - - - - 6 109929.83 9652 284892 108454.8310-9-4 25 8274.00 8274 8274 0.00 25 2077.08 114 8369 1854.68

10-10-3 25 - - - - 25 - - - -

Table 7.15: Number of iterations for both greedy integer and set approaches to theSocial Golfer Problem.

113

s = 3 s = 4 s = 5 s = 6 s = 7 s = 8 s = 9 s = 10g w ∆(w) w ∆(w) w ∆(w) w ∆(w) w ∆(w) w ∆(w) w ∆(w) w ∆(w)6 8 0 6 0 6 0 3 0 - - - - - - - -7 9 0 7 0 6 -1 4 -1 8 0 - - - - - -8 10 0 8 0 6 0 5 -3 4 0 5 -4 - - - -9 12 0 9 0 7 0 6 -3 5 0 4 0 5 -5 - -

10 13 0 10 0 8 0 7 +1 5 0 5 +1 4 0 3 0

Table 7.16: Instances solved with both integer and set CBLS approaches to the SocialGolfer problem.

7.2.4 Solved InstancesThe solved instances are shown in Table 7.16 where bold entries indicate thenumber of weeks that were equated or surpassed with respect to Table 7.2.Even though the number of weeks did not always reach the values given inTable 7.2, many times they did and moreover a couple of times these numberwere exceeded using the set approach.

7.3 ConclusionThe results of this experiment show that the effect of set variables for CBLSis not only a convenience for faster and higher-level modeling:

• Since the local search is constraint-based, the search procedure was moreeasily expressed using the constraints on set variables. The reader shouldagree that Lines 86 to 99 in Listing 15.5 are practically a literal translationof the the basic idea behind the search procedure for the set approach givenin Section 7.1.2.2. The problem with the integer couterpart is that the notionof slot is outside the domain of the problem specification.

• The set approach could sometimes be necessary since most of the instancesreported less search time and furthermore the instances golf-10-6-7and golf-10-8-5 were solved with the set approach only, while none ofthe sources for this project reports a solution found for any of these two in-stances using a tabu-search meta-heuristic. However, more elaborated tech-niques (with interesting symmetry-breaking schemes) can also find theseinstances as in [6].

The experiment also shows that even though the integer model introducesan arbitrary ordering of the slots in order to avoid using set variables (tak-ing advantage of the known fixed group size), the set model model does notincrease the model’s complexity and furthermore gives better performance.

114

8. Steiner Triple Systems(sts-v)

Given three integers t, k and v such that 2 ≤ t < k < v, a Steiner systemdenoted by S(t, k, v) is a set V of cardinality v together with a set of subsetsof V called a set of blocks, such that the cardinality of each block is k andeach subset of V of cardinality t is contained in exactly one block.

It was the nineteenth century geometer Jakob Steiner (Utzenstorf 1796 –1863 Bern) who posed the question of the existence of Steiner systems as hewent to ask about S(t, t + 1, v) [5]. Unaware of the earlier work of Kirk-man (Bolton 1806 – 1895 Bowdon), who had given a construction method forSteiner triple systems of order v = 1 mod 6 and v = 3 mod 6, in 1853Steiner first asked about S(2, 3, v).1

No Steiner systems are known with t larger than five. The problem of find-ing a Steiner triple system2 of order v can be formulated as follows:

Find a set of v·(v−1)6 triples of distinct integer elements in {1, . . . , v}

such that any two triples have at most one common element.

A Steiner triple system of order v is denoted by sts-v and stands for S(2, 3, v)where blocks have cardinality three and are hence called triples. Any triplet ∈ Sv (where Sv is the set of blocks) contains three subsets of cardinality twoand, likewise, V contains v·(v−1)

2 subsets of cardinality 2 (pairs). As each pairof V appears in exactly one triple, the equality 3 · |Sv| = v·(v−1)

2 holds andthus |Sv| = v·(v−1)

6 . Requiring any two triples to have at most one commonelement ensures that no pair will appear in more than one triple.

As it was shown by Kirkman in 1847 (six years before Steiner posed thequestion on their existence!), a Steiner triple system of order v exists if andonly if v ≡ 1 or v ≡ 3 mod 6 [5].

As an example, a solution to sts-7 (note 7 ≡ 1 mod 6) is :

S7 = {{1, 2, 6} , {1, 3, 5} , {2, 3, 4} , {3, 6, 7} , {2, 5, 7} , {1, 4, 7} , {4, 5, 6}}

where, clearly, |S7| = 7·(7−1)6 = 7.

1In Kirkman’s schoolgirl problem, if one lets each group of three girls, who walk togetherduring the course of the week, be a block; since the problem terms require that every two girlswalk together exactly once during the week, the solution is actually a Steiner triple system.2Steiner triple systems is problem number 44 at http://www.csplib.org/

115


8.1 The ExperimentThe experiment aims to demonstrate, by solving sts-v for as big as possiblevalues of v, that the effect of set variables for CBLS is not only a conveniencefor faster and higher-level modeling but it could also sometimes be necessarybecause problem instances with integer variables would not fit into memoryor take much more time to be solved.

Two different approaches are compared: one using an integer model of theproblem and the other using a set model of the problem as proposed in [12]for Constraint Programming (notice that only the declarative part of the mod-els are taken from [12] since Constraint-based Local Search and ConstraintProgramming are two very different techniques). These models have been im-proved with global constraints and implementations for both approaches havebeen developed from scratch.

8.1.1 ModelThe sts-v problem is modeled as both a CSP and a set-CSP as explained in[12]. On the one hand, the integer model uses three integer variables rangingover Nv = {1, . . . , v} to represent a triple {X,Y, Z} ∈ Sv. Ordering con-straints are required between the three variables in a triple (X < Y < Z)so as to remove equivalent triples under permutation of elements; and, sinceany triple must have at most one element in common with the other triples,constraints are required to ensure each pair of a triple to be pairwise distinctfrom any other pair appearing in another triple. As this would require con-straint all the v·(v−1)

2 possible ordered pairs (3 per triple {X,Y, Z}: (X,Y ),(X,Z), and (Y, Z)) to be pairwise different, a better idea is to apply theSocialTournament global constraint defined in Section 7.1.1.2.

On the other hand, if each triple is represented as one set variable, thenthe modeling is simpler and requires fewer variables. Such a modeling corre-sponds to a set model which uses v·(v−1)

6 set variables. Also the constraintsapplied between the possible pairs of each triple become one constraint be-tween two triples (read set variables). An even better idea is to use one singleconstraint using the GlobalAtMost1 constraint defined in Section 7.1.1.4.

8.1.1.1 CSPClearly, U = V 3 = Nv. Given:

• a set of blocks indexed by N|Sv | =[1, v·(v−1)

6

]and

• a set to index slots N3

the CSP for sts-v is given by:

• V ={M(t,s) | t ∈ N|Sv |, s ∈ N3

};

3please, do not confuse this V with the V used to denote the set of variables in the CSP

116

• D = U ; and

• C =⋃

t1<t2∈N|Sv |i1,i2∈N3j1,j2∈N3

{PairDifferent

((M(t1,i1),M(t1,j1)

),(M(t2,i2),

M(t2,j2)

))| i1 < j1 ∧ i2 < j2

}where the PairDifferent(P1, P2) constraint is satisfied if and only if the pairof pairs of integer variables P1 and P2 take different values.

A better model using just one SocialTournament constraint, called herefor the sake of clarity GlobalPairDifferent constraint, would be given by:

• V ={M(t,s) | t ∈ N|Sv |, s ∈ N3

};

• D = U ; and

• C ={

GlobalPairDifferent(N|Sv |,N3, U, V

)}Notice symmetry breaking constraints could have been introduced in the pro-posed CSPs, nevertheless the model introduces an arbitrary ordering of theslots and they are ignored. The search procedure will guarantee the cardinal-ity constraints always hold.

8.1.1.2 PairDifferent and GlobalPairDifferent ConstraintsIn order to define the PairDifferent constraint as a differentiable con-straint, it is necessary to define its constraint measures and differentiationfunctions.

First, for a configuration k, Penalty(PairDifferent)(k) returns 1 if the twopairs of variables (X1, Y1) and (X2, Y2) in vars(PairDifferent) are equal,and 0 otherwise, i.e.,:

Penalty(PairDifferent) ((X1, Y1), (X2, Y2)) (k) = (k (X1) = k (X2) ∧k (Y1) = k (Y2))? 1 : 0

Second, for simplicity, the conflict (PairDifferent) function simple returns thepenalty of the constraint, i.e.,

∀X ∈vars(PairDifferent) :conflict (PairDifferent)(X, k) = penalty(PairDifferent)(k)

Finally, the δ-assign(PairDifferent)(k, `) differentiation function is definedsuch that it returns: −1 whenever penalty(PairDifferent)(k) is equal to 1 (andpenalty(PairDifferent)(`) = 0); 1 whenever penalty(PairDifferent)(`) is equal to1 (and penalty(PairDifferent)(k) = 0); and 0 otherwise.

As the name hints, the GlobalPairDifferent serves as a global constraintaimed to replace the pairwise use of the PairDifferent constraint; its seman-tics is the same as for the SocialTournament constraint (described in Sec-tion 7.1.1.2).

117

8.1.1.3 Set-CSPGiven U = Nv and also a set of blocks indexed by NSv , a set-CSP for sts-vis given by:

• V ={S(t) | t ∈ NSv

};

• D = P(U); and

• C =⋃

t1<t2∈NSv

{PairAtMost1

(S(t1), S(t2)

)}Nevertheless, a better model using the GlobalAtMost1 constraint would be

given by:

• V ={S(t) | t ∈ NSv

};

• D = P(U); and

• C = {GlobalAtMost1 (NSv , U, V )}Notice the symmetry breaking constraint are not ignored but unnecessary in

the models due to the use of set variables. The search procedure will take careof the cardinality constraints and thereby become implicit. The GlobalAtMost1constraint has already proved its efficiency in the experiment for the SocialGolfer Problem (see Chapter 7).

8.1.2 Search HeuristicSince the problem was modeled both as a CSP and a set-CSP, one CBLSalgorithm is needed for each approach.


1 while the GlobalPairDifferent constraint is (alternatively allPairDifferent constraints are) not satisfied

2 select a variable M(t,s) (in V ) such that its conflict is maximum3 select a value u (in D) such that the increase in violations by

assigning u to M(t,s) is minimum (and for all s′ ∈ N3,u 6= k

(M(t,s′)

)).

4 assign u to M(t,s)

which is enhanced with tabu list, aspiration criteria, intensification, and restarts.The search heuristic is shown in Figure 8.1. Both the neighborhood and themeta-heuristics used by this local search algorithm are explained below.

118

INT-STEINER-TRIPLE-SYSTEM-LS(Nv)1 forall t ∈ Nv

2 tabu[t]← ∅3 k∗ ← k ← initial configuration4 it ← n← 05 maxNonImproving ← 2506 restartFreq ← 10007 τ ← 128 while penalty(GlobalPairDifferent)(k) > 0 ∧ timeout not expired

9 select assign(M(t,s),u)(k) ∈(

ASSIGN t(V )(k, it) ∪

ASSIGN ∗(V )(k, k∗))

10 minimizing penalty(GlobalPairDifferent)

(assign(M(t,s),u)(k)

)11 tabu[t]← tabu[t] ∪ {〈s, u, it + τ〉}12 k ← assign(M(t,s),u)(k)13 if penalty(GlobalPairDifferent)(k) < penalty(GlobalPairDifferent)(k∗)14 k∗ ← k15 n← 016 elseif n > maxNonImproving17 k ← k∗

18 n← 019 forall t ∈ Nv

20 tabu[t]← ∅21 else22 n← n+ 123 it ← it + 124 if it mod restrartFreq = 025 k ← new random configuration26 k∗ ← k27 forall t ∈ Nv

28 tabu[t]← ∅29 n← 0

Figure 8.1: CBLS algorithm for the integer approach to find a Steiner triple system.

8.1.2.1.1 NeighborhoodThe neighborhood is the set of moves consisting in assigning a new elementto a triple such that the new triple still has (three) distinct elements:

S(k) ={

assign(M(t,s),u)(k) | u ∈ D ∧ ∀s′ ∈ N3 : u 6= k(M(t,s′)

)}119

Restricting the attention to assignments involving just a most conflictingvariable, the neighborhood becomes:

S′(k) ={

assign(M,u)(k) | assign(M,u)(k) ∈ S(k) ∧conflict (GlobalPairDifferent) (M,k) =

maxM ′∈V

conflict (GlobalPairDifferent)

(M ′, k

)}which ensures that the algorithm focuses on assignments which decrease thenumber of violations. The neighborhood is then:

ASSIGN (V )(k) ={

assign(M,u)(k) | assign(M,u)(k) ∈ S′(k) ∧ M ∈ V}

8.1.2.1.2 Meta-HeuristicsFirst, the tabu component of the algorithm features a tabu-list of length 12 (avalue chosen arbitrarily) distributed across the various triples. Each triple thas an associated tabu list tabu[t] which maintains triplets 〈i, v, j〉 where v isan element in D, i specifies one of the three slots of the triple and j representsthe first iteration where it is allowed to assign (again) v to the ith position ofthe triple. The fact that assigning v at iteration it to some slot i of a triplet is forbidden is denoted by tabu[t](i, v, it) and therefore tabu[t](i, v, it) ↔〈i, v, j〉 ∈ tabu[t] ∧ j ≤ it . As a result, given a configuration k and aniteration j, the neighborhood is actually:

ASSIGN t(V )(k, j) =

{assign(M(t,s),u)(k) |

assign(M(t,s),u)(k) ∈ ASSIGN (V )(k)

∧ ¬tabu[t] (s, u, j)}

Second, in addition to the non-tabu moves, the neighborhood of the movesimproving the so far best solution is also considered. This neighborhood isgiven by:

ASSIGN ∗(V )(k, k∗) =

{assign(k) | assign(k) ∈ ASSIGN (V )(k)

∧ penalty(GlobalPairDifferent) (assign(k)) <

penalty(GlobalPairDifferent) (k∗)}

Third, an intensification component is added which reinitializes the searchfrom the so-far best solution and resets the tabu-list whenever the so-far bestsolution has not been improved upon a maximum number of non-improvingiterations.

Finally, the restarting component reinitializes the search from a possiblyrandom configuration whenever a threshold on the number of iterations has

120

been reached. Notice that the assignment moves cannot violate cardinalityconstraints and likewise they do keep all the triples containing different values.


1 while the GlobalAtMost1 constraint is (alternatively allPairAtMost1 constraints are) not satisfied

2 select a triple T (in V ) such that its conflict is maximum3 select two values: v in D \ k(T ) and u in k(T ) such that the

increase in violations by flipping u to v in T is minimum4 flip u to v in T

which is enhanced with tabu list, aspiration criteria, intensification and restarts.The search heuristic is shown in Figure 8.2. Both the neighborhood and meta-heuristics used by this local search algorithm are explained below.

8.1.2.2.1 NeighborhoodThe neighborhood of the local search is the set of moves consisting in flippingone value in a triple such that the triple still has (three) distinct elements:

S(k) ={

flip(T,u,v)(k) | v ∈ U \ k(T ) ∧ u ∈ k(T )}

Restricting the attention to flip moves involving just the most conflicted vari-able, the neighborhood becomes:

S′(k) ={

flip(T,u,v)(k) | flip(T,u,v)(k) ∈ S(k) ∧conflict (Global≤1) (T, k) =

maxT ′∈V

conflict (Global≤1)

(T ′, k

)}which ensures that the algorithm focuses on assignments which decrease thenumber of violations. The neighborhood is then:

FLIP (V )(k) ={

flip(T,u,v)(k) | flip(T,u,v)(k) ∈ S′(k) ∧ T ∈ V}

8.1.2.2.2 Meta-HeuristicsFirst, the tabu component of the algorithm features a tabu-list of length 12distributed across the various triples. Each triple t has an associated tabu listtabu[t] and each of these lists maintains triplets 〈u, v, j〉 where j representsthe first iteration where it is allowed to flip (again) u to v in the triple t. Thefact that flipping u to v at iteration it is forbidden for a triple t is denoted bytabu[t](u, v, it) and therefore tabu[t](u, v, it)↔ 〈u, v, j〉 ∈ tabu[t] ∧ j ≤ it .As a result, given a configuration k and an iteration j, the neighborhood is

121

SET-STEINER-TRIPLE-SYSTEM-LS(Nv)1 forall t ∈ Nv

2 tabu[t]← ∅3 k∗ ← k ← initial configuration4 it ← n← 05 maxNonImproving ← 2506 restartFreq ← 10007 τ ← 128 while penalty(Global≤1)(k) > 0 ∧ timeout not expired

9 select flip(T,u,v)(k) ∈(

FLIP t(V )(k, it) ∪ FLIP∗(V )(k, k

∗))

10 minimizing penalty(Global≤1)

(flip(T,u,v)(k)

)11 tabu[t]← tabu[t] ∪ {〈u, v, it + τ〉}12 k ← flip(T,u,v)(k)13 if penalty(Global≤1)(k) < penalty(Global≤1)(k∗)14 k∗ ← k15 n← 016 elseif n > maxNonImproving17 k ← k∗

18 n← 019 forall t ∈ Nv

20 tabu[t]← ∅21 else22 n← n+ 123 it ← it + 124 if it mod restrartFreq = 025 k ← new random configuration26 k∗ ← k27 forall t ∈ Nv

28 tabu[t]← ∅29 n← 0

Figure 8.2: CBLS algorithm for the set approach to find a Steiner triple system.

actually:

FLIP t(V )(k, j) =

{flip(T,u,v)(k) | flip(T,u,v)(k) ∈ FLIP (V )(k) ∧

¬tabu[t] (u, v, j)}

Second, in addition to the non-tabu moves, the neighborhood of the movesimproving the so far best solution is also considered. This neighborhood is

122

given by:

FLIP∗(V )(k, k∗) = {flip(k) | flip(k) ∈ FLIP (V )(k) ∧

penalty(Global≤1) (flip(k)) < penalty(Global≤1) (k∗)}

Third, an intensification component is added which reinitializes the searchfrom the so-far best solution and resets the tabu-list whenever the so-far bestsolution has not been improved upon a maximum number of non-improvingiterations.

Finally, the restarting component reinitializes the search from a possiblyrandom configuration whenever a threshold on the number of iterations hasbeen reached. Notice that the flip moves can never violate cardinality con-straints and likewise they do keep all the triples containing different values.

8.1.3 Setup of the Experiment8.1.3.1 Problem Instances and Initial ConfigurationsFor each of the approaches Steiner triple systems are tried from order 7 tothe maximum possible value. However, initial configurations are (randomly)created separately and the search with all of the approaches starts from thesame initial configuration.

8.1.3.2 The ImplementationThe implementation of both the CBLS algorithm for the integer approachand the CBLS algorithm for the set approach were made from scratch usingComet. The source code for this implementation can be found respectively inSections 15.3 and 15.4.

8.1.3.2.1 CBLS for the Integer ApproachThe implementation of the CBLS algorithm for the integer approach requiredthe implementation of the PairDifferent and GlobalPairDifferent constraintsdescribed in Section 8.1.1.2. The implementation of the GlobalPairDifferentconstraint (given in Listing 15.12) roughly resembles the implementation ofthe SocialTournament constraint (given in Listing 15.2), the main differ-ence is that the GlobalPairDifferent constraint required and adjustment inthe types of the incremental variables. For the same reason, a new version ofthe Meet invariant (shown in Listing 15.3) was necessary (see Listing 15.13).

8.1.3.2.2 CBLS for the Set ApproachContrasting the implementation of the CBLS algorithm for the integer ap-proach, the implementation for the set approach did not require the implemen-tation of any new constraint. However, instead of providing an adjusted imple-mentation of the GlobalAtMost1 constraint, the same implementation given

123

Integer model without a global constraintinstance time (miliseconds) iterations restores/v n average min. max. std.dev. average min. max. std.dev. restarts7 25 1.08 1 2 0.28 4.96 4 5 0.20 0 / 09 25 17.24 5 23 2.82 31.56 10 43 5.00 0 / 0

13 25 178.08 138 244 15.81 92.24 70 120 7.26 0 / 015 25 766.92 288 4398 759.70 242.44 90 1439 250.25 3 / 119 25 3559.16 1629 4079 437.90 494.80 237 509 56.21 0 / 021 25 5849.72 3687 6125 633.08 604.48 385 623 64.13 23 / 025 19 9604.26 7414 12532 864.58 577.42 448 765 53.82 1 / 0

Table 8.1: Run-time (in milliseconds) and number of iterations for the integer ap-proach to find Steiner triple systems.

Integer model without a global constraintinstance mem GC Usage mem VM Usage iterations per secondv n average min. max. std.dev. average min. max. std.dev. average min. max. std.dev.7 25 26388.84 18419 31532 4245.04 48496.64 32768 65536 16708.47 4760.00 2500.00 5000.00 708.879 25 48120.80 25230 67280 12229.02 78643.20 65536 131072 26754.96 1836.35 1777.78 2000.00 62.03

13 25 169578.24 59074 326620 68578.50 309329.92 131072 524288 145955.60 518.29 491.80 525.71 6.6615 25 293053.44 93454 467643 106536.84 566231.04 262144 1048576 269469.07 313.39 309.64 327.19 3.3319 25 790250.76 234325 1388474 360877.21 1384120.32 524288 2097152 621821.19 139.29 124.79 145.49 3.6721 25 1151684.40 337375 1873003 454053.73 1761607.68 1048576 2097152 499222.03 103.37 101.71 104.55 0.7325 19 1932524.95 673838 3086902 792397.05 3311292.63 2097152 4194304 1063795.61 60.11 59.40 61.04 0.42

Table 8.2: Memory usage and number of iterations per second for the integer approachto find Steiner triple systems.

in Listing 15.6 was used together with an insignificant trick when declaringthe types of incremental variables in Line 15 of Listing 15.15.

8.1.3.3 The MachineAll programs were run on ASTRA’s experiment server ghoul, a machinewith an Intel Core i7-950 processor and 3 gigabytes of RAM. A timeout of 15minutes per instance was set and each instance was run 25 times.

8.2 Results8.2.1 Integer ApproachThis section presents results for both integer approaches to sts-v (with andwithout a global constraint).

8.2.1.1 Without a Global ConstraintThis section presents results for the integer approach to sts-v in terms ofrun-time (in milliseconds) and number of iterations in Table 8.1 and in termsof memory and iterations per second in Table 8.2.

124

Integer model with a global constraintinstance time (miliseconds) iterations restores/v n average min. max. std.dev. average min. max. std.dev. restarts7 25 0.16 0 1 0.37 5.76 4 11 1.76 0 / 09 25 0.36 0 1 0.49 16.28 16 22 1.21 0 / 0

13 25 4.96 2 11 2.46 122.24 35 283 62.74 0 / 015 25 6.96 4 14 2.85 146.32 72 310 65.75 0 / 019 22 18.73 11 24 3.97 283.77 154 330 65.35 0 / 021 22 16.32 12 34 5.94 250.68 190 572 102.43 0 / 025 20 38.90 32 66 7.85 497.70 411 883 104.28 0 / 027 19 46.89 35 71 9.15 501.47 384 826 121.93 0 / 031 6 71.83 49 92 13.79 634.50 402 806 136.44 0 / 0

Table 8.3: Run-time (in milliseconds) and number of iterations for the integer ap-proach to find Steiner triple systems using a global constraint.

Integer model with a global constraintinstance mem GC Usage mem VM Usage iterations per secondv n average min. max. std.dev. average min. max. std.dev. average min. max. std.dev.7 25 15992.24 15908 16004 18.02 32768.00 32768 32768 0.00 - 5000.00 - -9 25 16221.28 16112 16233 23.12 32768.00 32768 32768 0.00 - 16000.00 - -

13 25 19130.48 16582 21328 2127.21 32768.00 32768 32768 0.00 24570.81 17333.33 33000.00 4021.2815 25 20278.36 17358 21855 2033.34 32768.00 32768 32768 0.00 20843.04 17833.33 23400.00 1785.7219 22 21481.77 17888 22474 1810.32 32768.00 32768 32768 0.00 15084.50 12833.33 16500.00 985.5821 22 23604.00 20185 24517 1639.22 32768.00 32768 32768 0.00 15223.33 14500.00 16823.53 701.7025 20 28062.05 20663 34540 4540.35 60620.80 32768 65536 12004.48 12794.13 11339.62 13431.82 480.5327 19 27372.89 21035 34569 4628.97 60362.11 32768 65536 12276.02 10648.50 9440.00 12058.82 753.4731 6 28097.00 22430 30903 3431.71 60074.67 32768 65536 13377.48 8797.48 8183.10 9342.11 504.68

Table 8.4: Memory usage and number of iterations per second for the integer approachto find Steiner triple systems using a global constraint.

Note the integer approach found Steiner Triple systems of order up to 19.

8.2.1.2 With the Global ConstraintThis section presents results for the integer approach to sts-v using theglobal constraint in terms of run-time (in milliseconds) and number of iter-ations in Table 8.3 and in terms of memory an iterations per second in Ta-ble 8.4.Note the integer approach using a global constraint was only slightly better asit found Steiner Triple systems of order up to 25.

8.2.1.3 ComparisonThis section presents a comparison between the integer approaches to sts-vwith and without the global constraint in terms of run-time (in milliseconds)and number of iterations in Tables 8.5, 8.6 and 8.7; and in terms of memoryin Tables 8.8 and 8.9.

125

Run time (miliseconds)instance Integer model w-out/global constraint Integer model w/global constraint

v n average min. max. std.dev. n average min. max. std.dev.7 25 1.08 1 2 0.28 25 0.16 0 1 0.379 25 17.24 5 23 2.82 25 0.36 0 1 0.49

13 25 178.08 138 244 15.81 25 4.96 2 11 2.4615 25 766.92 288 4398 759.70 25 6.96 4 14 2.8519 25 3559.16 1629 4079 437.90 22 18.73 11 24 3.9721 25 5849.72 3687 6125 633.08 22 16.32 12 34 5.9425 19 9604.26 7414 12532 864.58 20 38.90 32 66 7.8527 ? - - - - 19 46.89 35 71 9.1531 ? - - - - 6 71.83 49 92 13.79

Table 8.5: Run-time (in milliseconds) for both integer approaches to find Steiner triplesystems (with and without a global constraint).

Number of iterationsinstance Integer model w-out/global constraint Integer model w/global constraint


13 25 92.24 70 120 7.26 25 122.24 35 283 62.7415 25 242.44 90 1439 250.25 25 146.32 72 310 65.7519 25 494.80 237 509 56.21 22 283.77 154 330 65.3521 25 604.48 385 623 64.13 22 250.68 190 572 102.4325 19 577.42 448 765 53.82 20 497.70 411 883 104.2827 ? - - - - 19 501.47 384 826 121.9331 ? - - - - 6 634.50 402 806 136.44

Table 8.6: Number of iterations for both integer approaches to find Steiner triple sys-tems (with and without a global constraint).

Iterations per secondinstance Integer model w-out/global constraint Integer model w/global constraint

v n average min. max. std.dev. n average min. max. std.dev.7 25 4760.00 2500.00 5000.00 708.87 25 - 5000.00 - -9 25 1836.35 1777.78 2000.00 62.03 25 - 16000.00 - -

13 25 518.29 491.80 525.71 6.66 25 24570.81 17333.33 33000.00 4021.2815 25 313.39 309.64 327.19 3.33 25 20843.04 17833.33 23400.00 1785.7219 25 139.29 124.79 145.49 3.67 22 15084.50 12833.33 16500.00 985.5821 25 103.37 101.71 104.55 0.73 22 15223.33 14500.00 16823.53 701.7025 19 60.11 59.40 61.04 0.42 20 12794.13 11339.62 13431.82 480.5327 ? - - - - 19 10648.50 9440.00 12058.82 753.4731 ? - - - - 6 8797.48 8183.10 9342.11 504.68

Table 8.7: Iterations per second for both integer approaches to find Steiner triple sys-tems (with and without a global constraint).

126

GC memory usage (KB)instance Integer model w-out/global constraint Integer model w/global constraint

v n average min. max. std.dev. n average min. max. std.dev.7 25 26388.84 18419 31532 4245.04 25 15992 15908 16004 18.029 25 48120.80 25230 67280 12229.02 25 16221 16112 16233 23.12

13 25 169578.24 59074 326620 68578.50 25 19130 16582 21328 2127.2115 25 293053.44 93454 467643 106536.84 25 20278 17358 21855 2033.3419 25 790250.76 234325 1388474 360877.21 22 21482 17888 22474 1810.3221 25 1151684.40 337375 1873003 454053.73 22 23604 20185 24517 1639.2225 19 1932524.95 673838 3086902 792397.05 20 28062 20663 34540 4540.3527 ? - - - - 19 27373 21035 34569 4628.9731 ? - - - - 6 28097 22430 30903 3431.71

Table 8.8: GC-memory for both integer approaches to find Steiner triple systems (withand without a global constraint).

VM memory usage (KB)instance Integer model w-out/global constraint Integer model w/global constraint


13 25 309329.92 131072 524288 145955.60 25 32768 32768 32768 0.0015 25 566231.04 262144 1048576 269469.07 25 32768 32768 32768 0.0019 25 1384120.32 524288 2097152 621821.19 22 32768 32768 32768 0.0021 25 1761607.68 1048576 2097152 499222.03 22 32768 32768 32768 0.0025 19 3311292.63 2097152 4194304 1063795.61 20 60621 32768 65536 12004.4827 ? - - - - 19 60362 32768 65536 12276.0231 ? - - - - 6 60075 32768 65536 13377.48

Table 8.9: VM-memory for both integer and set approaches to find Steiner triple sys-tems (with and without a global constraint).

Set model model w-out/global constraintinstance time (miliseconds) iterations restores/v n average min. max. std.dev. average min. max. std.dev. restarts7 25 0.64 0 1 0.49 9.08 7 13 0.91 0 / 09 25 5.76 3 8 0.88 47.52 23 69 7.91 0 / 0

13 25 22.24 12 47 5.96 70.64 38 149 18.68 0 / 015 25 258.96 69 306 79.28 582.04 151 677 179.86 0 / 019 25 468.36 200 549 78.93 557.00 223 644 96.54 0 / 021 25 1494.44 629 1710 272.29 1353.48 570 1548 247.44 0 / 025 25 2143.72 1345 4087 496.70 1209.80 760 2343 287.76 0 / 027 25 1978.88 1683 5679 815.09 880.32 765 2571 371.49 0 / 031 25 6885.32 3607 7302 869.28 2078.12 1068 2183 268.31 0 / 033 25 6690.00 4919 17122 2289.53 1634.80 1100 4233 573.99 0 / 037 25 12400.28 8733 21913 2556.04 2114.12 1533 3802 444.25 0 / 039 25 22266.52 12245 56394 7468.13 3197.92 1810 7890 1035.79 0 / 043 25 23998.16 22551 32082 2613.55 2595.12 2479 3568 287.40 0 / 045 25 33613.52 29319 42607 2442.31 3117.16 2751 3910 217.07 0 / 049 25 55007.84 39854 87198 7671.46 3724.08 2767 5799 500.09 0 / 051 25 78013.36 48943 102867 9628.33 4882.68 3130 6467 616.50 0 / 0

Table 8.10: Run-time (in milliseconds) and number number of iterations for the setapproach to find Steiner triple systems.

127

Set model w-out/global constraintinstance mem GC Usage mem VM Usage iterations per secondv n average min. max. std.dev. average min. max. std.dev. average min. max. std.dev.7 25 16243.44 16177 16250 14.17 32768.00 32768 32768 0.00 - 9000.00 - -9 25 17029.12 16585 17155 224.28 32768.00 32768 32768 0.00 8246.33 6600.00 9800.00 584.61

13 25 21683.80 18960 23179 2013.78 32768.00 32768 32768 0.00 3180.65 2840.00 3444.44 113.7215 25 25884.56 21380 27516 1802.80 58982.40 32768 65536 13377.48 2244.17 2148.44 2285.71 27.6219 25 40035.72 31245 44236 4691.31 65536.00 65536 65536 0.00 1187.18 1115.00 1232.22 20.5821 25 50032.32 36105 66507 9511.34 81264.64 65536 131072 28566.48 905.55 891.96 915.56 5.4525 25 78850.28 59157 97003 12150.00 131072.00 131072 131072 0.00 563.92 555.78 573.28 4.0527 25 118279.84 76863 155090 25587.71 225443.84 131072 262144 60064.74 444.23 432.80 454.55 6.6031 25 176467.68 121330 241456 41264.46 325058.56 262144 524288 114265.92 301.66 296.09 305.49 2.4633 25 229867.04 149816 293700 46313.19 450887.68 262144 524288 120129.47 243.92 223.62 250.24 4.7937 25 335675.52 218307 466552 83901.59 639631.36 262144 1048576 240258.94 170.51 157.41 175.54 4.1439 25 427060.68 281425 609297 81525.07 901775.36 524288 1048576 240258.94 143.90 134.48 152.34 3.7143 25 619153.72 391612 910156 155616.85 1006632.96 524288 1048576 145168.77 108.14 103.46 111.50 1.5845 25 710855.44 475416 984685 176180.57 1300234.24 1048576 2097152 457063.68 92.76 91.41 94.15 0.7949 25 1016401.12 689980 1236653 189240.47 1845493.76 1048576 2097152 457063.68 67.75 66.50 71.53 1.1551 25 1144090.64 793856 1475152 230053.59 2013265.92 1048576 2097152 290337.55 62.57 60.03 63.95 0.75

Table 8.11: Memory usage and number of iterations per second for the set approachto find Steiner triple systems.

As expected, the solution using a global constraint was in general faster andrequired fewer iterations (and reported a better rate of iterations per second).It also required less memory and solved more instances.

8.2.2 Set ApproachThis section presents the results for both set approaches to sts-v (with andwithout a global constraint).

8.2.2.1 Without a Global ConstraintThis section presents results for the set approach to sts-v in Tables 8.10and 8.11.Note the set approach found Steiner Triple systems of order up to 51.

8.2.2.2 With the Global ConstraintThis section presents results for the set approach to sts-v using the globalconstraint in Tables 8.12 and 8.13.Note the set approach with a global constraint found Steiner Triple systems oforder up to 63 (and even more! – see Section 8.2.4).

8.2.2.3 ComparisonThis section presents a comparison between the set approaches to sts-vwithand without the global constraint in terms of run-time (in milliseconds) andnumber of iterations in Tables 8.14, 8.15 and 8.16; and in terms of memory inTables 8.17 and 8.18.

128

Set model with a global constraintinstance time (miliseconds) iterations restores/v n average min. max. std.dev. average min. max. std.dev. restarts7 25 0.60 0 1 0.50 6.24 4 10 1.27 0 / 09 25 1.96 1 3 0.73 16.00 10 30 5.58 0 / 0

13 25 9.16 5 17 3.74 58.56 24 121 28.48 0 / 015 25 15.36 12 22 2.18 75.64 53 116 12.82 0 / 019 25 31.20 14 55 11.31 178.96 95 301 58.13 0 / 021 25 52.36 18 89 15.55 335.80 96 353 60.75 0 / 025 25 57.84 29 102 18.05 267.60 140 378 60.54 0 / 027 25 74.36 46 142 26.66 398.20 209 609 87.28 0 / 031 25 139.60 76 200 46.16 451.04 337 672 59.09 0 / 033 25 238.84 185 311 36.34 595.36 399 829 120.79 0 / 037 25 252.52 149 503 96.25 795.52 477 1630 259.33 0 / 039 25 237.08 144 517 102.44 874.04 543 1387 218.31 0 / 043 25 386.52 265 692 130.67 896.96 811 1250 111.42 0 / 045 25 601.04 353 890 122.00 1441.40 911 1579 196.30 0 / 049 25 641.56 390 990 193.88 1349.76 1052 1869 229.58 0 / 051 25 657.20 496 1107 161.16 1534.88 1173 1757 145.55 0 / 055 25 906.24 550 1498 280.41 1835.32 1283 2341 317.98 0 / 057 25 753.88 642 878 64.85 1936.72 1490 2497 255.47 0 / 061 25 1084.16 1014 1413 80.76 2232.28 2052 3603 298.90 0 / 063 25 1299.64 1136 2665 300.16 1935.04 1796 2554 248.39 0 / 0

Table 8.12: Run-time (in milliseconds) and number number of iterations for the setapproach to find Steiner triple systems using a global constraint.

Set model with a global constraintinstance mem GC Usage mem VM Usage iterations per secondv n average min. max. std.dev. average min. max. std.dev. average min. max. std.dev.7 25 16224.24 16218 16236 4.59 32768.00 32768 32768 0.00 - 4000.00 - -9 25 16393.00 16372 16439 20.33 32768.00 32768 32768 0.00 8653.33 5500.00 13000.00 2277.57

13 25 17392.80 17273 17622 102.95 32768.00 32768 32768 0.00 6226.56 4800.00 7875.00 689.8415 25 17635.88 17544 17780 44.29 32768.00 32768 32768 0.00 4924.32 4235.29 5789.47 380.9419 25 20833.52 20513 21275 207.74 32768.00 32768 32768 0.00 6238.34 3800.00 10033.33 2445.1821 25 20774.68 20729 21423 153.28 32768.00 32768 32768 0.00 6682.79 3966.29 8022.73 1459.6825 25 27280.64 26674 27732 268.91 32768.00 32768 32768 0.00 4932.74 2768.12 6750.00 1396.9827 25 33988.48 31488 34732 604.80 65536.00 65536 65536 0.00 5764.74 2912.09 7303.03 1577.0031 25 38216.96 37488 41192 1097.11 65536.00 65536 65536 0.00 3560.68 2250.00 5333.33 1110.5633 25 54392.52 53140 55298 502.74 65536.00 65536 65536 0.00 2476.78 2156.76 2798.35 177.1537 25 65527.36 59409 67704 1470.60 131072.00 131072 131072 0.00 3411.21 1697.51 4728.89 1071.5639 25 89069.48 77736 90664 2474.11 131072.00 131072 131072 0.00 3910.65 2173.49 4968.00 742.7443 25 102778.96 102358 103826 421.41 131072.00 131072 131072 0.00 2513.06 1537.48 3281.69 659.0145 25 111574.80 109350 116976 1325.58 256901.12 131072 262144 26214.40 2481.93 1412.40 3352.17 545.6349 25 187522.08 185977 189342 951.21 262144.00 262144 262144 0.00 2265.82 1355.11 3493.46 682.9251 25 179527.44 177953 180387 484.24 262144.00 262144 262144 0.00 2429.77 1432.70 2907.09 466.6655 25 298037.92 225965 303412 15074.14 513802.24 262144 524288 52428.80 2145.50 1289.83 2803.44 505.9157 25 332622.88 330949 335401 1111.93 524288.00 524288 524288 0.00 2563.67 1943.35 2843.96 185.8761 25 359362.48 357646 363919 1167.39 524288.00 524288 524288 0.00 2053.51 1867.15 2549.89 118.6163 25 381990.16 380746 384155 709.02 524288.00 524288 524288 0.00 1517.49 950.84 1854.76 198.94

Table 8.13: Memory usage and number of iterations per second for the set approachto find Steiner triple systems using a global constraint.

129

Run time (miliseconds)instance set model w-out/global constraint set model w/global constraint


13 25 22.24 12 47 5.96 25 9.16 5 17 3.7415 25 258.96 69 306 79.28 25 15.36 12 22 2.1819 25 468.36 200 549 78.93 25 31.20 14 55 11.3121 25 1494.44 629 1710 272.29 25 52.36 18 89 15.5525 25 2143.72 1345 4087 496.70 25 57.84 29 102 18.0527 25 1978.88 1683 5679 815.09 25 74.36 46 142 26.6631 25 6885.32 3607 7302 869.28 25 139.60 76 200 46.1633 25 6690.00 4919 17122 2289.53 25 238.84 185 311 36.3437 25 12400.28 8733 21913 2556.04 25 252.52 149 503 96.2539 25 22266.52 12245 56394 7468.13 25 237.08 144 517 102.4443 25 23998.16 22551 32082 2613.55 25 386.52 265 692 130.6745 25 33613.52 29319 42607 2442.31 25 601.04 353 890 122.0049 25 55007.84 39854 87198 7671.46 25 641.56 390 990 193.8851 25 78013.36 48943 102867 9628.33 25 657.20 496 1107 161.1655 ? - - - - 25 906.24 550 1498 280.4157 ? - - - - 25 753.88 642 878 64.8561 ? - - - - 25 1084.16 1014 1413 80.7663 ? - - - - 25 1299.64 1136 2665 300.16

Table 8.14: Run-time (in milliseconds) for both set approaches to find Steiner triplesystems (with and without a global constraint).

As expected, the solution using a global constraint was faster and requiredfewer iterations (and reported a better rate of iterations per second). It alsorequired less memory and solved more instances.

8.2.3 Comparison Between the Integer and Set ApproachesThis section presents comparisons between the integer and set approaches tosts-v (with and without using a global constraint).

8.2.3.1 Without a Global ConstraintThis section presents a comparison between both integer and set approachesto sts-v in terms of run-time (in milliseconds) and number of iterations inTables 8.19, 8.20 and 8.21; and in terms of memory in Tables 8.22 and 8.23.Note the set approach was much faster and succeeded in many instances wherethe integer model failed. The integer model required fewer iterations in theinstances solved by both approaches, anyway the set approach reported betterrates of iterations per second. The set approach was also clearly superior inmemory terms.

8.2.3.2 With the Global ConstraintThis section presents a comparison between both integer and set approaches tosts-v using a global constraint constraint in terms of run-time (in millisec-

130

Number of iterationsinstance set model w-out/global constraint set w/global constraint


13 25 70.64 38 149 18.68 25 58.56 24 121 28.4815 25 582.04 151 677 179.86 25 75.64 53 116 12.8219 25 557.00 223 644 96.54 25 178.96 95 301 58.1321 25 1353.48 570 1548 247.44 25 335.80 96 353 60.7525 25 1209.80 760 2343 287.76 25 267.60 140 378 60.5427 25 880.32 765 2571 371.49 25 398.20 209 609 87.2831 25 2078.12 1068 2183 268.31 25 451.04 337 672 59.0933 25 1634.80 1100 4233 573.99 25 595.36 399 829 120.7937 25 2114.12 1533 3802 444.25 25 795.52 477 1630 259.3339 25 3197.92 1810 7890 1035.79 25 874.04 543 1387 218.3143 25 2595.12 2479 3568 287.40 25 896.96 811 1250 111.4245 25 3117.16 2751 3910 217.07 25 1441.40 911 1579 196.3049 25 3724.08 2767 5799 500.09 25 1349.76 1052 1869 229.5851 25 4882.68 3130 6467 616.50 25 1534.88 1173 1757 145.5555 ? - - - - 25 1835.32 1283 2341 317.9857 ? - - - - 25 1936.72 1490 2497 255.4761 ? - - - - 25 2232.28 2052 3603 298.9063 ? - - - - 25 1935.04 1796 2554 248.39

Table 8.15: Number of iterations for both set approaches to find Steiner triple systems(with and without a global constraint).

Iterations per secondinstance set model w-out/global constraint set w/global constraint

v n average min. max. std.dev. n average min. max. std.dev.7 25 - 9000.00 - - 25 - 4000.00 - -9 25 8246.33 6600.00 9800.00 584.61 25 8653.33 5500.00 13000.00 2277.57

13 25 3180.65 2840.00 3444.44 113.72 25 6226.56 4800.00 7875.00 689.8415 25 2244.17 2148.44 2285.71 27.62 25 4924.32 4235.29 5789.47 380.9419 25 1187.18 1115.00 1232.22 20.58 25 6238.34 3800.00 10033.33 2445.1821 25 905.55 891.96 915.56 5.45 25 6682.79 3966.29 8022.73 1459.6825 25 563.92 555.78 573.28 4.05 25 4932.74 2768.12 6750.00 1396.9827 25 444.23 432.80 454.55 6.60 25 5764.74 2912.09 7303.03 1577.0031 25 301.66 296.09 305.49 2.46 25 3560.68 2250.00 5333.33 1110.5633 25 243.92 223.62 250.24 4.79 25 2476.78 2156.76 2798.35 177.1537 25 170.51 157.41 175.54 4.14 25 3411.21 1697.51 4728.89 1071.5639 25 143.90 134.48 152.34 3.71 25 3910.65 2173.49 4968.00 742.7443 25 108.14 103.46 111.50 1.58 25 2513.06 1537.48 3281.69 659.0145 25 92.76 91.41 94.15 0.79 25 2481.93 1412.40 3352.17 545.6349 25 67.75 66.50 71.53 1.15 25 2265.82 1355.11 3493.46 682.9251 25 62.57 60.03 63.95 0.75 25 2429.77 1432.70 2907.09 466.6655 ? - - - - 25 2145.50 1289.83 2803.44 505.9157 ? - - - - 25 2563.67 1943.35 2843.96 185.8761 ? - - - - 25 2053.51 1867.15 2549.89 118.6163 ? - - - - 25 1517.49 950.84 1854.76 198.94

Table 8.16: Iterations per second for both set approaches to find Steiner triple systems(with and without a global constraint).

131

GC memory usage (KB)instance set model w-out/global constraint set w/global constraint


13 25 21683.80 18960 23179 2013.78 25 17393 17273 17622 102.9515 25 25884.56 21380 27516 1802.80 25 17636 17544 17780 44.2919 25 40035.72 31245 44236 4691.31 25 20834 20513 21275 207.7421 25 50032.32 36105 66507 9511.34 25 20775 20729 21423 153.2825 25 78850.28 59157 97003 12150.00 25 27281 26674 27732 268.9127 25 118279.84 76863 155090 25587.71 25 33988 31488 34732 604.8031 25 176467.68 121330 241456 41264.46 25 38217 37488 41192 1097.1133 25 229867.04 149816 293700 46313.19 25 54393 53140 55298 502.7437 25 335675.52 218307 466552 83901.59 25 65527 59409 67704 1470.6039 25 427060.68 281425 609297 81525.07 25 89069 77736 90664 2474.1143 25 619153.72 391612 910156 155616.85 25 102779 102358 103826 421.4145 25 710855.44 475416 984685 176180.57 25 111575 109350 116976 1325.5849 25 1016401.12 689980 1236653 189240.47 25 187522 185977 189342 951.2151 25 1144090.64 793856 1475152 230053.59 25 179527 177953 180387 484.2455 ? - - - - 25 298038 225965 303412 15074.1457 ? - - - - 25 332623 330949 335401 1111.9361 ? - - - - 25 359362 357646 363919 1167.3963 ? - - - - 25 381990 380746 384155 709.02

Table 8.17: GC-memory for both set approaches to find Steiner triple systems (withand without a global constraint).

VM memory usage (KB)instance set model w-out/global constraint set w/global constraint


13 25 32768.00 32768 32768 0.00 25 32768 32768 32768 0.0015 25 58982.40 32768 65536 13377.48 25 32768 32768 32768 0.0019 25 65536.00 65536 65536 0.00 25 32768 32768 32768 0.0021 25 81264.64 65536 131072 28566.48 25 32768 32768 32768 0.0025 25 131072.00 131072 131072 0.00 25 32768 32768 32768 0.0027 25 225443.84 131072 262144 60064.74 25 65536 65536 65536 0.0031 25 325058.56 262144 524288 114265.92 25 65536 65536 65536 0.0033 25 450887.68 262144 524288 120129.47 25 65536 65536 65536 0.0037 25 639631.36 262144 1048576 240258.94 25 131072 131072 131072 0.0039 25 901775.36 524288 1048576 240258.94 25 131072 131072 131072 0.0043 25 1006632.96 524288 1048576 145168.77 25 131072 131072 131072 0.0045 25 1300234.24 1048576 2097152 457063.68 25 256901 131072 262144 26214.4049 25 1845493.76 1048576 2097152 457063.68 25 262144 262144 262144 0.0051 25 2013265.92 1048576 2097152 290337.55 25 262144 262144 262144 0.0055 ? - - - - 25 513802 262144 524288 52428.8057 ? - - - - 25 524288 524288 524288 0.0061 ? - - - - 25 524288 524288 524288 0.0063 ? - - - - 25 524288 524288 524288 0.00

Table 8.18: VM-memory for both set approaches to find Steiner triple systems (withand without a global constraint).

132

Run time (miliseconds)instance integer model w-out/global constraint set model w-out/global constraint


13 25 178.08 138 244 15.81 25 22.24 12 47 5.9615 25 766.92 288 4398 759.70 25 258.96 69 306 79.2819 25 3559.16 1629 4079 437.90 25 468.36 200 549 78.9321 25 5849.72 3687 6125 633.08 25 1494.44 629 1710 272.2925 19 9604.26 7414 12532 864.58 25 2143.72 1345 4087 496.7027 ? - - - - 25 1978.88 1683 5679 815.0931 ? - - - - 25 6885.32 3607 7302 869.2833 ? - - - - 25 6690.00 4919 17122 2289.5337 ? - - - - 25 12400.28 8733 21913 2556.0439 ? - - - - 25 22266.52 12245 56394 7468.1343 ? - - - - 25 23998.16 22551 32082 2613.5545 ? - - - - 25 33613.52 29319 42607 2442.3149 ? - - - - 25 55007.84 39854 87198 7671.4651 ? - - - - 25 78013.36 48943 102867 9628.33

Table 8.19: Run-time (in milliseconds) for both integer and set approaches to findSteiner triple systems.

Number of iterationsinstance integer model w-out/global constraint set model w-out/global constraint


13 25 92.24 70 120 7.26 25 70.64 38 149 18.6815 25 242.44 90 1439 250.25 25 582.04 151 677 179.8619 25 494.80 237 509 56.21 25 557.00 223 644 96.5421 25 604.48 385 623 64.13 25 1353.48 570 1548 247.4425 19 577.42 448 765 53.82 25 1209.80 760 2343 287.7627 ? - - - - 25 880.32 765 2571 371.4931 ? - - - - 25 2078.12 1068 2183 268.3133 ? - - - - 25 1634.80 1100 4233 573.9937 ? - - - - 25 2114.12 1533 3802 444.2539 ? - - - - 25 3197.92 1810 7890 1035.7943 ? - - - - 25 2595.12 2479 3568 287.4045 ? - - - - 25 3117.16 2751 3910 217.0749 ? - - - - 25 3724.08 2767 5799 500.0951 ? - - - - 25 4882.68 3130 6467 616.50

Table 8.20: Number of iterations for both integer and set approaches to find Steinertriple systems.

133

Iterations per secondinstance integer model w-out/global constraint set model w-out/global constraint

v n average min. max. std.dev. n average min. max. std.dev.7 25 4760.00 2500.00 5000.00 708.87 25 - 9000.00 - -9 25 1836.35 1777.78 2000.00 62.03 25 8246.33 6600.00 9800.00 584.61

13 25 518.29 491.80 525.71 6.66 25 3180.65 2840.00 3444.44 113.7215 25 313.39 309.64 327.19 3.33 25 2244.17 2148.44 2285.71 27.6219 25 139.29 124.79 145.49 3.67 25 1187.18 1115.00 1232.22 20.5821 25 103.37 101.71 104.55 0.73 25 905.55 891.96 915.56 5.4525 19 60.11 59.40 61.04 0.42 25 563.92 555.78 573.28 4.0527 ? - - - - 25 444.23 432.80 454.55 6.6031 ? - - - - 25 301.66 296.09 305.49 2.4633 ? - - - - 25 243.92 223.62 250.24 4.7937 ? - - - - 25 170.51 157.41 175.54 4.1439 ? - - - - 25 143.90 134.48 152.34 3.7143 ? - - - - 25 108.14 103.46 111.50 1.5845 ? - - - - 25 92.76 91.41 94.15 0.7949 ? - - - - 25 67.75 66.50 71.53 1.1551 ? - - - - 25 62.57 60.03 63.95 0.75

Table 8.21: Iterations per second for both integer and set approaches to find Steinertriple systems.

GC memory usage (KB)instance integer model w-out/global constraint set model w-out/global constraint


13 25 169578.24 59074 326620 68578.50 25 21684 18960 23179 2013.7815 25 293053.44 93454 467643 106536.84 25 25885 21380 27516 1802.8019 25 790250.76 234325 1388474 360877.21 25 40036 31245 44236 4691.3121 25 1151684.40 337375 1873003 454053.73 25 50032 36105 66507 9511.3425 19 1932524.95 673838 3086902 792397.05 25 78850 59157 97003 12150.0027 ? - - - - 25 118280 76863 155090 25587.7131 ? - - - - 25 176468 121330 241456 41264.4633 ? - - - - 25 229867 149816 293700 46313.1937 ? - - - - 25 335676 218307 466552 83901.5939 ? - - - - 25 427061 281425 609297 81525.0743 ? - - - - 25 619154 391612 910156 155616.8545 ? - - - - 25 710855 475416 984685 176180.5749 ? - - - - 25 1016401 689980 1236653 189240.4751 ? - - - - 25 1144091 793856 1475152 230053.59

Table 8.22: GC-memory for both integer and set approaches to find Steiner triplesystems.

134

VM memory usage (KB)instance integer model w-out/global constraint set model w-out/global constraint


13 25 309329.92 131072 524288 145955.60 25 32768 32768 32768 0.0015 25 566231.04 262144 1048576 269469.07 25 58982 32768 65536 13377.4819 25 1384120.32 524288 2097152 621821.19 25 65536 65536 65536 0.0021 25 1761607.68 1048576 2097152 499222.03 25 81265 65536 131072 28566.4825 19 3311292.63 2097152 4194304 1063795.61 25 131072 131072 131072 0.0027 ? - - - - 25 225444 131072 262144 60064.7431 ? - - - - 25 325059 262144 524288 114265.9233 ? - - - - 25 450888 262144 524288 120129.4737 ? - - - - 25 639631 262144 1048576 240258.9439 ? - - - - 25 901775 524288 1048576 240258.9443 ? - - - - 25 1006633 524288 1048576 145168.7745 ? - - - - 25 1300234 1048576 2097152 457063.6849 ? - - - - 25 1845494 1048576 2097152 457063.6851 ? - - - - 25 2013266 1048576 2097152 290337.55

Table 8.23: VM-memory for both integer and set approaches to find Steiner triplesystems.

onds) and number of iterations in Tables 8.24, 8.25 and 8.26; and in terms ofmemory in Tables 8.27 and 8.28.Surprisingly, the integer approach using a global constraint reported betterrun-time measures for the instances it solved. However, the set approach usinga global constraint solved all the tried instances the 25 times and succeededwhere the integer approach failed. The set approach required in general feweriterations, but this did not avoid the integer approach to report better rates ofiterations per second. The set approach required in general less memory butthe integer approach reported sometimes better or equal memory consumptionfor the smaller instances. For even larger instances where the set approach isexpected to be far better, the Comet system seems to behave abnormally (withany of the approaches) since the programs seem to hang without a valid reasonsometimes reporting misleading error messages.

8.2.4 Solved InstancesThe current implementation of the set approach with a global constraint canactually find solutions up to sts-109 without difficulty. This means thatlarger instances, like sts-111 or sts-115, might also be found: attemptsto find solutions for these two instances end up with an error in executiontime saying internal Error without an actual message explaining whatis going on (as this seems to be a problem in the Comet system, there is achance that it is due to a memory leak). A better (tailored) implementation of

135

Run time (miliseconds)instance integer model w/global constraint set modelw/global constraint


13 25 4.96 2 11 2.46 25 9.16 5 17 3.7415 25 6.96 4 14 2.85 25 15.36 12 22 2.1819 22 18.73 11 24 3.97 25 31.20 14 55 11.3121 22 16.32 12 34 5.94 25 52.36 18 89 15.5525 20 38.90 32 66 7.85 25 57.84 29 102 18.0527 19 46.89 35 71 9.15 25 74.36 46 142 26.6631 6 71.83 49 92 13.79 25 139.60 76 200 46.1633 ? - - - - 25 238.84 185 311 36.3437 ? - - - - 25 252.52 149 503 96.2539 ? - - - - 25 237.08 144 517 102.4443 ? - - - - 25 386.52 265 692 130.6745 ? - - - - 25 601.04 353 890 122.0049 ? - - - - 25 641.56 390 990 193.8851 ? - - - - 25 657.20 496 1107 161.1655 ? - - - - 25 906.24 550 1498 280.4157 ? - - - - 25 753.88 642 878 64.8561 ? - - - - 25 1084.16 1014 1413 80.7663 ? - - - - 25 1299.64 1136 2665 300.16

Table 8.24: Run-time (in milliseconds) for both integer and set approaches to findSteiner triple systems using a global constraint.

Number of iterationsinstance integer model w/global constraint set modelw/global constraint


13 25 122.24 35 283 62.74 25 58.56 24 121 28.4815 25 146.32 72 310 65.75 25 75.64 53 116 12.8219 22 283.77 154 330 65.35 25 178.96 95 301 58.1321 22 250.68 190 572 102.43 25 335.80 96 353 60.7525 20 497.70 411 883 104.28 25 267.60 140 378 60.5427 19 501.47 384 826 121.93 25 398.20 209 609 87.2831 6 634.50 402 806 136.44 25 451.04 337 672 59.0933 ? - - - - 25 595.36 399 829 120.7937 ? - - - - 25 795.52 477 1630 259.3339 ? - - - - 25 874.04 543 1387 218.3143 ? - - - - 25 896.96 811 1250 111.4245 ? - - - - 25 1441.40 911 1579 196.3049 ? - - - - 25 1349.76 1052 1869 229.5851 ? - - - - 25 1534.88 1173 1757 145.5555 ? - - - - 25 1835.32 1283 2341 317.9857 ? - - - - 25 1936.72 1490 2497 255.4761 ? - - - - 25 2232.28 2052 3603 298.9063 ? - - - - 25 1935.04 1796 2554 248.39

Table 8.25: Number of iterations for both integer and set approaches to find Steinertriple systems using a global constraint.

136

Iterations per secondinstance integer model w/global constraint set modelw/global constraint

v n average min. max. std.dev. n average min. max. std.dev.7 25 - 5000.00 - - 25 - 4000.00 - -9 25 - 16000.00 - - 25 8653.33 5500.00 13000.00 2277.57

13 25 24570.81 17333.33 33000.00 4021.28 25 6226.56 4800.00 7875.00 689.8415 25 20843.04 17833.33 23400.00 1785.72 25 4924.32 4235.29 5789.47 380.9419 22 15084.50 12833.33 16500.00 985.58 25 6238.34 3800.00 10033.33 2445.1821 22 15223.33 14500.00 16823.53 701.70 25 6682.79 3966.29 8022.73 1459.6825 20 12794.13 11339.62 13431.82 480.53 25 4932.74 2768.12 6750.00 1396.9827 19 10648.50 9440.00 12058.82 753.47 25 5764.74 2912.09 7303.03 1577.0031 6 8797.48 8183.10 9342.11 504.68 25 3560.68 2250.00 5333.33 1110.5633 ? - - - - 25 2476.78 2156.76 2798.35 177.1537 ? - - - - 25 3411.21 1697.51 4728.89 1071.5639 ? - - - - 25 3910.65 2173.49 4968.00 742.7443 ? - - - - 25 2513.06 1537.48 3281.69 659.0145 ? - - - - 25 2481.93 1412.40 3352.17 545.6349 ? - - - - 25 2265.82 1355.11 3493.46 682.9251 ? - - - - 25 2429.77 1432.70 2907.09 466.6655 ? - - - - 25 2145.50 1289.83 2803.44 505.9157 ? - - - - 25 2563.67 1943.35 2843.96 185.8761 ? - - - - 25 2053.51 1867.15 2549.89 118.6163 ? - - - - 25 1517.49 950.84 1854.76 198.94

Table 8.26: Iterations per second for both integer and set approaches to find Steinertriple systems using a global constraint.

GC memory usage (KB)instance integer model w/global constraint set model w/global constraint


13 25 19130.48 16582 21328 2127.21 25 17393 17273 17622 102.9515 25 20278.36 17358 21855 2033.34 25 17636 17544 17780 44.2919 22 21481.77 17888 22474 1810.32 25 20834 20513 21275 207.7421 22 23604.00 20185 24517 1639.22 25 20775 20729 21423 153.2825 20 28062.05 20663 34540 4540.35 25 27281 26674 27732 268.9127 19 27372.89 21035 34569 4628.97 25 33988 31488 34732 604.8031 6 28097.00 22430 30903 3431.71 25 38217 37488 41192 1097.1133 ? - - - - 25 54393 53140 55298 502.7437 ? - - - - 25 65527 59409 67704 1470.6039 ? - - - - 25 89069 77736 90664 2474.1143 ? - - - - 25 102779 102358 103826 421.4145 ? - - - - 25 111575 109350 116976 1325.5849 ? - - - - 25 187522 185977 189342 951.2151 ? - - - - 25 179527 177953 180387 484.2455 ? - - - - 25 298038 225965 303412 15074.1457 ? - - - - 25 332623 330949 335401 1111.9361 ? - - - - 25 359362 357646 363919 1167.3963 ? - - - - 25 381990 380746 384155 709.02

Table 8.27: GC-memory for both integer and set approaches to find Steiner triplesystems using a global constraint.

137

VM memory usage (KB)instance integer model w/global constraint set model w/global constraint


13 25 32768.00 32768 32768 0.00 25 32768 32768 32768 0.0015 25 32768.00 32768 32768 0.00 25 32768 32768 32768 0.0019 22 32768.00 32768 32768 0.00 25 32768 32768 32768 0.0021 22 32768.00 32768 32768 0.00 25 32768 32768 32768 0.0025 20 60620.80 32768 65536 12004.48 25 32768 32768 32768 0.0027 19 60362.11 32768 65536 12276.02 25 65536 65536 65536 0.0031 6 60074.67 32768 65536 13377.48 25 65536 65536 65536 0.0033 ? - - - - 25 65536 65536 65536 0.0037 ? - - - - 25 131072 131072 131072 0.0039 ? - - - - 25 131072 131072 131072 0.0043 ? - - - - 25 131072 131072 131072 0.0045 ? - - - - 25 256901 131072 262144 26214.4049 ? - - - - 25 262144 262144 262144 0.0051 ? - - - - 25 262144 262144 262144 0.0055 ? - - - - 25 513802 262144 524288 52428.8057 ? - - - - 25 524288 524288 524288 0.0061 ? - - - - 25 524288 524288 524288 0.0063 ? - - - - 25 524288 524288 524288 0.00

Table 8.28: VM-memory for both integer and set approaches to find Steiner triplesystems using a global constraint.

the solution given in this chapter, perhaps using C or C++, may lead to evenbetter results.

8.3 ConclusionThe results of this experiment show that the effect of set variables for CBLSis not only a convenience for faster and higher-level modeling but could alsosometimes be necessary: many Steiner Triple Systems were found with the setapproach where the integer approach failed since it demanded less memoryfrom the system. Actually, the current implementation of the set approachwith a global constraint gave solutions up to sts-109 without difficulty. Thiseffect should be clearer on larger instances or problems where the integermodel demands many more variables than the set model, the next experimenton Schur’s lemma aims to further support this conclusion.

This experiment also shows for Constraint-based Local Search a well knownfact in Constraint Programming: global constraints give better performanceand they are not (necessarily) decomposable into conjunctions of simpler con-straints.

138

9. Schur’s Lemma(schur-k-n)

A set T of integers is sum-free if a, b ∈ T → a+b /∈ T . For instance, {1, 2, 5}is sum-free while {2, 3, 5} and {2, 4} are not. Given an integer k ≥ 0, theSchur number of k, denoted by S(k), is the largest integer n for which theinterval [1, n] can be partitioned into k sum-free sets. Schur’s lemma1 dealswith partitions of the first n natural numbers into k parts and whether or not apart contains a triple 〈x, y, z〉 such that x+y = z (i.e., whether a part is or notsum-free): given k ∈ N there is a maximum number n = S(k) so that thereexist a partition of [1, n] into k sum-free parts.

Indeed, the existence of S(k) for each k is guaranteed by a well knowntheorem of Schur. Around 1916, Issai Schur (Mogilyov 1875 – Tel Aviv 1941)proved that for any k there exists an integer n such that for all N > n and forevery partition of {1, . . . , N} into k sets there exist x, y and z (where x andy are not necessarily distinct) in the same subset such that x + y = z holds.Schur’s problem can then be stated as:

Find the largest integer n for which the set {1, . . . , n} can bepartitioned into k sum-free sets.

Schur proved his theorem basically by showing that S(k) ≤ bk!ec (whereb·c stands for the floor function) and also gave the lower bound S(k) ≥12

(3k − 1

). The equality of the lower bound holds for k = 1, 2, 3 and there-

fore S(1) = 1, S(2) = 4, and S(3) = 13. It has been found that S(4) = 44but S(5) is unknown. However, other bounds have been given. For instance,it has been shown that 160 ≤ S(5) ≤ 315, S(6) ≥ 536 and S(7) ≥ 1680.

As an example, consider S(2) = 4; this means [1, 4] can be partitioned into2 sum-free sets and there is no other natural number n > 4 with this property.Consider the partition [1, 4] = {1, 4} ∪ {2, 3} (showing S(2) ≥ 4) andsuppose there exists a partition of [1, 5] in to two sum-free sets L and R. Withno loss of generality, 1 ∈ L implies 2 ∈ R (since 1 + 1 = 2). Thus 4 ∈ L andtherefore 3 ∈ R. As a result, there is no place to put 5 and hence S(2) < 5.

Clearly, if [1, n] can be partitioned into k sum-free parts, then so is [1, n′]for n′ < n. The related decision problem asks to state whether, given twointegers k, n ≥ 0, there exists a partition of [1, n] into k sum-free sets. Aninstance of this problem is denoted by schur-k-n and specified by a pair〈k, n〉.1Schur’s lemma is problem number 15 at http://www.csplib.org/

139


9.1 The ExperimentThe experiment aims to demonstrate, by solving several schur-k-n in-stances, that the effect of set variables for CBLS is not only a conveniencefor faster and higher-level modeling but it could also sometimes be necessarybecause problem instances with integer variables would not fit into memoryor take much more time to be solved. Two different approaches are compared:one using an integer model of the problem and the other using a set modelof the problem as proposed in [27] (be aware, however, that only the declara-tive part of the model for Constraint Programming proposed in [27] is takenas operationally constraints for CP, i.e., propagators, are useless for CBLS).Implementations for both approaches have been developed from scratch.

9.1.1 ModelOn the one hand, the integer model introduces n integer variables Xi repre-senting the subset in which element i is placed (1 ≤ i ≤ n). Thus, D ={1, . . . , k}. To ensure that the subsets are sum-free,

(Xi = s) ∧ (Xj = s)→ (Xi+j 6= s)

constraints are added for all subsets s ∈ D and elements 1 ≤ i ≤ j ≤ n suchthat i+ j ≤ n.

On the other hand, the set model introduces k set variables Si represent-ing the sum-free subsets, with i ∈ {1, . . . , k}. Thus D = [∅, {1, . . . , n}]. Toensure that the subsets are sum-free,

sum-free (Si)

constraints are added for all subsets Si, with i ∈ {1, . . . , k}. In this way thereare just k such constraints contrasting the O

(kn2

)constraints of the integer

model.

9.1.1.1 CSPClearly, U = Nk. Given:

• a set of natural numbers Nn, and

• a set of (sub)sets indexed by Nk = U ,

the CSP for schur-k-n is given by:

• V = {Xi | i ∈ Nn};

• D = U ;

• C =⋃s∈Nk

i≤j∈Nn:i+j≤n

{(Xi = s) ∧ (Xj = s)→ (Xi+j 6= s)}

140

9.1.1.1.1 The (Xi = s) ∧ (Xj = s)→ (Xi+j 6= s) ConstraintA common way of building a complex constraint is through the use of logicalconnectives. Since:

(Xi = s) ∧ (Xj = s)→ (Xi+j 6= s) ≡ (Xi 6= s) ∨ (Xj 6= s) ∨ (Xi+j 6= s)

this constraint can be treated as the disjunction of the three (Xi 6= s), (Xj 6= s)and (Xi+j 6= s) constraints. As a result, it is satisfied whenever any of thethree mentioned constraints is satisfied, hence:

Penalty((Xi=s) ∧ (Xj=s)→(Xi+j 6=s))(k) = min(

Penalty(Xi 6=s)(k) ,

Penalty(Xj 6=s)(k),

Penalty(Xi+j 6=s)(k))

The conflict function is a little more complicated as the conflict for a vari-able x is (ideally) equal to the maximum decrease to the total violation thatcan take place by assigning x another value in its domain, that is:

Conflict ((Xi=s) ∧ (Xj=s)→(Xi+j 6=s))(x, k) =

Penalty((Xi=s) ∧ (Xj=s)→(Xi+j 6=s))(k)−

min(

Penalty(Xi 6=s)(k)− Conflict (Xi 6=s)(x, k),

Penalty(Xj 6=s)(k)− Conflict (Xj 6=s)(x, k),

Penalty(Xi+j 6=s)(k)− Conflict (Xi+j 6=s)(x, k))

Note that, in the previous formula, Conflict (Xy 6=s)(x, k) = 0 when x is notthe variableXy. Finally, as usual, the δ-assign((Xi=s) ∧ (Xj=s)→(Xi+j 6=s))(k, `)function returns the difference in the penalty between k and ` where ` isthe configuration given as a result of assigning to a variable X a new valuev 6= k(X).

9.1.1.2 Set-CSPClearly, U = Nn. Given:

• a set of natural numbers Nn = U , and

• a set of (sub)sets indexed by Nk,

the CSP for schur-k-n is given by:

• V = {Si | i ∈ Nk};

141

• D = P(U);

• C =⋃i∈Nk

{sum-free (Si)}

9.1.1.2.1 sum-free ConstraintFirst, the sum-free constraint defined on a set S ensures that for each pairof (not necessarily different) elements of S, their sum is not an element of S,hence:

Penalty(sum-free(S))(k) = |{c | a+ b = c ∈ k(S) ∧ a ∈ k(S) ∧ b ∈ k(S)}|

A number c ∈ k(S) such that a+ b = c with a ∈ k(S) and b ∈ k(S) is calleda forbidden element.

Second, since the constraint is defined only on one set variable, the conflictfunction is given by:

Conflict (sum-free(S))(x, k) = Penalty(sum-free(S))(k)

Finally, the δ-add (sum-free(S))(k, `) and δ-drop(sum-free(S))(k, `) differenti-ation functions give the number of (possibly not new) forbidden elements thatarise as a result of moving from k to `, respectively due to adding or droppingan element to or from S, minus the number of elements that are no longerforbidden (although they may still be in `(S)) as a result of moving from k to`. More precisely, if F is the multiset (or bag)2 of forbidden elements of S,δ-add (sum-free(S))(k, `) and δ-drop(sum-free(S))(k, `) give |`(F )| − |k(F )|.

The use of multisets should not be confusing. Consider, for instance, a setS = {1, 2, 3, 4, 6} and its multiset of forbidden elementsF = {{2, 3, 4, 4, 6, 6}}.3Note that both 4 and 6 appear twice in F since 1 + 3 = 2 + 2 = 4 and2 + 4 = 3 + 3 = 6. Removing 2 from S would hence remove 4 and 6 from Fonly once, and therefore 4 and 6 would still be in F . Similarly, adding 5 to Swould give both a not new forbidden element 6 since 1 + 5 = 6 (i.e., 6 wouldnow appear three times in F ) and a new forbidden element 5.

9.1.2 Search HeuristicSince the problem was modeled both as a CSP and as a set-CSP, one CBLSalgorithm is needed for each of the approaches.


2The notion of multiset is a generalization of the notion of set in which members are allowedto appear more than once. In this sense, the cardinality of a multi-set is the total number ofelements including multiplicities of the members.3Please, do not get confused with the notation used here for multisets, a multiset is not a setcontaining one set.

142

1 while any of the (Xi = s) ∧ (Xj = s)→ (Xi+j 6= s) constraints isnot satisfied

2 select a variable Xi ∈ V such that its conflict is maximum3 select a value v ∈ D such that the increase in violations by

assigning v to Xi is minimum4 assign v to Xi

which is enhanced with tabu list, intensification and restarts. The completesearch heuristic is shown in Figure 9.1. Both the neighborhood and the meta-heuristics used by this local search algorithm are explained next.

INT-SCHUR-PROBLEM-LS(Nk,Nn)1 tabu ← ∅2 k∗ ← k ← initial configuration3 it ← n← 04 maxNonImproving ← 1005 restartFreq ← 10006 τ ← 57 while ∃ (c = ((Xi = s) ∧ (Xj = s)→ (Xi+j 6= s))) | (s ∈ Nk,

i, j ∈ Nn, i ≤ j) ∧ penalty(c)(k) > 0 ∧ timeout ¬expired

8 select assign(Xi,v)(k) ∈(

ASSIGN t(V )(k, it)

)9 minimizing

∑∀c∈C

penalty(c)

(assign(Xi,v)(k)

)10 tabu ← tabu ∪ {〈v, it + τ〉}11 k ← assign(Xi,v)(k)12 if n > maxNonImproving13 k ← k∗

14 n← 015 tabu ← ∅16 else17 n← n+ 118 it ← it + 119 if it mod restrartFreq = 020 k ← new random configuration21 k∗ ← k22 tabu ← ∅23 n← 0

Figure 9.1: CBLS algorithm for the integer approach to Schur’s problem.

143

9.1.2.1.1 NeighborhoodThe neighborhood is the set of moves assigning an element i ∈ {1, . . . , n} toa new subset in {1, . . . , k}:

S(k) ={

assign(Xi,v)(k) | v ∈ Nk

}Restricting the attention to assignments involving just a most conflicting

variable, the neighborhood becomes:

S′(k) ={

assign(X,v)(k) | assign(X,v)(k) ∈ S(k) ∧

∑c∈C:

X∈vars(c)

conflict (c) (X, k) = maxX∈V

∑c∈C:

X∈vars(c)

conflict (c) (X, k)

which ensures that the algorithm focuses on assignments which decrease thenumber of violations. The neighborhood is then:

ASSIGN (V )(k) ={

assign(X,v)(k) | assign(X,v)(k) ∈ S′(k) ∧ X ∈ V}

9.1.2.1.2 Meta-HeuristicsFirst, the tabu component of the algorithm features a tabu-list of length 5 (avalue chosen arbitrarily) which maintains pairs 〈v, j〉 where j represents thefirst iteration where is allowed to assign again an element to a subset v. Thefact that assigning v at iteration it is forbidden is denoted by tabu(v, it) andtherefore tabu(v, it) ↔ 〈v, j〉 ∈ tabu ∧ j ≤ it . The neighborhood thenbecomes:

ASSIGN t(V )(k, j) =

{assign(Mi,v)(k) |

assign(Xi,v)(k) ∈ ASSIGN (V )(k)

∧ ¬tabu (v, j)}

Second, an intensification component is added which reinitializes the searchfrom the so-far best known solution k∗ and resets the tabu-list whenever k∗

has not been improved upon a maximum maxNonImproving number of iter-ations.

Finally, the restarting component reinitializes the search from a possiblyrandom configuration every restartFreq number of iterations.


144

1 while any of the sum-free constraints is not satisfied2 select a set variable Si among the most conflicted and second most

conflicted set variables3 select another set variable Sj (i 6= j) and a value v ∈ Si such that

the increase in violations by transferring v from Si to Sjis minimum

4 transfer v from Xi to Xj

which is enhanced with tabu list, an aspiration criterion, intensification andrestarts. The set variable Si is selected among the most conflicted and secondmost conflicted set variables because it was determined experimentally to bebetter than choosing only among the most conflicted variables. The searchheuristic is shown in Figure 9.2. Both the neighborhood and meta-heuristicsused by this local search algorithm are explained below.

9.1.2.2.1 NeighborhoodThe neighborhood of the local search is the set of moves consisting in trans-ferring one value from a subset Si to another subset Sj (i 6= j):

N(k) ={

transfer (Si,v,Sj)(k) | v ∈ k (Si)}

Restricting the attention to transfer moves involving involving one among themost conflicted and the second most conflicted variables, the neighborhoodbecomes:

N ′(k) ={

transfer (Si,v,Sj)(k) | transfer (Si,v,Sj)(k) ∈ N(k) ∧∑c∈C:

X∈vars(c)

conflict (c) (X, k) ∈

maxX∈V

[2]

∑c∈C:

X∈vars(c)

conflict (c) (X, k)

which ensures that the algorithm focuses on transfers which decrease the num-ber of violations. Note max[2](Y ) returns not only the maximum(s) in Y butalso the maximum(s) in Y \max(Y ). The neighborhood is then:

TRANSFER(V )(k) ={

transfer (Si,v,Sj)(k) | transfer (Si,v,Sj)(k) ∈ N ′(k)

∧ Si, Sj ∈ V ∧ i 6= j}

9.1.2.2.2 Meta-HeuristicsFirst, the tabu component of the algorithm features a tabu-list of length 5 (avalue chosen arbitrarily to be equal to the length of the tabu-list of the inte-

145

SET-SCHUR-PROBLEM-LS(Nk,Nn)1 tabu ← ∅2 k∗ ← k ← initial configuration3 it ← n← 04 maxNonImproving ← 12005 restartFreq ← 120006 τ ← 57 while ∃ (c = sum-free (Si)) | (i ∈ Nk) ∧

∧ penalty(c)(k) > 0 ∧ timeout not expired

8 select transfer (Si,v,Sj)(k) ∈(

TRANSFERt(V )(k, it) ∪

TRANSFER∗(V )(k, k∗))

9 minimizing∑∀c∈C

penalty(c)

(transfer (Si,v,Sj)(k)

)10 tabu ← tabu ∪ {〈v, it + τ〉}11 k ← transfer (Si,v,Sj)(k)12 if

∑∀c∈C

penalty(c)(k) <∑∀c∈C

penalty(c)(k∗)

13 k∗ ← k14 n← 015 elseif n > maxNonImproving16 k ← k∗

17 n← 018 tabu ← ∅19 else20 n← n+ 121 it ← it + 122 if it mod restrartFreq = 023 k ← new random configuration24 k∗ ← k25 tabu ← ∅26 n← 0

Figure 9.2: CBLS algorithm for the set approach to Schur’s problem.

ger approach) which maintains pairs 〈v, j〉 where j represents the first itera-tion where it is allowed to transfer again the element v. The fact that trans-ferring v at iteration it is forbidden is denoted by tabu(v, it) and thereforetabu(v, it)↔ 〈v, j〉 ∈ tabu ∧ j ≤ it . As a result, given a configuration k

146

and an iteration j, the neighborhood is actually:

TRANSFERt(V )(k, j) =

{transfer (S,v,T )(k) | transfer (S,v,T )(k) ∈

TRANSFER(V )(k) ∧¬tabu (v, j)}

Second, in addition to the non-tabu moves, the neighborhood of the movesimproving the so far best solution is also considered. This neighborhood isgiven by:

TRANSFER∗(V )(k, k∗) = {transfer(k) | transfer(k) ∈ TRANSFER(V )(k)

∧∑∀c∈C

penalty(c)(k) <∑∀c∈C

penalty(c)(k∗)

}

Third, an intensification component is added which reinitializes the searchfrom the so-far best known solution k∗ and resets the tabu-list whenever k∗

has not been improved upon a maximum maxNonImproving number of iter-ations.

Finally, the restarting component reinitializes the search from a possiblyrandom configuration every restartFreq iterations.

9.1.3 Setup of the Experiment9.1.3.1 Problem Instances and Initial ConfigurationsTo compare between the two approaches, Schur problems are taken with k =3 and k = 4. As it is known that S(3) = 13 and S(4) = 44, the instancestaken are schur-3-13 and the feasible instances from schur-4-37 toschur-4-44. In both approaches the search starts from the same initial con-figuration generated at random in advance.


9.1.3.2.1 CBLS for the Integer ApproachFortunately, Comet allows posting constraints involving complex arithmeticand logical expressions. The (Xi = s) ∧ (Xj = s) → (Xi+j 6= s) logicalimplication constraint is no exception and therefore there is no need to designand implement this constraint. The source code for the implementation of theinteger approach is given in Section 15.5

147

Figure 9.3: Set-invariants for Comet’s Constraint-Based local search back-end.

9.1.3.2.2 CBLS for the Set ApproachUnfortunately, since Comet’s CBLS back-end does not support set constraints(and despite all the machinery introduced in Chapter 6) it is not possible todirectly post constraints involving set expressions. Moreover, although it sup-ports definitions of invariants over set expressions (for example, using theunion, intersection, set difference, member and cardinality operators alongwith filtering operators) they are not enough to maintain the sum-set of aset as an invariant. This not necessarily because it is not possible to expressthe invariant itself, but rather because it simply will not work: execution er-rors are thrown – e.g., “execution error: Dynamic expressioninside a fully dynamic invariant” wich seems to mean that thecurrent implementation (i.e., version 2.1) of layer 1 of Comet’s CBLS back-end (see Figure 9.3) cannot maintain the invariant incrementally. As a result, anew invariant for this purpose was implemented in Listing 15.19. The sourcecode for the implementation of the set approach is given in Section 15.6.

9.1.3.3 The MachineAll programs were run on ASTRA’s experiment server ghoul, a machinewith an Intel Core i7-950 processor and 3 gigabytes of RAM. A timeout ofone minute per instance was set and each instance was run 25 times.

9.2 ResultsIn this section results are given in terms of number of successful runs, run-time (in milliseconds), memory consumption and number of iterations. Com-parisons are made to contrast between the integer and set approaches.

148

Integer modelinstance time (miliseconds) iterations restores/k-n n average min. max. std.dev. average min. max. std.dev. restarts

3-13 25 60.36 1 144 36.66 1304.12 6 3269 848.23 287 / 284-37 25 11993.84 871 28023 7948.23 44503.88 3143 106149 29742.83 9858 / 11084-38 25 9511.48 649 40938 8891.07 33648.44 2089 145102 31528.42 7444 / 8374-39 21 24199.29 1784 52757 17859.70 83364.43 6056 182052 61874.99 15452 / 17484-40 7 31938.43 11784 51828 16789.92 105945.71 41087 168081 55333.48 6520 / 7414-41 7 29559.29 1605 52383 21623.80 91389.86 4218 172351 69067.77 5628 / 6384-42 6 36412.33 840 58119 21506.00 103626.50 2091 164078 61583.62 5435 / 6214-43 2 26035.00 412 51658 36236.39 70617.50 1089 140146 98328.15 1225 / 1414-44 1 41367.00 41367 41367 - 112395.00 112395 112395 - 981 / 112

Table 9.1: Run-time (in milliseconds) and number of iterations for the integer ap-proach to Schur’s problem.

Integer modelinstance mem GC Usage mem VM Usage iterations per secondk-n n average min. max. std.dev. average min. max. std.dev. average min. max. std.dev.

3-13 25 31015.56 21224 37010 5209.47 62914.56 32768 65536 9073.05 20319.30 6000.00 25813.01 3720.904-37 25 244420.28 161948 304502 46818.22 492830.72 262144 524288 86943.33 3707.39 3599.53 3911.45 76.044-38 25 258275.08 178221 319811 45790.06 513802.24 262144 524288 52428.80 3508.31 3218.80 3721.35 114.374-39 21 272206.86 200513 336613 49212.87 524288.00 524288 524288 0.00 3435.70 3252.96 3730.63 91.674-40 7 277904.29 200637 331583 50458.18 524288.00 524288 524288 0.00 3326.59 3239.77 3486.68 85.204-41 7 286657.71 210572 346756 56444.48 524288.00 524288 524288 0.00 3013.32 2628.04 3417.43 246.674-42 6 327303.50 255207 364786 45433.86 524288.00 524288 524288 0.00 2784.67 2489.29 2904.37 148.054-43 2 300813.00 239060 362566 87331.93 524288.00 524288 524288 0.00 2678.08 2643.20 2712.96 49.324-44 1 396890.00 396890 396890 - 524288.00 524288 524288 - 2717.02 2717.02 2717.02 -

Table 9.2: Memory usage and number of iterations per second for the integer approachto Schur’s problem.

9.2.1 Integer ApproachThis section presents results for the integer approach in terms of :

• run-time (in milliseconds) and number of iterations in Table 9.1, and interms of

• memory and iterations per second in Table 9.2.

9.2.2 Set ApproachThis section presents results for the set approach in terms of:



9.2.3 Comparison Between the Integer and Set ApproachesThis section presents comparisons between the integer and set approaches interms of :

149

Set modelinstance time (miliseconds) iterations restores/k-n n average min. max. std.dev. average min. max. std.dev. restarts

3-13 25 104.84 17 114 25.30 1575.32 257 1685 379.97 23 / 04-37 23 913.74 7 1812 379.17 5220.39 41 10394 2171.45 84 / 04-38 18 1330.56 198 4412 946.08 7682.83 1034 31185 6608.66 93 / 24-39 17 1459.82 92 2186 528.08 7802.76 503 11676 2820.53 104 / 04-40 5 1097.20 694 2086 573.02 5788.20 3647 11076 3069.19 20 / 04-41 2 1021.00 1007 1035 19.80 5057.50 4969 5146 125.16 8 / 04-42 1 2028.00 2028 2028 - 9901.00 9901 9901 - 8 / 04-43 1 34.00 34 34 - 153.00 153 153 - 0 / 04-44 1 2352.00 2352 2352 - 10858.00 10858 10858 - 8 / 0

Table 9.3: Run-time (in milliseconds) and number number of iterations for the setapproach to Schur’s problem.

Set modelinstance mem GC Usage mem VM Usage iterations per secondk-n n average min. max. std.dev. average min. max. std.dev. average min. max. std.dev.

3-13 25 18370.96 16955 18550 487.42 32768.00 32768 32768 0.00 15025.52 14780.70 15458.72 192.574-37 23 18295.09 17020 19334 559.48 32768.00 32768 32768 0.00 5718.27 5548.90 5857.14 63.584-38 18 18038.61 17078 19690 846.86 32768.00 32768 32768 0.00 5545.92 5222.22 7068.22 386.904-39 17 18776.65 17622 19685 493.68 32768.00 32768 32768 0.00 5353.17 5239.37 5467.39 52.424-40 5 17745.00 17275 18714 582.44 32768.00 32768 32768 0.00 5260.57 5185.92 5334.62 61.944-41 2 19155.00 18902 19408 357.80 32768.00 32768 32768 0.00 4953.22 4934.46 4971.98 26.534-42 1 17817.00 17817 17817 - 32768.00 32768 32768 - 4882.15 4882.15 4882.15 -4-43 1 17401.00 17401 17401 - 32768.00 32768 32768 - 4500.00 4500.00 4500.00 -4-44 1 18214.00 18214 18214 - 32768.00 32768 32768 - 4616.50 4616.50 4616.50 -

Table 9.4: Memory usage and number of iterations per second for the set approach toSchur’s problem.

Run time (miliseconds)instance integer model set model

o n average min. max. std.dev. n average min. max. std.dev.3-13 25 60.36 1 144 36.66 25 104.84 17 114 25.304-37 25 11993.84 871 28023 7948.23 23 913.74 7 1812 379.174-38 25 9511.48 649 40938 8891.07 18 1330.56 198 4412 946.084-39 21 24199.29 1784 52757 17859.70 17 1459.82 92 2186 528.084-40 7 31938.43 11784 51828 16789.92 5 1097.20 694 2086 573.024-41 7 29559.29 1605 52383 21623.80 2 1021.00 1007 1035 19.804-42 6 36412.33 840 58119 21506.00 1 2028.00 2028 2028 -4-43 2 26035.00 412 51658 36236.39 1 34.00 34 34 -4-44 1 41367.00 41367 41367 - 1 2352.00 2352 2352 -

Table 9.5: Run-time (in milliseconds) for both integer and set approaches to Schur’sproblem.

Number of iterationsinstance integer model set model

o n average min. max. std.dev. n average min. max. std.dev.3-13 25 1304.12 6 3269 848.23 25 1575.32 257 1685 379.974-37 25 44503.88 3143 106149 29742.83 23 5220.39 41 10394 2171.454-38 25 33648.44 2089 145102 31528.42 18 7682.83 1034 31185 6608.664-39 21 83364.43 6056 182052 61874.99 17 7802.76 503 11676 2820.534-40 7 105945.71 41087 168081 55333.48 5 5788.20 3647 11076 3069.194-41 7 91389.86 4218 172351 69067.77 2 5057.50 4969 5146 125.164-42 6 103626.50 2091 164078 61583.62 1 9901.00 9901 9901 -4-43 2 70617.50 1089 140146 98328.15 1 153.00 153 153 -4-44 1 112395.00 112395 112395 - 1 10858.00 10858 10858 -

Table 9.6: Number of iterations for both integer and set approaches to Schur’s prob-lem.

150

Iterations per secondinstance integer model set model

o n average min. max. std.dev. n average min. max. std.dev.3-13 25 20319.30 6000.00 25813.01 3720.90 25 15025.52 14780.70 15458.72 192.574-37 25 3707.39 3599.53 3911.45 76.04 23 5718.27 5548.90 5857.14 63.584-38 25 3508.31 3218.80 3721.35 114.37 18 5545.92 5222.22 7068.22 386.904-39 21 3435.70 3252.96 3730.63 91.67 17 5353.17 5239.37 5467.39 52.424-40 7 3326.59 3239.77 3486.68 85.20 5 5260.57 5185.92 5334.62 61.944-41 7 3013.32 2628.04 3417.43 246.67 2 4953.22 4934.46 4971.98 26.534-42 6 2784.67 2489.29 2904.37 148.05 1 4882.15 4882.15 4882.15 -4-43 2 2678.08 2643.20 2712.96 49.32 1 4500.00 4500.00 4500.00 -4-44 1 2717.02 2717.02 2717.02 - 1 4616.50 4616.50 4616.50 -

Table 9.7: Iterations per second for both integer and set approaches to Schur’s prob-lem.

GC memory usage (KB)instance integer model set model

o n average min. max. std.dev. n average min. max. std.dev.3-13 25 31015.56 21224 37010 5209.47 25 18371 16955 18550 487.424-37 25 244420.28 161948 304502 46818.22 23 18295 17020 19334 559.484-38 25 258275.08 178221 319811 45790.06 18 18039 17078 19690 846.864-39 21 272206.86 200513 336613 49212.87 17 18777 17622 19685 493.684-40 7 277904.29 200637 331583 50458.18 5 17745 17275 18714 582.444-41 7 286657.71 210572 346756 56444.48 2 19155 18902 19408 357.804-42 6 327303.50 255207 364786 45433.86 1 17817 17817 17817 -4-43 2 300813.00 239060 362566 87331.93 1 17401 17401 17401 -4-44 1 396890.00 396890 396890 - 1 18214 18214 18214 -

Table 9.8: GC-memory for both integer and set approaches to Schur’s problem.

• run-time (in milliseconds) in Table 9.5,

• number of iterations in Table 9.6,

• rate of iterations per second in Table 9.7,

• memory in Tables 9.8 and 9.9, and

• number of restores/restarts in Table 9.10.

The set approach was significantly faster in all instances except the easierone (schur-3-13), reported fewer iterations and a much better rate of iter-ations per second. The set approach was also far better in memory terms as itneeded far less memory. The set approach was also more stable as it restartedfar less often. Despite of all that, the integer approach succeeded more times.

9.2.4 Solved InstancesThe solutions presented in this chapter can find the known Schur numbersS(3) and S(4). S(5) remains unknown and no serious attempts have beenmade in this experiment to try to find this number. However, some instanceshave been tried with k = 5, 6, 7 with success. Some solved instances of

151

VM memory usage (KB)instance integer model set model

o n average min. max. std.dev. n average min. max. std.dev.3-13 25 62914.56 32768 65536 9073.05 25 32768 32768 32768 0.004-37 25 492830.72 262144 524288 86943.33 23 32768 32768 32768 0.004-38 25 513802.24 262144 524288 52428.80 18 32768 32768 32768 0.004-39 21 524288.00 524288 524288 0.00 17 32768 32768 32768 0.004-40 7 524288.00 524288 524288 0.00 5 32768 32768 32768 0.004-41 7 524288.00 524288 524288 0.00 2 32768 32768 32768 0.004-42 6 524288.00 524288 524288 0.00 1 32768 32768 32768 -4-43 2 524288.00 524288 524288 0.00 1 32768 32768 32768 -4-44 1 524288.00 524288 524288 - 1 32768 32768 32768 -

Table 9.9: VM-memory for both integer and set approaches to Schur’s problem.

Total number of restores and restartsinstance integer model set model

o n restores restarts n restores restarts3-13 25 287 28 25 23 04-37 25 9858 1108 23 84 04-38 25 7444 837 18 93 24-39 21 15452 1748 17 104 04-40 7 6520 741 5 20 04-41 7 5628 638 2 8 04-42 6 5435 621 1 8 04-43 2 1225 141 1 0 04-44 1 981 112 1 8 0

Table 9.10: Total number of restarts for both integer and set approaches to Schur’sproblem.

Schur’s lemma given in [27] for these three values of k, albeit using ConstraintProgramming, had already shown the succinctness of the set representationfor this problem: several instances with an equivalente integer representationcould not be solved as they would exceed the memory limits.

However, before dealing with open instances, a good idea would be to pro-vide a global constraint for the set approach (in an analogous fashion to theexperiment on Steiner triple systems in Chapter 8) together with a C or C++implementation of the solution described in this chapter. Hopefully, with someluck, at least some bounds for Schur numbers could be tightened.

9.3 ConclusionOverall, these results demonstrate that a set representation can not only beconvenient from a modeling perspective, but also helpful from a computa-tional perspective. For this problem, the effect of using set variables goes be-yond the convenience for faster and higher-level modeling. The use of setconstraints could become necessary when trying to find Schur numbers sincefor large instances the required memory is far less as shown with the instancesrun for this problem.

152

Part V:

Other Experiments with Comet and Set-CBLS

10. The Scene Allocation Problem

A scene allocation consists of deciding when to shoot scenes for a movie.Each scene involves a number of actors and each actor may appear in morethan one scene. All actors of a scene must be present on the day the sceneis shot. The actors have fees representing the amount to be paid per day theyspent in the studio.

The Scene Allocation problem has been used before to compare and illus-trate differences between programming models (for example, in [23]). Thisoptimization problem asks to minimize the total cost when shooting scenesfor a given movie. Only one instance of this problem is considered in thisexperiment:1

• There are eleven actors and their daily fees are given in Table 10.1.

• These actors appear in (some of the) 19 scenes given in Table 10.2.

• The movie must be filmed during at most 5 days and at most 5 scenes perday can be filmed.

For example, Pacino is the only actor appearing in scene 1 and he has a dailyfee of 9381; if all the 5 scenes where Pacino appears are filmed in the sameday, then he gets paid only 9381.

An optimal solution for this problem instance (where a set of scenes isassigned to each day) with a total cost of 344144 is:

Day1 = {3, 9, 10, 16, 17} Day2 = {4, 7, 11, 13, 19}Day3 = {2, 5, 6, 12, 15} Day4 = {1, 6, 14, 18}

1Taken from the project portfolio of the Uppsala University’s Autumn 2010 Constraint Pro-gramming course.

Actor Daily fee Actor Daily fee Actor Daily feeDe Niro 26481 Kidman 25043 Cruise 30310

Thurman 4085 Liu 7562 Pacino 9381Stormare 8770 Johansson 5788 Cole 7423Williams 3303 Bogart 9593

Table 10.1: Actors and their daily fees for the Scene Allocation problem instance.

155

Scene Set of actors1 {Pacino}2 {De Niro,Pacino,Liu,Thurman}3 {Johansson,Cruise,Cole,Liu}4 {Kidman,Cole}5 {Cole,Stormare,De Niro, Johansson,Williams}6 {Bogart , Johansson,Stormare,Cruise,Williams}7 {Kidman,De Niro}8 {Cole,Thurman}9 {Kidman, Johansson,Cole,Cruise,Bogart}

10 {Kidman, Johansson,Cruise,De Niro}11 {De Niro}12 {Pacino,Bogart , Johansson,Thurman,Liu}13 {Pacino,Thurman,Kidman,De Niro}14 {Stormare,Cruise}15 {Bogart ,Thurman, Johansson,De Niro}16 {Cruise, Johansson,Kidman,Cole}17 {Cruise,De Niro,Liu}18 {Cruise, Johansson,Pacino,Bogart}19 {Kidman}

Table 10.2: Set of scenes and actors participating in each scene for the Scene Alloca-tion problem instance.

10.1 The ExperimentSo far the Comet’s CBLS back-end’s differentiable objects layer (see Fig-ure 4.1) has been extended to support set constraints. However, since themechanism to define user-defined invariants exists, it should be possible tointroduce any kind of differentiable object (not only constraints). This chap-ter aims to further extend Comet’s CBLS back-end’s differentiable objectslayer to support differentiable set objective functions (see Figure 10.1) and toapply them to compare between an integer CBLS approach and a set CBLSapproach to the Scene Allocation problem.

The integer CBLS approach to this problem was taken from from [26] aswell as the Comet program partially depicted there. The set CBLS approachas well as its implementation have been developed from scratch. A better run-time performance for the set approach is expected.

10.1.1 Objective Functions in Local SearchThe concept of differentiable objects has emerged as the cornerstone of CBLS[26]. Like invariants, objective functions incrementally maintain the valueof their associated expression. Unlike invariants, they are differentiable andhence can be queried. Indeed, objective functions are very similar to con-

156

Figure 10.1: Set differentiable objective functions for Comet’s Constraint-Based lo-cal search back-end.

straints [25]: an objective function maintains its value (the counterpart of thetruth value of a constraint) and its evaluation (the counterpart of the violationsof a constraint), as well as the evaluations of its variables. This should becomemore clear after taking a look at the mechanism Comet’s CBLS module pro-vides to declare objective functions.

10.1.1.1 Objective Functions in CometAll objective functions in Comet’s CBLS module implement the Function<

LS> interface which is partially shown in Listing 10.1.

1 interface Function<LS> {2 var{int} evaluation();34 var{int} increase(var{int});5 var{int} decrease(var{int});67 int getAssignDelta(var{int},int);8 int getSwapDelta(var{int},var{int});9

10 ...11 }

Listing 10.1: Function<LS> interface

While the evaluation method maintains incrementally the value of the ob-jective function, the methods increase(var{int}) and decrease(var{int}

) specify respectively how much a given variable can increase or decrease thefunction’s evaluation by changing its value to any value in its domain. Finally,similarly to constraints, the methods getAssignDelta(var{int},int) andgetSwapDelta(var{int},var{int}) return the increase in the evaluation byassigning a value to a variable respectively by swapping two variables.

157

10.1.2 Set Objective Functions for Comet CBLS’s Back-EndIn order to define set objective functions in Comet’s CBLS module, a newinterface named SetObjectiveFunction<LS> is defined as shown in List-ing 10.2. By design, all set objective functions will be required to implementthis interface.

1 interface SetObjectiveFunction<LS> {2 Solver<LS> getLocalSolver();3 var{set{int}}[] getSetVariables();45 var{int} evaluation();6 var{int} increase(var{set{int}} s);7 var{int} decrease(var{set{int}} s);89 int getAddDelta(var{set{int}} s, int v);

10 int getDropDelta(var{set{int}} s, int u);11 int getFlipDelta(var{set{int}} s, int u, int v);12 int getTransferDelta(var{set{int}} s, int u,13 var{set{int}} t);14 int getSwapDelta(var{set{int}} s, int u, int v,15 var{set{int}} t);1617 void post();18 }

Listing 10.2: SetObjectiveFunction_LS_.co: SetObjectiveFunction<

LS> interface.

Note how similar this interface is with respect to the SetConstraint<LS>

interface shown in Listing 6.1. Basically, the main differences are that:

• there is no need for an isTrue method;

• instead of a violation method for the penalty of the constraint, there is anevaluation method to retrieve the current value of the objective functionover the set variables; and

• instead of a violation method for the conflict function, the methods increase(var{int}) and decrease(var{int}) are provided to compute how mucha given set variable can respectively increase or decrease the function’sevaluation. More parameters might be added to these methods, but this isnot further discussed here.

Note differentiation functions are the same with respect to those given by theSetConstraint<LS> interface.

Finally, analogous to the case of user-defined set constraints, user-definedset objective functions will extend the UserSetObjectiveFunction<LS> ab-stract class shown in Listing 15.20 which basically provides trivial defaultimplementations of the methods defined in the SetObjectiveFunction<LS>

interface.

158

10.1.3 ModelThere are mainly three constraints specified by the problem:

• at most 5 scenes per day must be filmed (capacity constraint),

• each scene must be filmed once, and

• an actor must be in the studio when filming one of his/her scenes (and henceget paid for that day).

On the one hand, the model for the integer approach is directly taken from[26]: it associates an integer variable scene[s]2 with every scene s to representthe day s is filmed and makes the capacity on the scenes an implicit (hard)constraint. The objective function uses reification to decide whether to pay anactor on a given day.

On the other hand, the set model associates a set variable scenes[d ] withevery day d to represent the set of scenes that are filmed on day d. The capacityon the scenes is made an implicit (hard) constraint as well, and the objectivefunction uses reification to keep a set of actors per day to decide how manydays an actor has to go to the studio in order to film the movie.

10.1.4 Objective FunctionsThe CSPs given for the Scene Allocation problem do not precisely complywith the definitions given in Section 1.3. In addition to the set of constraints,an objective (cost) function to be minimized is given; as a result instead ofCSPs they are called COPs (Constrained Optimization Problems).

For the integer approach, the cost function is given by:

Oisceneallocation

=∑

a∈Actors,d∈Days

fee(a) ·

∨s∈

appears(a)

scene[s] = d

and the cost function for the set approach is given by:

Ossceneallocation

=∑

a∈Actors

fee(a)·|{d | d ∈ D ∧ ∃s ∈ scenes[d] : s ∈ appears(a)}|

where fee(a) gives the fee of actor a (see Table 10.1) and appears(a) givesthe set of scenes where actor a appears (see Table 10.2).

2It might be more clear to call such integer variables day [s] as they hold days, however theoriginal names are kept.

159

10.1.4.1 COPGiven a set of actors A and a set of scenes indexed by NS to be filmed in a setof days D3; U = D and the COP for the Scene Allocation problem is givenby:

• V = {scenes | s ∈ NS};

• D = U ;

• O =

cost =∑

a∈Actors,d∈Days

fee(a) ·

∨s∈

appears(a)

scenes = d

where scenei denotes the day scene i is shot. Since all scenes get a day as-signed, it is implicit that each scene is filmed once. The capacity constraint iskept implicit as well, i.e., satisfied by the initial configuration and maintainedthrough local moves.

10.1.4.2 Set-COPGiven a set of actors A and a set of scenes indexed by NS , to be filmed in aset of days D; U = NS and the set-COP for the Scene Allocation problem isgiven by:

• V = {scenesd | d ∈ D};

• D = P(U);

• O ={

cost =∑

a∈Actors

fee(a) · |{d | d ∈ D ∧∃s ∈ scenesd : s ∈ appears(a)}|}

where scenesd denotes the set of scenes shot at day d. The constraint that eachscene must be filmed once as well as the capacity constraint are also kept asimplicit constraints, i.e., satisfied by the initial configuration and maintainedthrough local moves.

10.1.5 Search HeuristicSince the problem was modeled taking both an integer and a set approach, oneCBLS algorithm is needed for each approach.


3please, do not confuse this D with the D used to denote the domain of variables in the CSP

160

INT-SCENE-ALLOCATION-LS(Actors,Days, fee, appears)1 tabu ← ∅2 k∗ ← k ← initial configuration3 it ← n← 04 maxNonImproving ← 150005 τ ← 1006 while timeout ¬expired ∧ it ≤ maxNbIterations7 select swap(scenei,scenej)(k) ∈

(SWAP t

(V )(k, it) ∪

SWAP t(V )(k, k

∗))

8 minimizing Oisceneallocation

(swap(scenei,scenej)(k)

)9 tabu ← tabu ∪ {〈i, j, it + τ〉}

10 k ← swap(scenei,scenej)(k)11 if Oiscene

allocation(k) < Oiscene

allocation(k∗)

12 k∗ ← k13 n← 014 if n > maxNonImproving15 k ← new random configuration16 tabu ← ∅17 n← 018 else19 n← n+ 120 it ← it+ 1

Figure 10.2: CBLS algorithm for the integer approach to the Scene Allocation prob-lem.

1 while some allocated resource (such as running time or a number ofiterations) has not been exhausted

2 select two different scenes such that the increase in the evaluationof the objective function by swapping the days the two scenes are shotis minimum

(the goal is to minimize the cost given by Oiscene

allocation

).

3 swap the days the two scenes are shot

which is enhanced with a tabu-list, an aspiration criterion and restarts. Thesearch heuristic is shown in Figure 10.2. Both the neighborhood and the meta-heuristics used by this local search algorithm are explained below.

Concerning the implementation of the search heuristic, should not surpriseto the reader that, in Line 69 of Listing 15.21 the condition of the while loop

161

is Oisceneallocation

6= 344144 since its purpose is to let the program run until the(known) optimal solution has been reached.

10.1.5.1.1 NeighborhoodThe neighborhood of the local search consists of swapping the days two dif-ferent scenes are shot:

SWAP (V )(k) ={

swap(scenei,scenej)(k) | i 6= j ∧ scenei, scenej ∈ V}

10.1.5.1.2 Meta-HeuristicsFirst, the tabu component of the algorithm features a tabu-list of length 100which maintains triples 〈s1, s2, j〉 where j represents the first iteration whereit is allowed to swap again the days the two scenes s1 and s2 are shot. The factthat swapping s1 and s2 at iteration it is forbidden is denoted by tabu(s1, s2, it)and therefore tabu(s1, s2, j) ↔ 〈s1, s2, j〉 ∈ tabu ∧ j ≤ it . The neighbor-hood then becomes:

SWAP t(V )(k, j) =

{swap(scenei,scenej)(k) | swap(scenei,scenej)(k)

∈ SWAP (V )(k) ∧ ¬tabu (scene1, scene2, j)}

Second, in addition to the non-tabu moves, the neighborhood of the movesthat improve the best solution found so far is also considered:

SWAP t(V )(k, k

∗) ={

swap(scenei,scenej)(k) |

swap(scenei,scenej)(k) ∈ SWAP (V )(k) ∧

Oisceneallocation

(swap(scenei,scenej)(k)

)< Oiscene

allocation(k∗)

}Finally, the restarting component reinitializes the search from a random con-figuration whenever the minimum cost found so far can not be improved upona maximum number of non-improving iterations.


1 while some allocated resource (such as running time or a number ofiterations) has not been exhausted

2 select two different days and one scene shot in each of these days suchthat the increase in the evaluation of the objective function by swapping thetwo scenes of days is minimum (the goal is to minimize the cost givenby this function).

3 swap the two scenes of days

162

SET-SCENE-ALLOCATION-LS(Actors,Days, fee, appears)1 tabu ← ∅2 k∗ ← k ← initial configuration3 it ← n← 04 maxNonImproving ← 150005 while timeout ¬expired ∧ it ≤ maxNbIterations6 select swap(scenei,s1,s2,scenej)(k) ∈

(SWAP t

(V )(k, it) ∪

SWAP t(V )(k, k

∗))

7 minimizing Ossceneallocation

(swap(scenei,s1,s2,scenej)(k)

)89 τ ← RANDOM([100, 200])

10 tabu ← tabu ∪ {〈s1, s2, it + τ〉}11 k ← swap(scenei,s1,s2,scenej)(k)12 if Osscene

allocation(k) < Osscene

allocation(k∗)

13 k∗ ← k14 n← 015 if n > maxNonImproving16 k ← new random configuration17 tabu ← ∅18 n← 019 else20 n← n+ 121 it ← it+ 1

Figure 10.3: CBLS algorithm for the set approach to the Scene Allocation problem.

which is enhanced with a variable length tabu-list, an aspiration criterion andrestarts. The search heuristic is shown in Figure 10.3. Both the neighborhoodand meta-heuristics used by this local search algorithm are explained below.

Concerning the implementation of the search heuristic, should not surpriseto the reader that, in Line 71 of Listing 15.22 the condition of the while loopis Osscene

allocation6= 344144 since its purpose is to let the program run until the

(known) optimal solution has been reached.

10.1.5.2.1 NeighborhoodThe neighborhood of the local search consists of swapping two scenes fromdifferent days:

SWAP (V )(k) ={

swap(scenei,s1,s2,scenej)(k) | i 6= j ∧ scenei, scenej ∈ V}

163

When writing swap(S,u,v,T )(k) it is implicit that u ∈ k(S) and v ∈ k(T ).

10.1.5.2.2 Meta-HeuristicsFirst, the tabu component of the algorithm features a variable-length tabu-list which maintains triples 〈s1, s2, j〉 where the value of j is dynamicallygenerated at random in the interval [100, 200] and represents the first iterationwhere it is allowed to swap again two scenes s1 and s2 of days. The factthat swapping s1 and s2 of days at iteration it is forbidden is denoted bytabu(s1, s2, it) and therefore tabu(s1, s2, j) ↔ 〈s1, s2, j〉 ∈ tabu ∧ j ≤ it .The neighborhood then becomes:

SWAP t(V )(k, j) =

{swap(scenei,s1,s2scenej)(k) | swap(scenei,s1,s2,scenej)(k)

∈ SWAP (V )(k) ∧ ¬tabu (scene1, scene2, j)}

Second, in addition to the non-tabu moves the neighborhood consisting of themoves improving the best solution found so far is also considered:

SWAP t(V )(k, k

∗) ={

swap(scenei,s1,s2,scenej)(k) |

swap(scenei,s1,s2,scenej)(k) ∈ SWAP (V )(k) ∧

Ossceneallocation

(swap(scenei,s1,s2,scenej)(k)

)< Osscene

allocation(k∗)

}Finally, the restarting component reinitializes the search from a random con-figuration whenever the minimum cost found so far can not be improved upona maximum number of non-improving iterations.

10.1.6 Setup of the Experiment10.1.6.1 Problem Instances and Initial ConfigurationsAs explained at the beginning of this chapter, only one instance of this problemis considered here (actually, to the best of my knowledge, this is the onlyinstance available in the literature). In both approaches the search starts fromrandom initial configurations.


10.1.6.2.1 CBLS for the Integer ApproachThe Comet code for the implementation of the integer approach was partiallytaken from [26] (note the whole program is not available, just these lines)although it had to be slightly modified since it was developed with an old

164

Integer modeltime (miliseconds) iterations rest-

n average min. max. std.dev. average min. max. std.dev. arts50 8501.70 4 38645 8783.18 14795.94 6 66168 15299.35 25

Table 10.3: Run-time (in milliseconds) and number of iterations for the integer ap-proach to the Scene Allocation problem.

version of Comet. The whole program is shown in Listing 15.21 and thelines taken from the paper are Lines 44 to 51.

10.1.6.2.2 CBLS for the Set ApproachThe implementation of the CBLS algorithm for the set approach was devel-oped from scratch (taking the integer implementation as reference) and it isshown in Listing 15.22. Again, the invariants layer for set variables gave prob-lems throwing execution errors (like “Semy-Dynamic/Fully Dynamicaggregate unions not yet supported”) when attempting to useseemingly well-formed invariants. As a result, it was necessary to handcraftset invariants to handle the desired behavior. The complete implementation isgiven in Section 15.6.

10.1.6.3 The MachineAll programs were run on ASTRA’s experiment server ghoul, a machinewith an Intel Core i7-950 processor and 3 gigabytes of RAM. Instead of atimeout value or a threshold in the number of iterations, each instance was run50 times until the known optimal solution was found (i.e., until the objectivefunction evaluated to 344144).

10.2 ResultsThis section gives the results of the experiment in time and memory terms.Comparisons are made to contrast between the two approaches.

10.2.1 Integer ApproachThis section presents results for the integer approach in terms of :



165

Integer modelmem GC Usage mem VM Usage iterations per second

n average min. max. std.dev. average min. max. std.dev. average min. max. std.dev.50 19544.56 15911 23182 2397.26 32768.00 32768 32768 0.00 1733.60 1500.00 1825.40 48.11

Table 10.4: Memory usage and number of iterations per second for the integer ap-proach to the Scene Allocation problem.

Set modeltime (miliseconds) iterations rest-

n average min. max. std.dev. average min. max. std.dev. arts50 871.70 4 5212 1160.82 893.48 4 5318 1186.91 0

Table 10.5: Run-time (in milliseconds) and number number of iterations for the setapproach to the Scene Allocation problem.

Set modelmem GC Usage mem VM Usage iterations per second

n average min. max. std.dev. average min. max. std.dev. average min. max. std.dev.50 16481.04 15709 18135 617.13 32768.00 32768 32768 0.00 1036.17 1000.00 1142.86 22.74

Table 10.6: Memory usage and number of iterations per second for the set approachto the Scene Allocation problem.

10.2.2 Set ApproachThis section presents results for the set approach in terms of:



10.2.3 Comparison Between the Integer and Set ApproachesThis section presents comparisons between the integer and set approaches interms of :

• run-time (in milliseconds) in Table 10.7,

• number of iterations in Table 10.8,

• rate of iterations per second in Table 10.9,

• memory in Tables 10.10 and 10.11, and

• number of restores/restarts in Table 10.12.

The set approach found the solution far faster and required in general feweriterations. However, the integer approach reported a better rate of iterations persecond. The set approach demanded less memory and was also more stable asthe local search never had to restart.

166

Run time (miliseconds)integer model set model

n average min. max. std.dev. n average min. max. std.dev.50 8501.70 4 38645 8783.18 50 871.70 4 5212 1160.82

Table 10.7: Run-time (in milliseconds) for both integer and set approaches to theScene Allocation problem.

Number of iterationsinteger model set model

n average min. max. std.dev. n average min. max. std.dev.50 14795.94 6 66168 15299.35 50 893.48 4 5318 1186.91

Table 10.8: Number of iterations for both integer and set approaches to the SceneAllocation problem.

Iterations per secondinteger model set model

n average min. max. std.dev. n average min. max. std.dev.50 1733.60 1500.00 1825.40 48.11 50 1036.17 1000.00 1142.86 22.74

Table 10.9: Iterations per second for both integer and set approaches to the SceneAllocation problem.

GC memory usage (KB)integer model set model

n average min. max. std.dev. n average min. max. std.dev.50 19544.56 15911 23182 2397.26 50 16481 15709 18135 617.13

Table 10.10: GC-memory for both integer and set approaches to the Scene Allocationproblem.

VM memory usage (KB)integer model set model

n average min. max. std.dev. n average min. max. std.dev.50 32768.00 32768 32768 0.00 50 32768 32768 32768 0.00

Table 10.11: VM-memory for both integer and set approaches to the Scene Allocationproblem.

Total number of restartsinteger model set modeln restarts n restarts

50 25 50 0

Table 10.12: Total number of restarts for both integer and set approaches to the SceneAllocation problem.

167

10.3 ConclusionThe objective function defined on set variables for the Scene Allocation prob-lem proved its efficiency giving better performance results with respect to theinteger counterpart and yet they are essentially identical. Both models for thisproblem are simple (as simple as possible) but the model using set variables isa little more natural because it is easier to think about a day as a set of scenes(and perhaps a scene as a set of actors) and gives a better performance.

168

11. Balanced Incomplete BlockDesigns (BIBD-v-b-r-k-lambda)

A balanced incomplete block design (BIBD)1 is defined as an arrangement ofv distinct objects into b blocks such that each block contains exactly k distinctobjects, each object occurs in exactly r different blocks, and every two distinctobjects occur together in exactly lambda blocks. More formally:

A pair (V,B) where V is a set of cardinality v and B is a set ofsubsets of V (called blocks) such that |B| = b and s ∈ B →|s| = k is a balanced incomplete block design (BIBD) when eachelement of V is contained in exactly r blocks and any subset of Vof cardinality 2 is contained in exactly λ blocks.

The numbers v, b, r, k, λ are parameters of the BIBD, and hence an instanceof this problem is denoted by BIBD-v-b-r-k-lambda. The problem is toactually generate (or “design”) a balanced incomplete block design with theseparameters. Trivial necessary (but not sufficient) conditions for the existenceof BIBDs are [5]: r · v = b · k and r · (k − 1) = λ · (v − 1).

An alternative way of defining a balanced incomplete block design is interms of its incidence matrix, which is a v by b binary matrix with exactly rones per row, k ones per column, and with a scalar product of λ between anypair of distinct rows. As an example, solutions for BIBD-7-7-3-3-1 andBIBD-6-10-5-3-2 are:

0 1 1 0 0 1 01 0 1 0 1 0 00 0 1 1 0 0 11 1 0 0 0 0 10 0 0 0 1 1 11 0 0 1 0 1 00 1 0 1 1 0 0

1 0 1 1 1 0 0 0 0 10 0 1 1 0 1 1 0 1 01 1 0 1 0 0 0 1 1 00 0 0 0 1 0 1 1 1 10 1 1 0 0 1 0 1 0 11 1 0 0 1 1 1 0 0 0

Note, however, that such a binary matrix model leads to many symmetries

since, given any solution, any two rows or columns may be exchanged toobtain another solution. Constructive methods can be used to design BIBDsof special forms, but the general case is very challenging [19]. For example,[19] explains that, at the moment it was written, the smallest open instancewas BIBD-22-33-12-4-8..1BIBDs is problem number 44 at http://www.csplib.org/

169


11.1 The ExperimentThe experiment aims to design balanced incomplete block designs using set-CBLS. The idea for an alternative approach to local search is taken from [19].A good performance is expected when using a differentiable set objectivefunction (see Section 10.1.2) to guide the search.

Note that the model for this problem is not taken from [19] but rather theidea behind the search procedure. A model using set variables is introducedtogether with a differentiable set objective to detect when the local search hasto backtrack.

11.1.1 A Different Approach to Local SearchThe approach to local search used in this experiment, as explained in [19]and reproduced here, differs from the approach described in Section 3.3 be-cause configurations are no longer (by definition) complete assignments. Toillustrate this, take as an example the n-queens problem presented in Sec-tion 1.2.2. The usual local search approach (see Figure 3.1) starts from aninitial configuration (i.e., the n queens are placed, possibly randomly, on theboard) and then moves to (better) configurations until a (good enough) solu-tion is found. However, with this approach, one or more constraints are vio-lated under the current configuration until a solution configuration is found.An alternative approach would not allow constraints to be violated at any pointduring the search, i.e., would make all constraints hard.

This alternative approach begins placing queens (possibly randomly) innon-attacked positions; whenever a queen cannot be placed, it randomly (orusing some heuristic) removes one or more (placed) queens (i.e., backtracks)and continues until all queens are placed (i.e., until a solution is found). It ispossible to see the number of unplaced queens (unassigned variables) as thecost function to be minimized. For instance, this alternative approach to localsearch applied to 5-queens is shown in Figure 11.1.

Two advantages of this approach are that [19]: local search can concentrateits efforts on feasibility and this form of local search can be integrated with(at least some forms of) constraint propagation in the tightest possible way(not done here): propagation prunes states from the search space, as in manybacktracking algorithms.

11.1.2 ModelThe set model associates a set variable objects[b] with every block b to rep-resent the set of objects assigned to b. There are two types of constraints: thecardinality constraints and the λ-constraints. All constraints are made hard;however, since configurations here are not complete assignments, having allconstraints not violated does not imply that a solution has been found.

170

Figure 11.1: Alternative local search approach to 5-queens.

A (set) objective function has been introduced to the model such that itevaluates to zero if and only if all of the constraints have been satisfied, other-wise it evaluates to a positive number representing the violation degree of theproblem. Naturally, the objective function provides differentiation methods.

11.1.2.1 Objective FunctionGiven two distinct objects o1 and o2 in V , and a configuration `; let us denoteby #`(o1, o2) the number of blocks containing both o1 and o2 under `. Sinceit is desired that every two distinct objects occur exactly in λ blocks (theseare the λ-constraints), the number of times o1 and o2 occur in the same blockbeyond or below the allowed number λ is given by:

#′`(o1, o2) = |#`(o1, o2)− λ|

and, hence, it is possible to compute how violated a given object o is withrespect to the λ-constraints by: ∑

o2 6=o∈V#′`(o, o2)

Likewise, it is possible to compute how violated an object o and a block b arewith respect to the cardinality constraints respectively by:

||blocks`(o)| − r| and ||`(b)| − k|

where blocks`(o) gives the set of blocks containing an object o under `.Given a configuration `, the objective function is then given by:

OBIBD =∑b∈B||`(b)| − k|+

∑o∈V||blocks`(o)| − r|+

∑o∈V

∑o2 6=o∈V

#′`(o, o2)

171

The way add and drop differentiation functions compute their values isstraightforward from the previous definitions as they compute respectivelyhow many constraints would be violated when adding or dropping an objectto a block and how many constraints would no longer be violated when addingor dropping an object from a block.

11.1.2.2 Set-COPGiven a set of objects indexed by V = U 2 and a set of blocks B, the set-COPfor balanced incomplete block designs is given by:

• V = {objectsb | b ∈ B}

• D = P(U); and

• O ={

cost =∑b∈B||objectsb| − k|+

∑o∈V||objects(o)| − r|+

∑o∈V

∑o2 6=o∈V

#′(o, o2)

(where the (cost) objective function was explained in the previous section).

11.1.3 Search HeuristicThe basic idea of the search procedure for the set approach is:

1 while OBIBD 6= 0 ∧ timeout not expired2 select a block and an object that is not contained in that block such

that the increase in the evaluation of the objective function by addingthe object to that block is minimum (the goal is to minimize the costgiven by this function).

3 add the object to the block4 if the increase in the evaluation of the objective function by

adding the object to the block is greater than zero5 select, among the best 5, n objects from any block such

that the increase in the evaluation by dropping these objectsfrom its blocks is minimum

6 drop the selected objects from its blocks.

which is enhanced with a noise parameter n. The search heuristic is shown inFigure 11.2 and both the neighborhood and the meta-heuristics are explainedbelow.

2please, do not confuse this V which stands for the set of the v distinct objects with the V usedfor the set of variables of the set-COP

172

BIBD-LS(Nv,Nb, k, r, λ)1 k ← “empty configuration”2 it ← nbBacktracks ← 03 noise ← 54 while OBIBD(Nv ,Nb,k,r,λ)(k) 6= 0 ∧ timeout ¬expired5 select add (objectsb,o)

(k) ∈ ADD(V )(k)6 minimizing OBIBD

(add (objectsb,o)

(k))

7 O′ ← OBIBD(Nv ,Nb,k,r,λ)(k)8 k ← add (objectsb,o,)

(k)9 if

(OBIBD(Nv ,Nb,k,r,λ)(k)−O′

)> 0

10 nbBacktracks ← nbBacktracks+ 111 n← 012 while n < noise13 select[5] drop(objectsb′ ,o

′)(k) ∈ DROP(V )(k)

14 minimizing OBIBD

(drop(objectsb′ ,o

′)(k))

15 k ← drop(objectsb′ ,o′)(k)

16 n← n+ 117 it ← it+ 1

Figure 11.2: CBLS algorithm to generate balanced incomplete block designs.

11.1.3.1 HeuristicThe neighborhoods are the sets of add and drop moves:

ADD(V )(k) ={

add (objectsb,o)(k) | objectsb ∈ V

}DROP(V )(k) =

{drop(objectsb,o)

(k) | ∧ objectsb ∈ V}

Recall that when writing drop(S,u)(k) it is implicit that u ∈ k(S) and whenwriting add (S,v)(k) it is implicit that v ∈ k(S).

11.1.3.2 Meta-HeuristicsIn order to backtrack, n objects are dropped. The value n is called a noiseparameter [19] and could be specified at runtime. However, here the value is(arbitrarily) fixed to 5.

173

11.1.4 Setup of the Experiment11.1.4.1 Problem Instances and Initial ConfigurationsThere is no need of an initial configuration for this approach. Instances for thisproblem are taken from the tables given in [19].

11.1.4.2 The ImplementationThe implementation is shown in Section 15.9. The implementation of the (set)objective function (shown in Listing 15.26) required the implementation of auser-defined invariant (shown in Listing 15.27) to keep the the set of blockscontaining a given object.

11.1.4.3 The MachineAll programs were run on ASTRA’s experiment server ghoul, a machinewith an Intel Core i7-950 processor and 3 gigabytes of RAM. A timeout of 5minutes was set, and each instance was run 25 times.

11.2 ResultsMost of the instances with v · b < 1400 and k = 3 have been solved (fromtables in Figures 4 and 5 in [19]). However, for instances with v · b < 1000and k 6= 3 (from tables in Figures 5, 6 and 7 in [19]) only very few of themhave been solved using this approach and therefore they are not listed in thetables below. No attempts have been made to improve or tune the algorithm.

Tables 11.1 and 11.3 give the results in terms of run-time (in milliseconds)and number of iterations, and Tables 11.2 and 11.4 in terms of number ofbacktracks and iterations per second. Most of the solved instances reportedfewer backtracks.

11.3 ConclusionA simple set model for BIBD-v-b-r-k-lambda has been given using setvariables and it was combined with an alternative approach to local search thatwas found to be successful in a previous study, moreover an objective functionwas defined over set variables to drive the search. Several instances have beensolved requiring fewer backtracks (than reported in the previous study).

174

instance time (miliseconds) iterationsv-b-r-k-lambda n average min. max. std.dev. average min. max. std.dev.

6-10-5-3-2 25 36.84 15 57 7.43 185.40 80 275 33.516-20-10-3-4 25 62.72 60 64 1.34 160.00 160 160 0.006-30-15-3-6 25 80.64 76 85 2.40 145.00 145 145 0.006-40-20-3-8 25 359.32 97 565 88.69 412.80 135 630 94.13

6-50-25-3-10 25 357.88 197 735 120.00 338.00 205 655 100.086-60-30-3-12 25 253.32 242 263 5.40 220.00 220 220 0.006-70-35-3-14 25 1636.04 400 3931 973.52 966.60 285 2225 539.226-80-40-3-16 25 1461.20 512 5106 784.92 759.40 310 2480 370.39

7-14-6-3-2 25 27.44 26 29 0.87 82.00 82 82 0.007-21-9-3-3 25 94.96 92 99 2.05 168.00 168 168 0.00

7-28-12-3-4 25 176.48 171 183 2.82 229.00 229 229 0.007-35-15-3-5 25 839.20 813 855 8.51 780.00 780 780 0.007-42-18-3-6 25 1451.92 351 3551 712.01 1085.80 286 2611 521.007-49-21-3-7 25 1737.48 276 6068 1112.44 1107.80 207 3802 688.997-56-24-3-8 25 5321.04 270 21522 4384.39 2869.80 188 11548 2339.327-63-27-3-9 25 2974.40 684 7070 1564.45 1427.20 364 3329 728.41

7-7-3-3-1 25 8.20 7 9 0.58 51.00 51 51 0.008-56-21-3-6 25 9093.72 634 32224 7367.75 3727.20 293 13198 2952.40

9-12-4-3-1 25 218.88 17 650 168.56 427.20 41 1261 325.969-24-8-3-2 25 4896.20 192 7855 2913.50 4216.20 177 6767 2487.76

9-36-12-3-3 25 1355.32 484 13347 3035.42 726.00 283 7073 1575.329-48-16-3-4 25 19425.56 3424 64960 15740.07 7495.00 1364 24954 6058.2310-30-9-3-2 25 14803.88 1134 54112 10667.76 8112.00 635 29850 5888.6713-26-6-3-1 16 220969.56 23329 286692 93872.69 84661.75 8883 109013 36025.78

Table 11.1: Run-time (in milliseconds) and number of iterations for the set approachto find BIBDs.

instance nbBacktracks iterations per secondv-b-r-k-lambda n average min. max. std.dev. average min. max. std.dev.

6-10-5-3-2 25 31.08 10 49 6.70 5055.59 4743.59 5333.33 183.626-20-10-3-4 25 20.00 20 20 0.00 2552.16 2500.00 2666.67 55.526-30-15-3-6 25 11.00 11 11 0.00 1799.64 1705.88 1907.89 53.416-40-20-3-8 25 58.56 3 102 18.83 1160.51 1115.04 1391.75 56.33

6-50-25-3-10 25 37.60 11 101 20.02 954.56 891.16 1040.61 41.846-60-30-3-12 25 8.00 8 8 0.00 868.84 836.50 909.09 18.486-70-35-3-14 25 151.32 15 403 107.84 611.33 566.01 712.50 43.636-80-40-3-16 25 103.88 14 448 74.08 526.31 485.70 605.47 21.05

7-14-6-3-2 25 8.00 8 8 0.00 2991.21 2827.59 3153.85 94.467-21-9-3-3 25 21.00 21 21 0.00 1769.96 1696.97 1826.09 38.06

7-28-12-3-4 25 29.00 29 29 0.00 1297.91 1251.37 1339.18 20.647-35-15-3-5 25 135.00 135 135 0.00 929.55 912.28 959.41 9.507-42-18-3-6 25 191.96 32 497 104.20 753.95 704.75 814.81 21.687-49-21-3-7 25 192.16 12 731 137.80 646.88 608.84 750.00 27.457-56-24-3-8 25 540.36 4 2276 467.86 555.33 510.00 696.30 38.897-63-27-3-9 25 247.64 35 628 145.68 483.63 470.56 532.16 12.11

7-7-3-3-1 25 6.00 6 6 0.00 6249.52 5666.67 7285.71 446.168-56-21-3-6 25 711.84 25 2606 590.48 415.92 384.69 462.15 12.769-12-4-3-1 25 78.24 1 245 65.19 1985.41 1870.06 2411.76 102.319-24-8-3-2 25 828.84 21 1339 497.55 869.85 815.43 946.63 28.34

9-36-12-3-3 25 123.60 35 1393 315.06 566.01 500.66 584.71 16.839-48-16-3-4 25 1470.20 244 4962 1211.65 386.41 372.91 398.36 4.1910-30-9-3-2 25 1604.40 109 5952 1177.73 547.41 538.98 559.96 5.3413-26-6-3-1 16 16916.75 1761 21787 7205.16 382.93 377.94 399.52 4.75

Table 11.2: Number of backtracks and number of iterations per second for the setapproach to find BIBDs.

175

instance time (miliseconds) iterationsv-b-r-k-lambda n average min. max. std.dev. average min. max. std.dev.

7-70-30-3-10 25 1995.52 632 6861 1541.18 867.60 310 2825 622.527-77-33-3-11 25 7019.84 2255 19846 3062.90 2636.00 886 7611 1170.617-84-36-3-12 25 15873.68 1079 37627 7036.82 5343.20 427 12622 2344.867-91-39-3-13 25 20458.04 1736 43142 9753.69 6261.20 598 13133 2949.959-108-36-3-9 3 231001.00 152939 296051 72437.87 34662.33 23509 43044 10058.11

9-120-40-3-10 4 153907.00 101101 243905 66997.07 20886.25 13825 32925 8995.469-60-20-3-5 25 64976.96 5517 195978 35595.42 19738.20 1655 59195 10754.099-72-24-3-6 24 58883.04 2098 268758 66727.64 14260.17 546 65681 16197.119-84-28-3-7 22 97628.00 16662 292458 60499.31 19735.86 3402 58867 12173.589-96-32-3-8 23 151502.17 31699 226905 43016.08 26549.96 5573 39653 7563.72

10-120-36-3-8 1 252336.00 252336 252336 - 27630.00 27630 27630 -10-60-18-3-4 7 79642.29 12680 226417 71108.06 19628.57 3135 55905 17582.2710-90-27-3-6 0 > timeout - - - - - - 0

11-110-30-3-6 1 28735.00 28735 28735 - 2910.00 2910 2910 -11-55-15-3-3 3 174163.33 121851 217719 48530.17 38868.33 27415 48630 10708.1912-44-11-3-2 3 167343.67 108756 217367 54809.65 40843.67 26207 53217 13646.5012-88-22-3-4 0 > timeout - - - - - - 0

13-104-24-3-4 0 > timeout - - - - - - 013-52-12-3-2 0 > timeout - - - - - - 013-78-18-3-3 0 > timeout - - - - - - 0

15-35-7-3-1 1 11665.00 11665 11665 - 2370.00 2370 2370 -15-70-14-3-2 0 > timeout - - - - - - 016-80-15-3-2 0 > timeout - - - - - - 0

19-57-9-3-1 0 > timeout - - - - - - 0

Table 11.3: Run-time (in milliseconds) and number of iterations for the set approachto find BIBDs.

instance nbBacktracks iterations per secondv-b-r-k-lambda n average min. max. std.dev. average min. max. std.dev.

7-70-30-3-10 25 131.52 20 523 124.50 445.97 411.75 490.51 18.507-77-33-3-11 25 481.00 131 1476 234.12 376.06 362.12 392.90 7.537-84-36-3-12 25 1018.24 35 2474 468.97 341.20 321.26 395.74 15.437-91-39-3-13 25 1197.64 65 2572 589.99 308.91 295.88 344.47 9.579-108-36-3-9 3 6867.67 4637 8544 2011.62 150.84 145.39 153.71 4.72

9-120-40-3-10 4 4105.25 2693 6513 1799.09 135.88 134.99 136.74 0.769-60-20-3-5 25 3911.64 295 11803 2150.82 304.04 299.98 309.74 2.119-72-24-3-6 24 2808.83 66 13093 3239.42 244.51 229.84 262.63 5.949-84-28-3-7 22 3896.77 630 11723 2434.72 202.43 200.04 212.42 2.459-96-32-3-8 23 5252.39 1057 7873 1512.74 175.23 169.84 176.73 1.42

10-120-36-3-8 1 5454.00 5454 5454 - 109.50 109.50 109.50 -10-60-18-3-4 7 3889.71 591 11145 3516.45 245.98 243.03 247.52 1.6210-90-27-3-6 0 - - - - - - - -

11-110-30-3-6 1 516.00 516 516 - 101.27 101.27 101.27 -11-55-15-3-3 3 7740.67 5450 9693 2141.64 223.36 221.74 224.99 1.6312-44-11-3-2 3 8142.33 5215 10617 2729.30 243.62 240.97 245.05 2.2912-88-22-3-4 0 - - - - - - - -

13-104-24-3-4 0 - - - - - - - -13-52-12-3-2 0 - - - - - - - -13-78-18-3-3 0 - - - - - - - -15-35-7-3-1 1 453.00 453 453 - 203.17 203.17 203.17 -

15-70-14-3-2 0 - - - - - - - -16-80-15-3-2 0 - - - - - - - -19-57-9-3-1 0 - - - - - - - -

Table 11.4: Number of backtracks and number of iterations per second for the setapproach to find BIBDs.

176

Part VI:

Conclusions and References

12. Conclusions

This thesis demonstrates that the effect of set variables for Constraint-basedLocal Search is not only a convenience for faster and higher-level modeling,but also sometimes necessary because both:

• it can lead to a better search heuristic requiring less search time and tosolutions that otherwise may not be able to be found (witness the SocialGolfer Problem experiment in Chapter 7), and

• it can lead to find solutions to problem instances that with integer variableswould not fit into memory or take much more time to be solved (witnessthe experiments on Steiner Triple Systems and Schur’s lemma in Chapters 8and 9 respectively).

Notice the experiments comparing between integer and set approaches tothe same problem have been made as rigourously as possible, in particulartrying to avoid being handicapped by (sometimes) not being working withinthe Comet kernel. Unfortunately, this was not always possible since, for ex-ample, when implementing constraints, unlike invariants on integer variables,many invariants on set variables had to be handcrafted. Moreover, there is nodoubt about the existence of some overhead when using all the machineryintroduced in Chapter 6 as it was implemented outside of the Comet ker-nel. Just as a reference, be aware that a previous study in [17], where theauthors present a framework for using graph constraints and tree constraintsin Comet, has found the implementation in Comet around 2.5 times slowerthan the counterpart implemented in C++. Comet might have been imple-mented in C++. Despite of all these, most measures have reported very goodresults for the set approach.

However, after making efforts to make rigorous experiments contrastingCBLS using constraints on integer variables against CBLS using constraintson set variables, and clearly showing that set variables are useful, sometimeseven necessary, and moreover that constraints on them can achieve outstand-ing performance; at this point, the author of this thesis believes that, for prac-tical purposes, such a rigid separation between integer and set approaches isunnecessary. The separation between CSP and set-CSP (where all variablesare set variables) may sometimes be good (for instance, to study CBLS usingset variables in isolation) but it seems that CSPs can definitely benefit fromboth worlds.

179

For example, consider the experiment on Schur’s lemma in Chapter 9 andthe CSP given in Section 9.1.1.1. One could attempt to write one global con-straint for this model (which uses integer variables) to obtain the k sum-freesets. However, this is very likely to mean to have to incrementally maintain ksets according to the values taken by the incremental integer variables. Thiswould then be like channeling the integer variables to these sets and in practiceequivalent to forge k set variables. As a result, the argument of using a pureinteger model would be gone. Another attempt would be to mimic the use ofset variables using integer variables (like in the CSP given for the experimenton the Social Golfer Problem in Section 7.1.1). However, a major problemto represent sets using integer variables is the non-existence of constraints onthe cardinality of the k sets. A workaround might exist, but it is very likely todemand even more integer variables and, as a result, give worse results thanthose reported by the current solution.

The scenario in the current implementation of Comet is opportune to ex-periment with mixed models (i.e., CSPs defined on both integer and set vari-ables – see Section 13.2). However, a step further would be to instead of pro-viding sets of integers as incremental variables (e.g., set variables in Comet),provide incremental set variables over elements that are in turn incrementalvariables. For instance, sets of integer variables as incremental variables. Thisidea is not new at all since, for example, [12] explains that one distinctivefeature of the constraint logic programming framework CLPS (Legeard andLegros) was to allow set elements to range over integer domains.

The experiment on the Social Golfer Problem in Chapter 7 has shown thepotential of being able to reason at both element and set levels. Using setconstraints, new search procedures can be designed exploiting the structureexpressed in the model using set variables, and provide a better guidance inthe neighborhood exploration toward high-quality solutions.

Another interesting point is to notice that many of the problems discussedhere are well known problems posed by mathematicians. The mathematicallink between some of them is known and this was reflected here with thesimilarity of the constraints used when stating their (set-)CSPs.

Finally, it is worth to mention that even though it is great to have a freelicence to use Comet for academic purposes, the limitations of not havingaccess to the actual source code can sometimes generate both doubts and frus-tration when performing experiments of this kind. Be aware, however, that aforum for general postings and questions about the Comet platform is avail-able on the web.

Overall, this thesis demonstrates the same effect of set variables for CBLSas was already shown for classical CP (under systematic search) in [27],namely that set variables are not only a convenience for faster and higher-level modeling, but could also sometimes be necessary because solutions toproblem instances with integer variables may not be found otherwise, wouldnot fit into memory, or take much more time to be solved.

180

13. Contributions and Further Work

13.1 ContributionsThis thesis, besides providing solid evidence that set variables for Constraint-based Local Search are useful, even necessary, and that constraints on set vari-ables can achieve outstanding performance, has made the following contribu-tions:

• A unified framework of definitions from Constraint Modeling to Constraint-based Local Search in Part I. Most of them collected from the main bibli-ographical sources (see Chapter 14), some of them slightly modified anda few formulated only here (basically those in section Section 3.4). Note,however, that even though the author made a great effort to be as formal andcomplete as possible, this was done just as a way to introduce the reader toCBLS from scratch.

• The design and implementation of an extension of Comet’s Constraint-based Local Search back-end to support constraints on set variables to-gether with a mechanism to combine such constraints (namely a Set Con-straint System) in Part III.

• The design and implementation of the GlobalAtMost1 constraint on setvariables for Constraint-based Local Search in Section 7.1.1.4 and List-ing 15.6 respectively.

• The design and implementation of a solution to the Social Golfer Problemusing constraints on set variables for Constraint-based Local Search. Themodel and search heuristic are described in Chapter 7 while the implemen-tation is shown in Section 15.2.

• Two instances of golf-g-s-w have been solved for the first time usinga tabu-search meta-heuristic (see Section 7.2.4). Namely golf-10-6-7and golf-10-8-5. However, this instances have also been reported to besolved by a memetic algorithm combining ideas from the realm of evolu-tionary programming and tabu-search (see [6]).

• The design and implementation of a solution to find Steiner Triple Systemsusing constraints on set variables for CBLS. The model and the searchheuristic are described in Chapter 8 while the implementation is given inSection 15.4.

• Instances of sts-v have been solved up to sts-109 without difficulty(i.e, larger instances could probably also be solved but the current version

181

of the Comet systems, that is version 2.1, throws an internal Errorfor the given implementation – see Section 8.2.4).

• The design and implementation of the sum-free constraint on set vari-ables for Constraint-based Local Search in Section 9.1.1.2.1 and Listing 15.18respectively.

• A solution to find Schur numbers using constraints on set variables forConstraint-based Local Search. The model and the search heuristic are de-scribed in Chapter 9 while the implementation is given in Section 15.6.

• A further extension of Comet’s Constraint-based Local Search back-end tosupport objective functions on set variables in Section 10.1.2 together withtwo set objective functions designed and implemented to solve the SceneAllocation Problem and to find BIBDs in Sections 10.1.4 and 11.1.2.1 andListings 15.23 and 15.26 respectively.

13.2 Further WorkThere are many ways to extend the work done for this thesis:

• Using the current version of Comet (i.e., version 2.1) it is already pos-sible to experiment with CSPs defined on both integer and set variables.Notice, for instance, that both the implemented user-defined invariants oninteger variables (e.g., the Meet invariant in Listing 15.3) and the imple-mented user-defined invariants on set variables (e.g., the MeetSet invari-ant in Listing 15.7) implement the same Invariant<LS> interface. As aconsequence, there should not be any problems implementing user-definedinvariants involving both integer and set variables. This means constraintsinvolving both integer and set variables (at the same time) could also beimplemented. An example of such a constraint is a cardinality constraint|S| ≤ z where S is an incremental set variable and z an incremental integervariable. The next step would be then to implement a constraint combinatorfor such constraints. This can be certainly done in a similar fashion to whatwas done here in Chapter 6 for set constraints.

• Another different approach to combine constraints on integer variables withconstraints on set variables (available now in Comet with the machineryintroduced in Chapter 6) is through a constraint combinator. A constraintsystem of this nature should not be difficult to implement taking as base theimplementation given in Listing 6.4 and described in Section 6.3.

• Inspired by [17], other higher-order variables (e.g., sequence variables)could be introduced to Comet. Even though the kernel of Comet pro-vide only integer and set incremental variables and its open architecturestarts one layer above (i.e., at the invariants level – see Figure 4.1), otherhigher-order variables could be introduced on top of the existing ones (per-

182

haps adding an extra layer to the architecture). Then would be possible tointroduce invariants and constraints (in a similar fashion to what has beendone here in Chapter 6) on these new incremental variables. This way newexperiments could be achieved using interesting constraints and neighbor-hoods. For instance, after introducing sequence variables to Comet’s CBLSback-end, one could attempt to give an interesting solution using CBLS tothe Nurse Rostering problem.1 An implementation of the regular constraint(see the example given in Section 2.1) for CBLS in Comet has been givenin [18] and it might be adapted to operate on sequence variables. It would bealso, of course, nice to have new incremental variables within the Cometkernel. For instance, since sets in Comet are actually multi-sets, the intu-ition says that it might not be hard for the developers of Comet to providealso multi-sets as incremental variables.• For different reasons, a tabu-search meta-heuristic has been used in almost

all of the experiments presented in this thesis. There are many other heuris-tics and meta heuristics that can be tried for these problems. Some of themare well known (e.g., simulated annealing – see Section 3.3.3.1) and per-haps tried already in previous studies, but others are rather new and notlikely to have been tried (e.g., dialectic search – see [14]). Even other vari-ations on the given search heuristic and meta-heuristics can be tried (seealso [13]). For instance, in the experiment on BIBDs in Chapter 11, onecould start applying to this problem other local search heuristics but thistime complying with the definition given in Section 3.3 (not done here).Furthermore, alternative models could also be tried. For instance, considerthe matrix modeling for BIBDs shown in the introduction of Chapter 11, in-stead of using one set variable to replace each column (i.e., one set variablefor each block) one could use one set variable to replace each row.• A must-do is to re-run the programs for Steiner Triple Systems (in Chap-

ter 8) and Schur’s Lemma (in Chapter 9) with new releases of Comet. Itseems that the Comet system may be suffering of a memory leak rightnow. This should not be a surprise as a previous master student workingon his thesis at the ASTRA research group, some time ago, has already ex-perienced this kind of problems. A better idea might be to implement thesame solutions in C or C++ (this also applies to the solution given to theSocial Golfer Problem – see the next point), and run largest instances ofthese problems starting with sts-111 and sts-115.• It is also necessary to give an implementation in C or C++ to both of the

solutions given to the Social Golfer Problem (in Chapter 7). First, to mea-sure (again) the run-times for the problem instances using both of the ap-proaches, and based on the new comparisons determine more preciselywhich is the impact of using set variables (and set constraints) on this

1there exists a big library for this problem called NSPLib available at http://www.projectmanagement.ugent.be/nsp.php

183

http://www.projectmanagement.ugent.be/nsp.php

http://www.projectmanagement.ugent.be/nsp.php

problem. And, second, to check whether the new implementations can findsolutions for all of the instances shown in Table 7.2 since some of themcould not be found with the Comet implementation given in Sections 15.1and 15.2 (see Table 7.16).

• A good idea is to provide one single global constraint for the set approach tothe Schur’s lemma (see the set-CSP in Section 9.1.1.2). Once successfullydone using Comet, a tailored implementation in C or C++ could also bedeveloped in order to attempt to be lucky and lessen the current boundsgiven for Schur’s numbers. There is always hope to determine S(5).

• An alternative path, not completely unrelated to this thesis, is to experimentwith hybrid techniques integrating CP and CBLS using Comet. 2

• Comet has been the state-of-the-art in Constraint-based Local Search sys-tem for several years. However, it could be also interesting to make exper-iments with other systems released under an open source license. For ex-ample, another Constraint-based Local Search system named Kangaroo[16] has emerged and it has already been compared with Comet.

2see, for a good starting point, the slides on “Hybrid Techniques: CP + CBLS” availableat http://www.gecode.org/events/acp-summerschool-2011/programme.html

184

http://www.gecode.org/events/acp-summerschool-2011/programme.html

http://www.gecode.org/events/acp-summerschool-2011/programme.html

14. Bibliography

Anyone who would like to extend the work done for this thesis, besides thisdocument, might (in particular) want to have the following at hand:

• “The Comet tutorial” (available with the distribution of Comet, i.e., [1]).

• “Constraint-Based Local Search” by Pascal Van Hentenryck and LaurentMichel, i.e., [25].

• “Set Constraints for Local Search” by Magnus Ågren, i.e., [2].

• “Principles of Constraint Programming” by Krzysztof R. Apt, i.e., [4].

For more resources, there is a web page maintained by the ASTRA researchgroup available at http://www.it.uu.se/research/group/astra/resources/constraint.

185

http://www.it.uu.se/research/group/astra/resources/constraint

http://www.it.uu.se/research/group/astra/resources/constraint

15. References

[1] Comet Tutorial. Dynamic Decision Technologies, Providence, USA, May 2010.Available with the distrubution of Comet 2.1 at http://dynadec.com/.

[2] Magnus Ågren. Set Constraints for Local Search. PhD thesis, Departmentof Information Technology, Uppsala University, Sweden, 2008. Available athttp://urn.kb.se/resolve?urn=urn:nbn:se:uu:diva-8373.

[3] Magnus Ågren, Pierre Flener, and Justin Pearson. Set variables and local search.In Roman Barták and Michela Milano, editors, Proceedings of CP-AI-OR’05,volume 3524 of LNCS, pages 19–33. Springer-Verlag, 2005.

[4] Krzysztof R. Apt. Principles of Constraint Programming. Cambridge UniversityPress, 2003.

[5] Charles J. Colbourn and Jeffrey H. Dinitz, editors. The CRC Handbook of Com-binatorial Designs. CRC Press, 1996. A new edition of this book is available:see details at http://www.cems.uvm.edu/~dinitz/hcd.html.

[6] Carlos Cotta, Iván Dotú, Antonio J. Fernández, and Pascal Van Hentenryck.Scheduling social golfers with memetic evolutionary programming. In HybridMetaheuristics, volume 4030 of LNCS, pages 150–161. Springer-Verlag, 2006.

[7] Grégoire Dooms, Yves Deville, and Pierre Dupont. CP(Graph): Introducinga graph computation domain in constraint programming. In Peter van Beek,editor, Proceedings of CP’05, volume 3709 of LNCS, pages 211–225. Springer-Verlag, 2005.

[8] Iván Dotú and Pascal Van Hentenryck. Scheduling social tournaments locally.In AI Communications, volume 20, pages 151–162. IOS Press, 2007.

[9] Torsten Fahle, Stefan Schamberger, and Meinolf Sellmann. Symmetry breaking.In Toby Walsh, editor, Proceedings of CP’01, volume 2239 of LNCS, pages 93–107. Springer-Verlag, 2001.

[10] Pierre Flener. “Lecture 03: Consistency”. ASTRA Research Group on CP, Au-gust 2010. Slides used in the Autumn 2010 Constraint Programming course atUppsala University. Available at http://www.it.uu.se/edu/course/homepage/consprog/ht10/schedule/L03b-Consistency.pdf.

[11] Pierre Flener. “Topic 11: Constraint-Based Local Search”. ASTRAResearch Group on CP, November 2010. Slides used in the Autumn2010 Constraint Programming course at Uppsala University. Available at

187

http://dynadec.com/

http://urn.kb.se/resolve?urn=urn:nbn:se:uu:diva-8373

http://www.cems.uvm.edu/~dinitz/hcd.html

http://www.it.uu.se/edu/course/homepage/consprog/ht10/schedule/L03b-Consistency.pdf

http://www.it.uu.se/edu/course/homepage/consprog/ht10/schedule/L03b-Consistency.pdf

http://www.it.uu.se/edu/course/homepage/consprog/ht10/schedule/L11-LocalSearch.pdf.

[12] Carmen Gervet. Interval propagation to reason about sets: Definition and imple-mentation of a practical language. Constraints, 1(3):191–244, 1997.

[13] Fred Glover and Manuel Laguna. Tabu search. In Modern Heuristic Techniquesfor Combinatorial Problems, pages 70–150. John Wiley & Sons, 1993.

[14] Serdar Kadioglu and Meinolf Sellmann. Dialectic search. In Ian Gent, editor,CP’09, volume 5732 of LNCS, pages 486–500. Springer, 2009.

[15] Laurent Michel and Pascal Van Hentenryck. Comet in context. In PCK50 Pro-ceedings of the Paris C. Kanellakis memorial workshop on Principles of Com-puting & Knowledge: Paris C. Kanellakis memorial workshop on the occasionof his 50th birthday, 2003.

[16] M.A.Hakim Newton, Duc-Nghia Pham, Abdul Sattar, and Michael Maher. Kan-garoo: An efficient constraint-based local search system using lazy propagation.In Jimmy Lee, editor, Proceedings of CP’11. Springer, 2011.

[17] Quang Dung Pham, Yves Deville, and Pascal Van Hentenryck. LS (Graph):A local search framework for constraint optimization on graphs and trees. InRonaldo Menezes and Mirko Viroli, editors, Proceedings of SAC’09, the 24thAnnual ACM Symposium on Applied Computing, volume III, pages 1402–1407.ACM Press, 2009.

[18] Benoit Pralong. Implémentation de la contrainte Regular en Comet. Master’sthesis, École Polytechnique de Montréal, Canada, 2007.

[19] Steven Prestwich. A local search algorithm for balanced incomplete block de-signs. In Barry O’Sullivan, editor, Recent Advances in Constraints, volume 2627of LNCS, pages 132–143. Springer, 2003.

[20] Christian Schulte. Programming constraint services. Springer, 2002.

[21] Christian Schulte. “Modeling with Regular”. School of Informa-tion and Communication Technology, KTH, November 2010. Slidesused by Christian Schulte in a guest lecture given in the Autumnof 2010 for the Constraint Programming course at Uppsala Univer-sity. Available at http://www.it.uu.se/edu/course/homepage/consprog/ht10/schedule/L12-Regular.pdf.

[22] Christian Schulte. Course Notes. Constraint Programming (ID2204). Springsemester. 2011. Available at http://www.ict.kth.se/courses/ID2204/notes/ID2204-CN.pdf.

[23] Pascal Van Hentenryck. Constraint and integer programming in OPL.INFORMS Journal on Computing, 14(4):345–372, 2002. Availableat http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.102.1278.

188

http://www.it.uu.se/edu/course/homepage/consprog/ht10/schedule/L11-LocalSearch.pdf

http://www.it.uu.se/edu/course/homepage/consprog/ht10/schedule/L11-LocalSearch.pdf

http://www.it.uu.se/edu/course/homepage/consprog/ht10/schedule/L12-Regular.pdf

http://www.it.uu.se/edu/course/homepage/consprog/ht10/schedule/L12-Regular.pdf

http://www.ict.kth.se/courses/ID2204/notes/ID2204-CN.pdf

http://www.ict.kth.se/courses/ID2204/notes/ID2204-CN.pdf

http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.102.1278

http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.102.1278

[24] Pascal Van Hentenryck, Pierre Flener, Justin Pearson, and Magnus Ågren.Tractable symmetry breaking for CSPs with interchangeable values. In Pro-ceedings of IJCAI’03, pages 277–282. Morgan Kaufmann, 2003.

[25] Pascal Van Hentenryck and Laurent Michel. Constraint-Based Local Search.The MIT Press, 2005.

[26] Pascal Van Hentenryck and Laurent Michel. Differentiable invariants. InFrédéric Benhamou, editor, Proceedings of CP’06, volume 4204 of LNCS, pages604–619. Springer-Verlag, 2006.

[27] Willem-Jan van Hoeve and Ashish Sabharwal. Two set constraints for mod-eling and efficiency. In Jimmy Lee and Peter Stuckey, editors, Proceedings ofModRef’07, the 6th International Workshop on Constraint Modelling and Refor-mulation, 2007. Available at http://www.cse.cuhk.edu.hk/~jlee/cp07Model/.

189

http://www.cse.cuhk.edu.hk/~jlee/cp07Model/

http://www.cse.cuhk.edu.hk/~jlee/cp07Model/

Appendices

Implementation of golf-g-s-w

This appendix contains the source code for the implementation of:

• social-golfer.co: a CBLS integer approach to the Social GolferProblem in Listing 15.1 (taken from [1]).

• SocialTournament.co: the SocialTournament user-defined constraintin Listing 15.2 (taken from [1]).

• Meet.co: the user-defined invariant Meet in Listing 15.3 (taken from [1]).

• social-golfer-greedy.co: a CBLS greedy integer approach to theSocial Golfer Problem in Listing 15.4.

• social-golfer-set.co: a CBLS set approach to the Social GolferProblem in Listing 15.5.

• GlobalAtMost1_LS_.co: the user-defined GlobalAtMost1<LS> con-straint in Listing 15.6.

• MeetSet.co: the user-defined invariant MeetSet in Listing 15.7.

• social-golfer-set-greedy.co: a CBLS greedy set approach tothe Social Golfer Problem in Listing 15.8.

15.1 Integer Approach1 import cotls;2 include "sg-io-functions";3 include "SocialTournament";45 Integer nbWeeks(8);6 Integer nbGroups(6);7 Integer nbSlots(3);8 string problemFiles[0..1]; //i/o files9

10 getInput(nbWeeks, nbGroups, nbSlots, problemFiles);1112 Solver<LS> m();13 range Weeks = 1..nbWeeks;14 range Groups = 1..nbGroups;15 range Slots = 1..nbSlots; // slots per group16 range Golfers = 1..(nbGroups * nbSlots);17

193

18 tuple Position {int week; int group; int slot;}1920 var{int} golfer[Weeks,Groups,Slots](m,Golfers);21 if(problemFiles[0] != null)22 initFromFile(problemFiles[0],23 Weeks,Golfers,Groups,Slots,golfer);24 else25 init(Weeks,Golfers,Groups,Slots,golfer);26 SocialTournament tourn(m,Weeks,Groups,Slots,Golfers,golfer);27 m.post(tourn);2829 var{int} conflict[w in Weeks,g in Groups,s in Slots] =30 tourn.violations(golfer[w,g,s]);31 var{int} violations = tourn.violations();32 m.close();3334 function void init(range Weeks, range Golfers, range Groups,35 range Slots, var{int}[,,] golfer) {36 forall (w in Weeks) {37 RandomPermutation golferPerm(Golfers);38 forall (g in Groups,s in Slots)39 golfer[w,g,s] := golferPerm.get();40 }41 }4243 string[][] initScheduleStr =44 getSchedule(Weeks,Groups,Slots,golfer); //save k04546 int tabu[Weeks,Golfers,Golfers] = -1;47 UniformDistribution tabuDistr(4..20);48 int best = violations;49 int it = 0;50 int nbRestarts = 0;51 int nonImprovingSteps = 0;52 int maxNonImproving = 15000;5354 int timeout = 30 * 60 * 1000; //miliseconds55 int t0 = System.getCPUTime();5657 while (violations > 0 &&58 (System.getCPUTime() - t0) < timeout )59 selectMin(w in Weeks,60 g1 in Groups,s1 in Slots: conflict[w,g1,s1] > 0,61 g2 in Groups: g2 != g1, s2 in Slots,62 delta = tourn.getSwapDelta(golfer[w,g1,s1],63 golfer[w,g2,s2]) :64 tabu[w,golfer[w,g1,s1],golfer[w,g2,s2]] < it65 || violations + delta < best)66 (delta) {67 golfer[w,g1,s1] :=: golfer[w,g2,s2];68 int tabuLength = tabuDistr.get();69 tabu[w,golfer[w,g1,s1],

194

70 golfer[w,g2,s2]] = it + tabuLength;71 tabu[w,golfer[w,g2,s2],72 golfer[w,g1,s1]] = it + tabuLength;73 if (violations < best) {74 best = violations;75 nonImprovingSteps = 0;76 }77 else {78 nonImprovingSteps++;79 if (nonImprovingSteps > maxNonImproving) {80 init(Weeks,Golfers,Groups,Slots,golfer);81 nbRestarts++;82 best = violations;83 nonImprovingSteps = 0;84 }85 }86 it++;87 }8889 int time = System.getCPUTime() - t0;90 setOutput(violations,time,it,nbRestarts,91 Weeks, Groups, Slots,92 problemFiles[1],93 initScheduleStr, golfer);

Listing 15.1: social-golfer.co: CBLS integer approach to the Social GolferProblem (taken from [1]).

1 include "Meet";23 class SocialTournament extends UserConstraint<LS> {4 Solver<LS> m;5 range Weeks;6 range Groups;7 range Slots;8 range Golfers;9

10 var{int}[,,] golfer;11 var{int}[,] meetings;12 dict{var{int}->Position} position;13 var{int}[,,] varViolations;14 var{int} violationDegree;1516 var{int}[] golfersInConflict;1718 SocialTournament(Solver<LS> _m, range _Weeks,19 range _Groups, range _Slots,20 range _Golfers, var{int}[,,] _golfer)21 : UserConstraint<LS>(_m) {22 m = _m;23 Weeks = _Weeks;24 Groups = _Groups;

195

25 Slots = _Slots;26 Golfers = _Golfers;27 golfer = _golfer;28 }2930 void post();31 var{int} violations(var{int} x);32 var{int} violations() { return violationDegree; }33 int getSwapDelta(var{int} x,var{int} y);34 var{int}[] getGolfersInConflict() {35 return golfersInConflict; }36 }3738 void SocialTournament::post() {39 Meet meetInvariant(m,Weeks,Groups,Slots,Golfers,golfer);40 m.post(meetInvariant);41 meetings = meetInvariant.getMeetings();42 position = meetInvariant.getPosition();4344 varViolations = new var{int}[w in Weeks,45 g in Groups,s in Slots](m) <-46 sum(t in Slots : t != s)47 (meetings[golfer[w,g,s],golfer[w,g,t]] >= 2);48 violationDegree = new var{int}(m) <-49 sum(g in Golfers, h in Golfers: g < h)50 max(0,meetings[g,h]-1);5152 golfersInConflict = new var{int}[w in Weeks](m) <-53 sum(g in Groups, s in Slots)54 (varViolations[w,g,s] > 0);55 }5657 var{int} SocialTournament::violations(var{int} x) {58 Position p = position{x};59 return varViolations[p.week,p.group,p.slot];60 }6162 int SocialTournament::getSwapDelta(var{int} x,var{int} y) {63 Position xp = position{x};64 Position yp = position{y};65 assert(xp.week == yp.week);66 assert(xp.group != yp.group);6768 int delta = 0;69 forall (s in Slots : s != yp.slot)70 delta += (meetings[x,golfer[yp.week,yp.group,s]] >= 1)71 - (meetings[y,golfer[yp.week,yp.group,s]] >= 2);72 forall (s in Slots : s != xp.slot)73 delta += (meetings[y,golfer[xp.week,xp.group,s]] >= 1)74 - (meetings[x,golfer[xp.week,xp.group,s]] >= 2);75 return delta;

196

76 }

Listing 15.2: SocialTournament.co: SocialTournament user-definedconstraint (taken from [1]).

1 class Meet implements Invariant<LS> {2 Solver<LS> m;3 range Weeks;4 range Groups;5 range Slots;6 range Golfers;7 var{int}[,,] golfer;8 var{int}[,] meetings;9 dict{var{int}->Position} position;

1011 Solver<LS> getLocalSolver() { return m; }12 var{int}[,] getMeetings(){ return meetings; }13 dict{var{int}->Position} getPosition(){ return position; }1415 Meet(Solver<LS> _m, range _Weeks,range _Groups,16 range _Slots,range _Golfers, var{int}[,,] _golfer) {17 m = _m;18 Weeks = _Weeks;19 Groups = _Groups;20 Slots = _Slots;21 Golfers = _Golfers;22 golfer = _golfer;23 meetings = new var{int}[Golfers,Golfers](m) := 0;24 position = new dict{var{int}->Position}();25 forall (w in Weeks, g in Groups, s in Slots)26 position{golfer[w,g,s]} = new Position(w,g,s);27 }2829 void post(InvariantPlanner<LS> planner);30 void initPropagation();31 void propagateInt(bool b,var{int} v);3233 void propagateFloat(bool b,var{float} v) {}34 void propagateInsertIntSet(bool b,var{set{int}} s,35 int value) {}36 void propagateRemoveIntSet(bool b,var{set{int}} s,37 int value) {}38 }3940 void Meet::post(InvariantPlanner<LS> planner) {41 forall (w in Weeks, g in Groups, s in Slots)42 planner.addSource(golfer[w,g,s]);43 forall (p in Golfers, q in Golfers)44 planner.addTarget(meetings[p,q]);45 }4647 void Meet::initPropagation() {

197

48 forall (w in Weeks, g in Groups)49 forall (s in Slots, t in Slots : s < t) {50 meetings[golfer[w,g,s],golfer[w,g,t]]++;51 meetings[golfer[w,g,t],golfer[w,g,s]]++;52 }53 }5455 void Meet::propagateInt(bool b,var{int} v) {56 Position p = position{v};57 int oldGolfer = v.getOld();58 int newGolfer = v;59 forall (s in Slots : s != p.slot) {60 int o = golfer[p.week,p.group,s];61 meetings[oldGolfer,o]--;62 meetings[o,oldGolfer]--;63 meetings[newGolfer,o]++;64 meetings[o,newGolfer]++;65 }66 }

Listing 15.3: Meet.co: User-defined invariant Meet (taken from [1]).

1 import cotls;2 include "sg-io-functions";3 include "SocialTournament";45 Integer nbWeeks(8);6 Integer nbGroups(6);7 Integer nbSlots(3);8 string problemFiles[0..1]; //i/o files9

10 getInput(nbWeeks, nbGroups, nbSlots, problemFiles);1112 Solver<LS> m();13 range Weeks = 1..nbWeeks;14 range Groups = 1..nbGroups;15 range Slots = 1..nbSlots; // slots per group16 range Golfers = 1..(nbGroups * nbSlots);1718 tuple Position {int week; int group; int slot;}1920 var{int} golfer[Weeks,Groups,Slots](m,Golfers);21 if(problemFiles[0] != null)22 initFromFile(problemFiles[0],23 Weeks,Golfers,Groups,Slots,golfer);24 else25 init(Weeks,Golfers,Groups,Slots,golfer);26 SocialTournament tourn(m,Weeks,Groups,Slots,Golfers,golfer);27 m.post(tourn);2829 var{int} conflict[w in Weeks,g in Groups,s in Slots] =30 tourn.violations(golfer[w,g,s]);

198

31 var{int}[] golfersInConflict = tourn.getGolfersInConflict();32 var{int} violations = tourn.violations();33 m.close();3435 function void init(range Weeks, range Golfers, range Groups,36 range Slots, var{int}[,,] golfer) {37 forall (w in Weeks) {38 RandomPermutation golferPerm(Golfers);39 forall (g in Groups,s in Slots)40 golfer[w,g,s] := golferPerm.get();41 }42 }4344 string[][] initScheduleStr =45 getSchedule(Weeks,Groups,Slots,golfer); //save k04647 int tabu[Weeks,Golfers,Golfers] = -1;48 UniformDistribution tabuDistr(4..20);49 int best = violations;50 int it = 0;51 int nbRestarts = 0;52 int nonImprovingSteps = 0;53 int maxNonImproving = 15000;5455 int timeout = 30 * 60 * 1000;56 int t0 = System.getCPUTime();5758 bool behaveGreedy = false;5960 while (violations > 0 &&61 (System.getCPUTime() - t0) < timeout )62 if(behaveGreedy) {63 selectMax(w in Weeks) (golfersInConflict[w])64 selectMin(g1 in Groups,s1 in Slots: conflict[w,g1,s1] > 0,65 g2 in Groups: g2 != g1, s2 in Slots,66 delta = tourn.getSwapDelta(golfer[w,g1,s1],67 golfer[w,g2,s2]) :68 tabu[w,golfer[w,g1,s1],golfer[w,g2,s2]] < it69 || violations + delta < best)70 (delta) {71 golfer[w,g1,s1] :=: golfer[w,g2,s2];72 int tabuLength = tabuDistr.get();73 tabu[w,golfer[w,g1,s1],74 golfer[w,g2,s2]] = it + tabuLength;75 tabu[w,golfer[w,g2,s2],76 golfer[w,g1,s1]] = it + tabuLength;77 if (violations < best) {78 best = violations;79 nonImprovingSteps = 0;80 }81 else {82 nonImprovingSteps++;

199

83 if (nonImprovingSteps > maxNonImproving) {84 init(Weeks,Golfers,Groups,Slots,golfer);85 nbRestarts++;86 behaveGreedy = !behaveGreedy;87 best = violations;88 nonImprovingSteps = 0;89 }90 }91 it++;92 }93 } else {94 selectMin(w in Weeks,95 g1 in Groups,s1 in Slots: conflict[w,g1,s1] > 0,96 g2 in Groups: g2 != g1, s2 in Slots,97 delta = tourn.getSwapDelta(golfer[w,g1,s1],98 golfer[w,g2,s2]) :99 tabu[w,golfer[w,g1,s1],golfer[w,g2,s2]] < it

100 || violations + delta < best)101 (delta) {102 golfer[w,g1,s1] :=: golfer[w,g2,s2];103 int tabuLength = tabuDistr.get();104 tabu[w,golfer[w,g1,s1],105 golfer[w,g2,s2]] = it + tabuLength;106 tabu[w,golfer[w,g2,s2],107 golfer[w,g1,s1]] = it + tabuLength;108 if (violations < best) {109 best = violations;110 nonImprovingSteps = 0;111 }112 else {113 nonImprovingSteps++;114 if (nonImprovingSteps > maxNonImproving) {115 init(Weeks,Golfers,Groups,Slots,golfer);116 nbRestarts++;117 behaveGreedy = !behaveGreedy;118 best = violations;119 nonImprovingSteps = 0;120 }121 }122 it++;123 }124 }125126 int time = System.getCPUTime() - t0;127 setOutput(violations,time,it,nbRestarts,128 Weeks, Groups, Slots,129 problemFiles[1],130 initScheduleStr, golfer);

Listing 15.4: social-golfer-greedy.co: Attempt to improve the CBLSinteger approach to the Social Golfer Problem adding a greedy component to themeta-heuristics.

200

15.2 Set Approach

1 import cotls;2 include "sg-set-io-functions";3 include "GlobalAtMost1_LS_";45 Integer nbWeeks(8);6 Integer nbGroups(6);7 Integer sizeGroup(3);8 string problemFiles[0..1]; //i/o files9

10 getInput(nbWeeks, nbGroups, sizeGroup, problemFiles);1112 Solver<LS> m();1314 range Weeks = 1..nbWeeks;15 range Groups = 1..nbGroups;16 range Slots = 1..sizeGroup; //there is no notion of slot,17 //just the name is kept18 range Golfers = 1..(nbGroups * sizeGroup);1920 var{set{int}} group[Weeks,Groups] = new var{set{int}}(m);21 if(problemFiles[0] != null)22 initFromFile(problemFiles[0],23 Weeks,Golfers,Groups,Slots,group);24 else25 init(Weeks,Golfers,Groups,Slots,group);26 GlobalAtMost1<LS> tourn(m,Weeks,Groups,Slots,Golfers,group);2728 set{int}[,] golfersInConflict= tourn.getGolfersInConflict();29 set{int}[] violatedGroups = tourn.getViolatedGroups();3031 var{int} violations = tourn.violations();32 var{int} groupViolations[w in Weeks, g in Groups] =33 tourn.violations(group[w, g]);34 m.close();3536 function void init(range Weeks, range Golfers, range Groups,37 range Slots, var{set{int}}[,] group){38 forall(w in Weeks){39 RandomPermutation perm(Golfers);40 forall(g in Groups){41 set{int} golfers = group[w,g];42 forall(e in golfers.copy())43 group[w,g].delete(e);44 forall(k in Slots)45 group[w,g].insert(perm.get());46 }47 }48 }4950 string[][] initScheduleStr =

201

51 getSchedule(Weeks,Groups,group); //save k05253 Integer tabu[Weeks,Golfers,Golfers](-1);54 UniformDistribution tabuDistr(4..20);55 Integer best(0) := violations;56 Counter it(m,0);57 Integer nbRestarts(0);58 Counter nonImprovingSteps(m,0);59 Counter improvingSteps(m,0);60 int maxNonImprovingSteps = 15000;6162 int timeout = 30 * 60 * 1000; //miliseconds63 Integer t0(0);6465 forall(w in Weeks, g in Groups){66 whenever group[w,g]@remove(int s1)67 when group[w,g]@insert(int s2)68 tabu[w,s1,s2] := it + tabuDistr.get();69 }7071 whenever nonImprovingSteps@changes(int oldV, int newV){72 if(oldV > maxNonImprovingSteps){73 init(Weeks,Golfers,Groups,Slots,group);74 nbRestarts++;75 best := violations;76 nonImprovingSteps := 0;77 }78 }7980 whenever improvingSteps@changes(){81 best := violations;82 nonImprovingSteps := 0;83 }8485 t0 := System.getCPUTime();86 while(violations > 0 &&87 (System.getCPUTime() - t0) < timeout)88 selectMin(w in Weeks,89 g1 in violatedGroups[w], g2 in Groups: g2 != g1,90 s1 in golfersInConflict[w,g1],91 s2 in group[w,g2],92 delta = tourn.getSwapDelta(group[w,g1], s1,93 s2, group[w,g2]):94 ((tabu[w,s1,s2] < it)95 || violations + delta < best))96 (delta){97 group[w,g1].delete(s1); group[w,g2].insert(s1);98 group[w,g2].delete(s2); group[w,g1].insert(s2);99 //i.e. group[w,g1] :=: group[w,g2]

100101 if(violations < best)102 improvingSteps++;

202

103 else104 nonImprovingSteps++;105106 it++;107 }108109 int time = System.getCPUTime() - t0;110 setOutput(violations,time,it,nbRestarts,111 Weeks, Groups, Slots,112 problemFiles[1],113 initScheduleStr, group);

Listing 15.5: social-golfer-set.co: CBLS set approach to the Social GolferProblem.

1 include "UserSetConstraint_LS_";2 include "MeetSet";34 class GlobalAtMost1<LS> extends UserSetConstraint<LS> {5 range _Weeks;6 range _Groups;7 range _Slots;8 range _Golfers;9

10 var{set{int}}[,] _schedule;11 dict{var{set{int}}->Position} _position;1213 //invariants14 var{int} _penalty;15 var{int}[,] _conflict;16 set{int}[,] _meetings;1718 set{int}[] _violatedGroups;19 set{int}[,] _golfersInConflict;2021 GlobalAtMost1<LS>(Solver<LS> m, range Weeks,22 range Groups, range Slots,23 range Golfers,var{set{int}}[,] schedule)24 :UserSetConstraint<LS>(m) {25 _Weeks = Weeks;26 _Groups = Groups;27 _Slots = Slots;28 _Golfers = Golfers;29 _schedule = schedule;30 post();31 }3233 var{set{int}}[] getSetVariables(){34 return all(w in _Weeks, g in _Groups) _schedule[w,g]; }35 set{int}[] getViolatedGroups() { return _violatedGroups; }36 set{int}[,] getGolfersInConflict() {37 return _golfersInConflict; }

203

3839 var{int} violations(){ return _penalty; }40 var{int} violations(var{set{int}} s){41 Position p = _position{s};42 return _conflict[p.week,p.group]; }43 }4445 void GlobalAtMost1<LS>::post(){46 if(!_posted){47 SetMeet meetInvariant(_ls, _Weeks, _Groups,48 _Slots, _Golfers, _schedule);49 _ls.post(meetInvariant);50 _meetings = meetInvariant.getMeetings();51 _position = meetInvariant.getPosition();52 _conflict = meetInvariant.getVarViolations();53 _violatedGroups = meetInvariant.getViolatedGroups();54 _golfersInConflict =55 meetInvariant.getGolfersInConflict();5657 _penalty = new var{int}(_ls) <-58 sum(w in _Weeks, g in _Groups) _conflict[w,g];59 _isSatisfied = new var{bool}(_ls) <- _penalty == 0;60 _posted = true;61 }62 }6364 int GlobalAtMost1<LS>::getSwapDelta(var{set{int}} s, int u,65 int v, var{set{int}} t){66 int delta = 0;67 forall(e in t: e != v)68 delta += (_meetings[u,e].getSize() >= 1) -69 (_meetings[v,e].getSize() >= 2);70 forall(e in s: e != u)71 delta += (_meetings[v,e].getSize() >= 1) -72 (_meetings[u,e].getSize() >= 2);7374 return delta;75 }7677 int GlobalAtMost1<LS>::getFlipDelta(var{set{int}} s, int u,78 int v){79 int delta = 0;80 forall(e in s: e != u)81 delta += (_meetings[v,e].getSize() >= 1) -82 (_meetings[u,e].getSize() >= 2);8384 return delta;85 }

Listing 15.6: GlobalAtMost1_LS_.co: Implementation of the GlobalAtMost1set-constraint.

204

1 tuple Position {int week; int group;}23 class SetMeet implements Invariant<LS> {4 Solver<LS> _m;56 range _Weeks;7 range _Groups;8 range _Slots;9 range _Golfers;

1011 var{set{int}}[,] _group;12 set{int}[,] _meetings;13 dict{var{set{int}}->Position} _position;14 //position (w,g) of an incremental set variable15 var{int}[,] _varViolations;16 set{int}[] _violatedGroups;17 set{int}[,] _golfersInConflict;1819 Solver<LS> getLocalSolver() { return _m; }20 set{int}[,] getMeetings() { return _meetings; }21 dict{var{set{int}}->Position} getPosition() {22 return _position; }23 var{int}[,] getVarViolations() { return _varViolations; }24 set{int}[] getViolatedGroups() { return _violatedGroups; }25 set{int}[,] getGolfersInConflict() {26 return _golfersInConflict; }2728 SetMeet(Solver<LS> m, range Weeks, range Groups,29 range Slots, range Golfers,30 var{set{int}}[,] group) {31 _m = m;32 _Weeks = Weeks;33 _Groups = Groups;34 _Slots = Slots;35 _Golfers = Golfers;36 _group = group;3738 _meetings = new set{int}[_Golfers,_Golfers]();39 _position = new dict{var{set{int}}->Position}();40 _varViolations = new var{int}[_Weeks,_Groups](_m) := 0;41 _violatedGroups = new set{int}[_Weeks]();42 _golfersInConflict = new set{int}[_Weeks,_Groups]();43 forall(w in _Weeks, g in _Groups)44 _position{_group[w,g]} = new Position(w,g);45 }4647 void post(InvariantPlanner<LS> p);48 void initPropagation();49 void propagateInsertIntSet(boolean b,50 var{set{int}} s, int value);51 void propagateRemoveIntSet(boolean b,52 var{set{int}} s, int value);

205

5354 //not implemented, included to avoid a compiler error55 void propagateInt(bool b, var{int} v) { assert(false); }56 void propagateFloat(bool b, var{float} v) {57 assert(false); }58 }5960 void SetMeet::post(InvariantPlanner<LS> p) {61 forall(w in _Weeks, g in _Groups)62 p.addSource(_group[w,g]);63 forall(w in _Weeks, g in _Groups)64 p.addTarget(_varViolations[w,g]);65 }6667 void SetMeet::initPropagation(){68 forall(w in _Weeks, g in _Groups)69 forall(g1 in _group[w,g], g2 in _group[w,g] : g1 < g2) {70 _meetings[g1,g2].insert(10000*w + g);71 _meetings[g2,g1].insert(10000*w + g);72 if(_meetings[g1,g2].getSize() >= 2) {73 if(_meetings[g1,g2].getSize() == 2) {74 forall(e in _meetings[g1,g2]) {75 int wkNb = e/10000;76 int gpNb = e%10000;77 _varViolations[wkNb,gpNb]++;78 _golfersInConflict[wkNb,gpNb].insert(g1);79 _golfersInConflict[wkNb,gpNb].insert(g2);80 }81 } else {82 _varViolations[w,g]++;83 _golfersInConflict[w,g].insert(g1);84 _golfersInConflict[w,g].insert(g2);85 }86 }87 }88 forall(w in _Weeks,g in _Groups: _varViolations[w,g] > 0)89 _violatedGroups[w].insert(g);90 }9192 void SetMeet::propagateInsertIntSet(boolean b,93 var{set{int}} s,94 int g1){95 Position sp = _position{s};96 forall(g2 in (_group[sp.week,sp.group] \ {g1})){97 _meetings[g1,g2].insert(10000*sp.week + sp.group);98 _meetings[g2,g1].insert(10000*sp.week + sp.group);99 if(_meetings[g1,g2].getSize() >= 2){

100 if(_meetings[g1,g2].getSize() == 2){101 forall(e in _meetings[g1,g2]){102 int wkNb = e/10000;103 int gpNb = e%10000;104 bool violatedGroup= _varViolations[wkNb,gpNb] > 0;

206

105 _varViolations[wkNb,gpNb]++;106 _golfersInConflict[wkNb,gpNb].insert(g1);107 _golfersInConflict[wkNb,gpNb].insert(g2);108 if(!violatedGroup &&109 _varViolations[wkNb,gpNb] > 0)110 _violatedGroups[wkNb].insert(gpNb);111 }112 } else {113 bool violatedGroup =114 _varViolations[sp.week,sp.group] > 0;115 _varViolations[sp.week,sp.group]++;116 _golfersInConflict[sp.week,sp.group].insert(g1);117 _golfersInConflict[sp.week,sp.group].insert(g2);118 if(!violatedGroup &&119 _varViolations[sp.week,sp.group] > 0)120 _violatedGroups[sp.week].insert(sp.group);121 }122 }123 }124 }125126 void SetMeet::propagateRemoveIntSet(boolean b,127 var{set{int}} s,128 int g1) {129 Position sp = _position{s};130 forall(g2 in _group[sp.week,sp.group]){131 if(_meetings[g1,g2].getSize() >= 2){132 if(_meetings[g1,g2].getSize() == 2){133 forall(e in _meetings[g1,g2]){134 int wkNb = e/10000;135 int gpNb = e%10000;136 bool violatedGroup= _varViolations[wkNb,gpNb] > 0;137 _varViolations[wkNb,gpNb]--;138 _golfersInConflict[wkNb,gpNb].del(g1);139 _golfersInConflict[wkNb,gpNb].del(g2);140 if(violatedGroup &&141 _varViolations[wkNb,gpNb] == 0)142 _violatedGroups[wkNb].delete(gpNb);143 }144 } else {145 bool violatedGroup =146 _varViolations[sp.week,sp.group] > 0;147 _varViolations[sp.week,sp.group]--;148 _golfersInConflict[sp.week,sp.group].del(g1);149 _golfersInConflict[sp.week,sp.group].del(g2);150 if(violatedGroup &&151 _varViolations[sp.week,sp.group] == 0)152 _violatedGroups[sp.week].delete(sp.group);153 }154 }155 _meetings[g1,g2].del(10000*sp.week + sp.group);156 _meetings[g2,g1].del(10000*sp.week + sp.group);

207

157 }158 }

Listing 15.7: MeetSet.co: User-defined invariant MeetSet.

1 import cotls;2 include "sg-set-io-functions";3 include "GlobalAtMost1_LS_";45 Integer nbWeeks(8);6 Integer nbGroups(6);7 Integer sizeGroup(3);8 string problemFiles[0..1]; //i/o files9

10 getInput(nbWeeks, nbGroups, sizeGroup, problemFiles);1112 Solver<LS> m();1314 range Weeks = 1..nbWeeks;15 range Groups = 1..nbGroups;16 range Slots = 1..sizeGroup; //there is no notion of slot,17 //just the name is kept18 range Golfers = 1..(nbGroups * sizeGroup);1920 var{set{int}} group[Weeks,Groups] = new var{set{int}}(m);21 if(problemFiles[0] != null)22 initFromFile(problemFiles[0],23 Weeks,Golfers,Groups,Slots,group);24 else25 init(Weeks,Golfers,Groups,Slots,group);26 GlobalAtMost1<LS> tourn(m,Weeks,Groups,Slots,Golfers,group);2728 set{int}[,] golfersInConflict= tourn.getGolfersInConflict();29 set{int}[] violatedGroups = tourn.getViolatedGroups();3031 var{int} violations = tourn.violations();32 var{int} groupViolations[w in Weeks, g in Groups] =33 tourn.violations(group[w, g]);34 m.close();3536 function void init(range Weeks, range Golfers, range Groups,37 range Slots, var{set{int}}[,] group){38 forall(w in Weeks){39 RandomPermutation perm(Golfers);40 forall(g in Groups){41 set{int} golfers = group[w,g];42 forall(e in golfers.copy())43 group[w,g].delete(e);44 forall(k in Slots)45 group[w,g].insert(perm.get());46 }47 }

208

48 }4950 string[][] initScheduleStr =51 getSchedule(Weeks,Groups,group); //save k05253 Integer tabu[Weeks,Golfers,Golfers](-1);54 UniformDistribution tabuDistr(4..20);55 Integer best(0) := violations;56 Counter it(m,0);57 Integer nbRestarts(0);58 Counter nonImprovingSteps(m,0);59 Counter improvingSteps(m,0);60 int maxNonImprovingSteps = 15000;61 enum BEHAVIOR = {GREEDY};62 bool behave[BEHAVIOR] = false;6364 int timeout = 30 * 60 * 1000; //miliseconds65 Integer t0(0);6667 forall(w in Weeks, g in Groups){68 whenever group[w,g]@remove(int s1)69 when group[w,g]@insert(int s2)70 tabu[w,s1,s2] := it + tabuDistr.get();71 }7273 whenever nonImprovingSteps@changes(int oldV, int newV){74 if(oldV > maxNonImprovingSteps){75 init(Weeks,Golfers,Groups,Slots,group);76 nbRestarts++;77 best := violations;78 nonImprovingSteps := 0;79 behave[GREEDY] = (behave[GREEDY]? false : true);80 }81 }8283 whenever improvingSteps@changes(){84 best := violations;85 nonImprovingSteps := 0;86 }8788 t0 := System.getCPUTime();89 while(violations > 0 &&90 (System.getCPUTime() - t0) < timeout)91 if(behave[GREEDY])92 selectMax(w in Weeks) (card(violatedGroups[w]))93 selectMin(g1 in violatedGroups[w], g2 in Groups: g2 != g1,94 s1 in golfersInConflict[w,g1],95 s2 in group[w,g2],96 delta =97 tourn.getSwapDelta(group[w,g1], s1,98 s2, group[w,g2]):99 ((tabu[w,s1,s2] < it)

209

100 || violations + delta < best))101 (delta){102 group[w,g1].delete(s1); group[w,g2].insert(s1);103 group[w,g2].delete(s2); group[w,g1].insert(s2);104105 if(violations < best)106 improvingSteps++;107 else108 nonImprovingSteps++;109110 it++;111 }112 else113 selectMin(w in Weeks,114 g1 in violatedGroups[w], g2 in Groups: g2 != g1,115 s1 in golfersInConflict[w,g1],116 s2 in group[w,g2],117 delta =118 tourn.getSwapDelta(group[w,g1], s1,119 s2, group[w,g2]):120 ((tabu[w,s1,s2] < it)121 || violations + delta < best))122 (delta){123 group[w,g1].delete(s1); group[w,g2].insert(s1);124 group[w,g2].delete(s2); group[w,g1].insert(s2);125126 if(violations < best)127 improvingSteps++;128 else129 nonImprovingSteps++;130131 it++;132 }133134 int time = System.getCPUTime() - t0;135 setOutput(violations,time,it,nbRestarts,136 Weeks, Groups, Slots,137 problemFiles[1],138 initScheduleStr, group);

Listing 15.8: social-golfer-set-greedy.co: Attempt to improve the CBLSset approach to the Social Golfer Problem adding a greedy component to the meta-heuristics.

210

Implementation of sts-v


• steiner-triple-system.co: a CBLS integer approach to find aSteiner triple system in Listing 15.9.

• PairDifferent.co: the user-defined PairDifferent constraint in List-ing 15.10.

• steiner-triple-system-global.co: a CBLS integer approachto find a Steiner triple system using one single global constraint in List-ing 15.11.

• GlobalPairDifferent.co: the user-defined GlobalPairDifferent

constraint in Listing 15.12.

• MeetPair.co: the user-defined invariant MeetPair in Listing 15.13.

• steiner-triple-system-set.co: a CBLS set approach to find aSteiner triple system in Listing 15.14.

• steiner-triple-system-set-global.co: a CBLS set approachto find a Steiner triple system using one single global constraint in List-ing 15.15.

15.3 Integer Approach1 import cotls;2 include "st-io-functions";3 include "PairDifferent";45 Integer order(7);6 string problemFiles[0..1]; //i/o files78 getInput(order, problemFiles);9

10 Integer nbTriples(order * (order - 1) / 6);11 range Triples = 1..nbTriples;12 range Elements = 1..order;13 range Pairs = 1..6; //six pairs per triple1415 Solver<LS> m();16 var{int} triple[Triples,1..3] = new var{int}(m,Elements);

211

1718 VIPair<LS>[] pairs[Triples];19 forall(t in Triples) {20 int p = 0;21 pairs[t] = new VIPair<LS>[Pairs];22 forall(i in 1..3, j in 1..3: i != j)23 pairs[t][++p] = new VIPair<LS>(triple[t,i],24 triple[t,j]);25 }2627 ConstraintSystem<LS> cs(m);28 forall(t1 in 1..(nbTriples-1), p1 in Pairs)29 forall(t2 in (t1+1)..nbTriples, p2 in Pairs)30 cs.post(PairDifferent(pairs[t1][p1], pairs[t2][p2]));3132 var{int} conflict[t in Triples, j in 1..3]33 = cs.violations(triple[t,j]);34 var{int} violations = cs.violations();35 cs.close();36 m.close();3738 function void init(range Elements, range Triples,39 var{int}[,] triple) {40 UniformDistribution distr(Elements);41 forall(t in Triples)42 {43 int a = distr.get();44 int b;45 do b = distr.get(); while (a == b);46 int c;47 do c = distr.get(); while (c == b || c == a);48 triple[t,1] := a;49 triple[t,2] := b;50 triple[t,3] := c;51 }52 }5354 if(problemFiles[0] != null)55 initFromFile(problemFiles[0], Triples, triple);56 else57 init(Elements, Triples, triple);5859 string[] initBlockSetStr = getTriples(Triples, triple); //k06061 Integer tabu[Triples,1..3,Elements](-1);62 Integer tabuLength(12);63 Solution bestSolution[1..1](m);64 Integer minViolations(0) := violations;65 Counter it(m,0);66 Integer nbRestarts(0);67 Integer nbRestores(0);68 Counter nonImprovingSteps(m,0);

212

69 Counter improvingSteps(m,0);70 int maxNonImprovingSteps = 250;71 int restartFreq = 1000;7273 int timeout = 15 * 60 * 1000; //miliseconds74 Integer t0(0);7576 forall(t in Triples, j in 1..3)77 whenever triple[t,j]@changes(int o, int n)78 tabu[t,j,n] := it + tabuLength;7980 whenever nonImprovingSteps@changes(int oldV, int newV) {81 if(oldV == maxNonImprovingSteps) {82 bestSolution[1].restore();83 nbRestores := nbRestores + 1;84 forall(t in Triples, j in 1..3, e in Elements)85 tabu[t,j,e] := -1;86 nonImprovingSteps := 0;87 }88 }8990 whenever improvingSteps@changes() {91 minViolations := violations;92 bestSolution[1] = new Solution(m);93 nonImprovingSteps := 0;94 }9596 whenever it@changes() {97 if((it % restartFreq == 0) && (minViolations > 0)) {98 init(Elements, Triples, triple);99 nbRestarts := nbRestarts + 1;

100 minViolations := violations;101 bestSolution[1] = new Solution(m);102 forall(t in Triples, j in 1..3, e in Elements)103 tabu[t,j,e] := -1;104 nonImprovingSteps := 0;105 }106 }107108 t0 := System.getCPUTime();109 while(violations > 0 &&110 (System.getCPUTime() - t0) < timeout) {111 selectMax(t in Triples, j in 1..3)(conflict[t,j])112 selectMin(e1 in Elements:113 e1 != triple[t,(((j-1)+1) % 3)+1] &&114 e1 != triple[t,(((j-1)+2) % 3)+1],115 delta = cs.getAssignDelta(triple[t,j], e1) :116 (tabu[t,j,e1] < it ||117 violations + delta < minViolations))118 (delta) {119 triple[t,j] := e1;120

213

121 if(violations < minViolations)122 improvingSteps++;123 else124 nonImprovingSteps++;125 }126 it++;127 }128129 int time = System.getCPUTime() - t0;130 setOutput(violations,time,it,131 nbRestores,nbRestarts,132 System.getGCUsage(), System.getVMUsage(),133 order, Triples,134 problemFiles[1],135 initBlockSetStr,136 triple, pairs);

Listing 15.9: steiner-triple-system.co: CBLS integer approach to find aSteiner triple system.

1 class PairDifferent extends UserConstraint<LS> {2 Solver<LS> _m;3 VIPair<LS> _pair1;4 VIPair<LS> _pair2;56 var{int} _penalty;7 var{bool} _isSatisfied;89 bool _posted;

1011 PairDifferent(VIPair<LS> pair1, VIPair<LS> pair2)12 :UserConstraint<LS>(pair1.getFirst().getLocalSolver()) {13 _pair1 = pair1;14 _pair2 = pair2;15 _m = _pair1.getFirst().getLocalSolver();16 }1718 Solver<LS> getLocalSolver(){ return _m; }19 var{int}[] getVariables(){20 var{int} vars[0..3] = [_pair1.getFirst(),21 _pair1.getSecond(),22 _pair2.getFirst(),23 _pair2.getSecond()];24 return vars;25 }2627 var{bool} isTrue(){ return _isSatisfied; }28 var{int} violations(){ return _penalty; }29 var{int} violations(var{int} x) { return _penalty; }3031 int getAssignDelta(var{int} x, int d);32 int getSwapDelta(var{int} x, var{int} y) {

214

33 assert(false); return 0;} //not implemented3435 void post();36 }3738 void PairDifferent::post() {39 if(!_posted) {40 _penalty = new var{int}(_m) <-41 (_pair1.getFirst() == _pair2.getFirst() &&42 _pair1.getSecond() == _pair2.getSecond())? 1 : 0;43 _isSatisfied = new var{bool}(_m) <- _penalty == 0;44 _posted = true;45 }46 }4748 int PairDifferent::getAssignDelta(var{int} x, int d) {49 if(x == d)50 return 0;5152 if(_penalty == 1)53 return -1;5455 if(x === _pair1.getFirst())56 return ((d == _pair2.getFirst()) &&57 (_pair1.getSecond() == _pair2.getSecond()))?58 1 : 0;5960 if(x === _pair1.getSecond())61 return ((_pair1.getFirst() == _pair2.getFirst()) &&62 (d == _pair2.getSecond()))? 1 : 0;6364 if(x === _pair2.getFirst())65 return ((_pair1.getFirst() == d) &&66 (_pair1.getSecond() == _pair2.getSecond()))?67 1 : 0;6869 if(x === _pair2.getSecond())70 return ((_pair1.getFirst() == _pair2.getFirst()) &&71 (_pair1.getSecond() == d))? 1 : 0;7273 assert(false);74 }

Listing 15.10: PairDifferent.co: Implementation of the PairDifferentconstraint.

1 import cotls;2 include "st-io-functions";3 include "GlobalPairDifferent";45 Integer order(9);6 string problemFiles[0..1]; //i/o files

215

78 getInput(order, problemFiles);9

10 Integer nbTriples(order * (order - 1) / 6);11 range Triples = 1..nbTriples;12 range Elements = 1..order;1314 Solver<LS> m();15 var{int} triple[Triples,1..3] = new var{int}(m,Elements);1617 GlobalPairDifferent gPairDiff(m,Triples,1..3,18 Elements,triple);19 m.post(gPairDiff);2021 var{int} conflict[t in Triples, j in 1..3]22 = gPairDiff.violations(triple[t,j]);23 var{int} violations = gPairDiff.violations();24 m.close();2526 function void init(range Elements, range Triples,27 var{int}[,] triple) {28 UniformDistribution distr(Elements);29 forall(t in Triples) {30 int a = distr.get();31 int b;32 do b = distr.get(); while (a == b);33 int c;34 do c = distr.get(); while (c == b || c == a);35 triple[t,1] := a;36 triple[t,2] := b;37 triple[t,3] := c;38 }39 }4041 if(problemFiles[0] != null)42 initFromFile(problemFiles[0], Triples, triple);43 else44 init(Elements, Triples, triple);4546 string[] initBlockSetStr = getTriples(Triples, triple); //k04748 Integer tabu[Triples,1..3,Elements](-1);49 Integer tabuLength(12);50 Solution bestSolution[1..1](m);51 Integer minViolations(0) := violations;52 Counter it(m,0);53 Integer nbRestarts(0);54 Integer nbRestores(0);55 Counter nonImprovingSteps(m,0);56 Counter improvingSteps(m,0);57 int maxNonImprovingSteps = 250;58 int restartFreq = 1000;

216

5960 int timeout = 15 * 60 * 1000; //miliseconds61 Integer t0(0);6263 forall(t in Triples, j in 1..3)64 whenever triple[t,j]@changes(int o, int n)65 tabu[t,j,n] := it + tabuLength;6667 whenever nonImprovingSteps@changes(int oldV, int newV) {68 if(oldV == maxNonImprovingSteps) {69 bestSolution[1].restore();70 nbRestores := nbRestores + 1;71 forall(t in Triples, j in 1..3, e in Elements)72 tabu[t,j,e] := -1;73 nonImprovingSteps := 0;74 }75 }7677 whenever improvingSteps@changes() {78 minViolations := violations;79 bestSolution[1] = new Solution(m);80 nonImprovingSteps := 0;81 }8283 whenever it@changes() {84 if((it % restartFreq == 0) && (minViolations > 0)) {85 init(Elements, Triples, triple);86 nbRestarts := nbRestarts + 1;87 minViolations := violations;88 bestSolution[1] = new Solution(m);89 forall(t in Triples, j in 1..3, e in Elements)90 tabu[t,j,e] := -1;91 nonImprovingSteps := 0;92 }93 }9495 t0 := System.getCPUTime();96 while(violations > 0 &&97 (System.getCPUTime() - t0) < timeout) {98 selectMax(t in Triples, j in 1..3)(conflict[t,j])99 selectMin(e1 in Elements:

100 e1 != triple[t,(((j-1)+1) % 3)+1] &&101 e1 != triple[t,(((j-1)+2) % 3)+1],102 delta= gPairDiff.getAssignDelta(triple[t,j], e1)103 : (tabu[t,j,e1] < it ||104 violations + delta < minViolations))105 (delta) {106 triple[t,j] := e1;107 if(violations < minViolations)108 improvingSteps++;109 else110 nonImprovingSteps++;

217

111 }112 it++;113 }114115 int time = System.getCPUTime() - t0;116 setOutput(violations,time,it,117 nbRestores,nbRestarts,118 System.getGCUsage(), System.getVMUsage(),119 order, Triples,120 problemFiles[1],121 initBlockSetStr,122 triple, null);

Listing 15.11: steiner-triple-system-global.co: CBLS integerapproach to find a Steiner triple system using one single global constraint.

1 include "MeetPair";23 tuple Position {int group; int slot;}45 class GlobalPairDifferent extends UserConstraint<LS> {6 Solver<LS> m;7 range Groups;8 range Slots;9 range Elements;

1011 var{int}[,] group;12 var{int}[,] meetings;13 dict{var{int}->Position} position;14 var{int}[,] conflict;15 var{int} penalty;1617 GlobalPairDifferent(Solver<LS> _m,18 range _Groups, range _Slots,19 range _Elements, var{int}[,] _group)20 : UserConstraint<LS>(_m) {21 m = _m;22 Groups = _Groups;23 Slots = _Slots;24 Elements = _Elements;25 group = _group;26 }2728 void post();29 var{int} violations(var{int} x);30 var{int} violations() { return penalty; }31 int getSwapDelta(var{int} x,var{int} y);32 int getAssignDelta(var{int} x, int v);33 }3435 void GlobalPairDifferent::post() {36 MeetPair meetInvariant(m,Groups,Slots,Elements,group);

218

37 m.post(meetInvariant);38 meetings = meetInvariant.getMeetings();39 position = meetInvariant.getPosition();4041 conflict = new var{int}[g in Groups, s in Slots](m) <-42 sum(t in Slots : t != s)43 (meetings[group[g,s],group[g,t]] >= 2);44 penalty = new var{int}(m) <-45 sum(g in Elements, h in Elements: g < h)46 max(0,meetings[g,h]-1);47 }4849 var{int} GlobalPairDifferent::violations(var{int} x) {50 Position p = position{x};51 return conflict[p.group,p.slot];52 }5354 int GlobalPairDifferent::getSwapDelta(var{int} x,55 var{int} y) {56 Position xp = position{x};57 Position yp = position{y};58 assert(xp.group != yp.group);5960 int delta = 0;61 forall (s in Slots : s != yp.slot)62 delta += (meetings[x,group[yp.group,s]] >= 1)63 - (meetings[y,group[yp.group,s]] >= 2);64 forall (s in Slots : s != xp.slot)65 delta += (meetings[y,group[xp.group,s]] >= 1)66 - (meetings[x,group[xp.group,s]] >= 2);67 return delta;68 }6970 int GlobalPairDifferent::getAssignDelta(var{int} x, int v){71 Position xp = position{x};7273 int delta = 0;74 forall (s in Slots : s != xp.slot)75 delta += (meetings[v,group[xp.group,s]] >= 1)76 - (meetings[x,group[xp.group,s]] >= 2);77 return delta;78 }

Listing 15.12: GlobalPairDifferent.co: Implementation of theGlobalPairDifferent constraint.

1 class MeetPair implements Invariant<LS> {2 Solver<LS> m;3 range Groups;4 range Slots;5 range Elements;6 var{int}[,] group;

219

7 var{int}[,] meetings;8 dict{var{int}->Position} position;9

10 Solver<LS> getLocalSolver() { return m; }11 var{int}[,] getMeetings(){ return meetings; }12 dict{var{int}->Position} getPosition(){ return position; }1314 MeetPair(Solver<LS> _m, range _Groups, range _Slots,15 range _Elements, var{int}[,] _group) {16 m = _m;17 Groups = _Groups;18 Slots = _Slots;19 Elements = _Elements;20 group = _group;21 meetings = new var{int}[Elements,Elements](m) := 0;22 position = new dict{var{int}->Position}();23 forall (g in Groups, s in Slots)24 position{group[g,s]} = new Position(g,s);25 }2627 void post(InvariantPlanner<LS> planner);28 void initPropagation();29 void propagateInt(bool b,var{int} v);3031 //not implemented, included to avoid a compiler error32 void propagateFloat(bool b,var{float} v){ assert(false); }33 void propagateInsertIntSet(bool b,var{set{int}} s,34 int value) { assert(false); }35 void propagateRemoveIntSet(bool b,var{set{int}} s,36 int value) { assert(false); }37 }3839 void MeetPair::post(InvariantPlanner<LS> planner) {40 forall (g in Groups, s in Slots)41 planner.addSource(group[g,s]);42 forall (p in Elements, q in Elements)43 planner.addTarget(meetings[p,q]);44 }4546 void MeetPair::initPropagation() {47 forall (g in Groups)48 forall (s in Slots, t in Slots : s < t) {49 meetings[group[g,s],group[g,t]]++;50 meetings[group[g,t],group[g,s]]++;51 }52 }5354 void MeetPair::propagateInt(bool b,var{int} v) {55 Position p = position{v};56 int oldElement = v.getOld();57 int newElement = v;58 forall (s in Slots : s != p.slot) {

220

59 int o = group[p.group,s];60 meetings[oldElement,o]--;61 meetings[o,oldElement]--;62 meetings[newElement,o]++;63 meetings[o,newElement]++;64 }65 }

Listing 15.13: MeetPair.co: User-defined invariant MeetPair.

15.4 Set Approach

1 import cotls;2 include "st-set-io-functions";3 include "SetConstraintSystem_LS_";4 include "PairAtMost1_LS_";56 Integer order(7);7 string problemFiles[0..1];89 getInput(order, problemFiles);

1011 Integer nbTriples(order * (order - 1) / 6);12 range Triples = 1..nbTriples;13 range Elements = 1..order;1415 Solver<LS> m();16 var{set{int}} triple[Triples] = new var{set{int}}(m);1718 SetConstraintSystem<LS> cs(m);19 forall(i in Triples, j in Triples: i < j)20 cs.post(PairAtMost1<LS>(triple[i], triple[j]));21 cs.close();22 m.close();2324 function void init(range Elements, range Triples,25 var{set{int}}[] triple) {26 UniformDistribution distr(Elements);27 forall(t in Triples) {28 set{int} tri = triple[t];29 forall(e in tri.copy())30 triple[t].delete(e);31 }32 forall(t in Triples)33 do{34 int v = distr.get();35 if(!member(v,triple[t])) triple[t].insert(v);36 }while(card(triple[t])!=3);37 }3839 if(problemFiles[0] != null)40 initFromFile(problemFiles[0], Triples, triple, null);

221

41 else42 init(Elements, Triples, triple);4344 var{int} violations = cs.violations();45 var{int} conflict[t in Triples] = cs.violations(triple[t]);4647 string[] initBlockSetStr = getTriples(Triples, triple); //k04849 Integer tabu[Triples,Elements,Elements](-1);50 Integer tabuLength(12);51 set{int} bestSolution[Triples] = new set{int}();52 Integer minViolations(0) := violations;53 Counter it(m,0);54 Integer nbRestarts(0);55 Integer nbRestores(0);56 Counter nonImprovingSteps(m,0);57 Counter improvingSteps(m,0);58 int maxNonImprovingSteps = 10000;59 int restartFreq = 100000;6061 int timeout = 15 * 60 * 1000; //miliseconds62 Integer t0(0);6364 forall(t in Triples)65 whenever triple[t]@remove(int s1)66 when triple[t]@insert(int s2)67 tabu[t,s1,s2] := it + tabuLength;6869 whenever nonImprovingSteps@changes(int oldV, int newV) {70 if(oldV == maxNonImprovingSteps) {71 restore(Triples,bestSolution,triple);72 nbRestores := nbRestores + 1;73 forall(t in Triples, e1 in Elements, e2 in Elements)74 tabu[t,e1,e2] := -1;75 nonImprovingSteps := 0;76 }77 }7879 whenever improvingSteps@changes() {80 minViolations := violations;81 forall(t in Triples) {82 bestSolution[t].reset();83 forall(e in triple[t])84 bestSolution[t].insert(e);85 }86 nonImprovingSteps := 0;87 }8889 whenever it@changes() {90 if((it % restartFreq == 0) && (minViolations > 0)) {91 init(Elements, Triples, triple);92 nbRestarts := nbRestarts + 1;

222

93 minViolations := violations;94 forall(t in Triples) {95 bestSolution[t].reset();96 forall(e in triple[t])97 bestSolution[t].insert(e);98 }99 forall(t in Triples, e1 in Elements, e2 in Elements)

100 tabu[t,e1,e2] := -1;101 nonImprovingSteps := 0;102 }103 }104105 t0 := System.getCPUTime();106 while(violations > 0 &&107 (System.getCPUTime() - t0) < timeout) {108 selectMax(t in Triples)(conflict[t])109 selectMin(e1 in Elements: !member(e1,triple[t]),110 e2 in triple[t],111 delta = cs.getFlipDelta(triple[t], e2, e1) :112 tabu[t,e2,e1] < it ||113 violations + delta < minViolations)114 (delta) {115 triple[t].delete(e2); //flip elements116 triple[t].insert(e1);117118 if(violations < minViolations)119 improvingSteps++;120 else121 nonImprovingSteps++;122 }123 it++;124 }125126 int time = System.getCPUTime() - t0;127128 setOutput(violations,time,it,129 nbRestores,nbRestarts,130 System.getGCUsage(), System.getVMUsage(),131 order, Triples,132 problemFiles[1],133 initBlockSetStr,134 triple,null);135136 function void restore(range Triples, set{int}[] best,137 var{set{int}}[] triple) {138 forall(t in Triples) {139 set{int} tri = triple[t];140 forall(e in tri.copy())141 triple[t].delete(e);142 forall(e in best[t])143 triple[t].insert(e);144 }

223

145 }

Listing 15.14: steiner-triple-system-set.co: CBLS set approach to finda Steiner triple system.

1 import cotls;2 include "st-set-io-functions";3 include "GlobalAtMost1_LS_";45 Integer order(9);6 string problemFiles[0..1];78 getInput(order, problemFiles);9

10 Integer nbTriples(order * (order - 1) / 6);11 range Triples = 1..nbTriples;12 range Elements = 1..order;1314 Solver<LS> m();15 var{set{int}} triple[1..1,Triples] = new var{set{int}}(m);

1617 GlobalAtMost1<LS> gAtMost1(m,1..1,Triples,1..3,Elements,

triple);18 m.close();1920 function void init(range Elements, range Triples,21 var{set{int}}[,] triple) {22 UniformDistribution distr(Elements);23 forall(t in Triples) {24 set{int} tri = triple[1,t];25 forall(e in tri.copy())26 triple[1,t].delete(e);27 }28 forall(t in Triples)29 do{30 int v = distr.get();31 if(!member(v,triple[1,t])) triple[1,t].insert(v);32 }while(card(triple[1,t])!=3);33 }3435 if(problemFiles[0] != null)36 initFromFile(problemFiles[0], Triples, null,triple);37 else38 init(Elements, Triples, triple);3940 var{int} violations = gAtMost1.violations();41 var{int} conflict[t in Triples] =42 gAtMost1.violations(triple[1,t]);4344 string[] initBlockSetStr = getTriples(Triples, triple); //k045

224

46 Integer tabu[Triples,Elements,Elements](-1);47 Integer tabuLength(12);48 set{int} bestSolution[Triples] = new set{int}();49 Integer minViolations(0) := violations;50 Counter it(m,0);51 Integer nbRestarts(0);52 Integer nbRestores(0);53 Counter nonImprovingSteps(m,0);54 Counter improvingSteps(m,0);55 int maxNonImprovingSteps = 10000;56 int restartFreq = 100000;5758 int timeout = 15 * 60 * 1000; //miliseconds59 Integer t0(0);6061 forall(t in Triples)62 whenever triple[1,t]@remove(int s1)63 when triple[1,t]@insert(int s2)64 tabu[t,s1,s2] := it + tabuLength;6566 whenever nonImprovingSteps@changes(int oldV, int newV) {67 if(oldV == maxNonImprovingSteps) {68 restore(Triples,bestSolution,triple);69 nbRestores := nbRestores + 1;70 forall(t in Triples, e1 in Elements, e2 in Elements)71 tabu[t,e1,e2] := -1;72 nonImprovingSteps := 0;73 }74 }7576 whenever improvingSteps@changes() {77 minViolations := violations;78 forall(t in Triples) {79 bestSolution[t].reset();80 forall(e in triple[1,t])81 bestSolution[t].insert(e);82 }83 nonImprovingSteps := 0;84 }8586 whenever it@changes() {87 if((it % restartFreq == 0) && (minViolations > 0)) {88 init(Elements, Triples, triple);89 nbRestarts := nbRestarts + 1;90 minViolations := violations;91 forall(t in Triples) {92 bestSolution[t].reset();93 forall(e in triple[1,t])94 bestSolution[t].insert(e);95 }96 forall(t in Triples, e1 in Elements, e2 in Elements)97 tabu[t,e1,e2] := -1;

225

98 nonImprovingSteps := 0;99 }

100 }101102 t0 := System.getCPUTime();103 while(violations > 0 &&104 (System.getCPUTime() - t0) < timeout) {105 selectMax(t in Triples)(conflict[t])106 selectMin(e1 in Elements: !member(e1,triple[1,t]),107 e2 in triple[1,t],108 delta = gAtMost1.getFlipDelta(triple[1,t],109 e2, e1) :110 tabu[t,e2,e1] < it ||111 violations + delta < minViolations)112 (delta) {113 triple[1,t].delete(e2); //flip elements114 triple[1,t].insert(e1);115116 if(violations < minViolations)117 improvingSteps++;118 else119 nonImprovingSteps++;120 }121 it++;122 }123124 int time = System.getCPUTime() - t0;125126 setOutput(violations,time,it,127 nbRestores,nbRestarts,128 System.getGCUsage(), System.getVMUsage(),129 order, Triples,130 problemFiles[1],131 initBlockSetStr,132 null,triple);133134 function void restore(range Triples, set{int}[] best,135 var{set{int}}[,] triple) {136 forall(t in Triples) {137 set{int} tri = triple[1,t];138 forall(e in tri.copy())139 triple[1,t].delete(e);140 forall(e in best[t])141 triple[1,t].insert(e);142 }143 }

Listing 15.15: steiner-triple-system-set-global.co: CBLS setapproach to find a Steiner triple system using one single global constraint.

226

Implementation of schur-k-n


• schur.co: a CBLS integer approach to Schur’s lemma in Listing 15.16.

• schur-set.co: a CBLS set approach to Schur’s lemma in Listing 15.17.

• SetSumFree_LS_.co: the user-defined SetSumFree<LS> constraint inListing 15.18.

• SetSumSet.co: the user-defined SetSumSet invariant in Listing 15.19.

15.5 Integer Approach

1 import cotls;2 include "schur-io-functions";34 Integer n(25);5 Integer k(4);6 string problemFiles[0..1]; //i/o files78 getInput(n,k,problemFiles);9

10 range N = 1..n;11 range K = 1..k;1213 Solver<LS> m();14 var{int} subset[N](m,K);15 ConstraintSystem<LS> S(m);16 forall(k in K, i in N, j in N: i <= j && i + j <= n)17 S.post((subset[i] == k && subset[j] == k)18 => subset[i+j] != k);19 m.close();2021 if(problemFiles[0] != null)22 initFromFile(problemFiles[0], N, K, subset);23 else24 init(N,K,subset);2526 string[] initPartsStr = getParts(N,K,subset);2728 var{int} violations = S.violations();29 var{int} conflict[i in N] = S.violations(subset[i]);

227

3031 bool tabu[N] = false;32 Integer tabuLength(5);33 Solution bestSolution[1..1](m);34 Integer minViolations(0) := violations;35 Counter it(m,0);36 Integer nbRestarts(0);37 Integer nbRestores(0);38 Counter nonImprovingSteps(m,0);39 Counter improvingSteps(m,0);40 int maxNonImprovingSteps = 100;41 int restartFreq = 1000;4243 int timeout = 1 * 60 * 1000; //miliseconds44 Integer t0(0);4546 forall(i in N)47 whenever subset[i]@changes() {48 tabu[i] = true;49 when it@reaches[it + tabuLength]()50 tabu[i] = false;51 }5253 whenever improvingSteps@changes() {54 minViolations := violations;55 bestSolution[1] = new Solution(m);56 nonImprovingSteps := 0;57 }5859 whenever nonImprovingSteps@changes(int oldV, int newV)60 if(oldV == maxNonImprovingSteps) {61 bestSolution[1].restore();62 nbRestores := nbRestores + 1;63 forall(i in N)64 tabu[i] = false;65 nonImprovingSteps := 0;66 }6768 whenever it@changes()69 if((it % restartFreq == 0) && (minViolations > 0)) {70 with delay(m)71 init(N,K,subset);72 nbRestarts := nbRestarts + 1;73 minViolations := S.violations();74 bestSolution[1] = new Solution(m);75 forall(i in N)76 tabu[i] = false;77 nonImprovingSteps := 0;78 }7980 t0 := System.getCPUTime();81 while(violations > 0 &&

228

82 (System.getCPUTime() - t0) < timeout) {83 selectMax(i in N: !tabu[i]) (conflict[i])84 selectMin(k in K,85 delta = S.getAssignDelta(subset[i],k))86 (delta) {87 subset[i] := k;8889 if(violations < minViolations)90 improvingSteps++;91 else92 nonImprovingSteps++;9394 it++;95 }96 }9798 int time = System.getCPUTime() - t0;99 setOutput(violations, time, it,

100 nbRestores, nbRestarts,101 System.getGCUsage(), System.getVMUsage(),102 n, k,103 problemFiles[1],104 initPartsStr,105 subset);106107 function void init(range N, range K, var{int}[] subset) {108 UniformDistribution distr(K);109 forall (i in N)110 subset[i] := distr.get();111 }

Listing 15.16: schur.co: CBLS integer approach to Schur’s lemma.

15.6 Set Approach

1 import cotls;2 include "schur-set-io-functions";3 include "SetConstraintSystem_LS_";4 include "SetSumFree_LS_";56 Integer n(25);7 Integer k(4);8 string problemFiles[0..1]; //i/o files9

10 getInput(n,k,problemFiles);1112 range N = 1..n;13 range K = 1..k;1415 Solver<LS> m();16 var{set{int}}[] subset = all(i in K) (new var{set{int}}(m));17

229

18 if(problemFiles[0] != null)19 initFromFile(problemFiles[0], N, K, subset);20 else21 init(N,K,subset);2223 SetConstraintSystem<LS> cs(m);24 forall(i in K)25 cs.post(SetSumFree<LS>(subset[i],n));26 cs.close();27 m.close();2829 string[] initPartsStr = getParts(K,subset);30 var{int} violations = cs.violations();31 var{int} conflict[i in K] = cs.violations(subset[i]);3233 Integer tabu[N](0);34 int tabuLength = 5;35 set{int}[] bestSolution = all(i in K) (new set{int}());36 saveSolution(bestSolution, K, subset);37 Integer minViolations(0) := violations;38 Counter it(m,0);39 Integer nbRestarts(0);40 Integer nbRestores(0);41 Counter nonImprovingSteps(m,0);42 Counter improvingSteps(m,0);43 int maxNonImprovingSteps = 1200;44 int restartFreq = 12000;4546 int timeout = 1 * 60 * 1000; //miliseconds47 Integer t0(0);4849 whenever improvingSteps@changes() {50 minViolations := violations;51 nonImprovingSteps := 0;52 }5354 whenever nonImprovingSteps@changes(int oldV, int newV)55 if(oldV == maxNonImprovingSteps) {56 restore(K, bestSolution, subset);57 nbRestores := nbRestores + 1;58 forall(i in N)59 tabu[i] := 0;60 nonImprovingSteps := 0;61 }6263 whenever it@changes()64 if((it % restartFreq == 0) && (minViolations > 0)) {65 init(N,K,subset);66 nbRestarts := nbRestarts + 1;67 minViolations := violations;68 saveSolution(bestSolution, K, subset);69 forall(i in N)

230

70 tabu[i] := 0;71 nonImprovingSteps := 0;72 }7374 t0 := System.getCPUTime();75 while(violations > 0 &&76 (System.getCPUTime() - t0) < timeout) {77 selectMax[2](k in K) (conflict[k])78 selectMin(j in K: (j != k),79 n in N: member(n, subset[k]),80 delta = cs.getTransferDelta(subset[k],n,81 subset[j]) :82 delta + violations < minViolations83 || (tabu[n] == 0))84 (delta) {85 //transfer86 subset[k].delete(n);87 subset[j].insert(n);8889 tabu[n] := 1;90 when it@reaches[it + tabuLength]()91 tabu[n] := 0;9293 if(violations < minViolations)94 improvingSteps++;95 else96 nonImprovingSteps++;97 }98 it++;99 }

100101 int time = System.getCPUTime() - t0;102 setOutput(violations, time, it, nbRestores, nbRestarts,103 System.getGCUsage(), System.getVMUsage(),104 n, k, problemFiles[1], initPartsStr, subset);105106 function void init(range N, range K,107 var{set{int}}[] subset){108 UniformDistribution distrK(K);109 forall(i in N)110 subset[distrK.get()].insert(i);111 }112113 function void restore(range K, set{int}[] best,114 var{set{int}}[] subset) {115 forall(k in K) {116 set{int} sSet = subset[k];117 forall(e in sSet.copy())118 subset[k].delete(e);119 forall(e in best[k])120 subset[k].insert(e);121 }

231

122 }123124 function void saveSolution(set{int}[] best, range K,125 var{set{int}}[] sol) {126 forall(i in K) {127 set{int} pi_ = sol[i];128 best[i] = pi_.copy();129 }130 }

Listing 15.17: schur-set.co: CBLS set approach to the Schur’s lemma.

1 include "UserSetConstraint_LS_";2 include "SetSumSet";34 class SetSumFree<LS> extends UserSetConstraint<LS> {5 var{set{int}} _s;6 int _n;78 var{int} _penalty;9 var{int} _conflict;

1011 SetSumSet _setSumSetInv;12 int[] _addDelta;13 int[] _dropDelta;1415 SetSumFree<LS>(var{set{int}} s, int n)16 : UserSetConstraint<LS>(s.getLocalSolver()) {17 _s = s;18 _n = n;19 post();20 }2122 var{set{int}}[] getSetVariables() {23 return all(i in 1..1) _s; }2425 var{int} violations() { return _penalty; }2627 var{int} violations(var{set{int}} s) {28 return s === _s? _penalty : _zero;29 }3031 int getAddDelta(var{set{int}} s, int v) {32 return _addDelta[v]; }3334 int getDropDelta(var{set{int}} s, int u) {35 return _dropDelta[u]; }36 }3738 void SetSumFree<LS>::post() {39 if(!_posted) {40 _setSumSetInv = new SetSumSet(_ls, _s, _n);

232

41 _ls.post(_setSumSetInv);42 _addDelta = _setSumSetInv.getAddDelta();43 _dropDelta = _setSumSetInv.getDropDelta();44 _penalty = _setSumSetInv.getCardSumSet();45 _isSatisfied = new var{bool}(_ls) <- _penalty == 0;46 _posted = true;47 }48 }4950 int SetSumFree<LS>::getTransferDelta(var{set{int}} s, int u,51 var{set{int}} t) {52 if(s === _s)53 return getDropDelta(s, u);54 //else55 if(t === _s)56 return getAddDelta(t, u);57 //else58 return 0;59 }

Listing 15.18: SetSumFree_LS_.co: Implementation of the sum − free set-constraint.

1 class SetSumSet implements Invariant<LS> {2 Solver<LS> _ls;3 var{set{int}} _set;4 int _n;5 range _N;67 set{int} _conflictSet;8 set{int} _forbiddenSet;9 int _card;

10 var{int} _cardConflictSet;1112 int[] _addDelta;13 int[] _dropDelta;1415 SetSumSet(Solver<LS> ls, var{set{int}} s, int n) {16 _ls = ls;17 _set = s;18 _n = n;19 _N = 1.._n;2021 _conflictSet = new set{int}();22 _forbiddenSet = new set{int}();23 _card = 0;24 _cardConflictSet = new var{int}(_ls);2526 _addDelta = new int[_N] = 0;27 _dropDelta = new int[_N] = 0;28 }29

233

30 Solver<LS> getLocalSolver() { return _ls; }31 set{int} getSumSet() { return _conflictSet; }32 var{int} getCardSumSet() { return _cardConflictSet; }3334 int[] getAddDelta() { return _addDelta; }35 int[] getDropDelta() { return _dropDelta; }3637 void post(InvariantPlanner<LS> p);38 void initPropagation();39 void propagateInsertIntSet(boolean b, var{set{int}} s,40 int value);41 void propagateRemoveIntSet(boolean b, var{set{int}} s,42 int value);4344 //not implemented, included to avoid a compiler error45 void propagateInt(bool b, var{int} v) { assert(false); }46 void propagateFloat(bool b, var{float} v){ assert(false);}47 }4849 void SetSumSet::post(InvariantPlanner<LS> p) {50 p.addSource(_set);51 p.addTarget(_cardConflictSet);52 }5354 void SetSumSet::initPropagation() {5556 forall(a in _set, b in _set: a < b && member(a+b, _set)) {57 _conflictSet.insert(a+b);58 _card += 1;59 _dropDelta[a] -= 1;60 _dropDelta[b] -= 1;61 _dropDelta[a+b] -= 1;62 }6364 forall(a in _set : member(a+a, _set)) {65 _conflictSet.insert(a+a);66 _card += 1;67 _dropDelta[a] -= 1;68 _dropDelta[a+a] -= 1;69 }7071 _cardConflictSet := _card;7273 forall(a in _N, b in _set : !member(a, _set) &&74 member(a+b,_set)) {75 _forbiddenSet.insert(a);76 _addDelta[a] += 1;77 }7879 forall(a in _N: !member(a, _set) && member(a+a,_set)) {80 _forbiddenSet.insert(a);81 _addDelta[a] += 1;

234

82 }8384 forall(a in _set, b in _set : a < b && a+b <= _n &&85 !member(a+b, _set)) {86 _forbiddenSet.insert(a+b);87 _addDelta[a+b] += 1;88 }8990 forall(a in _set: a+a <= _n && !member(a+a, _set)) {91 _forbiddenSet.insert(a+a);92 _addDelta[a+a] += 1;93 }94 }9596 void SetSumSet::propagateInsertIntSet(boolean l,97 var{set{int}} s,98 int a){99

100 forall(b in s \ {a} : member(a+b,s)) {101 _conflictSet.insert(a+b);102 _card += 1;103 _dropDelta[a] -= 1;104 _dropDelta[b] -= 1;105 _dropDelta[a+b] -= 1;106 }107108 if(member(a+a,s)) {109 _conflictSet.insert(a+a);110 _card += 1;111 _dropDelta[a] -= 1;112 _dropDelta[a+a] -= 1;113 }114115 forall(b in s, c in s: b < c && b + c == a) {116 _conflictSet.insert(a);117 _card += 1;118 _dropDelta[a] -= 1;119 _dropDelta[b] -= 1;120 _dropDelta[c] -= 1;121 }122123 if(a % 2 == 0 && member(a/2,s)) {124 _conflictSet.insert(a);125 _card += 1;126 _dropDelta[a] -= 1;127 _dropDelta[a/2] -= 1;128 }129130 _cardConflictSet := _card;131132 forall(c in _N : !member(c,s) &&133 member(a + c, s)) {

235

134 _forbiddenSet.insert(c);135 _addDelta[c] += 1;136 }137138 forall(c in _N, b in s : !member(c,s) &&139 c + b == a) {140 _forbiddenSet.insert(c);141 _addDelta[c] += 1;142 }143144 if(a % 2 == 0 && !member(a/2,s)) {145 _forbiddenSet.insert(a/2);146 _addDelta[a/2] += 1;147 }148149 forall(b in s : a+b <=_n && !member(a+b,s)) {150 _forbiddenSet.insert(a+b);151 _addDelta[a+b] += 1;152 }153154 forall(b in s: b != a && member(a+b,s)) {155 _forbiddenSet.insert(a);156 _addDelta[a] -= 1;157 }158159 if(member(a+a,s)) {160 _forbiddenSet.del(a);161 _addDelta[a] -= 1;162 }163164 forall(b in _set, c in _set : b < c && b+c ==a) {165 _forbiddenSet.del(a);166 _addDelta[a] -= 1;167 }168169 if(a%2==0 && member(a/2,s)) {170 _forbiddenSet.del(a);171 _addDelta[a] -= 1;172 }173 }174175 void SetSumSet::propagateRemoveIntSet(boolean l,176 var{set{int}} s,177 int b) {178179 forall(a in s : member(a+b,s)) {180 _conflictSet.del(a+b);181 _card -= 1;182 _dropDelta[a] += 1;183 _dropDelta[b] += 1;184 _dropDelta[a+b] += 1;185 }

236

186187 if(member(b+b,s)) {188 _conflictSet.del(b+b);189 _card -= 1;190 _dropDelta[b] += 1;191 _dropDelta[b+b] += 1;192 }193194 forall(a in s, c in s : a < c && a + c == b) {195 _conflictSet.del(b);196 _card -= 1;197 _dropDelta[a] += 1;198 _dropDelta[c] += 1;199 _dropDelta[b] += 1;200 }201202 if(b % 2 == 0 && member(b/2,s)) {203 _conflictSet.del(b);204 _card -= 1;205 _dropDelta[b/2] += 1;206 _dropDelta[b] += 1;207 }208209 _cardConflictSet := _card;210211 forall(c in _N : c !=b && !member(c,s) &&212 member(b + c, s)) {213 _forbiddenSet.del(c);214 _addDelta[c] -= 1;215 }216217 forall(c in _N, a in s : !member(c,s) &&218 c + a == b) {219 _forbiddenSet.del(c);220 _addDelta[c] -= 1;221 }222223 if(b % 2 == 0 && !member(b/2,s)) {224 _forbiddenSet.del(b/2);225 _addDelta[b/2] -= 1;226 }227228 forall(a in s : a+b <=_n && !member(a+b,s)) {229 _forbiddenSet.del(a+b);230 _addDelta[a+b] -= 1;231 }232233 if(b+b <= _n && !member(b+b,s)) {234 _forbiddenSet.del(b+b);235 _addDelta[b+b] -= 1;236 }237

237

238 forall(a in s: member(b+a,s)) {239 _forbiddenSet.insert(b);240 _addDelta[b] += 1;241 }242243 if(member(b+b,s)) {244 _forbiddenSet.insert(b);245 _addDelta[b] += 1;246 }247248 forall(a in _set, c in _set : a < c && a+c ==b) {249 _forbiddenSet.insert(b);250 _addDelta[b] += 1;251 }252253 if(b%2==0 && member(b/2,s)) {254 _forbiddenSet.insert(b);255 _addDelta[b] += 1;256 }257 }

Listing 15.19: SetSumSet.co: User-defined SetSumSet invariant.

238

Implementation of the Scene AllocationProblem


• UserSetObjectiveFunction_LS_.co: theUserSetObjectiveFunction<LS> abstract class is in Listing 15.20.

• scene-allocation.co: a CBLS integer approach to the Scene Allo-cation problem in Listing 15.21.

• scene-allocation-set.co: a CBLS set approach to the Scene Al-location problem in Listing 15.22.

• SceneAllocationObjective_LS_.co: the user-defined set objec-tive function SceneAllocationObjective<LS> in Listing 15.23.

• ActorsSet.co: the user-defined ActorsSet invariant in Listing 15.24.

15.7 Set Objective Functions for Comet’s CBLS Back-End

1 include "SetObjectiveFunction_LS_";23 abstract class UserSetObjectiveFunction<LS>4 implements SetObjectiveFunction<LS> {56 Solver<LS> _ls;7 var{int} _zero;8 var{set{int}}[] _empty;9 bool _posted;

1011 UserSetObjectiveFunction<LS>(Solver<LS> ls) {12 _ls = ls;13 _zero = new var{int}(_ls) := 0;14 _empty = new var{set{int}}[1..0];15 _posted = false;16 }1718 Solver<LS> getLocalSolver() {19 return _ls; }20 var{set{int}}[] getSetVariables() {21 return _empty; }22

239

23 var{int} evaluation() {24 return _zero; }25 var{int} increase(var{set{int}} s) {26 return _zero; }27 var{int} decrease(var{set{int}} s) {28 return _zero; }2930 int getAddDelta(var{set{int}} s, int v) {31 return 0; }32 int getDropDelta(var{set{int}} s, int u) {33 return 0; }34 int getFlipDelta(var{set{int}} s, int u, int v) {35 return 0; }36 int getTransferDelta(var{set{int}} s, int u,37 var{set{int}} t) {38 return 0; }39 int getSwapDelta(var{set{int}} s, int u, int v,40 var{set{int}} t) {41 return 0; }4243 void post() {}44 }

Listing 15.20:UserSetObjectiveFunction_LS_.co: UserSetObjectiveFunction<LS

> class implementing the SetObjectiveFunction<LS> interface defined inListing 10.2.

15.8 Integer Approach1 import cotls;2 include "scene-alloc-io-functions";34 string problemFiles[0..1]; //i/o files5 getInput(problemFiles);67 int maxScene = 19;8 int maxDay = 5;9

10 range Scenes = 0..(maxScene-1);11 range Days = 0..(maxDay-1);1213 enum Actor = {DE_NIRO, KIDMAN, CRUISE, THURMAN, LIU, PACINO,14 STORMARE, JOHANSSON, COLE, WILLIAMS, BOGART };1516 int pay[Actor] = [26481, 25043, 30310, 4085, 7562, 9381,17 8770, 5788, 7423, 3303, 9593];1819 set{Actor} appears[Scenes];2021 appears[0] = {PACINO};22 appears[1] = {DE_NIRO, PACINO, LIU, THURMAN};

240

23 appears[2] = {JOHANSSON, CRUISE, COLE, LIU};24 appears[3] = {KIDMAN, COLE};25 appears[4] = {COLE, STORMARE, DE_NIRO, JOHANSSON, WILLIAMS};26 appears[5] ={BOGART, JOHANSSON, STORMARE, CRUISE, WILLIAMS};27 appears[6] = {KIDMAN, DE_NIRO};28 appears[7] = {COLE, THURMAN};29 appears[8] = {KIDMAN, JOHANSSON, COLE, CRUISE, BOGART};30 appears[9] = {KIDMAN, JOHANSSON, CRUISE, DE_NIRO};31 appears[10] = {DE_NIRO};32 appears[11] = {PACINO, BOGART, JOHANSSON, THURMAN, LIU};33 appears[12] = {PACINO, THURMAN, KIDMAN, DE_NIRO};34 appears[13] = {STORMARE, CRUISE};35 appears[14] = {BOGART, THURMAN, JOHANSSON, DE_NIRO};36 appears[15] = {CRUISE, JOHANSSON, KIDMAN, COLE};37 appears[16] = {CRUISE, DE_NIRO, LIU};38 appears[17] = {CRUISE, JOHANSSON, PACINO, BOGART};39 appears[18] = {KIDMAN};4041 set{int} which[a in Actor] = setof(s in Scenes)42 member(a,appears[s]);4344 Solver<LS> m();45 var{int} scene[Scenes](m,Days);46 RandomPermutation perm(Scenes);47 forall(i in Scenes) scene[perm.get()] := i/maxDay;4849 FunctionSum<LS> O(m);50 forall(a in Actor, d in Days)51 O.post(pay[a]*(or(s in which[a]) scene[s] == d));52 m.close();5354 string[] initAllocation = getScenes(Scenes, Days, scene);5556 int tabu[Scenes, Scenes] = -1;57 int tabuLength = 100;5859 int best = O.evaluation();60 int nonImprovingSteps = 0;61 int maxNonImprovingSteps = 15000;6263 int it = 0;64 int nbRestarts = 0;6566 //int timeout = 5 * 60 * 1000; //miliseconds67 int t0 = System.getCPUTime();6869 while (O.evaluation() != 334144) {70 selectMin(s1 in Scenes, s2 in Scenes: s1 != s2,71 delta = O.getSwapDelta(scene[s1], scene[s2]) :72 delta !=0 && (tabu[s1,s2] <= it ||73 O.evaluation() + delta < best))74 (delta) {

241

75 scene[s1] :=: scene[s2];76 tabu[s1,s2] = it + tabuLength;7778 if(O.evaluation() < best) {79 best = O.evaluation();80 nonImprovingSteps = 0;81 }82 else {83 nonImprovingSteps++;84 if(nonImprovingSteps > maxNonImprovingSteps) {85 RandomPermutation p(Scenes);86 forall(i in Scenes) scene[p.get()] := i/maxDay;87 best = O.evaluation();88 nonImprovingSteps = 0;89 forall(s1 in Scenes, s2 in Scenes)90 tabu[s1,s2] = -1;91 nbRestarts += 1;92 }93 }94 it++;95 }96 }9798 int time = System.getCPUTime() - t0;99 setOutput(O.evaluation(), time, it, nbRestarts,

100 System.getGCUsage(), System.getVMUsage(), Scenes,101 Days, problemFiles[1], initAllocation, scene);

Listing 15.21: scene-allocation.co: CBLS integer approach to SceneAllocation problem.

15.9 Set Approach

1 import cotls;2 include "scene-alloc-set-io-functions";3 include "SceneAllocationObjective_LS_";45 string problemFiles[0..1]; //i/o files6 getInput(problemFiles);78 int maxScene = 19;9 int maxDay = 5;

1011 range Scenes = 0..(maxScene-1);12 range Days = 0..(maxDay-1);1314 range Actor = 1..11;1516 int pay[Actor] = [26481, 25043, 30310, 4085, 7562, 9381,17 8770, 5788, 7423, 3303, 9593];1819 set{int} appears[Scenes];

242

2021 appears[0] = {6};22 appears[1] = {1, 6, 5, 4};23 appears[2] = {8, 3, 9, 5};24 appears[3] = {2, 9};25 appears[4] = {9, 7, 1, 8, 10};26 appears[5] = {11, 8, 7, 3, 10};27 appears[6] = {2, 1};28 appears[7] = {9, 4};29 appears[8] = {2, 8, 9, 3, 11};30 appears[9] = {2, 8, 3, 1};31 appears[10] = {1};32 appears[11] = {6, 11, 8, 4, 5};33 appears[12] = {6, 4, 2, 1};34 appears[13] = {7, 3};35 appears[14] = {11, 4, 8, 1};36 appears[15] = {3, 8, 2, 9};37 appears[16] = {3, 1, 5};38 appears[17] = {3, 8, 6, 11};39 appears[18] = {2};404142 Solver<LS> m();43 var{set{int}} scene[Days](m);44 int d = 0;4546 int sceneArray[Scenes];47 RandomPermutation pe(Scenes);48 forall(i in Scenes) sceneArray[pe.get()] = i/maxDay;49 forall(i in Scenes) scene[sceneArray[i]].insert(i);5051 SceneAllocationObjective<LS> O(m, appears, pay, maxDay);52 forall(d in Days)53 O.post(scene[d]);54 O.close();55 m.close();5657 string[] initAllocation = getScenes(Scenes, Days, scene);5859 int tabu[Scenes, Scenes] = -1;60 UniformDistribution tabuDistr(100..200);6162 int best = O.evaluation();63 int nonImprovingSteps = 0;64 int maxNonImprovingSteps = 15000;6566 int it = 0;67 int nbRestarts = 0;6869 // int timeout = 5 * 60 * 1000; //miliseconds70 int t0 = System.getCPUTime();71 while (O.evaluation() != 334144) {

243

72 selectMin(d1 in Days, d2 in Days: d1 != d2,73 e1 in scene[d1], e2 in scene[d2],74 delta = O.getSwapDelta(scene[d1], e1,75 e2, scene[d2]): delta!=076 && (tabu[e1,e2] <= it ||77 O.evaluation() + delta < best))78 (delta) {79 scene[d1].delete(e1); scene[d1].insert(e2);80 scene[d2].delete(e2); scene[d2].insert(e1);8182 tabu[e1,e2] = it + tabuDistr.get();83 tabu[e2,e1] = it + tabuDistr.get();8485 if(O.evaluation() < best) {86 best = O.evaluation();87 nonImprovingSteps = 0;88 }89 else {90 nonImprovingSteps++;91 if(nonImprovingSteps > maxNonImprovingSteps) {92 forall(d in Days) {93 set{int} actors_ = scene[d];94 forall(k in actors_.copy())95 scene[d].delete(k);96 }9798 int sceneArr[Scenes];99 RandomPermutation p(Scenes);

100 forall(i in Scenes) sceneArr[p.get()] = i/maxDay;101 forall(i in Scenes) scene[sceneArr[i]].insert(i);102103 forall(s1 in Scenes, s2 in Scenes)104 tabu[s1,s2] = -1;105106 best = O.evaluation();107 nonImprovingSteps = 0;108 }109 }110 it++;111 }112 }113114 int time = System.getCPUTime() - t0;115 setOutput(O.evaluation(), time, it, nbRestarts,116 System.getGCUsage(), System.getVMUsage(), Scenes,117 Days, problemFiles[1], initAllocation, scene);

Listing 15.22: scene-allocation-set.co: CBLS set approach to the SceneAllocation problem.

1 include "UserSetObjectiveFunction_LS_";2 include "ActorsSet";

244

34 class SceneAllocationObjective<LS>5 extends UserSetObjectiveFunction<LS> {67 //for construction only8 int _ticketVars;9 dict{int->var{set{int}}} _scenes_;

10 dict{var{set{int}}->int} _mapScenes;1112 //actual variables13 range _Days;14 range _Actors;15 range _Scenes;1617 var{set{int}}[] _scenes;18 var{int}[] _nbDays;19 set{int}[] _days;20 set{int}[,] _scenesSet;2122 set{int}[] _appears;23 int[] _pay;2425 ActorsSet actorsInv;26 var{set{int}}[] _actorsPerday;27 var{int} _evaluation;2829 SceneAllocationObjective<LS>(Solver<LS> ls,30 set{int}[] appears,31 int[] pay, int nbDays)32 : UserSetObjectiveFunction<LS>(ls) {33 _appears = appears;34 _pay = pay;35 _Actors = _pay.getRange();36 _Scenes = _appears.getRange();37 _Days = 1..nbDays;38 _nbDays = new var{int}[_Actors](_ls, _Days);3940 _ticketVars = 0;41 _scenes_ = new dict{int->var{set{int}}}();42 _mapScenes = new dict{var{set{int}}->int}();43 }4445 var{set{int}}[] getSetVariables() { return _scenes; }4647 var{int} evaluation() { return _evaluation; }4849 //add variables50 void post(var{set{int}} s);5152 //create invariants53 void close();54 }

245

5556 void SceneAllocationObjective<LS>::post(var{set{int}} s) {57 assert(_ticketVars < System.getMAXINT());58 int ticketVar = ++_ticketVars;59 _scenes_{ticketVar} = s;60 _mapScenes{s} = ticketVar;61 }626364 void SceneAllocationObjective<LS>::close() {65 //finish construction66 _scenes = new var{set{int}}[1.._ticketVars];67 forall(i in _scenes.getRange())68 _scenes[i] = _scenes_{i};69 _scenes_ = null; //should no longer be used7071 actorsInv = new ActorsSet(_ls, _scenes, _mapScenes,72 _appears, _nbDays);73 _ls.post(actorsInv);74 _days = actorsInv.getDaysPerActor();75 _scenesSet = actorsInv.getScenesPerDayAndActor();7677 _evaluation = new var{int}(_ls) <- sum(a in _Actors)78 _nbDays[a] * _pay[a];79 }8081 int SceneAllocationObjective<LS>::82 getSwapDelta(var{set{int}} s, int u, int v, var{set{int}}

t) {83 int delta = 0;84 int dayS = _mapScenes{s};85 int dayT = _mapScenes{t};8687 forall(a in _appears[u])88 delta+= ((1 - (_days[a].contains(dayT) &&89 (!(_scenesSet[a,dayT].getSize() == 190 &&_appears[v].contains(a)))))91 - (_scenesSet[a,dayS].getSize() == 1))*_pay[a];9293 forall(a in _appears[v])94 delta+= ((1 - (_days[a].contains(dayS) &&95 (!(_scenesSet[a,dayS].getSize() ==196 &&_appears[u].contains(a)))))97 - (_scenesSet[a,dayT].getSize() == 1))*_pay[a];9899 return delta;

100 }

Listing 15.23: SceneAllocationObjective_LS_.co: Implementation of theSceneAllocationObjective < LS > set objective function.

1 class ActorsSet implements Invariant<LS> {

246

2 Solver<LS> _m;34 range _Days;5 range _Actors;6 range _Scenes;78 var{set{int}}[] _scenes;9 set{int}[] _days;

10 set{int}[,] _scenes_;11 dict{var{set{int}}->int} _sceneDay;12 var{int}[] _nbDays;13 set{int}[] _appears;1415 Solver<LS> getLocalSolver() { return _m; }16 set{int}[] getDaysPerActor() { return _days; }17 set{int}[,] getScenesPerDayAndActor() { return _scenes_; }1819 ActorsSet(Solver<LS> m, var{set{int}}[] scenes,20 dict{var{set{int}}->int} sceneDay,21 set{int}[] appears, var{int}[] nbDays) {22 _m = m;23 _scenes = scenes;24 _sceneDay = sceneDay;25 _appears = appears;2627 _Days = _scenes.getRange();28 int nbActors = card(union(d in _Days, s in scenes[d])29 _appears[s]);30 _Actors = 1..nbActors;31 _Scenes = _appears.getRange();3233 _days = new set{int}[_Actors]();34 _scenes_ = new set{int}[_Actors, _Days]();35 _nbDays = nbDays;36 }373839 void post(InvariantPlanner<LS> p);40 void initPropagation();4142 void propagateInsertIntSet(boolean b, var{set{int}} s,43 int value);44 void propagateRemoveIntSet(boolean b, var{set{int}} s,45 int value);4647 //not implemented, included to avoid a compiler error48 void propagateInt(bool b, var{int} v) { assert(false); }49 void propagateFloat(bool b, var{float} v){ assert(false);}5051 }5253 void ActorsSet::post(InvariantPlanner<LS> p) {

247

54 forall(d in _Days)55 p.addSource(_scenes[d]);56 forall(a in _Actors)57 p.addTarget(_nbDays[a]);58 }5960 void ActorsSet::initPropagation(){61 forall(d in _Days, s in _scenes[d], a in _appears[s]) {62 _scenes_[a,d].insert(s);63 _days[a].insert(d);64 }65 forall(a in _Actors)66 _nbDays[a] := card(_days[a]);67 }6869 void ActorsSet::propagateInsertIntSet(boolean b,70 var{set{int}} s,71 int g1) {72 int d = _sceneDay{s};73 forall(a in _appears[g1]) {74 _scenes_[a,d].insert(g1);75 if(!_days[a].contains(d))76 _nbDays[a]++;77 _days[a].insert(d);78 }79 }8081 void ActorsSet::propagateRemoveIntSet(boolean b,82 var{set{int}} s,83 int g1) {84 int d = _sceneDay{s};85 forall(a in _appears[g1]) {86 _scenes_[a,d].del(g1);87 _days[a].del(d);88 if(!_days[a].contains(d))89 _nbDays[a]--;90 }91 }

Listing 15.24: ActorsSet.co: User-defined ActorsSet invariant.

248

Implementation ofBIBD-v-b-r-k-lambda


• balanced-incomplete-block-design.co: a set-CBLS approachto generate Balanced Incomplete Block Designs in Listing 15.25.

• BIBDObjective_LS_.co: the implementation of the user-defined setobjective function BIBDObjective<LS> in Listing 15.26.

• SetObjects.co: the user-defined SetObjects invariant in Listing 15.27.

1 import cotls;2 include "bibd-io-functions";3 include "SetConstraintSystem_LS_";4 include "BIBDObjective_LS_";56 Integer nbObjects(7); //v7 Integer nbBlocks(7); //b8 Integer rValue(3);9 Integer kValue(3);

10 Integer lambda(1);11 string problemFiles[0..1];1213 getInput(nbObjects, nbBlocks, rValue, kValue, lambda,14 problemFiles);1516 Solver<LS> m();17 range Objects = 1..nbObjects;18 range Blocks = 1..nbBlocks;19 var{set{int}}[] blocks = new var{set{int}}[Blocks](m);20 var{bool} isSolved = new var{bool}(m);21 BIBDObjective<LS> O(m, Objects, kValue, rValue,22 lambda, blocks);23 isSolved <- (O.evaluation() == 0);24 m.close();2526 int delta;27 int delta2;2829 int it = 0;30 int nbBackTracks = 0;31 range Noise = 1..5;32

249

33 int timeout = 5 * 60 * 1000; //miliseconds34 int t0 = System.getCPUTime();3536 while(!isSolved && (System.getCPUTime() - t0) < timeout) {37 selectMin(b in Blocks,38 o in Objects: !member(o, blocks[b]),39 delta = O.getAddDelta(blocks[b], o))40 (delta) {4142 blocks[b].insert(o);43 it += 1;4445 if(delta > 0) { //backtrack46 nbBackTracks += 1;47 forall(n in Noise)48 selectMin[5]( b1 in Blocks,49 o1 in blocks[b1],50 delta2 = O.getDropDelta(blocks[b1],51 o1))52 (delta2) {53 blocks[b1].delete(o1);54 }55 }56 }57 }5859 int time = System.getCPUTime() - t0;60 setOutput(O.evaluation(), time, it, nbBackTracks,61 problemFiles[1], nbObjects, nbBlocks,62 rValue, kValue, lambda, blocks);

Listing 15.25: balanced-incomplete-block-design.co: CBLS setapproach to generate Balanced Incomplete Block Designs.

1 include "UserSetObjectiveFunction_LS_";2 include "SetObjects";34 class BIBDObjective<LS>5 extends UserSetObjectiveFunction<LS> {67 int _k;8 int _r;9 int _lambda;

10 range _Objects;11 range _Blocks;1213 var{set{int}}[] _blocks;14 dict{var{set{int}}->int} _mapBlocks;15 var{set{int}}[] _objects;16 dict{var{set{int}}->int} _mapObjects;1718 var{int} _evaluation;

250

19 var{int}[,] _cardInter;20 var{int}[,] _pairExactlyKViolations;21 var{int}[] _objectViolations;22 var{int}[] _objectCardVio;23 var{int}[] _blockCardVio;24 SetObjects objectsInvariant;2526 BIBDObjective<LS>(Solver<LS> m, range Objects, int k,27 int r, int lambda,28 var{set{int}}[] blocks)29 : UserSetObjectiveFunction<LS>(m) {30 _Objects = Objects;31 _Blocks = blocks.getRange();32 _k = k;33 _r = r;34 _lambda = lambda;3536 _blocks = blocks;37 _mapBlocks = new dict{var{set{int}}->int}();38 forall(b in _Blocks)39 _mapBlocks{_blocks[b]} = b;4041 _cardInter = new var{int}[_Objects, _Objects](_ls);42 _pairExactlyKViolations = new var{int}[_Objects,43 _Objects](_ls);44 _objectViolations = new var{int}[_Objects](_ls);45 _objectCardVio = new var{int}[_Objects](_ls);46 _blockCardVio = new var{int}[_Blocks](_ls);4748 _posted = false;49 post();50 }5152 var{set{int}}[] getSetVariables(){ return _blocks; }5354 var{int} evaluation() { return _evaluation; }55 }5657 void BIBDObjective<LS>::post() {58 if(!_posted) {59 objectsInvariant = new SetObjects(_ls, _blocks,60 _mapBlocks, _Objects);61 _ls.post(objectsInvariant);62 _objects = objectsInvariant.getObjects();63 dict{var{set{int}}->int} _mapObjects;6465 forall(o1 in _Objects, o2 in _Objects) //o1 < o2?66 _cardInter[o1,o2] <- card(_objects[o1] inter67 _objects[o2]);6869 forall(o1 in _Objects, o2 in _Objects)70 _pairExactlyKViolations[o1,o2] <-abs(_cardInter[o1,o2]

251

71 - _lambda);7273 forall(o1 in _Objects)74 _objectViolations[o1] <- (sum(o2 in _Objects :75 o1 != o2)76 _pairExactlyKViolations[o1,77 o2]);7879 forall(o in _Objects)80 _objectCardVio[o] <- abs(card(_objects[o]) - _r);8182 forall(b in _Blocks)83 _blockCardVio[b] <- abs(card(_blocks[b]) - _k);8485 _evaluation = new var{int}(_ls) <- (sum(b in _Blocks)86 _blockCardVio[b]) +87 (sum(o in _Objects)(88 _objectViolations[o]89 +_objectCardVio[o]));90 _posted = true;91 }92 }9394 int BIBDObjective<LS>::getAddDelta(var{set{int}} b, int o) {95 //how many constraints would be "violated", some abuse in

the96 //language because we require ’exactly’ k and r97 int delta = 0;9899 if(card(b) >= _k)

100 delta += 1;101102 if(card(_objects[o]) >= _r)103 delta += 1;104105 forall(p in _Objects: p != o)106 if(member(_mapBlocks{b}, _objects[p]) &&107 _cardInter[o,p] >= _lambda)108 delta += 1;109110 return delta;111 }112113 int BIBDObjective<LS>::getDropDelta(var{set{int}} b, int o){114 //how many constraints would no longer be "violated"115 int delta = 0;116117 if(card(b) > _k)118 delta -= 1;119120 if(card(_objects[o]) > _r)121 delta -= 1;

252

122123 forall(p in _Objects: p != o)124 if(member(_mapBlocks{b}, _objects[p])125 && _cardInter[o,p] > _lambda)126 delta -= 1;127128 return delta;129 }

Listing 15.26: BIBDObjective_LS_.co: BIBDObjective<LS> set objectivefunction.

1 class SetObjects implements Invariant<LS> {2 Solver<LS> _m;3 range _Objects;4 range _Blocks;5 var{set{int}}[] _blocks;6 dict{var{set{int}}->int} _mapBlocks;7 var{set{int}}[] _objects;89 Solver<LS> getLocalSolver() { return _m; }

10 var{set{int}}[] getObjects() { return _objects; }1112 SetObjects(Solver<LS> m, var{set{int}}[] blocks,13 dict{var{set{int}}->int} mapBlocks,14 range Objects) {15 _m = m;16 _blocks = blocks;17 _objects = new var{set{int}}[Objects](_m);18 _Objects = Objects;19 _Blocks = _blocks.getRange();20 _mapBlocks = mapBlocks;21 }2223 void post(InvariantPlanner<LS> p);24 void initPropagation();2526 void propagateInsertIntSet(boolean a, var{set{int}} b,27 int o) {28 _objects[o].insert(_mapBlocks{b});29 }3031 void propagateRemoveIntSet(boolean a, var{set{int}} b,32 int o) {33 _objects[o].delete(_mapBlocks{b});34 }3536 //not implemented, included to avoid a compiler error37 void propagateInt(bool b, var{int} v) { assert(false); }38 void propagateFloat(bool b, var{float} v){ assert(false);}39 }40

253

41 void SetObjects::post(InvariantPlanner<LS> p) {42 forall(b in _Blocks)43 p.addSource(_blocks[b]);44 forall(o in _Objects)45 p.addTarget(_objects[o]);46 }4748 void SetObjects::initPropagation() {49 forall(b in _Blocks, o in _blocks[b])50 _objects[o].insert(b);51 }

Listing 15.27: SetObjects.co: User-defined SetObjects invariant.

254

Colophon

This report was typed by the author of this thesis using LATEX 2ε. I (i.e., theauthor of this thesis who is writing this document) developed the source codefor this thesis using GNU Emacs,1 and included it in this document using theListings package. 2

Since I left Bolivia to pursue a MSc degree, almost two years ago, manychanges have been going on there (e.g., now open source software and openstandards are going to be prioritized by law). I celebrate Bolivia’s moral andethical revolution as well as its takeover of its own natural resources. Eco-nomic surplus, transparency, and honesty, however, are no more than the basis,the only way to achieve freedom is through wisdom, knowledge, and technol-ogy: education is the cornerstone.

This is how my master studies end and it feels quite good, "Jallalla!" I mightsay. Sweden is a wonderful country and Uppsala a great place to study.

Thanks Uppsala University!

Rodrigo GumucioAugust 18, 2011

1To the date of writing, a Comet mode for Emacs is available at http://www.imada.sdu.dk/~marco/Teaching/AY2010-2011/DM826/comet.html2The Comet programming language is not currently supported by the Listings package. How-ever, I provided a definition of it in order to provide the code in the appendices – it should beavailable at my home web page in a couple of days; however, feel free to drop me an e-mail ifyou need it.

255

http://www.imada.sdu.dk/~marco/Teaching/AY2010-2011/DM826/comet.html

http://www.imada.sdu.dk/~marco/Teaching/AY2010-2011/DM826/comet.html

constraints on set variables for constraint-based local...

Documents