Work on the intro to the background

assets/glossary.tex

@@ -75,6 +75,11 @@
   description={},
 }
 
+\newglossaryentry{knapsack}{
+  name={knapsack problem},
+  description={},
+}
+
 \newglossaryentry{linear-programming}{
   name={linear programming},
   description={},

assets/packages.tex

@@ -129,6 +129,7 @@ style=apa,
 
 % Code formatting
 \usepackage[
+chapter,
 cachedir=listings,
 outputdir=build,
 ]{minted}

chapters/2_background.tex

@@ -5,22 +5,34 @@
 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
+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.
+actual workings of the hardware.
 
-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.
+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}
@@ -28,32 +40,61 @@ toys that bring Audrey the most amount of joy, but still fit in the car.
     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{example}
 
-\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}
+  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
+  a time intensive task that 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 \subset toys
+      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. The \(joy\) and \(space\) functions are
+  \glspl{parameter} used to map toys to a value depicting the amount of
+  enjoyment and space required respectively. \(C\) is the \gls{parameter} that
+  depicts the total space that is left in the car before packing the toys.
+  Finally, \(z\) is the objective \gls{variable} that is maximised to find the
+  optimal selections of toys to pack.
+
+  This constraint model gives a concise definition of the problem that would be
+  easy to adjust to changes in the requirements.
+
+\end{example}
 
-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.
@@ -67,16 +108,22 @@ compares their functionality to \minizinc{}. Finally, \cref{sec:back-term} and
 \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.
+\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 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{listing}
+  \mznfile{assets/mzn/2_knapsack.mzn}
+  \caption{\label{lst:2-mzn-knapsack} A \minizinc\ model describing a 0-1 knapsack
+    problem}
+\end{listing}
+
 \begin{mzn}
 int: n;
 array [1..n, 1..n] of var 1..n: x;
@@ -118,11 +165,6 @@ 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}