Fix references
This commit is contained in:
parent
f470a1c61d
commit
da2158ab87
@ -458,7 +458,7 @@
|
||||
description={
|
||||
A technique to apply \gls{meta-optimisation} methods within the \gls{solver}.
|
||||
The \gls{solver} is extended with \gls{native} \glspl{constraint} that set \glspl{variable} to a \gls{fixed} value on every \gls{restart}.
|
||||
See \cref{sec:6-modelling,sec:6-solver-extension}
|
||||
See \cref{sec:inc-modelling,sec:inc-solver-extension}
|
||||
},
|
||||
}
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 23 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB |
@ -1,28 +0,0 @@
|
||||
toys_joy = [63, 12, 50, 100]
|
||||
toys_space = [32, 8, 16, 40]
|
||||
space_left = 64
|
||||
|
||||
num_toys = len(toys_joy)
|
||||
# Initialise an empty table
|
||||
table = [
|
||||
[0 for x in range(space_left + 1)]
|
||||
for x in range(num_toys + 1)
|
||||
]
|
||||
for i in range(num_toys + 1):
|
||||
for j in range(space_left + 1):
|
||||
# If we are out of space or toys we cannot choose a toy
|
||||
if i == 0 or j == 0:
|
||||
table[i][j] = 0
|
||||
# If there is space for the toy, then compare the joy of
|
||||
# picking this toy over picking the next toy with more
|
||||
# space left
|
||||
elif toys_space[i - 1] <= j:
|
||||
table[i][j] = max(
|
||||
toys_joy[i - 1] + table[i - 1][j - wt[i - 1]],
|
||||
table[i - 1][j],
|
||||
)
|
||||
# Otherwise, consider the next toy
|
||||
else:
|
||||
table[i][j] = table[i - 1][j]
|
||||
|
||||
optimal_joy = table[num_toys][space_left]
|
||||
@ -7,12 +7,12 @@
|
||||
|
||||
\input{chapters/5_incremental_preamble}
|
||||
|
||||
\section{Modelling of Restart Based Meta-Optimisation}\label{sec:6-modelling}
|
||||
\section{Modelling of Restart Based Meta-Optimisation}\label{sec:inc-modelling}
|
||||
|
||||
This section introduces a \minizinc{} extension that enables modellers to define \gls{meta-optimisation} algorithms in \minizinc{}.
|
||||
This extension is based on the construct introduced in \minisearch{} \autocite{rendl-2015-minisearch}, as summarised below.
|
||||
|
||||
\subsection{Meta-Optimisation in MiniSearch}\label{sec:6-minisearch}
|
||||
\subsection{Meta-Optimisation in MiniSearch}\label{sec:inc-minisearch}
|
||||
|
||||
\minisearch{} introduced a \minizinc{} extension that enables modellers to express \gls{meta-optimisation} inside a \minizinc{} model.
|
||||
A \gls{meta-optimisation} algorithm in \minisearch{} typically solves a given \minizinc{} model, performs some calculations on the solution, adds new \constraints{} and then solves again.
|
||||
@ -29,23 +29,23 @@ It returns the value that variable \mzninline{x} was assigned to in the previous
|
||||
This allows the \gls{neighbourhood} to be defined in terms of the previous \gls{sol}.
|
||||
In addition, a \gls{neighbourhood} definition will typically make use of the random number generators available in \minizinc{}.
|
||||
|
||||
\Cref{lst:6-lns-minisearch-pred} shows a simple random \gls{neighbourhood}.
|
||||
\Cref{lst:inc-lns-minisearch-pred} shows a simple random \gls{neighbourhood}.
|
||||
For each decision variable \mzninline{x[i]}, it draws a random number from a uniform distribution.
|
||||
If it exceeds threshold \mzninline{destr_rate}, then it posts \constraints{} forcing \mzninline{x[i]} to take the same value from previous \gls{sol}.
|
||||
For example, \mzninline{uniform_neighbourhood(x, 0.2)} would result in each variable in the \gls{array} \mzninline{x} having a 20\% chance of being unconstrained, and an 80\% chance of being assigned to the value it had in the previous \gls{sol}.
|
||||
|
||||
\begin{listing}
|
||||
\mznfile{assets/listing/6_lns_minisearch_pred.mzn}
|
||||
\caption{\label{lst:6-lns-minisearch-pred} A simple random \gls{lns} predicate implemented in \minisearch{}}
|
||||
\mznfile{assets/listing/inc_lns_minisearch_pred.mzn}
|
||||
\caption{\label{lst:inc-lns-minisearch-pred} A simple random \gls{lns} predicate implemented in \minisearch{}}
|
||||
\end{listing}
|
||||
|
||||
\begin{listing}
|
||||
\mznfile{assets/listing/6_lns_minisearch.mzn}
|
||||
\caption{\label{lst:6-lns-minisearch} A simple \gls{lns} \gls{meta-optimisation} implemented in \minisearch{}}
|
||||
\mznfile{assets/listing/inc_lns_minisearch.mzn}
|
||||
\caption{\label{lst:inc-lns-minisearch} A simple \gls{lns} \gls{meta-optimisation} implemented in \minisearch{}}
|
||||
\end{listing}
|
||||
|
||||
The second part of a \minisearch{} \gls{meta-optimisation} is the \gls{meta-optimisation} algorithm itself.
|
||||
\Cref{lst:6-lns-minisearch} shows a basic \minisearch{} implementation of a basic \gls{lns}, called \mzninline{lns}.
|
||||
\Cref{lst:inc-lns-minisearch} shows a basic \minisearch{} implementation of a basic \gls{lns}, called \mzninline{lns}.
|
||||
It performs a fixed number of iterations, each invoking the \gls{neighbourhood} predicate \mzninline{uniform_neighbourhood} in a fresh scope.
|
||||
This means that the \constraints{} only affect the current loop iteration.
|
||||
It then searches for a solution (\mzninline{minimize_bab}) with a given timeout.
|
||||
@ -84,10 +84,10 @@ We then annotate the \mzninline{solve} item with the following \gls{annotation}
|
||||
Note that \minizinc{} currently does not support passing functions or predicates as arguments.
|
||||
Calling the predicate, as in \mzninline{::on_restart(my_neighbourhood())}, would not have the correct semantics.
|
||||
The predicate needs to be called for each restart.
|
||||
As a workaround, we currently pass the name of the predicate to be called for each restart as a string (see the definition of the new \mzninline{on_restart} annotation in \cref{lst:6-restart-ann}).
|
||||
As a workaround, we currently pass the name of the predicate to be called for each restart as a string (see the definition of the new \mzninline{on_restart} annotation in \cref{lst:inc-restart-ann}).
|
||||
|
||||
The second component of our \gls{lns} definition is the ``restarting strategy'', defining how much effort the \solver{} should put into each \gls{neighbourhood} (\ie{} \gls{restart}), and when to stop the overall search. We propose adding new search \glspl{annotation} to the \minizinc{} to control this behaviour.
|
||||
The proposed \glspl{annotation} are shown in \cref{lst:6-restart-ann}.
|
||||
The proposed \glspl{annotation} are shown in \cref{lst:inc-restart-ann}.
|
||||
|
||||
The \mzninline{restart_on_solution} annotation tells the solver to restart immediately for each \gls{sol}, rather than looking for the best one in each restart.
|
||||
The \mzninline{restart_without_objective} tells it not to add \gls{bnb} \constraints{} on the \gls{objective}.
|
||||
@ -96,8 +96,8 @@ The \mzninline{timeout} annotation gives an overall time limit for the search.
|
||||
Finally, the \mzninline{restart_limit} stops the search after a fixed number of \glspl{restart}.
|
||||
|
||||
\begin{listing}
|
||||
\mznfile{assets/listing/6_restart_ann.mzn}
|
||||
\caption{\label{lst:6-restart-ann} New annotations to control the restarting
|
||||
\mznfile{assets/listing/inc_restart_ann.mzn}
|
||||
\caption{\label{lst:inc-restart-ann} New annotations to control the restarting
|
||||
behaviour}
|
||||
\end{listing}
|
||||
|
||||
@ -119,7 +119,7 @@ This approach is sufficient for expressing many \gls{meta-optimisation} algorith
|
||||
|
||||
\paragraph{State access and initialisation}
|
||||
|
||||
The state access functions are defined in \cref{lst:6-state-access}.
|
||||
The state access functions are defined in \cref{lst:inc-state-access}.
|
||||
Function \mzninline{status} returns the status of the previous restart, namely:
|
||||
|
||||
\begin{description}
|
||||
@ -135,8 +135,8 @@ The value is undefined when \mzninline{status()=START}.
|
||||
Like \mzninline{sol}, it has versions for all basic \variable{} types.
|
||||
|
||||
\begin{listing}
|
||||
\mznfile{assets/listing/6_state_access.mzn}
|
||||
\caption{\label{lst:6-state-access} Functions for accessing previous \solver{} states}
|
||||
\mznfile{assets/listing/inc_state_access.mzn}
|
||||
\caption{\label{lst:inc-state-access} Functions for accessing previous \solver{} states}
|
||||
\end{listing}
|
||||
|
||||
In order to be able to initialise the \variables{} used for state access, we interpret \mzninline{on_restart} also before initial search using the same semantics.
|
||||
@ -162,34 +162,34 @@ In order to use this predicate with the \mzninline{on_restart} annotation, we ca
|
||||
\noindent{}Calling \mzninline{uniform_neighbourhood} like this would result in a single evaluation of the predicate, since \minizinc{} employs a call-by-value evaluation strategy.
|
||||
Furthermore, the \mzninline{on_restart} annotation only accepts the name of a nullary predicate.
|
||||
Therefore, users have to define their overall strategy in a new predicate.
|
||||
\Cref{lst:6-basic-complete} shows a complete example of a basic \gls{lns} model.
|
||||
\Cref{lst:inc-basic-complete} shows a complete example of a basic \gls{lns} model.
|
||||
|
||||
\begin{listing}
|
||||
\mznfile{assets/listing/6_basic_complete.mzn}
|
||||
\caption{\label{lst:6-basic-complete} Complete \gls{lns} example}
|
||||
\mznfile{assets/listing/inc_basic_complete.mzn}
|
||||
\caption{\label{lst:inc-basic-complete} Complete \gls{lns} example}
|
||||
\end{listing}
|
||||
|
||||
We can also define round-robin and adaptive strategies using these primitives.
|
||||
\Cref{lst:6-round-robin} defines a round-robin \gls{lns} meta-heuristic, which cycles through a list of \mzninline{N} neighbourhoods \mzninline{nbhs}.
|
||||
\Cref{lst:inc-round-robin} defines a round-robin \gls{lns} meta-heuristic, which cycles through a list of \mzninline{N} neighbourhoods \mzninline{nbhs}.
|
||||
To do this, it uses the \variable{} \mzninline{select}.
|
||||
In the initialisation phase (\mzninline{status()=START}), \mzninline{select} is set to \mzninline{-1}, which means none of the \glspl{neighbourhood} is activated.
|
||||
In any following \gls{restart}, \mzninline{select} is incremented modulo \mzninline{N}, by accessing the last value assigned in a previous \gls{restart}.
|
||||
This will activate a different \gls{neighbourhood} for each subsequent \gls{restart} (\lref{line:6:roundrobin:post}).
|
||||
|
||||
\begin{listing}
|
||||
\mznfile{assets/listing/6_round_robin.mzn}
|
||||
\caption{\label{lst:6-round-robin} A predicate providing the round-robin
|
||||
\mznfile{assets/listing/inc_round_robin.mzn}
|
||||
\caption{\label{lst:inc-round-robin} A predicate providing the round-robin
|
||||
meta-heuristic}
|
||||
\end{listing}
|
||||
|
||||
%\paragraph{Adaptive \gls{lns}}
|
||||
|
||||
For adaptive \gls{lns}, a simple strategy is to change the size of the \gls{neighbourhood} depending on whether the previous size was successful or not.
|
||||
\Cref{lst:6-adaptive} shows an adaptive version of the \mzninline{uniform_neighbourhood} that increases the number of free \variables{} when the previous \gls{restart} failed, and decreases it when it succeeded, within the bounds \([0.6,0.95]\).
|
||||
\Cref{lst:inc-adaptive} shows an adaptive version of the \mzninline{uniform_neighbourhood} that increases the number of free \variables{} when the previous \gls{restart} failed, and decreases it when it succeeded, within the bounds \([0.6,0.95]\).
|
||||
|
||||
\begin{listing}
|
||||
\mznfile{assets/listing/6_adaptive.mzn}
|
||||
\caption{\label{lst:6-adaptive} A simple adaptive neighbourhood}
|
||||
\mznfile{assets/listing/inc_adaptive.mzn}
|
||||
\caption{\label{lst:inc-adaptive} A simple adaptive neighbourhood}
|
||||
\end{listing}
|
||||
|
||||
\subsection{Optimisation strategies}
|
||||
@ -269,7 +269,7 @@ Otherwise, we record that we have one more \gls{sol}.
|
||||
We store the \gls{sol} values in \mzninline{s1} and \mzninline{s2} \glspl{array}.
|
||||
Before each \gls{restart} we add \constraints{} removing Pareto dominated \glspl{sol}, based on each previous \gls{sol}.
|
||||
|
||||
\section{Rewriting of Meta-Optimisation Algorithms}\label{sec:6-solver-extension}
|
||||
\section{Rewriting of Meta-Optimisation Algorithms}\label{sec:inc-solver-extension}
|
||||
|
||||
The \glspl{neighbourhood} defined in the previous section can be executed with \minisearch{} by adding support for the \mzninline{status} and \mzninline{last_val} built-in functions, and by defining the main \gls{restart} loop.
|
||||
The \minisearch{} evaluator will then call a \solver{} to produce a \gls{sol}, and evaluate the \gls{neighbourhood} predicate, incrementally producing new \flatzinc{} to be added to the next round of solving.
|
||||
@ -300,7 +300,7 @@ To compile a \gls{meta-optimisation} algorithms to a \gls{slv-mod}, the \gls{rew
|
||||
\end{enumerate}
|
||||
|
||||
These transformations will not change the code of many \gls{neighbourhood} definitions, since the functions are often used in positions that accept both \parameters{} and \variables{}.
|
||||
For example, the \mzninline{uniform_neighbourhood} predicate from \cref{lst:6-lns-minisearch-pred} uses \mzninline{uniform(0.0, 1.0)} in an \mzninline{if} expression, and \mzninline{sol(x[i])} in an equality \constraint{}.
|
||||
For example, the \mzninline{uniform_neighbourhood} predicate from \cref{lst:inc-lns-minisearch-pred} uses \mzninline{uniform(0.0, 1.0)} in an \mzninline{if} expression, and \mzninline{sol(x[i])} in an equality \constraint{}.
|
||||
Both expressions can be rewritten when the functions return a \variable{}.
|
||||
|
||||
\subsection{Rewriting the new functions}
|
||||
@ -309,12 +309,12 @@ We can rewrite \instances{} that contain the new functions by extending the \min
|
||||
|
||||
\paragraph{\mzninline{status}}
|
||||
|
||||
\Cref{lst:6-status} shows the definition of the \mzninline{status} function.
|
||||
\Cref{lst:inc-status} shows the definition of the \mzninline{status} function.
|
||||
It simply replaces the functional form by a predicate \mzninline{status} (declared in \lref{line:6:status}), which constrains its local variable argument \mzninline{stat} to take the status value.
|
||||
|
||||
\begin{listing}
|
||||
\mznfile{assets/listing/6_status.mzn}
|
||||
\caption{\label{lst:6-status} MiniZinc definition of the \mzninline{status} function}
|
||||
\mznfile{assets/listing/inc_status.mzn}
|
||||
\caption{\label{lst:inc-status} MiniZinc definition of the \mzninline{status} function}
|
||||
\end{listing}
|
||||
|
||||
\paragraph{\mzninline{sol} and \mzninline{last_val}}
|
||||
@ -322,14 +322,14 @@ It simply replaces the functional form by a predicate \mzninline{status} (declar
|
||||
The \mzninline{sol} function is overloaded for different types.
|
||||
Our \glspl{slv-mod} does not support overloading.
|
||||
Therefore, we produce type-specific \gls{native} \constraints{} for every type of \gls{native} \variable{} (\eg{} \mzninline{int_sol(x, xi)}, and \mzninline{bool_sol(x, xi)}).
|
||||
The resolving of the \mzninline{sol} function into these specific \gls{native} \constraints{} is done using an overloaded definition, like the one shown in \cref{lst:6-int-sol} for integer \variables{}.
|
||||
The resolving of the \mzninline{sol} function into these specific \gls{native} \constraints{} is done using an overloaded definition, like the one shown in \cref{lst:inc-int-sol} for integer \variables{}.
|
||||
If the value of the \variable{} has become known during \gls{rewriting}, then we use its \gls{fixed} value instead.
|
||||
Otherwise, the function call is rewritten into a type specific \mzninline{int_sol} \gls{native} \constraint{} that will be executed by the solver.
|
||||
We use the current \domain{} of the \variable{}, \mzninline{dom(x)}, as the \domain{} the \variable{} returned by \mzninline{sol}.
|
||||
|
||||
\begin{listing}
|
||||
\mznfile{assets/listing/6_sol_function.mzn}
|
||||
\caption{\label{lst:6-int-sol} MiniZinc definition of the \mzninline{sol}
|
||||
\mznfile{assets/listing/inc_sol_function.mzn}
|
||||
\caption{\label{lst:inc-int-sol} MiniZinc definition of the \mzninline{sol}
|
||||
function for integer variables}
|
||||
\end{listing}
|
||||
|
||||
@ -339,13 +339,13 @@ The compilation of \mzninline{last_val} is similar to that for \mzninline{sol}.
|
||||
|
||||
Calls to the random number functions have been renamed by appending \texttt{\_slv}, so that they are not simply evaluates directly.
|
||||
The definition of these new functions follows the same pattern as for \mzninline{sol}, \mzninline{status}, and \mzninline{last_val}.
|
||||
The \minizinc{} definition of the \mzninline{uniform_nbh} function is shown in \Cref{lst:6-int-rnd}\footnote{Random number functions need to be marked as \mzninline{::impure} for the compiler not to apply \gls{cse} when they are called multiple times with the same arguments.}.
|
||||
The \minizinc{} definition of the \mzninline{uniform_nbh} function is shown in \Cref{lst:inc-int-rnd}\footnote{Random number functions need to be marked as \mzninline{::impure} for the compiler not to apply \gls{cse} when they are called multiple times with the same arguments.}.
|
||||
Note that the function accepts \variable{} as its arguments \mzninline{l} and \mzninline{u}.
|
||||
As such, it can be used in combination with other functions, such as \mzninline{sol}.
|
||||
|
||||
\begin{listing}
|
||||
\mznfile{assets/listing/6_uniform_slv.mzn}
|
||||
\caption{\label{lst:6-int-rnd} MiniZinc definition of the
|
||||
\mznfile{assets/listing/inc_uniform_slv.mzn}
|
||||
\caption{\label{lst:inc-int-rnd} MiniZinc definition of the
|
||||
\mzninline{uniform_nbh} function for floats}
|
||||
\end{listing}
|
||||
|
||||
@ -365,7 +365,7 @@ Note that the \gls{slv-mod} will actually include the \mzninline{complete_reif}
|
||||
|
||||
We will now show the minimal extensions required from a \solver{} to interpret the new \gls{native} \constraints{} and, consequently, to execute \gls{meta-optimisation} definitions expressed in \minizinc{}.
|
||||
|
||||
First, the \solver{} needs to parse and support the \gls{restart} \glspl{annotation} of \cref{lst:6-restart-ann}.
|
||||
First, the \solver{} needs to parse and support the \gls{restart} \glspl{annotation} of \cref{lst:inc-restart-ann}.
|
||||
Many \solvers{} already support all this functionality.
|
||||
Second, the \solver{} needs to be able to parse the new \constraints{} \mzninline{status}, and all versions of \mzninline{sol}, \mzninline{last_val}, random number functions like \mzninline{float_uniform}, and \mzninline{complete}.
|
||||
In addition, for the new \constraints{} the \solver{} is extended using the following algorithms.
|
||||
@ -390,13 +390,13 @@ Typically, this means the solver must not propagate these \constraints{} until i
|
||||
Modifying a solver to support this functionality is straightforward if it already has a mechanism for posting \constraints{} during restarts.
|
||||
We have implemented these extensions for both \gls{gecode} (214 new lines of code) and \gls{chuffed} (173 new lines of code).
|
||||
|
||||
For example, consider the model from \cref{lst:6-basic-complete} again that uses the following \gls{meta-optimisation} algorithms.
|
||||
For example, consider the model from \cref{lst:inc-basic-complete} again that uses the following \gls{meta-optimisation} algorithms.
|
||||
|
||||
\begin{mzn}
|
||||
basic_lns(uniform_neighbourhood(x, 0.2))}
|
||||
\end{mzn}
|
||||
|
||||
\Cref{lst:6-flat-pred} shows a part of the resulting \gls{slv-mod}.
|
||||
\Cref{lst:inc-flat-pred} shows a part of the resulting \gls{slv-mod}.
|
||||
\Lrefrange{line:6:status:start}{line:6:status:end} define a Boolean variable \mzninline{b1} that is true if-and-only-if the status is not \mzninline{START}.
|
||||
The second block of code, \lrefrange{line:6:x1:start}{line:6:x1:end}, represents the \gls{decomp} of the following expression.
|
||||
|
||||
@ -417,8 +417,8 @@ We have omitted the similar code generated for \mzninline{x[2]} to \mzninline{x[
|
||||
Note that the \flatzinc{} \gls{slv-mod} shown here has been simplified for presentation.
|
||||
|
||||
\begin{listing}
|
||||
\mznfile{assets/listing/6_basic_complete_transformed.mzn}
|
||||
\caption{\label{lst:6-flat-pred} \flatzinc{} that results from compiling \\
|
||||
\mznfile{assets/listing/inc_basic_complete_transformed.mzn}
|
||||
\caption{\label{lst:inc-flat-pred} \flatzinc{} that results from compiling \\
|
||||
\mzninline{basic_lns(uniformNeighbourhood(x,0.2))}.}
|
||||
\end{listing}
|
||||
|
||||
@ -436,7 +436,7 @@ Furthermore, it is not strictly necessary to guard \mzninline{int_uniform} again
|
||||
The \mzninline{sol} \constraints{} will simply not propagate anything in case no \gls{sol} has been recorded yet, but we use this simple example to illustrate how these Boolean conditions are rewritten and evaluated.
|
||||
|
||||
\section{An Incremental Constraint Modelling Interface}%
|
||||
\label{sec:6-incremental-compilation}
|
||||
\label{sec:inc-incremental-compilation}
|
||||
|
||||
A universal approach to the incremental usage of \cmls{}, and \gls{meta-optimisation}, is to allow incremental changes to an \instance{} of a \cmodel{}.
|
||||
To solve these changing \instances{}, they have to be rewritten repeatedly to \glspl{slv-mod}.
|
||||
@ -452,7 +452,7 @@ Removing a \constraint{}, however, is not so simple.
|
||||
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:6-incremental}
|
||||
\begin{example}\label{ex:inc-incremental}
|
||||
Consider the following \minizinc\ fragment:
|
||||
|
||||
\begin{mzn}
|
||||
@ -484,7 +484,7 @@ When a \constraint{} is removed, its corresponding changes are undone by reversi
|
||||
In order to limit the amount of \gls{trail}ing required, the programmer must create explicit ``choice points'' to which the system state can be reset.
|
||||
In particular, this means that if no choice point was created before the initial \instance{} was rewritten, then this \gls{rewriting} can be performed without any \gls{trail}ing.
|
||||
|
||||
\begin{example}\label{ex:6-trail}
|
||||
\begin{example}\label{ex:inc-trail}
|
||||
|
||||
Let us once again consider the following \minizinc{} fragment from \cref{ex:rew-absreif}.
|
||||
|
||||
@ -582,7 +582,7 @@ These experiments illustrate that the \gls{meta-optimisation} implementations in
|
||||
|
||||
We ran experiments for three models from the MiniZinc Challenge \autocite{stuckey-2010-challenge, stuckey-2014-challenge} (\texttt{gbac}, \texttt{steelmillslab}, and \texttt{rcpsp-wet}).
|
||||
The \instances{} are rewritten using the \minizinc{} 2.5.5 \compiler{}, adjusted to rewrite \gls{rbmo} specifications.
|
||||
For each model we use a round-robin \gls{lns} approach, shown in \cref{lst:6-round-robin}, of two \glspl{neighbourhood}: a \gls{neighbourhood} that destroys 20\% of the main \variables{} (\cref{lst:6-lns-minisearch-pred}) and a structured \gls{neighbourhood} for the model (described below).
|
||||
For each model we use a round-robin \gls{lns} approach, shown in \cref{lst:inc-round-robin}, of two \glspl{neighbourhood}: a \gls{neighbourhood} that destroys 20\% of the main \variables{} (\cref{lst:inc-lns-minisearch-pred}) and a structured \gls{neighbourhood} for the model (described below).
|
||||
For each solving method we show the cumulative integral of the objective values for all \instances{} of the model.
|
||||
The underlying search strategy used is the fixed search strategy defined in the model.
|
||||
The restart strategy uses the following \glspl{annotation}.
|
||||
@ -600,11 +600,11 @@ The overall time out for each run is 120 seconds.
|
||||
The \gls{gbac} problem comprises courses having a specified number of credits and lasting a certain number of periods, load limits of courses for each period, prerequisites for courses, and preferences of teaching periods for professors.
|
||||
A detailed description of the problem is given in \autocite{chiarandini-2012-gbac}.
|
||||
The main decisions are to assign courses to periods, which is done via the \variables{} \mzninline{period_of} in the \minizinc{} model.
|
||||
\cref{lst:6-free-period} shows the neighbourhood chosen, which randomly picks one period and frees all courses that are assigned to it.
|
||||
\cref{lst:inc-free-period} shows the neighbourhood chosen, which randomly picks one period and frees all courses that are assigned to it.
|
||||
|
||||
\begin{listing}[b]
|
||||
\mznfile{assets/listing/6_gbac_neighbourhood.mzn}
|
||||
\caption{\label{lst:6-free-period}\gls{gbac}: \gls{neighbourhood} freeing all courses in a period.}
|
||||
\mznfile{assets/listing/inc_gbac_neighbourhood.mzn}
|
||||
\caption{\label{lst:inc-free-period}\gls{gbac}: \gls{neighbourhood} freeing all courses in a period.}
|
||||
\end{listing}
|
||||
|
||||
\begin{figure}
|
||||
@ -631,12 +631,12 @@ The steel mill slab design problem consists of cutting slabs into smaller ones,
|
||||
The steel mill only produces slabs of certain sizes, and orders have both a size and a colour.
|
||||
We have to assign orders to slabs, with at most two different colours on each slab.
|
||||
The model uses the \variables{} \mzninline{assign} for deciding which order is assigned to which slab.
|
||||
\Cref{lst:6-free-bin} shows a structured \gls{neighbourhood} that randomly selects a slab and frees the orders assigned to it in the incumbent \gls{sol}.
|
||||
\Cref{lst:inc-free-bin} shows a structured \gls{neighbourhood} that randomly selects a slab and frees the orders assigned to it in the incumbent \gls{sol}.
|
||||
These orders can then be freely reassigned to any other slab.
|
||||
|
||||
\begin{listing}
|
||||
\mznfile{assets/listing/6_steelmillslab_neighbourhood.mzn}
|
||||
\caption{\label{lst:6-free-bin}Steel mill slab: \gls{neighbourhood} that frees
|
||||
\mznfile{assets/listing/inc_steelmillslab_neighbourhood.mzn}
|
||||
\caption{\label{lst:inc-free-bin}Steel mill slab: \gls{neighbourhood} that frees
|
||||
all orders assigned to a selected slab.}
|
||||
\end{listing}
|
||||
|
||||
@ -666,12 +666,12 @@ However, We do see that, given enough time, baseline \gls{gecode} will eventuall
|
||||
The \gls{rcpsp} with Weighted Earliness and Tardiness cost, is a classic scheduling problem in which tasks need to be scheduled subject to precedence \constraints{} and cumulative resource restrictions.
|
||||
The objective is to find an optimal schedule that minimises the weighted cost of the earliness and tardiness for tasks that are not completed by their proposed deadline.
|
||||
The \variables{} in \gls{array} \mzninline{s} represent the start times of each task in the model.
|
||||
\Cref{lst:6-free-timeslot} shows our structured \gls{neighbourhood} for this model.
|
||||
\Cref{lst:inc-free-timeslot} shows our structured \gls{neighbourhood} for this model.
|
||||
It randomly selects a time interval of one-tenth the length of the planning horizon and frees all tasks starting in that time interval, which allows a reshuffling of these tasks.
|
||||
|
||||
\begin{listing}
|
||||
\mznfile{assets/listing/6_rcpsp_neighbourhood.mzn}
|
||||
\caption{\label{lst:6-free-timeslot}\Gls{rcpsp}/wet: \gls{neighbourhood} freeing
|
||||
\mznfile{assets/listing/inc_rcpsp_neighbourhood.mzn}
|
||||
\caption{\label{lst:inc-free-timeslot}\Gls{rcpsp}/wet: \gls{neighbourhood} freeing
|
||||
all tasks starting in the drawn interval.}
|
||||
\end{listing}
|
||||
|
||||
|
||||
@ -41,8 +41,8 @@ In this chapter we introduce two methods to provide this support:
|
||||
\end{itemize}
|
||||
|
||||
The rest of the chapter is organised as follows.
|
||||
\Cref{sec:6-modelling} discusses the declarative modelling of \gls{rbmo} methods in a \cml{}.
|
||||
\Cref{sec:6-solver-extension} introduces the method to rewrite these \gls{meta-optimisation} definitions into efficient \glspl{slv-mod} and the minimal extension required from the target \gls{solver}.
|
||||
\Cref{sec:6-incremental-compilation} introduces the alternative method that extends our architecture with an incremental \constraint{} modelling interface.
|
||||
\Cref{sec:inc-modelling} discusses the declarative modelling of \gls{rbmo} methods in a \cml{}.
|
||||
\Cref{sec:inc-solver-extension} introduces the method to rewrite these \gls{meta-optimisation} definitions into efficient \glspl{slv-mod} and the minimal extension required from the target \gls{solver}.
|
||||
\Cref{sec:inc-incremental-compilation} introduces the alternative method that extends our architecture with an incremental \constraint{} modelling interface.
|
||||
\Cref{sec:inc-experiments} reports on the experimental results of both approaches.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user