Morning editing

chapters/1_introduction.tex

@@ -3,17 +3,16 @@
 %************************************************
 
 \noindent{}A \gls{dec-prb} is any problem that requires us to make decisions according to a set of rules.
-Many important and difficult problems in the real world are \glspl{dec-prb}.
+Many important and difficult problems in the real world are \glspl{dec-prb}, for example, deciding on the country's rail timetable or the stand-by locations for ambulances in the region.
-We can think, for instance, about the decisions on the country's rail timetable or the stand-by locations for ambulances in the region.
 Formally, we define a \gls{dec-prb} as a set of \variables{} subject to a set of logical \constraints{}.
 A \gls{sol} to such a problem is the \gls{assignment} of all \variables{} to values that abide by the logic of the \constraints{}.
 These problems are also highly computationally complex: even with the fastest computers, finding a solution can take a long time.
 They get even more complex when we consider \glspl{opt-prb}: if there are multiple solutions, then one may be preferred over the other.
-But, although these problems are hard to solve, finding a (good) solution for these problems is essential in many walks of life.
+Although these problems are hard to solve, finding a (good) solution for these problems is essential in many walks of life.
 
 The field of \gls{or} uses advanced computational methods to help make (better) decisions.
 Famous classes of decision and \glspl{opt-prb}, such as \gls{sat} \autocite{biere-2021-sat}, \gls{cp} \autocite{rossi-2006-cp} and \gls{mip} \autocite{wolsey-1988-mip}, have been studied extensively.
-And, over the years, highly specialized \solvers{} have been created to find \glspl{sol} for these classes of problems.
+Over the years, highly specialized \solvers{} have been created to find \glspl{sol} for these classes of problems.
 Nowadays, most decision and \glspl{opt-prb} are solved by encoding them into one of the above-mentioned classes of problems.
 
 Encoding one problem in terms of another is, however, a difficult task.
@@ -22,7 +21,7 @@ Furthermore, \constraints{} can only refer to \variables{}, they cannot be (dire
 For example, \gls{sat} \solvers{} can only reason about Boolean \variables{}, deciding if something is true or false.
 \Constraints{} for \gls{sat} \solvers{} have to be in the form of disjunctions of Boolean \variables{}, or their negations.
 
-But, not only does the encoding have to be correct, the encoding also has to be performant.
+Not only does the encoding have to be correct, the encoding also has to be performant.
 There are often many possible correct encodings of a problem, but there can be a significant difference in how quickly the \solver{} finds a \gls{sol} for them and the preferred encoding can differ between \solvers{}.
 Two \solvers{} designed to solve the same problem class can perform very differently.
 
@@ -32,18 +31,18 @@ The typical process of using 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.
 Once given a complete \gls{assignment} of the \prbpars{}, the \cmodel{} forms an \instance{}.
-The \gls{rewriting} process of a \cml{} transforms a \cmodel{} into a \gls{slv-mod}: the encoding of the problem for the \solver{}.
+The \gls{rewriting} process of a \cml{} transforms an \instance{} into a \gls{slv-mod}: the encoding of the problem for the \solver{}.
 
 \begin{figure}
 	\centering
 	\includegraphics[width=\columnwidth]{assets/img/intro_cml_flow}
-	\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 the typical process of using a \cml{}.}
 \end{figure}
 
 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 languages 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 \gls{sicstus} \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 precursor to \cmls{}.
 In these languages, the modeller is encouraged to express high-level concepts by defining custom predicates and functions 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{}.
@@ -81,8 +80,7 @@ As such, additional types of \constraints{} for these problem classes have been
 Let us introduce the \glsxtrshort{ampl} language by modelling the ``open shop'' problem.
 In the open shop problem, the goal is to schedule jobs with multiple tasks.
 Each task must be performed by an assigned machine.
-A machine can only perform one task at any one time.
+A machine can only perform one task at any one time and only one task of the same job can be scheduled at the same time.
-And, only one task of the same job can be scheduled at the same time.
 We assume that each job has a task for every machine.
 As an \gls{opt-prb}, our goal is to find a schedule that minimizes the finishing time of the last task.
 
@@ -107,8 +105,7 @@ 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 (see lines \ref{line:intro:or:first} and \ref{line:intro:or:second}), it can only be encoded for \solvers{} that support \glsxtrshort{ampl}'s \gls{cp} interface.
 
 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 \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.
@@ -135,7 +132,7 @@ However, unlike the \glsxtrshort{ampl} model, Prolog would not provide this choi
 Instead, it enforces one, tests if this works, and otherwise it enforces the other.
 
 This is a powerful mechanism where choices are made in the \gls{rewriting} process, and not in the \solver{}.
-The problem with the mechanism is that it requires a highly incremental interface with the \solver{} that can incrementally post and retract \constraints{}.
+The problem with the mechanism is that it requires a highly incremental interface to the \solver{} that can incrementally post and retract \constraints{}.
 \Solvers{} are also not always able to verify if a certain set of \constraints{} is consistent.
 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.
@@ -174,7 +171,7 @@ For example, the logical \mzninline{or}-operator, which was only supported for \
 	predicate bool_or(var bool: x, var bool: y);
 \end{mzn}
 
-The functional paradigm employed by \minizinc{} has shown itself to be powerful and flexible for the modeller and \solver{}
+The functional paradigm employed by \minizinc{} has shown itself to be powerful and flexible for modeller and \solver{}.
 However, the performance of the functional evaluation of the language can be a limiting factor.
 
 \section{Why Rewriting MiniZinc is Difficult}
@@ -193,7 +190,7 @@ In particular:
 
 	\item The existing implementation of \minizinc{} is inefficient.
 		It does a surprisingly large amount of work for each expression (especially resolving sub-typing and overloading), which may be repeated many times.
-		And as models generated for low-level \solver{} technologies can be quite large, the resulting \gls{rewriting} procedure can be intolerably slow.
+		This means that, as models generated for low-level \solver{} technologies can be quite large, the resulting \gls{rewriting} procedure can be intolerably slow.
 		As the model transformations implemented in \minizinc{} become more sophisticated, these performance problems are simply magnified.
 
 	\item The generated models often contain unnecessary \constraints{}.
@@ -205,7 +202,7 @@ In particular:
 		In the second case, a \gls{reif} has to be introduced: an often costly form of the \constraint{} that determines whether a \constraint{} holds rather than enforcing the \constraint{} itself.
 		It is possible, however, that further \gls{rewriting} can reveal a \gls{reif} to be unnecessary.
 		The current \minizinc{} implementation cannot reverse any \gls{reif} decisions once they are made.
-		And, it also does not consider \gls{half-reif}, a cheaper alternative to \gls{reif} that is often applicable.
+		It also does not consider \gls{half-reif}, a cheaper alternative to \gls{reif} that is often applicable.
 
 	\item Monolithic \gls{rewriting} is wasteful.
 		When \minizinc{} is used as part of a \gls{meta-optimization} toolchain, there is typically a large base model, common to all sub-problems, and a small set of \constraints{}, which are added or removed in each iteration.

chapters/2_background.tex

@@ -53,8 +53,7 @@ The \solver{} then uses a dedicated algorithm that finds a \gls{sol} that fits t
 
 	In these equations \(S\) is a set \variable{}.
 	It represents the selection of toys to be packed for the trip.
-	The \gls{objective} evaluates the quality of the \gls{sol} through the \variable{} \(z\).
+	The \gls{objective} evaluates the quality of the \gls{sol} through the \variable{} \(z\), which is bound to the amount of joy that the selection of toys will bring.
-	And, \(z\) is bound to the amount of joy that the selection of toys will bring.
 	This is to be maximized.
 	The \prbpars{} \(T\) is the set of all available toys.
 	The \(joy\) and \(space\) functions are \prbpars{} used to map toys, \( t \in T\), to a numeric value describing the amount of enjoyment and space required respectively.
@@ -158,7 +157,7 @@ We briefly discuss the most important model items.
 Note that these items already refer to \minizinc{} expressions, which will be discussed in \cref{subsec:back-mzn-expr}.
 For a detailed overview of the structure of \minizinc{} models the full syntactic structure of \minizinc{} 2.5.5 can be consulted in \cref{ch:minizinc-grammar}.
 \textcite{nethercote-2007-minizinc} offer a detailed discussion of \minizinc{}.
-And, much of its history can be learned from the description of its predecessor, \zinc{} \autocite{marriott-2008-zinc}.
+Much of \minizinc{}'s history can be learned from the description of its predecessor, \zinc{} \autocite{marriott-2008-zinc}.
 
 \paragraph{Variable Declaration Items} Variables are declared using variable declaration items.
 The term ``variable'' has two overlapping, and slightly confusing meanings.
@@ -938,8 +937,7 @@ When solving a scheduling problem, \gls{opl} makes use of specialized interval \
 	The job shop problem is similar to the open shop problem discussed in the introduction.
 	Like the open shop problem, the goal is to schedule jobs with multiple tasks.
 	Each task must be performed by an assigned machine.
-	A machine can only perform one task at any one time.
+	A machine can only perform one task at any one time and only one task of the same job can be scheduled at the same time.
-	And, only one task of the same job can be scheduled at the same time.
 	However, in the job shop problem, the tasks within a job also have a specified order.
 	Abstracting from the \parameter{} declarations, the possible formulation of the \variable{} declarations and \constraints{} for the job shop problem in \gls{opl} is shown in \cref{lst:back-opl-jsp}.
 
@@ -977,7 +975,7 @@ When solving a scheduling problem, \gls{opl} makes use of specialized interval \
 	It instead uses integer \variables{} that represent the start times of the tasks and the end time for the \mzninline{makespan} activity that spans all tasks.
 	This means that much of the implicit behaviour of the \texttt{Activity} \variables{} has to be defined explicitly.
 	Where in the \gls{opl} model we could just state a global scheduling horizon, in \minizinc{} it has to be explicitly included in the \domains{} of the time \variables{}.
-	And, instead of a \texttt{precedes} operator, we have to explicitly enforce the precedence of tasks using linear \constraints{}.
+	Instead of a \texttt{precedes} operator, we have to explicitly enforce the precedence of tasks using linear \constraints{}.
 
 	\Gls{opl} model also has the advantage of its resource syntax.
 	It first states the resource objects and then merely has to use the \texttt{requires} keyword to force tasks on the same machine to be mutually exclusive.
@@ -1615,8 +1613,8 @@ It tries to reduce the number of Boolean \variables{} and tries to reduce the nu
 
 \section{Summary}
 
-This chapter summarized gave an overview of the background knowledge required to understand the following technical chapters.
+This chapter gave an overview of the background knowledge required to understand the following technical chapters.
-It introduced the practice of \constraints{} modelling, and the syntax of the \minizinc{} language.
+It introduced the practice of \constraint{} modelling, and the syntax of the \minizinc{} language.
 We also compared \minizinc{} to other \cmls{} and found many similarities.
 This indicates that the research presented in this thesis could be applied to these languages as well.
 By using \cmls{}, a modeller can easily express a problem for a variety of \solver{} programs.

chapters/3_rewriting.tex

@@ -8,7 +8,7 @@
 \section{Architecture Overview}
 \label{sec:rew-arch}
 
-\noindent{}\Gls{rewriting} a \minizinc{} instance into \gls{slv-mod} might often seem like a simple \gls{trs}.
+\noindent{}\Gls{rewriting} a \minizinc{} instance into \gls{slv-mod} may often seem like a simple \gls{trs}.
 In reality, however, \minizinc{} is quite a complex language, and producing a good \gls{slv-mod} is far from trivial. 
 
 Thus, in practice, this rewriting process is a highly complex task that needs to carefully track interactions between \constraints{} and how they affect \variables{}.
@@ -142,7 +142,7 @@ The translation from \minizinc{} to \microzinc{} involves the following steps.
 			if_then_else([x, true], [A, B])
 		\end{mzn}
 
-		And, an expression \mzninline{A[x]}, where \mzninline{x} is a \variable{}, is replaced by the following call.
+		An expression \mzninline{A[x]}, where \mzninline{x} is a \variable{}, is replaced by the following call.
 
 		\begin{mzn}
 			element(A, x)
@@ -198,7 +198,7 @@ The translation from \minizinc{} to \microzinc{} involves the following steps.
 		To prevent the runtime overhead of the dynamic lookup of overloaded function definitions for every call, the function dispatch in \microzinc{} is determined statically.
 
 		It is important, however, that the correct version of a function is chosen when it allows for either \variable{} and \parameter{} arguments.
-		And, as we will later discuss in more detail, is possible for a \variable{} to be \gls{fixed} to a single value during the \gls{rewriting} process.
+		As we will later discuss in more detail, is possible for a \variable{} to be \gls{fixed} to a single value during the \gls{rewriting} process.
 		At that point it can be treated as a \parameter{}.
 		To ensure the correct version of the function is used, functions are changed to, at runtime, check if a \variable{} is \gls{fixed} and, if so, dispatch to the \parameter{} version of the function.
 		If we, for example, have a \minizinc{} function \mzninline{f} that is overloaded on \mzninline{var int} and \mzninline{int}, then the \microzinc{} transformation can be described by the following two functions.

chapters/3_rewriting_preamble.tex

@@ -17,5 +17,5 @@ We show how this toolchain allows us to:
 This chapter is organized as follows.
 \Cref{sec:rew-arch} provides an overview of the proposed architecture.
 \Cref{sec:rew-micronano} introduces the core of our \gls{rewriting} system using the \microzinc{} and \nanozinc{} languages. These new languages provide a new intermediate representation that enables more efficient \gls{rewriting}.
-\Cref{sec:rew-simplification} describes how we can perform various processing and simplification steps on this representation
+\Cref{sec:rew-simplification} describes how we can perform various processing and simplification steps on this representation.
 Finally, in \cref{sec:rew-experiments} we report on the experimental results of the prototype implementation.

chapters/4_half_reif.tex

@@ -575,7 +575,7 @@ Note that the \(ctx\) of the \gls{let} itself, is irrelevant for the analysis of
 
 The inference for \constraint{} items is described by the (Con) rule.
 Since all expressions in well-formed \microzinc{} are total, the \constraint{} can be assumed to hold globally.
-And, unlike \minizinc{}, the \constraint{} is not dependent on the context of the \gls{let}.
+Unlike \minizinc{}, the \constraint{} is not dependent on the context of the \gls{let}.
 The \constraint{}'s expression is evaluated in \rootc{} context.
 
 The (Assign) rule reasons about declarations that have a right-hand side.

chapters/4_half_reif_preamble.tex

@@ -17,7 +17,6 @@ This chapter re-evaluates \gls{half-reif} and extends the \gls{rewriting} proces
 
 This chapter is organized as follows.
 In \cref{sec:half-intro,sec:half-propagation} we introduce the core concepts of \gls{half-reif} and \glspl{propagator} for \gls{half-reified} \constraints{}, as discussed by \textcite{feydy-2011-half-reif}.
-An additional benefit of \gls{half-reif} is that its \gls{decomp} can be significantly smaller than the \gls{decomp} of a \gls{reif}.
 \Cref{sec:half-decomposition} shows the benefits of \gls{half-reif} when writing \glspl{decomp} for \gls{mip} and \gls{sat} \solvers{}.
 In \cref{sec:half-context} we introduce our new context analysis algorithm: a way to determine where \gls{half-reif} can be used in \microzinc{}, and by extension \minizinc{}.
 Then, in \cref{sec:half-rewriting}, we elaborate on how using \gls{half-reif} changes the \gls{rewriting} process.

chapters/5_incremental.tex

@@ -534,7 +534,7 @@ The new items can be added to the program, and the \gls{rewriting} can proceed a
 
 Removing an item, however, is not so simple.
 A \variable{} can only be removed if it is not used in any \constraints{}.
-And, when we remove a \constraint{}, all effects the \constraint{} had on the \nanozinc{} program have to be undone.
+When we remove a \constraint{}, all effects the \constraint{} had on the \nanozinc{} program have to be undone.
 This includes results of \gls{propagation}, \gls{cse} and other simplifications.
 
 \begin{example}\label{ex:inc-incremental}

chapters/6_conclusions.tex

@@ -60,10 +60,10 @@ This could potentially lead to the ability to prove certain properties of the \g
 Additionally, the architecture introduces reasoning about the transition from \minizinc{} \instances{} to \gls{slv-mod} as two different levels: the transition from \minizinc{} to \microzinc{} and the evaluation of the \nanozinc{} program to create a \gls{slv-mod}.
 In our prototype we have presented techniques to help improve the quality of the \gls{slv-mod}, but many improvements to these techniques and other techniques may be possible.
 Finally, we use \nanozinc{} to track \constraints{} that are introduced to define a \variable{}.
-Although we have showed how this helps when a \variable{} becomes unused, we not yet investigated if the same information can help improve \solver{} performance.
+Although we have showed how this helps when a \variable{} becomes unused, we have not yet investigated if the same information can help improve \solver{} performance.
 A possible example of where this information can be useful is found in \gls{cp} \solvers{}.
 In these \solvers{}, a functionally defined \variable{} can become unused when the \constraints{} that use \variable{} have already been \gls{satisfied}, independent of its \gls{fixed} value.
-Like we can remove the defining \constraint{} during \gls{rewriting}, in a \gls{cp} \solver{} we could stop further \gls{propagation} of this \constraint{} and possibly speed up the solving.
+Similar to how we can remove the defining \constraint{} during \gls{rewriting}, in a \gls{cp} \solver{} we could stop further \gls{propagation} of this \constraint{} and possibly speed up the solving.
 
 \section*{Reasoning about Reification}
 Determining whether a \constraint{} is \gls{reified} is a crucial decision that has to be made during \gls{rewriting}.

dekker_thesis.tex

@@ -79,7 +79,7 @@ toc=bib,
 
 \chapter{Declaration}
 
-\noindent{}This thesis is an original work of my research and contains no material which has been accepted for the award of any other degree or diploma at any university or equivalent institution and that, to the best of my knowledge and belief, this thesis contains no material previously published or written by another person, except where due reference is made in the text of the thesis.
+\noindent{}This thesis is an original work of my research and contains no material which has been accepted for the award of any other degree or diploma at any university or equivalent institution and, to the best of my knowledge and belief, this thesis contains no material previously published or written by another person, except where due reference is made in the text of the thesis.
 
 \vspace{5em}