\section{Security}

This hybrid solution allows us to use the parent chain as a
reliable protector against most of the attacks that target the PoS systems.
\cite{pos_attacks}
In this section, we assume that the parent chain is well secured, and every
user has decent and reliable access to it.

\subsection{Nothing at stake}

This attack splits into two cases: microforks and generational forks.

\subsubsection{Microforks}

When a malicious leader is elected, they can produce blocks without any cost.
They are free to create conflicting branches within a single generation.

This case is very similar to BitcoinNG's. We introduce the Proof of Fraud (PoF)
mechanism to punish the malicious leaders, but in this situation, we can make
the penalties much more severe by acting not only on the transaction fees
but also staked tokens. On the other hand, this kind of forking is not dangerous
at all – it may introduce some mess but will be instantly solved with the next keyblock.

\begin{figure}[h]
	\caption{Microfork}
	\centering
	\includegraphics[scale=0.35]{microfork}
\end{figure}

\subsubsection{Generational forks}

This kind of attack is not a problem in PoW based BitcoinNG as producing
keyblocks is a hard task. On the contrary keyblocks on hyperchains are really,
really cheap - a malicious leader might flood the network with conflicting
keyblocks:

\begin{figure}[h]
	\caption{Generational Fork}
	\centering
	\includegraphics[scale=0.35]{genfork}
\end{figure}

The $K1a$, $K1b$, etc. are keyblocks on the child chain emitted by a malicious
leader over different microblocks. This
effectively splits the network in many parts, as it becomes unclear to which of
the forks the delegates should commit. To resolve this issue, a single leader
must be agreed upon using some additional mechanism – a new election
should be performed with the exclusion of the compromised delegate.

To notify the network about the generational fork, the peers need to announce
this fact on the parent chain by publishing the fraud commitments and the
cryptographic proofs of generational fraud (PoGF). Each commitment has to point to
the latest child keyblock considered by the delegates to be
valid, that is the generation where the fork starts. The committer also needs
to submit to which fork they want to contribute – if they get elected they
will be required to build on it (we disallow rollbacks). The voting power should be
calculated based on the latest block before the fraud was detected.

\begin{figure}[h]
	\caption{Generational Fork Solving}
	\centering
	\includegraphics[scale=0.45]{genfraud}
\end{figure}

Due to network propagation
delays and connectivity failures, some nodes might not notice that a generational
fork was created and not respond accordingly. New nodes or the ones catching up
after downtime need to be aware that a generational fork was created and apply
the appropriate resolution. Some of them may commit to one of the forks and receive a fraud
notification after they started mining. Therefore, we introduce a metric over the
branches that we are going to call "difficulty" for a conventional reason. The
rule to resolve conflicts caused by such data races is similar to already
existing PoW strategy "follow the most difficult chain," and the formula goes
as follows:

\begin{minipage}{\linewidth}
\begin{lstlisting}
  difficulty : Block -> Int
  difficulty(Genesis) = 0
  difficulty(block) =
    if exists proof of generational fraud on /block/
    then sum of the voting power of delegates
           that committed to /prev(block)/ +
         sum of the voting power of delegates
           that committed to solve the genfork
    else sum of the voting power of delegates
           that committed to /prev(block)/
\end{lstlisting}
\end{minipage}

If two forks have the same difficulty, then we prefer the one with lower
block hash. This formula ensures that keyblocks pointing to a PoGF are always
strongly preferred over ordinary keyblocks – delegates who detect generational
forks have higher priority over poorly connected/bootstrapping/syncing ones.

This solution may look vulnerable to situations where the leader doesn't respond
or responds with significant delay. To solve these cases, we just elect a new
leader, stalling the network for a while. To vanish the doubts arising when the
previous leader reappears, we can assume
finalization after $f$ (implementation dependent) generations.

There is a compelling case where the malicious leader submits a generational
fork by publishing keyblocks on conflicting microblocks.
Here we want to prioritize PoGF because the consequences of the forks on
keyblocks are much more severe than these on microblocks, and we would need to
solve them anyway.

\subsection{Stake grinding}

Since the RNG depends ultimately on the keyblock hash on the PoW chain, it is
impossible to predict its outcomes. One could try to mine the parent chain
in a special way, but it would require so much computational power that in
most cases it would be easier to take control over it by some 51\% attack.

\subsection{Long range attack}
While it is still possible to perform it, it would be impossible to do it in
silence and without preparation since the very beginning. The commitments
guarantee that the information of the delegates is stored on an immutable chain,
and one would need to announce their will of mining some suspicious blocks during
the full period of the attack. This would quickly expose the intention of the attacker
and let the others prepare for an eventual surprise (by blacklisting them, for example).

\subsection{Avoiding punishments}
Depending on the circumstances on the network the transaction fees may vary
– this makes the original penalty system from BitcoinNG not sufficient in every
case as the risk of fraud detection may be much lesser than expected profit.

One of the most natural ideas is to freeze the stake with some period before the
election. In this scenario, the protocol will be able to painfully slash the
malicious leaders by burning/redistributing their stake. However, this may raise
some problems when the delegated voting is used – the malicious leader may vote
for their second, empty account that will do the fraud losing potentially
nothing in case of getting compromised. This scenario can be dealt with, allowing only
top $k$ stakers to be voted on or slashing \textit{everyone} who supported the
malicious leader. We leave this implementation-dependent as different solutions
require different security approaches.


\section{$\alpha$}

\section{Extra section with $\epsilon$ warnings}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                                 %
%  GEANT manual in LaTeX form                              %
%                                                                 %
%  Michel Goossens (for translation into LaTeX)                   %
%  Version 1.00                                                   %
%  Last Mod. Jan 24 1991  1300   MG + IB                          %
%                                                                 %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\Origin{D. Ward, L.Urb\'{a}n}
\Submitted{26.10.84} \Revised{16.12.93}
\Version{Geant 3.16}\Routid{PHYS331}
\Makehead{Simulation of the delta-ray production}
\section{Subroutines}
\Shubr{GDRAY}{}
\Rind{GDRAY} generates explicitly the delta-rays (see
{\tt [PHYS330]} for treatment of the ionization as continuous energy loss
and for the calculation of the total cross-section).
\begin{DLtt}{MMMMMMMMMM}
\item[input:]  common \FCind{/GCTRAK/}
\item[output:] common \FCind{/GCKING/}
\end{DLtt}
The routine is called from the tracking routines
\Rind{GTELEC}, \Rind{GTMUON}, \Rind{GTHION} and \Rind{GTHADR}
when a charged particle reaches
its interaction point.
\section {Method }
\subsection{Differential cross-section}
The differential cross-section of the $\delta$-ray production can
be written as in equations (\ref{eq:phys331-1}, \ref{eq:phys331-2})
\cite{bib-MES1}, \cite{bib-EGS3}, \cite{bib-PDGB}. For the
electron/electron (M\"{o}ller) scattering we have:
\begin{equation}
\label{eq:phys331-1}
\frac{d\sigma }{d \epsilon }=\frac{2 \pi Z r^2 _0 m }{\beta^2 (E-m)}
\left[ \frac{(\gamma -1 )^2}  {\gamma^2 }+\frac{1}{\epsilon}
\left(\frac{1}{\epsilon}-\frac{2 \gamma -1 } {\gamma^2 } \right) +
\frac{1}{1- \epsilon}\left(\frac{1} {1- \epsilon} \frac{2 \gamma - 1}
{\gamma^2 }\right)  \right]
\end{equation}
and for the positron-electron (Bhabha) scattering:
\begin{equation}
\label{eq:phys331-2}
\frac{d \sigma}{d \epsilon}=\frac{2 \pi Z r^2_0 m }{(E-m)}\left[
\frac{1} {\beta^2 \epsilon^2}-\frac{B_1}{\epsilon}+B_2 - B_3 \epsilon
+ B_4 \epsilon^2\right]
 \end{equation}

where

\[
\begin{array}{LcL@{\hspace{1.6cm}}LcL}
Z        & = & \mbox{atomic number of the medium}   &
E        & = & \mbox{energy of the incident particle} \\
M        & = & \mbox{rest mass of the incident particle} &
\gamma   & = & \frac{E}{M}   \\ [.2cm]
\beta^2  & = & 1- \frac{1} {\gamma^2 } &
 y       & = & \frac{1} {\gamma + 1}               \\ [.2cm]
 B_1     & = & 2-y^2                   &
 B_2     & = & (1-2y)(3+y^2 )                       \\
 B_3     & = & (1-2y)^2+(1-2y)^3 &
 B_4     & = & (1-2y)^3  \\
\epsilon & = & \frac{T} {E-m}
\end{array}
\]

with $T$ the kinematic energy of the scattered electron (of the lower
energy in the case of $\Pem\Pep$ scattering).

The kinematical limits for the variable $\epsilon$ are:

\[
\epsilon_0 = \frac{\mbox{\tt TCUT}}{E-m} \leq \epsilon \leq \frac{1}{2}
\mbox{\hspace{.2cm} for \Pem\Pem} \hspace{2cm}
\epsilon_0 = \frac{\mbox{\tt TCUT}}{E-m} \leq \epsilon \leq 1
\mbox{\hspace{.2cm} for \Pep\Pem}
\]
For the other charged particles the differential cross-section
can be written:
\[
\begin{array}{LcLl}
\frac {d\sigma }{dT}&=& 2 \pi Z r^2_ 0 m\frac{1}{\beta^2 }\frac{1}{T^2}
\left[ 1- \beta^2 \frac{T} {\mbox{\tt TMAX }}\right]
& \mbox{for spin 0 particle} \\ [.3cm]
\frac{d \sigma} {dT}&=& 2 \pi Z r^2_0 m \frac{1}{\beta^2 } \frac{1}{T^2}
\left[1- \beta^ 2 \frac{T}{ \mbox{\tt TMAX}}+ \frac{T^2} {2E^2}
 \right] &  \mbox{for spin 1/2 particle}
\end{array}
\]
where {\tt TMAX} is the maximum energy transferable to the free electron:
\[
\mbox{\tt TMAX} = \frac{2m(\gamma^2 -1)} {1+2\gamma (m/M) +
(m/M)^2}
\]
and {\tt TCUT} is the energy threshold for the $\delta$-ray emission:
$ \mbox{\tt TCUT} \leq T \leq \mbox{\tt TMAX} $

\subsection{Sampling}
Apart from the normalisation, the cross-section can be written as
\[
\frac{d\sigma}{d\epsilon}=f(\epsilon) g(\epsilon),
\]
where, for $\Pem\Pem$ scattering,
\begin{eqnarray*}
f(\epsilon)&=&\frac{1}{\epsilon^2} \frac{\epsilon_0 }{1- 2\epsilon_0} \\
g(\epsilon)&=&\frac{4}{9\gamma^2 - 10 \gamma + 5}\left[(\gamma -1)^2
\epsilon^2 - (2 \gamma^2 +2\gamma -1) \frac{\epsilon} {1- \epsilon }+
\frac{\gamma^2}{(1- \epsilon )^2 }\right]
\end{eqnarray*}
and for $\Pep\Pem$ scattering
\begin{eqnarray*}
  f(\epsilon)&=&\frac{1}{\epsilon^2} \frac{\epsilon_0}{1- \epsilon_0 } \\
  g(\epsilon)&=&\frac{B_0 -B_1 \epsilon +B_2 \epsilon^2
     -B_3 \epsilon^3 +B_4 \epsilon ^4}{B_ 0-B_1\epsilon_0
+B_2\epsilon^2_0
    -B_3 \epsilon^3_0 +B_4 \epsilon^4_0 }
\end{eqnarray*}
Here $ B_0=\gamma^2/(\gamma^2-1)$ and
all the other quantities have been defined above.
For the other charged particles:
\begin{eqnarray*}
f(T) &=& \left(\frac{1}{\mbox{\tt TCUT}} -\frac{1}{\mbox{\tt TMAX}}\right)
\frac{1}{T} \\
g(T) &=& 1 - \beta^2\frac{T}{\mbox{\tt TMAX}} +\frac{T^2}{2E^2}
\mbox{\quad(last term for spin-$\frac{1}{2}$ particle only)}
\end{eqnarray*}
\Rind{GDRAY} samples the variable $\epsilon$ by:
\begin{enumerate}
\item sample $\epsilon$ from $f(\epsilon)$
\item calculate the rejection function $g(\epsilon)$ and accept the
sampled $\epsilon$ with a probability of $g(\epsilon)$.
\end{enumerate}

After the successful sampling of $\epsilon$, \Rind{GDRAY} generates the polar
angles of the scattered electron with respect to the direction of the
incident particle. The azimuthal angle $\phi$ is generated isotropically;
the polar angle
$\theta$ is calculated from the energy momentum conservation.
This information
is used to calculate the energy and momentum of both scattered
particles and to transform them into the {\tt GEANT} coordinate system.


\subsection{Veblen goods}

The demand curve is sloping up.


\documentclass[a4paper,11pt,twoside,titlepage,openright]{book}

\usepackage[english]{babel}
\usepackage{color}
\usepackage{graphicx}
\usepackage{amsmath}
\numberwithin{equation}{section}
\usepackage[margin=3cm]{geometry}
\usepackage{hyperref}
\usepackage{epsfig,amsfonts}
\usepackage{xcolor,import}

\pagestyle{plain}

\newcommand{\ud}[1]{\underline{#1}}
\newcommand{\e}[1]{\underline{e}_{#1}}
\newcommand{\lt}{\left}
\newcommand{\rt}{\right}
\newcommand{\lra}{\Leftrightarrow}
\DeclareMathOperator{\n}{\underline{n}}
\DeclareMathOperator{\ex}{\underline{e}_x}
\DeclareMathOperator{\ey}{\underline{e}_y}
\DeclareMathOperator{\ez}{\underline{e}_z}
\DeclareMathOperator{\bragg}{\theta_{bragg}}
\DeclareMathOperator{\Z}{Z_C}
\DeclareMathOperator{\DD}{\cos(\theta)^2 - \sin(\psi)^2}
\newcommand{\wdg}{\wedge}
\newcommand{\hypot}[1]{\textbf{\textcolor{green}{#1}}}

\begin{document}

\title{ToFu geometric tools\\ Intersection of a cone with a circle (magnetic axis)}
\author{Didier VEZINET}
\date{04.12.2019}
\maketitle

\tableofcontents

\chapter{Geometry}
\label{chap:Geometry}

\section{Generic cone and plane}

Let's consider a cartesian frame $(O, \ex, \ey, \ez)$.
Let's consider a half-cone defined by its axis $(S, \n)$ and half-opening $\alpha = \pi/2 - \bragg$.
The coordinates of $S$ are $(x_S, y_S, z_S)$.
The coordinates of $\n$ are $(n_x, n_y, n_z)$.
Let's consider a circle of axis $(O, \ez)$, of radius $R$, centered on $C$ or coordinates $(0, 0, \Z)$.

Let's consider point $M$ of coordinates $(x, y, z)$ and $(R, \theta, z)$ belonging to both the cone and the circle.

$$
\lt\{
	\begin{array}{ll}
		M \in circle & \lra \ud{OM} = \Z\ez + R(\cos(\theta)\ex + \sin(\theta)\ey)\\
		M \in cone & \lra \ud{SM}.\n = \cos(\alpha)\|\ud{SM}\|
	\end{array}
\rt.
$$

\section{Intersection}

If $M$ belongs to both the circle and the cone, then:

$$
\begin{array}{ll}
	& \lt[\lt(\ud{SO}+\ud{OM}\rt).\n\rt]^2 = \cos^2(\alpha)\|\ud{SO} + \ud{OM}\|^2\\
	\lra &
	\lt(\ud{SO}.\n\rt)^2 + \lt(\ud{OM}.\n\rt)^2 + 2\lt(\ud{SO}.\n\rt)\lt(\ud{OM}.\n\rt)
	= \cos^2(\alpha)\lt[\|\ud{SO}\|^2 + \|\ud{OM}\|^2 + 2\ud{SO}.\ud{OM}\rt]\\
	\lra &
	\lt(\ud{OM}.\n\rt)^2 + 2\lt(\ud{SO}.\n\rt)\lt(\ud{OM}.\n\rt)
	- \cos^2(\alpha)\|\ud{OM}\|^2 - 2\cos^2(\alpha)\ud{SO}.\ud{OM} + A = 0
\end{array}
$$

Where we have introduced $A = \lt(\ud{SO}.\n\rt)^2 - \cos^2(\alpha)\|\ud{SO}\|^2$

Now, we can write:
$$
\lt\{
	\begin{array}{lll}
		\|\ud{OM}\|^2 & = & \Z^2 + R^2\\
		\ud{OM}.\n & = & \Z n_z + R\cos(\theta)n_x + R\sin(\theta)n_y\\
		\lt(\ud{OM}.\n\rt)^2 & = & \lt(\Z n_z\rt)^2 + \lt(R\cos(\theta)n_x\rt)^2 + \lt(R\sin(\theta)n_y\rt)^2\\
				     &&  + 2\Z R\cos(\theta)n_xn_Z + 2\Z R\sin(\theta)n_yn_z + 2R^2\cos(\theta)\sin(\theta)n_xn_y\\
		\ud{SO}.\ud{OM} & = & -\Z z_S - Rx_S\cos(\theta) - Ry_S\sin(\theta)
	\end{array}
\rt.
$$

Hence:
$$
\begin{array}{ll}
	& \lt(\ud{OM}.\n\rt)^2 + 2\lt(\ud{SO}.\n\rt)\lt(\ud{OM}.\n\rt)
	- \cos^2(\alpha)\|\ud{OM}\|^2 - 2\cos^2(\alpha)\ud{SO}.\ud{OM} + A\\
	= &
	\lt(\Z n_z\rt)^2 + \lt(R\cos(\theta)n_x\rt)^2 + \lt(R\sin(\theta)n_y\rt)^2\\
	& + 2\Z R\cos(\theta)n_xn_Z + 2\Z R\sin(\theta)n_yn_z + 2R^2\cos(\theta)\sin(\theta)n_xn_y\\
	& +2\lt(\ud{SO}.\n\rt)\lt(\Z n_z + R\cos(\theta)n_x + R\sin(\theta)n_y\rt)\\
	& - \cos^2(\alpha)\Z^2 - \cos^2(\alpha)R^2\\
	& + 2\cos^2(\alpha)\lt(\Z z_S + Rx_S\cos(\theta) + Ry_S\sin(\theta)\rt) + A
\end{array}
$$

\section{Parametric equation}

\subsection{From bragg angle and parameter to local cartesian coordinates}

\appendix
\chapter{Appendices}

\section{Section}
\subsection{Subsection}

\end{document}


\chapter{Generalised Least Squares}


\section{Limitations and open perspectives}

MOFA solves important challenges for the integrative analysis of (single-cell) multi-omics datasets. Yet, the model is not free of limitations and there are open possibilities for future research:

\begin{itemize}

	\item \textbf{Linearity}: this is an assumption that is critical for obtaining interpretable feature weights. Nonetheless, there is a trade-off between explanatory power and interpretability\cite{Kuhn}. Non-linear approaches, including deep neural networks or variational autoencoders have shown promising results when it comes to dimensionality reduction \cite{Lin2017,Ding2018,Lopez2018}, batch correction\cite{Lopez2018}, denoising \cite{Eraslan2019} or imputation \cite{Lin2016}. Interestingly, very few multi-view factor analysis models exist that incorporate flexible non-linear assumptions, making it an interesting line of research to explore.

	\item \textbf{Scalability}: the size of biological datasets is rapidly increasing, particularly in the field of single cell sequencing \cite{Svensson2018,Cao2019}. When comparing the inference framework to previous methods that make use of sampling-based MCMC approaches, the variatonal framework implemented in MOFA yields a vast improvement in scalability. Yet, in its vanilla form, variational inference also becomes prohibitively slow with very large datasets \cite{Hoffman2013,Blei2016,Hoffman2014}. This has been recently addressed by a reformulation of the variational inference problem in terms of a gradient descent optimisation problem, which enables the full machinery of stochastic inference to be applied in the context of Bayesian inference. This line of research is followed in Chapter 5, with the development of a stochastic version of the variational inference algorithm.

	\item \textbf{Generalisations to multi-group structures}: the sparsity assumptions in MOFA are based on the principle that features are structured into non-overlapping views. As such, the activity of the latent factors is also expected to be structured, so that different factors explain variability in different subsets of views (\Cref{fig:MOFA}). Following the same logic, many studies contain structured samples, as either multiple experiments or conditions. A simple generalisation of MOFA would be to intuitively break the assumption of independent samples and introduce an additional prior that captures the group structure at the sample level. This line of research is followed in Chapter 5.

	% \item \textbf{Tailored likelihoods for single-cell assays}: MOFA enables the modular extension to arbitrary non-Gaussian likelihoods, provided that they can be locally bounded and integrated into the variational framework (see \Cref{section:mofa_ngaussian}). New likelihood models such as zero-inflated negative binomial distributions \cite{Risso2018} could make MOFA more suited to the analysis of single-cell data.

	\item \textbf{Bayesian treatment of predictions}: in the current implementation of MOFA, only the point estimates for the posterior distributions are used in the downstream analysis. While convienient for most operations, this ignores the uncertainity associated with the point estimates, which is a major strength of Bayesian modelling. Future extensions could attempt a more comprehensive Bayesian treatment that propagates uncertainity in the downstream analyses, mainly when it comes to making predictions and imputation \cite{Gelman2013}.

	\item \textbf{Incorporation of prior information}: an unsupervised approach is appealing for discovering the principal axes of variation, but sometimes this can yield challenges in the interpretation of factors. Future extensions could exploit the rich information encoded in gene set ontologies, similar to the methodology proposed in \cite{Buettner2017}.

	\item \textbf{View imbalance}: a property of MOFA is that the number of features can influence the contribution of a data modality to the latent space, such that bigger views tend to contribute more to the factors. This is because the objective function (the evidence lower bound, ELBO) does not weight the different data modalities according to their number of features. This is not necessarily a problem, as we have demonstrated in \Cref{section:mofa_cll}, where we extracted meaningful signal from small data modalities. In general, however, the signal that can be extracted from small data modalities will depend on the degree of structure within the dataset, the levels of noise and on how strong the feature imbalance is between data modalities. In practice we suggest users to try balance the number of features by subsetting highly variable features in the larger views. An alternative option would be to weight the contribution of each view on the ELBO, such that small views have a relatively higher contribution than large views. This is however a heuristic that does not arise from the Bayesian generative model and there would be no theoretical guarantees about its behaviour.

\end{itemize}


\chapter{Some chapter}
This is a chapter.

\section{\texorpdfstring{$L^p$}{L\^{}p} spaces}
A section.


\section{Modelling REDFIN in Haskell}\label{sec-transformer}

In this section we formally define the REDFIN microarchitecture and express the
semantics of the instruction set as an explicit and symbolic state transformer.

\begin{figure}[t]
\begin{minted}[xleftmargin=10pt]{haskell}
data State = State
  { registers           :: RegisterBank
  , memory              :: Memory
  , instructionCounter  :: InstructionAddress
  , instructionRegister :: InstructionCode
  , program             :: Program
  , flags               :: Flags
  , clock               :: Clock }

type Register           = SymbolicValue Word2
type Value              = SymbolicValue Int64
type RegisterBank       = SymbolicArray Word2 Int64
type MemoryAddress      = SymbolicValue Word8
type Memory             = SymbolicArray Word8 Int64

type InstructionAddress = SymbolicValue Word8
type InstructionCode    = SymbolicValue Word16
type Program            = SymbolicArray Word8 Word16

data Flag               = Condition@\,@|@\,@Overflow@\,@|@\,@Halt@\,@...
type Flags              = SymbolicArray Flag Bool
type Clock              = SymbolicValue Word64
\end{minted}
\caption{Basic types for modelling REDFIN.\label{fig-types}}
\end{figure}

\subsection{The REDFIN Microarchitecture State}

The main idea of our approach is to use an explicit state transformer
semantics of the REDFIN microarchitecture. The \hs{State} of the entire
processing core is a product of states of every component, see
Fig.~\ref{fig-types}. We define \hs{SymbolicValue} and \hs{SymbolicArray} on top
of the SBV library~\cite{SBV} that we use as a frontend for SMT translation and
verification.

% \begin{equation*}
% \begin{split}
% S=\{(r, m, ic, ir, p, f, c) : r \in R, m \in M, ic \in A, \\ir \in I,
% p \in P, f \in F, c \in C\},
% \end{split}
% \end{equation*}

% \noindent
% where $R$ is the set of register bank configurations;
% $M$ is the memory state space;
% $A$~is the set of instruction addresses (the instruction counter $ic$ stores the
% address of the current instruction);
% $I$ is the set of instruction codes (the instruction register $ir$ stores the
% code of the current instruction);
% $P$ is the set of programs;
% $F$ is the set of the flag register configurations; and
% $C$ is the set of clock values.

% Fig.~\ref{fig-types} shows the translation of the above into Haskell types. Note
% that the types are not parameterised: recall that REDFIN is parameterised, e.g.
% the data width can be chosen depending on mission requirements, whereas we use fixed
% 64-bit data path for the sake of simplicity. The chosen names are self-explanatory,
% for example, the data type \hs{State} directly corresponds to the set of states~$S$.

% \todo{In principle, any other SMT frontend
% can be used, but to the best of our knowledge, SBV is the most mature SMT library
% available for Haskell. \textbf{No, SBV here is crucial because it does all the actual symbolic execution}} We briefly overview all \hs{State} components below.

% \subsubsection{Data values, registers and memory}

There are~4 registers (addressed by \hs{Word2}) and 256 memory cells (addressed
by \hs{Word8}) that store 64-bit values (\hs{Int64}). The register bank and
memory are represented by symbolic arrays
that can be accessed via SBV's functions \hs{readArray} and \hs{writeArray}.
REDFIN uses 16-bit \hs{InstructionCode}s, whose 6 leading bits contain the
opcode, and the remaining 10 bits hold instruction arguments. The \hs{Program}
maps 8-bit instruction addresses to instruction codes.

The microarchitecture status \hs{Flags} support conditional branching, track
integer overflow, and terminate the program (we omit a few other flags for
brevity).
The \hs{Clock} is a 64-bit counter
incremented on each clock cycle. Status flags and the clock are used for
diagnostics, formal verification, and worst-case execution time analysis.

\subsection{Instruction and Program Semantics}

We can now define the formal semantics of REDFIN instructions and programs as a
\emph{state transformer} $T : S \rightarrow S$, i.e. a function that maps
states to states. We distinguish instructions and programs by using
Haskell's list notation, e.g. $T_{\subhs{nop}}$ is the semantics of the
instruction $\hs{nop} \in I$, whereas $T_{\subhs{[}\subhs{nop}\subhs{]}}$ is the
semantics of the single-instruction program $\hs{[}\hs{nop}\hs{]} \in P$.
\footnote{REDFIN does not have a dedicated \hs{nop} instruction, but it can be
expressed as a jump to the next instruction, i.e.~\hs{jmpi 0}.}

\vspace{-1.5mm}
\noindent\hrulefill~\\
\vspace{-3.5mm}

\noindent
\textbf{Definition (program semantics):} The semantics of a program $p \in P$
is inductively defined as follows:

% \begin{itemize}
% \item
    The semantics of the \emph{empty program} $\hs{[}\hs{]} \in P$ coincides with
    the semantics of the instruction \hs{nop} and is the identity state transformer:
    $T_{\subhs{[}\subhs{]}} = T_{\subhs{nop}} = \hs{id}$.

    % \item
    The semantics of a \emph{single-instruction program} $\hs{[}\hs{i}\hs{]} \in P$
    is a composition of (i) fetching the instruction from
    the program memory~$T_\textit{fetch}$, (ii) incrementing the
    instruction counter~$T_\textit{inc}$, and (iii) the state transformer
    of the instruction itself~$T_{\subhs{i}}$; or,~using the order of state
    components from Fig.~\ref{fig-types}:
    \vspace{-1mm}
    \[
    \begin{array}{lcl}
    T_\textit{fetch} & = & (r, m, ic, ir, p, f, c) \mapsto (r, m, ic, p[ic], p, f, c + 1)\\
    T_\textit{inc} & = & (r, m, ic, ir, p, f, c) \mapsto (r, m, ic + 1, ir, p, f, c)\\
    T_{\subhs{[}\subhs{i}\subhs{]}} & = & T_{\subhs{i}} \circ T_\textit{inc} \circ T_\textit{fetch}\\
    \end{array}
    \]

    \noindent
    The semantics of a \emph{composite program} $\hs{i}\hs{:}\hs{p} \in P$,
    where the operator~\hs{:}~prepends an instruction $\hs{i} \in I$ to a program
    $\hs{p} \in P$, is defined as $T_{\subhs{i}\subhs{:}\subhs{p}} = T_{\hs{p}} \circ T_{\subhs{[}\subhs{i}\subhs{]}}$.

% \end{itemize}

\vspace{-1mm}
\noindent\hrulefill~\\
\vspace{-3mm}

% \noindent
We represent state transformers in Haskell using the \emph{state monad}, a
classic approach to emulating mutable state in a purely functional programming
language~\cite{wadler1990comprehending}. We call our state monad~\hs{Redfin} and
define it as follows\footnote{A generic version of this monad is available in
the standard module \hs{Control.Monad.State}.}:

\begin{minted}[xleftmargin=10pt]{haskell}
data Redfin a = Redfin { transform :: State -> (a, State) }
\end{minted}

\noindent
A computation of type~\hs{Redfin}~\hs{a} yields a value of type~\hs{a}~and
possibly alters the \hs{State} of the REDFIN microarchitecture.
The type \hs{Redfin}~\hs{()} describes a computation that does not produce any
value as part of the state transformation; such computations directly correspond
to state transformers.

\noindent
For example, here is the state transformer $T_\textit{inc}$:

\begin{minted}[xleftmargin=10pt]{haskell}
incrementInstructionCounter :: Redfin ()
incrementInstructionCounter = Redfin $ \current -> ((), next)
  where
    next = current { instructionCounter = instructionCounter current + 1 }
\end{minted}

\noindent
In words, the state transformer looks up the value of the \hs{instructionCounter}
in the \hs{current} state and replaces it in the \hs{next} state with the
incremented value. We can compose such primitive computations into more complex
state transformers using Haskell's \hs{do}-notation:

\begin{minted}[xleftmargin=10pt]{haskell}
readInstructionRegister :: Redfin InstructionCode
readInstructionRegister = Redfin $ \s -> (instructionRegister s, s)

executeInstruction :: Redfin ()
executeInstruction = do
    fetchInstruction
    incrementInstructionCounter
    instructionCode <- readInstructionRegister
    decodeAndExecute instructionCode
\end{minted}

\noindent
Here \hs{readInstructionRegister} reads the instruction code from the current
state \emph{without modifying it}, and is subsequently used in \hs{executeInstruction},
which defines the semantics of the REDFIN execution cycle. We omit definitions of
\hs{fetchInstruction} and \hs{decodeAndExecute} for brevity. The latter is a
case analysis of 47 opcodes that returns the matching instruction. We discuss
several instructions below.

\subsubsection{Halting the Processor}
The instruction~\hs{halt} sets the flag~\hs{Halt}, which stops the execution of
the current subroutine until a new one is started by a higher-level system
controller that resets~\hs{Halt}.

\begin{minted}[xleftmargin=10pt]{haskell}
halt :: Redfin ()
halt = writeFlag Halt true
\end{minted}

\noindent
The auxiliary function \hs{writeFlag} modifies the flag:

\begin{minted}[xleftmargin=10pt]{haskell}
writeFlag :: Flag -> SymbolicValue Bool -> Redfin ()
writeFlag flag value = Redfin $ \s -> ((), s')
  where
    s' = s { flags = writeArray (flags s) (flagId flag) value }
\end{minted}

\noindent
In the rest of the paper we will use auxiliary functions \hs{readRegister},
\hs{writeRegister}, \hs{readState}, etc.; they are simple state transformers
defined similarly to \hs{writeFlag}.

\subsubsection{Arithmetics}
The instruction \hs{abs} is more involved:
it reads a register and writes back the absolute value of its contents.
The semantics accounts for the potential integer overflow that leads to the
\emph{negative resulting value} when the input is $-2^{63}$ (REDFIN uses the
common two's complement signed number representation). The overflow is flagged
by setting~\hs{Overflow}. We use SBV's symbolic \emph{if-then-else}
operation~\hs{ite} to \emph{merge} two symbolic values~---~in this case two
possible next states, one of which is a state with the \hs{Overflow} flag set:

\begin{minted}[xleftmargin=10pt]{haskell}
abs :: Register -> Redfin ()
abs reg = do
    state  <- readState
    result <- fmap Prelude.abs (readRegister reg)
    let (_, state') = transform (writeFlag Overflow true) state
    writeState $ ite (result .< 0) state' state
    writeRegister reg result
\end{minted}

\subsubsection{Conditional Branching}
As an example of a control flow instruction consider \hs{jmpi_ct}, which
tests the~\hs{Condition} flag, and adds the provided \hs{offset} to the
instruction counter if the flag is set.

\begin{minted}[xleftmargin=10pt]{haskell}
jmpi_ct :: SymbolicValue Int8 -> Redfin ()
jmpi_ct offset = do
    ic <- readInstructionCounter
    condition <- readFlag Condition
    let ic' = ite condition (ic + offset) ic
    writeInstructionCounter ic'
\end{minted}

\noindent
% After working through the above examples, it is worth noting that
We use our Haskell encoding of the state transformer as a~\emph{metalanguage}:
we operate the REDFIN core as a puppet master, using external meta-notions of
addition, comparison and let-binding. From the processor's
point of view, we have infinite memory and act instantly, which gives us unlimited
modelling power. For example, we can simulate the processor environment
in an external tool and feed its result to \hs{writeRegister} as if it was
obtained in one clock cycle.

\subsection{Symbolic simulation}

Having defined the semantics of REDFIN programs, we can perform
\emph{symbolic processor simulation}.

There are many flavours of symbolic execution~\cite{SurveySymExec-CSUR18}
and there is no single answer to the question of which one is the best.
The choice of the symbolic execution technique depends heavily on the
verification scenarios. The verification framework for REDFIN is designed
to deal with two main classes of programs: (i) arithmetic calculations that
are statically provable to be terminating and (ii) control programs with
unbounded loops whose termination depend on dynamic input data. We approach
verification of the former using~\emph{symbolic execution with merging} that
allows for whole-program verification by translating the program and the
verification condition into a single SMT formula. However, unconditional merging
does not work for non-terminating programs.~To~verify those, we use an
alternative approach to symbolic execution, which constructs tree-shaped traces
with multiple execution paths that can be analysed and verified separately. The
presented framework thus works in two modes --- \emph{merging} and
\emph{branching} --- see examples in~\S\ref{sec-verification}
and~\S\ref{sec-motor-control}, respectively.

\subsubsection{Merging Mode}

The function \hs{simulate} takes a number of simulation steps~$N$ and an initial
symbolic \hs{State} as input, and runs \hs{executeInstruction} defined above~$N$
times. In each \hs{state} we merge two possible futures: (i) if the \hs{Halt}
flag is set, we stop the simulation and remain in the current \hs{state},
since in this case the processor must remain idle; (ii) otherwise we continue
the simulation from the~\hs{future}~state.

\begin{minted}[xleftmargin=10pt]{haskell}
simulate :: Int -> State -> State
simulate steps state =
    let halted = readArray (flags state) (flagId Halt)
    in if steps <= 0
       then state
       else let future = snd (transform executeInstruction state)
            in  ite halted state (simulate (steps-1) future)
\end{minted}

\noindent
The function~\hs{ite} performs symbolic merging of two possible next states,
depending on whether the program has \hs{halted}. As we have seen, the semantics
of individual instructions, as captured by \hs{executeInstruction}, also uses
\hs{ite} to merge possible next states when encountering choices, thereby
resulting in a linear simulation path.

\subsubsection{Branching Mode}

In the branching mode, on the contrary, we do not perform any merging at all and
generate a tree of simulation paths where every node contains a program state
with an associated~\emph{path condition} --- a symbolic Boolean expression
that encodes the choices taken along the path leading to the node.

To implement the branching semantics, we modify the~\hs{Redfin} monad by adding
support for non-determinism and tracking of path conditions. While we omit
the details, below we show how the types of the main simulation functions,
\hs{executeInstruction} and \hs{simulate}, need to change. The former becomes a
non-deterministic function that can return multiple next states:

\begin{minted}[fontsize=\small,xleftmargin=10pt]{haskell}
executeInstruction :: (State, SymbolicValue Bool) -> [(State, SymbolicValue Bool)]
\end{minted}

\noindent
For example, it will return two states in the case of the conditional jump
instruction~\hs{jmpi_ct} instead of merging them with \hs{ite}. The path
condition (of type~\hs{SymbolicValue}~\hs{Bool}) will be conjoined with the jump
condition for the first returned state, and with its negation for the second.

The type of~\hs{simulate} becomes more involved too. Since the semantics of
individual instructions now produces multiple next states, the symbolic
execution trace naturally grows into a tree:

\begin{minted}[fontsize=\small,xleftmargin=10pt]{haskell}
data Tree a = Node a [Tree a]
\end{minted}
\begin{minted}[fontsize=\small,xleftmargin=10pt]{haskell}
simulate :: Int -> (State, SymbolicValue Bool) -> Tree (State, SymbolicValue Bool)
\end{minted}

\noindent
The simulation starts form an initial state with a path condition representing
the precondition of the program, which can be instantiated with~\hs{true} if no
precondition is imposed. Proceeding further, more successor states can stem from
every state, until either the \hs{halt} instruction is encountered or the maximum
number of simulation steps is reached.

Symbolic simulation is very powerful. It allows us to formally verify properties
of REDFIN programs by fixing some parts of the state to constant values (e.g.,
the program), and then making assertions on the symbolic part of the resulting
state, as demonstrated in sections~\S\ref{sec-verification}
and~\S\ref{sec-motor-control}.


\subsubsection{Cap/Floor}

The \lstinline!CapFloorData! node is the trade data container for the \emph{CapFloor} trade type.  It's a cap, floor or collar
(i.e. a portfolio of a long cap and a short floor for a long position in the collar) on a series of Ibor or CMS rates. The
\lstinline!CapFloorData! node contains a \lstinline!LongShort! sub-node which indicates whether the cap (floor, collar)
is long or short, and a \lstinline!LegData!  sub-node where the
LegType can be set to \emph{Floating}, \emph{CMS}, \emph{CPI}
or \emph{YY}, plus elements for the Cap and Floor rates. An example structure with Cap rates is shown in in Listing
\ref{lst:capfloor_data}. A \lstinline!CapFloorData! node must have either \lstinline!Caps! or \lstinline!Floors!
elements, or both. In the case of both (I.e. a collar with long cap and short floor) the sequence is that  \lstinline!Caps! elements must be above the \lstinline!Floors! elements. Note that
the \lstinline!Caps! and \lstinline!Floors! elements must be outside the \lstinline!LegData! sub-node, i.e. a \emph{CapFloor}
can't have a capped or floored  \emph{Floating}  or \emph{CMS} leg.

\begin{listing}[H]
%\hrule\medskip
\begin{minted}[fontsize=\footnotesize]{xml}
<CapFloorData>
  <LongShort>Long</LongShort>
  <LegData>
    <Payer>false</Payer>
    <LegType>Floating</LegType>
     ...
  </LegData>
  <Caps>
    <Cap>0.05</Cap>
  </Caps>
</CapFloorData>
\end{minted}
\caption{Cap/Floor data}
\label{lst:capfloor_data}
\end{listing}

The meanings and allowable values of the elements in the \lstinline!CapFloorData!  node follow below.

\begin{itemize}

\item LongShort: This node defines the position in the cap (floor, collar) and can take values \emph{Long} or \emph{Short}.

\item LegData: This is a trade component sub-node outlined in section \ref{ss:leg_data}. Exactly
  one \lstinline!LegData! node is allowed, and the LegType element must
  be set to \emph{Floating}, \emph{CMS}, \emph{CPI} or \emph{YY}.

\item Caps: This node has child elements of type \lstinline!Cap!
  capping the floating leg (after applying spread if any). The first rate value corresponds to the
  first coupon, the second rate value corresponds to the second
  coupon, etc. If the number of coupons exceeds the number of rate
  values, the rate will be kept flat at the value of last entered rate
  for the remaining coupons. For a fixed cap rate over all coupons,
  one single rate value is sufficient. The number of entered rate
  values cannot exceed the number of coupons.

  Allowable values for each \lstinline!Cap! element: Any real number. The rate is expressed in decimal form, eg 0.05 is
  a rate of 5\%

\item Floors: This node has child elements of type
  \lstinline!Floor! flooring the floating leg (after applying spread if any).  The first rate value
  corresponds to the first coupon, the second rate value corresponds
  to the second coupon, etc. If the number of coupons exceeds the
  number of rate values, the rate will be kept flat at the value of
  last entered rate for the remaining coupons. For a fixed floor rate
  over all coupons, one single rate value is sufficient. The number of
  entered rate values cannot exceed the number of coupons.

  Allowable values for each \lstinline!Floor! element: Any real number. The rate is expressed in decimal form, eg 0.05 is
  a rate of 5\%

\end{itemize}


\documentclass[a4paper,11pt]{article}
\usepackage[T1]{fontenc}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{amsthm}
\usepackage{amsfonts}
\usepackage{slashed}
\usepackage{dsfont}
\usepackage{hyperref}
\usepackage[pdftex]{graphicx}
\usepackage{epstopdf}
\usepackage{subfigure}
\usepackage{float}
\usepackage{tikz}
\usepackage{braket}
\usepackage{simplewick}
\usepackage{color}
\usepackage[utf8]{inputenc}

\hypersetup{
    pdftitle={The Time-Dependent Variational Principle for Matrix Product State, An Implementation},    % title
    pdfauthor={Ashley Milsted, Institute for Theoretical Physics, Leibniz Universität Hannover},     % author
    pdfkeywords={Matrix Product States} {Variational Principle} {Implementation}, % list of keywords
}

\tolerance=300
\newcommand{\id}{\mbox{$1 \hspace{-1.0mm} {\bf l}$}}

%opening
\title{The Time-Dependent Variational Principle for Matrix Product States\\
{\Large  An implementation}}
\author{Ashley Milsted,\\
		Institute for Theoretical Physics,\\
		Leibniz Universität Hannover
	   }
\begin{document}

\maketitle

\begin{abstract}
Efficient algorithms for the application of the time-dependent variational
principle (TDVP) to matrix product states (MPS) exist. This document describes
the differences between the algorithm for generic MPS
published by Haegeman et al. \cite{haegeman_time-dependent_2011}
and the one implemented in \emph{evoMPS},
as well as novel parts of the \emph{evoMPS} algorithm that
have not been published elsewhere.

This document provides a little background to MPS and the TDVP, and then
describes the key differences between the implementation of the TDVP algorithm
for generic MPS in \emph{evoMPS} and that described in \cite{haegeman_time-dependent_2011}.
\end{abstract}

\setcounter{tocdepth}{2}
\tableofcontents

\section{Introduction}
The matrix product state (MPS) representation of the state of a one-dimensional
quantum spin chain is known for its usefulness in efficiently simulating dynamics,
as well as in computing ground states (e.g. via imaginary time evolution), due
to its ability to efficiently capture states that have a limited amount of
entanglement \cite{vidal_efficient_2003}, \cite{verstraete_matrix_2008}.

An efficient algorithm for the application of the time-dependent variational
principle (TDVP) to MPS for the generic (not
translationally invariant) case was first described by Haegeman et al.
\cite{haegeman_time-dependent_2011}, who also set out and implemented an algorithm for the
translationally invariant case (uniform MPS or uMPS). The former has now also been implemented, with some
modifications with respect to the published version, in \emph{evoMPS}.

\subsection{The Matrix Product State Representation}
The MPS representation of a state $\ket{\Psi}$, for a one-dimensional spin chain
of finite length $N$ with open boundary conditions, can be written as
\begin{equation}
    \ket{\Psi[A]} = \sum_{s_1 \dots s_N=1}^{q_1 \dots q_N} A_{1}^{s_1} \dots A_{N}^{s_N} \ket{s_1, \dots , s_N}
    \label{eq:MPS_Def}
\end{equation}
where each $A_n^{s_n}$ represents a $D_{n - 1} \times D_n$ matrix, which will
henceforth be abbreviated to $A^{s_n}$.
$D_n$ is called the \emph{bond dimension} %TODO: Explain
and $q_n$ is the dimension of the Hilbert space
$\mathcal{H}_n = \mathbb{C}^{q_n}$ of a site on the chain. The left and right
boundary vectors have been absorbed into the first and last matrices respectively,
so that $D_0 = D_N = 1$.
The boundary vectors have been included
in the end-site matrices $A^{s_1}$ and $A^{s_N}$, which are therefore row and column
vectors respectively.

For the calculation of expectation values, the norm of the state and other
quantities, it is useful to define the left and right density matrices
\begin{equation}
	l_n = \sum_{s_n} {A^{s_n}}^\dagger l_{n-1} A^{s_n}
	\label{eq:Dens_L}
\end{equation}
\begin{equation}
	r_{n - 1} = \sum_{s_n} A^{s_n}  r_{n} {A^{s_n}}^\dagger
	\label{eq:Dens_R}
\end{equation}
where $l_0 = r_N = 1$. As can be seen by writing out the norm of (\ref{eq:MPS_Def}),
$l_N = r_0 = \braket{\Psi[A] | \Psi[A]}$.

\subsection{Gauge Freedom}
A state represented in the above MPS form is invariant under gauge transformations
\begin{equation}
    A^{s_n} \rightarrow g_{n - 1} A^{s_n} g_{n}^{-1}
    \label{eq:MPS_GF}
\end{equation}
where the $g_n$ are $D_n \times D_n$ invertible matrices and $g_0 = g_N \in \mathbb{C}$,
as can easily be verified.

\subsection{The Time Dependent Variational Principle for Matrix Product States}
The TDVP works by projecting the exact time evolution of a state
\begin{equation}
    \mathrm{i} \frac{\mathrm{d}}{\mathrm{d}t} \ket{\Psi(t)} = \hat{H}(t) \ket{\Psi(t)}
\end{equation}
(with units such that $\hbar = 1$)
onto a variational manifold within the Hilbert space belonging to the system.
The class of MPS with fixed bond dimensions $D_n$ defines such a variational
manifold $\mathcal{M}_{\mathrm{MPS}\{ D_n \}}$ where the $D_n$ are generally chosen to
be less than would be required to exactly represent any state of the system. In this
way, the computational complexity of the problem can be reduced by sacrificing the
ability to represent states with higher levels of entanglement \cite{vidal_efficient_2003}.

Since the variational manifold is, for
practical purposes, smaller than the Hilbert space, projecting $\hat{H}(t) \ket{\Psi(t)}$
onto the manifold involves finding a tangent vector $\ket{\Phi}$ on
the manifold that best approximates the exact time
evolution.

For MPS, a general tangent vector has the form
\begin{equation}
	\ket{\Phi[B;A]} = \sum^N_{n=1} \sum^{q_n}_{s_n=1} B^{s_n} \frac{\partial}{\partial A^{s_n}} \ket{\Psi[A]}
	\label{eq:MPS_Gen_Tang}
\end{equation}
The tangent vector best approximating $\hat{H}(t) \ket{\Psi(t)}$ can then be written as
$\ket{\Phi[B^*(t);A(t)]}$ where
\begin{equation}
    B^*(t) = \arg_B \mathrm{min} \| \ket{\Phi[B;A(t)]} - \hat{H}(t)\ket{\Psi[A(t)]} \|^2
    \label{eq:TDVP_MPS_OptB}
\end{equation}
Here, $A$ and $B$ represent the set of all matrices $A^{s_n}$ and $B^{s_n}$.

At first sight, calculation of the optimal parameters ${B^{s_n}}^*$ involves evaluating
$\braket{\Phi[\bar{B}] | \Phi[B]}$, which, as can be seen from (\ref{eq:MPS_Gen_Tang}),
includes terms that mix the ${B^{s_n}}$ for different sites. Finding $B^*$ would
therefore require an iterative algorithm that sweeps over the chain several times.

Conveniently, the gauge freedom in the MPS representation (\ref{eq:MPS_GF}) can
be exploited to eliminate the site-mixing terms in
$\braket{\Phi[\bar{B}] | \Phi[B]}$ such that sweeping is no longer required. This
is achieved by restricting the choice of $B^{s_n}$, using a parametrization,
to those that alter only the physical degrees of freedom (those that
maintain the current gauge choice). This leads to the
efficient algorithm for the TDVP set out in \cite{haegeman_time-dependent_2011}.

\section{Differences in the \emph{evoMPS} Implementation of the TDVP for MPS}

\subsection{Parametrization of the Tangent Space}
The gauge freedom inherent in the MPS representation can be exploited to
greatly simplify the application of the TDVP.
The set of tangent vectors
$\mathbb{T}_\mathrm{MPS}[A]$ at a given point $A$ on the variational manifold
$\mathcal{M}_\mathrm{MPS\{D_n\}}$ can be parametrized
in a way that eliminates all non-physical degrees of freedom and, simultaneously,
eliminates all non-local (site-mixing) terms from $\braket{\Phi[\bar{B}] | \Phi[B]}$,
which must be evaluated in a TDVP implementation.

A parametrization of the tangent space $B^{s_n}[x_n]$ in terms of
matrices $x_n$
is chosen so that each $B^{s_n}$ satisfies a gauge-fixing condition.
In \cite{haegeman_time-dependent_2011}, the \emph{left} gauge-fixing condition
\begin{equation}
    \sum_{s_n=1}^{q_n} {A^{s_n}}^\dagger l_{n - 1} B^{s_n} = 0 \quad \forall n \in 1 \dots N
\end{equation}
is used, leading to a parametrization
\begin{equation}
    B^{s_n}(x_n) = l_{n - 1}^{-1/2} V_L^{s_n} x_n r_n^{-1/2}
    \label{eq:B_par_L}
\end{equation}
where $[V_L^{s_n}]_{\alpha,\beta} = [V_{L,n}]_{(s_n, \alpha);\beta}$ is defined to
contain an orthonormal basis for the null space of the matrix $L_n$
($L_n V_{L,n} = 0$ and $V_{L,n}^\dagger V_{L,n} = \id$)
with
\begin{equation}
    [L_n]_{\alpha; (s_n, \beta)} = [{A^{s_n}}^\dagger l_{n-1}^{1/2}]_{\alpha, \beta}
\end{equation}
In \emph{evoMPS}, the \emph{right} gauge-fixing condition
\begin{equation}
    \sum_{s_n=1}^{q_n} {B^{s_n}} r_{n} {A^{s_n}}^\dagger = 0 \quad \forall n \in 1 \dots N
\end{equation}
is used instead, with the corresponding parametrization
\begin{equation}
    B^{s_n}(x_n) = l_{n - 1}^{-1/2} x_n V_R^{s_n} r_n^{-1/2}
    \label{eq:B_par_R}
\end{equation}
Here, $[V_R^{s_n}]_{\alpha,\beta} = [V_{R,n}]_{\alpha;(s, \beta)}$ contains an
orthonormal basis for the null space of $R_n$ ($V_{R,n} R_n = 0$ and
$V_{R,n} V_{R,n}^\dagger = \id$) defined as
\begin{equation}
    [R_n]_{(s_n, \alpha); \beta} = [r_{n}^{1/2} {A^{s_n}}^\dagger]_{\alpha, \beta}
\end{equation}
That the parametrizations satisfy the respective gauge-fixing conditions can
easily be confirmed.

\subsection{Norm-Preserving Dynamics}
The TDVP can be modified so that the projection onto the variational manifold
explicitly preserves the norm of the the state. In \cite{haegeman_time-dependent_2011},
this norm-preserving form of the TDVP was described, with (\ref{eq:TDVP_MPS_OptB}) becoming
\begin{equation}
    B^*(t) = \arg_B \mathrm{min} \| \ket{\Phi[B;A(t)]} - \left[\hat{H}(t) - H(t)\right]\ket{\Psi[A(t)]} \|^2
    \label{eq:TDVP_MPS_OptB_NP}
\end{equation}
In \cite{haegeman_time-dependent_2011}, $\hat{H}(t) - H(t)$ is present in
the final TDVP algorithm for generic MPS. However, this is not necessary when using
a tangent space that excludes changes to the norm ($\braket{\Phi[B;A(t)]|\Psi[A]} = 0$),
as is the case for the gauge-fixing parametrizations (\ref{eq:B_par_L}) and (\ref{eq:B_par_R}).
In this case, (\ref{eq:TDVP_MPS_OptB_NP}) and (\ref{eq:TDVP_MPS_OptB}) are equivalent,
as can easily be seen.

In \emph{evoMPS}, this simplification is used in the implementation of the TDVP algorithm.

\subsection{Inclusion of a Single-Site Hamiltonian Term}
A single-site Hamiltonian term can be included in the nearest-neighbour term (making
it non-uniform, if it was uniform before),
thus allowing an algorithm designed for a non-uniform nearest-neighbour
Hamiltonian to be used in this case too. However, it is also straightforward to introduce single-site
terms into the algorithm for the TDVP explicitly, which has been done in \emph{evoMPS}.
See the next subsection for an example.

\subsection{Implications for the Algorithm}
Apart from the obvious differences in the parametrization of the tangent
vectors, the choice of left or right gauge fixing determines how terms like
$\bra{\Phi[\bar{B}]}\hat{H}\ket{\Psi[A]}$ are calculated, since the left and
right gauge fixing choices eliminate different terms in the resulting sum.

The lack of a need to use the explicitly norm-preserving form of the TDVP
(\ref{eq:TDVP_MPS_OptB_NP}) means, compared to
\cite{haegeman_time-dependent_2011}, merely changing $(\hat{H} - H)$ to $\hat{H}$
or, for a nearest-neighbour Hamiltonian $\hat{H} = \sum_n \hat{h}_{n, n+1}$
changing $(\hat{h}_{n, n + 1} - h_{n, n + 1})$ to $\hat{h}_{n, n + 1}$, where
$\hat{h}_{n, n + 1}$ is the nearest neighbour term for sites $n$ and $n + 1$.

To illustrate the required changes to the algorithm published by Haegeman et al.,
the matrices $C^{s_n,t_n}$ defined on page 14 of
\cite{haegeman_time-dependent_2011} become, in \emph{evoMPS},
\begin{equation}
	C^{s_n, t_{n + 1}} = \sum_{u_n, v_{n + 1}}^{q_n, q_{n+1}} \braket{s_n, t_{n + 1} | \hat{h}_{n, n + 1} | u_n, v_{n + 1}} A^{u_n} A^{v_{n+1}}
\end{equation}
and the matrices $K_n$ used to evaluate the Hamiltonian as required for the calculation of
(\ref{eq:TDVP_MPS_OptB}) become
\begin{align}
	\nonumber K_n = & \theta(n < N) \left[ \sum_{s_n, t_{n + 1}}^{q_n, q_{n+1}} C^{s_n, t_{n + 1}} r_{n+1} {A^{t_{n + 1}}}^\dagger {A^{s_{n}}}^\dagger + \sum_{s_n}^{q_n} A^{s_n}K_{n+1}{A^{s_n}}^\dagger \right] \\
	&  + \sum_{s_n, t_n}^{q_n, q_n} \braket{s_n | \hat{h}_n^{\mathrm{s.s.}} | t_n} A^{t_n} r_n {A^{s_n}}^\dagger
\end{align}
where $K_{N+1} = 0$ and the recursion now runs from right to left due to the decision to use right gauge-fixing. $\theta$ is the Heaviside step function. $\hat{h}^\mathrm{s.s.}_n$ is the single-site Hamiltonian term
for site $n$. Since the $H$ term from (\ref{eq:TDVP_MPS_OptB_NP}) was eliminated,
$K_1 = \braket{\Psi[A] | \hat{H} | \Psi[A]}$ and gives us the energy expectation value (for a normalized state).

The $F_n = x_n^*$ matrices in \cite{haegeman_time-dependent_2011} that represent the projection of the exact time evolution onto the MPS
tangent space are, of course, also calculated differently in \emph{evoMPS} due to right gauge-fixing and
due to the inclusion of an extra term for the single-site part of the Hamiltonian.

\section{Additional Numerical Integration Methods}
Some features have been added to the algorithm for \emph{evoMPS} that are not described,
at least for the non-uniform case, in \cite{haegeman_time-dependent_2011}. For example,
Haegeman et al. describe a time-symmetrical implicit method for numerically integrating
the TDVP flow equations for the translationally invariant case (uniform MPS). A modified
version has been implemented for the non-uniform case in \emph{evoMPS}.
Additionally, the explicit fourth-order Runge-Kutta method has been implemented.

\subsection{Implicit Midpoint Method}
In \cite{haegeman_time-dependent_2011}, a numerical integration scheme is described
for the uniform MPS case which
is time-symmetric, and has a lower order error than the simple forward Euler method.
It is intended to produce better results when simulating real time evolution, where
errors accumulate over time.

It is an implicit midpoint method, where a midpoint $\ket{\Psi[A(t + dt/2)]}$ between
$\ket{\Psi[A(t)]}$ and $\ket{\Psi[A(t + dt)]}$
is first determined via the backward Euler method by iteratively solving an implicit
equation. From the midpoint,
a further forward Euler step of $dt/2$ is taken to produce the point $\ket{\Psi[A(t + dt)]}$.

This method is complicated by the gauge freedom (\ref{eq:MPS_GF}) because a finite step
will, despite using a gauge-fixing parametrization of the tangent space, generally alter
$A$ along the gauge degrees of freedom by a small amount. For this reason, iteratively solving
the implicit equation to find the midpoint requires a
gauge transformation to ensure that only physical degrees of freedom are compared.

For \emph{evoMPS}, the midpoint method for uMPS has been adapted to generic MPS,
where the implicit equation
for the midpoint $\tilde{A}^{s_n} := A^{s_n}(t + dt/2)$ becomes
\begin{equation}
    g_{n-1}^{-1} A^{s_n} g_n = \tilde{A}^{s_n} - \mathrm{i} \frac{dt}{2} B^{s_n}(\tilde{x}_n)
    \label{eq:Midpoint_Impl}
\end{equation}
where $A^{s_n} = A^{s_n}(t)$ and $g_{n-1}$ is computed by solving
\begin{equation}
	\sum_{s_n} A^{s_n} g_n \tilde{r}_n \tilde{A}^{s_n} = g_{n-1} \tilde{r}_{n-1}
    \label{eq:Midpoint_GT}
\end{equation}
Starting from an initial forward Euler estimate
\begin{equation}
	\tilde{A}^{s_n}_0 = A^{s_n} + \mathrm{i} \frac{dt}{2} B^{s_n}(x_{n})
	\label{eq:Midpoint_Init_Step}
\end{equation}
where the subscript $0$ indicates the current iteration,
the equation can be solved iteratively for $A^{s_n}(t + dt/2)$ by setting
\begin{equation}
	\tilde{A}^{s_n}_1 = \tilde{A}^{s_n}_0 + d\tilde{A}^{s_n}_0
	\label{eq:Midpoint_ItrNext}
\end{equation}
where
\begin{equation}
	d\tilde{A}^{s_n}_0 = g_{n-1}^{-1} A^{s_n} g_n - \tilde{A}^{s_n}_0 + \mathrm{i} \frac{dt}{2} B^{s_n}(\tilde{x}_{n, 0})
	\label{eq:Midpoint_dA}
\end{equation}
To quantify convergence, the size of the correction $d\tilde{A}^{s_n}$ for site $n$ can be used
\begin{equation}
	\zeta_n = \| d\tilde{A}^{s_n}\frac{\partial}{\partial A^{s_n}} \ket{\Psi[\tilde{A}]} \|= \mathrm{tr} \left[ \tilde{l}_{n-1} \sum_{s_n} d\tilde{A}^{s_n} \tilde{r}_n {d\tilde{A}^{s_n}}^\dagger \right]^{1/2}
	\label{eq:Midpoint_Err}
\end{equation}
and an overall error measure can be defined as
\begin{equation}
	\zeta = \sum_n \zeta_n
	\label{eq:Midpoint_Err_All}
\end{equation}
To solve (\ref{eq:Midpoint_Impl}) for the whole state:
\begin{enumerate}
	\item Evaluate (\ref{eq:Midpoint_Init_Step}) for all $s_n$ to get the initial estimate for $\tilde{A}$.
	\item Set $n \leftarrow N$ and $g_n \leftarrow 1$. \label{enum:Midpoint_StartChain}
	\item Solve (\ref{eq:Midpoint_GT}) to find $g_{n - 1}$. \label{enum:Midpoint_g}
	\item Set $i \leftarrow 0$ and evaluate (\ref{eq:Midpoint_dA}) to get $d\tilde{A^{s_n}_i}$.
	\item Use the result and (\ref{eq:Midpoint_ItrNext}) to get an improved estimate $\tilde{A}^{s_n}_{i + 1}$.
	\item Set $i \leftarrow i + 1$ so that $\tilde{A}^{s_n}_i \leftarrow \tilde{A}^{s_n}_{i + 1}$.
	\item Repeat the previous three steps until the error $\zeta_n$ (\ref{eq:Midpoint_Err}) is small enough.
	\item Set $n \leftarrow n - 1$ (and $g_n \leftarrow g_{n-1}$) and go to step \ref{enum:Midpoint_g}.
	\item Having individually optimized the $A^{s_n}$ for each $n$, go to step
		  \ref{enum:Midpoint_StartChain} and repeat until the overall error (\ref{eq:Midpoint_Err_All})
		  is small enough.
\end{enumerate}
Note that the current estimate for the midpoint $\tilde{A}$ is always updated as soon as a new $\tilde{A}^{s_n}$
is generated and is used for the generation of the next $B$.

Having carried out the above, we have the midpoint $\ket{\Psi[A(t + dt/2)]}$ and can take a further
forward step $dt/2$ to reach $\ket{\Psi[A(t + dt)]}$.

This algorithm is a simple extension of the algorithm for uniform MPS in \cite{haegeman_time-dependent_2011},
where the key difference is the need, in general, to sweep over the chain more than once to obtain
a good solution. This is due to the dependence of $B^{s_n}$, for a given $n$, on the entire state, which
is clear because the exact time evolution $\hat{H} \ket{\Psi}$ also depends of the entire state.

The current \emph{evoMPS} implementation of this algorithm appears to have problems reaching the desired
accuracy. The exact reason is currently unknown to the author.

\subsection{Runge-Kutta Method}
The well known explicit fourth order Runge-Kutta method for numerical integration
\cite{press_section_????} has
also been implemented in \emph{evoMPS}. Due to its explicit nature, there is no need to solve an equation
when using this method and therefore no requirement to handle variation along the
gauge degrees of freedom.

For cases tested by the author, this integration method seems to perform better
for real time evolution than the midpoint method described in the previous subsection,
achieving a better accuracy with fewer operations for the same step size.

\section{Appendix}

\subsection{Obtaining a Canonical Form}
A (right) canonical form for generic MPS with open boundary conditions is described in
\cite{perez-garcia_matrix_2006}, which also includes details as to how the canonical
form can be obtained from a general MPS using a gauge transformation (\ref{eq:MPS_GF}).

The canonical form used in \emph{evoMPS} is largely the same and can be written as
\begin{equation}
	\sum_{s_n} A^{s_n} {A^{s_n}}^\dagger = \id \quad \forall n \iff r_n = \id \quad \forall n
\end{equation}
which leads to the entanglement spectrum for a cut between sites $n$ and $n+1$
being contained in the left density matrices $l_n$ (\ref{eq:Dens_L}). In \emph{evoMPS},
these matrices are not diagonalized.

To obtain this form, essentially the same method is used as in \cite{perez-garcia_matrix_2006},
except that a Cholesky decomposition of
$M = \sum_{s_n} A^{s_n} {A^{s_n}}^\dagger$
is performed in place of the singular value decomposition, where $M$ is taken to be positive
definite. %TODO: Need ref. for Cholesky/SVD?

\subsection{Restoration of the Norm}
Since, for a finite time step, the norm of the state may drift, it must
be restored to 1 from time to time. This can be done by simply multiplying the vectors $A^{s_1}$
or $A^{s_N}$ by $(\braket{\Psi | \Psi})^{-1/2}$, since $\braket{\Psi | \Psi} = l_N = r_0$ with
$r_n$ and $l_n$ defined in (\ref{eq:Dens_L}) and (\ref{eq:Dens_R}).

In principle, one could modify any of the matrices $A^{s_n}$ (for fixed $n$ and $\forall s_n = 1 \dots q_n$). It is, however,
more efficient to modify one of the end matrices because fewer steps are then required to calculate
the new norm using (\ref{eq:Dens_L}) or (\ref{eq:Dens_R}). This is required since, in general, a single attempt to restore the norm in the above
way will not succeed due to numerical inaccuracy. To solve this problem, the above operation
is carried out repeatedly until the state is normalized to the desired precision.

\bibliographystyle{plain_url}
\bibliography{mps.bib}

\end{document}


% ================= IF YOU HAVE QUESTIONS =======================
%
% Technical questions to bbob@lri.fr
% ===============================================================
%
\documentclass{article}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%% PREAMBLE   %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\usepackage{amssymb,amsmath}
%\usepackage{wasysym} % needed for some symbols hexagon pentagon
%\usepackage{MnSymbol} % needed for some other symbols upY downY leftY rightY
\usepackage{xstring}
\usepackage{graphicx}
\usepackage{tabularx}
\usepackage{float}
\usepackage{rotating}
\usepackage{lscape}
\usepackage{colortbl}
\usepackage[dvipsnames]{xcolor}
\usepackage{xstring} % for string operations
\usepackage{wasysym} % Table legend with symbols input from post-processing
\usepackage{MnSymbol} % Table legend with symbols input from post-processing

\definecolor{tableShade}{HTML}{ECF3FE}
\newcommand{\DIM}{\ensuremath{\mathrm{DIM}}}
\newcommand{\ERT}{\ensuremath{\mathrm{ERT}}}
\newcommand{\FEvals}{\ensuremath{\mathrm{FEvals}}}
\newcommand{\nruns}{\ensuremath{\mathrm{Nruns}}}
\newcommand{\Dfb}{\ensuremath{\Delta f_{\mathrm{best}}}}
\newcommand{\Df}{\ensuremath{\Delta f}}
\newcommand{\nbFEs}{\ensuremath{\mathrm{\#FEs}}}
\newcommand{\fopt}{\ensuremath{f_\mathrm{opt}}}
\newcommand{\ftarget}{\ensuremath{f_\mathrm{t}}}
\newcommand{\CrE}{\ensuremath{\mathrm{CrE}}}
\newcommand{\tablecaption}[2]{\ERT\ on $f_{#1}$ in #2-D over \ERT$_\text{best}$
obtained in BBOB 2009}
%%%%%%%%%%%%%%%%%%%%   END OF PREAMBLE   %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \newcommand{\bbobdatapath}{ppdatamany/} % was default output folder of rungenericmany.py
\newcommand{\bbobdatapath}{ppdata/} % default output folder of rungeneric.py
\graphicspath{{\bbobdatapath}}
\input{\bbobdatapath bbob_pproc_commands.tex} % provide default of algname and algfolder

\title{Black-Box Optimization Benchmarking Template for the Comparison of Algorithms on the Noisy Testbed}
\author{}

\begin{document}

\maketitle

% \section{Introduction}
%
% \section{Algorithm Presentation}
%
% \section{Experimental Procedure}
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Results}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Results from experiments according to \cite{hansen2010exp} on the benchmark
functions given in \cite{wp200902_2010,hansen2010noi} are presented in
Figures~\ref{fig:ECDFs05D} and \ref{fig:ECDFs20D}, and Figure~\ref{fig:scaling}.
The \textbf{expected running time (\ERT)}, used in the figures and table,
depends on a given target function value, $\ftarget=\fopt+\Df$, and is computed
over all relevant trials as the number of function evaluations executed during
each trial while the best function value did not reach \ftarget, summed over
all trials and divided by the number of trials that actually reached \ftarget\
\cite{hansen2010exp,price1997dev}.
\textbf{Statistical significance} is tested with the rank-sum test for a given
target $\Delta\ftarget$ using, for each trial, either the number of needed
function evaluations to reach $\Delta\ftarget$ (inverted and multiplied by
$-1$), or, if the target was not reached, the best $\Df$-value achieved,
measured only up to the smallest number of overall function evaluations for any
unsuccessful trial under consideration if available.
Tables~\ref{tab:f101_05D} to \ref{tab:f130_05D} and \ref{tab:f101_20D} to
\ref{tab:f130_20D} give the Expected Running Time (\ERT) for targets
$10^{1,\,-1,\,-3,\,-5,\,-7}$ divided by the best \ERT\ obtained during
BBOB-2009 (given in the \ERT$_{\text{best}}$ row), respectively in 5-D
and 20-D.
Bold entries correspond to the best (or 3-best if there are more than 3
algorithms) values.
The median number of conducted function evaluations is additionally given in
\textit{italics}, if $\ERT(10^{-7}) =\infty$.
\#succ is the number of trials that reached the final target $\fopt + 10^{-8}$.
Entries with the $\downarrow$ symbol are statistically significantly better
(according to the rank-sum test) compared to the best algorithm in BBOB-2009,
with $p=0.05$ or $p=10^{-k}$ where $k>1$ is the number
following the $\downarrow$ symbol, with Bonferroni correction of 30.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The following line shows the figure as they are:
% \newcommand{\includeperfprof}[1]{\includegraphics[width=0.5\textwidth,trim=0mm 0mm 0mm 10mm, clip]{#1}}
% The following uncommented line clips the right of the figures and uses the
% information in file \bbobdatapath pprldmany_XXD_XXX.tex for displaying the
% right hand legend information, thus allowing to modify the algorithm names
% in the legend.
\newcommand{\includeperfprof}[1]{ \includegraphics[width=0.4135\textwidth,trim=0mm 0mm 35mm 10mm, clip]{#1}\input{\bbobdatapath #1}}
% Algorithm names on the right of the ECDF figures can be modified by
% uncommenting the following lines and inputting some text in the last
% brackets, make sure the algorithms are in the same order than for the post-processing:
% \newcommand{\algaperfprof}{Algorithm a short name}
% \newcommand{\algbperfprof}{Algorithm b short name}
% ...
% \newcommand{\algzperfprof}{Algorithm z short name}
% \newcommand{\algAperfprof}{Algorithm A short name}
% ...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{figure}
 \begin{tabular}{@{}c@{}c@{}}
all functions & moderate noise \\
 \includeperfprof{pprldmany_05D_nzall} &
 \includeperfprof{pprldmany_05D_nzmod} \\
severe noise & severe noise multimod.\\
 \includeperfprof{pprldmany_05D_nzsev} &
 \includeperfprof{pprldmany_05D_nzsmm}
 \end{tabular}
\caption{\label{fig:ECDFs05D}Empirical cumulative distribution of the
bootstrapped distribution of \ERT\ over dimension for 50 targets in
$10^{[-8..2]}$ for all functions and subgroups in 5-D. The best ever line
corresponds to the algorithms from BBOB 2009 with the best \ERT\ for
each of the targets considered}
\end{figure}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{figure}
 \begin{tabular}{@{}c@{}c@{}}
all functions & moderate noise \\
 \includeperfprof{pprldmany_20D_nzall} &
 \includeperfprof{pprldmany_20D_nzmod} \\
severe noise & severe noise multimod.\\
 \includeperfprof{pprldmany_20D_nzsev} &
 \includeperfprof{pprldmany_20D_nzsmm}
 \end{tabular}
\caption{\label{fig:ECDFs20D}Empirical cumulative distribution of the
bootstrapped distribution of \ERT\ over dimension for 50 targets in
$10^{[-8..2]}$ for all functions and subgroups in 20-D. The best ever line
corresponds to the algorithms from BBOB 2009 with the best \ERT\ for
each of the targets considered}
\end{figure}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Algorithm names in the tables can be modified by uncommenting the following
% lines and inputting some text in the last brackets, make sure the algorithms
% are in the same order than for the post-processing:
% \newcommand{\algatables}{Algorithm a short name}
% \newcommand{\algbtables}{Algorithm b short name}
% \newcommand{\algctables}{Algorithm c short name}
% ...
% \newcommand{\algztables}{Algorithm z short name}
% \newcommand{\algAtables}{Algorithm A short name}
% ...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
\begin{table}
\caption{\label{tab:f101_05D}\tablecaption{101}{5}}
\centering
\footnotesize
\input{\bbobdatapath pptables_f101_05D}
\end{table}
%\begin{table}
%\caption{\label{tab:f102_05D}\tablecaption{102}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f102_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f103_05D}\tablecaption{103}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f103_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f104_05D}\tablecaption{104}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f104_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f105_05D}\tablecaption{105}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f105_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f106_05D}\tablecaption{106}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f106_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f107_05D}\tablecaption{107}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f107_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f108_05D}\tablecaption{108}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f108_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f109_05D}\tablecaption{109}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f109_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f110_05D}\tablecaption{110}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f110_05D}
%\end{table}
%\clearpage
%\begin{table}
%\caption{\label{tab:f111_05D}\tablecaption{111}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f111_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f112_05D}\tablecaption{112}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f112_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f113_05D}\tablecaption{113}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f113_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f114_05D}\tablecaption{114}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f114_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f115_05D}\tablecaption{115}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f115_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f116_05D}\tablecaption{116}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f116_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f117_05D}\tablecaption{117}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f117_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f118_05D}\tablecaption{118}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f118_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f119_05D}\tablecaption{119}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f119_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f120_05D}\tablecaption{120}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f120_05D}
%\end{table}
%\clearpage
%\begin{table}
%\caption{\label{tab:f121_05D}\tablecaption{121}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f121_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f122_05D}\tablecaption{122}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f122_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f123_05D}\tablecaption{123}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f123_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f124_05D}\tablecaption{124}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f124_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f125_05D}\tablecaption{125}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f125_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f126_05D}\tablecaption{126}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f126_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f127_05D}\tablecaption{127}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f127_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f128_05D}\tablecaption{128}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f128_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f129_05D}\tablecaption{129}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f129_05D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f130_05D}\tablecaption{130}{5}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f130_05D}
%\end{table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\clearpage
%\begin{table}
%\caption{\label{tab:f101_20D}\tablecaption{101}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f101_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f102_20D}\tablecaption{102}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f102_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f103_20D}\tablecaption{103}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f103_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f104_20D}\tablecaption{104}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f104_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f105_20D}\tablecaption{105}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f105_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f106_20D}\tablecaption{106}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f106_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f107_20D}\tablecaption{107}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f107_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f108_20D}\tablecaption{108}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f108_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f109_20D}\tablecaption{109}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f109_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f110_20D}\tablecaption{110}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f110_20D}
%\end{table}
%\clearpage
%\begin{table}
%\caption{\label{tab:f111_20D}\tablecaption{111}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f111_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f112_20D}\tablecaption{112}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f112_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f113_20D}\tablecaption{113}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f113_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f114_20D}\tablecaption{114}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f114_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f115_20D}\tablecaption{115}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f115_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f116_20D}\tablecaption{116}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f116_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f117_20D}\tablecaption{117}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f117_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f118_20D}\tablecaption{118}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f118_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f119_20D}\tablecaption{119}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f119_20D}
%\end{table}
%\clearpage
%\begin{table}
%\caption{\label{tab:f120_20D}\tablecaption{120}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f120_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f121_20D}\tablecaption{121}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f121_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f122_20D}\tablecaption{122}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f122_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f123_20D}\tablecaption{123}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f123_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f124_20D}\tablecaption{124}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f124_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f125_20D}\tablecaption{125}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f125_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f126_20D}\tablecaption{126}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f126_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f127_20D}\tablecaption{127}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f127_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f128_20D}\tablecaption{128}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f128_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f129_20D}\tablecaption{129}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f129_20D}
%\end{table}
%\begin{table}
%\caption{\label{tab:f130_20D}\tablecaption{130}{20}}
%\centering
%\footnotesize
%\input{\bbobdatapath pptables_f130_20D}
%\end{table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{figure}
\centering
\begin{tabular}{@{}c@{}c@{}c@{}c@{}c@{}}
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f101}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f104}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f107}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f110}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f113}\\
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f102}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f105}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f108}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f111}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f114}\\
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f103}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f106}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f109}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f112}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f115}\\
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f116}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f119}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f122}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f125}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f128}\\
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f117}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f120}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f123}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f126}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f129}\\
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f118}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f121}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f124}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f127}&
\includegraphics[width=0.2\textwidth, trim=20mm 7mm 15mm 3mm, clip]{ppfigs_f130}
\end{tabular}
\caption[Expected running time (\ERT) divided by dimension
versus dimension in log-log presentation]{\label{fig:scaling}
\bbobppfigslegend{$f_{101}$ and $f_{130}$}
%Expected running
%time (\ERT) divided by dimension  for
%target function value $10^{−8}$ as $\log_{10}$ values versus dimension. Differen%t symbols
%correspond to different algorithms given in legend of $f_{101}$ and $f_{130}$.
%Light symbols give the maximum number of function evaluations from all trials div%ided by the
%dimension. Horizontal lines give linear scaling,
%the slanted dotted lines give quadratic scaling.
%\input{\bbobdatapath ppfigs}
}
% The legend is in file \bbobdatapath ppfigs.tex
% While compiling this document, if the following error comes up:
% ! Undefined control sequence.
% try uncommenting line 9 and 10
\end{figure}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The following two commands are all you need in the
% initial runs of your .tex file to
% produce the bibliography for the citations in your paper.
\bibliographystyle{abbrv}
\bibliography{bbob}  % bbob.bib is the name of the Bibliography in this case
% You must have a proper ".bib" file
%  and remember to run:
% latex bibtex latex latex
% to resolve all references
\end{document}


\chapter{\label{ch:MeasurementCorrections}Measurement Corrections}

\chapauthor{Darrel J. Conway}{Thinking Systems, Inc.}

To be written.

\section{Introduction}

\section{Additive Corrections}

\section{Event Based Corrections}

\begin{figure}
\begin{center}
\includegraphics[scale=0.52]{Images/EventLocationLightTimeCorrection.eps}
% EventLocationLightTimeCorrection.png: 831x901 pixel, 72dpi, 29.32x31.79 cm, bb=0 0 831 901
\caption{Steps in Light Time Correction: Two Way Range}
\end{center}
\end{figure}

\begin{figure}
\begin{center}
\includegraphics[scale=0.36]{Images/EventLocationExecutionforMeasurements.eps}
% EventLocationExecutionforM...ts.png: 1282x1371 pixel, 72dpi, 45.23x48.37 cm, bb=0 0 1282 1371
\caption{\label{fig:MeasurementLocationSD}Event Location for Measurements}
\end{center}
\end{figure}


\SetAPI{J-C}
\section{cache.lru.threshold}
\label{configuration:CacheLruThreshold}
\ClearAPI
Sets the threshold of the Least Recently Used entries. If activated the RootCache contains references to the last n entities in the a list so they are not garbage collected. Valid values are numbers $\geq$ 0, whereas 0 stands for deactivated.
%% GENERATED USAGE REFERENCE - DO NOT EDIT
\begin{longtable}{ l l } \hline \textbf{Used in bean} & \textbf{Module} \
	\endhead
	\hline
		\type{com.koch.ambeth.cache.RootCache} &
		\prettyref{module:Cache} \\
	\hline
		\type{com.koch.ambeth.cache.RootCache} &
		\prettyref{module:Cache} \\
	\hline
\end{longtable}
%% GENERATED USAGE REFERENCE END
\type{com.koch.ambeth.cache.config.CacheConfigurationConstants.CacheLruThreshold}
\begin{lstlisting}[style=Props,caption={Usage example for \textit{cache.lru.threshold}}]
cache.lru.threshold=0
\end{lstlisting}