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

Final work on the incremental chapter

Browse Source
This commit is contained in:
Jip J. Dekker 2021-07-28 15:55:06 +10:00
parent 4562bb685d
commit affa257ac0
No known key found for this signature in database
GPG Key ID: 517DF4A00618C9C3
3 changed files with 79 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
assets/bibliography/references.bib
View File

@ -875,23 +875,13 @@
version = {2.5.5}, version = {2.5.5},
} }
@inproceedings{michel-2005-comet, @book{michel-2005-comet,
author = {Laurent Michel and Pascal Van Hentenryck}, author = {Van Hentenryck, Pascal and Michel, Laurent},
editor = {Peter van Beek}, title = {Constraint-Based Local Search},
title = {The Comet Programming Language and System}, year = {2005},
booktitle = {Principles and Practice of Constraint Programming - {CP} 2005, isbn = {0262220776},
11th International Conference, {CP} 2005, Sitges, Spain, October publisher = {The MIT Press},
1-5, 2005, Proceedings}, url = {https://mitpress.mit.edu/books/constraint-based-local-search},
series = {Lecture Notes in Computer Science},
volume = 3709,
pages = {881--881},
publisher = {Springer},
year = 2005,
url = {https://doi.org/10.1007/11564751_119},
doi = {10.1007/11564751_119},
timestamp = {Tue, 14 May 2019 10:00:45 +0200},
biburl = {https://dblp.org/rec/conf/cp/MichelH05a.bib},
bibsource = {dblp computer science bibliography, https://dblp.org},
} }
@article{nightingale-2017-ess-prime, @article{nightingale-2017-ess-prime,
@ -1288,6 +1278,19 @@
optimization}, optimization},
} }
@inproceedings{hentenryck-2013-objcp,
author = {Van Hentenryck, Pascal and Michel, Laurent},
title = {The Objective-CP Optimization System},
year = {2013},
booktitle = {Principles and Practice of Constraint Programming - 19th
International Conference, CP 2013, Uppsala, Sweden, September
16-20, 2013. Proceedings},
pages = {8--29},
doi = {10.1007/978-3-642-40627-0_5},
url = {http://dx.doi.org/10.1007/978-3-642-40627-0_5},
}
@book{wallis-2011-combinatorics, @book{wallis-2011-combinatorics,
title = {Introduction to Combinatorics}, title = {Introduction to Combinatorics},
author = {Wallis, W.D. and George, J.}, author = {Wallis, W.D. and George, J.},

15
assets/glossary.tex
View File

@ -182,6 +182,11 @@
} }
} }
\newglossaryentry{comet}{
name={COMET},
description={A \cml{} with advanced \gls{meta-optimization} functionality \autocite{michel-2005-comet}.}
}
\newglossaryentry{compiler}{ \newglossaryentry{compiler}{
name={compiler}, name={compiler},
description={ description={
@ -420,6 +425,11 @@
description={A function defined over the \glspl{variable} of a \gls{model} to assign a numeric value to the quality of the \gls{sol}.}, description={A function defined over the \glspl{variable} of a \gls{model} to assign a numeric value to the quality of the \gls{sol}.},
} }
\newglossaryentry{obj-cp}{
name={Objective-CP},
description={A library for the Objective-C programming language to provide constraint modelling functionality\autocite{hentenryck-2013-objcp}.},
}
\newglossaryentry{openwbo}{ \newglossaryentry{openwbo}{
name={OpenWBO}, name={OpenWBO},
description={A well-known \gls{maxsat} \gls{solver} \autocite{martins-2014-openwbo}.}, description={A well-known \gls{maxsat} \gls{solver} \autocite{martins-2014-openwbo}.},
@ -481,6 +491,11 @@
} }
} }
\newglossaryentry{search-comb}{
name={search combinators},
description={A language extension proposed for \cmls{} that allows the modeller to describe search conducted by the \solver{} \autocite{schrijvers-2013-combinators}.}
}
\newglossaryentry{search-decision}{ \newglossaryentry{search-decision}{
name={search decision}, name={search decision},
description={ description={

69
chapters/5_incremental.tex
View File

@ -9,45 +9,61 @@
\section{An Introduction to Meta-Optimization} \section{An Introduction to Meta-Optimization}
\todo{Expand and finalize this section.} There are many different kinds of \gls{meta-optimization} algorithms.
Examples of these methods are: They share neither a goal or an exact method.
However, they can often be described through the use of incremental \constraint{} modelling.
Each algorithm solves an \instance{}, adds new \constraints{}, the resulting \instance{} is solved again, and the \constraints{} may be removed again.
This process is repeated until the goal of the \gls{meta-optimization} algorithm is reached.
\begin{itemize} The following algorithms are examples of \gls{meta-optimization}.
\item Multi-objective search \autocite{jones-2002-multi-objective}.
\begin{description}
\item[Multi-objective search]\autocite{jones-2002-multi-objective}
Optimizing multiple \glspl{objective} is often not supported directly in solvers. Optimizing multiple \glspl{objective} is often not supported directly in solvers.
Instead, it can be achieved using a \gls{meta-optimization} approach: find a \gls{sol} to a (single-objective) problem, then add more \constraints{} to the original problem and repeat. Instead, it can be achieved using a \gls{meta-optimization} approach: find a \gls{sol} to a (single-objective) problem, then add more \constraints{} to the original problem and repeat.
\item \gls{lns} \autocite{shaw-1998-local-search}. \item[\gls{lns}] \autocite{shaw-1998-local-search}
This is a very successful \gls{meta-optimization} algorithm to quickly improve \gls{sol} quality. This is a very successful \gls{meta-optimization} algorithm to quickly improve \gls{sol} quality.
After finding a (sub-optimal) \gls{sol} to a problem, \constraints{} are added to restrict the search in the \gls{neighbourhood} of that \gls{sol}. After finding a (sub-optimal) \gls{sol} to a problem, \constraints{} are added to restrict the search in the \gls{neighbourhood} of that \gls{sol}.
When a new \gls{sol} is found, the \constraints{} are removed, and \constraints{} for a new \gls{neighbourhood} are added. When a new \gls{sol} is found, the \constraints{} are removed, and \constraints{} for a new \gls{neighbourhood} are added.
\item Online Optimization \autocite{jaillet-2021-online}. \item[Online Optimization]\autocite{jaillet-2021-online}
These techniques can be employed when the problem rapidly changes. These techniques can be employed when the problem rapidly changes.
An \instance{} is continuously updated with new data, such as newly available jobs to be scheduled or customer requests to be processed. An \instance{} is continuously updated with new data, such as newly available jobs to be scheduled or customer requests to be processed.
\item Diverse \Gls{sol} Search \autocite{hebrard-2005-diverse}. \item[Diverse \Gls{sol} Search]\autocite{hebrard-2005-diverse}
Here we aim to provide a set of \glspl{sol} that are sufficiently different from each other in order to give human decision makers an overview of the possible \glspl{sol}. Here we aim to provide a set of \glspl{sol} that are sufficiently different from each other in order to give human decision makers an overview of the possible \glspl{sol}.
Diversity can be achieved by repeatedly solving a problem instance with different \glspl{objective}. Diversity can be achieved by repeatedly solving a problem instance with different \glspl{objective}.
\item Interactive Optimization \autocite{belin-2014-interactive}. \item[Interactive Optimization]\autocite{belin-2014-interactive}
In some scenarios it can be useful to allow a user to directly provide feedback on \glspl{sol} found by the \solver{}. In some scenarios it can be useful to allow a user to directly provide feedback on \glspl{sol} found by the \solver{}.
The feedback in the form of \constraints{} are added back into the problem, and a new \gls{sol} is generated. The feedback in the form of \constraints{} are added back into the problem, and a new \gls{sol} is generated.
Users may also take back some earlier feedback and explore different aspects of the problem to arrive at the best \gls{sol} that suits their needs. Users may also take back some earlier feedback and explore different aspects of the problem to arrive at the best \gls{sol} that suits their needs.
\end{description}
The usage of \gls{meta-optimization} algorithms is not new to \cmls{}.
Languages such as \gls{opl} and \gls{comet} \autocite{michel-2005-comet} language, later succeeded by the \gls{obj-cp} library \autocite{hentenryck-2013-objcp}, provide convenient syntax for programmable search for their target \solvers{}.
Crucially, \gls{comet} the first system to introduce the notion of applying new \constraints{} on \gls{restart}.
A \gls{restart} happens when a solver abandons its current search efforts, returns to its initial \gls{search-space}, and begins a new exploration.
In many (\gls{cp}) \solvers{} it is possible to add new \constraints{} upon restarting that are only valid for the particular \gls{restart}.
Many \gls{meta-optimization} algorithms can be implemented using only this technique.
Even though \minizinc{} does not have explicit support for programmable search, \gls{meta-optimization} algorithms have been successfully applied to the language.
\begin{itemize}
\item \textcite{schiendorfer-2018-minibrass} use \gls{meta-optimization} algorithms to solve \minizinc{} \instances{} that have been extended to contain soft-\constraints{}.
\item \textcite{ingmar-2020-diverse} implement \gls{meta-optimization} algorithms to explore the diversity of \glspl{sol} for \minizinc{} models.
\item \textcite{ek-2020-online} extend \minizinc{} to model and solve online optimization problems using \gls{meta-optimization}.
\end{itemize} \end{itemize}
All of these examples have in common that an \instance{} is solved, new \constraints{} are added, the resulting \instance{} is solved again, and the \constraints{} may be removed again.
The usage of these algorithms is not new to \cmls{}, and they have proven to be very useful \autocite{schrijvers-2013-combinators, rendl-2015-minisearch, schiendorfer-2018-minibrass, ek-2020-online, ingmar-2020-diverse}.
In its most basic form, a simple scripting language is sufficient to implement these algorithms, by repeatedly \gls{rewriting} and solving the adjusted \instances{}. In its most basic form, a simple scripting language is sufficient to implement these algorithms, by repeatedly \gls{rewriting} and solving the adjusted \instances{}.
For some applications the runtime required to repeatedly rewrite the \instance{} can be prohibitive.
\todo{Here we also need to discuss Comet and Objective CP: ``I think this chapter needs to refer to Comet and Objective CP. Those are both modelling languages (or libraries) with explicit support for meta optimization. I'm not sure how much has been published, but I think the idea of doing something on restart is definitely coming from Comet.'' — Guido} Approaches such as \gls{search-comb} \autocite{schrijvers-2013-combinators} and \minisearch{} \autocite{rendl-2015-minisearch} have been proposed to reduce this overhead and ease the use of \gls{meta-optimization} in \minizinc{}.
However, these approaches were found hard to implement and maintain, and were never adopted into \minizinc{}
\section{Modelling of Restart Based Meta-Optimization}\label{sec:inc-modelling} \section{Modelling of Restart Based Meta-Optimization}\label{sec:inc-modelling}
This section introduces a \minizinc{} extension that enables modellers to define \gls{meta-optimization} algorithms in \minizinc{}. This section introduces a \minizinc{} extension that enables modellers to define \gls{meta-optimization} algorithms in \minizinc{}.
This extension is based on the constructs introduced in \minisearch{} \autocite{rendl-2015-minisearch}, as summarized below. This extension is based on the constructs introduced in \minisearch{}, as summarized below.
\subsection{Meta-Optimization in MiniSearch}\label{sec:inc-minisearch} \subsection{Meta-Optimization in MiniSearch}\label{sec:inc-minisearch}
@ -108,7 +124,7 @@ Instead of the complex \minisearch{} definitions, we propose to add support for
A \gls{restart} happens when a solver abandons its current search efforts, returns to its initial \gls{search-space}, and begins a new exploration. A \gls{restart} happens when a solver abandons its current search efforts, returns to its initial \gls{search-space}, and begins a new exploration.
Many \gls{cp} \solvers{} already provide support for controlling their restarting behaviour. Many \gls{cp} \solvers{} already provide support for controlling their restarting behaviour.
They can periodically restart after a certain number of nodes, or restart for every \gls{sol}. They can periodically restart after a certain number of nodes, or restart for every \gls{sol}.
Typically, \solvers{} also support posting additional \constraints{} upon restarting that are only valid for the particular \gls{restart} (e.g., Comet \autocite{michel-2005-comet}). Typically, \solvers{} also support posting additional \constraints{} upon restarting that are only valid for the particular \gls{restart}.
These \constraints{} are ``retracted'' for the next \gls{restart}. These \constraints{} are ``retracted'' for the next \gls{restart}.
In its simplest form, we can therefore implement \gls{lns} by merely specifying a \gls{neighbourhood} predicate. In its simplest form, we can therefore implement \gls{lns} by merely specifying a \gls{neighbourhood} predicate.
@ -500,17 +516,19 @@ Furthermore, it is not strictly necessary to guard \mzninline{int_uniform} again
The \mzninline{sol} \constraints{} will simply not propagate anything until the first \gls{sol} is recorded, but we use this simple example to illustrate how these Boolean conditions are rewritten and evaluated. The \mzninline{sol} \constraints{} will simply not propagate anything until the first \gls{sol} is recorded, but we use this simple example to illustrate how these Boolean conditions are rewritten and evaluated.
In \cref{sec:inc-experiments} we assess the performance of \gls{rbmo}, which can be used when supported by the target \solver{}. In \cref{sec:inc-experiments} we assess the performance of \gls{rbmo}, which can be used when supported by the target \solver{}.
In the next section, we discuss how \gls{meta-optimization} can still be efficiently applied through the use of \gls{incremental-rewriting}. In the next section, we discuss how \gls{meta-optimization} can still be efficiently applied even without an extended \solver{}, through the use of \gls{incremental-rewriting}.
\section{An Incremental Constraint Modelling Interface}% \section{An Incremental Constraint Modelling Interface}%
\label{sec:inc-incremental-compilation} \label{sec:inc-incremental-compilation}
A universal approach to the incremental usage of \cmls{}, and \gls{meta-optimization}, is to allow incremental changes to an \instance{} of a \cmodel{}. A common approach to implementing \gls{meta-optimization} algorithms using \cmls{} is through \gls{incremental-rewriting}.
We allow an \gls{meta-optimization} algorithm, implemented in \minisearch{} or a scripting language, to make incremental changes to an \instance{} of a \cmodel{}.
To solve these changing \instances{}, they have to be rewritten repeatedly to \glspl{slv-mod}. To solve these changing \instances{}, they have to be rewritten repeatedly to \glspl{slv-mod}.
In this section we extend our architecture with an incremental constraint modelling interface that allows the modeller to change an \instance{}.
For changes made using this interface, the architecture can employ \gls{incremental-rewriting} to minimize the required \gls{rewriting}.
As such, the \microzinc{} \interpreter{} is extended to be able to \textbf{add} and \textbf{remove} \nanozinc{} \constraints{} and \variables{} from/to an existing \nanozinc{} program. In this section we extend our architecture with an incremental constraint modelling interface that accommodates \gls{incremental-rewriting}.
Changes that are made using this interface will require only minimal additional \gls{rewriting}.
The \microzinc{} \interpreter{} is extended to be able to \textbf{add} and \textbf{remove} \nanozinc{} \constraints{} and \variables{} from/to an existing \nanozinc{} program.
Adding new \constraints{} and \variables{} is straightforward. Adding new \constraints{} and \variables{} is straightforward.
\nanozinc{} is already processed one item at a time, in any order. \nanozinc{} is already processed one item at a time, in any order.
The new items can be added to the program, and the \gls{rewriting} can proceed as normal. The new items can be added to the program, and the \gls{rewriting} can proceed as normal.
@ -531,7 +549,7 @@ This includes results of \gls{propagation}, \gls{cse} and other simplifications.
After evaluating the first \constraint{}, the \domain{} of \mzninline{x} is changed to be less than ten. After evaluating the first \constraint{}, the \domain{} of \mzninline{x} is changed to be less than ten.
Evaluating the second \constraint{} causes the \domain{} of \mzninline{y} to be less than nine. Evaluating the second \constraint{} causes the \domain{} of \mzninline{y} to be less than nine.
If we now, however, try to remove the first \constraint{}, then it is not just the direct inference on the \domain{} of \mzninline{x} that has to be undone. If we now, however, try to remove the first \constraint{}, then it is not just the direct inference on the \domain{} of \mzninline{x} that has to be undone.
All consequent effects of those changes, in this case, the changes to the \domain{} of \mzninline{y}, also have to be changed back. All consequent effects, in this case, the changes to the \domain{} of \mzninline{y}, also have to be reversed.
\end{example} \end{example}
@ -575,14 +593,15 @@ In particular, this means that until the first choice point is created \gls{rewr
The following code fragment illustrates the elements in this \gls{trail}. The following code fragment illustrates the elements in this \gls{trail}.
The reversal actions are annotated on the different elements. The reversal actions are annotated on the different elements.
The \mzninline{attach} and \mzninline{detach} actions signal the \interpreter{} to attach/detach a \constraint{} to the argument \variable{}, or the global \cmodel{} in case the argument is the value \true{}. The \mzninline{attach} and \mzninline{detach} actions signal the \interpreter{} to attach/detach a \constraint{} to the argument \variable{}, or the global \cmodel{} in case the argument is the value \true{}.
The \mzninline{add} action tells the \interpreter{} to add a \variable{} to the \nanozinc{} program. The \mzninline{add} action adds a \variable{} to the \nanozinc{} program.
Finally, the \mzninline{set_domain} action makes the \interpreter{} restore the \domain{} using declaration to which it was attached. Finally, the \mzninline{restore_domain} action replaces the variable declaration in the \nanozinc{} program.
This restores the \domain{} to its previous value.
\begin{nzn} \begin{nzn}
% Posted c % Posted c
constraint c ::detach(true); constraint c ::detach(true);
% Propagated c = true % Propagated c = true
var bool: c ::set_domain; var bool: c ::restore_domain;
constraint c ::attach(true); constraint c ::attach(true);
% Simplified bool_or(b1, true) = true % Simplified bool_or(b1, true) = true
constraint bool(b1, c) ::attach(true); constraint bool(b1, c) ::attach(true);