\section{Research}
\subsection{Blockchain}

The theory of a \keyword{blockchain} is not new \cite{origins_blockchain} but the implementation and hype around \keyword{blockchains} is new and extremely popular in the current day thanks to Bitcoin designed by Satoshi Nakamoto based on their white paper \cite{nakamoto2008bitcoin}. The accepted benefits of a \keyword{blockchain} are decentralisation, distribution, and immutability.For a \keyword{blockchain} to exist and be useful it needs nodes to maintain the data structure authenticate all transactions and hash the current block in preparation for the next in the chain.

\begin{figure}[H]
\caption{Blockchain structure with transactions saved in Merkle trees\cite{btc-white}}
\centering
\includegraphics[width=\textwidth,height=0.4\textheight,keepaspectratio]{images/patterns/merkle}
\centering
\end{figure}

\subsubsection{Technical proficiencies / limitations}

{\noindent\regular\textbf{Proficiencies}\vspace{2mm}}

\begin{description}
	\item[Security] Is the core of \keyword{blockchain} as the cryptographic hashing strategy is what makes the data structure a chain.
	\item[Transparency] Is not intrinsic to \keyword{blockchains} that is down to the implementation (public or private), however the underlying concept facilitates and promotes this open and transparent behaviour simply by the fact that nodes within a \keyword{blockchain} network need a copy of all transactions/blocks.
	\item[Decentralisation] Is definitely the most popular benefit of \keyword{blockchains} and it's not a technical benefit just like transparency decentralisation is a social debate that is made possible by technical decisions of the \keyword{blockchain} architecture, centred around the control and ownership of peoples data \begin{quote}"It avoids concentrations of power that could let a single person or organization take control."\cite{bohme2015bitcoin}\end{quote}
\end{description}

{\noindent\regular\textbf{Limitations}\vspace{2mm}}

\noindent\keyword{Blockchain} technology faces two major limitations, the largest chains in the world (Bitcoin and \keyword{Ethereum}) are quickly growing in size which has pointed out scaleability problems caused by transaction speed and cost per transaction which are currently slow and expensive respectively compared to traditional systems (cost experiments have borne this out in the aptly named paper "Comparing blockchain and cloud services for business process execution"\cite{rimba2017comparing} and show that business logic on \keyword{blockchains} are 2 orders of magnitude more expensive than current cloud services).

\keyword{Blockchains} rely on \keyword{consensus protocols} which is a mathematical formula to determine consensus of the network, essentially enough of the nodes have to agree the current state of the \keyword{blockchain} whenever it's modified. Currently all major chains including Bitcoin and \keyword{Ethereum} use a protocol called proof of work\cite{PoW} which uses the total amount of compute a node has produced as the comparable proof that can be verified by many other nodes easily. This has worked so far for these major chains however ballooning energy consumption (which can be seen in realtime at the \href{https://ccaf.io/cbeci/index}{Cambridge Bitcoin Electricity Consumption Index}), high transaction costs, and inadequate transaction processing bandwidth is forcing them to change and look for solutions.

\keyword{Ethereum} have decided to completely reinvent their consensus protocol with a fundamentally different protocol called proof of stake which promises reduced energy consumption, cheaper, and faster transactions\cite{PoS}. Although there have been other proposed solutions including: improving the proof of stake system by parallelising it across nodes\cite{fi12080125} or reducing the block size for a increase transaction capacity by reducing the amount of work needed per block with a security trade off to balance\cite{kiayias2015speed}.

\subsubsection{Use of blockchain for IP protection}

I am not the first person to have thought of representing and enforcing \keyword{copyright} protection on a distributed \keyword{blockchain}, there has actually been a lot of discussion around the topic showing the benefits of using this technology for \keyword{copyright} such as transparency; \begin{quote} "Blockchain may substantially increase visibility and availability of information about copyright ownership." \cite{Copyright_in_the_blockchain_era} \end{quote} the power of \keyword{smart contracts} and utilising a networks cryptocurrency \begin{quote} "Smart contracts will allow automatic and instantaneous payments to designated parties, and expiration of a license after a certain amount of time." \cite{Copyright_in_the_blockchain_era} \end{quote} and simplification through the globalisation of \keyword{copyright} law. majority opinion says that introducing \keyword{smart contracts} to \keyword{blockchain} technology is extremely powerful particularly within \keyword{copyright} law to \begin{quote}"reliably automate a large volume of ‘dumb transactions’" \cite{missing_link_in_copyright_licensing}\end{quote} which will greatly reduce friction by removing unnecessary work and removing expertise needed currently in the field to be properly protected.

\subsubsection{Use of blockchain for legal purposes}

Bringing \keyword{copyright} to \keyword{blockchain} is apart of a larger conversation about the compatibility of any legal or even governmental workflows to be either represented or completely reinvented using \keyword{blockchain} technology, and it does look like in many cases these types of problems can leverage \keyword{blockchain} and possibly even thrive.

The legal industry is notoriously complicated requiring a great level of knowledge and expertise in the field to make sense of anything or more importantly get anything done. Logically laws make an obvious starting point for computerisation because computers are defined systems of ridged laws however this didn't make sense during the first wave of \keyword{blockchains} which almost entirely focused its efforts towards currency. The introduction of \keyword{smart contracts} has opened up the possibilities for automated law processing massively reducing boilerplate and bulky legal work which is largely trivial but time consuming.

\begin{quote}
	"So-called ‘smart contracts’ built on blockchain technologies may prove to be the most important example yet of “self-executing, customised rules”." \cite{MILLARD2018843}
\end{quote}

For governing \keyword{blockchains} ledger and transparency will take centre stage as essentially all governments are big collections of "things", assets, people and information. Not only are they collections but historical records, thankfully \keyword{blockchains} are immutable, timestamped, secure and built for openness. Because \keyword{blockchains} are just general purpose data structures there're uses are broad; \begin{quote}"keeping an overview of the authorities provided in a public organization and the ability to change the authority only if there is agreement among nodes which are classified as being higher ranked in the hierarchy." \cite{OLNES2017355}\end{quote}

% TODO Probably not needed, bit of a rehash of other sections

%\subsection{Copyright law}
%
%What is the reason for "fixing" \keyword{copyright}? is it broken? \keyword{Copyright} law is old, it was first introduced from the 1700s to the 1800s with the introduction of the printing press and the first true \keyword{copyright} act being the Statute of Anne in 1710 which has morphed into the Copyright, Designs and Patents Act 1988 in the UK (\href{https://www.legislation.gov.uk/ukpga/1988/48/contents}{see}) and the Copyright Act of 1976 in the US. The fact that each country has its own unique \keyword{copyright} laws (even though the international Berne Convention exists local jurisdictions still apply) exacerbated by the internet has been showing signs of cracks especially when "digital goods" are involved.
%
%Theses issues can be broken down into three key areas:
%
%\begin{enumerate}
%	\item \textbf{Legal transparency/complexity} Is the absolutely at the top of this list, as a creative can you be sure your work is protected in every jurisdiction possible? No you can't because the current copyrighting system is a sparse disconnected collection of closed databases. Implementing a globally open database of copyrighted works with consistent rules and digital finger printing.
%	\item \textbf{Royalty distributions (compensation)} Monetary transactions are the current forte of all major \keyword{blockchains} so why not simplify one of the hardest tasks for an creator, receiving payment for the use of a work of course this has become easier with the introduction of internet payments and purpose built systems like "PRS for Music" but integrating royalty payments straight into the \keyword{copyright} registration proves for secure and cohesive system.
%	\item \textbf{Cost} Of protection a work is essentially free as the Berne Convention prohibits the registration of a work as a requirement to protection (\keyword{copyright} is born with the work), however legally protecting and defending authorship of a work is not free and can be devastating not to mention extremely one sided (massive record company vs band). With the help of an immutable global ledger determining who registered the work is simple.
%\end{enumerate}
%
%These problems and solutions in this section are talked about in the paper \textit{Copyright in the blockchain era: Promises and challenges} \cite{Copyright_in_the_blockchain_era}

%\section{Environment and crypto} not enough for this section

\subsection{The market}

The vast majority of \keyword{blockchain} applications in the current day are financial for obvious reasons with the market capitalisation of cryptocurrencies being the universal metric for the \keyword{blockchain} markets size \cite{wood_2021}, however the health care industry has been aggressively investigating and implementing \keyword{blockchain} technology particularly in the secure distribution of medical data and health records \cite{8167115}, supply chain technology has seen some innovation tracking goods as they pass through a chain.


\documentclass[11pt]{article}
% \textwidth=6in
% \textheight=9in
% \oddsidemargin=0.25in
% \evensidemargin=0.25in
% \marginparwidth=0in
% \marginparsep=0in
% \topmargin=0in
% \headheight=0in
% \headsep=0in
% \topskip=0in
\usepackage{amssymb}
\usepackage{hyperref}
\usepackage{lscape}
\usepackage{longtable}
\usepackage{graphics}
\usepackage[pdftex]{graphicx}
\usepackage{color}
\usepackage{rotating}
\newcommand{\hilight}[1]{\colorbox{yellow}{#1}}

\newenvironment{packed_itemize}{
\begin{itemize}
  \setlength{\itemsep}{1pt}
  \setlength{\parskip}{0pt}
  \setlength{\parsep}{0pt}
}{\end{itemize}}

\title{Options for a consistent GraphBLAS notation}
\author{Tim Davis, Gabor Szarnyas}
\date{\today}
\begin{document}

\maketitle

\section{Creating matrices}

\begin{itemize}
\item[] in the C API: \verb'GrB_Matrix_new (&A, m, n, GrB_INT64)'
\item[] in ASCII: \verb'A = int16(m,n)' (I'm open to suggestions for this)
\item[] in LaTeX: $\mbox{let: } {\bf A} \in \mathbb{Z}^{m \times n}_{16}$
\end{itemize}

\section{Mask computation}

In the following table the ``mask'' column is the value of the
mask after applying the value/structural option and optionally
complementing the mask.  If no mask is present (and not complemented)
then mask is 1.  If no mask is present (yet complemented) then the mask is
always 0; this has no effect unless the Replace option is also used.

The repl column in the table is ``yes'' if Replace is enabled, ``no'' otherwise.
The accum column in the table is ``yes'' if the accum is
present, ``no'' otherwise.
The ${\bf C}$ column is listed as $c_{ij}$ if that entry is present,
and a dash otherwise, likewise for the ${\bf A}$ column.

\begin{table}
{\small
\begin{tabular}{lllll|l}
\hline
repl & accum & ${\bf C}$ & ${\bf A}$ & mask & action taken by ${\bf C \langle M \rangle = C \odot A}$ \\
\hline
\hline
       &    &          &           &      & \verb'C<M>=A' and \verb'C<!M>=A' \\
\hline
    -  &-   & $c_{ij}$ & $a_{ij}$  & 1    &  $c_{ij} = a_{ij}$, update \\
    -  &-   &  -       & $a_{ij}$  & 1    &  $c_{ij} = a_{ij}$, insert \\
    -  &-   & $c_{ij}$ &  -        & 1    &  delete $c_{ij}$ because $a_{ij}$ not present \\
    -  &-   &  -       &  -        & 1    &   \\
\hline
    -  &-   & $c_{ij}$ & $a_{ij}$  & 0    &   \\
    -  &-   &  -       & $a_{ij}$  & 0    &   \\
    -  &-   & $c_{ij}$ &  -        & 0    &   \\
    -  &-   &  -       &  -        & 0    &   \\
\hline
\hline
       &    &          &           &      & \verb'C<M,repl>=A' and \verb'C<!M,repl>=A' \\
\hline
    yes&-   & $c_{ij}$ & $a_{ij}$  & 1    &  $c_{ij} = a_{ij}$, update \\
    yes&-   &  -       & $a_{ij}$  & 1    &  $c_{ij} = a_{ij}$, insert \\
    yes&-   & $c_{ij}$ &  -        & 1    &  delete $c_{ij}$ because $a_{ij}$ not present \\
    yes&-   &  -       &  -        & 1    &   \\
\hline
    yes&-   & $c_{ij}$ & $a_{ij}$  & 0    &  delete $c_{ij}$  (because of \verb'GrB_REPLACE') \\
    yes&-   &  -       & $a_{ij}$  & 0    &   \\
    yes&-   & $c_{ij}$ &  -        & 0    &  delete $c_{ij}$  (because of \verb'GrB_REPLACE') \\
    yes&-   &  -       &  -        & 0    &   \\
\hline
\hline
       &    &          &           &      & \verb'C<M>+=A' and \verb'C<!M>+=A' \\
\hline
    -  &yes & $c_{ij}$ & $a_{ij}$  & 1    &  $c_{ij} = c_{ij} \odot a_{ij}$, apply accumulator \\
    -  &yes &  -       & $a_{ij}$  & 1    &  $c_{ij} = a_{ij}$, insert \\
    -  &yes & $c_{ij}$ &  -        & 1    &   \\
    -  &yes &  -       &  -        & 1    &   \\
\hline
    -  &yes & $c_{ij}$ & $a_{ij}$  & 0    &   \\
    -  &yes &  -       & $a_{ij}$  & 0    &   \\
    -  &yes & $c_{ij}$ &  -        & 0    &   \\
    -  &yes &  -       &  -        & 0    &   \\
\hline
\hline
       &    &          &           &      & \verb'C<M,repl>+=A' and \verb'C<!M,repl>+=A' \\
\hline
    yes&yes & $c_{ij}$ & $a_{ij}$  & 1    &  $c_{ij} = c_{ij} \odot a_{ij}$, apply accumulator \\
    yes&yes &  -       & $a_{ij}$  & 1    &  $c_{ij} = a_{ij}$, insert \\
    yes&yes & $c_{ij}$ &  -        & 1    &   \\
    yes&yes &  -       &  -        & 1    &   \\
\hline

\hline
    yes&yes & $c_{ij}$ & $a_{ij}$  & 0    &  delete $c_{ij}$  (because of \verb'GrB_REPLACE') \\
    yes&yes &  -       & $a_{ij}$  & 0    &   \\
    yes&yes & $c_{ij}$ &  -        & 0    &  delete $c_{ij}$  (because of \verb'GrB_REPLACE') \\
    yes&yes &  -       &  -        & 0    &   \\
\hline
\end{tabular}
}
\caption{Results of the mask/accumulator phase \label{tab:maskaccum}}
\end{table}

\newpage
\section{For Mask/Accum/Replace: there are 32 variants}

All these options can affect each other so there are 32 variants total,
except that when no mask is present, the value/structural option makes
no difference.

\begin{itemize}
\item the mask ${\bf M}$ can be present, or not present.
\item the mask can be complemented, or not (even when no mask is present)
\item the mask can be valued or structural
\item the replace option can be enabled, or not.
\item the accumulator can be present, or not.
\end{itemize}

Here are some options:

\begin{itemize}
\item plain mask, with accum:

    \begin{itemize}
    \item[] in ASCII: \verb'C<M>+=A'
    \item[] in LaTex: $\bf C \langle M \rangle \odot\!\!= A $
    \end{itemize}

\item negated mask, with accum.  Several options for LaTeX.
I like the $\overline{\bf M}$ since it is more compact, but it
has problems when $\bf M$ is also structural (see below).

    \begin{itemize}
    \item[] in ASCII: \verb'C<!M>+=A'
    \item[] in LaTex: $\bf C \langle \neg M \rangle \odot\!\!= A$
    \item[] in LaTex:  $\bf C \langle \overline{M} \rangle \odot\!\!= A$
    \end{itemize}

\item structural mask, not complemented:
using $s({\bf M})$ where $s$ stands for structural.
This feels wordy to me.  Not elegant.
The letter $s$ could be confused for a vector or scalar.

    \begin{itemize}
    \item[] in ASCII: \verb'C<s(M)>+=A'
    \item[] in LaTex:  ${\bf C} \langle s({\bf M}) \rangle \odot\!\!= {\bf A}$
    \end{itemize}

\item structural mask alternatives.  The letter $s$ could be confused
for a scalar or vector, so a Greek letter could be used instead,
such as sigma ($\sigma$).  But this is also wordy.

    \begin{itemize}
    \item[] in ASCII: \verb'C<s(M)>+=A'
    \item[] in LaTex:  ${\bf C} \langle \sigma({\bf M}) \rangle \odot\!\!= {\bf A}$
    \end{itemize}

\item structural mask alternative.  The notation
$s({\bf M})$ is a little wordy.  The Mask cannot be transposed in a
single call to \verb'GrB_anything' so a superscript would work.  But a
subscript might be better, because someone might want to indicate a
transposed mask (which would have to be done as a separate call to
\verb'GrB_transpose').  This doesn't look good in ASCII however:

    \begin{itemize}
    \item[] in ASCII: \verb'C<M_s>+=A'
    \item[] in LaTex:  ${\bf C} \langle {\bf M}_s \rangle \odot\!\!= {\bf A}$
    \end{itemize}

\item structural mask: why not use set notation?  The structure of ${\bf M}$
is a set of the entries of ${\bf M}$.  In a sense, selecting the
structural option in the descriptor converts ${\bf M}$
into a set.  So how about set notation, with curly brackets?
We don't use curly brackets anywhere else in GraphBLAS, so this is unambigous.
I like this the best.

    \begin{itemize}
    \item[] in ASCII: \verb'C<{M}>+=A'
    \item[] in LaTex:  ${\bf C} \langle \{{\bf M}\} \rangle \odot\!\!= {\bf A}$
    \end{itemize}

\item complemented structural mask, for $s({\bf M})$:

    \begin{itemize}
    \item[] in ASCII: \verb'C<!s(M)>+=A'
    \item[] in LaTex:  ${\bf C} \langle \neg s({\bf M}) \rangle \odot\!\!= {\bf A}$
    \end{itemize}

\item  complemented structural mask, for the curly bracket option:
It is important to note that the structure of ${\bf M}$ is taken
first, and then complemented.  Not the other way around.
I like this option the best (with $\neg$).

    \begin{itemize}
    \item[] ASCII: \verb'C<!{M}>+=A'
    \item[] LaTeX: ${\bf C} \langle \neg \{{\bf M}\} \rangle \odot\!\!= {\bf A}$
    \item[] LaTeX:
    ${\bf C} \langle \overline{ \{{\bf M}\}} \rangle \odot\!\!= {\bf A}$
    ouch.  That is a long overline, and could be confused with
    ${\bf C} \langle  \{\overline{\bf M}\} \rangle \odot\!\!= {\bf A}$
    \end{itemize}

\end{itemize}

(Gabor) I like the set notation for the ``structure'' option and the $\neg$
symbol for negation.  (Tim): I think this is the best option I've seen so far,
too.

\newpage

\section{Replace option}

The examples consider all options except for Replace.
Here are some ideas; I am not really happy with any of them.

\begin{itemize}

\item simple case: a mask with replace

    \begin{itemize}
    \item[] in ASCII: \verb'C<M,replace>+=A'
    \item[] in LaTex: $\bf C \langle M, \mbox{replace} \rangle \odot\!\!= A $
    \end{itemize}

\item complemented structural mask with replace

    \begin{itemize}
    \item[] ASCII: \verb'C<!{M},replace>+=A'
    \item[] LaTeX: ${\bf C} \langle \neg \{{\bf M}\}, \mbox{replace}
    \rangle \odot\!\!= {\bf A}$
    \end{itemize}

\item no mask, yet complemented, with replace.  This does actual work that
does not depend on the input matrix $\bf A$ or input scalar.

    \begin{itemize}
    \item[] ASCII: \verb'C<!,replace>=A'
    \item[] LaTeX: ${\bf C} \langle \neg, \mbox{replace}
    \rangle \odot\!\!= {\bf A}$
    \end{itemize}

\end{itemize}

\subsection{(Gabor) Alternative. (Tim): I like this}

How about double angle brackets for ``replace''? This could symbolize that the computation only keeps that part by the mask and discards the rest.

(Tim):  I like this idea.  It indicates to me that the Mask is ``strong,''
in the sense that stuff outside the mask (where the final mask value is
false after possibly taking the structure and/or complementing)
gets obliterated.

\begin{itemize}

    \item simple case: a mask with replace

        \begin{itemize}
        \item[] in ASCII: \verb'C<<M>>+=A'
        \item[] in LaTex: $\bf C \langle\!\langle M \rangle\!\rangle \odot\!\!= A $
        \end{itemize}

    \item complemented structural mask with replace

        \begin{itemize}
        \item[] ASCII: \verb'C<<!{M}>>+=A'
        \item[] LaTeX: ${\bf C} \langle\!\langle \neg \{{\bf M}\}
        \rangle\!\rangle \odot\!\!= {\bf A}$
        \end{itemize}

    \item no mask, yet complemented, with replace

        \begin{itemize}
        \item[] ASCII: \verb'C<<!>>=A'
        \item[] LaTeX: ${\bf C} \langle\!\langle \neg \rangle\!\rangle \odot\!\!= {\bf A}$
        \end{itemize}

\end{itemize}

\section{Different accum operators}

The accum operator can be any function, such as PLUS, TIMES, FIRST, MIN, MAX,
ANY, logical OR, logical AND etc.  I propose using using symbols from C/C++ if
available, or spelling out the function otherwise.
Assuming no mask/replace/complement, in ASCII:

    \begin{itemize}
    \item[] \verb'C +=A ' plus
    \item[] \verb'C *= A ' times
    \item[] \verb'C &&= A ' logical AND
    \item[] \verb'C &= A ' bitwise AND
    \item[] \verb'C ||= A ' logical OR
    \item[] \verb'C |= A ' bitwise OR
    \item[] \verb'C ^= A ' logical XOR, but see the XOR in LaTeX below
    \item[] \verb'C /= A ' divide
    \item[] \verb'C max= A ' maximum
    \item[] \verb'C any= A ', this is Tim's \verb'GxB_ANY_*' operator.
    \item[] \verb'C first= A '
    \item[] and so on
    \end{itemize}

In LaTeX, it is very similar.  Note the spacing:

    \begin{itemize}
    \item[] $\bf C \,+\!\!= A $, plus
    \item[] Latex source of the above: \verb'$\bf C \,+\!\!= A$'
    \item[] $\bf C \,*\!\!= A $, times
    \item[] $\bf C \,\wedge\!\!= A $, logical AND
    \item[] $\bf C \,\&\!\!= A $, bitwise AND
    \item[] $\bf C \,\vee\!\!= A $, logical OR
    \item[] $\bf C \,|\!\!= A $, bitwise OR
    \item[] $\bf C \,\oplus\!\!= A $, logical XOR?  but this conflicts with
        the use of $\oplus$ to denote a generic additive operator.
        So perhaps logical XOR should be written
        $\bf C \,\mbox{xor}\!\!= A $.
    \item[] $\bf C \,/\!\!= A $, divide, or perhaps
        $\bf C \,\div\!\!= A $
    \item[] $\bf C \,\mbox{max}\!\!= A $, maximum
    \item[] $\bf C \,\mbox{any}\!\!= A $, ANY
    \item[] $\bf C \,\mbox{first}\!\!= A $, FIRST
    \item[] and so on
    \end{itemize}

(Gabor) I propose to use \verb+\mathbin{}+ for spacing around the operator,
e.g., $\bf C \mathbin{+\!\!=} A $.
(Tim) I like that suggestion, which looks like this in the LaTeX:
\verb'$\bf C \mathbin{+\!\!=} A$'.

\end{document}


%!TEX root = /home/renaud/Documents/EPL/tfe/latex/tfe.tex
%-------------------------------------------CLUSTERING OVERTURNER-----------------------------------------------%
\newpage
\section{Clustering of the overturner problem}
% 1. Expliquer ce qu'on va faire
% 2. Décomposition du domaine en boxes, on cherche ce que donne le clustering sur ces boxes.
% 3. Résultats pour nboxy = 15, nboxz = 10 (et expliquer que ces choix permettent que y0 et z0 correspondent à des frontières de box)

This section presents the results of applying a stability-based community detection algorithm on the overturner problem. First, we explain how the method is applied and then we present the results for a given set of data's.

% %-----------------------DESCRIPTION OF THE METHOD---------------------------------%
% \subsection{Description of the method}
% In order to apply a clustering algorithm on the overturner problem, we have to define how the model can be considered as a graph. To this end, the domain is decomposed into $\nby \times \nbz$ boxes. We note $N_{box} = \nby\nbz$ the total number of boxes. Figure~\ref{fig:box_scheme} represents an example of such a domain decomposition with $\nby = 15$ and $\nbz = 10$. For any time $T$, the corresponding directed graph is build as follows : each node represents a box, and the weight of the edge between nodes $i$ and $j$ is the probability $m_{ij}(T)$ that a particle ends up in box $j$ after a time $T$ if it was initially in box $i$. If $m_{ij}(T) = 0$, one can equivalently consider that there is no edge between nodes $i$ and $j$. Since the problem is stationary, $m_{ij}(T)$ depends only on the elapsed time $T$, not on the initial time. Hence, the initial time can indifferently be considered as being zero. The adjacency matrix $\b M(T)$ of the graph is build from the weights $m_{ij}(T)$: $[\b M(T)]_{ij} = m_{ij}(T)$. For any time $T$, $\b M(T)$ is row-stochastic, i.e. $\b M(T)\b 1 = \b 1$, where $\b 1$ is the $N_{box}$-dimensional unit column vector. The latter has a straightforward physical interpretation: every particle remains in the domain.
% \begin{figure}[h!]
% 	\centering
% 	\input{fig/clusters/box_scheme}
% 	\caption{Illustration of the decomposition of the domain into boxes with $\nby = 15$ and $\nbz = 10$.}
% 	\label{fig:box_scheme}
% \end{figure}

% To estimate the probabilities $m_{ij}(T)$, the program is run for a time $T$ with each box containing initially $J$ uniformly distributed particles. $m_{ij}(T)$ is then numerically estimated as the number of particles having started in box $i$ and ending up in box $j$, divided by $J$. This \textit{box counting} method has been extensively used to estimate the concentration in studies using random walk modeling, see e.g. \cite{riddle1998specification}. Nevertheless, this method suffers some drawbacks; the most important of them are pointed in \cite{spivakovskaya2007lagrangian}, but we recall them here for the sake of completeness. The estimated transition probability depends on the choice of the boxes, in particular of their size and their center. Moreover, the number of boxes cannot be chosen to be too large; otherwise the estimated concentration tends to become very irregular or noisy. Finally, the resolution of the estimated concentration is limited to the size of the boxes, as it cannot be described in a box more precisely than a constant. But it is the perfect method for our problem since the volume average over such boxes (the nodes) is precisely what we want. Note however that other methods exist for estimating the concentration, that might be better suited for other studies. For example, the \textit{kernel estimation} method allows to reduce drastically the number of particles, and does not suffer from the resolution limit inherent to the box counting method. This method is briefly presented in \cite{spivakovskaya2007lagrangian}. Classical references are \cite{silverman1986density} and \cite{wand1995kernel}.

% %-------------------------USE OF THE TOOLBOX----------------------------%
% \subsection{Use of the stability software}
% % \newcommand\localFontSize@mlpr{10}
% We present here briefly how the \textit{PartitionStability} software is used to compute the partitions. Every concept appearing here has been presented in chapter~\ref{chap:clustering}. The \mtlb{stability} function is simply called as follows : \vspace{-.2cm}
% \begin{center}
% 	\mtlb{[S,N,VI,C] = stability(M,Markov_T,'directed','plot','teleport',0.01);}
% \end{center} %style = Matlab-bw for black and white
% Here, \mtlb{M} is the matrix $\b M(T)$ at the desired time $T$; \mtlb{Markov_T} is the vector containing every Markov times at which the optimal stability partition has to be computed (ideally, the sampling should be exponential); the \mtlb{'directed'} option specifies that we consider a directed graph; \mtlb{'plot'} asks the program to plot the stability, number of communities and variation of information as a function of the Markov time; and \mtlb{'teleport',0.01} allows to specify the value of the teleportation probability $\tau$ to $0.01$, the default value being $0.15$. The choice of $0.01$ is motivated by the fact that we believe the graph to be ergodic, even if we cannot prove it. Note that the program allows to choose which type of laplacian should be used to calculate the stability. However, the question does not arise here since both laplacians are equivalent in our case. Indeed, the total outgoing weight is the same at every node and is precisely equal to the number of particles $J$ released in each box. Hence, $k_i = J$ for every node $i$ and $\langle \b k \rangle = J$, so that $\bs \lambda_{combi}(\b k) = \b k/ \langle \b k \rangle = \b 1 = \bs \lambda_{norm}(\b k)$. We let thus the program run with the default normalized Laplacian, since it does not make any difference in our case. The output arguments \mtlb{S}, \mtlb{N}, \mtlb{VI} and \mtlb{C} contain respectively the stability, the number of communities, the variation of information, and the optimal partition for each Markov time contained in \mtlb{Markov_T}. If the latter is of size $n$, then \mtlb{S}, \mtlb{N} and \mtlb{VI} are $n$-dimensional vectors and \mtlb{C} is a $N_{box} \times n$ matrix. At the $j$th Markov time, communities are labeled by consecutive integers between $0$ and \mtlb{N(j)}$-1$ such that \mtlb{C(i,j)} $= k$ means that node $i$ belongs to community $k$ at Markov time \mtlb{Markov_T(j)}.

%--------------------------RESULTS--------------------------------------%
\subsection{Results}
Now we present some results on a particular discretization of the overturner problem. The box decomposition of the domain is the one shown in figure~\ref{fig:box_scheme}, and $J = 10\,000$ particles are released in each box. More precisely, a box is decomposed into a $100 \times 100$ sub-grid, and one particle is initially located at every point of the sub-grid, so that the particles are initially uniformly distributed within the box. The transition probability matrices $\b M(T)$ are generated for different values of $T$. We show here the results for $T = 1$, $10$, $50$ and $100$ years. The vector of the Markov times \mtlb{Markov_T} is sampled exponentially from $0.1$ to $100$ : $\log_{10}($\mtlb{Markov_T}$) = [-1,\, -0.98, \dots ,\, 1.98,\, 2]$. Notice that the physical meaning of the Markov time changes with $T$ : a Markov time step of $1$ is equal to a physical time step of $T$. Hence, for $a >0$, if for $\b M(T)$ we find some communities in the range of Markov times $[t_{M_1},\, t_{M_2}]$, then for $\b M(aT)$ we expect to find similar communities in the range of Markov times $\frac{1}{a}[t_{M_1},\, t_{M_2}]$.

% \begin{figure}[!htp]
% 	\centering
% 	\input{fig/clusters/box_scheme}
% 	\caption{Illustration of the decomposition of the domain into boxes with $\nby = 15$ and $\nbz = 10$.}
% 	\label{fig:box_scheme}
% \end{figure}

Figures~\ref{fig:stab0}, \ref{fig:stab1}, \ref{fig:stab5} and~\ref{fig:stab10} show the stability curves, the number of communities and the variation of information as functions of the Markov time for $T = 1$, $10$, $50$ and $100$ years respectively. As discussed in section~\ref{subsec:robustness}, robust partitions correspond to plateaux in the community curve of the graphs. By using this criterion, partitions of 6, 5, 4, 3 and 2 communities are found at different time scales. Those partitions are summarized in table~\ref{tab:partitions_summary} along with the physical time range at which they reveal themselves. Figure~\ref{fig:cluster0}, \ref{fig:cluster1}, \ref{fig:cluster5} and~\ref{fig:cluster10} shows the most robust clusterings for $T=1$, $10$, $50$ and $100$ respectively. From table~\ref{tab:partitions_summary}, we observe that some similar partitions happen to be the most relevant at different time scales when we modify $T$. For example, for $T=1$, 6 communities are found in the time range 9 - 12 years (figure~\ref{fig:cluster0_6_}). A similar clustering is found for $T = 10$ and $T = 50$ but in the time ranges 24 - 48 years and 36-48 years respectively (figures~\ref{fig:cluster1_6_} and~\ref{fig:cluster5_6_}).

It is important to notice that the community detection algorithm may fail to detect the right number of communities. Take figure~\ref{fig:cluster1_2_} for example : the stability software detects 2 communities. However, the white community consists of two noncontiguous blocks. Intuitively, particles leaving the lower white block should enter the khaki block first before entering the upper white block. Hence, there should be 3 communities rather than 2 for this partitioning. A way to quantify this intuition is by looking at
\begin{equation}
	\b M_{\P}(T) = \diag^{-1}(\b n)\b H^{\t}_{\P} \b M(T) \b H_{\P},
\end{equation}
where $\b n$ is the $c$-dimensional vector containing the number of blocks in each community. $[\b M_{\P}]_{kl}$ is the transition probability from community $k$ to community $l$. By considering the clustering where the lower and the upper white blocks are separated communities, we get
\begin{equation}
	\b M_{\P}(10) =
	\begin{pmatrix}
		0.886 & 0.114 & 0.000\\
	    0.052 & 0.895 & 0.053\\
	    0.017 & 0.256 & 0.727\\
    \end{pmatrix}.
\end{equation}
Here, community 1 is the lower white block, community 2 is the khaki block and community 3 is the upper white block. We observe that $[\b M_{\P}]_{13} = 0$ and $[\b M_{\P}]_{31} = 0.017$, indicating very weak links between the lower and the upper white blocks. Hence, they should indeed be considered as separated communities. However, this does not mean that~\ref{fig:cluster1_2_} provides then the optimal clustering with 3 communities ! Such a clustering is rather given by figure~\ref{fig:cluster1_3_}, and the clustering proposed in figure~\ref{fig:cluster1_2_} should simply be disregarded as being non-relevant.

Now, let us analyze a seemingly relevant community structure. By looking at table~\ref{tab:partitions_summary} together with figures~\ref{fig:cluster1_5_} and~\ref{fig:cluster5_5_}, we observe that two similar 5-communities clusterings arise in the time range 50 - 63 years when $T = 10$ and $T = 50$. This indicates that those community structures might be more resilient than others. There is only a 2 boxes difference between the two clusterings; we will therefore focus on the clustering found for $T = 10$, namely the one from figure~\ref{fig:cluster1_5_}. The communities are numbered from 1 to 5 on the figure. The matrix $\b M_{\P}$ for this community structure is
\begin{equation}
	\b M_{\P}(10) =
	\begin{pmatrix}
	0.907 & 0.024 &     0 & 0.024 & 0.045\\
    0.073 & 0.827 & 0.043 & 0.057 & 0\\
        0 & 0.029 & 0.925 & 0.036 & 0.010\\
    0.039 & 0.041 & 0.089 & 0.776 & 0.055\\
    0.020 &     0 & 0.048 & 0.022 & 0.910\\
	\end{pmatrix}.
\end{equation}
Obviously, particles in a community tends to stay in that community. But what are the main interconnections between communities ? By looking at matrix $\b M_{\P}$, we observe that particles leaving community 1 goes preferentially to community 5; from community 2, the main tendency is to go to community 1; from 3 to 4 and 2; from 4 to 3 (mainly because of the size of 3) and from 5 to 3. Hence, the dominant tendency is that the particles tend to describes a clockwise cycle in the domain, which is exactly the expected behavior.

\textcolor{blue}{J'aimerais aller un peu plus loin dans mes commentaires mais les idées ne se bousculent pas... Et les commentaires que je fais ci-dessus ne nous apprennent rien. Cela fait sans doute beaucoup d'images d'images pour au final pas grand chose.}

\begin{table}[H]
\centering
\caption{Summary of the dominant clusterings found by inspection of the transition probability matrix $\b M(T)$ for $T = 1$, $10$, $50$ and $100$ years.}
\label{tab:partitions_summary}
\begin{tabular}{l|ccccc}
\hline
\multirow{2}{*}{$T$} & \multicolumn{5}{c}{Time range [year]} \\ \cline{2-6}
                  &  6 communities &  5 communities  &  4 communities  &  3 communities &  2 communities \\ \hline
              1   & \phantom{0}9 - 12  & 15 - 26 & 28 - 36 & \phantom{0}38 - $\dots$  &   \\
              10  & 24 - 48 &  50 - 63 & & \phantom{0}91 - 316 & 331 - $\dots$ \\
              50  & 36 - 48 & 50 - 66 & & \phantom{0}69 - 138 & 144 - 190 \\
              100 & 58 - 76 & 79 - 105 & &120 - 229 & 240 - 316 \\ \hline
\end{tabular}
\end{table}

%------------------ T = 1 ------------------------------%
\begin{figure}[H]
	\centering
	\includegraphics[width = .7\textwidth]{clusters/stab0.eps}
	\caption{Stability, number of communities and variation of information as a function of the Markov time for $T=1$ year.}
	\label{fig:stab0}
\end{figure}

\begin{figure}[H]
	\centering
	\begin{subfigure}[t]{0.49\textwidth}
		\includegraphics[width=\textwidth]{clusters/cluster0_6_.eps}
		\caption{6 communities.}
		\label{fig:cluster0_6_}
	\end{subfigure}
	\begin{subfigure}[t]{0.49\textwidth}
		\includegraphics[width=\textwidth]{clusters/cluster0_5_.eps}
		\caption{5 communities.}
		\label{fig:cluster0_5_}
	\end{subfigure}
	\begin{subfigure}[t]{0.49\textwidth}
		\includegraphics[width=\textwidth]{clusters/cluster0_4_.eps}
		\caption{4 communities.}
		\label{fig:cluster0_4_}
	\end{subfigure}
	\begin{subfigure}[t]{0.49\textwidth}
		\includegraphics[width=\textwidth]{clusters/cluster0_3_.eps}
		\caption{3 communities.}
		\label{fig:cluster0_3_}
	\end{subfigure}
	\caption{The relevant clusterings detected at different time scales for $T=1$ year.}
	\label{fig:cluster0}
\end{figure}

%------------------ T = 10 -----------------------------%

\begin{figure}[H]
	\centering
	\includegraphics[width = .7\textwidth]{clusters/stab1.eps}
	\caption{Stability, number of communities and variation of information as a function of the Markov time for $T=10$ years.}
	\label{fig:stab1}
\end{figure}

\begin{figure}[H]
	\centering
	\begin{subfigure}[t]{0.49\textwidth}
		\includegraphics[width=\textwidth]{clusters/cluster1_6_.eps}
		\caption{6 communities.}
		\label{fig:cluster1_6_}
	\end{subfigure}
	\begin{subfigure}[t]{0.49\textwidth}
		\includegraphics[width=\textwidth]{clusters/cluster1_5_num.eps}
		\caption{5 communities.}
		\label{fig:cluster1_5_}
	\end{subfigure}
	\begin{subfigure}[t]{0.49\textwidth}
		\includegraphics[width=\textwidth]{clusters/cluster1_3_.eps}
		\caption{3 communities.}
		\label{fig:cluster1_3_}
	\end{subfigure}
	\begin{subfigure}[t]{0.49\textwidth}
		\includegraphics[width=\textwidth]{clusters/cluster1_2_.eps}
		\caption{2 communities detected by the algorithm which should rather be considered as being 3 communities.}
		\label{fig:cluster1_2_}
	\end{subfigure}
	\caption{The relevant clusterings detected at different time scales for $T=10$ years.}
	\label{fig:cluster1}
\end{figure}

%------------------ T = 50 -----------------------------%
\begin{figure}[H]
	\centering
	\includegraphics[width = .7\textwidth]{clusters/stab5.eps}
	\caption{Stability, number of communities and variation of information as a function of the Markov time for $T=50$ years.}
	\label{fig:stab5}
\end{figure}

\begin{figure}[H]
	\centering
	\begin{subfigure}[t]{0.49\textwidth}
		\includegraphics[width=\textwidth]{clusters/cluster5_6_.eps}
		\caption{6 communities.}
		\label{fig:cluster5_6_}
	\end{subfigure}
	\begin{subfigure}[t]{0.49\textwidth}
		\includegraphics[width=\textwidth]{clusters/cluster5_5_.eps}
		\caption{5 communities.}
		\label{fig:cluster5_5_}
	\end{subfigure}
	\begin{subfigure}[t]{0.49\textwidth}
		\includegraphics[width=\textwidth]{clusters/cluster5_3_.eps}
		\caption{3 communities.}
		\label{fig:cluster5_3_}
	\end{subfigure}
	\begin{subfigure}[t]{0.49\textwidth}
		\includegraphics[width=\textwidth]{clusters/cluster5_2_.eps}
		\caption{2 communities.}
		\label{fig:cluster5_2_}
	\end{subfigure}
	\caption{The relevant clusterings detected at different time scales for $T=50$ years.}
	\label{fig:cluster5}
\end{figure}

%------------------ T = 100 ----------------------------%
\begin{figure}[H]
	\centering
	\includegraphics[width = .7\textwidth]{clusters/stab10.eps}
	\caption{Stability, number of communities and variation of information as a function of the Markov time for $T=100$ years.}
	\label{fig:stab10}
\end{figure}

\begin{figure}[H]
	\centering
	\begin{subfigure}[t]{0.49\textwidth}
		\includegraphics[width=\textwidth]{clusters/cluster10_3_.eps}
		\caption{3 communities.}
		\label{fig:cluster10_3_}
	\end{subfigure}
	\begin{subfigure}[t]{0.49\textwidth}
		\includegraphics[width=\textwidth]{clusters/cluster10_2_.eps}
		\caption{2 communities.}
		\label{fig:cluster10_2_}
	\end{subfigure}
	\caption{The relevant clusterings detected at different time scales for $T=100$ years.}
	\label{fig:cluster10}
\end{figure}


%!TEX root = /home/renaud/Documents/EPL/tfe/latex/tfe.tex
\section{The code} \label{sec:thecode}
The preceding sections cover all the material needed to implement a Lagrangian code that solves a two-dimensional advection-diffusion problem. For the need of this work, a \Cpp code has been implemented. The choice of \Cpp is motivated by the fact that it is \textit{fast}, and that it comes together with a wide range of \textit{open source} supporting tools. Another reason is that \Cpp is an \textit{object-oriented language}, and it is widely held that writing in an object-oriented style leads to programs which are easier to understand, to extend, to maintain and to refactor \cite{pitt2012guide}.

The code deals with the two-dimensional transport equation
\begin{equation} \label{eq:TEcode}
	\frac{\partial C}{\partial t} = \nabla \cdot (-\b u C + \b K \nabla C)
\end{equation}
on rectangular domains with no-through boundary conditions. It allows to simulate trajectories, to compute the concentration and to build the transition probability matrix for a given partitioning of the domain. The trajectories are simulated using the backward Euler method, applied on the system of backward Itô SDE's~\eqref{eq:bi-TM}.
% The user can choose between the Euler-Maruyama \textcolor{red}{attention implémenter drift gradient term} and backward-Itô method to simulate the trajectories. In view of the preceding sections, the Itô SDE corresponding to~\eqref{eq:TEcode} is
In this work, only the box-counting method is used for the estimation of the concentration (and thus also for the computation of the transition probability matrix) but the density kernel estimation method has also been implemented for the sake of completeness.

In order to use the code on a particular problem meeting the above specifications, a class that defines the problem must be implemented. That class must inherit from the abstract base class \mintinline{c++}{AbstractAdvDiffProblem} (see listing~\ref{listing:abstractadvdiffproblem}), and must at least implement the two pure virtual functions of the abstract base class:
\begin{listing}[ht!]
\caption{The abstract base class \cppcode{AbstractAdvDiffProblem}.}
\label{listing:abstractadvdiffproblem}
\begin{minted}[breaklines,tabsize=4,fontsize=\footnotesize,style=tango,escapeinside=||]{c++}
class AbstractAdvDiffProblem
{
	protected:
		double mH0, mH1; // boundaries of the domain in the z-direction : H0 <= z <= H1
		double mL0, mL1; // boundaries of the domain in the y-direction : L0 <= y <= L1

	public:
		AbstractAdvDiffProblem(double H0, double H1, double L0, double L1);
		virtual ~AbstractAdvDiffProblem(){};
		double getH0() const;
		double getH1() const;
		double getL0() const;
		double getL1() const;
		virtual SymMatrix getK(double y, double z) const=0; // diffusivity tensor
		virtual LowerTriMatrix getB(double y, double z) const; // 2K = BB'
		virtual Vec2 getU(double y, double z) const=0; // velocity vector
		virtual void printInfo(std::ofstream& f) const;
};
\end{minted}
\end{listing}
\begin{itemize}[nosep]
	\item \mintinline[style=tango]{c++}{SymMatrix getK(double y, double z)}: returns the diffusivity tensor $\b K$ evaluated at $(y,z)$. The return value is of type \cppcode{SymMatrix}, a structure intended to store a $2\times 2$ symmetric matrix with only three elements stored in memory. Instantiating an object \cppcode{A} of type \cppcode{SymMatrix} is pretty simple: \cppcode{SymMatrix A(a,b,c)} creates the matrix
	\[
		A = \begin{pmatrix} a & b \\ b & c \end{pmatrix},
	\]
	where \cppcode{a}, \cppcode{b} and \cppcode{c} are of type \cppcode{double}. The elements of \cppcode{A} are then accessed via the syntax \cppcode{A(i,j)} which uses one-based indexing. Hence, \cppcode{A(1,1) = a}, \cppcode{A(1,2) = A(2,1) = b} and \cppcode{A(2,2) = c}. The same syntax can be used to modify the elements of \cppcode{A}.
	\item \mintinline[style=tango]{c++}{Vec2 getU(double y, double z)}: returns the velocity vector $\b u$ evaluated at $(y,z)$. The return value is of type \cppcode{Vec2}, a structure that stores two elements of type \cppcode{double}. The syntax \cppcode{Vec2 v(a,b)} is used to create the two-dimensional vector $v = (a,b)$. The elements of \cppcode{v} are accessed via the syntax \cppcode{v(i)} which also uses one-based indexing: \cppcode{v(1) = a} and \cppcode{v(2) = b}.
\end{itemize}
By default, the code computes the matrix $\b B$ using~\eqref{eq:B} and~\eqref{eq:Bstar}. This is done by the function \cppcode{LowerTriMatrix GetB(double y, double z)}. In some cases, it can be interesting to overload that definition of \cppcode{GetB}, which is possible since this function is virtual. The return value must be of type \cppcode{LowerTriMatrix}, which is a structure similar to \cppcode{SymMatrix} but is intended to store lower triangular $2\times2$ matrices instead of symmetric $2\times2$ matrices.

Notice that the code as such implements the dimensional form of the transport model. However, it can be used to run simulations on the adimensional form of the transport model. To this end, it suffice to define the functions \cppcode{getK} and \cppcode{getU} accordingly: \cppcode{getK} shall return the inverse of the Peclet matrix, and \cppcode{getU} shall return the adimensional velocity vector.

Once a class describing the problem is properly defined, three methods can be used to compute either the trajectories, the normalized concentration or the transition probability matrix. We call those methods the \textit{compute methods}. Their signatures are given in listing~\ref{listing:signature_compute}. Since those functions are well documented in the code, we invite the interested reader to refer to the code for further explanations about those functions.
\begin{listing}[ht!]
\caption{Signatures of the \textit{compute methods}.}
\label{listing:signature_compute}
\begin{minted}[breaklines,tabsize=4,fontsize=\footnotesize,style=tango,escapeinside=||]{c++}
void ComputeTrajectories(const AbstractAdvDiffProblem& prob, std::string model,
						 double dt, double T, int Nloc, double yStart, double zStart);
void ComputeConcentration(const AbstractAdvDiffProblem &prob, std::string model,
						  double dt, double T, std::string estimator, int Nloc,
						  double yStart, double zStart, int nboxy, int nboxz);
void ComputeTransitionProbabilities(const AbstractAdvDiffProblem& prob,
									std::string model, int nboxy, int nboxz, int nyloc,
									int nzloc, double dt, double Times[], int nTimes,
									bool binary, std::string estimator = "box");
\end{minted}
\end{listing}

Test cases with analytical solutions have been built to assess the validity of the implementation. They are presented in appendix~\ref{app:test_case} and the numerical solution is compared to the analytical solution, producing satisfying results.
% \begin{itemize}
% 	\item \mintinline{c++}{LowerTriMatrix getB(double y, double z)}:
% 	\item io
% \end{itemize}
% Le code résout des probleme 2D generaux sur un domaine rectangulaire avec des conditions frontières no trough.
% Choix entre Ito (attention alors il faut implémenter le drift gradient velocity) et backward Ito.
% --> Pour résoudre un problème particulier :
% 	1. Implémenter une class problem qui hérite de abstractadvdiff, et dont les méthode minimales sont : ...
% 	AbstractAdvDiff implémente Cholesky par défaut mais on peut aussi implémenter sa propre méthode getB,
%	ce qui permet d'autre choix de B et dans certains cas une meilleure efficacité. (+ exemple)
%	Si on veut de l'adim il suffit de faire K = 1/Pe et U = ...
%	2. Ensuite les méthodes Compute permette de calculer trajectoire, concentration et matrice de transition de proba.
%	Ces méthodes font entre autre appel aux méthodes de la classe solver et de ses enfant. Par exemple backward ito est implémenté dans
%	biSlver par <CODE>.
%	3. Mettre le code "main" dans un studycase (à voir si c'est vraiment intéressant de parler des studycases)
%
% \begin{listing}[ht!]
% \caption{Implementation of the backward Euler method.}
% \label{listing:updateposition}
% \begin{minted}[breaklines,tabsize=4,fontsize=\footnotesize,style=tango,escapeinside=||]{c++}
% void BISolver::UpdatePosition(const AbstractAdvDiffProblem& prob)
% {
% 	LowerTriMatrix B;
% 	Vec2 U;
% 	double R1, R2, dY, dZ, y, z, ypred, zpred;
% 	double sqrt_dt = sqrt(mdt);
% 	for (int i=0; i<mParticles.mN; i++)
% 	{
% 		// position and speed of particle i at time t
% 		y = mParticles.mY[i];
% 		z = mParticles.mZ[i];
% 		U = prob.getU(y,z);
% 		B = prob.getB(y,z);
% 		// realisations of the noises
% 		R1 = wiener(generator);
% 		R2 = wiener(generator);
% 		// prediction step of the backward-Ito scheme
% 		dY = B(1,1)*sqrt_dt*R1;
% 		dZ = B(2,1)*sqrt_dt*R1 + B(2,2)*sqrt_dt*R2;
% 		// No-through BC also applies on the predictions -> bouncing on the walls
% 		ypred = y+dY;
% 		zpred = z+dZ;
% 		ypred = (ypred < prob.getL0()) ? 2*prob.getL0()-|\color{black}{ypred}| :
% 				(ypred > prob.getL1()) ? 2*prob.getL1()-|\color{black}{ypred}| : ypred;
% 		zpred = (zpred < prob.getH0()) ? 2*prob.getH0()-|\color{black}{zpred}| :
% 				(zpred > prob.getH1()) ? 2*prob.getH1()-|\color{black}{zpred}| : zpred;
% 		// amplitude of the noises
% 		B = prob.getB(ypred,zpred);
% 		/* update particles positions using backward-Ito scheme
% 		* No-flux BC : Bounce on the wall */
% 		ypred = mParticles.mY[i] + U(1)*mdt + B(1,1)*sqrt_dt*R1;
% 		zpred = mParticles.mZ[i] + U(2)*mdt + B(2,1)*sqrt_dt*R1 + B(2,2)*sqrt_dt*R2;
% 		mParticles.mY[i] = (ypred < prob.getL0()) ? 2*prob.getL0()-|\color{black}{ypred}| :
% 						   (ypred > prob.getL1()) ? 2*prob.getL1()-|\color{black}{ypred}| : ypred;
% 		mParticles.mZ[i] = (zpred < prob.getH0()) ? 2*prob.getH0()-|\color{black}{zpred}| :
% 						   (zpred > prob.getH1()) ? 2*prob.getH1()-|\color{black}{zpred}| : zpred;
% 	}
% 	mParticles.mTime += mdt;
% }
% \end{minted}
% \end{listing}


\documentclass[12pt]{cdblatex}
\usepackage{eqtns}

\begin{document}

\section*{PhysRevD.62.044034 equation (15)}

\begin{cadabra}
   from shared import *
   import cdblib

   jsonfile = 'eqtn15.json'
   cdblib.create (jsonfile)

   defG2GBar = cdblib.get ('defG2GBar','gamma.json')

   # --------------------------------------------------------------------------
   # Rphi = the part of Rab from the conformal factor

   Rab := R_{a b}.                                                   # cdb (eq15.101,Rab)

   substitute     (Rab, defRab)                                      # cdb (eq15.102,Rab)
   substitute     (Rab, defRiem)                                     # cdb (eq15.103,Rab)
   substitute     (Rab, defG2GBar)                                   # cdb (eq15.104,Rab)
   distribute     (Rab)                                              # cdb (eq15.105,Rab)
   product_rule   (Rab)                                              # cdb (eq15.106,Rab)
   Rab = product_sort (Rab)                                          # cdb (eq15.107,Rab)
   rename_dummies (Rab)                                              # cdb (eq15.108,Rab)
   canonicalise   (Rab)                                              # cdb (eq15.109,Rab)
   substitute     (Rab, $gBar_{b c} gBar^{c a} -> gBar^{a}_{b}$)
   substitute     (Rab, $\partial_{a}{gBar^{a}_{b}} -> 0$)
   substitute     (Rab, $\partial_{a}{gBar_{b}^{c}} -> 0$)
   substitute     (Rab, $gBar^{a}_{a} -> 3$)
   eliminate_kronecker (Rab)                                         # cdb (eq15.110,Rab)
   Rab = product_sort (Rab)                                          # cdb (eq15.111,Rab)
   rename_dummies (Rab)                                              # cdb (eq15.112,Rab)
   canonicalise   (Rab)                                              # cdb (eq15.113,Rab)
   substitute     (Rab, $gBar_{b c} gBar^{c a} -> gBar^{a}_{b}$)     # cdb (eq15.114,Rab)
   substitute     (Rab, $gBar^{a}_{a} -> 3$)                         # cdb (eq15.115,Rab)
   eliminate_kronecker (Rab)                                         # cdb (eq15.116,Rab)

   # |\clearpage|
   # isolate Rphi from Rab by switching to local RNC

   Rphi := @(Rab).

   substitute (Rphi, $GammaBar^{a}_{b c}->0$)                        # cdb (eq15.117,Rphi)
   substitute (Rphi, $\partial_{a}{gBar_{b c}}->0$)                  # cdb (eq15.118,Rphi)
   substitute (Rphi, $\partial_{a}{gBar^{b c}}->0$)                  # cdb (eq15.119,Rphi)

   substitute (Rphi, $\partial_{a b}{\phi} -> DBar_{a b}{\phi}$)     # cdb (eq15.120,Rphi)
   substitute (Rphi, $\partial_{a}{\phi} -> DBar_{a}{\phi}$)         # cdb (eq15.121,Rphi)

   defRphi := Rphi_{a b} -> @(Rphi).

   cdblib.put ('defRphi',defRphi,jsonfile)
\end{cadabra}

\clearpage

\begin{dgroup*}[spread=5pt]
   \begin{dmath*}
      \cdb{eq15.101}
         = \Cdb*{eq15.102}
         = \Cdb*{eq15.103}
         = \Cdb*[\hskip2.5cm\hfill]{eq15.104}
         = \Cdb*{eq15.105}
         = \Cdb*{eq15.106}
         = \Cdb*{eq15.107}
   \end{dmath*}
\end{dgroup*}

\clearpage

\begin{dgroup*}[spread=5pt]
   \begin{dmath*}
      \cdb{eq15.101}
         = \Cdb*{eq15.108}
         = \Cdb*[\hskip2cm\hfill]{eq15.109}
         = \Cdb*{eq15.110}
         = \Cdb*{eq15.111}
         = \Cdb*{eq15.112}
   \end{dmath*}
\end{dgroup*}

\clearpage

\begin{dgroup*}[spread=5pt]
   \begin{dmath*}
      \cdb{eq15.101}
         = \Cdb*[\hskip2.5cm\hfill]{eq15.113}
         = \Cdb*[\hskip2.5cm\hfill]{eq15.114}
         = \Cdb*{eq15.115}
         = \Cdb*{eq15.116}
   \end{dmath*}
\end{dgroup*}

The above doesn't look much like equation (15). So, what do we do? First note that {\tt (eq15.116)}
represents the full $R_{ab}$, that is, equation (14). To isolate the contributions from $\phi$
we can first set $\bar{\Gamma}$ and its derivatives to zero (which in turn requires setting
$\partial_{a} \bar{g}_{bc}=0$). The result is equation {\tt (eq15.119)} below. Having set
$\bar{\Gamma}$ to zero means that we can replace $\partial$ with $\bar{D}$ leading to equation
{\tt (eq15.121)}. But that is clearly a tensor equation and so by the usual arguments it must be true
in all frames (not just this frame with $\bar{\Gamma}=0$). It's a standard argument and I've
probably overdone the discussion. Anyway, equation {\tt (eq15.121)} is exactly equation $(15)$ from
the paper. Yeah.

\begin{dgroup*}[spread=5pt]
   \begin{dmath*}
      R^{\phi}_{ab}
         = \Cdb*{eq15.117}
         = \Cdb*{eq15.118}
         = \Cdb*{eq15.119}
         = \Cdb*{eq15.120}
         = \Cdb*{eq15.121}
   \end{dmath*}
\end{dgroup*}

\clearpage

\begin{cadabra}
   # --------------------------------------------------------------------------
   # Check against prd62.

   foo := @(Rphi).                                      # cdb(eq15.lcb,foo)
   bah  = cdblib.get('prd62.eq15.rhs','prd62.json')     # cdb(eq15.prd,bah)

   diff := @(foo) - @(bah).

   distribute     (diff)
   diff = product_sort (diff)
   rename_dummies (diff)
   map_sympy      (diff, "simplify")
   canonicalise   (diff)                                # cdb(eq15.chk,diff)
\end{cadabra}

% \clearpage

\begin{dgroup*}
   \begin{dmath*} \cdb*{eq15.lcb} \end{dmath*}
   \begin{dmath*} \cdb*{eq15.prd} \end{dmath*}
   \begin{dmath*} \cdb*{eq15.chk} \end{dmath*}
\end{dgroup*}

\end{document}


\documentclass{report}
\begin{document}
\title{A generic heap interface specification for Common Lisp}
\author{Ingvar Mattsson \\ {\tt <ingvar@google.com>}}
\maketitle

\chapter{Generic extendable heaps for Common Lisp}
\section{Rationale}
 There is no standard heap implementation in the Common Lisp
 standard. It is, however, a useful data structure. Having a generic
 heap implementation that is tweakable to allow for the exact
 behaviour wanted and peforms relatively well is wanted.

 The intention is to provide a portable, flexible, performant heap
 framework that can be used on essentially all data where storing
 according to a ranking criterion makes sense.

 This API specification carefully does not discuss how it behaves in a
 multi-processing environment.

\section{Guarantees}
\subsection{Time complexity}
The heap data structure gives you $O(1)$ peek at one extreme of the
heap. It also gives you $O(log n)$ addition and removal from the heap.

However, the $O(log n)$ insertion and removal relies on an O(1)
comparison operator. With having user-specified comparison (and key
extraction) operators, the best guarantee the reference implemenation
can give is that insertion and removal is $O(C log n)$ for a
comparator complexity of $O(C)$.

\subsection{Multi-processing}
There are no explicit multi-processing or concurrency guarantees for
the generic heaps. However, implementors are encouraged to add
recursive locks to each heap object and lock/unlock these as
necessary.

\subsection{Side-effects}

Any code that modifies an object currently in the heap is likely to
breach the heap invariant. Doing that is highly discouraged. However,
modifying things within an object that does not, in any way,
contribute to the value used in comparisons may be safe.

\section{Interface specification}
 \subsection{Package}
 All symbols of a generic heap implementation should be accessible in
 a package names such that :genheap is a designator for the
 package.

 This means that only one GENHEAP implementation can be loaded in any
 given image, without having to do package renaming. However, it makes
 it easier for devbelopers to write code against the package or probe
 for the package's existence using FIND-PACKAGE.

 The functional interface presented is a minimum interface, it may be
 that an implementor is willing to give guarantees for the
 implementation that extend beyond this.

 The exact underlying data structures are not specified. The reference
 implementations use CLOS, generic functions and methods on these for
 its implementation. One of them defines new methods as new generic
 heap types are asked for, the other one doesn't.

 \subsection{Functional interface}
 \subsubsection{make-heap}
   (make-heap \&key (test #'<) (initial-size 16) (key \#'identity)) -> heap

 Returns a newly created heap, using the specified test as the heap
 criterion, using {\sl key} as the value to be compared. The key
 defaults to the identity function.

 \subsubsection{insert}
   (insert value heap) -> value

 Inserts a new element into the heap. The value inserted is returned.

 \subsubsection{remove}
   (remove heap) -> (or value nil)

 Removes and returns the value at the head of the heap, unless the
 heap is empty. If the heap is empty, NIL is returned.

 \subsubsection{emptyp}
   (emptyp heap) -> boolean

 This function returns T when called on an empty heap, NIL otherwise.

 \subsubsection{heapify}
   (heapify sequence \&key (test #'<) (key \#'identity)) -> heap

 Creates a heap populated by the sequence passed in, returning a heap
 that should behave identically as one created by MAKE-HEAP, then
 populated element by element.

 \subsubsection{peek}
   (peek heap) -> value

 Returns the value at the top of the heap, without modifying the heap.

 \subsubsection{heap-p}
   (heap-p object) -> boolean

 This function returns NIL when called on a non-heap object and a true
 value if presented with a heap object.

 \subsubsection(MACRO declare-heap)
   (declare-heap \&key (test \#'<) (key \#'identity))

 This macro either updates internal data structures about a specific
 type of test/key pair or not. It should be called before any
 heap with that test/key pair is created.

 The presence of this macro is to make heap-creation time more
 predictable, allowing the implementation to do any heavy
 class-creation up front, instead of at the time of the first heap
 being created.

\end{document}


\subsection{Quantitative}
\label{subsec:appendix-experiments-quantitative}

\begin{figure*}
	\centering
	\input{plots/appendix-sbd-avg}
	\input{plots/appendix-sunrgbd-avg}
	\input{plots/appendix-fash-avg}
	\caption{\Rec, \UE and \EV on the \SBD, \SUNRGBD and \Fash datasets. Similar to the results
	presented for the \BSDS and \NYU datasets (compare Figures \ref{fig:experiments-quantitative-bsds500}
	and \ref{fig:experiments-quantitative-nyuv2}), \Rec and \UE give a roguh overview of
	algorithm performance with respect to ground truth. Concerning \Rec, we observe
	similar performance across the three datasets, while algorithms may show different
	behavior with respect to \UE. Similarly, \EV gives a ground truth independent
	overview of algorithm performance where algorithms show similar performance across datasets.
	\textbf{Best viewed in color.}}
	\label{fig:appendix-experiments-sbd-sunrgbd-fash}
	\vskip 12px
	\input{legends/full+depth}
\end{figure*}
\begin{figure*}
	\centering
	\input{plots/appendix-runtime}
	\caption{Runtime in seconds $t$ on the \SBD, \SUNRGBD and \Fash datasets. The results allow
	to get an impression of how runtime of individual algorithms scales with the size
	of the image. In particular, we deduce that most algorithm's runtime scales linear
	in the input size, while the number of generated superpixels does have little influence.
	\textbf{Best viewed in color.}}
	\label{fig:appendix-experiments-runtime}
\end{figure*}
\begin{figure*}
	\centering
	\input{plots/appendix-bsds500-ue-asa-uel}\\
	\input{plots/appendix-nyuv2-ue-asa-uel}
	\caption{\UE, \ASA and \UEL on the \BSDS and \NYU datasets. We find that \ASA does not
	provide new insights compared to \UE, as it closely reflects $(1 - \UE)$ except
	for a minor absolute offset. \UEL, in contrast, provides a different point view
	compared to \UE. However, \UEL is harder to interpret and strongly varies across datasets.
	\textbf{Best viewed in color.}}
	\label{fig:appendix-experiments-bsds500-nyuv2}
	\vskip 12px
	\input{legends/full+depth}
\end{figure*}

The following experiments complement the discussion in Section \ref{subsec:experiments-quantitative}
in two regards. First, we present additional experiments considering both \ASA and
\UEL on the \BSDS and \NYU datasets. Then, we consider \Rec, \UE and \EV in more details for
the remaining datasets, \ie the \SBD, \SUNRGBD and \Fash datasets. We begin by discussing \ASA
and \UEL, also in regard to the observations made in Sections \ref{subsec:benchmark-correlation} and \ref{sec:appendix-benchmark}.

As observed on the \BSDS and \NYU datasets in Section \ref{subsec:experiments-quantitative},
\Rec and \UE can be used to roughly asses superpixel algorithms based on ground
truth. However, for large \K, these metrics are not necessarily
sufficient to discriminate between the superpixel algorithms. Considering Figure
\ref{fig:appendix-experiments-sbd-sunrgbd-fash}, in particular with regard to
\Rec, we can identify algorithms showing above-average performance such as \ETPS
and \SEEDS. These algorithms perform well on all three datasets. Similarly,
\PF, \QS, \SEAW and \TPS perform poorly on all three datasets. Regarding \UE,
in contrast, top-performer across all three algorithms are not identified as easily.
For example, \POISE demonstrates low \UE on the \SBD and \Fash datasets, while performing
poorly on the \SUNRGBD dataset. Similarly, \ERS shows excellent performance on the \SUNRGBD dataset,
while being outperformed by \POISE as well as \ETPS on the \SBD and \Fash datasets.
Overall, \Rec and \UE do not necessarily give a consistent
view on the performance of the superpixel algorithms across datasets. This may also
be explained by the ground truth quality as already discussed in Section \ref{subsec:experiments-quantitative}.

The above observations also justify the use of \EV to judge superpixel algorithms
independent of ground truth. Considering Figure \ref{fig:appendix-experiments-sbd-sunrgbd-fash},
in particular, with regard to \EV, we can observe a more consistent view across the datasets.
Both, top-performing algorithms such as \ETPS and \SEEDS, as well as poorly performing
algorithms such as \PF, \PB or \TPS can easily be identified. In between these two extremes,
superpixel algorithms are easier to discriminate compared to \Rec and \UE. Furthermore,
some superpixel algorithms such as \QS, \FH or \CIS are performing better compared to
\Rec or \UE. This confirms the observations that ground truth independent assessment
is beneficial but cannot replace \Rec or \UE.

We find that \ASA closely mimicks the behavior of $(1 - \UE)$ while \UEL may
complement our discussion with an additional viewpoint which is, however, hard to interpret.
We consider Figure \ref{fig:appendix-experiments-bsds500-nyuv2}
showing \UE, \ASA and \UEL for both the \BSDS and \NYU datasets. Focussing on \UE and
\ASA, we easily see that \ASA nearly reflects $(1 - \UE)$ while being a small
constant off. In particular, all algorithms exhibit nearly the same behavior,
while absolutely the algorithms show higher \ASA
compared to $(1 - \UE)$. This demonstrates that \ASA does not give new insights
with respect to the quantitative comparison of superpixel algorithms. In contrast,
the algorithms show different behavior considering \UEL. This is mainly due to the
unconstrained range of \UEL (compared to $\UE \in [0,1]$). In particular,
for algorithms such as \EAMS and \FH, \UEL reflects the behavior of $\max\UE$
as shown in Figure \ref{subfig:experiments-quantitative-bsds500-ue_np.max_max}.
The remaining algorithms lie more closely together.
Still, algorithms such as \ERS, \SEEDS or \PB show better \UEL than \UE (seen relatively to the remaining algorithms).
In the case of \EAMS and \FH, high \UEL may indeed
be explained by the considerations of Neubert and Protzel \cite{NeubertProtzel:2012}
arguing that \UEL unjustly penalizes large superpixels slightly overlapping with multiple ground truth segments.
For the remaining algorithms,
the same argument can only be applied in smaller scale as these algorithms usually
do not generate large superpixels. In this line of throught, the excellent
performance of \ERS may be explained by the employed regularizer for enforcing
uniform superpixel size. Overall, \ASA does not contribute to an insightful discussion,
while \UEL may be considered in addition to \UE to complete the picture of algorithm performance.


\newcommand{\sigmatwo}{\overline{\sigma}}
The current query evaluation mechanism for \datalogM is a bottom-up naive\cite{Green:2013:DRQ:2688167.2688168} evaluation. It is based on the fixpoint-theoretic semantics, deriving tuples from rules until no new tuples may be derived. The rule evaluation is performed using relational algebra (see e.g. \cite{Abiteboul:1995:FDL:551350}) and a thorough description is given in Appendix A.

\subsection{Mutual Dependencies and Predicate Ordering}
With multiple rules and potentially many mutual dependencies between the predicates, there is a need to find an order in which to apply the rules. Indeed, for mutually dependent predicates, all rules which may derive new facts for those predicates need to be iterated together. \textit{Stratification}\cite{Green:2013:DRQ:2688167.2688168} is the process of clustering the predicates that need to be computed together into so called \textit{strata} as well as to find an optimal order between the strata. The iterative fix-point algorithm is then run over each \textit{stratum} following the computed order. The process is formalized below.

A predicate $P_i$ \textit{directly depends} on predicate $P_j$ iff there exists a rule for which $P_i$ is in the head and $P_j$ is in the body. Let $Dep(P_i)$ be the set of predicates which $P_i$ directly depends on. The dependency graph $G_{DEP}$ has the set of predicate symbols as vertices and there is an edge from $P_i$ to $P_j$ iff $P_j \in DEP(P_i)$. A strongly connected component in $G_{DEP}$ then contains the predicates which are mutually recursive. Such a connected component can be found e.g. using Tarjan's algorithm \cite{Tarjan72depthfirst} and is called a stratum. By merging the vertices of $G_{DEP}$ into such strata we get a graph $G_{STRAT}$ with vertices being the strata of $G_{DEP}$ and edges the collapsed multi-edges from $G_{DEP}$. By construction there exists a total order on $G_{STRAT}$ with $S_1 < S_2$ iff $(S_1, S_2) \in Edge(G_{STRAT})$. The desired order is found by a reverse post-order search of $G_{STRAT}$.
\begin{figure*}[!hbt]
	\includegraphics[scale=0.7]{img/souffleEval.pdf}
	\caption{Souffle Printing Pipeline. \textbf{Yellow}: A Datalog Program. \textbf{Blue}: An evaluation mechanism. \textbf{Green}: A compiler stage. }
	\label{figure:soufflePipeline}
\end{figure*}
\subsection{Cross Compilation}
In addition to internal evaluation, $Datalog^M$ supports cross-compilation, or pretty-printing, to Souffle\cite{SouffleHome}. The compilation pipeline is shown in figure \ref{figure:soufflePipeline}. First, a number of semantic checks are performed. For example, the semantic check ensures that all variables used in the head of a rule also occures in the body of the rule (the range restriction property\cite{Ceri:1989:YAW:627272.627357}). In the next stage, the program is type checked (type-checking is described in more detail in the following section). As was mentioned in the introduction (and will be explained in the next section), \datalogM supports meta-predicates. Souffle however has no such support so naturally it does not recognize the meta-semantics. To this end, a separate pre-process Datalog program is generated to evaluate all meta-predicates and subsequently output them as EDB files. Finally, the program is pretty-printed to a Souffle program $P_{Souffle}$. $P_{Souffle}$ declares the meta-predicates and loads them from the EDB files; the meta-predicates can then be used as ordinary predicates within the Souffle environment.


% !TeX root = ../main.tex
% Add the above to each chapter to make compiling the PDF easier in some editors.
\graphicspath{{./figures/ch4/}}

\chapter{Simulation}\label{chapter:simulation}

To find out how the HPB format influences efficiency and revenue in comparison to the SMRA, I ran several simulations based on the findings in the previous chapter. For the bidders to act as agents in the auction simulations, they need a strategy and a suitable selection heuristic to model their behaviour and thus to place bids. In this chapter I will at first give an overview of the structure of the implementation, followed by a further description of the simulation process by defining the setup as well as the strategy and the selector model. Afterwards, I will present the findings of the experiment.

\section{Structure of the Project}
In order to run the simulations I extended an existing project from the university chair. In this project, an abstract structure on how to run auction simulations was given by an already defined software architecture. \autoref{fig:structure-sim} visualises the structure I used for my experiment. The whole project was implemented in Python.

As can be seen from the visualisation, a main \textbf{Auction} object exists, that has an own \textbf{AuctionFormat} which specifies the auction characteristics and the procedure, as well as a collection of agents participating. Every \textbf{Agent} possesses a bidding \textbf{Strategy} which in turn holds a \textbf{Selector}. The latter computes optimal bidding vectors based on the chosen selector model (e.g. a naive exhaust approach by iterating over each possible bid). Then the strategy translates these into according actions like submitting a bid based on the selector's result or calling a waiver to exclude the agent from bidding in the current round. The strategy class realises this by comparing the payoff $ \pi_{combination} $ of different combinations, where payoff is defined as a \textit{quasilinear utility function} by subtracting the prices $ p(combination) $ a bidder has to pay from the bidder's valuation $ v(combination) $ for a certain bidding combination.

\begin{equation}
	\centering
	\pi_{combination} = v(combination) - p(combination)
	\label{eq:payoff}
\end{equation}

The valuation $ v(combination) $ can be obtained by the strategy class using its \textbf{ValueModel}. This model has access to the \textbf{ItemStructure}, which holds the \textbf{Items} of the auction as well as possible packages, mapping (e.g. to frequency bands), or hierarchies. Before submitting a bid, the action gets validated by the \textbf{BidderInfo} class (e.g. to check if spectrum cap instructions were followed). After each successful round, the important information like \textit{payments, prices}, and the current \textit{allocation} are saved in the \textbf{RoundInfo}.

\begin{figure}[h]
	\centering
	\includegraphics[scale=0.4]{structure.png}
	\caption{Structure of the simulation implementation} \label{fig:structure-sim}
\end{figure}

To simulate the auctions I had to extend the existing auction formats for SMRA and HPB. Making it possible to fill them with the specific characteristics of the German auction. In particular, this included implementing the spectrum cap of three blocks in the 900 MHz band and extending mechanisms in the HPB format. Also, I needed to implement the mathematical formulation of the value model (see \autoref{subsection:value-model}) as well as the specific selector model, which is based on the value model. Furthermore, I implemented a sealed bid model to calculate the optimal allocation needed to compare the two auction formats.

\section{The Simulation Process}
As stated in the previous section, in order to run the simulations based on the information and data of the German Auction I needed to extend and further develop the existing project. In this section I will describe the set-up of the auctions (e.g. the items and hierarchies used) as well as the implementation of the value, strategy and selector model.

\subsection{Auction Set-Up}
As discussed in the Value Model section, the simulation concentrated on the 700, 900 and 1800 MHz frequency bands, which include a total of 23 items. Each bidder was able to bid on every item and item combination. For the first round, the starting prices were appointed according to the official definition of the German Auction \cite{Bundesnetzagentur2015} as provided in \autoref{tbl:start-parms}.

\begin{table}[h]
	\centering
	\begin{tabular}{|c|c|c|c|}
		\hline
		\textbf{block} & \textbf{quantity} & \textbf{\begin{tabular}[c]{@{}c@{}}starting\\ price\end{tabular}} & \textbf{\begin{tabular}[c]{@{}c@{}}eligibility\\ points\end{tabular}} \\ \hline
		700 MHz        & 6                 & EUR 75 mn                                                         & 2                                                                     \\ \hline
		900 MHz        & 7                 & EUR 75 mn                                                         & 2                                                                     \\ \hline
		1800 MHz       & 10                & EUR 37.5 mn                                                       & 2                                                                     \\ \hline
	\end{tabular}
	\caption{Starting parameters for the items in the auction}
	\label{tbl:start-parms}
\end{table}
The activity level was chosen to be 65\% of the eligibility points held by each bidder in every round. This is the activity level chosen in the first phase of the German Auction. As no mathematical progression rule for the phase shifts exists, because they are decided by the auction moderator \cite{Bundesnetzagentur2015}, the activity level stayed the same throughout the auction simulations.
Furthermore, the exposure ratio (the degree to which a bidder can overbid the valuation of an item) was set very high, practically eliminating exposure. This decision was made, as deriving a fitting exposure ratio for the simulation was out of the scope of this thesis. I will discuss the implications in \autoref{chapter:conclusion}.

As HPB makes use of pre-defined packaging of items using a tree structure, I needed to develop a useful item hierarchy to be used in the simulation. To show how the hierarchy affects the bidding and thus efficiency and revenue, I created two slightly different hierarchy models. As the 900 MHz band had a spectrum cap, the bidders were limited on how many items they can acquire (here: maximum of three blocks). The other bands had no such limitations, thus each bidder would try to acquire the most items possible under the constraints of item valuations and maximizing payoff. To research the impact of the hierarchies on the bidding behaviour, I devised two different hierarchies that had different pre-packaging in the 900 MHz band, because bidders were only allowed to acquire up to three blocks, a combination that had super-additive valuation for the bidders (\autoref{subsection:value-model}) and I assumed the competition to be high in this band. \autoref{fig:hpb-hierarchy-competition} shows the item hierarchy called $ H_{competition} $, where one package of three items (reflecting a desired bundling) exists in the structure. The hierarchy is called "competition" as only one of the desired bundling exists.

\begin{figure}[]
	\centering
	\input{./figures/ch4/hierarchy_competition.tikz}
	\input{./figures/ch4/h_1800.tikz}
	\caption{HPB Hierarchy "Competition", packages with bonus in red}
	\label{fig:hpb-hierarchy-competition}
\end{figure}

As the 900 MHz band consists of seven items, it has enough items for incorporating two bundles of three items each. I assumed that following the formulation and the bonuses of the value model (see \autoref{subsection:value-model}) at least two bidders will try to acquire bonus enabling packages. This is what $ H_{VM} $ in \autoref{fig:hpb-hierarchy-vm-predict} incorporates.
Note, that bidders were still able to gain super-additive valuation by bidding on single items (in different packages) and still be able to successfully secure three items in the 900 MHz band. In the HPB simulation, the advantage for bidders was that they could bid on packages, signalling an interest in a certain item combination. When bidding on the package, the bidder either acquires all the items in its desired packaging or none, thus resulting in a reduced exposure risk for the bidders as it prevents him from potentially bidding above an item's valuation in order to realise a certain item combination.

\begin{figure}[]
	\centering
	\input{./figures/ch4/hierarchy_vm_predict.tikz}
	\input{./figures/ch4/h_1800.tikz}
	\caption{HPB Hierarchy "VM Prediction", packages with bonus in red}
	\label{fig:hpb-hierarchy-vm-predict}
\end{figure}

\subsection{Strategy and Selector Model}
In the simulation, the participating agents needed to emulate a certain bidding behaviour. This is realised by the strategy model. In this experiment, the bidders followed a \textbf{straightforward bidding} behaviour, essentially meaning that they always bid according to the minimum prices in each round \cite[p. 270.]{Milgrom2000}. This can be described as a function $ p(I) $ that returns the bidding price of an item according to minimum prices, where $ \beta $ is the current bid price \cite[p. 6 ff.]{Wellman2008}.

\begin{equation}
	p(I) =
		\begin{cases}
			\beta & \text{if item is already won} \\
			\beta + increment & \text{otherwise}
		\end{cases}
		\label{eq:sb-prices}
\end{equation}

The straightforward bidding is also called \textit{"myopic best response"} \cite{Brooks2000}. Additionally, the strategy used in the simulation is payoff maximizing.

As explained in the section above, value models return the valuation of certain item combinations and selectors return optimal bidding vectors $ \vec{\theta} $. The strategy model translates the results into an according action, e.g. a bid based on a payoff maximizing strategy.

One could argue that once the simulations are run on a computer, finding the best bidding combination should be done via an exhaustive iteration over every single possible combination. However, using this approach showed to be an ineffective use of time and to be computationally expensive. The number of items in the simulation was 23. Lining up all the items in fixed order and using a binary vector to display if each respective item should be included into a bid creates the vector $ \vec{\theta} \in \{0,1\}^{23} $. With simple combinatorics it can be deduced, that computing every possible allocation takes $ 2^{23} \approx 8.388 \times 10^{6} $ iterations. Remembering that 700 MHz had 6 blocks, 900 MHz 7 blocks and 1800 MHz 10 blocks and taking into account, that bidders were only allowed to acquire up to three blocks in the 900 MHz band, the number of iteration can be reduced to $$ 2^6 * \sum_{i=1}^{3} \binom{n}{k} * 2^{10} = 2^6 * (2^6 - 1) * 2^{10} = 2^{16} * (2^6-1) = 2^{22} - 2^{16} \approx 4.1 \times 10^6 $$
Due to the current implementation in the project, this has to be done twice for each of the three bidders, requiring an amount of $ 2 \times 3 \times 2^{22} - 2^{16} \approx 25.1 \times 10^{6} $ computation steps each auction round.
Clearly, a different approach was needed to select the optimal bidding vector.

Instead, a \textbf{mixed integer linear program} (MILP) %TODO abbr
was used to compute the optimized bidding vector $ \vec{\theta} $. For that, I extended existing code for an additive payoff selector from the main project and added the specific bonuses and caps to the LP. Additionally, the bidders had to incorporate bidding on packages, when the payoff for single items and package bids were the same. This behaviour was integrated by adding a \textit{very small} bonus for using packages to the objective function (Epsilon-Method). When a bidder would bid on a package, the payoff would be marginally higher than when bidding on the single items, but by only a very small number which does not affect the overall allocation. The MILP formulation is very similar to the one in \autoref{subsection:meth-evaluation}, but this time only computes the best allocation for a single bidder. Also, the bidder's objective function was extended by the small "bidding-on-HPB-package-bonus", so that the selector MILP can take the existing package hierarchy into account. So for each super-additive package $ p \in Hierarchy $ the objective function increases by a very small amount (in comparison to the sum of all the valuations) if the package was bid on. This leads to the following MILP formulation, where $ Hierarchy_{900}, Hierarchy_{1800} \in Hierarchy $ are the respective subsets of packages in the 900 and 1800 MHz bands and $ Hierarchy_{900bonus} \in Hierarchy_{900}, Hierarchy_{1800bonus} \in Hierarchy_{1800} $ the respective subsets with bonus packages. Additionally, $ bonusV_{900} $ and $ bonusV_{1800} $ stand for the bidder's valuation of the bonuses, they correspond to the $ V_{MNO}^{900_3} $ and $ V_{MNO}^{1800_4} $ from \autoref{subsection:value-model}  where $ MNO $ equals the respective bidder.

\begin{align*}
	& {\text{maximize}}
	& & \sum_{i \in Items} ass_{i} * V_{i} + b_{900} * bonusV_{900}  + b_{1800} *bonusV_{1800} \\
	& & & + \varepsilon * \Bigg[ \sum_{p \in Hierarchy_{900bonus}} m_p + \sum_{p \in Hierarchy_{1800bonus}} m_p \Bigg] \\
	& \text{subject to}
	& & \sum_{i \in Items_{900}}  ass_{i}  \geq 3 *  b_{900} \tag{\textit{Bonus in 900 MHz}}  \\
	&&& \sum_{i \in Items_{1800}}  ass_{i}  \geq 4 *  b_{1800} \tag{\textit{Bonus in 1800 MHz}} \\
	&&& \sum_{i \in Items_{900}}  ass_{i}  \leq 3 \tag{\textit{Caps in 900 MHz}} \\
	&&& \sum_{i \in p} ass_i \geq |p| * m_p \quad \forall p \in Hierarchy_{900bonus} \cup Hierarchy_{1800bonus} \tag{\textit{Preemptive bundle selection}} \\
	& \text{where}
	& & V_{i}, bonusV_{900}, bonusV_{1800} \in \mathbb{N}, \quad \forall i \in Items \\
	&&& ass_{i}, b_{900}, b_{1800} \in \{0,1\} \\
	&&& m_p \in \{0,1\}, \quad \forall p \in Hierarchy
\end{align*}\label{eq:selector-lp}

\section{Results}
Now, with the project incorporating all the characteristics of the German Auction I was able to simulate the SMRA and HPB auctions. To research the sensitivity of efficiency and revenue towards the change of the set-up parameters I ran simulations iterating over sequences of the parameters $ \beta_{900}, \beta_{1800} $ and $ s_{DT}, s_{VOD} $ for both Hierarchies $ H_{competition}, H_{vm-prediction} $. Because of the high number of possible parameter combinations I will focus on the most important results below. To answer the question \textit{"How well does HPB perform in comparison to SMRA in the context of the German Auction?"}, my analysis was mainly guided by the following questions:

\begin{itemize}
	\item How sensitive are \textit{efficiency} and \textit{revenue} to \textit{bonus valuations}?
	\item What is the impact of the \textit{HPB hierarchy} on both metrics?
	\item How does \textit{efficiency} and \textit{revenue} change in relation to the environment of \textit{bidder strengths}?
\end{itemize}

\subsection{Efficiency of the Formats}\label{subsection:eff-formats}
A \textit{"well performing"} auction results in a (near-)optimal allocation of the bidding items to the bidders, meaning reaching a high efficiency is desired. As described in \autoref{subsection:meth-evaluation}, efficiency is described as the ratio of the total welfare achieved in relation to the optimal welfare, which is calculated by running a sealed-bid model on the parameters. Therefore, the efficiency of the sealed-bid model is always equal to one and the other formats are judged on this basis.

\begin{figure}[h]
	\centering
	\includegraphics[scale=0.5]{eff_both_betas_moving.pdf}
	\caption{Sensitivity of efficiency against $ \beta_{900} = \beta_{1800} $ in $ H_{competition} $} \label{fig:eff-both-beta-mov}

	\vspace*{\floatsep}

	\includegraphics[scale=0.5]{eff_both_betas_moving_VMP.pdf}
	\caption{Sensitivity of efficiency against $ \beta_{900} = \beta_{1800} $ in $ H_{vm-prediction} $} \label{fig:eff-both-beta-mov-vmp}
\end{figure}

%\paragraph{The influence of bonus valuations and hierarchies.}
When running simulations iterating over the bonuses valuations, differences between both hierarchies became clear. \autoref{fig:eff-both-beta-mov} shows the development of efficiency in relation to the bonuses valuations in the $ H_{competition} $ hierarchy and \autoref{fig:eff-both-beta-mov-vmp} for $ H_{vm-prediction} $ respectively. Despite the fact that the efficiency levels of HPB showed to be more stable than SMRA, there were differences in the results between the two hierarchies.
In $ H_{competition} $ HPB showed to be superior to SMRA with $ HPB \succ SMRA $. Also, HPB showed to be much more stable in resulting in a high efficiency level, which was near-optimal. In comparison, the overall allocation in SMRA seems to be more susceptible to the bonuses valuations, but still resulting in a high efficiency.

From the data it seems that in HPB the valuation of the bonus inducing packages has little effect on the overall allocation and efficiency of the auction, making it a versatile tool to auction items with such characteristics. But the correct choice of the structure appears to be an important question. The findings indicate, that a competitive HPB hierarchy might help in reaching a better overall allocation in comparison SMRA. But this needs to be verified by further experiments (see \autoref{chapter:conclusion}).

%\begin{figure}[h]
%	\centering
%	\includegraphics[scale=0.5]{eff_s_both_mov.pdf}
%	\caption{Sensitivity of efficiency against bidder strength $ [s_{DT} = s_{VOD}] $} \label{fig:eff-s-both}
%
%	\vspace*{\floatsep}
%
%	\includegraphics[scale=0.5]{eff_s_singlemov.pdf}
%	\caption{Sensitivity of efficiency with one stronger bidder $ s_{TEF} = s_{DT} = 1 $} \label{fig:eff-s-single}
%\end{figure}
%
%\paragraph{The competition environment.}
%Following the findings from the previous section, I will focus the analysis of the competition environment on the $ H_{competition} $ as maximizing efficiency is a desired property of an auction.

\subsection{Revenue of the Formats}
While reaching an optimal allocation is especially relevant to the participating bidders of an auction, maximizing revenue - to an appropriate level - mostly concerns the auctioneer. As revenue has no upper bound (like efficiency), there is no \textit{perfect} revenue. To analyse the sensitivity of revenue I will at first have a look on the influence of bonus valuations and the hierarchies. Afterwards, I will establish an understanding of the competition environment of the auction formats, meaning the sensitivity towards the distribution of bidder strength.

\paragraph{The influence of bonus valuations and hierarchies.}
\begin{figure}[h]
	\centering
	\includegraphics[scale=0.5]{rev_both_beta_mov.pdf}
	\caption{Sensitivity of revenue against $ \beta_{900} = \beta_{1800} $ in $ H_{competition} $} \label{fig:rev-both-beta-mov}

	\vspace*{\floatsep}

	\includegraphics[scale=0.5]{rev_both_beta_mov_VMP.pdf}
	\caption{Sensitivity of revenue against $ \beta_{900} = \beta_{1800} $ in $ H_{vm-prediction} $} \label{fig:rev-both-beta-mov-VMP}
\end{figure}

The general tendency is that $ \beta_{900} \text{ and } \beta_{1800} $ have a positive impact on the development of revenues. With higher bonuses valuations, the overall revenue rises, as can be seen in \autoref{fig:rev-both-beta-mov} and \autoref{fig:hpb-hierarchy-vm-predict}. Interestingly, the effect of the different HPB hierarchies can be observed.
When using $ H_{competition}  $ in most cases $ \text{HPB} \succ \text{SMRA} $, where the HPB format produced slightly higher revenues in comparison to SMRA. This is contrary to the effect seen in \autoref{fig:hpb-hierarchy-vm-predict}, where $ \text{HPB} \prec \text{SMRA}$ and through beta-space HPB generated prominently lower revenues. Note that in $ H_{vm-prediction} $ two bonuses inducing pre-packaged bundles in the 900 MHz band exist, instead of only one in $ H_{competition}  $. This is an indicator, that HPB might help bidders to coordinate earlier in the auction if the respective hierarchies enable them to, but simultaneously  leading to lower revenue.  Whereas a more competitive HPB hierarchy tends to drive competition and thus revenue.

\paragraph{The competition environment.}
In this section, I will focus on the findings using the  $ H_{competition}  $ hierarchy as it produced the higher efficiency (see \autoref{subsection:eff-formats}) and thus higher social welfare, which I argue to be an optimization goal of an auctioneer.

\begin{figure}[h]
	\centering
	\includegraphics[scale=0.6]{rev_hpb_comp_environment.pdf}
	\caption{Competition environment of HPB with $ H_{competition} \text{ \& } [rev \sim s_{DT}, s_{VOD}] $} \label{fig:rev-hpb-comp-env}
\end{figure}

\autoref{fig:rev-hpb-comp-env} shows the competition environment of the HPB format in the simulation. Each tile shows the revenue generated according to the set-up of the bidder strengths. As can be seen from the figure, when all bidders have the same strength ($ s_{TEF}=s_{DT}=s_{VOD}=1 $) the highest revenues were generated due to the fact, that each bidder had to bid very close to its valuation. In an environment with one very strong bidder, revenues tend to yield much lower level as the strong bidder can much earlier outbid its competitors and thus decrease overall revenue.
As the revenues from both formats were very similar when using the competitive hierarchy (see \autoref{fig:rev-both-beta-mov}), the competition environment also looks very similar. To compare both environments, \autoref{fig:rev-diff-comp-env} depicts the difference between the revenues yielded in HPB and SMRA. The figure suggests, that there is no systematic relation in the superiority or inferiority of an auction format when dealing with different bidder strength environments.

\begin{figure}[b]
	\centering
	\includegraphics[scale=0.45]{rev_diff.pdf}
	\caption{Competition environment of HPB vs. SMRA $ [rev_{HPB} - rev_{VOD} \sim s_{DT}, s_{VOD}] $} \label{fig:rev-diff-comp-env}
\end{figure}

To compare both formats further, \autoref{fig:rev-s-both} and \autoref{fig:rev-s-single} show the development of revenue in relation to two different bidder strength. As both depict that revenue decreases with increasing bidder strengths, \autoref{fig:rev-s-both} shows that in less unequally distributed bidder environments $ \text{HPB} \succ \text{SMRA} $, where HPB can yield slightly higher revenues even when bidder strengths are high. On the other hand, in an environment where one bidder is much stronger than the other participating bidders, this not only results in much lower revenues, but also slightly lower revenues by the HPB format in comparison to SMRA, even though the difference is marginal.

\begin{figure}[h]
	\centering
	\includegraphics[scale=0.5]{rev_s_bothmov.pdf}
	\caption{Sensitivity of revenue against bidder strength $ [s_{DT} = s_{VOD}] $} \label{fig:rev-s-both}

	\vspace*{\floatsep}

	\includegraphics[scale=0.5]{rev_s_singlemov.pdf}
	\caption{Sensitivity of revenue with one stronger bidder $ [s_{TEF} = s_{DT} = 1] $} \label{fig:rev-s-single}
\end{figure}

\subsection{Summary of the Results}
The following table summarises the findings of the simulations, where $ \beta $ means $ \beta_{900} = \beta_{1800} $ and $ s $ means $ s_{DT} = s_{VOD} $.

\begin{table}[h]
	\centering
\begin{tabular}{cc|l|l|}
	\cline{3-4}
	\multicolumn{1}{l}{}                       & \multicolumn{1}{l|}{} & \multicolumn{1}{c|}{\textbf{$\beta$}} & \multicolumn{1}{c|}{\textbf{$s$}} \\ \hline
	\multicolumn{1}{|c|}{\multirow{2}{*}{\textbf{Efficiency}}} & $ H_{competition} $                    & $  HPB \succ SMRA $                         & $ HPB \equiv SMRA $ after $ s= 1.5
	$                      \\ \cline{2-4}
	\multicolumn{1}{|c|}{}                     & $ H_{vm-predict} $                 & $ HPB \approx SMRA$                         & $ HPB \prec SMRA $ when $ s > 1 $                      \\ \hline
	\multicolumn{1}{|c|}{\multirow{2}{*}{\textbf{Revenue}}} & $ H_{competition} $                    & $ HPB \succ SMRA $                         & $ HPB \succ SMRA $, rapidly decreasing                      \\ \cline{2-4}
	\multicolumn{1}{|c|}{}                     & $ H_{vm-predict} $                  & $ HPB \prec SMRA $                         & $ HPB \prec SMRA $                      \\ \hline
\end{tabular}
	\caption{Summary of the findings in the simulations}\label{tbl:sim-results-summary}
\end{table}

From the table it can be seen, that the simulations indicate that HPB might be helpful in enabling bidders to find more efficient overall allocations when choosing an appropriate bidding hierarchy. This improvement came with the reduction of overall revenue as bidder signalling improved. SMRA was superior when a less competitive HPB hierarchy was used, indicating that choosing a suitable hierarchy is key to the success of the auction.

% BACKUP
%\begin{figure}[h]
%	\centering
%	\includegraphics[scale=0.5]{rev_smra_comp_environment.pdf}
%	\caption{Competition environment of SMRA $ [rev \sim s_{DT}, s_{VOD}] $} \label{fig:rev-smra-comp-env}
%
%	\vspace*{\floatsep}
%
%	\includegraphics[scale=0.5]{rev_hpb_comp_environment.pdf}
%	\caption{Competition environment of HPB $ [rev \sim s_{DT}, s_{VOD}] $} \label{fig:rev-hpb-comp-env}
%\end{figure}

%\begin{figure}[h]
%	\centering
%	\includegraphics[scale=0.5]{rev_b900mov.pdf}
%	\caption{Sensitivity of revenue against $ \beta_{900} $ with $ \beta_{1800} = 1$} \label{fig:rev-b900-mov}
%
%	\vspace*{\floatsep}
%
%	\includegraphics[scale=0.5]{rev_b1800mov.pdf}
%	\caption{Sensitivity of revenue against $ \beta_{1800} $ with $ \beta_{900} = 1$} \label{fig:rev-b1800-mov}
%
%	\vspace*{\floatsep}
%
%	\includegraphics[scale=0.5]{rev_both_beta_mov.pdf}
%	\caption{Sensitivity of revenue against $ \beta_{1800} = \beta_{900} $} \label{fig:rev-both-beta-mov}
%\end{figure}

%\begin{figure}[h]
%	\centering
%	\includegraphics[scale=0.5]{rev_hpb_comp_environment.pdf}
%	\caption{Competition environment of HPB $ [rev \sim s_{DT}, s_{VOD}] $} \label{fig:rev-hpb-comp-env}
%
%	\vspace*{\floatsep}
%
%	\includegraphics[scale=0.5]{rev_diff.pdf}
%	\caption{Competition environment of HPB vs. SMRA $ [rev_{HPB} - rev_{VOD} \sim s_{DT}, s_{VOD}] $} \label{fig:rev-diff-comp-env}
%\end{figure}

%The impact of the betas are different, because with the caps in the 900 MHz band
%at $ \beta_{1800} = 3 $ are the bonuses that high that it is feasible to buy cheapest four items instead of package (?) and then get the bonus, at $ \beta_{1800} = 2.5 $ it doesnt pay off to do that