MiniCP: a lightweight solver for constraint programming

Abstract

This paper introduces MiniCP, a lightweight, open-source solver for constraint programming. MiniCP is motivated by educational purposes and the desire to provide the core implementation of a constraint-programming solver for students in computer science and industrial engineering. The design of MiniCP provides a one-to-one mapping between the theoretical and implementation concepts and its compositional abstractions favor extensibility and flexibility. MiniCP obviously does not support all available constraint-programming features and implementation techniques, but these could be implemented as future extensions or exploratory projects. MiniCP also comes with a full set of exercises, unit tests, and development projects.

Appendices

Java closures

Java 1.8 supports the concept of closures (aka first-order functions) which is at the core of functional programming. The MiniCP solver makes extensive use of closures for more readibility and conciseness. Consider the identity function $\lambda x.x$ expressed in lambda-calculus. It can be written in Java 1.8 as

The code indicates that Java provides a generic type ${\texttt {Function<A,B>}}$ to represent a function of type $A \rightarrow B$. and r is used to refer to the identity function. The next two lines show how to apply closure r for various values. Since this example is somewhat verbose, Java 1.8 offers syntactic sugar to simplify the notation, dropping the argument type, the block syntax, and the return keyword to obtain

This brings the definition of r close to a lambda calculus definition. Java 1.8 also makes it possible to define arbitrary closure types through the concept of functional interface. For instance, the snippet

defines the type of a closure that takes no input and return no outputs. It just executes a block of code. MiniCP also makes extensive use of functional interfaces defined in the JDK 1.8. For instance, a branching (closure returning an array of Procedure) is none other than ${\texttt {Supplier<Procedure[]>}}$. Boolean predicates over some type T (i.e., first-order functions of type $T \rightarrow \mathbb {B}$ use ${\texttt {Predicate<T>}}$ while first-order functions of type $T \rightarrow N$ use ${\texttt {Function<T,N>}}$.

Performance evaluation

The objective of those experiments is to measure the raw performances of the basic funtionalities offered by a solver: backtracking and propagation mechanisms, domains, search, etc. Our goal is to measure if, despite its simplicity, MiniCP achieve reasonable performance when compared to carefully engineered and optimized solvers, including Choco [14] (version 4.0.2) implemented in Java and OscaR [9] (version 4.0.0) implemented in Scala. Both [14] and [9] have more than 50K lines of code. The MiniCP version used in the test is 1.0.1. Table 3 was obtained on a MacBook Pro with a 2.6Ghz 6-Core i7 running macOS Catalina 10.15.1. The Java version used is

Runtime were obtained by using the time command of the operating system as in, for instance:

and reporting the wall clock time.

Table 3 Performance comparison with Choco [14] and OscaR [9]

In state-of-the-art solvers, great care is dedicated to the efficient implementation of global constraints. Since comparing implementations of global constraints is not the purpose of this evaluation, the models used in the experiments and available here https://zenodo.org/record/3557449 are quite simple and composed of sum, elements, reification and binary constraints. The experimental evaluation ensures that the same search trees is explored by all the solvers. The evaluation also forces a sparse-representation of the domains as this is the only available option in MiniCP in the base implementation.

Table 3 presents the results and running times are given in seconds. The performance of MiniCP is reasonably good despite its simplicity, flexibility and the fact that we explicitly refrain from optimizing the implementation. For instance, the code uses Java collections which induce a significant overhead due to object and iterator creations; An optimized solver such as OscaR or Choco often uses its own array-based collections. Boolean variables in MiniCP are simply 0/1 integer variables, while OscaR uses a dedicated implementation. OscaR statically pre-allocates frequently used objects to avoid the dynamic creation of StateEntries. Aside from this lack of optimization in memory management, the performance difference can be explained by the fact that OscaR and Choco have a priority system to schedule light constraints before more complex ones. While the default implementation of MiniCP has no constraint priorities, adding the necessary support is straightforward and un-intrusive. First, one must add a constant attribute (and an accessor) to each constraint instance to hold onto a priority level (a value from a discrete subset of integers, e.g., 0 through k where k is the highest priority). Second, the state of MiniCP solver class (Listing 15) must be upgraded to hold onto a vector of ${\texttt {Queue<Constraint>}}$, one for each discrete priority. Third, when a constraint c is scheduled, it gets added to the propagation queue matching c’s priority (changes to method schedule of MiniCP. Finally, the fixpoint algorithm (method fixPoint of MiniCP) must, at each iteration, determine the highest non-empty priority queue and pull the next constraint from there. Once all queues become empty, the fixpoint is reached and one can break out of the loop.