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{}.} \caption{\label{fig:intro-cml-flow}A flow diagram of typical process of a \cml{}.}
\end{figure} \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. 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{}. 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}. 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{}. 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. \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{}. 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. 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{}. 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. 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}. 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. 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{}. Let us now study the different ways of constraint modelling in more detail, starting with one of the most commonly used \cmls{}: \glsxtrshort{ampl}.
It was originally designed as a common interface between different \gls{mip} \solvers{}.
\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 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{}. \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. 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{}. 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. 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. 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. 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{}. \gls{clp}, as used for example in the \gls{sicstus} language, 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{}. 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. For example, the concepts of one task preceding another and non-overlapping of tasks could be defined in Prolog as follows.
\begin{minted}[ \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). precedes(startA, durA, startB) ; precedes(startB, durB, startA).
\end{minted} \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{}. 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. 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. 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. 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. \minizinc{} is one of the most prominent \cmls{} and operates on a level in between these two types of languages.
Like \glsxtrshort{ampl}, it is a \solver{}-independent \cml{}. 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{}.
And like \gls{clp} languages, modellers can declare common concepts and control the encoding into the \gls{slv-mod}. 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}.
The latter is accomplished through the use of function definitions. % 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. For example, a modeller could create the following \minizinc{} function to express the non-overlapping relation.
\begin{mzn} \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. \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. \minizinc{} also determines how an \instance{} is encoded for a \solver{} through function definitions.
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{}.
All functionality in the \minizinc{} language is eventually expressed using function calls. 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. 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} \begin{mzn}
predicate bool_or(var bool: x, var bool: y) = 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); predicate bool_or(var bool: x, var bool: y);
\end{mzn} \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{}. \section{The Problems of Rewriting MiniZinc}
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}.
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. 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. 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.