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

Small corrections

Browse Source
This commit is contained in:
Jip J. Dekker 2021-07-27 23:38:21 +10:00
parent 1041eda4c7
commit 900c920057
No known key found for this signature in database
GPG Key ID: 517DF4A00618C9C3
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
chapters/1_introduction.tex
View File

@ -29,11 +29,11 @@ Two \solvers{} designed to solve the same problem class can perform very differe
\Cmls{} have been designed to tackle these issues.
They serve as a level of abstraction between the modeller and the \solver{}.
The typical process of a \cml{} is visualized in \cref{fig:intro-cml-flow}.
Instead of providing a flat list of \variables{} and \constraints{}, a modeller creates a \cmodel{} using the more natural syntax of the \cml{}.
A \cmodel{} can generally describe a class of problems through the use of \prbpars{}, values assigned by external input.
A \cmodel{} can generally describe a class of problems through the use of \prbpars{}: values assigned by external input.
Once given a complete \gls{assignment} of the \prbpars{}, the \cmodel{} forms an \instance{}.
Central to the process of a \cml{}, the \instance{} is transformed, through \gls{rewriting}, into a \gls{slv-mod}, an encoding of the problem that can be used by the \solver{}.
This process is visualized in \cref{fig:intro-cml-flow}.
The \gls{rewriting} process of a \cml{} transforms a \cmodel{} into a \gls{slv-mod}: the encoding of the problem for the \solver{}.
\begin{figure}
\centering
@ -42,16 +42,16 @@ This process is visualized in \cref{fig:intro-cml-flow}.
\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{}.
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 different to \gls{clp} languages, such 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 Sictus Prolog \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{}.
And 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.
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.
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.
@ -112,7 +112,7 @@ And, apart from changing the implementation of \glsxtrshort{opl} or \gls{essence
\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{}.
For example, the concepts of one task preceding another and non-overlapping of tasks could be defined in Prolog as:
For example, the concepts of one task preceding another and non-overlapping of tasks could be defined in Prolog as follows.
\begin{minted}[
autogobble=true,