80 lines
4.9 KiB
TeX
80 lines
4.9 KiB
TeX
\noindent{}In previous chapters we explored the compilation of constraint models for a
|
|
\gls{solver} as a definitive linear process, but to solve real-world problems
|
|
\gls{meta-search} algorithms are often used. These methods usually require
|
|
solving almost the same combinatorial problem repeatedly, with only slight
|
|
modifications, thousands of times. Examples of these methods are:
|
|
|
|
\begin{itemize}
|
|
\item Multi-objective search \autocite{jones-2002-multi-objective}. Optimising
|
|
multiple objectives is often not supported directly in solvers. Instead,
|
|
it can be solved using a \gls{meta-search} approach: find a solution to
|
|
a (single-objective) problem, then add more constraints to the original
|
|
problem and repeat.
|
|
\item \gls{lns} \autocite{shaw-1998-local-search}. This is a very successful
|
|
\gls{meta-search} algorithm to quickly improve solution quality. After
|
|
finding a (sub-optimal) solution to a problem, constraints are added to
|
|
restrict the search in the \gls{neighbourhood} of that solution. When a
|
|
new solution is found, the constraints are removed, and constraints for
|
|
a new \gls{neighbourhood} are added.
|
|
\item Online Optimisation \autocite{jaillet-2021-online}. These techniques can
|
|
be employed when the problem rapidly changes. A problem instance is
|
|
continuously updated with new data, such as newly available jobs to be
|
|
scheduled or customer requests to be processed.
|
|
\item Diverse Solution Search \autocite{hebrard-2005-diverse}. Here we aim to
|
|
provide a set of solutions that are sufficiently different from each
|
|
other in order to give human decision makers an overview of the solution
|
|
space. Diversity can be achieved by repeatedly solving a problem
|
|
instance with different objectives.
|
|
\item Interactive Optimisation \autocite{belin-2014-interactive}. In some
|
|
scenarios it might be useful to allow a user to directly provide
|
|
feedback on solutions found by the solver. The feedback in the form of
|
|
constraint are added back into the problem, and a new solution is
|
|
generated. Users may also take back some earlier feedback and explore
|
|
different aspects of the problem to arrive at the best solution that
|
|
suits their needs.
|
|
\end{itemize}
|
|
|
|
All of these examples have in common that a problem instance is solved, new
|
|
constraints are added, the resulting instance is solved again, and constraints
|
|
may be removed again.
|
|
|
|
The usage of these methods is not new to \gls{constraint-modelling}, 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 methods, by repeatedly calling on the
|
|
\gls{constraint-modelling} infrastructure to compile and solve the adjusted
|
|
constraint models. While improvements of the compilation of constraint models,
|
|
such as the ones discussed in previous chapters, can increase the performance of
|
|
these approaches, the overhead of re-compiling an almost identical model may
|
|
still prove prohibitive, warranting direct support from the
|
|
\gls{constraint-modelling} infrastructure. In this chapter we introduce two
|
|
methods to provide this support:
|
|
|
|
\begin{itemize}
|
|
\item We introduce the notion of restart-based \gls{meta-search} algorithms.
|
|
Using a minimal extension to a \cml\ and its target solver, we can model
|
|
some \gls{meta-search} algorithms and compile \gls{meta-search}
|
|
algorithms into efficient solver-level specifications based on solver
|
|
restarts, avoiding re-compilation all-together.
|
|
\item Alternatively, we can add an incremental interface for adding and
|
|
removing constraints to the infrastructure of the \cml{}. Although this
|
|
does not avoid the need for re-compilation, it can reduce the work to
|
|
only the part of the constraint model that has changed. This approach
|
|
can be used when an algorithm cannot be described using restart-based
|
|
\gls{meta-search} or required extension is not available for the solver.
|
|
\end{itemize}
|
|
|
|
The rest of the chapter is organised as follows. \Cref{sec:6-modelling}
|
|
discusses the declarative modelling of restart-based \gls{meta-search}
|
|
algorithms that can be modelled directly in a \cml{}.
|
|
\Cref{sec:6-solver-extension} introduces the method to compile these
|
|
\gls{meta-search} specifications into efficient solver-level specifications that
|
|
only require a small extension of existing \glspl{solver}.
|
|
\Cref{sec:6-incremental-compilation} introduces the alternative method that
|
|
extends the \gls{constraint-modelling} infrastructure with an interface to add
|
|
and remove constraints from an existing model while avoiding recompilation.
|
|
\Cref{sec:6-experiments} reports on the experimental results of both approaches.
|
|
Finally, \Cref{sec:6-conclusion} presents the conclusions.
|
|
|