Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

The Travelling Tournament Problem is a well-known optimisation problem, where the goal is to schedule a series of games at different venues such that the travel distance for the participating teams is minimized. The Travelling Umpire Problem (TUP) is a related problem, in which the games and their location are given and the goal is to assign an umpire to each of these games. This assignment must satisfy a number of hard constraints (e.g., the same umpire should not referee the same team two weeks in a row) and the overall distance travelled by the umpires should be minimized.

This problem, which abstracts a real-life task for the Major League Baseball (MLB), was first introduced into the scientific literature in 2007 [15]. Over the last five years, it has received a good deal of attention within the scientific community [4, 5, 13, 14, 16,17,18, 20, 21]. One of its interesting characteristics is that the TUP has a compact description, but is computationally very challenging. Its associated decision problem is NP-complete [5].

In this paper, we investigate whether it is possible to solve the TUP using the declarative paradigm of Answer Set Programming (ASP). For this, we will make use of the state-of-the-art ASP solver Clasp [8], which is a regular winner of the ASP competition [1,2,3, 6, 9, 10]. As we will show below, the TUP can be represented in ASP in an elegant and modular representation. Such a representation has the advantage that it can easily be extended with additional constraints, in order to better capture the real-life MLB problem. The computational performance of our method is superior to that of other declarative paradigms, and matches that of the first special-purpose algorithm to be developed for TUP [16]. However, it cannot match the performance of more recent special-purpose algorithms, such as the state-of-the-art method from [14]. Nevertheless, it is of course a benefit of our declarative approach that improvements to the general-purpose Clasp server automatically speed up our approach as well.

This paper is structured as follows. Section 2 recalls the basic concepts of ASP and Sect. 3 the definition of the TUP. In Sect. 4, our basic encoding of TUP in ASP is then presented. Next, Sect. 5 discusses some ways of improving the computational performance of this encoding. We evaluate the performance of our method and compare it to existing approaches in Sect. 6. Finally, Sect. 7 presents our conclusions.

2 Preliminaries: Answer Set Programming

In this section, we briefly recall the Answer Set Programming (ASP) language and it semantics [11].

An atom is an expression \(p(T_1,\ldots ,T_n)\) where p is an n-ary predicate symbol (\(n\ge 0\)) and the \(T_i\) are either constants (starting with a lower case letter) or variables (starting with an upper case letter). A (normal) rule is an expression of the form:

$$\begin{aligned} A {~\mathtt {}:{}-}~B_1, \dots , B_n, \mathtt {not}\;C_1, \dots ,\mathtt {not}\;C_m. \end{aligned}$$
(1)

Here, A and all of the \(B_i\) and \(C_j\) are atoms. The atom A is called the head of the rule and \(B_1,\ldots ,B_n\), \(\mathtt {not}\;C_1, \ldots ,\mathtt {not}\;C_m\) its body. A (normal) logic program is a finite set of such rules. An atom, rule or program is called ground if it does not contain any variables.

A belief set X is a set of ground atoms. Such a set X satisfies a ground rule r of form (1) if A belongs to X or there exists an \(i \in [1,n]\) such that \(B_i \not \in X\) or a \(j \in [1,m]\) such that \(C_j \in X\). A belief set is a model of a ground program P if it satisfies all rules \(r \in P\).

For a ground rule r of the form (3) and a belief set X, the reduct \(r^X\) is defined whenever there is no atom \(C_j\) for \(j \in [1,m]\) such that \(C_j \in X\). If the reduct \(r^X\) is defined, then it is the rule: \( A {~\mathtt {}:{}-}~B_1,\ldots ,B_n.\) The reduct \(P^X\) of the ground program P consists of all \(r^X\) for \(r\in P\) for which the reduct is defined. A belief set X is a stable model or answer set of P, denoted \(X \models _{st} P\), if it is the least model of \(P^X\).

The answer sets of a non-ground program are defined as the answer sets of the grounding of the program. This grounding is constructed by replacing each non-ground rule r by the set of all ground rules that can be constructed by replacing all the variables in r by constants in all possible ways.

An answer set solver is a program that computes the stable models of a given program. Typically, these solvers extend the basic ASP language with some additional constructs to make it easier to represent interesting problems. In this paper, we will use the input language of the solver Clasp [7]. This language allows the following additional constructs.

A rule of the form

$$\begin{aligned} {~\mathtt {}:{}-}~B_1, \dots , B_n, \mathtt {not}\;C_1, \dots ,\mathtt {not}\;C_m, \end{aligned}$$
(2)

is called a constraint. It is seen as an abbreviation for a rule

$$\begin{aligned} f {~\mathtt {}:{}-}~B_1, \dots , B_n, \mathtt {not}\;C_1, \dots ,\mathtt {not}\;C_m, \mathtt {not}\;f. \end{aligned}$$
(3)

where f is a fresh atom. The effect of such a rule is that no answer set may contain both all of the positive literals \(B_i\) and none of the negative literals \(C_i\). A constraint therefore expresses that its body may not be satisfied.

Another common pattern in ASP programming is the use of a loop over negation to represent a choice between two alternatives. For instance, to express that either p or q must hold, the following two rules may be used:

figure a

The answer sets of this small program are precisely \(\{\) p \(\}\) and \(\{\) q \(\}\). However, because this style of programming quickly grows cumbersome, Claps also allows to represent choices as:

figure b

This expresses that precisely one of the two atoms p and q must holds (the leftmost 1 states that at least one of these atoms must hold and the rightmost 1 states that at most one may hold). It has the same two answer sets as the above two rules (but the two programs are not strongly equivalent—for that, an additional constraint :- p,q should be added to the two rules).

This construct is made even more powerful by the fact that more complex set expressions may be used instead of a simple enumeration of atoms. For instance, 1{p(X) : q(X)}1 states that precisely one atom p(X) must hold out of all atoms p(X) for which X is such that q(X) holds. If we add to this rule the following three facts:

figure c

the answer sets will be precisely \(\{\) p(1) \(\}\), \(\{\) p(2) \(\}\) and \(\{\) p(3) \(\}\). The above three facts may also be conveniently abbreviated as: q(1..3).

3 The Travelling Umpire Problem

The TUP is the problem of assigning n umpires to a double round-robin tournament of 2n teams. Since each team plays every other team twice, there are \(r = 2(2n-1)\) different rounds, in which each team plays against exactly one other team. Each game is played at the home venue of one of the two participating teams. The assignment of umpires is subject to three hard constraints:

  • Each umpire should visit each team’s home venue at least once.

  • An umpire should not visit the same home venue more than once in any sequence of \(q_1\) rounds.

  • An umpire should not referee the same team more than once in any sequence of \(q_2\) rounds.

The parameters \(q_1\) and \(q_2\) control the tightness of the constraints: higher values are more difficult. Clearly, it only makes sense to have \(q_2 \le q_1 \le r/2\).

In addition to these three hard constraints, there is also an objective function that must be minimized, namely, the total distance travelled by all of the umpires (assuming they start in the location where their first game is played). To calculate this objective function, a (symmetric) distance matrix is given which enumerates the distances between the home venues of each pair of teams.

Figure 1 shows an example instance for \(n=2\) and a solution for the problem with \(q_1 = 2\) and \(q_2 = 1\) (note that this problem has no solutions for \(q_2 > 1\); taking \(q_2 = 1\) means that the third constraint can simply be ignored). The solution shown is also the optimal solution (regardless of which distance matrix is used), since the only other solution that exists (modulo the symmetry between the two umpires) is that in which they needlessly move around between rounds 3 and 4.

Fig. 1.
figure 1

An instance of the TUP for \(n=2, q_1=2,q_2=1\) and its optimal solution.

4 Representing the TUP in ASP

Problem instance. The parameters of an instance are represented by a set of ASP facts

figure d

The tournament schedule is given by a set of facts of the form plays(ijr), which denote that home-team i plays away-team j in round r. The distance matrix is represented by a set of facts distance \((i,j,\delta )\), indicating that the distance between the home venue of team i and that of team j is \(\delta \). Only facts for \(i\le j\) are included. The symmetric information is represented by a rule

figure e

Finally, it is also convenient to include a unary predicate last \((r-1)\) which indicates the number \(r-1\) of the last round and a unary predicate max_dist \((\delta _{max})\) which indicates the largest number that occurs in the distance matrix.

The example shown in Fig. 1 corresponds to the following set of facts:

figure f

Generating the search space. We represent the possible solutions to the problem by a set of atoms move(utr), meaning that umpire u moves to the home venue of team t in round r. For instance, move(1,1,0) means that umpire 1 moves to the home venue of team 1 in the round 0 (i.e., the home venue of team 1 is the starting position of umpire 1). The solution shown in Fig. 1 would be represented as:

figure g

Obviously, in a valid solution these atoms must be such that team t actually plays a home game in round r. We first define which teams this are.

figure h

We can then generate the search space by the following choice rule:

figure i

Testing the hard constraints.

Each game must be assigned precisely one umpire. We represent this requirement as:

figure j

The expression \({\texttt {\{move(U,T,R) : umpire(U)\} 0}}\) holds if the set of all move(U,T,R) atoms for which round(R) holds is at most zero; in other words, if no umpires are assigned to the round R game in which team T is the home team. Given the way in which the search space is generated, it would actually be sufficient to add only of these two constraints. However, adding both of them helps the solver to solve the problem more quickly.

Next, we handle the constraint that each umpire should visit each venue. First, we define when an umpire U visits the home venue of team T:

figure k

Now, the constraint is that this predicate must hold for all U and T:

figure l

Of the two constraints regarding repeated games with the same umpire, the constraint concerning home venues is easiest to represent (recall that limit_big contains the paramater \(q_1\) of the instance):

figure m

To express the constraint regarding \(q_2\), we first need to define when an umpire U officiates a game in which team T is involved (as either home or away team) in round R:

figure n

Using this predicate, the constraint for the parameter \(q_1\) (given by the predicate limit_small) is represented as follows:

figure o

Optimisation.

The rules and constraints that we have so far suffice to produce feasible solutions. To find the optimal solution, we first define the distance D that a given umpire U travelled in round R (i.e., to go from his venue in round \(R-1\) to his venue for round R):

figure p

The following statement instructs Clasp to minimize the sum of all these distances D:

figure q

5 Improving the Performance

The program that we have discussed so far correctly generates optimal solutions to the TUP. In this section, we discuss two additions to the program that may improve its computational performance.

A typical method for improving the efficiency of such a program is to introduce additional constraints to break symmetries. For the TUP, only one symmetry is known in the literature, namely the fact that the umpires are all identical. We therefore introduce the following symmetry breaking rule, which forces one particular assignment in round 0:

figure r

A second possibility for improving the efficiency is to choose a suitable heuristic to guide the search process. Similar to, e.g., SAT solvers, an ASP solver works by iteratively selecting some atom that is currently neither true nor false, assigning it one of these two truth values, and then propagating the effects of this assignment. A heuristic is used to decide, first of all, which atom (among those that do not yet have a truth value) should be selected and, second, whether this atom should be made true or whether it should be made false. Clasp already contains a number of built-in heuristics, but it also allows users to provide a domain-specific heuristic by defining a predicate _heuristic (axw). Here, a is an atom, w is a weight and x is a special constant. If \(x =\ \) sign, then w must be either 1 or -1. The meaning of such an atom _heuristic( a ,sign,-1) is that whenever atom a is chosen, it will be given the value false; if instead \(w=1\), then a is assigned the value true.

For the TUP, a good heuristic might be to make choices that assign an umpire to a particular game (i.e., that make a move(U,T,R) atom true). It seems likely that these are the kind of choices that will lead to the most propagation: indeed, making a single such atom true will have at least the effect of forcing all \(n-1\) such atoms for the same game to be false. We therefore include the following rule:

figure s

To complete the heuristic, it still remains to decide which move(U,T,R) atom to choose first. To get the most propagation, it seems reasonable to handle the different rounds in order, and since the assignment in the first round is fixed by the symmetry breaking rule, it makes sense to work in ascending order. Within a round, we greedily attempt to send each umpire to the venue with the smallest travel distance. In this way, we hope to bias the search towards more optimal solutions. This is the same strategy as followed in [14]. We implement this strategy by assigning each move(U,T,R) atom a weight of \(n\delta _{max} + (\delta _{max} - \delta )\), where \(\delta _{max}\) is the maximum distance between venues, \(\delta \) is the distance that the umpire would have to travel to get to the home venue of team T in round R, and n is the number of rounds left after the Rth round.

figure t

In addition to changing the heuristic, Clasp also has numerous configuration options that determine how it precisely conducts the search for a solution. Because the space of all possible configurations is huge, a tool called Piclasp has been developed, which tries to automatically deduce an optimal configuration for a given problem using the SMAC method [12]. It does this by first experimenting with different settings on a number of training instances and then applying Machine Learning techniques to surmise an optimal configuration. This tool does not yet offer support for optimisation problems, however. Nevertheless, we have used it to determine a configuration for the problem of finding a feasible solution (i.e., one that satisfies all the hard constraints, without taking the optimisation criterium into account).

Finally, Clasp is also able to take advantage of multiple processors by running certain computations in parallel. It offers two strategies for this. The compete strategy launches a number of independent executions of the solver, each with different configuration parameters. The output is then simply the result produced by the best configuration. The split strategy essentially runs a single instance of the solver, splitting its search tree over different parallel threads. This has the advantage that the different threads actually help each other, rather than competing with each other and possible duplicating a lot of the work done by the other threads. The disadvantage, however, is that the different threads now need to communicate with—and thus wait for—each other, which may cause some of the capacity to go unused.

6 Experimental Results

In this section, we present some experiments that were conducted to determine which ways of running Clasp perform best for the TUP and how our solution compares to the state of the art. For the first point, we want to answer three questions:

  • Whether the domain-specific heuristic discussed in the previous section performs better than Clasp’s default heuristic (which it selects based on some properties of the problem instance);

  • Whether the configuration settings learned by Piclasp perform better than the default configuration settings (which Clasp again selects based on properties of the problem instance);

  • Whether using multiple processors in parallel leads to better results and, if so, which of the two possible strategies (compete or split) is better.

Experimental results are shown in Table 1. In the name of the different variants, def and dom refer to the use of, respectively, Clasp’s default heurstic versus our domain-specific heuristic; 1, comp and split refer to whether only a single processor was used, or whether all available processors were used with either the competitive or split strategy; finally, \(\pi \) is added to the name whenever the settings learned by Piclasp where used instead of the default settings. All results in this table were computed on a Linux machine containing eight Intel(R) Core(TM) 3.2 GHz processors. The benchmarks instances come from [16] and a timeout of 10 min was used. All results in this section are given as the fraction difference with the best known solution from [19]. In other words, if x is the best value that was computed at the time-out and b is the best known value, then the tables report \(\frac{x-b}{b}\). In addition, the table also reports the average fraction difference for each of the variants, the number of benchmarks for which the variant failed to produce a feasible solution with the time limit (indicated as NoSol in the table—these values are not taken into account when computing the average percentage difference), and the number of benchmarks won by this variant.

Table 1. Comparison of different variants for size \(n=14\).

A first observation about these results is that the default settings consistently perform better than those learned by Piclasp, regardless of which heuristic is being used and regardless of whether parallel processing is used. This may be due to the fact that Piclasp does not support optimisation problems, or to the fact that we supplied it with relatively small training instances (because it needs to run a large number of experiments). For these reasons, Piclasp’s training data may not have been representative enough for the actual problem.

Second, on a single processor, our domain-specific heuristic is almost always (in 10 of the 12 benchmarks) better than the default heuristic. In competitive multi-processor mode, the default heuristic has a slight edge (7 of the 12 benchmarks), whereas in split mode, the domain dependent heuristic has the edge (also 7 out of 12). When the default heuristic is used, competitive mode beats split mode (8 out of 12), whereas split mode always beats competitive mode for the domain-dependent heuristic. Regardless of the heuristic, using all 8 processors instead of just a single processor leads to better results if the appropriate multi-processor strategy is chosen (e.g., dom-1 beats dom-comp, but loses to dom-split in 9 benchmarks).

We conclude from these results that the best variants are dom-split and def-comp. In the rest of our experiments, we use these two variants, together with dom-1, the best single-processor variant. We now compare these three variants with results from [16]. This article reports on three different approaches: a Constraint Programming (CP) approach, an Integer Programming (IP) approach (both using ILOG OPL Studio 3.7 as a solver), and the special-purpose search algorithm GBNS developed by its authors. The results reported for these three approaches are taken from [16] and were performed on an Intel(R) Xeon(TM) processor which ran at the same clock speeds of 3.2 GHz as the Intel(R) Core(TM) processor we used to test our own approach.

Table 2. Comparison for \(n=14\) between our methods (timeout: 10 min) and those of [16] (timeout: 3 h).

Table 2 shows results for \(n=14\). Our own approaches were benchmarked with a timeout of 10 min, while the results reported for the approaches from [16] use a timeout of 3 h. Even taking into account the fact that our multiprocessor variants use 8 processors instead of one, this still puts our approach at a disadvantage. Nevertheless, as can be seen in Table 2, it performs quite well. All of our variants beat Trick et al.’s CP solution on all benchmarks. Against Trick et al.’s IP solution, dom-split performs best, winning 7/12 benchmarks and tying 2; our single-processor variant and def-comp also win 7 but lose the others. Against their special-purpose GBNS algorithm, our single-processor variant wins 6 and ties 2 benchmarks, dom-split wins 5 and tries 3, while def-comp wins 7.

Table 3. Comparison for \(n=16\) between our methods and those of [16] (both timeouts: 3 h).

To judge also the performance for somewhat bigger instances, Table 3 shows experimental results for \(n=16\). Here, our own approaches were benchmarked with the same timeout of 3 h as in [16]. An entry of UNSAT in this table means that the system was able to report that no feasible solution exists; an entry of NoSol means that the system was unable to decide whether a feasible solution exists within the time limit. Also for \(n=16\), the CP solution does not win a single benchmark against any of our approaches. Against IP, our def-comp approach wins 9 out of 16 benchmarks, while dom-split wins only 5 and loses 7. Against GBNS, def-comp wins half of the benchmarks against GBNS and loses the other half. Our dom-split approach does worse, winning only 5 benchmarks against GBNS and losing 7.

In conclusion, our approach clearly outperform the CP approach and does slightly better than IP. It is also on par with the GBNS special-purpose algorithm. However, the same cannot be said for more recent special-purpose algorithms. The currently state-of-the-art the approach of [14] is able to find the optimal solution for each of the \(n=14\) benchmarks and most of the \(n=16\) ones. The best results reported in Tables 2 and 3 above are typically around 10% worse than those of [14].

7 Conclusions

A declarative approach allows computational problems to be solved without requiring the development of special-purpose algorithms. An advantage of such an approach is that the problem specification can easily be changed, by adding or replacing certain constraints. Moreover, developments in solver technology immediately improve the performance of declarative solutions for numerous different problems. A disadvantage is that the computational performance of declarative solvers often lags behind that of special-purpose algorithms, since it may take some time to lift improvements that were made to specific algorithm for one specific problem to the level of a generic reasoning tool. However, features such as domain-specific heuristics allow domain knowledge to be used to improve the performance of the solver.

In this paper, we examined a declarative solution for the Travelling Umpire Problem, which is a challenging optimisation problem that has recently received a lot of attention. As we have shown, it can be formulated in an elegant and modular way in the declarative ASP paradigm. Because the TUP as considered in the literature is only an abstraction of a real-life problem in Major League Baseball, the flexibility to easily add or change constraints is a useful feature for this application.

Using the state-of-the-art ASP solver Clasp, we found that the performance of our approach improves on that of previous declarative solutions and is on par with the first special-purpose algorithm published for this problem. However, it cannot match the performance of current special-purpose algorithms. This suggests that these algorithms use more advanced techniques which have not yet found their way into general-purpose ASP solvers. We believe the TUP might therefore be an interesting benchmark to guide future developments in ASP solver technology.