194 lines
9.0 KiB
TeX
194 lines
9.0 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
|
|
\gls{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 \cml\ 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.
|
|
|
|
In a constraint model, instead of specifying the manner in which we can find the
|
|
solution, we give a concise description of the problem. We describe 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}.
|
|
|
|
This type of combinatorial problem is typically called a \gls{csp}. Many \cmls\
|
|
also support 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 solution that
|
|
satisfies all \glspl{constraint} while minimising (or maximising) \(z\).
|
|
|
|
Although a constraint model does not contain any instructions to find a suitable
|
|
solution, dedicated solving programs exist
|
|
|
|
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.
|
|
|
|
\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}
|
|
|
|
\begin{example}%
|
|
\label{ex:back-knapsack}
|
|
|
|
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.
|
|
|
|
One way to solve this problem is to try all combinations of toys, but this is
|
|
time intensive and quickly grows with the number of toys considered (which one
|
|
would quickly realise trying to pack a car \(2^{|\text{toys}|}\) different
|
|
ways).
|
|
|
|
An educated reader in optimisation problems might recognise that this is a
|
|
variation on the widely known \gls{knapsack}, 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}. The use of dynamic
|
|
programming avoid the exponential growth of the problem when increasing the
|
|
number of toys.
|
|
|
|
Although expert knowledge can sometimes bring you an efficient solution to a
|
|
known problem, it should be noted that not all problems will easily map to
|
|
well known (and studied) problems. Even when part of a problem finds an
|
|
equivalent in a well studied problem, the overall problem might still contain
|
|
requirements that impair you from using known algorithms to solve the problem.
|
|
For example, if wanted to bring toys with different colours, then the
|
|
algorithm in \cref{lst:2-dyn-knapsack} would have to be drastically changed.
|
|
\Gls{constraint-modelling} can offer a more flexible alternative that requires
|
|
less expert knowledge.
|
|
|
|
The following set of equations describe this knapsack problem as a \gls{cop}:
|
|
|
|
\begin{equation}
|
|
\text{maximise}~z~\text{subject to}~
|
|
\begin{cases}
|
|
S \subseteq T \\
|
|
z = \sum_{i \in S} joy(i) \\
|
|
\sum_{i \in S} space(i) < C \\
|
|
\end{cases}
|
|
\end{equation}
|
|
|
|
In these equations \(S\) is set \gls{variable}. It contains the selection of
|
|
toys that will be packed for the trip. \(z\) is the objective \gls{variable}
|
|
that is maximised to find the optimal selections of toys to pack. The
|
|
\gls{parameter} \(T\) is the set of all the toys. The \(joy\) and \(space\)
|
|
functions are \glspl{parameter} used to map toys, \( t \in T\), to a value
|
|
depicting the amount of enjoyment and space required respectively. Finally,
|
|
the \gls{parameter} \(C\) is that depicts the total space that is left in the
|
|
car before packing the toys.
|
|
|
|
This constraint model gives a abstract mathematical definition of the
|
|
\gls{cop} that would be easy to adjust to changes in the requirements. To
|
|
solve instances of this problem, however, these instances have to be
|
|
transformed into input accepted by a \gls{solver}. \cmls\ are designed to
|
|
allow the modeller to express combinatorial problems in a similar fashion to
|
|
the above mathematical definition and generate a definition that can be used
|
|
by dedicated solvers.
|
|
|
|
\end{example}
|
|
|
|
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-clp} survey the closely related fields of \gls{term-rewriting}
|
|
and \gls{clp}.
|
|
|
|
\section{\glsentrytext{minizinc}}%
|
|
\label{sec:back-minizinc}
|
|
|
|
\minizinc\ is a high-level, solver- and data-independent modelling language for
|
|
discrete satisfiability and optimisation problems
|
|
\autocite{nethercote-2007-minizinc}. Its expressive language and extensive
|
|
library of constraints allow users to easily model complex problems.
|
|
|
|
Let us introduce the language by modelling the problem from
|
|
\cref{ex:back-knapsack}. A \minizinc\ model encoding this problem is shown in
|
|
\cref{lst:back-mzn-knapsack}.
|
|
|
|
\begin{listing}
|
|
\mznfile{assets/mzn/back_knapsack.mzn}
|
|
\caption{\label{lst:back-mzn-knapsack} A \minizinc\ model describing a 0-1 knapsack
|
|
problem}
|
|
\end{listing}
|
|
|
|
The model starts with the declaration of the \glspl{parameter}.
|
|
\Lref{line:back:knap:toys} declares an enumerated type that represents all
|
|
possible toys, \(T\) in the mathematical model in the example.
|
|
\Lref{line:back:knap:joy,line:back:knap:space} declare arrays mapping from toys
|
|
to integer values, these represent the functional mappings \(joy\) and
|
|
\(space\). Finally, \lref{line:back:knap:left} declares an integer
|
|
\gls{parameter} to represent the car capacity as an equivalent to \(C\).
|
|
|
|
The model then declares its \glspl{variable}. \Lref{line:back:knap:sel} declares
|
|
the main \gls{variable} \mzninline{selection}, which represents the selection of
|
|
toys to be packed. \(S\) in our earlier model. We also declare the variable
|
|
\mzninline{total_joy}, on \lref{line:back:knap:tj}, which is functionally
|
|
defined to be the summation of all the joy for the toy picked in our selection.
|
|
|
|
Finally, the model contains a constraint, on \lref{line:back:knap:con}, to
|
|
ensure we do not exceed the given capacity and states the goal for the solver:
|
|
to maximise the value of the variable \mzninline{total_joy}.
|
|
|
|
One might note that, although more textual and explicit, the \minizinc\ model
|
|
definition is very similar to our earlier mathematical definition.
|
|
|
|
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.
|
|
|
|
Given the assignments
|
|
|
|
\begin{mzn}
|
|
TOYS = {football, tennisball, stuffed_elephant};
|
|
toy_joy = [63, 12, 100];
|
|
toy_space = [32, 8, 40];
|
|
space_left = 44;
|
|
\end{mzn}
|
|
|
|
the following model is the result of flattening:
|
|
|
|
\begin{mzn}
|
|
var 0..1: selection_0;
|
|
var 0..1: selection_1;
|
|
var 0..1: selection_2;
|
|
var 0..175: total_joy:: is_defined_var;
|
|
constraint int_lin_le([32,8,40],[selection_0,selection_1,selection_2],44);
|
|
constraint int_lin_eq([63,12,100,-1],[selection_0,selection_1,selection_2,total_joy],0):: defines_var(total_joy);
|
|
solve maximize total_joy;
|
|
\end{mzn}
|
|
|
|
This \emph{flat} problem will be passed to some \gls{solver}, which will attempt
|
|
to determine an assignment to each decision variable \mzninline{solection_i} and
|
|
\mzninline{total_joy} that satisfies all constraints and maximises
|
|
\mzninline{total_joy}, or report that there is no such assignment.
|
|
|
|
\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}
|