Jip Dekker's PhD Thesis
0
fork

Configure Feed

Select the types of activity you want to include in your feed.

Morning editing

+28 -34
+13 -16
chapters/1_introduction.tex
··· 3 3 %************************************************ 4 4 5 5 \noindent{}A \gls{dec-prb} is any problem that requires us to make decisions according to a set of rules. 6 - Many important and difficult problems in the real world are \glspl{dec-prb}. 7 - We can think, for instance, about the decisions on the country's rail timetable or the stand-by locations for ambulances in the region. 6 + 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. 8 7 Formally, we define a \gls{dec-prb} as a set of \variables{} subject to a set of logical \constraints{}. 9 8 A \gls{sol} to such a problem is the \gls{assignment} of all \variables{} to values that abide by the logic of the \constraints{}. 10 9 These problems are also highly computationally complex: even with the fastest computers, finding a solution can take a long time. 11 10 They get even more complex when we consider \glspl{opt-prb}: if there are multiple solutions, then one may be preferred over the other. 12 - But, although these problems are hard to solve, finding a (good) solution for these problems is essential in many walks of life. 11 + Although these problems are hard to solve, finding a (good) solution for these problems is essential in many walks of life. 13 12 14 13 The field of \gls{or} uses advanced computational methods to help make (better) decisions. 15 14 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. 16 - And, over the years, highly specialized \solvers{} have been created to find \glspl{sol} for these classes of problems. 15 + Over the years, highly specialized \solvers{} have been created to find \glspl{sol} for these classes of problems. 17 16 Nowadays, most decision and \glspl{opt-prb} are solved by encoding them into one of the above-mentioned classes of problems. 18 17 19 18 Encoding one problem in terms of another is, however, a difficult task. ··· 22 21 For example, \gls{sat} \solvers{} can only reason about Boolean \variables{}, deciding if something is true or false. 23 22 \Constraints{} for \gls{sat} \solvers{} have to be in the form of disjunctions of Boolean \variables{}, or their negations. 24 23 25 - But, not only does the encoding have to be correct, the encoding also has to be performant. 24 + Not only does the encoding have to be correct, the encoding also has to be performant. 26 25 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{}. 27 26 Two \solvers{} designed to solve the same problem class can perform very differently. 28 27 ··· 32 31 Instead of providing a flat list of \variables{} and \constraints{}, a modeller creates a \cmodel{} using the more natural syntax of the \cml{}. 33 32 A \cmodel{} can generally describe a class of problems through the use of \prbpars{}: values assigned by external input. 34 33 Once given a complete \gls{assignment} of the \prbpars{}, the \cmodel{} forms an \instance{}. 35 - The \gls{rewriting} process of a \cml{} transforms a \cmodel{} into a \gls{slv-mod}: the encoding of the problem for the \solver{}. 34 + The \gls{rewriting} process of a \cml{} transforms an \instance{} into a \gls{slv-mod}: the encoding of the problem for the \solver{}. 36 35 37 36 \begin{figure} 38 37 \centering 39 38 \includegraphics[width=\columnwidth]{assets/img/intro_cml_flow} 40 - \caption{\label{fig:intro-cml-flow}A flow diagram of typical process of a \cml{}.} 39 + \caption{\label{fig:intro-cml-flow}A flow diagram of the typical process of using a \cml{}.} 41 40 \end{figure} 42 41 43 42 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{}. 44 43 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. 45 44 46 - 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{}. 45 + 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{}. 47 46 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{}. 48 47 The downside of \gls{clp} languages is that, because of its search mechanism, the \solver{} is tightly integrated within the \gls{rewriting}. 49 48 These languages thus lack the \solver{}-independence of \cmls{}. ··· 81 80 Let us introduce the \glsxtrshort{ampl} language by modelling the ``open shop'' problem. 82 81 In the open shop problem, the goal is to schedule jobs with multiple tasks. 83 82 Each task must be performed by an assigned machine. 84 - A machine can only perform one task at any one time. 85 - And, only one task of the same job can be scheduled at the same time. 83 + 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. 86 84 We assume that each job has a task for every machine. 87 85 As an \gls{opt-prb}, our goal is to find a schedule that minimizes the finishing time of the last task. 88 86 ··· 107 105 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. 108 106 109 107 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. 110 - They do not provide any way to capture common concepts. 111 - And, apart from changing the implementation of \glsxtrshort{opl} or \gls{essence}, the \solver{} is unable to influence their preferred encoding. 108 + 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. 112 109 113 110 \gls{clp}, as used for example in the \gls{sicstus} language, offers a very different mechanism to create a \cmodel{}. 114 111 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 132 Instead, it enforces one, tests if this works, and otherwise it enforces the other. 136 133 137 134 This is a powerful mechanism where choices are made in the \gls{rewriting} process, and not in the \solver{}. 138 - The problem with the mechanism is that it requires a highly incremental interface with the \solver{} that can incrementally post and retract \constraints{}. 135 + The problem with the mechanism is that it requires a highly incremental interface to the \solver{} that can incrementally post and retract \constraints{}. 139 136 \Solvers{} are also not always able to verify if a certain set of \constraints{} is consistent. 140 137 This makes the behaviour of the \gls{clp} program dependent on the \solver{} that is used. 141 138 As such, a \gls{clp} program is not \solver{}-independent. ··· 174 171 predicate bool_or(var bool: x, var bool: y); 175 172 \end{mzn} 176 173 177 - The functional paradigm employed by \minizinc{} has shown itself to be powerful and flexible for the modeller and \solver{} 174 + The functional paradigm employed by \minizinc{} has shown itself to be powerful and flexible for modeller and \solver{}. 178 175 However, the performance of the functional evaluation of the language can be a limiting factor. 179 176 180 177 \section{Why Rewriting MiniZinc is Difficult} ··· 193 190 194 191 \item The existing implementation of \minizinc{} is inefficient. 195 192 It does a surprisingly large amount of work for each expression (especially resolving sub-typing and overloading), which may be repeated many times. 196 - And as models generated for low-level \solver{} technologies can be quite large, the resulting \gls{rewriting} procedure can be intolerably slow. 193 + This means that, as models generated for low-level \solver{} technologies can be quite large, the resulting \gls{rewriting} procedure can be intolerably slow. 197 194 As the model transformations implemented in \minizinc{} become more sophisticated, these performance problems are simply magnified. 198 195 199 196 \item The generated models often contain unnecessary \constraints{}. ··· 205 202 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. 206 203 It is possible, however, that further \gls{rewriting} can reveal a \gls{reif} to be unnecessary. 207 204 The current \minizinc{} implementation cannot reverse any \gls{reif} decisions once they are made. 208 - And, it also does not consider \gls{half-reif}, a cheaper alternative to \gls{reif} that is often applicable. 205 + It also does not consider \gls{half-reif}, a cheaper alternative to \gls{reif} that is often applicable. 209 206 210 207 \item Monolithic \gls{rewriting} is wasteful. 211 208 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.
+6 -8
chapters/2_background.tex
··· 53 53 54 54 In these equations \(S\) is a set \variable{}. 55 55 It represents the selection of toys to be packed for the trip. 56 - The \gls{objective} evaluates the quality of the \gls{sol} through the \variable{} \(z\). 57 - And, \(z\) is bound to the amount of joy that the selection of toys will bring. 56 + 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. 58 57 This is to be maximized. 59 58 The \prbpars{} \(T\) is the set of all available toys. 60 59 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 157 Note that these items already refer to \minizinc{} expressions, which will be discussed in \cref{subsec:back-mzn-expr}. 159 158 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}. 160 159 \textcite{nethercote-2007-minizinc} offer a detailed discussion of \minizinc{}. 161 - And, much of its history can be learned from the description of its predecessor, \zinc{} \autocite{marriott-2008-zinc}. 160 + Much of \minizinc{}'s history can be learned from the description of its predecessor, \zinc{} \autocite{marriott-2008-zinc}. 162 161 163 162 \paragraph{Variable Declaration Items} Variables are declared using variable declaration items. 164 163 The term ``variable'' has two overlapping, and slightly confusing meanings. ··· 938 937 The job shop problem is similar to the open shop problem discussed in the introduction. 939 938 Like the open shop problem, the goal is to schedule jobs with multiple tasks. 940 939 Each task must be performed by an assigned machine. 941 - A machine can only perform one task at any one time. 942 - And, only one task of the same job can be scheduled at the same time. 940 + 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. 943 941 However, in the job shop problem, the tasks within a job also have a specified order. 944 942 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}. 945 943 ··· 977 975 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. 978 976 This means that much of the implicit behaviour of the \texttt{Activity} \variables{} has to be defined explicitly. 979 977 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{}. 980 - And, instead of a \texttt{precedes} operator, we have to explicitly enforce the precedence of tasks using linear \constraints{}. 978 + Instead of a \texttt{precedes} operator, we have to explicitly enforce the precedence of tasks using linear \constraints{}. 981 979 982 980 \Gls{opl} model also has the advantage of its resource syntax. 983 981 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 1613 1616 1614 \section{Summary} 1617 1615 1618 - This chapter summarized gave an overview of the background knowledge required to understand the following technical chapters. 1619 - It introduced the practice of \constraints{} modelling, and the syntax of the \minizinc{} language. 1616 + This chapter gave an overview of the background knowledge required to understand the following technical chapters. 1617 + It introduced the practice of \constraint{} modelling, and the syntax of the \minizinc{} language. 1620 1618 We also compared \minizinc{} to other \cmls{} and found many similarities. 1621 1619 This indicates that the research presented in this thesis could be applied to these languages as well. 1622 1620 By using \cmls{}, a modeller can easily express a problem for a variety of \solver{} programs.
+3 -3
chapters/3_rewriting.tex
··· 8 8 \section{Architecture Overview} 9 9 \label{sec:rew-arch} 10 10 11 - \noindent{}\Gls{rewriting} a \minizinc{} instance into \gls{slv-mod} might often seem like a simple \gls{trs}. 11 + \noindent{}\Gls{rewriting} a \minizinc{} instance into \gls{slv-mod} may often seem like a simple \gls{trs}. 12 12 In reality, however, \minizinc{} is quite a complex language, and producing a good \gls{slv-mod} is far from trivial. 13 13 14 14 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 142 if_then_else([x, true], [A, B]) 143 143 \end{mzn} 144 144 145 - And, an expression \mzninline{A[x]}, where \mzninline{x} is a \variable{}, is replaced by the following call. 145 + An expression \mzninline{A[x]}, where \mzninline{x} is a \variable{}, is replaced by the following call. 146 146 147 147 \begin{mzn} 148 148 element(A, x) ··· 198 198 To prevent the runtime overhead of the dynamic lookup of overloaded function definitions for every call, the function dispatch in \microzinc{} is determined statically. 199 199 200 200 It is important, however, that the correct version of a function is chosen when it allows for either \variable{} and \parameter{} arguments. 201 - 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. 201 + 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. 202 202 At that point it can be treated as a \parameter{}. 203 203 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. 204 204 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.
+1 -1
chapters/3_rewriting_preamble.tex
··· 17 17 This chapter is organized as follows. 18 18 \Cref{sec:rew-arch} provides an overview of the proposed architecture. 19 19 \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}. 20 - \Cref{sec:rew-simplification} describes how we can perform various processing and simplification steps on this representation 20 + \Cref{sec:rew-simplification} describes how we can perform various processing and simplification steps on this representation. 21 21 Finally, in \cref{sec:rew-experiments} we report on the experimental results of the prototype implementation.
+1 -1
chapters/4_half_reif.tex
··· 575 575 576 576 The inference for \constraint{} items is described by the (Con) rule. 577 577 Since all expressions in well-formed \microzinc{} are total, the \constraint{} can be assumed to hold globally. 578 - And, unlike \minizinc{}, the \constraint{} is not dependent on the context of the \gls{let}. 578 + Unlike \minizinc{}, the \constraint{} is not dependent on the context of the \gls{let}. 579 579 The \constraint{}'s expression is evaluated in \rootc{} context. 580 580 581 581 The (Assign) rule reasons about declarations that have a right-hand side.
-1
chapters/4_half_reif_preamble.tex
··· 17 17 18 18 This chapter is organized as follows. 19 19 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}. 20 - An additional benefit of \gls{half-reif} is that its \gls{decomp} can be significantly smaller than the \gls{decomp} of a \gls{reif}. 21 20 \Cref{sec:half-decomposition} shows the benefits of \gls{half-reif} when writing \glspl{decomp} for \gls{mip} and \gls{sat} \solvers{}. 22 21 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{}. 23 22 Then, in \cref{sec:half-rewriting}, we elaborate on how using \gls{half-reif} changes the \gls{rewriting} process.
+1 -1
chapters/5_incremental.tex
··· 534 534 535 535 Removing an item, however, is not so simple. 536 536 A \variable{} can only be removed if it is not used in any \constraints{}. 537 - And, when we remove a \constraint{}, all effects the \constraint{} had on the \nanozinc{} program have to be undone. 537 + When we remove a \constraint{}, all effects the \constraint{} had on the \nanozinc{} program have to be undone. 538 538 This includes results of \gls{propagation}, \gls{cse} and other simplifications. 539 539 540 540 \begin{example}\label{ex:inc-incremental}
+2 -2
chapters/6_conclusions.tex
··· 60 60 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}. 61 61 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. 62 62 Finally, we use \nanozinc{} to track \constraints{} that are introduced to define a \variable{}. 63 - 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. 63 + 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. 64 64 A possible example of where this information can be useful is found in \gls{cp} \solvers{}. 65 65 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. 66 - 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. 66 + 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. 67 67 68 68 \section*{Reasoning about Reification} 69 69 Determining whether a \constraint{} is \gls{reified} is a crucial decision that has to be made during \gls{rewriting}.
+1 -1
dekker_thesis.tex
··· 79 79 80 80 \chapter{Declaration} 81 81 82 - \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. 82 + \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. 83 83 84 84 \vspace{5em} 85 85