From c53d492e11ee6852ab1db56e9a24ad4f92a430f1 Mon Sep 17 00:00:00 2001 From: "Jip J. Dekker" Date: Sun, 25 Jul 2021 15:32:42 +1000 Subject: [PATCH] Fix small spelling inconsistencies --- chapters/3_rewriting.tex | 4 ++-- chapters/5_incremental.tex | 2 +- chapters/6_conclusions.tex | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/chapters/3_rewriting.tex b/chapters/3_rewriting.tex index 51a50d9..7e91ef7 100644 --- a/chapters/3_rewriting.tex +++ b/chapters/3_rewriting.tex @@ -805,8 +805,8 @@ Times are averages of 10 runs. Points below the line indicate that the new system is faster. On average, the new system achieves a speed-up of 5.5, with every \instance{} achieving at least 2.5 speed-up and multiple \instances{} with a speed-up of over 100. In terms of memory performance (\cref{sfig:rew-comparemem}), version 2.5.5 can sometimes still outperform the new prototype. -We have identified that the main memory bottlenecks are our currently unoptimised implementations of \gls{cse} lookup tables and argument vectors. -These are very encouraging results, given that we are comparing a largely unoptimised prototype to a mature piece of software. +We have identified that the main memory bottlenecks are our currently unoptimized implementations of \gls{cse} lookup tables and argument vectors. +These are very encouraging results, given that we are comparing a largely unoptimized prototype to a mature piece of software. \begin{figure} \centering diff --git a/chapters/5_incremental.tex b/chapters/5_incremental.tex index 0b13181..c799275 100644 --- a/chapters/5_incremental.tex +++ b/chapters/5_incremental.tex @@ -560,7 +560,7 @@ For one of the \solvers{}, we also compare with an oracle approach that can dire As such, we show that the use of \gls{rbmo} introduces an insignificant computational overhead. Our second experiment compares the performance of using \minizinc{} incrementally. -We compare our two methods, \gls{rbmo} and the incremental constraint modelling interface, against the baseline of continuously \gls{rewriting} and reinitialising the \solver{}. +We compare our two methods, \gls{rbmo} and the incremental constraint modelling interface, against the baseline of continuously \gls{rewriting} and reinitializing the \solver{}. For this comparison compare the time that is required to (repeatedly) rewrite an \instance{} and the time required by the \solver{}. The first model contains a lexicographic objective. The second model is shared between the two experiments and uses a round-robin \gls{lns} approach. diff --git a/chapters/6_conclusions.tex b/chapters/6_conclusions.tex index be03e8e..f9c5628 100644 --- a/chapters/6_conclusions.tex +++ b/chapters/6_conclusions.tex @@ -128,7 +128,7 @@ Since multiple iterations of \gls{meta-optimization} typically share large parts As an additional improvement, the changes observed in the \gls{slv-mod} can be incrementally applied within the \solver{}. Ideally, the \solver{} can fully support the incremental changes made to the \gls{slv-mod}. -This avoids the overhead of re-initialisation and allows the solver to retain all search information. +This avoids the overhead of reinitialization and allows the solver to retain all search information. Otherwise, the \solver{} can still be warm-started. Instead of starting the search without any information, the \solver{} is given information about the previous \gls{sol} to speed up its search.