139 lines
6.4 KiB
TeX
139 lines
6.4 KiB
TeX
%************************************************
|
|
\chapter{Review of Literature}\label{ch:background}
|
|
%************************************************
|
|
|
|
A goal shared between all programming languages is to provide a certain level of
|
|
abstraction: an assembly language allows you to abstract from the binary
|
|
instructions and memory positions; Low-level imperial languages, like FORTRAN,
|
|
were the first to allow you to abstract from the processor archITECTURE of the
|
|
target machine; and nowadays writing a program requires little knowledge of the
|
|
actual workings of the hardware. Freuder states that the ``Holy Grail'' of
|
|
programming languages would be where the user merely states the problem, and the
|
|
computer solves it and that constraint modelling is one of the biggest steps
|
|
towards this goal to this day \autocite*{freuder-1997-holygrail}. Different
|
|
from imperative (and even other declarative) languages, in a constraint
|
|
modelling language the modeller does not describe how to solve the problem, but
|
|
rather provides the problem requirements. You could say that a constraint model
|
|
actually describes the solution to the problem.
|
|
|
|
For example, let us consider the following scenario: Packing for a weekend trip,
|
|
I have to decide which toys to bring for my dog, Audrey. We only have a small
|
|
amount of space left in the car, so we cannot bring all the toys. Since Audrey
|
|
gets enjoys playing with some toys more than others, we can now try and pick the
|
|
toys that bring Audrey the most amount of joy, but still fit in the car.
|
|
|
|
\begin{listing}
|
|
\pyfile{assets/py/2_dyn_knapsack.py}
|
|
\caption{\label{lst:2-dyn-knapsack} A Python program that solves a 0-1 knapsack
|
|
problem using dynamic programming}
|
|
\end{listing}
|
|
|
|
A well educated reader in optimisation problems might immediately recognise that
|
|
this is a variation on the widely known \textit{knapsack problem}, more
|
|
specifically a \textit{0-1 knapsack problem}
|
|
\autocite[13--67]{silvano-1990-knapsack}. A commonly used solution to this
|
|
problem is based on dynamic programming. An implementation of this approach is
|
|
shown in \cref{lst:2-dyn-knapsack}. In a naive recursive approach we would try
|
|
all different combinations of toys to find the combination that will give the
|
|
most joy, but using a dynamic programming approach this exponential behaviour
|
|
(on the number of toys) can be avoided.
|
|
|
|
\begin{listing}
|
|
\mznfile{assets/mzn/2_knapsack.mzn}
|
|
\caption{\label{lst:2-mzn-knapsack} A \minizinc\ model describing a 0-1 knapsack
|
|
problem}
|
|
\end{listing}
|
|
|
|
A constraint model offers a different view of the problem. Instead of specifying
|
|
the manner in which we can find the solution, we give a concise description of
|
|
the problem in terms of what we already know, the \glspl{parameter}, what we
|
|
wish to know, the \glspl{variable}, and the relationships that should exists
|
|
between them, the \glspl{constraint}. \Cref{lst:2-mzn-knapsack} shows a
|
|
\minizinc\ model of the knapsack problem, where the different elements of the
|
|
constraint model are separated. Although a constraint model does not contain any
|
|
instructions to find a suitable solutions, these models can generally be given
|
|
to a dedicated solving program, or \gls{solver} for short, that can find a
|
|
solution that fits the requirements of the model.
|
|
|
|
In the remainder of this chapter we will first, in \cref{sec:back-minizinc}
|
|
introduce \minizinc\ as the leading \cml\ used within this thesis.
|
|
\cref{sec:back-mzn-interpreter} explains the process that the current \minizinc\
|
|
interpreter uses to translate a \minizinc\ model into a solver-level constraint
|
|
model. Then, \cref{sec:back-other-languages} introduces alternative \cmls\ and
|
|
compares their functionality to \minizinc{}. Finally, \cref{sec:back-term} and
|
|
\cref{sec:back} survey the closely related fields of
|
|
|
|
|
|
\section{\glsentrytext{minizinc}}%
|
|
\label{sec:back-minizinc}
|
|
|
|
\minizinc\ \autocite{nethercote-2007-minizinc} is a high-level, solver- and
|
|
data-independent modelling language for discrete satisfiability and optimisation
|
|
problems. Its expressive language and extensive library of constraints allow
|
|
users to easily model complex problems.
|
|
|
|
Let us introduce the language by modelling the well-known \emph{Latin squares}
|
|
problem \autocite{wallis-2011-combinatorics}: Given an integer \(n\), find an
|
|
\(n \times n\) matrix, such that each row and column is a permutation of values
|
|
\(1 \ldots n\). A \minizinc\ model encoding this problem could look as follows:
|
|
|
|
\begin{mzn}
|
|
int: n;
|
|
array [1..n, 1..n] of var 1..n: x;
|
|
|
|
constraint forall (r in 1..n) (
|
|
all_different([x[r, c] | c in 1..n])
|
|
);
|
|
constraint forall (c in 1..n) (
|
|
all_different([x[r, c] | r in 1..n])
|
|
);
|
|
\end{mzn}
|
|
|
|
The model introduces a \gls{parameter} \mzninline{n}, and a two-dimensional
|
|
array of \glspl{variable} (marked by the \mzninline{var} keyword) \mzninline{x}.
|
|
Each variable in \mzninline{x} is restricted to the set of integers
|
|
\mzninline{1..n}, which is called the variable's \gls{domain}. The constraints
|
|
specify the requirements of the problem: for each row \mzninline{r}, the
|
|
\mzninline{x} variables of all columns must take pairwise different values (and
|
|
the same for each column \mzninline{c}). This is modelled using the
|
|
\mzninline{all_different} function, one of hundreds of pre-defined constraints
|
|
in \minizinc's library.
|
|
|
|
Given ground assignments to input \glspl{parameter}, a \minizinc\ model is
|
|
translated (via a process called \emph{flattening}) into a set of variables and
|
|
primitive constraints. Here is the result of flattening for \mzninline{n=2}:
|
|
|
|
\begin{mzn}
|
|
var 1..2: x_1_1;
|
|
var 1..2: x_1_2;
|
|
var 1..2: x_2_1;
|
|
var 1..2: x_2_2;
|
|
constraint all_different([x_1_1, x_1_2]);
|
|
constraint all_different([x_2_1, x_2_2]);
|
|
constraint all_different([x_1_1, x_2_1]);
|
|
constraint all_different([x_1_2, x_2_2]);
|
|
\end{mzn}
|
|
|
|
This \emph{flat} problem will be passed to some \gls{solver}, which will attempt
|
|
to determine an assignment to each decision variable \verb|x_i_j| that satisfies
|
|
all constraints, or report that there is no such assignment.
|
|
|
|
This type of combinatorial problem is typically called a \gls{csp}. \minizinc
|
|
also supports the modelling of \gls{cop}, where a \gls{csp} is augmented with an
|
|
\gls{objective} \(z\). In this case the goal is to find an assignment that
|
|
satisfies all constraints while minimising (or maximising) \(z\).
|
|
|
|
\section{The current \glsentrytext{minizinc} interpreter}%
|
|
\label{sec:back-mzn-interpreter}
|
|
|
|
\section{Other Constraint Modelling Languages}%
|
|
\label{sec:back-other-languages}
|
|
|
|
\section{ACD Term Rewriting}%
|
|
\label{sec:back-term}
|
|
|
|
\section{Constraint Logic Programming}%
|
|
\label{sec:back-clp}
|
|
|
|
|