%************************************************
\chapter{Modelling with Constraints}\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}[ht]
  \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}[ht]
  \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.


\section{Constraint Modelling Basics}
\label{sec:2-constraint-modelling-basics}

\section{Solving Techniques}
\label{sec:2-solving-techniques}

\section{A Comparison of Constraint Modelling Languages}
\label{sec:2-different-languages}

\section{What Makes a ``Good'' Model?}
\label{sec:2-model-quality}


\section{From the Abstract Machine Paper}
\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\).