Dekker1/dekker-phd-thesis
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

A better try for the introduction connections

Browse Source
This commit is contained in:
Jip J. Dekker 2021-07-28 10:24:32 +10:00
parent 900c920057
commit fe0234b009
No known key found for this signature in database
GPG Key ID: 517DF4A00618C9C3
1 changed files with 25 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
chapters/1_introduction.tex
View File

@ -41,17 +41,17 @@ The \gls{rewriting} process of a \cml{} transforms a \cmodel{} into a \gls{slv-m
\caption{\label{fig:intro-cml-flow}A flow diagram of typical process of a \cml{}.}
\end{figure}
Traditional \cmls{}, such as \glsxtrshort{ampl} \autocite{fourer-2003-ampl}, \gls{essence} \autocite{frisch-2007-essence}, and \glsxtrshort{opl} \autocite{van-hentenryck-1999-opl}, offer the modeller an expressive language that can be used to target a great variety of \solvers{}.
Traditional \cmls{}, such as \emph{\glsxtrshort{ampl}} \autocite{fourer-2003-ampl}, \gls{essence} \autocite{frisch-2007-essence}, and \emph{\glsxtrshort{opl}} \autocite{van-hentenryck-1999-opl}, offer the modeller an expressive language that can be used to target a great variety of \solvers{}.
However, these language lack a certain level of flexibility: the modeller is unable to capture common concepts used throughout a \cmodel{}, and the \solver{} cannot influence their way in which the problem is encoded.
This is a stark difference to \gls{clp} languages, such as Sictus Prolog \autocite{carlsson-1997-sicstus}, which are said to be the precursors to \cmls{}.
This is a stark difference to \gls{clp} languages, such as \gls{sicstus} \autocite{carlsson-1997-sicstus}, which are said to be the precursors to \cmls{}.
In these languages, the modeller is encouraged to create high-level concepts and declare the way in which they are rewritten into \gls{native} \constraints{}.
The downside of \gls{clp} languages is that, because of its search mechanism, the \solver{} is tightly integrated within the \gls{rewriting}.
These languages thus lack the \solver{}-independence of \cmls{}.
\minizinc{} \autocite{nethercote-2007-minizinc} is a functional \cml{} that operates on a level in between these two types of languages.
Like a traditional \cml{}, it is a \solver{}-independent \cml{}.
Similarly, like a \gls{clp} language, modellers can declare common concepts and control the encoding into the \gls{slv-mod} through the use of function definitions.
Like a \gls{clp} language, modellers can declare and reuse common concepts and control the encoding into the \gls{slv-mod} through the use of function definitions.
Fundamentally, in its \gls{rewriting} process \minizinc{} is a functional language.
It continuously evaluates the calls in a \minizinc{} \instance{} until it reaches \gls{native} \constraints{}.
Like other functional languages, \minizinc{} allows recursion; it can be used as a fully Turing complete programming language.
@ -68,12 +68,13 @@ The overhead of \gls{rewriting} all these \instances{} separately can be substan
In this thesis we revisit the \gls{rewriting} of functional \cmls{} into \glspl{slv-mod}.
We design and evaluate an architecture for \cmls{} that can accommodate the modern uses of these languages.
\section{Constraint Modelling}
\section{Constraint Modelling Varieties}
\glsxtrshort{ampl} is a commonly used \cml{}.
It was originally designed as a common interface between different \gls{mip} \solvers{}.
Let us now study the different ways of constraint modelling in more detail, starting with one of the most commonly used \cmls{}: \glsxtrshort{ampl}.
\glsxtrshort{ampl} was originally designed as a common interface to different \gls{mip} \solvers{}.
The language provides a natural way to define numeric \variables{} and express \constraints{} in the form of linear (in-)equations as described by the class of problem.
The same \glsxtrshort{ampl} model can then be used between different \solvers{}.
The same \glsxtrshort{ampl} model can then be used for different \solvers{}.
\glsxtrshort{ampl} was later extended to include other \solver{} targets, including \gls{cp} and quadratic \solvers{}.
As such, additional types of \constraints{} for these problem classes have been added to the language, removing the restriction that \constraints{} must be linear (in-)equations.
@ -106,12 +107,12 @@ The \solver{} cannot specify how, for example, an operator is best rewritten.
As such, \glsxtrshort{ampl} cannot rewrite all models for all its \solvers{}.
For example, since the model in \cref{lst:intro-open-shop} uses the \mzninline{or} operator, it can only be encoded for \solvers{} that support \glsxtrshort{ampl}'s \gls{cp} interface.
Although they do support the rewriting of models between different problem classes, other \cmls{}, such as \gls{essence} \autocite{frisch-2007-essence} and \glsxtrshort{opl} \autocite{van-hentenryck-1999-opl}, exhibit the same problems.
Although they do support the \gls{rewriting} of models between different problem classes, other traditional \cmls{}, such as \gls{essence} and \glsxtrshort{opl}, exhibit the same problems.
They do not provide any way to capture common concepts.
And, apart from changing the implementation of \glsxtrshort{opl} or \gls{essence}, the \solver{} is unable to influence their preferred encoding.
\gls{clp}, as used for example in the Sictus Prolog language \autocite{carlsson-1997-sicstus}, offers a very different mechanism to create a \cmodel{}.
In these languages, the modeller is encouraged to create high-level concepts and declare the way in which they are rewritten into \gls{native} \constraints{}.
\gls{clp}, as used for example in the \gls{sicstus} language, offers a very different mechanism to create a \cmodel{}.
In \gls{clp} the main method to formulate a \cmodel{} and how to search for a solution it through the use of so-called \constraint{} predicates.
For example, the concepts of one task preceding another and non-overlapping of tasks could be defined in Prolog as follows.
\begin{minted}[
@ -130,7 +131,7 @@ For example, the concepts of one task preceding another and non-overlapping of t
precedes(startA, durA, startB) ; precedes(startB, durB, startA).
\end{minted}
The definition of \mzninline{nonoverlap} requires that either task A precedes task B, or vice versa.
The definition of \texttt{non\_overlap} requires that either task A precedes task B, or vice versa.
However, unlike the \glsxtrshort{ampl} model, Prolog would not provide this choice to the \solver{}.
Instead, it enforces one, test if this works, and it otherwise enforces the other.
@ -140,10 +141,11 @@ The problem with the mechanism is that it requires a highly incremental interfac
This makes the behaviour of the \gls{clp} program dependent on the \solver{} that is used.
As such, a \gls{clp} program is not \solver{}-independent.
\minizinc{} \autocite{nethercote-2007-minizinc} is a functional \cml{} that operates on a level in between these two types of languages.
Like \glsxtrshort{ampl}, it is a \solver{}-independent \cml{}.
And like \gls{clp} languages, modellers can declare common concepts and control the encoding into the \gls{slv-mod}.
The latter is accomplished through the use of function definitions.
\minizinc{} is one of the most prominent \cmls{} and operates on a level in between these two types of languages.
It offers the modeller an expressive language that, in addition to user-defined functions, includes advanced features, such as many types of \variables{}, \glspl{annotation}, and an extensive standard library of \constraints{}.
All of these can be used with all \solver{} targets and, through its functional language, \solvers{} can control how they are encoded into a \gls{slv-mod}.
% As a result of the popularity and maturity of the language, there is a large suite of \minizinc{} models available that can be used as benchmarks.
% The language has also been used in multiple studies as a host for meta-optimization techniques \autocite{ingmar-2020-diverse,ek-2020-online}.
For example, a modeller could create the following \minizinc{} function to express the non-overlapping relation.
\begin{mzn}
@ -156,14 +158,10 @@ For example, a modeller could create the following \minizinc{} function to expre
\noindent{}Since functions that return the truth value of an expression are common when constructing \constraints{}, \minizinc{} supports the ``\mzninline{predicate}'' keyword as equivalent to the ``\mzninline{function var bool:}'' syntax.
Fundamentally, in its \gls{rewriting} process \minizinc{} is a functional language.
It continuously evaluates the calls in a \minizinc{} \instance{} until it reaches \gls{native} \constraints{}.
Like other functional languages, \minizinc{} allows recursion; it can be used as a fully Turing complete programming language.
Using the same mechanism, \minizinc{} defines how an \instance{} is encoded for a \solver{}.
\minizinc{} also determines how an \instance{} is encoded for a \solver{} through function definitions.
All functionality in the \minizinc{} language is eventually expressed using function calls.
The \solver{}, then, has the decision to choose if this call is a \gls{native} \constraint{}, or how this call is rewritten.
For example, the logical or-operator, which was only supported for \gls{cp} \solvers{} in \glsxtrshort{ampl}, could be defined for \gls{mip} solvers in \minizinc{} using the following definition.
For example, the logical \mzninline{or}-operator, which was only supported for \gls{cp} \solvers{} in \glsxtrshort{ampl}, could be defined for \gls{mip} solvers in \minizinc{} using the following definition.
\begin{mzn}
predicate bool_or(var bool: x, var bool: y) =
@ -176,13 +174,10 @@ predicate bool_or(var bool: x, var bool: y) =
predicate bool_or(var bool: x, var bool: y);
\end{mzn}
\section{The Problems of Rewriting MiniZinc}
The functional paradigm employed by \minizinc{} has shown itself to be powerful and flexible for the modeller and \solver{}
However, the performance of the functional evaluation of the language can be a limiting factor.
\minizinc{} is one of the most prominent \cmls{}.
It is an expressive language that, in addition to user-defined functions, gives modellers access to advanced features, such as many types of \variables{}, \glspl{annotation}, and an extensive standard library of \constraints{}.
All of these can be used with all \solver{} targets.
As a result of the popularity and maturity of the language, there is a large suite of \minizinc{} models available that can be used as benchmarks.
The language has also been used in multiple studies as a host for meta-optimization techniques \autocite{ingmar-2020-diverse,ek-2020-online}.
\section{The Problems of Rewriting MiniZinc}
A \minizinc{} model generally consists of a few loops or \glspl{comprehension}; for a \gls{cp} solver, this would be rewritten into a relatively small set of \constraints{} which would be fed whole into the solver.
The existing process for translating \minizinc{} into a \gls{slv-mod} is a somewhat ad-hoc, (mostly) single-pass, recursive unrolling procedure, and many aspects (such as call overloading) are resolved dynamically.