% This LaTeX was auto-generated from an M-file by MATLAB.
% To make changes, update the M-file and republish this document.

%%% \documentclass{article}
%%% \usepackage{graphicx}
%%% \usepackage{color}

%%% \sloppy
%%% \definecolor{lightgray}{gray}{0.5}
\setlength{\parindent}{0pt}

%%% \begin{document}

\subsection*{testGM}

\begin{par}
Example for algorithm testGM. Algorithm is usefull only for testing QWTB toolbox. It calculates maximal and minimal value of the record. GUF/MCM is calculated by wrapper.
\end{par} \vspace{1em}
\begin{par}
See also \lstinline{qwtb}
\end{par} \vspace{1em}

\subsubsection*{Contents}

\begin{itemize}
\setlength{\itemsep}{-1ex}
   \item Generate sample data
   \item Call algorithm
   \item Plot results
\end{itemize}

\subsubsection*{Generate sample data}

\begin{par}
Two quantities are prepared: \lstinline{x} and \lstinline{y}.
\end{par} \vspace{1em}
\begin{lstlisting}[style=mcode]
x = []; y = [];
x.v = [1:20];
y.v = [1:14 13:-1:8];
\end{lstlisting}
\begin{par}
All uncertainties are set to 1.
\end{par} \vspace{1em}
\begin{lstlisting}[style=mcode]
x.u = x.v.*0 + 1;
y.u = y.v.*0 + 1;
\end{lstlisting}
\begin{par}
Set degrees of freedom.
\end{par} \vspace{1em}
\begin{lstlisting}[style=mcode]
x.d = x.v.*0 + 60;
y.d = y.v.*0 + 9;
\end{lstlisting}
\begin{par}
Quantities are put into data input structure \lstinline{DI}.
\end{par} \vspace{1em}
\begin{lstlisting}[style=mcode]
DI = [];
DI.x = x;
DI.y = y;
\end{lstlisting}
\begin{par}
Create calculation settings \lstinline{CS} and set uncertainty calculation method to Monte Carlo method. Allow randomization of uncertainties by the QWTB toolbox.
\end{par} \vspace{1em}
\begin{lstlisting}[style=mcode]
CSMCM = [];
CSMCM.unc = 'mcm';
CSMCM.mcm.randomize = 1;
\end{lstlisting}
\begin{par}
Create calculation settings and set uncertainty calculation method to GUM uncertainty framework.
\end{par} \vspace{1em}
\begin{lstlisting}[style=mcode]
CSGUF = [];
CSGUF.unc = 'guf';
\end{lstlisting}

\subsubsection*{Call algorithm}

\begin{par}
Use QWTB to apply algorithm \lstinline{testGM} to data \lstinline{DI} with calculation settings \lstinline{CSGUF}.
\end{par} \vspace{1em}
\begin{lstlisting}[style=mcode]
DOGUF = qwtb('testGM', DI, CSGUF);
\end{lstlisting}

        \begin{lstlisting}[style=output]
QWTB: default correlation matrix generated for quantity `x`
QWTB: default correlation matrix generated for quantity `y`
QWTB: uncertainty calculation by means of wrapper or algorithm
\end{lstlisting} \color{black}
    \begin{par}
Use QWTB to apply algorithm \lstinline{testGM} to data \lstinline{DI} with calculation settings \lstinline{CSMCM}.
\end{par} \vspace{1em}
\begin{lstlisting}[style=mcode]
DOMCM = qwtb('testGM', DI, CSMCM);
\end{lstlisting}

        \begin{lstlisting}[style=output]
QWTB: default correlation matrix generated for quantity `x`
QWTB: quantity x was randomized by QWTB
QWTB: default correlation matrix generated for quantity `y`
QWTB: quantity y was randomized by QWTB
QWTB: uncertainty calculation by means of wrapper or algorithm
\end{lstlisting} \color{black}

\subsubsection*{Plot results}

\begin{par}
Plot input data and calculated maximal and minimal values as a red and green lines with uncertainties represented by dashed lines.
\end{par} \vspace{1em}
\begin{lstlisting}[style=mcode]
figure
hold on
errorbar(DI.x.v, DI.y.v, DI.y.u, 'xb')
plot([DI.x.v(1) DI.x.v(end)], [DOGUF.max.v DOGUF.max.v], '-r', 'linewidth', 3)
plot([DI.x.v(1) DI.x.v(end)], [DOGUF.max.v - DOGUF.max.u DOGUF.max.v - DOGUF.max.u], '--r', 'linewidth', 3)
plot([DI.x.v(1) DI.x.v(end)], [DOGUF.min.v DOGUF.min.v], '-g', 'linewidth', 3)
plot([DI.x.v(1) DI.x.v(end)], [DOGUF.min.v - DOGUF.min.u DOGUF.min.v - DOGUF.min.u], '--g', 'linewidth', 3)
plot([DI.x.v(1) DI.x.v(end)], [DOGUF.max.v + DOGUF.max.u DOGUF.max.v + DOGUF.max.u], '--r', 'linewidth', 3)
plot([DI.x.v(1) DI.x.v(end)], [DOGUF.min.v + DOGUF.min.u DOGUF.min.v + DOGUF.min.u], '--g', 'linewidth', 3)
legend('original data (DI.x.v, DI.y.v)', 'line at maximum value (DO.max.v)', 'uncertainty',  'line at minimum value (DO.min.v)', 'uncertainty', 'location', 'southoutside')
xlabel('quantity x')
ylabel('quantity y')
title('input data and results of testGM algorithm, GUF method')
hold off
\end{lstlisting}

\begin{center}
\includegraphics[width=0.7\textwidth]{algs_examples_published/testGM_alg_example_01.pdf}
\end{center}
\begin{par}
Plot histogram of calculated maximal value, i.e. probability density function simulated by Monte Carlo method and overlay by result of GUF method (approximately scaled to MCM result).
\end{par} \vspace{1em}
\begin{lstlisting}[style=mcode]
figure
hold on
hist(DOMCM.max.r, 50)
a = axis;
x = [a(1):0.1:a(2)];
pdf = normpdf(x, DOGUF.max.v, DOGUF.max.u);
plot(x, a(4)/max(pdf).*pdf, '-r', 'linewidth', 4);
title('results of maximum value (DO.max.r)')
legend('Monte Carlo results', 'GUF result (approximately scaled to MCM results', 'location', 'southoutside')
hold off
\end{lstlisting}

\begin{center}
\includegraphics[width=0.7\textwidth]{algs_examples_published/testGM_alg_example_02.pdf}
\end{center}

%%% \end{document}


\subsection{VGA driver}

VGA driver is the most complex peripheral of MARK II. It is display driver with
VGA output, working in text mode. Its parameters are:

\begin{itemize}
    \item Pixel clock: 25MHz
    \item Resolution: 640x480 @ 60Hz
    \item Text resolution: 80x30 chars
    \item Char resolution: 16x8 pixels
    \item Colors: 16 collors
    \item Charset: 128 ASCII chars with some pseudo graphics
\end{itemize}

\subsubsection{Function}

Although VGA driver is complex peripheral, it's controlling is really simple.
By the programmer, VGA driver is seen as simple memory. You can read from this
memory and you can also write to this memory. But this memory is only 15 bits
wide.

VGA driver is able to display only characters. It has it own char set that is
mostly compatible with ASCII codes. Char set is shown on figure
\ref{fig:MARK_II_charset}.

Except standard ASCII characters there are also some chars that can be used to
print pseudo graphics.

VGA driver also support colors. You can specify color for foreground (character
itself) and for background. There is sixteen kinds of colors. And are listed,
together with their codes in table \ref{tab:vga_colors_codes}.

\begin{figure}[h]
    \centering
    \includegraphics[width=.85\textwidth]{img/MARKII_charset.png}
    \caption{VGA driver character set}
    \label{fig:MARK_II_charset}
\end{figure}

\begin{table}[h]
    \centering
    \begin{tabular}{|l|l|}
        \hline
        \textbf{Color} & \textbf{Code}  \\ \hline
        $0000_{2}$     & black          \\ \hline
        $0001_{2}$     & light gray     \\ \hline
        $0010_{2}$     & red            \\ \hline
        $0011_{2}$     & light red      \\ \hline
        $0100_{2}$     & green          \\ \hline
        $0101_{2}$     & light green    \\ \hline
        $0110_{2}$     & brown          \\ \hline
        $0111_{2}$     & yellow         \\ \hline
        $1000_{2}$     & blue           \\ \hline
        $1001_{2}$     & light blue     \\ \hline
        $1010_{2}$     & magenta        \\ \hline
        $1011_{2}$     & light magenta  \\ \hline
        $1100_{2}$     & cyan           \\ \hline
        $1101_{2}$     & light cyan     \\ \hline
        $1110_{2}$     & gray           \\ \hline
        $1111_{2}$     & white          \\ \hline
    \end{tabular}
    \caption{VGA driver supported colors}
    \label{tab:vga_colors_codes}
\end{table}

Writing on VGA display can be done by writing char code to the specified memory
location. Coordinates where character appear on the display is given by memory
address where character is wrote.

Display is organized as two dimensional array of characters. Its sizes are 80
columns and 30 lines of characters.

This organization is in video ram too. Address of character in memory is given
by following expression:

$$
    Address = r * 80_{16} + c
$$

Where $r$ mean row and $c$ mean column. For example, we want write character to
sixth row and eight column. Address to write is:

$$
    Address = r * 80_{16} + c = 6 * 80_{16} + 8 = 308_{16}
$$

Remember, top left corner have coordinates $[0, 0]$.

One memory location have 15 bits, in these 15 bits are coded color for background,
color for foreground, and character to display in following fashion:

\begin{itemize}
    \item \textbf{Bits 6 down to 0} - Character code from figure \ref{fig:MARK_II_charset}.
    \item \textbf{Bits 10 down to 7} - Foreground color code.
    \item \textbf{Bits 14 down to 11} - Background color code.
\end{itemize}

\subsubsection{Hacking}

You can simply add second VGA driver to drive two monitors at same time. This
can be done simply by adding second instance of vga component.

\begin{lstlisting}[language=VHDL, frame=single]
entity vga is
    generic(
        BASE_ADDRESS: unsigned(23 downto 0) := x"000000"
    );
    port(
        clk_bus: in std_logic;
        address: in unsigned(23 downto 0);
        data_mosi: in unsigned(31 downto 0);
        data_miso: out unsigned(31 downto 0);
        WR: in std_logic;
        RD: in std_logic;
        ack: out std_logic;
        clk_vga: in std_logic;
        h_sync: out std_logic;
        v_sync: out std_logic;
        red: out std_logic_vector(1 downto 0);
        green: out std_logic_vector(1 downto 0);
        blue: out std_logic_vector(1 downto 0)
    );
end entity vga;
\end{lstlisting}

Entity vga have standard bus interface for connecting to the system bus, plus
some extra special signals. These special signals are output to the VGA connector,
and clock input for pixel generator. Part of VGA driver is running at another
clock domain. This domain have to be clocked at $25MHz$. Input named clk\_bus
is standard system clock.

Signals h\_sync and v\_sync are horizontal and vertical synchronizations. Signals
red, green and blue are color signals and they should be connected to the DA converters.


The {\module{ctre}} module
implements compact trees (``ctrees'')
and supporting functions.
Compact trees are used to approximate the state of the ledger
by recording what assets are held at what addresses.
The {\module{ctregraft}} module
implements a way to graft information onto a compact
tree in order to form an approximation with more information.

{\bf{Note:}} Unit tests for the {\module{ctre}} and {\module{ctregraft}} modules are in {\file{ctreunittests.ml}}
in the {\dir{src/unittests}}
directory in the {\branch{testing}} branch.
These unit tests give a number of examples demonstrating how the functions described below should behave.
The {\branch{testing}} branch is, however, out of date with the code in the {\branch{dev}} and {\branch{master}} branches.

\section{Compact Ledger Trees}

We describe the main content of the module {\module{ctre}}.

{\bf{Note:}} The largest part of the Coq formalization deals with verifying compact trees
indeed represent ledgers as intended.
The Coq module {\coqmod{LedgerStates}} represents ledgers as functions
describing the current state of the ledger (see the Coq type \coqtype{statefun}).
The Coq module {\coqmod{MTrees}} uses a form of Merkle tree~\cite{Merkle1980} to approximate such a
{\coqtype{statefun}} function.
The Coq types {\coqtype{hlist}} and {\coqtype{nehlist}} defined in {\coqmod{MTrees}} correspond to
the types {\type{hlist}} and {\type{nehlist}} defined in {\module{ctre}} in the OCaml code.
The dependent Coq type {\coqtype{mtree}} $n$ is a Merkle tree with height $n$,
where the default case is $n=162$ (since Qeditas addresses are determined by 162 bits).
The Coq module {\coqmod{CTrees}} uses the compact tree (essentially a Patricia tree)
to represent the Merkle tree and hence approximate the ledger state.
The dependent Coq type {\coqtype{ctree}} $n$ is a compact tree with height $n$.
In the OCaml code the corresponding type is the simple type {\type{ctree}}.
Several functions are defined by recursion on $n$ in both the Coq and OCaml versions,
even though in the OCaml version the requirement that the compact tree has height $n$
is no longer enforced by the type system.
Note that {\coqmod{CTrees}} (mostly) corresponds to {\module{ctre}},
while {\coqmod{LedgerStates}} and {\coqmod{MTrees}} are only needed in the theory
and (for the most part) have no counterpart in the OCaml code.
For more information, see~\cite{White2015b}.

\subsection{Coin-age}

We first consider some variables which affect the likelihood of
coins to stake.\footnote{Since this has nothing to do with compact trees, it should be moved to a more appropriate module.}
The current settings have been chosen after
doing some simulations to determine a reasonable mixture
between staking of coins in the initial distribution
vs. staking of new coins issued through block rewards.
(Initial simulations revealed that block rewards could
easily dominate staking in the first few weeks unless their
influence was dampened.)

Typically, unlocked currency assets age quadratically as $(1+\lfloor\frac{a}{512}\rfloor)^2$ where $a$ is the number of blocks
since the asset became {\defin{mature}}. This continues until a maximum age is reached.
Users may commit currency assets to stake by locking them.
Locked non-reward assets mature more quickly and, once mature, have their maximum age
until it is close to the block height at which they will be unlocked, at which point
they will be ineligible for staking.
Rewards are necessarily locked. They age like unlocked currency assets until it is close to
the block height at which they will be unlocked, at which point they will be ineligible for staking.

\begin{itemize}
\item {\var{maximum\_age}} is the number of blocks after which unlocked coins
stop aging. This is currently set to $2^{14}$. With a 10 minute average block time,
this means unlocked coins reach their maximum age after roughly $4$ months.
(Coins in the initial distribution are exceptional: they have birthday $0$ and start with their maximum age.)
\item {\var{maximum\_age\_sqr}} is $(1+\lfloor \frac{a}{512}\rfloor)^2$ where $a$ is {\var{maximum\_age}}.
This is the maximum factor that can be used to determine an asset's coin-age.
Given current settings this is $33^2$, i.e., $1089$.
\item {\var{reward\_maturation}} indicates how old a reward must be before it can begin staking. This is currently set to $512$.
\item {\var{unlocked\_maturation}} indicates how many blocks must pass before
an unlocked asset can be used for staking. It is currently set to $512$.
\item {\var{locked\_maturation}} indicates how many blocks must pass before
a new locked currency asset can be used for staking.
It is currently set to $8$. This implies that $8$ blocks after creating a locked
currency asset, the currency asset can be used for staking with its maximum age,
until it is close to being unlocked.\footnote{The intention here is to encourage
stakers to commit to ``locking'' some of their coins only for use in staking.}
\item {\var{close\_to\_unlocked}} indicates the point at which locked assets can
no longer be used for staking. It is currently set to $32$, meaning that
the locked asset cannot be used for staking if it is $32$ blocks from being spendable
(or even after it is spendable).
\end{itemize}

Rewards must be locked until a certain block height before they can be spent.
In order to prevent rewards from dominating the early staking process,\footnote{If rewards could be unlocked quickly, then they could be
spent to create a locked non-reward asset. This locked non-reward asset would
very quickly mature and begin staking with its maximum age.}
this lock time is very long at first (16384 blocks, roughly 4 months), but reduces to
128 blocks (roughly 1 day) over the course of the first 114688 blocks (roughly 2 years).
The function {\var{reward\_locktime}} takes a given block height and
returns the minimum number of blocks a reward must be locked.
For the first 16384 blocks, the reward locktime is $16384$ (the same as {\var{maximum\_age}}).
Every 16384 blocks, the reward locktime is halved
until it reaches 128, where it remains indefinitely.

The function {\func{coinage}} computes the {\defin{coin-age}} of a
currency asset given the current block height.
As described above the ``age'' ranges from $0$ to $1089$,
with a quadratic increase each $512$ blocks.
(Specifically, the ``age'' progresses to be $n^2$
where $n$ is incremented from $1$ to $33$ each $512$ blocks
and then remains at $33$.)
Assume $v$ is the number of cants in the currency asset.
If the birthday of the asset is $0$, then it is part of the initial distribution
and its coin-age is $1089 v$.
Other than coins in the initial distribution,
there are three cases: unlocked currency assets, locked rewards and locked non-rewards.
Unlocked currency asset and locked rewards mature after $512$ blocks and then age quadratically
as described above. In the case of locked rewards, the coin-age drops to $0$
after block height $l-32$, where $l$ is the lock given for the reward.
Locked non-rewards mature after $8$ blocks and then have coin-age $1089 v$
until the coin-age drops to $0$ after block $l-32$, where $l$ is the lock given.

\subsection{Approximating Asset Lists by Hlists}

An asset list can be approximated by an {\defin{hlist}} $\cH$, a value of type {\type{hlist}}.
The constructors for {\type{hlist}} are as follows:
\begin{itemize}
\item ${\constr{HHash}}(h)$ approximates a nonempty asset list with hash root $h$.\footnote{The hash root of an asset list does not seem to be explicitly defined in the code. However, it could be defined using {\func{ohashlist}} and {\func{hashasset}} and this seems to be the intended hash root.}
\item ${\constr{HNil}}$ approximates the empty asset list.
\item ${\constr{HCons}}(a,\cH)$ where $a$ is an asset and $\cH$ is an hlist.
\item ${\constr{HConsH}}(h,\cH)$ where $h$ is an asset id (a hash value) and $\cH$ is an hlist.
\end{itemize}
The idea is that an hlist explicitly lists a prefix of the assets (or references to the assets
by their id) ending with a hash root
summarizing the rest of the asset list. It is also possible for the hlist to list all the assets.
Values of this type can be serialized and deserialized using
{\serfunc{seo\_hlist}}
and {\serfunc{sei\_hlist}}.

The type {\type{nehlist}} represents nonempty hlists and has three constructors:
\begin{itemize}
\item ${\constr{NehHash}}(h)$ corresponds to the hlist ${\constr{HHash}}(h)$.
\item ${\constr{NehCons}}(a,\cH)$ corresponds to the hlist ${\constr{HCons}}(a,\cH)$.
\item ${\constr{NehConsH}}(h,\cH)$ corresponds to the hlist ${\constr{HConsH}}(h,\cH)$.
\end{itemize}
Values of this type can be serialized and deserialized using
{\serfunc{seo\_nehlist}}
and
{\serfunc{sei\_nehlist}}.

We briefly relevant functions.
\begin{itemize}
\item {\func{nehlist\_hlist}} converts a nonempty hlist to an hlist.
\item {\func{hlist\_hashroot}} computes an optional hash root for an hlist, with {\val{None}} playing
the role of the hash root for {\constr{HNil}}.
\item {\func{nehlist\_hashroot}} computes a hash root for an nehlist,
the same as the one given by {\func{hlist\_hashroot}}.
\item {\func{in\_hlist}} and {\func{in\_nehlist}} check if an asset is explicitly listed in
the hlist or nehlist. Note that this will return {\val{false}} if the asset is not explicitly listed
but is an asset on the part of the list being summarized by ${\constr{HHash}}$ or ${\constr{NehHash}}$.
\item {\func{print\_hlist}} and {\func{print\_hlist\_to\_buffer}} print hlists and are included for debugging purposes.
\end{itemize}

\subsection{Compact Trees}

The intention of a compact tree is to provide a binary tree approximation of
a function from addresses (162-bit sequences) to hlists, where the hlists
approximate the assets held at the addresses.
In general, functions on compact trees will be defined by recursion and so we
usually need to consider compact trees at level $n$ (corresponding to functions
from $n$-bit sequences to hlists).
A $0$ bit corresponds to the left child while a $1$ bit corresponds to the right child.

The vast majority of the leaves will be empty, and so compact trees
only store the nonempty parts explicitly.
The empty compact tree (with no assets stored at leaves) can be thought of as
represented by {\val{None}}, and the type {\type{ctree option}}
is used when the empty compact tree should be considered.

Compact trees $\cC$ are values of type ${\type{ctree}}$, which is defined by the following constructors.
\begin{itemize}
\item ${\constr{CLeaf}}(\overline{b},\cH)$ is a compact tree with a single nonempty leaf
at the location determined by the bit sequence (list of booleans) $\overline{b}$
and containing the nonempty hlist $\cH$.
\item ${\constr{CHash}}(h)$ is a compact tree with a hash $h$. This approximates every compact tree with hash root $h$.
\item ${\constr{CLeft}}(\cC)$ is the compact tree with $\cC$ as its left child and the empty tree as its right child.
\item ${\constr{CRight}}(\cC)$ is the compact tree with the empty tree as its left child and $\cC$ as its right child.
\item ${\constr{CBin}}(\cC_0,\cC_1)$ is the compact tree with two nonempty children: $\cC_0$ on the left and $\cC_1$ on the right.
\end{itemize}
Values of type ${\type{ctree}}$ can be serialized and deserialized using
{\serfunc{seo\_ctree}}
and
{\serfunc{sei\_ctree}}.

The following functions are important:
\begin{itemize}
\item {\func{ctree\_hashroot}} computes a hash root for the compact tree.
Many different compact trees will give the same hash roots, however they will
always approximate the same ledger state.
For example, they can differ in where they include ${\constr{CHash}}$ nodes,
as well has the level of detail included in
hlists at the leaves.
\item {\func{octree\_hashroot}} takes an optional compact tree and returns an optional hash value.
It simply returns {\val{None}} for the empty compact tree {\val{None}}
and returns the result of {\func{ctree\_hashroot}} otherwise.
\item {\func{ctree\_lookup\_asset}} takes an asset id (a hash value), a ctree and a bit sequence.
It traverses to leaf in the ctree following the bit sequence.
It then tries to look up the asset with the asset id in the nonempty hlist at the leaf.
If the leaf is empty or the asset is not found, then {\val{None}} is returned. Otherwise, the asset is returned.
\item {\func{ctree\_addr}} given an address and a compact tree,
returns the leaf (as a compact tree) at that address.
This leaf could either be {\val{None}} indicating no assets are held at the address,
or it could be a nonempty hlist, approximating the assets held at the address.
It also returns the depth, which should always be 162, so it can be ignored.
\item {\func{octree\_lub}} takes the ``least upper bound'' of two optional compact trees.
These are assumed to be ``compatible'' in the sense that they must have the same hash root.
This means either both will be empty ({\val{None}})
or both will be compact trees.
The least upper bound of two empty compact trees is the empty compact tree.
For nonempty compact trees, the recursive structure is followed,
abreviations are expanded, and if one of the trees is a {\constr{CHash}}
node then the other tree is taken.
The idea is that if some information is in at least one of the trees,
then the information will be in the resulting tree.
\item {\func{print\_ctree}} and {\func{print\_ctree\_all}} print compact trees and are included for debugging purposes.
\end{itemize}

\subsection{Elements}

As noted above, the purpose of having ${\constr{CHash}}(h)$ nodes in compact trees
and having ${\constr{HHash}}(h)$ nodes in hlists
is to work with small approximations of larger structures.
We will need to save some of these small approximations as
key-value pairs in a database (see Chapter~\ref{chap:db}).
This, however, introduces a problem: many different ctrees will have hash root $h$
and can be approximated by the compact tree ${\constr{CHash}}(h)$.
If we wish to use $h$ as the key, there must be a unique compact tree (at least up to the level of detail included)
that corresponds
to $h$. A similar situation occurs when considering hlists.

To resolve these problems, we introduce a notion of {\em{elements}}
for hlists and compact trees.\footnote{The notion of an element was introduced and coded by Trent Russell in early 2016. This replaced earlier code which used ``frames'' and ``abbrev'' nodes in compact trees.}
A compact tree element will be defined so that there is at most one compact tree element with a given hash root.
We consider the case of hlists (and nehlists) first, as this is simpler.

First, empty hlists obviously do not need to be stored. It is clear that if the hashroot of an hlist is {\val{None}}, then the hlist list is {\constr{HNil}}.
Hence we only need to consider cons pairs.
We say an {\em{hcons element}} is a pair $(h,k)$ where $h$ is a hash value and $k$
is an optional hash value.
The idea is that the hlist (or nehlist) corresponds to a nonempty asset list where
the first asset has asset id $h$ and the rest of the asset list has hash root $k$ (or {\val{None}}
if there are no more assets on the list).
The weakest approximation of this asset list as an hlist
that retains the $h$ and $k$ is
${\constr{HConsH}}(h,{\constr{HHash}}(k))$ if $k$ is not ${\val{None}}$
and
${\constr{HConsH}}(h,{\constr{HNil}})$ if $k$ is not ${\val{None}}$
otherwise.
As an nehlist, the corresponding approximations are
${\constr{NehConsH}}(h,{\constr{HHash}}(k))$ if $k$ is not ${\val{None}}$
and
${\constr{NehConsH}}(h,{\constr{HNil}})$ if $k$ is not ${\val{None}}$.

The module {\module{DbHConsElt}} implements a database for storing hcons elements
(see Chapter~\ref{chap:db}).
At the moment, this uses the basic file storage implementation {\module{Dbbasic2}}.

The function {\func{save\_hlist\_elements}} takes an arbitrary hlist
and splits it into elements, saving the corresponding assets in the
{\module{DbAsset}} database
and the corresponding hcons elements in the database {\module{DbHConsElt}}.
This ensures that there is enough information to reconstruct the
hlist from the hash root and the information in the database.
The function {\func{save\_nehlist\_elements}} performs a similar
function for values of type {\type{nehlist}}.

The function {\func{get\_hcons\_element}} takes a hash value and
uses {\func{dbget}} to try to look up the hcons element from the database.
If it is not found in the database,
then the data is requested from network peers\footnote{This is not currently implemented. Some earlier code to do this is commented out.}
and the exception {\exc{GettingRemoteData}} is raised.
The idea is that the next time ${\constr{get\_hcons\_element}}$ is
called the hcons element
may have been put into the database after it was received from a peer.
The functions {\func{get\_hlist\_element}} and {\func{get\_nehlist\_element}}
call {\func{get\_hcons\_element}} and, if the hcons element is found,
returns the information packaged as a value of type {\type{hlist}} or {\type{nehlist}}.

Compact tree elements are defined to give full information for 9 levels, using
${\constr{CHash}}(h)$ at the ninth level (and using ${\constr{NehHash}}(h)$ for all leaves).
We can define this more formally as follows:
\begin{itemize}
\item A compact tree is {\em{elemental at level 0}} if it is of the form ${\constr{CHash}}(h)$.
\item A compact tree is {\em{elemental at level $i+1$}} if it is one of the following forms:
${\constr{CLeaf}}(\overline{b},{\constr{NehHash}}(h))$,
${\constr{CLeft}}(c_0)$ where $c_0$ is elemental at level $i$,
${\constr{CRight}}(c_1)$ where $c_1$ is elemental at level $i$
or
${\constr{CBin}}(c_0,c_1)$ where $c_0$ and $c_1$ is elemental at level $i$.
\item A compact tree is an {\em{element}} if it is elemental at level $9$.
\end{itemize}
The function ${\func{ctree\_element\_p}}$ checks if a compact tree is an element
and the auxiliary function ${\func{ctree\_element\_a}}$ checks if a compact
tree is elemental at level $i$.

The ${\func{ctree\_super\_element\_a}}$ checks if a compact tree has
at least as much explicit information as a compact tree that is elemental at level $i$.
Likewise, the ${\func{ctree\_super\_element\_p}}$ checks if a compact tree
has at least as much explicit information as a compact tree element.
Such compact trees can be used to extract an approximating element.
The function ${\func{super\_element\_to\_element}}$ computes such an approximation
using the function ${\func{super\_element\_to\_element\_a}}$
that computes an approximation that is elemental at a given level.

The module {\module{DbCTreeElt}} implements a database for storing compact tree elements
(see Chapter~\ref{chap:db}).
At the moment, this uses the basic file storage implementation {\module{Dbbasic2}}.

The function ${\func{save\_ctree\_elements}}$
takes a compact tree and factors it into elements which are saved into
the database, returning the compact tree ${\constr{CHash}}(h)$ where $h$ is the hash root
of the compact tree.
The function makes use of ${\func{save\_ctree\_elements\_a}}$
which constructs intermediate elemental compact trees
and uses ${\func{dbput}}$ to save the constructed elements into the database.

The function ${\constr{get\_ctree\_element}}$ takes a hash value and
uses ${\func{dbget}}$ to try to extract the corresponding compact tree element
from the database.
If it is not found, then it is requested from peers\footnote{This is not currently implemented. Some earlier code to do this is commented out.}
and the exception ${\exc{GettingRemoteData}}$ is raised.
The idea is that the next time ${\constr{get\_ctree\_element}}$ is
called the compact tree element
may have been put into the database after it was received from a peer.

\subsection{Transactions}

We now describe functions relating compact trees and transactions.
One of the main concepts is that of {\defin{support}}.
In short, we say a compact tree supports a transaction if for each
input there is a corresponding asset held at the given address
and that a number of conditions hold.
To be more precise, there are further dependencies.
For example, some of these conditions depend on the block height
(e.g., to ensure an old enough intention justifies a publication).\footnote{Lock heights are not checked here, but instead are checked with the signatures of transactions. The reason is that lock heights prevent an asset from being spent, but do not prevent assets from being moved. The distinction between being spent and being moved is not relevant for support.}
Also, we must check the correctness of publications
which may require looking up a theory or signature.
These dependencies
are explicit in the function {\func{ctree\_supports\_tx}}
which checks if a compact tree supports a transaction,
given a block height, theory tree ({\type{ttree}}) and signature tree ({\type{stree}}).
The conditions to be checked often make reference to the actual assets
being spent (which are referred to in the transaction by their assetids).
The function {\func{ctree\_lookup\_input\_assets}} elaborates
the inputs by looking up the assets.
The exception {\exc{NotSupported}} is raised if
some condition required for a transaction to be supported fails,
which can happen either because the assets being spent cannot be found
in the compact tree or because of failure of some condition.

Let $\cC$ be a compact tree.
We say an asset $a$ is {\defin{held at $\alpha$ in $\cC$}}
if there is a nonempty hlist $\cH$ at leaf $\alpha$ in $\cC$ and $a$
is explicitly listed in $\cH$ (see {\func{in\_nehlist}}).
Let $\iota$ be an {\type{addr\_assetid}} list (a list of transaction inputs)
and $\iota'$ be a list of pairs $(\alpha,a)$ of addresses and assets.
We say $\iota'$ is an {\emph{elaboration of $\iota$ relative to $\cC$}}
if for each $(\alpha,h) \in\iota$ there is a pair $(\alpha,a) \in\iota'$
where $a$ is held at $\alpha$ in $\cC$ and $a$ has assetid $h$.\footnote{Technically, in the implementations the lists $\iota$ and $\iota'$ will list assetids and assets in the same order.}
The function {\func{ctree\_lookup\_input\_assets}}
computes an elaboration $\iota'$ given $\iota$ and $\cC$,
raising {\exc{NotSupported}} if
there is no asset $a$ with assetid $h$ held at $\alpha$ in $\cC$
for some $(\alpha,h)$ in $\iota$.

The function {\func{ctree\_supports\_tx}} simply
calls {\func{ctree\_lookup\_input\_assets}} to obtain $\iota'$
and then calls {\func{ctree\_supports\_tx\_2}} with this extra information.
The function {\func{ctree\_supports\_tx\_2}} checks the conditions for
$\cC$ to support $\tau=(\iota,o)$ with elaborated input $\iota'$
relative to a block height $b$, a theory tree and a signature tree.\footnote{The function {\func{ctree\_supports\_tx\_2}} is also given a list of assets, but this is simply the second components of the pairs in $\iota'$.}
Support requires several conditions.
We describe each condition as a single sentence followed by
a longer description.\footnote{Similar conditions can also be found in the Coq formalization as {\coqfunc{ctree\_supports\_tx}} in {\file{CTrees.v}}.}
\begin{enumerate}
\item {\sc{All output addresses are supported.}}
That is, for each $(\alpha,u)\in o$ there is no ${\constr{CHash}}$ node along the
path to the leaf in $\cC$ with position $\alpha$.
This is needed so that the new assets can be added to the leaves.
For each $(\alpha,u)\in o$ there are two possibilities: either there are no assets currently
held at $\alpha$
or there are assets represented by the nonempty hlist $\cH$ at $\alpha$.
If there are no assets, the new nonempty hlist will only contain the new assets.
If there are currently assets represented by $\cH$, we only need to
push the new assets onto the explicit prefix of $\cH$.
Note that this is possible even if $\cH$ is only the hash root of the hlist.
\item {\sc{If an object or a proposition is used in a signature specification, then it must be free to use.}}
For the definition of ``used'' see
{\func{output\_signaspec\_uses\_objs}}
and
{\func{output\_signaspec\_uses\_props}}.
Recall that each signature specification is intended for a specific theory (possibly the empty theory).
Each parameter in a signature specification will correspond to two term
addresses: one for the pure object and one for the object in the theory.
Both of these addresses must be owned as objects and the ownership assets
must both give $0$ as the price of a right to use the object.
Likewise each axiom in a signature specification will correspond to two term
addresses: one for the pure proposition and one for the proposition in the theory.
Both of these addresses must be owned as propositions and the ownership assets
also must give $0$ as the price of a right to use the proposition.
The reason for this condition is to prevent someone from paying once
for the right to use an object or a proposition
and then publishing it in a signature which is then free for anyone to use.
Of course, someone can purchase the ownership assets from the owners
and then make the corresponding objects and propositions free to use.
\item {\sc{If rights are spent in the input, then they must be mentioned in the output.}}
If a preasset ${\constr{RightsObj}}(\beta,n)$ is being spent, then
$\beta$ must be ``mentioned'' (see {\func{obj\_rights\_mentioned}})
in the sense that there is either an output of the form
${\constr{RightsObj}}(\beta,m)$
or the object is used (as a parameter) in a document being published.
If a preasset ${\constr{RightsProp}}(\beta,n)$ is being spent, then
$\beta$ must be ``mentioned'' (see {\func{prop\_rights\_mentioned}})
in the sense that there is either an output of the form
${\constr{RightsProp}}(\beta,m)$
or the proposition is used (as an axiom) in a document being published.
\item {\sc{Rights must be balanced.}}
Let $\alpha$ be a term address corresponding to an object [a proposition] used in a document.
Ensure that all the assets held at $\alpha$ are explict
(using {\func{hlist\_full\_approx}})
and look up the ownership asset for $\alpha$ as an object [a proposition].
(Such ownership assets are held at $\alpha$.)
If $\alpha$ has no owner, then the transaction is not supported.
Let $r_1$ be the number of rights to $\alpha$ used as an object [a proposition].
That is, $r_1$ is the number of documents which import $\alpha$ as a parameter [an axiom].
This is computed using {\func{count\_rights\_used}}.
Let $r_2$ be the number of rights to $\alpha$ as an object [a proposition]
which are created in the output of the transaction.
This is computed using {\func{rights\_out\_obj}} [{\func{rights\_out\_prop}}]
and can be described as a simple sum:
$$
\sum_{{\constr{RightsObj}(\alpha,m)} {\mbox{ in }} o} m
\,\,
\left[
\sum_{{\constr{RightsProp}(\alpha,m)} {\mbox{ in }} o} m
\right]
$$
Let $r_3$ be the number of rights to $\alpha$ as an object [a propostion]
which are spent in the input of the transaction.
This is computed using {\func{count\_obj\_rights}} [{\func{count\_prop\_rights}}]
and can be described as a simple sum:
$$
\sum_{{\constr{RightsObj}(\alpha,m)} {\mbox{ in }} \iota'} m
\,\,
\left[
\sum_{{\constr{RightsProp}(\alpha,m)} {\mbox{ in }} \iota'} m
\right].
$$
The function {\func{ctree\_rights\_balanced}} is called with this information,
returning a boolean indicating if the rights are {\defin{balanced}}.
Rights being balanced depends on the cost to purchase rights which is found in the
ownership asset.
If the cost to purchase rights is {\val{None}} (meaning rights cannot be purchased),
then rights are balanced if $r_1 + r_2 = r_3$.\footnote{In practice, $r_1 > 0$ since the object or proposition was used. Hence the only way this equation can hold is if $r_3>0$. This is possible if rights to use
the object or proposition were purchased earlier at a time when rights were being sold.}
If the cost to purchase rights is $0$, then the rights are balanced.\footnote{Note that this means anyone can create rights to use the object or proposition later.}
Assume the ownership asset is of the form ${\constr{OwnsObj}}(\beta,p)$
[${\constr{OwnsProp}}(\beta,p)$] where $p>0$.
That is, the cost to purchase rights is $p>0$. In this case it is possible rights are being purchased
by paying cants to $\beta$.
Let $r_4$ be the sum of cants sent to $\beta$ in the output $o$.
The rights are balanced if $r_1+r_2 = r_3+r_4$.\footnote{There is a corner case here. If the same pay address $\beta$ was used in more than one ownership asset at term addresses $\alpha_1$ and $\alpha_2$, then someone could simultaneously create rights to use $\alpha_1$ and $\alpha_2$ by paying cants to $\beta$ once in a single transaction. This can be avoided by always giving a unique pay address for distinct ownership assets. This uniqueness is not enforced.}
The transaction is not supported if the rights are not balanced.
\item {\sc{Publications are correct, new and were declared in advance by a sufficiently old intention (marker).}}
Recall that there are three kinds of publications:
theory specifications, signature specifications and documents.
The corresponding preassets are
${\constr{TheoryPublication}}(\gamma,\nu,\tau)$,
${\constr{SignaPublication}}(\gamma,\nu,h,\Sigma)$
and
${\constr{DocPublication}}(\gamma,\nu,h,\Delta)$.
Recall that $\nu$ is a nonce.
There will be two publication addresses associated with the publication.
One is determined simply by the contents ($\tau$, $(h,\Sigma)$ or $(h,\Delta)$)
and must be the $\alpha$ (in $o$) where the publication asset will be held.
(This is checked in {\func{tx\_outputs\_valid\_addr\_cats}}.)
The $\alpha$ must be empty or the transaction is not supported.
(If $\alpha$ holds an asset, it implies the publication has already been published.)
All the information (including $\gamma$ and $\nu$)
can be hashed to obtain a publication address $\beta$,
called the {\defin{marker address}}.
The author of the document was able to compute this publication address $\beta$
before making the corresponding publication (included in the preasset) public
without revealing information about the publication's contents.
The author must publish a {\constr{Marker}} asset
to the address $\beta$ a certain number of blocks before attempting to publish
the transaction with the publication.\footnote{The purpose of this is to prevent plagiarism, as described when ${\constr{Marker}}$ was introduced in Chapter~\ref{chap:assetstx}.}
The number of blocks is {\var{intention\_minage}} which is currently set to $144$ (a day, assuming 10 minute block times).
This {\constr{Marker}} must be spent by the transaction (assuring it exists)
and must be old enough, otherwise the transaction is not supported.
Finally, the publication must be correct.
Correctness is judged by {\func{check\_theoryspec}}, {\func{check\_signaspec}} or {\func{check\_doc}}.
In the cases of {\func{check\_signaspec}} or {\func{check\_doc}},
the appropriate theory (if nonempty) must be looked up in the current theory tree,
and the current signature tree must be given so that signatures imported by
the signature specification or document can be retrieved.
Also, recall that {\func{check\_signaspec}} and {\func{check\_doc}}
depend on arguments
{\var{gvtp}} and
{\var{gvkn}}
where
{\var{gvtp}} determines if an term is known to have a type in a theory
and
{\var{gvkn}} determines if a proposition is known to be provable in a theory.
Now that we have access to the compact tree $\cC$,
we are in a position to supply these arguments.
In particular, {\var{gvtp}} computes the term address $\alpha'$ for the object in the given theory
(which depends on the theory identifier,
the hash root of the term in question and the hash of the type in question)
and uses {\func{hlist\_lookup\_obj\_owner}} to determine if $\alpha'$
is known to have an owner as an object.
Similarly, {\var{gvkn}} computes the term address $\alpha'$ for the proposition in the given theory
(which depends on the theory identifier and
the hash root of the term in question)
and uses {\func{hlist\_lookup\_prop\_owner}} to determine if $\alpha'$
is known to have an owner as a proposition.
Since term addresses can only be given owners as objects [propositions]
when they are published in a document, the type correctness [provability]
is guaranteed by ownership.
\item {\sc{If a marker asset is being spent in the input, then there must be a corresponding publication in the output.}}
Suppose $(\beta,a)\in\iota'$
where the preasset of $a$ is {\constr{Marker}}.
There must be some
${\constr{TheoryPublication}}(\gamma,\nu,\tau)$,
${\constr{SignaPublication}}(\gamma,\nu,h,\Sigma)$
or
${\constr{DocPublication}}(\gamma,\nu,h,\Delta)$
in $o$
for which $\beta$ is the marker address.
\item {\sc{If an ownership asset is spent in the input, then it must be included as an output.}}
That is, once a term address has an owner, it will always have an owner.
This is necessary since ownership is used to determine which objects have certain types and which propositions
have been proven (in both cases relative to a theory).
The ownership asset may be spent and recreated for a number of reasons.
It can be done to change the pay address or the purchase price of rights.
Such a change could correspond to the ownership being sold from one party to another,
where the payment for the sale is part of the same (atomic) transaction.
Another reason would be to collect a bounty.
Ownership of propositions and negated propositions are spent (and recreated) as part of
a transaction which collect bounties.
(Collecting bounties is the only reason for ownership of negated propositions.)
Note that the signature to spend an ownership asset is the pay address in the obligation,
not the pay address for the purchase of rights.
The pay address in the obligation indicates the ``owner'' of the term address.\footnote{Ownership assets always have nontrivial obligations.}
\item {\sc{New ownership preassets in the transaction outputs must have an explicit (non-reward) obligation and must be created or transferred. If an ownership output is being created, it must be supported by the transaction outputs.}}
Suppose $(\alpha,(\omega,u))\in o$ where $u$ is either ${\constr{OwnsObj}}(\beta,p)$,
${\constr{OwnsProp}}(\beta,p)$ or ${\constr{OwnsNegProp}}$.
The obligation $\omega$ must not be $\val{None}$ and must indicate it is not a reward.
There must either be an ownership asset at $\alpha$ listed in $\iota'$ (so ownership is being transferred)
or no ownership asset is held at $\alpha$ in $\cC$ (so the ownership is being created).
If the ownership asset is being created, then $o$ must support $u$ at $\alpha$ (see Section~\ref{sec:outputcreates}).
\item {\sc{New objects and propositions must be given ownership by the transaction publishing the document.}}
There are three different cases.
(The notions of ``creates'' used here were defined in see Section~\ref{sec:outputcreates}.)
If $o$ creates an object at term address $\alpha$
and there is no ${\constr{OwnsObj}}$ asset held at $\alpha$ in $\cC$,
then there must be some
$(\alpha,(\omega,{\constr{OwnsObj}}(\beta,p)))\in o$.
If $o$ creates a proposition at term address $\alpha$
and there is no ${\constr{OwnsProp}}$ asset held at $\alpha$ in $\cC$,
then there must be some
$(\alpha,(\omega,{\constr{OwnsProp}}(\beta,p)))\in o$.
(There is no requirement that created negated propositions must be given ownership.)
\item {\sc{Bounties can only be collected by the owners of propositions or negated propositions.}}
Suppose $(\alpha,a)\in\iota'$
and the preasset of $a$ is ${\constr{Bounty}}(v)$.
There must also be some $(\alpha,a')\in\iota'$ (with the same $\alpha$)
where the preasset of $a'$ is either ${\constr{OwnsProp}}(\beta,p)$
(for some $\beta$ and $p$)
or ${\constr{OwnsNegProp}}$.
The fact that ownership asset is being spent means that the ``owner'' (as given in the obligation of $a'$)
must have signed the transaction spending the bounty.
Note that by a condition above, the ownership asset must be recreated in the output $o$.
The idea is that an owner of the proposition or negated proposition collects
the bounty by a trivial transfer of the ownership asset.
\end{enumerate}
An attentive reader will note that none of these conditions require the currency units consumed
in the input to be at least as great as the currency units created in the outputs (plus those
required to be burned to publish theories and signatures).
This is not required for support,
and will not be true for coinstake transactions (which receive a reward).

We summarize the descriptions of these three main functions discussed above as follows:
\begin{itemize}
\item {\func{ctree\_lookup\_input\_assets}} takes a compact tree and an
{\type{addr\_assetid}} list (a list of transaction inputs)
and uses {\func{ctree\_lookup\_asset}} to look up the assets corresponding to
the assetids, returning the resulting list of pairs of addresses and assets.
If one of the assetids cannot be found in the compact tree,
the exception {\exc{NotSupported}} is raised.
\item {\func{ctree\_supports\_tx}} checks if a compact tree supports a transaction.
The function also requires an optional {\type{ttree}} (with all the currently known theories)
an optional {\type{stree}} (with all the currently known signatures)
and the current block height.
If the transaction is not supported, the exception {\exc{NotSupported}} is raised.
If the transaction is supported,
the difference between the currency units output or burned and the currency units input
is returned. If this value is negative, then it corresponds to a fee.
If the value is positive, then it corresponds to a reward.
\item {\func{ctree\_supports\_tx\_2}} is the same as {\func{ctree\_supports\_tx}}
except it also receives two extra inputs:
a list of the input addresses associated with their assets
and a list of those assets.
\end{itemize}

If a compact tree supports a transaction or list of transactions,
typically some small approximation of the compact tree also provides the support.
We next describe functions to construct such small approximations.
\begin{itemize}
\item {\func{full\_needed}} takes a {\type{addr\_preasset}} list (a list of transaction outputs)
and returns a list of bit sequences (addresses represented as boolean lists)
indicating which leaves need to have their full list of assets explicit
in order to check if the transaction with these outputs
is supported.
\item {\func{get\_tx\_supporting\_octree}} takes a transaction and (optional) compact tree
and returns an approximation of the (optional) compact tree sufficient to support the transaction.
\item {\func{get\_txl\_supporting\_octree}} takes a list of transactions and (optional) compact tree
and returns an approximation of the (optional) compact tree sufficient to support the transactions.
\end{itemize}

There are two functions which transform (optional) compact trees using transactions.
\begin{itemize}
\item {\func{tx\_octree\_trans}} takes a block height, transaction and compact tree
and transforms the ctree by deleting assets consumed in the inputs and
create the new assets in the output. (The block height is needed to give
birthdays to the new assets.)
\item {\func{txl\_octree\_trans}} transforms a compact tree according to a
list of transactions, sequentially.
\end{itemize}

There are also four auxiliary functions exposed in the interface.
\begin{itemize}
\item {\func{strip\_bitseq\_true}} takes a list of pairs, the first component of which are bit sequences, and returns the list
filtered to the ones with a {\val{true}} as the head of the list with this {\val{true}} removed.
For example, the input
$$[((\val{false}::\overline{b_0}),x);((\val{true}::\overline{b_1}),y)]$$
would give the output
$$[(\overline{b_1},y)].$$
\item {\func{strip\_bitseq\_false}} takes a list of pairs, the first component of which are bit sequences, and returns the list
filtered to the ones with a {\val{false}} as the head of the list with this {\val{false}} removed.
For example, the input
$$[((\val{false}::\overline{b_0}),x);((\val{true}::\overline{b_1}),y)]$$
would give the output
$$[(\overline{b_0},x)].$$
\item {\func{strip\_bitseq\_true0}} takes a list of bit sequences, and returns the list
filtered to the ones with a {\val{true}} as the head of the list with this {\val{true}} removed.
\item {\func{strip\_bitseq\_false0}} takes a list of bit sequences, and returns the list
filtered to the ones with a {\val{false}} as the head of the list with this {\val{false}} removed.
\end{itemize}
These are exposed because they are used in the {\module{ctregraft}} module.\footnote{It might make more sense to combine the {\module{ctre}} and {\module{ctregraft}} modules so that these functions need not be exposed.}

\section{Grafting Trees}

The module {\module{ctregraft}}
has code for grafting subtrees onto a compact tree in order
to form an approximation with more information.
The purpose of this is so that a block header can
have a compact tree small enough to check the details of the asset which
staked the block,
and the block delta can have a graft extending this compact tree
to a larger compact tree with enough information to support
all the transactions in the block.

{\bf{Note:}}
In the Coq formalization the Coq module {\coqmod{CTreeGrafting}}
corresponds to {\module{ctregrafting}}.
For more information, see~\cite{White2015b}.

The type {\type{cgraft}} is a list of hash values associated with compact trees.
The idea is simply to associate some hash roots with compact trees with these hash roots.
As usual, the serialization and deserialization functions
for this type are
{\serfunc{seo\_cgraft}}
and
{\serfunc{sei\_cgraft}}.

There are four functions exposed by {\module{ctregraft}}.
\begin{itemize}
\item {\func{cgraft\_valid}} checks if a graft is {\defin{valid}}, meaning simply that
each pair $(h,\cC)$ is such that the hash root of $\cC$ is $h$.
\item {\func{ctree\_cgraft}} takes a graft $\cG$ and a compact tree $\cC$
and replaces each ${\constr{CHash}}(h)$ in $\cC$ with $\cC'$
where $(h,\cC')$ is in $\cG$.
\item {\func{factor\_tx\_ctree\_cgraft}} takes a transaction and a compact tree $\cC$
and computes a pair $(\cC',\cG)$ of a compact tree $\cC'$ and a graft $\cG$.\footnote{This function is currently unused.}
Here $\cC'$ is an approximation of $\cC$
and {\func{ctree\_cgraft}} applied to $\cG$ and $\cC'$ yields $\cC$.
\item {\func{factor\_inputs\_ctree\_cgraft}} takes an {\type{addr\_assetid}}
(a list of transaction inputs)
and a compact tree $\cC$
and computes a pair $(\cC',\cG)$ of a compact tree $\cC'$ and a graft $\cG$.
Here $\cC'$ is an approximation of $\cC$
and {\func{ctree\_cgraft}} applied to $\cG$ and $\cC'$ yields $\cC$.
The purpose of this function is to factor the part of the compact tree
needed for the block header from the part needed for the rest of the block.
\end{itemize}


\documentclass[12pt]{amsart}

\usepackage{enumerate, color, amssymb, amsmath, amsfonts, amsthm, graphics, mathrsfs}
%\usepackage[hmargin=1 in, vmargin = 0.5 in]{geometry}

%%%%%%% Pagestyle stuff %%%%%%%%%%%%%%%%%%%
 \usepackage{fancyhdr}                   %%
   \pagestyle{fancy}                     %%
   \fancyhf{} %delete the current section for header and footer
 \usepackage[paperheight=11in,%          %%
             paperwidth=8.5in,%          %%
             outer=1.2in,%               %%
             inner=1.2in,%               %%
             bottom=.7in,%               %%
             top=.7in,%                  %%
             includeheadfoot]{geometry}  %%
   \addtolength{\headwidth}{.75in}       %%
   \fancyhead[RO,LE]{\thepage}           %%
   \fancyhead[RE,LO]{\sectionname}       %%
   \setlength{\headheight}{15.8pt}       %%
   \raggedbottom{}                       %%
%%%%%%% End Pagestyle stuff %%%%%%%%%%%%%%%

% When you first define a new word, use this macro to make it stand out
% EG We say that an abelian group $I$ is \newword{injective} if, for any
% injection $G \to H$, and any map $G \to I$, there is a map $H \to I$ making the
% obvious diagram commute.
\newcommand{\newword}[1]{\textbf{\emph{#1}}}

%Arrows
\newcommand{\into}{\hookrightarrow}
\newcommand{\onto}{\twoheadrightarrow}

%Things LaTeX names by appearance, rather than meaning
% By now, I've learned the standard LaTeX names, but I remember they used to give me trouble, so here are some macros
\newcommand{\isom}{\cong} %The isomorphism symbol
\newcommand{\union}{\cup}
\newcommand{\intersection}{\cap}
\newcommand{\bigunion}{\bigcup}
\newcommand{\bigintersection}{\bigcap}
\newcommand{\disjointunion}{\sqcup}
\newcommand{\bigdisjointunion}{\bigsqcup}
\newcommand{\hilight}[1]{\colorbox{yellow}{#1}}

%Some multiletter functions
\DeclareMathOperator{\Hom}{Hom}
\DeclareMathOperator{\Ext}{Ext}
\DeclareMathOperator{\End}{End}
\DeclareMathOperator{\Tor}{Tor}
\DeclareMathOperator{\Ker}{Ker}
\DeclareMathOperator{\CoKer}{CoKer}
\DeclareMathOperator{\Spec}{Spec}
\DeclareMathOperator{\Proj}{Proj}
\DeclareMathOperator{\Lie}{Lie}
\DeclareMathOperator{\Map}{Map}
\DeclareMathOperator{\Endo}{End}
\DeclareMathOperator{\tr}{tr}
\DeclareMathOperator{\ad}{ad}
\renewcommand{\Im}{\mathop{\mathrm{Im}}}
%Their calligraphic versions; use these for the sheaf constructions
\DeclareMathOperator{\HHom}{\mathcal{H} \textit{om}}
\DeclareMathOperator{\EExt}{\mathcal{E} \textit{xt}}
\DeclareMathOperator{\EEnd}{\mathcal{E} \textit{nd}}
\DeclareMathOperator{\TTor}{\mathcal{T} \textit{or}}
\DeclareMathOperator{\KKer}{\mathcal{K}\textit{er}}
\DeclareMathOperator{\CCoKer}{\mathcal{C} \textit{o}\mathcal{K} \textit{er}}
\newcommand{\IIm}{\mathop{\mathcal{I} \textit{m}}}
\newcommand{\ccH}{\mathscr{H}} %The very curly H

%This makes alternating tensors look right in displayed equations
\newcommand{\Alt}{\bigwedge\nolimits}

\newcommand{\mf}[1]{\mathfrak{#1}}

%Blackboard bold letters.
\renewcommand{\AA}{\mathbb{A}}
\newcommand{\BB}{\mathbb{B}}
\newcommand{\CC}{\mathbb{C}}
\newcommand{\DD}{\mathbb{D}}
\newcommand{\EE}{\mathbb{E}}
\newcommand{\FF}{\mathbb{F}}
\newcommand{\GG}{\mathbb{G}}
\newcommand{\HH}{\mathbb{H}}
\newcommand{\II}{\mathbb{I}}
\newcommand{\JJ}{\mathbb{J}}
\newcommand{\KK}{\mathbb{K}}
\newcommand{\LL}{\mathbb{L}}
\newcommand{\MM}{\mathbb{M}}
\newcommand{\NN}{\mathbb{N}}
\newcommand{\OO}{\mathbb{O}}
\newcommand{\PP}{\mathbb{P}}
\newcommand{\QQ}{\mathbb{Q}}
\newcommand{\RR}{\mathbb{R}}
\renewcommand{\SS}{\mathbb{S}}
\newcommand{\TT}{\mathbb{T}}
\newcommand{\UU}{\mathbb{U}}
\newcommand{\VV}{\mathbb{V}}
\newcommand{\WW}{\mathbb{W}}
\newcommand{\XX}{\mathbb{X}}
\newcommand{\YY}{\mathbb{Y}}
\newcommand{\ZZ}{\mathbb{Z}}

%Calligraphic letters

\newcommand{\cA}{\mathcal{A}}
\newcommand{\cB}{\mathcal{B}}
\newcommand{\cC}{\mathcal{C}}
\newcommand{\cD}{\mathcal{D}}
\newcommand{\cE}{\mathcal{E}}
\newcommand{\cF}{\mathcal{F}}
\newcommand{\cG}{\mathcal{G}}
\newcommand{\cH}{\mathcal{H}}
\newcommand{\cI}{\mathcal{I}}
\newcommand{\cJ}{\mathcal{J}}
\newcommand{\cK}{\mathcal{K}}
\newcommand{\cL}{\mathcal{L}}
\newcommand{\cM}{\mathcal{M}}
\newcommand{\cN}{\mathcal{N}}
\newcommand{\cO}{\mathcal{O}}
\newcommand{\cP}{\mathcal{P}}
\newcommand{\cQ}{\mathcal{Q}}
\newcommand{\cR}{\mathcal{R}}
\newcommand{\cS}{\mathcal{S}}
\newcommand{\cT}{\mathcal{T}}
\newcommand{\cU}{\mathcal{U}}
\newcommand{\cV}{\mathcal{V}}
\newcommand{\cW}{\mathcal{W}}
\newcommand{\cX}{\mathcal{X}}
\newcommand{\cY}{\mathcal{Y}}
\newcommand{\cZ}{\mathcal{Z}}
\newcommand{\fg}{\mathfrak{g}}
\newcommand{\fh}{\mathfrak{h}}
\newcommand{\fn}{\mathfrak{n}}
\newcommand{\fb}{\mathfrak{b}}
\newcommand{\GL}{\text{GL}}

\newtheorem{thm}{Theorem}
\newtheorem{lem}[thm]{Lemma}
\newtheorem{prop}[thm]{Proposition}
\newtheorem{cor}[thm]{Corollary}

\theoremstyle{definition}
\newtheorem{defn}[thm]{Definition}
\newtheorem{expl}[thm]{Example}
\newtheorem{expls}[thm]{Examples}
\newtheorem{rmk}[thm]{Remark}
\newtheorem{example}[thm]{Example}

\title{MAT5105 study notes}
\author{Robert Lech}
\date{\today}

\begin{document}

\maketitle

\section{Planar Graphs}

% Jordan-Curve Theorem
\begin{thm} (Jordan-Curve Theorem)

A Jordan curve $J$ in the plane separates the rest of the plane into two disjoint open sets $int(J)$ and $ext(J)$ (with their respective closures $Int(J)$ and $Ext(J)$ intersecting in $J$). Any arc with origin in $int(J)$ and terminus in $ext(J)$ must intersect $J$ in at least one point.
\end{thm}

% Non-Planar
\begin{thm} (Non-Planar)

$K_5$ and $K_{3,3}$ are non-planar.
\end{thm}

% Proper Face Conditions
\begin{thm} (Proper Face Conditions)

If $G$ is non-separable, and $G\ncong K_1, K_2$ $\Rightarrow$ the boundary of each face is a cycle.
\end{thm}

% Swap Inner Face with Outer Face
\begin{prop} (Swap Inner Face with Outer Face)

Let $G$ be a planar graph with a planar embedding $\widetilde{G}$. Take any face $f\in F(\widetilde{G})$. Then $G$ has a planar embedding such that $\partial(f)$ is the boundary of the outer face.
\end{prop}

% Subdivision Planarity
\begin{prop} (Subdivision Planarity)

$G$ is a planar graph $\Longleftrightarrow$ every subdivision of $G$ is planar.
\end{prop}

% $K_5$ and $K_{3,3}$ Subdivisions are not Planar
\begin{cor} ($K_5$ and $K_{3,3}$ Subdivisions are not Planar)

Every subdivision of $K_5$ and $K_{3,3}$ is not planar.
\end{cor}

% [KURATOWSKI] NASC for Planarity
\begin{thm} (KURATOWSKI) (NASC for Planarity)

$G$ is a planar graph $\Longleftrightarrow$ $G$ contains no subdivision of $K_5$ or $K_{3,3}$.
\end{thm}

% NASC for Embeddability
\begin{thm} (NASC for Embeddability)

$G$ is a embeddable on a plane $\Longleftrightarrow$ $G$ is a embeddable on a sphere
\end{thm}

% Dual Facts
\begin{lem} (Dual Facts)

Let $G$ be a plane graph, $G^*$ its dual. Then:
\begin{itemize}
  \item $|V(G^*)|=|F(G)|$
  \item $|E(G^*)|=|E(G)|$
  \item $d_G(f)=d_{G^*}(f^*), \forall f\in F(G)$
\end{itemize}

\end{lem}

%Faces-Edge Relation
\begin{cor} (Faces-Edge Relation)

$\sum_{f\in F(G)} d_G(f)=2|E(G)|$
\end{cor}

%Euler's Formula
\begin{thm} (Euler's Formula)

$G$ connected graph on a surface with characteristic $\sigma$ $\implies$ $|V|-|E|+|F|=\sigma$.
\end{thm}

%Euler's Formula Corollary
\begin{cor} (Euler's Formula Corollary)

Let $G$ be a connected and planar. Then
\begin{itemize}
  \item All planar embeddings of $G$ have the same number of faces.
  \item If $G$ is simple and $n\geq 3$, then $|E| \leq 3|V|-6$.
  \item If $G$ is simple and $n\geq 3$, then $\delta(G) \leq 5$.
\end{itemize}
\end{cor}

%Non-Planar
\begin{cor} (Non-Planar)

$K_5$ and $K_{3,3}$ are non-planar.
\end{cor}

\section{Stable Sets, Cliques, and Colourings}

%Clique/Stable Set Connection
\begin{lem} (Clique/Stable Set Connection)

$S$ is a stable set of $G$ $\Longleftrightarrow$ $S$ is a clique of $\overline{G}$.
\end{lem}

%Lower Bound on $\chi$ with $\alpha$
\begin{lem} (Lower Bound on $\chi$ with $\alpha$)

$\chi \geq n/\alpha$
\end{lem}

%Upper on Chromatic Number for Subgraph $
\begin{lem} (Bound on Chromatic Number for Subgraph)

If $H \subseteq G$, then $\chi(H) \leq \chi(G)$
\end{lem}

%Lower Bound on $\chi$ with $\omega$
\begin{cor} (Lower Bound on $\chi$ with $\omega$)

$\chi \geq \omega$
\end{cor}

%Upper Bound on $\chi$ with $\Delta$
\begin{cor} (Upper Bound on $\chi$ with $\Delta$)

$\chi \leq \Delta+1$
\end{cor}

%Critical Implies Connected
\begin{lem} (Critical Implies Connected)

If $G$ is critical, then $G$ is connected.
\end{lem}

%Critical Implies Bound on $\delta$
\begin{thm} (Critical Implies Bound on $\delta$)

If $G$ is $k-$critical, then $\delta(G)\geq k-1$
\end{thm}

%Chromatic and Degree of Vertices
\begin{cor} (Chromatic and Degree of Vertices)

If $G$ is $k-$chromatic, then $G$ has $k$ vertices $(v_1,\ldots, v_k)$ such that $d(v_i)\geq k-1$
\end{cor}

%Upper Bound on $\chi$ with $\Delta$
\begin{cor} (Upper Bound on $\chi$ with $\Delta$)

$\chi \leq \Delta+1$
\end{cor}

%NC for $S-$component
\begin{thm} (NC for $S-$component)

If $G$ is $k-$critical and $S$ is a vx cut of $G$, then $S$ is not a clique.
\end{thm}

%NC for $\{u\}-$component
\begin{cor} (NC for $\{u\}-$component)

If $G$ is $k-$critical and $S=\{u\}$ is a vx cut of $G$, then $v$ is not a separating vertex.
\end{cor}

%NC for $\{u,v\}-$component
\begin{cor} (NC for $\{u,v\}-$component)

If $G$ is $k-$critical and $S=\{u,v\}$ is a vx cut of $G$, then $u\nsim v$.
\end{cor}

%[DIRAC] Type-1, Type-2 Subgraphs for $\{u,v\}-$components
\begin{thm} (DIRAC) (Type-1, Type-2 Subgraphs for $\{u,v\}-$components)

If $G$ is $k-$critical and $S=\{u,v\}$ is a vx cut of $G$, then:
\begin{itemize}
  \item $G=G_1+G_2$, where $G_1$ is type-1 and $G_2$ is type-2.
  \item $G+uv$ and $G_2/\{u,v\}$ are $k-$critical.
\end{itemize}
\end{thm}

%Critical Implies Bound on Degrees
\begin{cor} (Critical Implies Bound on Degrees)

Let $G$ is $k-$critical and $S=\{u,v\}$ is a vx cut of $G$, then $d_G(u)+d_G(v)\geq 3k-5$.
\end{cor}

%1,2,3-Critical Graphs
\begin{lem} ($1,2,3-$Critical Graphs)

Let $G$ is $k-$critical. Then:
\begin{itemize}
  \item $k=1\implies G \cong K_1$
  \item $k=2\implies G \cong K_2$
  \item $k=3\implies G \cong C_{2k+1}$
\end{itemize}
\end{lem}

%[Brooks 1941] Better Bound on $\chi$
\begin{thm} (BROOKS 1941) (Better Bound on $\chi$)

Let $G$ be a connected, simple graph where $G\ncong K_n, G\ncong C_{2l+1}$ then $\chi(G)\leq \Delta(G)$.
\end{thm}

\section{Matchings and Coverings}

% [BERGE] Augmenting Paths and Maximal Matching
\begin{thm} (BERGE) (Augmenting Paths and Maximal Matching)

Let $M$ be a matching of $G$. Then $M$ is maximum if and only if $G$ contains no $M$-augmenting path.
\end{thm}

% [TUTTE] Perfect Matchings and \# Odd Components with Vertex Cu
\begin{thm} (TUTTE) (Perfect Matchings and \# Odd Components with Vertex Cut)

Let $G$ be a connected, simple graph. $G$ has a perfect matching if and only if $o(G-S) \leq |S|$ for all $S \subseteq V$.
\end{thm}

% [PETERSEN] Perfect Matchings and 3-Regular Graphs
\begin{thm} (PETERSEN) (Perfect Matchings and 3-Regular Graphs)

If $G$ is a $3$-regular graph without cut edges, then $G$ has a perfect matching.
\end{thm}

% [HALL] NASC for Saturated Matching in Bipartite Graphs
\begin{thm} (HALL) (NASC for Saturated Matching in Bipartite Graphs)

Let $G$ be a bipartite graph with bipartition $(X,Y)$. Then $G$ contains a matching that saturates
every vertex in $X$ if and only if $|N(S)| \geq |S|$ for all $S \subseteq X$.
\end{thm}

% [MARRIAGE] Perfect Matching and Regular Bipartite Graphs
\begin{thm} (HALL/MARRIAGE THEOREM) (Perfect Matching and Regular Bipartite Graphs)

If $G$ is a $k$-regular bipartite graph with $k > 0$, then $G$ has a perfect matching.
\end{thm}

% Regular Graphs and 1-Factorizations
\begin{thm} (Regular Graphs and 1-Factorizations)

If $G$ is a $k$-regular graph with $k > 0$, then $G$ has a 1-factorization.
\end{thm}

% [K\"{O}NIG-EGERV\'{A}RY] Maximum Matching and Minimum Covering in Bipartite Graphs
\begin{thm} (K\"{O}NIG-EGERV\'{A}RY) (Maximum Matching and Minimum Covering in Bipartite Graphs)

If $G$ is a bipartite graph with a maximum matching $M^*$ and a minimum covering $\widetilde{K}$, then $|M^*|=|\widetilde{K}|$
\end{thm}

\section{Hamilton Graphs}

% Hamilton Cycle and \# Components with Vertex Cut
\begin{thm} (Hamilton Cycle and \# Components with Vertex Cut)

Let $G$ be a Hamilton graph. Then $\forall S\subset V$, $S\neq \emptyset$, $c(G-S)\leq |S|$.
\end{thm}

% [BONDY-CHVATAL] Conditions for when $G$ Hamiltonian $\Longleftrightarrow$ $G+uv$ Hamiltonian
\begin{lem} (BONDY-CHVATAL) (Conditions for when $G$ Hamiltonian $\Longleftrightarrow$ $G+uv$ Hamiltonian)

Let $G$ be a simple graph of order $n$. Let $u$ and $v$ be non-adjacent vertices with $d(u) + d(v) \geq n$. Then $G$ is Hamiltonian if and only if $G+uv$ is Hamiltonian.
\end{lem}

% [DIRAC] $\delta\geq \frac{n}{2}$ implies Hamiltonian
\begin{thm} (DIRAC 2) ($\delta\geq \frac{n}{2}\implies$ Hamiltonian)

Let $G$ be a simple graph of order $n \geq 3$ and minimum degree $\delta \geq n/2$. Then $G$ is Hamiltonian.
\end{thm}

% $cl(G)$ Closure Hamiltonian $\Longleftrightarrow$ $G$ Hamiltonian
\begin{cor} ($cl(G)$ Hamiltonian $\Longleftrightarrow$ $G$ Hamiltonian)

Let $G$ be a simple graph. Then $G$ is Hamiltonian if and only if the closure is Hamiltonian.
\end{cor}

% $cl(G)$ Complete $\implies$ $G$ Hamiltonian
\begin{cor} ($cl(G)$ Complete $\implies$ $G$ Hamiltonian)

Let $G$ be a simple graph with $n\geq 3$ and $cl(G)\cong K_n$. Then $G$ is Hamiltonian.
\end{cor}

% [CHVATAL]  Stupid Conditions $\implies$ Hamiltonian
\begin{thm} (CHVATAL) (Stupid Conditions $\implies$ Hamiltonian)

Let $G$ be a simple graph of order $n \geq 3$ with degree sequence $(d_1,d_2,\ldots,d_n)$, where
$d_1 \leq d_2 \leq \cdots \leq d_n$. Suppose that there is no value of $k$ less than $n/2$ for which
$d_k \leq k$ and $d_{n-k} \leq n-k$. Then $G$ is Hamiltonian.
\end{thm}

\section{Edge-Colourings}

% $\chi'$ and $\Delta$
\begin{lem} ($\chi'$ and $\Delta$)

Let $G$ be a graph. Then $\chi' \geq \Delta$.
\end{lem}

% [VIZING] Simple Graph, $\chi'$ and $\Delta$
\begin{thm} (VIZING) (Simple Graph, $\chi'$ and $\Delta$)

Let $G$ be a simple graph. Then $\chi' = \Delta$ (Class 1) or $\chi' = \Delta+1$ (Class 2).
\end{thm}

% Multiple Edge Graph, $\chi'$ and $\Delta$
\begin{lem} (Multiple Edge Graph, $\chi'$ and $\Delta$)

Let $G$ be a graph. Suppose $\mu=\#$ of edges between $u,v$, $\forall u,v\in V(G)$. Then $\chi' \leq \Delta+\mu$
\end{lem}

% Bipartite Graph, $\chi'$ and $\Delta$
\begin{thm} (Bipartite Graph, $\chi'$ and $\Delta$)

Let $G$ be a graph. If $G$ is bipartite, then $\chi' = \Delta$.
\end{thm}

\end{document}

Theorems for 2nd Half of Graph Theory Course/paper-no-proofs.tex


\section{Relative suffix tree}

The \emph{relative suffix tree} (\RCST) is a \CSTnpr{} of the
target sequence relative to a \CST{} of the reference sequence. It consists of
two major components: the relative FM-index with full functionality and the
\emph{relative} \LCP{} (\RLCP) \emph{array}. The optional relative select
structure can be generated or loaded from disk to speed up algorithms based on
forward searching. The \RLCP{} array is based on \RLZ{} parsing, while the
support for \nsv/\psv/\rmq{} queries is based on a minima tree over the
phrases.

\subsection{Relative \LCP{} array}

Given \LCP{} array $\mLCP[1,n]$, we define the \emph{differential} \LCP{}
\emph{array} $\mDLCP[1,n]$ as $\mDLCP[1] = \mLCP[1]$ and $\mDLCP[i] = \mLCP[i]
- \mLCP[i-1]$ for $i > 1$. If $\mBWT[i,j] = c^{j+1-i}$ for some $c \in
\Sigma$, then $\mLCP[\mLF(i)+1,\mLF(j)]$ is the same as $\mLCP[i+1,j]$, with
each value incremented by $1$ \cite{Fischer2009a}. This means
$\mDLCP[\mLF(i)+2,\mLF(j)] = \mDLCP[i+2,j]$, making the \DLCP{} array of a
repetitive text compressible with grammar-based compression
\cite{Abeliuk2013}.

We make a similar observation in the relative setting. If target sequence $S$
is similar to the reference sequence $R$, then their \LCP{} arrays should also
be similar. If there are long identical ranges $\mLCP_{R}[i,i+k] =
\mLCP_{S}[j,j+k]$, the corresponding \DLCP{} ranges $\mDLCP_{R}[i+1,i+k]$ and
$\mDLCP_{S}[j+1,j+k]$ are also identical. Hence we can use \RLZ{} parsing to
compress either the original \LCP{} array or the \DLCP{} array.

While the identical ranges are a bit longer in the \LCP{} array, we opt to
compress the \DLCP{} array, because it behaves better when there are long
repetitions in the sequences. In particular, assembled genomes often have long
runs of character $N$, which correspond to regions of very large \LCP{}
values. If the runs are longer in the target sequence than in the reference
sequence, the \RLZ{} parsing of the \LCP{} array will have many
mismatch characters. The corresponding ranges in the
\DLCP{} array typically consist of values $\set{-1, 0, 1}$, making them much
easier to compress.

We consider \DLCP{} arrays as strings over an integer alphabet and create an \RLZ{} parsing
of $\mDLCP_{S}$ relative to $\mDLCP_{R}$. After parsing, we switch to using
$\mLCP_{R}$ as the reference. The reference is stored in a
structure we call \slarray, which is a variant of \LCPbyte.
\cite{Abouelhoda2004}. Small values $\mLCP_{R}[i] < 255$ are stored in a byte
array, while large values $\mLCP_{R}[i] \ge 255$ are marked with a $255$ in the
byte array and stored separately. To quickly find the large values, we also
build a $\mrank_{255}$ structure over the byte array. The \slarray{} provides
reasonably fast random access and fast sequential access to the
underlying array.

The \RLZ{} parsing produces a sequence of phrases $w_{i} = (p_{i}, \ell_{i},
c_{i})$ (see Section~\ref{sect:rlz}; since we are using Cox et al.'s version, $c_{i}$ is now a string).
Because some queries involve decompressing an entire phrase, we limit the maximum phrase length to $1024$.
We also require that $\abs{c_{i}} > 0$ for all $i$, using the last character of the copied substring
as a mismatch if necessary.

Phrase lengths are encoded in the $W_{\ell}$ bitvector in the usual way. We convert the strings of mismatching
\DLCP{} values $c_{i}$ into strings of absolute \LCP{} values, append them into the mismatch array $W_{c}$, and
store the array as an \slarray. The mismatch values are used as \emph{absolute
samples} for the differential encoding.

To access $\mLCP_{S}[j]$, we determine the phrase $w_{i}$ as usual, and check whether we should return a mismatch character. If so, we compute which one using a prefix sum query on $L$, and return it.  If not, we determine the starting positions $p_{i}$ and $s_{i}$ of the phrase $w_{i}$ in the reference and the target, respectively. We can then compute the solution as
\begin{align*}
\mLCP_{S}[j] &= \mLCP_{S}[s_{i} - 1] + \sum_{k = s_{i}}^{j} \mDLCP_{S}[k] \\
&= \mLCP_{S}[s_{i} - 1] + \sum_{k = p_{i}}^{j'} \mDLCP_{R}[k] \\
&= \mLCP_{S}[s_{i} - 1] + \mLCP_{R}[j'] - \mLCP_{R}[p_{i} - 1],
\end{align*}
where $j' = p_{i} + j - s_{i}$.
Each \RLZ{} phrase ends with at least one mismatch character, so $\mLCP_{S}[s_{i} - 1]$ is readily available. After finding $\mLCP_{S}[j]$, accessing $\mLCP_{S}[j-1]$ and $\mLCP_{S}[j+1]$ is fast, as long as we do not cross phrase boundaries.

\paragraph{Example.}
Figure~\ref{fig:ex} shows an example reference sequence $R$ and target
sequence $S$, with their corresponding arrays $\SA$, $\LCP$, and $\DLCP$.
The single edit at $S[4]$ with respect to $R[4]$ may affect the positions
of suffixes $4$ and previous ones in $\SA$, although in general only a limited
number of preceding suffixes are affected. In our example, suffix $4$ moves
from position $7$ in $\SA_R$ to position $4$ in $\SA_S$, and suffix $3$ moves
from position $11$ in $\SA_R$ to position $10$ in $\SA_S$. Each suffix that
is moved from $\SA_R[i]$ to $\SA_S[j]$ may alter the values at positions $i$
or $i+1$ (depending on whether $j>i$ or $j<i$), as well as $j$ and $j+1$, of
$\LCP_S$. We have surrounded in rectangles the conserved regions in $\LCP_S$
(some are conserved by chance). Even some suffixes that
are not moved may change their $\LCP$ values. In turn, each change in
$\LCP_S[k]$ may change values $\DLCP_S[k]$ and $\DLCP_S[k+1]$.

After the change, we can parse $\DLCP_S$ into three phrases (with the copied
symbols surrounded by rectangles):
$(1,4,0)$, $(5,3,-2)$, $(6,2,-2)$, where the latter is formed by chance.
We represent this parsing as $W_c = \langle 1,0,0 \rangle$ (since we store the
absolute $\LCP_S$ values for the mismatches), $W_\ell = 100001000100$, and
$W_p = \langle 1,5,6 \rangle$ (or rather $W_r = \langle 0,-1,-4 \rangle$).

Let us compute $\LCP_S[j]$ for $j=8$. This corresponds to phrase number
$i = \rank(W_\ell,j) = 2$, which starts at position $s_i = \select(W_\ell,i)=6$
in $\LCP_S$. The corresponding position in $\LCP_R$ is $p_i = W_p[i] = 5$
(or rather $p_i = s_i + W_r[i] = 5$), and the mapped position $j$ is
$j' = p_i+j-s_i = 7$. Finally, $\LCP_S[s_i-1] = W_c[i-1]=1$.
According to our formula, then, we have
$\LCP_S[8] = \LCP_S[s_i-1] + \LCP_R[j'] - \LCP_R[p_i-1] = 1+2-1=2$.

\begin{figure}
\centerline{\includegraphics[width=0.4\textwidth]{ex.pdf}}
\caption{An example of our $\RLZ$ compression of $\DLCP$.}
\label{fig:ex}
\end{figure}

\subsection{Supporting \nsv/\psv/\rmq{} queries}

Suffix tree topology can be inferred from the \LCP{} array with range minimum
queries (\rmq) and next/previous smaller value (\nsv/\psv) queries
\cite{Fischer2009a}. Some suffix tree operations are more efficient
if we also support \emph{next/previous smaller or equal value} (\nsev/\psev)
queries \cite{Abeliuk2013}. Query $\mnsev(i)$ ($\mpsev(i)$) finds the next
(previous) value smaller than or equal to $\mLCP[i]$.

In order to support the queries, we build a $64$-ary \emph{minima tree} over
the phrases of the \RLZ{} parsing. Each leaf node stores the smallest \LCP{}
value in the corresponding phrase, while each internal node stores the
smallest value in the subtree. Internal nodes are created and stored in a
levelwise fashion, so that each internal node, except perhaps the rightmost
one of each level, has $64$ children.

We encode the minima tree as two arrays. The smallest \LCP{} values are
stored in $M_{\mLCP}$, which we encode as an \slarray. Plain array $M_{L}$
stores the starting offset of each level in $M_{\mLCP}$, with the leaves
stored starting from offset $M_{L}[1] = 1$. If $i$ is a minima tree node
located at level $j$, the corresponding minimum value is $M_{\mLCP}[i]$, the
parent of the node is $M_{L}[j+1] + \lfloor (i - M_{L}[j]) / 64 \rfloor$,
and its first child is $M_{L}[j-1] + 64 \cdot (i - M_{L}[j])$.

A range minimum query $\mrmq(sp,ep)$ starts by finding the minimal range of
phrases $w_{l}, \dotsc, w_{r}$ covering the query and the maximal range of
phrases $w_{l'}, \dotsc, w_{r'}$ contained in the query (note that $l \le l' \le
l+1$ and $r-1 \le r' \le r$). We then use the
minima tree to find the leftmost minimum value $j = M_{\mLCP}[k]$ in
$M_{\mLCP}[l',r']$, and find the leftmost occurrence $\mLCP[i] = j$ in phrase
$w_{k}$. If $l < l'$ and $M_{\mLCP}[l] \le j$, we decompress phrase $w_{l}$
and find the leftmost minimum value $\mLCP[i'] = j'$ (with $i' \ge sp$) in the
phrase. If $j' \le j$, we update $(i,j) \leftarrow (i',j')$. Finally we check
phrase $w_{r}$ in a similar way, if $r > r'$ and $M_{\mLCP}[r] < j$. The answer
to the range minimum query is $\mLCP[i] = j$, so we return
$(i,j)$.\footnote{The definition of the query only calls for the leftmost
minimum position $i$. We also return $\mLCP[i] = j$, because suffix tree
operations often need it.} Finally, the particular case where no phrase is
contained in $[sp,ep]$ is handled by sequentially scanning one or two phrases
in $\LCP$.

The remaining queries are all similar to each other. In order to answer query
$\mnsv(i)$, we start by finding the phrase $w_{k}$ containing position $i$,
and then determining $\mLCP[i]$. Next we scan the rest of the phrase to see
whether there is a smaller value $\mLCP[j] < \mLCP[i]$ later in the phrase. If
so, we return $(j,\mLCP[j])$. Otherwise we traverse the minima tree to find
the smallest $k' > k$ with $M_{\mLCP}[k'] < \mLCP[i]$. We decompress
phrase $w_{k'}$, find the leftmost position $j$ with $\mLCP[j] < \mLCP[i]$,
and return $(j,\mLCP[j])$.