Autotabling for subproblem presolving in MiniZinc
 1k Downloads
 3 Citations
Abstract
A wellknown and powerful constraint model reformulation is to compute the solutions to a model part, say a custom constraint predicate, and tabulate them within an extensional constraint that replaces that model part. Despite the possibility of achieving higher solving performance, this tabling reformulation is often not tried, because it is tedious to perform; further, if successful, it obfuscates the original model. In order to encourage modellers to try tabling, we extend the MiniZinc toolchain to perform the automatic tabling of suitably annotated predicate definitions, without requiring any changes to solvers, thereby eliminating both the tedium and the obfuscation. Our experiments show that automated tabling yields the same tables as manual tabling, and that tabling is beneficial for solvers of several solving technologies.
Keywords
Presolving Tabling Modelling methodology MiniZinc1 Introduction
If poor propagation is achieved within part of a constraint programming (CP) model, then a common piece of advice is to table that model part. Tabling amounts to computing all solutions to that model part and replacing it by an extensional constraint requiring the variables of that model part to form one of these solutions. If there are not too many solutions, then the hope is that the increased propagation leads to faster solving. An example will be given shortly.
Extensional predicates abound and their efficient propagation to domain consistency is a topic of intense research over the last decade (see [14] for the state of the art): the Open image in new window predicate takes the solutions in tabular form, whereas the Open image in new window predicate [28] takes a compression of such a table into a finite automaton defining a regular language, and the Open image in new window [8] and Open image in new window [9] predicates take a compression of such a table into a multivalued decision diagram (MDD).
The tabling reformulation is however often not tried, because it is tedious to perform; further, it obfuscates the original model if it is actually performed.
Example 1
 Layout

Put the Ace of spades in the middle of the board as the base or “black hole”. Deal all the other cards face up in seventeen fans of three, orbiting the black hole.
 Object

To build the whole pack into a single pile of 52 cards based on the black hole.
 Play

The top (exposed) card of each fan is available for building on the centre pile. Build in ascending or descending sequence regardless of suit, going up or down ad lib and changing direction as often as necessary. Ranking is continuous between Ace and King.
Would it not be nice if the modeller could just add a Open image in new window annotation to the head of the predicate definition whose solutions are to be computed and tabled, like in the first two variants of Fig. 2? Would it not be nice if the compilation and solving toolchain then performed this tabling, added the resulting Open image in new window constraint to the model, and replaced each call to the annotated predicate definition by a call to the relevant Open image in new window constraint?
In this paper, our main contribution is to enable the scenario outlined by the preceding two questions: we extend the MiniZinc toolchain [26] to perform the automatic tabling of suitably annotated predicate definitions.
We see three advantages to our extension. First, the modeller is more likely to experiment with the wellknown and powerful tabling reformulation if its tedium is eliminated by automation. Second, the original model is not obfuscated by tables, at the often negligible cost of computing them onthefly. Third, tabling is technologyneutral: our experiments in Section 2 show that tabling can be beneficial for CP backends, with or without lazy clause generation, constraintbased local search (CBLS) backends, Boolean satisfiability (SAT) backends, SAT modulo theory (SMT) backends, and hybrid backends; we have no evidence yet that a mixedinteger linear programming (MIP) backend to MiniZinc can benefit from tabling.
The organisation of the rest of this paper is as follows. In Section 2 we introduce our MiniZinc annotation and apply it on four case studies. In Section 3 we discuss the implementation issues of adding support for the discussed annotation to the MiniZinc toolchain, and we outline already implemented alternatives and future work. In Section 4 we discuss related work, and we conclude in Section 5.
2 Using the autotabling annotation
The MiniZinc toolchain first compiles, or flattens, a MiniZinc model into a sublanguage called FlatZinc, using instantiations of all the model parameters and predicate definitions that are specific to the solver that is then invoked when interpreting the resulting FlatZinc model [26]. As part of this transformation, the MiniZinc compiler replaces all predicate calls by their definitions. We extend the compiler instead to replace each call to a predicate defined with our Open image in new window annotation by a call to a Open image in new window constraint that has the same solutions (note that MiniZinc model annotations denote recommended but not imposed solving hints and do not affect the model semantics).
To do this, the compiler needs to collect these solutions. This is done by creating and solving, during compilation, some smaller models, which we call submodels. Each submodel defines the annotated predicate and has a single constraint, which calls the annotated predicate with only variables as arguments. We consider three strategies that differ in how many submodels are created and presolved for each annotated predicate definition, and how their variable domains are defined.
We make four case studies with the instancebased strategy, where a single submodel is created for each annotated predicate definition, and the domain of each variable is the union of the domains of that variable across all the calls in the MiniZinc model to that predicate. We describe the two other strategies in Section 3.
We chose our four case studies among many potential ones (say within the model pool of the MiniZinc Challenge and MiniZinc distribution) as follows. The blackholepatience model improvement (Section 2.1) is a famous textbooklevel case and we wanted to show how easy it is to reproduce it now. The block party metacube problem (Section 2.2) is unknown within our community and we wanted to show how a straightforward model can be accelerated. The JPencoding (Section 2.3) model was used in a MiniZinc Challenge and we wanted to show how easy it is now to improve it. The handball tournament (Section 2.4) model was also used in MiniZinc Challenges, and was refined in [7]. That last case study can be seen as a rational reconstruction of a fragment of the refined constraint model.

Gecode [16], version 4.4.0, is a CP solver;

Chuffed [10], version a01c29e, is a CP solver with lazy clause generation;

ortools [19], version 5.0, has a CP solver (ortools/CP) and a SAT solver (ortools/SAT);

MinisatID [11], version 3110, is a hybrid solver combining ideas from CP, SAT, and SMT;

MZN/Yices2 [6], version 2002, translates into an SMT model, solved by Yices2, version 2.5.1;

MZN/Gurobi [2], version 2.0.97, translates into a MIP model, solved by Gurobi Optimizer, version 6.5.2;

MZN/OscaR.cbls [5], version of December 2016, translates into a CBLS model and generates a blackbox search procedure, run by OscaR.cbls [12], version of December 2016.
All experiments were run on a single core of a Intel®; Xeon®; CPU E5520 @ 2.27 GHz with 16 cores and 24 GB RAM running Ubuntu 14.04 64 bits.
All models, instance data, and instance data generators used below are at https://github.com/Dekker1/MiniZincAutoTablingModels.
2.1 The blackhole patience problem
We first revisit the blackhole patience problem of Section 1. We used the second intensional formulation of Fig. 2 because the first one contains the Open image in new window function, which is not supported by all the MiniZinc backends we used; note that it does not matter which intensional formulation is used for autotabling, as the same extensional formulation (the one of Fig. 2) is generated, thereby yielding the published MiniZinc model with a Open image in new window constraint. When autotabling is not used, the second formulation is better for solvers: it creates a single Open image in new window constraint instead of three constraints (namely Open image in new window , Open image in new window , and Open image in new window ).
2.2 The block party metacube problem
It is worth noting that this predicate introduces a local variable, namely Open image in new window , which disappears when the predicate is tabled: as the predicate definition is not used anymore after the tabling, no extra variable is added to the FlatZinc model. This variable was used to express the relation in a succinct way, but is not necessary any more once the predicate is tabled.
In order to obtain more than one problem instance, we generated the Open image in new window array for 14 new satisfiable instances using a datagenerating MiniZinc model producing sets of eight cubes similar to the original ones upon a randomised search procedure. The results, shown in the upperright plot of Fig. 3, are very positive: the total runtime consistently drops by more than 10 times (and more instances are solved) for Chuffed, and by more than 5 times for Gecode. The results are more spread out for MinisatID and ortools/SAT: autotabling increases the runtime for a few instances but it also decreases it by more than 20 times for some instances with MinisatID and allows us to solve more instances with ortools/SAT. Note that MZN/Yices2 timedout on all instances without autotabling but could solve 2 instances with it. The presolving fraction for Gecode of the total solve time, for the instances that Gecode is able to solve or disprove without timing out, is negligible and never exceeds 1%. The presolve time never exceeds 20 ms.
2.3 The JPencoding problem
The JPencoding problem, introduced in the MiniZinc Challenge 2014,^{2} is to recover the original encoding of a stream of Japanese text where several encodings might have been mixed, say by accident. The considered encodings are ASCII, EUCJP, SJIS, and UTF8. An array of bytes is given and the goal is to assign to each byte its encoding in order to maximise the sum of the likelihoods of each byte appearing in the assigned encoding. The encodings may use different numbers of bytes to represent a given character. For example, ASCII always uses one byte, but UTF8 may use from one to four bytes depending on the encoded character. In addition, each encoding defines ranges of possible values for the byte of each position. For example, an ASCII byte can only have a value from 0 to 127, and a UTF8 character on two bytes must have the first byte from 194 to 223 and the second byte from 128 to 191.

Open image in new window is the status of Open image in new window , that is in which position of which variation of which encoding that byte is; the domain has 16 values, including one for an unknown status; for example, the value Open image in new window states that the byte is in the second position of a fourbyte UTF8 encoding;

Open image in new window is the encoding of Open image in new window ; the domain has 5 values, including one for an unknown encoding; for example, the value Open image in new window states that the byte is in the UTF8 encoding;

Open image in new window indicates whether Open image in new window is the start of a character.

Open image in new window is used to restrict the status combinations for two given consecutive bytes; for example, value Open image in new window must be directly preceded by Open image in new window ;

Open image in new window is used to state the functional dependencies between the three variables for a given byte;

Open image in new window is used to state the functional dependency from the encoding and input stream to the score of a given byte.
Many other changes can be made to the original model in order to improve it, and the problem can actually be solved more efficiently by dynamic programming. However, we refrained from making any major nonrefactoring changes to the original model.
Our experiments were run on the five instances used in the MiniZinc Challenge 2014, which range from 100 to 1700 bytes in the Open image in new window array. See the lowerleft plot of Fig. 3: autotabling makes a huge difference. For all plotted solvers except MZN/Gurobi, it is possible to prove optimality on the smallest instance without timing out when autotabling is enabled, and the best found solution at timeout is the same or better with autotabling for all other instances. MZN/OscaR.cbls and MinisatID could not solve any instance without autotabling but could solve the smallest one with it. These improvements are not surprising given that our autotabling replaces a lot of small reified constraints with poor interaction by a few Open image in new window constraints that can be handled very efficiently by most solvers. This is however not the case for MZN/Gurobi: thanks to its own presolving capabilities, this solver is able to prove optimality of all instances without autotabling very fast; enabling the autotabling unfortunately makes MZN/Gurobi about 12 times slower. The presolving fraction for Gecode of the total solve time, for the instances that Gecode is able to solve or disprove without timing out, is negligible and never exceeds 1.5%. The presolve time never exceeds 70 ms.
2.4 The handball tournament scheduling problem
Now, we study a sports scheduling problem that uses a tournament format that consists of two divisional roundrobin tournaments run in parallel (Part I), followed by a fullleague roundrobin tournament (Part II). Elitserien, the top Swedish handball league, uses such a format for its league schedule, followed by Part II repeated but played in reverse order and swapping home and away games for all teams. The league consists of two divisions of n = 7 teams each. In this case study, we ignore the reversed Part II, but keep all other salient features.
A constraint model for this problem was presented in [22]. We will repeat a fragment of the model here, referring the reader to [22] for further details.
A pair of greyshaded H A P array elements denotes a break, i.e., the given team plays at home twice in a row or away twice in a row. It is a constraint of the problem that for any team there can be no break during Part I, at most one break during Part II, and that the number of breaks should be minimal. This number was shown in [21] to be 2n − 2 for leagues with odd division size n.
To make a solution complete, every H A P array element must be assigned the opponent team that will meet the given team in the given period. It is worth noting that not every partial solution can be extended to a complete solution.
Finally, every team prefers not to play at home during selected periods, for example because of venue unavailability. So we have a constrained optimisation problem with the objective of maximising the number of satisfied preferences.
Note that the problem is structurally very constrained. First, symmetry breaking allows us to completely fix Part I (divisional play) of the H A P array up front. Further, the valid combination of any row of the H A P array is functionally determined by the row number and the period in which its break occurs, if any. We now give a fragment of the constraint model.

H A P[r, p] ∈{,,}, where the team in row r plays in period p.

H A P[r] is an abbreviation for the row \([\mathit {HAP}[r,p] \mid p \in \mathcal {P}]\).

\(B[r] \in \mathcal {B}\), the period in which the break for row r begins, or 0 if row r has no break in its schedule.

\(T[r] \in \mathcal {T}\), the team assigned to row r.
First, we applied autotabling to the conjunction of (1) and (2) and some symmetrybreaking constraints that allow us to completely fix Part I of the H A P array. This resulted in a Open image in new window (r, b, p, x) constraint with x = H A P[r, p] functionally determined by r, b = B[r], and p. Let h(r, b, p) denote this function. This in itself did not result in a significant speedup, which did not come as a big surprise, since (2) was the bulk of the autotabled conjunction, and Open image in new window can be propagated to domain consistency on a CP solver.
3 Tool support for autotabling
We now describe how we integrated autotabling into the MiniZinc toolchain.^{4} For further details, see [13].
3.1 Design decisions and implementation
Our first two important design decisions were to autotable predicate calls and to annotate predicate definitions. Indeed, there are other ways to define which subproblems should be presolved, as will be briefly surveyed in Section 5. Our decision to focus on predicates is mainly motivated by the facts that predicates offer a natural way to structure a model and that adding a single annotation to a predicate definition is the simplest way to enable autotabling. Using predicates as the basic building block has the additional benefit that any local variables introduced in a predicate definition disappear upon tabling, as seen in the case studies of Sections 2.2 and 2.4.
An apparent downside of using annotations to predicate definitions is that one may need to refactor a model in order to introduce the predicate definitions one wants to annotate, as seen in the case studies of Sections 2.3 and 2.4. However, one can also see this as an extra incentive for modellers to use predicates in the first place, as this is good modelling practice in the same way as it is good programming practice to break down procedural code into smaller units, such as functions or methods.
While MiniZinc annotations are usually targeted at the solvers, resolving annotations within the MiniZinc compiler is possible and has been done for other annotations in similar situations (for example, Open image in new window is used when set variables are replaced by variables of other types during flattening). Adding our annotation to the MiniZinc language amounts simply to declaring it in the MiniZinc standard library: we will show with Fig. 10 how to do that, after a few additional considerations.
An important advantage of our MiniZinc extension is that all changes are located within the compiler, so that no solver or other part of the toolchain needs to be changed. More precisely, our third important design decision was to add an extra compilation step into the MiniZinc compiler, namely after the type checking and before the actual flattening. This additional intermediate step provides all the presolving functionality. We chose to locate all code in this particular place in order to maintain the modular approach of the existing compiler.
 1.
Find the corresponding Open image in new window item and the calls to this predicate by walking through the parse tree.
 2.
Construct a MiniZinc model, called a submodel, for finding the solutions to the predicate. The submodel comprises the predicate definition, decision variables of the types of the formal arguments of the predicate, a constraint calling the predicate on those decision variables, and a Open image in new window item in order to ask for satisfiability solving. The domain of each introduced variable is the union of the domains of the corresponding variables across all the calls in the original MiniZinc model to the annotated predicate definition.
 3.
Search for all solutions to the constructed submodel by running the MiniZinc toolchain on the submodel: it is in turn flattened and given to a FlatZinc solver by asking for all solutions.
 4.
Collect all the solutions into an array suitable for a Open image in new window constraint. While this is mostly straightforward, some care is needed when the arguments are of different types. Indeed, the MiniZinc language only defines the Open image in new window constraint for all integer variables or all Boolean variables. Hence, one needs to cast Boolean variables into integer ones when they are mixed in a predicate. We currently do not support set and float variables.
 5.
Replace the body of the predicate definition in the original MiniZinc model by a call to a Open image in new window constraint with the obtained array of solutions. The subsequent flattening step will replace the calls to the predicate by this new body.
3.2 Two additional autotabling strategies
In order to accommodate other needs, we implemented two alternatives to the instancebased strategy, used throughout Section 2, which creates and solves a single submodel based on the calls in the MiniZinc model to the annotated predicate.
Under the callbased strategy, a separate submodel is created and solved for each call in the MiniZinc model to the annotated predicate: the domain of each variable in a submodel is the domain of that variable in the corresponding call. Compared to the instancebased strategy, this one may be more suitable when the domains of the calls do not overlap much, thereby creating smaller tables, at the cost of solving more submodels. This strategy must be used when the predicate is called with varying lengths for a variablearray argument: one cannot create a Open image in new window constraint over a nonfixed number of variables, so each call must be handled separately. An example of such a problem is the Kakuro puzzle, where this strategy converts a highly readable model into the specialised model discussed in [30] and [16, Chapter 21].
Under the modelbased strategy, a single, instanceindependent submodel is created, and the domain of each variable is the domain of the corresponding formal argument in the annotated predicate definition of the MiniZinc model. This strategy is called modelbased because it does not depend on the actual calls in the model to the predicate.
3.3 The new annotation
Thanks to this set of annotations, it is easy now for the modeller, novice and expert alike, to make experiments. Indeed, it suffices to change the annotation keyword and measure the effect.
Not all strategies are applicable in all situations. If one tries to use the instancebased strategy when not all calls to the predicate can be aggregated into a single submodel because of, for example, a varying amount of variables in an argument array, then the compiler will issue an error. The same error arises if one tries to use the modelbased strategy with a predicate having as formal argument an array of nonfixed length. The use of the callbased strategy is always safe and never leads to compilation errors.
3.4 Future work on the implementation
Future work includes new features for our implementation.
Under the modelbased strategy, all solutions could be collected only once, provided the predicate does not make use of the instance data, and then cached for use by future runs of the model, even with different instances. Caching of the solutions can be used when presolving for every instance would be too timeconsuming. This would however require extra care in the compiler to ensure that the predicate definition is indeed not dependent on instancespecific data to avoid producing invalid results. For example, caching can be used for the Open image in new window predicate of Fig. 2, but not for the Open image in new window predicate of Fig. 5 because the latter uses the instancespecific Open image in new window array.
A possible extension is to offer the modeller the option to augment the Open image in new window constraints inserted into the presolved model with a backendspecific annotation, or even the choice of an alternative predicate to Open image in new window . This relates to research into alternative implementations of Open image in new window and MiniZinc predicates that might perform better than the backend’s default. This is also related to adding to our implementation the support of MiniZinc features such as predicates on float and set variables or on mixed variable types.
A simple way to support float and set variables, optionally mixed with Boolean or integer variables, is to replace the Open image in new window constraint by an Open image in new window constraint for each column of the table, with all Open image in new window constraints sharing an index variable used to identify a row of the table. This reformulation is generally applicable, as MiniZinc has variants of the Open image in new window predicate on all variable types. However, it may lead to slower solving than using a single constraint.
While the onus of internally using an MDDbased propagator for the Open image in new window predicate is not on us but on the developers of CP backends to MiniZinc, it is important to understand why we currently do not compress the table of presolved tuples so as to use instead the Open image in new window predicate of MiniZinc or an Open image in new window predicate (which does not belong to MiniZinc yet): before compressing the presolved tuples, they have to be generated in the first place. So even though a compressed extension can be generated incrementally, there is no way to avoid enumerating the presolved tuples. An exciting research question in solver design is how to generate sets or subsets of solutions intensionally, say in automaton or MDD form, for a given problem instance and for arbitrary submodels. A starting point would be the work described in [3].
Other features might be added to help modellers. One could, for example, add a timeout parameter to presolving: if a predicate cannot be presolved within a set time limit, then the original definition of the predicate is used.
Further, one can investigate more advanced defaults for the choice of the presolving strategy and an automated choice of the solver to use for presolving, in order to match them better to the contents of the annotated predicate definition.
Finally, one can consider other strategies than the three already implemented ones. Notably, an alternative to the instancebased and callbased strategies would be to perform the tabling after the flattening, where more information about the actual variable domains and array lengths is available. This alternative implementation, which we are currently performing, has the further advantage of facilitating the support for reified calls to the annotated predicate, which are currently not supported.
4 Related work
In addition to the models for the Black Hole, Handball, and Kakuro problems discussed above, reformulation by tabling was used for the maximumdensity still life problem in [9].
Autotabling has been studied for a long time in the constraint programming community. For example, in generalised propagation, as implemented in the Propia library [23] of ECLiPSe, all solutions to an appropriately annotated goal are precomputed and internally replaced by a table constraint. More recently, with IBM ILOG CPLEX CP Optimizer, one can post a strong constraint on a set of variables [20]: all solutions to the constraints involving those variables in the model are found and a corresponding table constraint is posted as an implied constraint on those variables. The main difference with those approaches is that our approach is solverindependent, and even technologyindependent. Note also that using the strong predicate is less finegrained than our approach, because it is at the variable level rather than the predicate level.
Another line of related work is the automated synthesis of propagators for arbitrary constraints. The goal is fundamentally the same as for our autotabling, namely to speed up the solving process by transforming a suitable part of a model into an efficient propagator. The generated propagators can take several forms, such as CHR rules [1], stateless Ccode [18], multivalued decision diagrams [9], and extended indexicals [25]. Again, those approaches are very specific to a single technology or even to a particular solver. In our case, we generate table constraints, which can be used under various solvers and technologies.
Finally, it is important to mention that presolving in general is a wellknown concept in mixed integer programming and SAT modulo theories: solvers may transform models, for example in order to eliminate variables, to tighten constraints and domains, or to isolate some special substructures [15]. While this is less common in constraint programming, a form of presolving by reformulation is implemented in the CP solver of Google ortools [19]. It has also been shown recently that domain tightening can be integrated in the MiniZinc compiler and that it is beneficial to solvers of several technologies [24].
5 Conclusion
Tabling, that is replacing model parts by constraints with precomputed solution arrays, is a powerful yet laborious way to improve model performance. We proposed to automate this process by integrating it in the MiniZinc toolchain: a modeller enables autotabling simply by annotating the predicate definitions to table and the compiler takes care of the rest. Tabling is made easy to use and nonintrusive.
It is often said that modelling is an art that is difficult to master. Indeed, finding a model that is solved efficiently on at least one solver is often difficult. We argue that our autotabling annotation lowers the skill level required for designing a good model: while the way an autotabled predicate is defined still influences the presolving time, it has nearly no influence on the actual solving time (i.e., excluding the presolving time), as the same table will be generated, up to row ordering. Instead, the important modelling decisions for tabling are how to structure the model with predicates and which predicates to table.
While it is too early to extract general principles, our preliminary observations are that autotabling may make a huge difference when the tabled predicate exhibits some of the following characteristics: the predicate has few arguments; some argument is used more than once in the predicate definition; the predicate defines a variable that appears in the objective function; the predicate introduces local variables; or the predicate admits a moderate number of solutions.
Beside the toolspecific future work stated in Section 3.4, it would be interesting to study more closely whether those observations generalise and how much they depend on the use of the Open image in new window predicate or a particular solver.
In particular, while we showed good evidence that MiniZinc CP backends, with and without lazy clause generation, and SAT backends can benefit from autotabling, we have less evidence for the chosen solvers of the other selected technologies, probably because the chosen problems were not suited to those technologies (namely CBLS and hybrids) or, in the case of MZN/Yices2, because the FlatZinctoSMTlib conversion [6] is outdated. Autotabling may not be appropriate for MIP backends to MiniZinc: it is worth studying how one could improve the linearisation in [2] of the Open image in new window predicate.
Finally, lazily computing solutions to a model part is an interesting alternative to precomputing them, in a way similar to decomposition techniques in MIP, such as Benders decomposition or column generation, and to onthefly solution generation when enforcing CPstyle domain consistency on part of a model [4]. However, this would require different architectural choices from the ones we made: in particular, we chose to make no modifications to solvers, which allowed us to perform experiments with a wide range of technologies and solvers, but an onthefly approach would require us to modify the solvers, probably including a tighter integration with the MiniZinc compiler; this might be doable on top of the MiniSearch extension [29] to the MiniZinc toolchain.
Footnotes
 1.
 2.
 3.
 4.
The source code of the extended MiniZinc compiler can currently be found at https://github.com/Dekker1/libminizinc in the feature/presolve branch. The version used in our experiments and described here is tagged cpaior.
Notes
Acknowledgements
We thank Justin Pearson, Peter Stuckey, Guido Tack, Diego de Uña Gomez, and the anonymous referees for their helpful comments. Pierre Flener and Gustav Björdal are supported by the Swedish Research Council (VR) under grant 20154910.
References
 1.Abdennadher, S., & Rigotti, C. (2004). Automatic generation of rulebased constraint solvers over finite domains. ACM Transactions on Computational Logic, 5(2), 177–205.MathSciNetCrossRefzbMATHGoogle Scholar
 2.Belov, G., Stuckey, P.J., Tack, G., & Wallace, M. (2016). Improved linearization of constraint programming models. In Rueher, M. (Ed.), CP 2016, LNCS, (Vol. 9892 pp. 49–65): Springer.Google Scholar
 3.Bergman, D., Cire, A.A., van Hoeve, W.J., & Hooker, J. (2016). Decision diagrams for optimization. Springer.Google Scholar
 4.Bessière, C., & Régin, J.C. (1999). Enforcing arc consistency on global constraints by solving subproblems on the fly. In Jaffar, J. (Ed.), CP 1999, LNCS, (Vol. 1713 pp. 103–117): Springer.Google Scholar
 5.Björdal, G., Monette, J.N., Flener, P., & Pearson, J. (2015). A constraintbased local search backend for MiniZinc. Constraints, 20(3), 325–345.MathSciNetCrossRefzbMATHGoogle Scholar
 6.Bofill, M., Suy, J., & Villaret, M. (2010). A system for solving constraint satisfaction problems with SMT. In Strichman, O., & Szeider, S. (Eds.), SAT 2010, LNCS, (Vol. 6175 pp. 300–305): Springer.Google Scholar
 7.Carlsson, M., Johansson, M., & Larson, J. (2017). Scheduling double roundrobin tournaments with divisional play using constraint programming. European Journal of Operational Research, 259(3), 1180–1190.MathSciNetCrossRefGoogle Scholar
 8.Carlsson, M., Ottosson, G., & Carlson, B. (1997). An openended finite domain constraint solver. In Glaser, H., Hartel, P., & Kuchen, H. (Eds.), PLILP 1997, LNCS, (Vol. 1292 pp. 191–206): Springer.Google Scholar
 9.Cheng, K.C.K., & Yap, R.H.C. (2008). Maintaining generalized arc consistency on ad hoc rary constraints. In Stuckey, P.J. (Ed.), CP 2008, LNCS, (Vol. 5202 pp. 509–523): Springer.Google Scholar
 10.Chu, G. (2011). Improving combinatorial optimization. Ph.D. thesis, Department of Computing and Information Systems. Australia: University of Melbourne.Google Scholar
 11.De Cat, B., Bogaerts, B., Devriendt, J., & Denecker, M. (2013). Model expansion in the presence of function symbols using constraint programming. In Brodsky, A. (Ed.), ICTAI 2013 (pp. 1068–1075): IEEE. The MinisatID solver is available from https://dtai.cs.kuleuven.be/software/minisatid.
 12.De Landtsheer, R., & Ponsard, C. (2013). OscaR.cbls: An open source framework for constraintbased local search, ORBEL27, the 27th annual conference of the Belgian Operational Research Society. Available at http://www.orbel.be/orbel27/pdf/abstract293.pdf; the OscaR.cbls solver is available from https://bitbucket.org/oscarlib/oscar/branch/CBLS.
 13.Dekker, J.J. (2016). Subproblem presolving in MiniZinc. Master’s thesis, Department of Information Technology, Uppsala University, Sweden. Available at http://urn.kb.se/resolve?urn=urn:nbn:se:uu:diva307145.
 14.Demeulenaere, J., Hartert, R., Lecoutre, C., Perez, G., Perron, L., Régin, J., & Schaus, P. (2016). Compacttable: Efficiently filtering table constraints with reversible sparse bitsets. In Rueher, M. (Ed.), CP 2016, LNCS, (Vol. 9892 pp. 207–223): Springer.Google Scholar
 15.Eén, N., & Biere, A. (2005). Effective preprocessing in SAT through variable and clause elimination. In Bacchus, F., & Walsh, T. (Eds.), SAT 2005, LNCS, (Vol. 3569 pp. 61–75): Springer.Google Scholar
 16.Gecode Team (2016). Gecode: A generic constraint development environment. http://www.gecode.org.
 17.Gent, I.P., Jefferson, C., Kelsey, T., Lynce, I., Miguel, I., Nightingale, P., Smith, B.M., & Tarim, S.A. (2007). Search in the patience game ’black hole’. AI Communications, 20(3), 211–226.MathSciNetzbMATHGoogle Scholar
 18.Gent, I.P., Jefferson, C., Linton, S., Miguel, I., & Nightingale, P. (2014). Generating custom propagators for arbitrary constraints. Artificial Intelligence, 211, 1–33.MathSciNetCrossRefzbMATHGoogle Scholar
 19.Google Optimization Team (2016). ortools: Google’s software suite for combinatorial optimization. https://developers.google.com/optimization.
 20.IBM Knowledge Center. The strong constraint. http://www.ibm.com/support/knowledgecenter/SSSA5P_12.6.3/ilog.odms.ide.help/OPL_Studio/opllang_quickref/topics/tlr_oplsch_strong.html.
 21.Larson, J., & Johansson, M. (2014). Constructing schedules for sports leagues with divisional and roundrobin tournaments. Journal of Quantitative Analysis in Sports, 10 (2), 119–129.CrossRefGoogle Scholar
 22.Larson, J., Johansson, M., & Carlsson, M. (2014). An integrated constraint programming approach to scheduling sports leagues with divisional and roundrobin tournaments. In Simonis, H. (Ed.), CPAIOR 2014, LNCS, (Vol. 8451 pp. 144–158): Springer.Google Scholar
 23.Le Provost, T., & Wallace, M. (1992). Domain independent propagation, FGCS 1992, International conference on fifth generation computer systems (pp. 1004–1011): IOS Press.Google Scholar
 24.Leo, K., & Tack, G. (2015). Multipass highlevel presolving. In Yang, Q., & Wooldridge, M. (Eds.), IJCAI 2015 (pp. 346–352): AAAI Press.Google Scholar
 25.Monette, J.N., Flener, P., & Pearson, J. (2015). Automated auxiliary variable elimination through onthefly propagator generation. In Pesant, G. (Ed.), CP 2015, LNCS, (Vol. 9255 pp. 313–329): Springer.Google Scholar
 26.Nethercote, N., Stuckey, P.J., Becket, R., Brand, S., Duck, G.J., & Tack, G. (2007). MiniZinc: Towards a standard CP modelling language. In Bessière, C. (Ed.), CP 2007, LNCS. The MiniZinc toolchain is available at http://www.minizinc.org, (Vol. 4741 pp. 529–543): Springer.
 27.Parlett, D. (Ed.) (1990). The Penguin Book of Patience. London: Penguin.Google Scholar
 28.Pesant, G. (2004). A regular language membership constraint for finite sequences of variables. In Wallace, M. (Ed.), CP 2004, LNCS, (Vol. 3258 pp. 482–495): Springer.Google Scholar
 29.Rendl, A., Guns, T., Stuckey, P.J., & Tack, G. (2015). MiniSearch: A solverindependent metasearch language for MiniZinc. In Pesant, G. (Ed.), CP 2015, LNCS, (Vol. 9255 pp. 376–392): Springer.Google Scholar
 30.Simonis, H. (2008). Kakuro as a constraint problem. In Flener, P., & Simonis, H. (Eds.), ModRef 2018, the 7th International Workshop on Constraint Modelling and Reformulation. https://www.it.uu.se/research/group/astra/ModRef08/Simonis.pdf.
Copyright information
Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.