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

Tiny reformatting

Browse Source
This commit is contained in:
Jip J. Dekker 2021-06-24 19:39:44 +10:00
parent 574a40ea43
commit 5699b08621
No known key found for this signature in database
GPG Key ID: 517DF4A00618C9C3
1 changed files with 14 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
chapters/5_incremental.tex
View File

@ -694,26 +694,22 @@ trailing.
\subsection{Incremental Solving}
Ideally, the incremental changes made by the interpreter would also be applied
incrementally to the solver. This requires the solver to support both the
dynamic addition and removal of variables and constraints. While some solvers
can support this functionality, most solvers have limitations. The system can
therefore support solvers with different levels of an incremental interface:
Ideally, the incremental changes made by the interpreter would also be applied incrementally to the solver.
This requires the solver to support both the dynamic addition and removal of variables and constraints.
While some solvers can support this functionality, most solvers have limitations.
The system can therefore support solvers with different levels of an incremental interface:
\begin{itemize}
\item Using a non-incremental interface, the solver is reinitialised with the
updated \nanozinc\ program every time. In this case, we still get a
performance benefit from the improved flattening time, but not from
incremental solving.
\item Using a \textit{warm-starting} interface, the solver is reinitialised
with the updated program as above, but it is also given a previous solution
to initialise some internal data structures. In particular for mathematical
programming solvers, this can result in dramatic performance gains compared
to ``cold-starting'' the solver every time.
\item Using a fully incremental interface, the solver is instructed to apply
the changes made by the interpreter. In this case, the trail data structure
is used to compute the set of \nanozinc\ changes since the last choice
point.
\item Using a non-incremental interface, the solver is reinitialised with the updated \nanozinc\ program every time.
In this case, we still get a performance benefit from the improved flattening time, but not from incremental solving.
\item Using a \textit{warm-starting} interface, the solver is reinitialised with the updated program as above, but it is also given a previous solution to initialise some internal data structures.
In particular for mathematical programming solvers, this can result in dramatic performance gains compared to ``cold-starting'' the solver every time.
\item Using a fully incremental interface, the solver is instructed to apply the changes made by the interpreter.
In this case, the trail data structure is used to compute the set of \nanozinc\ changes since the last choice point.
\end{itemize}