\chapter{Related Work and Background}
\label{chap:realred_work}

\par In this chapter, we survey some of the related research in the areas of pattern prediction over event streams task, and techniques of distributed online learning over data streams. Then we give a brief overview of the Big Data platforms that we used to implement our system.
\section{Related Work}
\input{chapters/pattern_prediction}
\input{chapters/distributedOnlineLearning}
\input{chapters/technological_background}

\par In this thesis work, the approach we propose is to combine the Markov based pattern predictors \cite{alevizos2017event} with a distributed online learning protocol \cite{kamp2014communication} to learn a global model based on the local models. This is discussed in detail in Chapter~\ref{chapter:system}. We also implement our system within Apache Flink and Apache Kafka. The details will be discussed in Chapter~\ref{chapter:overview}.
%\section{Related Work}
%
%In this section, we discuss the building blocks and techniques of our proposed approach.
%
%
%\subsection{Event Forecasting with Pattern Markov Chains}
%
%Wayeb \cite{alevizos2017event} is a system that provides the ability to forecast the completion (i.e., full match) of defined patterns within an input stream of events, the proposed approach is based on the Pattern Markov Chain (PMC) framework \cite{nuel2008pattern} that provides a probabilistic model for the events pattern. The patterns are defined in  the form of regular expressions such as $p1=e1.*.(e3 | e4)$ ($p1$ is a pattern that starts with an event of type $e1$ followed by any event type, then ends with an event of type $e3$ or $e4$), which is transformed to deterministic finite automate $(DFA)$. The resulting $DFA$ is then used to construct a Markov Chain model, which  enables probabilistic inferences (i.e., probability of completion time interval) for the events pattern. Furthermore, the system implicitly is able to report the full matches of the foretasted pattern. We will employ it as the local prediction model in our system.
%
%%discuss stream is stationary assumption
%\subsection{Distributed Online Learning}
%
%\par In \cite{kamp2014communication} a distributed prediction learning protocol over multiple data streams has been proposed. Their work focuses on providing a dynamic and communication efficient synchronization scheme of learning models between distributed learners, by triggering the synchronization process on local node only if its local model diverges from a global reference point. This dynamic scheme comes as an improvement of the static synchronization (i.e., mini-batch) scheme \cite{dekel2012optimal} that is based on making the local learners send their local models to a central site after processing a fixed number of input samples (i.e., batch). In both settings, a central node  called coordinator receives the local learning models, in order to construct an aggregated global model based on all local models and sends it back to all participating nodes.
%
%\par In our system we refer to the predicator/forecaster nodes as the distributed learners. Our integration plan is divided into two steps: first, employing the distributed online learning protocol with mini-batch synchronization scheme by combing the local models after certain batch size $b \in \N$. Second, reduce the number of times that local learners need to communicate their models by applying the dynamic synchronization protocol.

%\subsection{Clustering}
%
%\par Clustering a set of objects into partitioned groups is a popular unsupervised machine learning method, it aims to divide the objects into disjoint subsets of objects (i.e., clusters), where the objects that belong to the same cluster are similar to each other and different from the objects in other clusters, and the similarity between objects is typically measured by some distance function \cite{clustering}. One of the most common clustering algorithms $DBSCAN$ \cite{ester1996density}  which is density based clustering algorithm that identifies clusters with arbitrary shapes in large spatial databases. Likewise, $k$-$means$ \cite{k-means} is another common clustering algorithms, it divides $M$ points into $K$ clusters based on minimizing the sum of squares (i.e., distance) between the points within the same cluster.
%
%\par In this thesis, we are applying our approach on events streams of moving objects (i.e., vessels). Thus, we are focusing on the trajectory-based clustering methods. Fortunately, There are many trajectory-based clustering techniques that have been proposed in literature, we will have to examine and evaluate some of the proposed clustering techniques to be utilized in our system.
%
% \par For instance, in \cite{liu2014knowledge} a density-based algorithm to cluster the moving trajectory points of vessels was introduced, they modified the definition of $Eps-neighborhood$ in the $DBSCAN$ algorithm to take into account the variance of the speed and direction. Moreover, Lee et al. \cite{lee2007trajectory} have proposed trajectories clustering algorithm (TRACLUS) that firstly splits the trajectory into  sequence of line segments,  which are then partitioned into clusters using s density-based clustering technique.
%
%\par On the other hand, the authors of \cite{chen2005robust} have proposed a new distance function of trajectories of moving objects, which is called $Edit Distance on Real sequence (EDR)$ that measures the similarity between two trajectories of moving objects (e.g., $T_1$ and $T_2$ based on the cost is needed to change $T_1$ into $T_2$ by checking the matching of the element of the two trajectories.

%don't forget to mention concept drift.


\subsection{Ableitungen}

\begin{tikzpicture}
	[	inner sep = 2mm,
		sin/.style={rectangle,minimum width=1.2cm,minimum height=1cm,rounded corners=5pt,draw=black,top color=green!20!black!50},
		abl/.style={rectangle}
	]
	\node at (1.2,0) (sin1) [sin] {$\sin$};
	\node at (0,-1.2) (cos2) [sin] {$-\cos$};
	\node at (1.2,-2.4) (sin2) [sin] {$-\sin$};
	\node at (2.4,-1.2) (cos1) [sin] {$\cos$};

	\draw[thick,black,->] (sin1.east) .. controls +(right:0.6cm) and +(up:0.6cm) ..  (cos1.north)
	node [pos=0.5,above](abl) {$\frac{d}{dx}$};
	\draw[thick,black,->] (cos1.south) .. controls +(down:0.6cm) and +(right:0.6cm) .. (sin2.east)
	node [pos=0.5,below](abl) {$\frac{d}{dx}$};
	\draw[thick,black,->] (sin2.west) .. controls +(left:0.6cm) and +(down:0.6cm) .. (cos2.south)
	node [pos=0.5,below](abl) {$\frac{d}{dx}$};
	\draw[thick,black,->] (cos2.north) .. controls +(up:0.6cm) and +(left:0.6cm) .. (sin1.west)
	node [pos=0.5,above](abl) {$\frac{d}{dx}$};
\end{tikzpicture}


\documentclass[a4paper]{article}

\usepackage{fixltx2e}
\usepackage{isomath}

\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[british]{babel}

\makeatletter
\useshorthands{"}%
\defineshorthand{"-}{\nobreak-\bbl@allowhyphens}
\defineshorthand{"=}{\nobreak--\bbl@allowhyphens}
\makeatother

\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{natbib}
\usepackage{proof}
\usepackage{tikz}
\usetikzlibrary{calc}
\usepackage{url}

\usepackage{microtype}

\usepackage{hyperref}

\newcommand*{\INFER}[3][]{\ensuremath{\infer[\text{\footnotesize #1}]{\mathstrut #2}{\mathstrut #3}}}

\newcommand*{\GRAPHR}[2]{%
	\begin{tikzpicture}[xscale=0.5, yscale=0.5]
		\path[draw, white] (0, 0) rectangle (1, 1);
		\path[thick, ->] (0, 0) edge[out=90, in=90, looseness=3] (1, 0);
		\node[anchor=north] at (0, 0) {$\mathstrut #1$};
		\node[anchor=north] at (1, 0) {$\mathstrut #2$};
	\end{tikzpicture}%
}

\newcommand*{\GRAPHL}[2]{%
	\begin{tikzpicture}[xscale=0.5, yscale=0.5]
		\path[draw, white] (0, 0) rectangle (1, 1);
		\path[thick, <-] (0, 0) edge[out=90, in=90, looseness=3] (1, 0);
		\node[anchor=north] at (0, 0) {$\mathstrut #1$};
		\node[anchor=north] at (1, 0) {$\mathstrut #2$};
	\end{tikzpicture}%
}

\newcommand*{\GRAPHH}[2]{%
	\begin{tikzpicture}[xscale=0.5, yscale=0.5]
		\path[draw, white] (0, 0) rectangle (1, 1);
		\draw[thick, help lines] (0, 0) rectangle (1, 0.75);
		\node[anchor=north] at (0, 0) {$\mathstrut #1$};
		\node[anchor=north] at (1, 0) {$\mathstrut #2$};
	\end{tikzpicture}%
}

\newcommand*{\SEQR}[2]{%
	\begin{tikzpicture}[xscale=0.5, yscale=0.5]
		\path[draw, white] (0, 0) rectangle (3.5, 1);
		\path[thick, ->] (0, 0) edge[out=90, in=90, looseness=3] (1, 0);
		\path[thick, ->] (2.5, 0) edge[out=90, in=90, looseness=3] (3.5, 0);
		\node at (1.75, 0.5) {$\mathstrut\cdots$};
		\node[anchor=north] at (0, 0) {$\mathstrut #1$};
		\node[anchor=north] at (3.5, 0) {$\mathstrut #2$};
	\end{tikzpicture}%
}

\newcommand*{\SEQL}[2]{%
	\begin{tikzpicture}[xscale=0.5, yscale=0.5]
		\path[draw, white] (0, 0) rectangle (3.5, 1);
		\path[thick, <-] (0, 0) edge[out=90, in=90, looseness=3] (1, 0);
		\path[thick, <-] (2.5, 0) edge[out=90, in=90, looseness=3] (3.5, 0);
		\node at (1.75, 0.5) {$\mathstrut\cdots$};
		\node[anchor=north] at (0, 0) {$\mathstrut #1$};
		\node[anchor=north] at (3.5, 0) {$\mathstrut #2$};
	\end{tikzpicture}%
}

\newcommand*{\SEQM}[2]{%
	\begin{tikzpicture}[xscale=0.5, yscale=0.5]
		\path[draw, white] (0, 0) rectangle (3.5, 1);
		\path[thick] (0, 0) edge[out=90, in=90, looseness=3] (1, 0);
		\path[thick] (2.5, 0) edge[out=90, in=90, looseness=3] (3.5, 0);
		\node at (1.75, 0.5) {$\mathstrut\cdots$};
		\node[anchor=north] at (0, 0) {$\mathstrut #1$};
		\node[anchor=north] at (3.5, 0) {$\mathstrut #2$};
	\end{tikzpicture}%
}

\newcommand*{\SEQU}[2]{%
	\begin{tikzpicture}[xscale=0.5, yscale=0.5]
		\path[draw, white] (0, 0) rectangle (3.5, 1);
		\path[thick] (0, 0) edge[out=90, in=90, looseness=3] (1, 0);
		\path[thick] (2.5, 0) edge[out=90, in=90, looseness=3] (3.5, 0);
		\node at (1.75, 0.5) {$\mathstrut\cdots$};
		\node at (1.75, 0.5) {$//$};
		\node[anchor=north] at (0, 0) {$\mathstrut #1$};
		\node[anchor=north] at (3.5, 0) {$\mathstrut #2$};
	\end{tikzpicture}%
}

\linespread{1.1}

\newcommand*{\ALGEBRA}[1]{\mathfrak{#1}}
\newcommand*{\FUN}[1]{\text{#1}}
\newcommand*{\SET}[1]{\{#1\}}
\newcommand*{\SETC}[2]{\SET{\,#1\mid #2\,}}
\newcommand*{\TERMS}[1]{T({#1})}

\begin{document}

\title{Tabulation of Noncrossing Acyclic Digraphs}

\author{%
	Marco Kuhlmann\\
	Department of Computer and Information Science\\
	Linköping University, Sweden}

\maketitle

\section{Introduction}

\begin{figure}
	\centering\footnotesize
	\input ncdags-examples
	\caption{Some (out of 335) noncrossing acyclic digraphs of size~4.}
	\label{fig:ncdags-examples}
\end{figure}

A \emph{noncrossing graph} is a graph with its vertices drawn on a
circle and its edges drawn in the interior such that no two edges
cross each other.
This note is concerned with \emph{noncrossing acyclic digraphs}.
Examples of such structures are given in
Figure~\ref{fig:ncdags-examples}.
I present an algorithm that, given a number $n \geq 1$, computes a
compact representation of the set of all noncrossing acyclic digraphs
with $n$ nodes.
This compact representation can be used as the basis for a wide range
of dynamic programming algorithms on these graphs.
As an illustration, along with this note I am releasing the
implementation of an algorithm for counting the number of noncrossing
acyclic digraphs of a given
size.\footnote{\url{https://github.com/khlmnn/ncdags}} This number is
given by the following integer sequence (starting with $n = 1$); this
is A246756 in the OEIS \citep{oeis}:
\begin{center}
  1, 3, 25, 335, 5521, 101551, 1998753, 41188543, 877423873, 19166868607, \dots
\end{center}
Another application of the tabulation technique is in semantic
dependency parsing \citep{oepen2014broad}, where it can be used to
compute the highest"-scoring dependency graph for a given sentence
under an edge"-factored model.

\section{Preliminaries}

Before presenting the tabulation I introduce some terminology for
special types of noncrossing acylic digraphs, as well as a set of
operations on graphs that will be useful for the understanding of the
technique.

\subsection{Classification}
\label{sec:Classification}

The proposed tabulation is based on a classification of noncrossing
acyclic digraphs into 7 different types.
To simplify the presentation I only consider graphs with at least $2$
nodes.

A graph is called \emph{edge"-covered} if there is an edge connecting
its extremal vertices.
Thus there are 2~types of edge"-covered graphs:
\begin{itemize}
\item The covering edge goes from the minimal vertex to the maximal
  vertex.
  In this case, I say that the graph is \emph{minmax"-covered}.
\item The covering edge goes from the minimal vertex to the maximal
  vertex.
  In this case, I say that the graph is \emph{maxmin"-covered}.
\end{itemize}
If a graph is not edge"-covered, I distinguish two cases depending on
whether or not the graph is weakly connected -- that is, whether there
exists a path (consisting of two or more edges) between the extremal
vertices.
In the following I use the term \emph{connected} in the sense `weakly
connected but not edge"-covered'.
I distinguish 3~types of connected graphs:
\begin{itemize}
\item There is a directed path from the minimal vertex to the maximal
  vertex.
  In this case, I say that the graph is \emph{minmax"-connected}.
\item There is a directed path from the maximal vertex to the minimal
  vertex.
  In this case, I say that the graph is \emph{maxmin"-connected}.
  Note that because of acyclicity, a graph cannot be both
  minmax"-connected and maxmin"-connected.
\item There is no directed path between the two extremal vertices,
  implying that there is a path consisting of edges with mixed
  directions.
  In this case, I say that the graph is \emph{mix"-connected}.
\end{itemize}
The last two types are the graphs that are neither edge"-covered nor
connected.
In the following I refer to these graphs as \emph{unconnected}.
I distinguish 2~types:
\begin{itemize}
\item The graph has $2$ nodes.
  In this case, the graph is uniquely determined; it is the graph with
  $2$ nodes and no edges.
  I refer to this graph as the \emph{elementary graph}.
\item The graph has more than $2$ nodes.
  I say that the graph is \emph{non"-elementary}.
\end{itemize}
Note that this classification is exhaustive, meaning that every
noncrossing acyclic digraph falls into (exactly) one of the 7 classes.

\subsection{Operations}
\label{sec:Operations}

The proposed tabulation takes an algebraic view on noncrossing acyclic
digraphs where every graph is composed from `smaller' graphs by means
of three operations:
\begin{itemize}
\item \emph{Concatenate} two graphs, identifying the last vertex of
  the first graph with the first vertex of the second graph.
  This operation is perhaps easiest illustrated by drawing the graphs
  on a straight line rather than on a circle.
  (With this layout, the non"-crossing condition means that the edges
  can be drawn in the half"-plane above the line without crossings.)
  \begin{displaymath}
    \text{concatenating}
    \quad
    \begin{tikzpicture}[xscale=0.5, baseline=(n1.base)]
      \node (n1) at (0, 0) {$\mathstrut 1$};
      \node (n2) at (1, 0) {$\mathstrut 2$};
      \node (n3) at (2, 0) {$\mathstrut 3$};
      \node (n4) at (3, 0) {$\mathstrut 4$};
      \path[thick, ->] (n1) edge[out=90, in=90] (n4);
      \path[thick, ->] (n3) edge[out=90, in=90] (n2);
    \end{tikzpicture}
    \quad
    \text{and}
    \quad
    \begin{tikzpicture}[xscale=0.5, baseline=(n1.base)]
      \node (n4) at (0, 0) {$\mathstrut 4$};
      \node (n5) at (1, 0) {$\mathstrut 5$};
      \path[thick, ->] (n5) edge[out=90, in=90] (n4);
    \end{tikzpicture}
    \quad
    \text{yields}
    \quad
    \begin{tikzpicture}[xscale=0.5, baseline=(n1.base)]
      \node[blue] (n1) at (0, 0) {$\mathstrut 1$};
      \node[blue] (n2) at (1, 0) {$\mathstrut 2$};
      \node[blue] (n3) at (2, 0) {$\mathstrut 3$};
      \node[fill=yellow] (n4) at (3, 0) {$\mathstrut 4$};
      \node[red] (n5) at (4, 0) {$\mathstrut 5$};
      \path[thick, ->, blue] (n1) edge[out=90, in=90] ($(n4.north) - (0.2, 0)$);
      \path[thick, ->, blue] (n3) edge[out=90, in=90] (n2);
      \path[thick, ->, red] (n5) edge[out=90, in=90] ($(n4.north) + (0.2, 0)$);
    \end{tikzpicture}
  \end{displaymath}
  Here the vertices and edges contributed by the first graph are drawn
  in blue, those contributed by the second graph are drawn in red, and
  the joint vertex (simultaneously the last vertex of the first graph
  and the first vertex of the second graph) is highlighted in yellow.

\item \emph{Cover} a graph by adding a new edge (with two possible
  directions) between the first vertex and the last vertex.
  In the following illustration, the new edges are drawn in red:
  \begin{displaymath}
    \text{covering}
    \quad
    \begin{tikzpicture}[xscale=0.5, baseline=(n1.base)]
      \node (n1) at (0, 0) {$\mathstrut 1$};
      \node (n2) at (1, 0) {$\mathstrut 2$};
      \node (n3) at (2, 0) {$\mathstrut 3$};
      \node (n4) at (3, 0) {$\mathstrut 4$};
      \path[thick, ->] (n3) edge[out=90, in=90] (n2);
    \end{tikzpicture}
    \quad
    \text{yields}
    \quad
    \begin{tikzpicture}[xscale=0.5, baseline=(n1.base)]
      \node (n1) at (0, 0) {$\mathstrut 1$};
      \node (n2) at (1, 0) {$\mathstrut 2$};
      \node (n3) at (2, 0) {$\mathstrut 3$};
      \node (n4) at (3, 0) {$\mathstrut 4$};
      \path[thick, ->, red] (n1) edge[out=90, in=90] (n4);
      \path[thick, ->] (n3) edge[out=90, in=90] (n2);
    \end{tikzpicture}
    \quad
    \text{or}
    \quad
    \begin{tikzpicture}[xscale=0.5, baseline=(n1.base)]
      \node (n1) at (0, 0) {$\mathstrut 1$};
      \node (n2) at (1, 0) {$\mathstrut 2$};
      \node (n3) at (2, 0) {$\mathstrut 3$};
      \node (n4) at (3, 0) {$\mathstrut 4$};
      \path[thick, <-, red] (n1) edge[out=90, in=90] (n4);
      \path[thick, ->] (n3) edge[out=90, in=90] (n2);
    \end{tikzpicture}
  \end{displaymath}
\end{itemize}
Note that the set of noncrossing acyclic digraphs is not closed under
these operations.
In particular, the cover operations may introduce cycles and even
multiple edges.

\section{Tabulation}

I present the proposed tabulation as a deduction system in the sense
of \citet{shieber1995principles}.
Tabulation is viewed as a deductive process in which rules of
inference are used to derive statements about sets of graphs from
other such statements.
Statements are represented by formulas called \emph{items}.

\paragraph{Notation}

Recall that I assume that $n \geq 2$.
In the following, $1 \leq i \leq j \leq k \leq n$.

\subsection{Items}

Following the classification given in
Section~\ref{sec:Classification}, the items of the deduction system
take one of 7 possible forms.
I represent these items using a graphical notation that is intended to
be mnemonic.
\begin{itemize}
\item \textit{Items for edge"-covered graphs.} For $j - i \geq 1$:
  \begin{displaymath}
    \GRAPHR{i}{j}
    \qquad
    \GRAPHL{i}{j}
  \end{displaymath}
  The intended interpretation of these items is: `It is possible to
  construct an edge"-covered noncrossing acyclic digraph on the
  vertices $i, \dots, j$.'

\item \textit{Items for connected graphs.} For $j - i \geq 2$:
  \begin{displaymath}
    \SEQR{i}{j}
    \qquad
    \SEQL{i}{j}
    \qquad
    \SEQM{i}{j}
  \end{displaymath}
  The intended interpretation of these items is: `It is possible to
  construct an minmax"-connected, maxmin"-connected, mix"-connected
  noncrossing acyclic digraph on the vertices $i, \dots, j$.'

\item \textit{Items for elementary graphs.} For $j - i = 1$:
  \begin{displaymath}
    \GRAPHH{i}{j}
  \end{displaymath}
  The intended interpretation of these items is: `The elementary graph on the vertices $i, j$ is a noncrossing acyclic digraph.'

\item \textit{Items for unconnected graphs.} For $j - i \geq 2$:
  \begin{displaymath}
    \SEQU{i}{j}
  \end{displaymath}
  The intended interpretation of these items is: `It is possible to
  construct an unconnected noncrossing acyclic digraph on the vertices
  $i, \dots, j$.'
\end{itemize}

\subsection{Axioms}

The axioms of the deduction system are the items for the elementary
graphs.

\subsection{Rules}

The deduction system has 26 rules.
Each of these rules simulates a concatenation or cover operation on
the 7 different types of noncrossing acyclic digraphs specified in
Section~\ref{sec:Classification}.

\paragraph{Concatenate two edge"-covered graphs}

The first four rules simulate the concatenation of two edge"-covered
graphs.
The result of such a concatenation is a connected graph:
\begin{displaymath}
  \INFER[01]{\SEQR{i}{k}}{\GRAPHR{i}{j} & \GRAPHR{j}{k}}
  \quad
  \INFER[02]{\SEQL{i}{k}}{\GRAPHL{i}{j} & \GRAPHL{j}{k}}
  \quad
  \INFER[03]{\SEQM{i}{k}}{\GRAPHR{i}{j} & \GRAPHL{j}{k}}
  \quad
  \INFER[04]{\SEQM{i}{k}}{\GRAPHL{i}{j} & \GRAPHR{j}{k}}
\end{displaymath}
For instance, rule~03 states that the concatenation of a
minmax"-covered graph on the vertices $i, \dots, j$ and an
maxmin"-covered graph on the vertices $j, \dots, k$ yields a
mix"-connected graph on the vertices $i, \dots, k$.

\paragraph{Concatenate an edge"-covered graph and the elementary graph}

The next rules simulate the concatenation of an edge"-covered graph
and the elementary graph.
The result of such a concatenation is an unconnected graph.
There are 4~cases:
\begin{displaymath}
  \INFER[05]{\SEQU{i}{k}}{\GRAPHR{i}{j} & \GRAPHH{j}{k}}
  \quad
  \INFER[06]{\SEQU{i}{k}}{\GRAPHH{i}{j} & \GRAPHR{j}{k}}
  \quad
  \INFER[07]{\SEQU{i}{k}}{\GRAPHL{i}{j} & \GRAPHH{j}{k}}
  \quad
  \INFER[08]{\SEQU{i}{k}}{\GRAPHH{i}{j} & \GRAPHL{j}{k}}
\end{displaymath}

\paragraph{Concatenate a connected graph and an edge"-covered graph}

The following rules simulate the concatenation of a connected graph
and an edge"-covered graph.
The result of such a concatenation is a connected graph.
There are 6 cases; I group them based on the type of the first
argument of the concatenation operation.

\begin{trivlist}
\item\relax \textit{Group~1: The first argument is minmax"-connected}
  \begin{displaymath}
    \INFER[09]{\SEQR{i}{k}}{\SEQR{i}{j} & \GRAPHR{j}{k}}
    \qquad
    \INFER[10]{\SEQM{i}{k}}{\SEQR{i}{j} & \GRAPHL{j}{k}}
  \end{displaymath}

\item\relax \textit{Group~2: The first argument is maxmin"-connected}
  \begin{displaymath}
    \INFER[11]{\SEQM{i}{k}}{\SEQL{i}{j} & \GRAPHR{j}{k}}
    \qquad
    \INFER[12]{\SEQL{i}{k}}{\SEQL{i}{j} & \GRAPHL{j}{k}}
  \end{displaymath}

\item\relax \textit{Group~3: The first argument is mix"-connected}
  \begin{displaymath}
    \INFER[13]{\SEQM{i}{k}}{\SEQM{i}{j} & \GRAPHR{j}{k}}
    \qquad
    \INFER[14]{\SEQM{i}{k}}{\SEQM{i}{j} & \GRAPHL{j}{k}}
  \end{displaymath}
\end{trivlist}

\paragraph{Concatenate a connected graph and the elementary graph}

The next rules simulate the concatenation of a connected graph and the
elementary graph.
The result of such a concatenation is an unconnected graph.
There are 3~cases:
\begin{displaymath}
  \INFER[15]{\SEQU{i}{k}}{\SEQR{i}{j} & \GRAPHH{j}{k}}
  \quad
  \INFER[16]{\SEQU{i}{k}}{\SEQL{i}{j} & \GRAPHH{j}{k}}
  \quad
  \INFER[17]{\SEQU{i}{k}}{\SEQM{i}{j} & \GRAPHH{j}{k}}
\end{displaymath}

\paragraph{Concatenate to an unconnected graph}

The next rules simulate the concatenation to an unconnected graph.
The result of such a concatenation is another unconnected graph.
I consider 3~cases:
\begin{displaymath}
  \INFER[18]{\SEQU{i}{k}}{\SEQU{i}{j} & \GRAPHR{j}{k}}
  \quad
  \INFER[19]{\SEQU{i}{k}}{\SEQU{i}{j} & \GRAPHL{j}{k}}
  \quad
  \INFER[20]{\SEQU{i}{k}}{\SEQU{i}{j} & \GRAPHH{j}{k}}
\end{displaymath}

\paragraph{Cover a graph}

The rules in the final set simulate the cover operations.
The result of such an operation is an edge"-covered graph.
There are 6~cases; I group them based on the direction of the covering
edge.
\begin{trivlist}
\item\relax \textit{Group~1: The covering edge goes from the minimal vertex to the maximal vertex}
  \begin{displaymath}
    \INFER[21]{\GRAPHR{i}{j}}{\SEQR{i}{j}}
    \qquad
    \INFER[22]{\GRAPHR{i}{j}}{\SEQM{i}{j}}
    \qquad
    \INFER[23]{\GRAPHR{i}{j}}{\SEQU{i}{j}}
  \end{displaymath}

\item\relax \textit{Group~2: The covering edge goes from the maximal vertex to the minimal vertex}
  \begin{displaymath}
    \INFER[24]{\GRAPHL{i}{j}}{\SEQL{i}{j}}
    \qquad
    \INFER[25]{\GRAPHL{i}{j}}{\SEQM{i}{j}}
    \qquad
    \INFER[26]{\GRAPHL{i}{j}}{\SEQU{i}{j}}
  \end{displaymath}
\end{trivlist}

This completes the presentation of the rules.

\subsection{Goal Items}

In contrast to the deduction systems of \citet{shieber1995principles},
the proposed tabulation does not have a unique goal item but
7~different goal items, corresponding to the 7~types of noncrossing
acyclic digraphs (Section~\ref{sec:Classification}).
\begin{gather*}
  \GRAPHR{1}{n}
  \quad
  \GRAPHL{1}{n}
  \quad
  \GRAPHH{1}{n}
  \\
  \SEQR{1}{n}
  \quad
  \SEQL{1}{n}
  \quad
  \SEQM{1}{n}
  \quad
  \SEQU{1}{n}
\end{gather*}

\subsection{Properties}

While I shall not provide a complete formal analysis of the
tabulation, I briefly mention some crucial properties:
\begin{itemize}
\item The runtime of the tabulation is in $O(n^3)$ and the space
  required for it is in $O(n^2)$.
  This can be seen by counting the number of possible instances of
  each inference rule and item.

\item The deduction system is \emph{sound}, meaning that for each
  rule, if the statements encoded by the antecedents hold, then the
  statement encoded by the consequent holds as well.
  To see this, one can check the soundness of each rule.

\item The deduction system is \emph{complete}, meaning that every
  noncrossing acyclic digraph can be constructed in a way that can be
  simulated by the inference rules.
  The completeness argument starts from the observation that the
  classification given in Section~\ref{sec:Classification} is
  exhaustive, and then checks for each rule that undoing the operation
  simulated by that rule decomposes a graph represented by the
  consequent item into the graphs represented by the antecedents.

\item Every noncrossing acyclic digraph has a \emph{unique} derivation
  in the deduction system.
  This property is useful because it means that we do not need to
  distinguish between graphs and their derivations.
  In particular, we can count graphs by counting their derivations.
  The uniqueness argument makes use of the observations that the graph
  types distinguished in Section~\ref{sec:Classification} are
  non"-overlapping, and that the backward application of rules is
  deterministic in the sense that for each graph there is at most one
  rule in which this graph appears as the consequent item.
\end{itemize}

\section{Derived Tabulations}

I conclude this note by noting how tabulation techniques for other
classes of noncrossing graphs can be derived from the proposed
technique.

\subsection{Enforcing Weak Connectivity}

To obtain a deduction system for \emph{weakly connected} noncrossing
acyclic digraphs one removes rule 20 (concatenate an unconnected graph
and the elementary graph) and deletes the item for unconnected graphs
from the list of goal items.
Along with this change comes a revised intended interpretation for the
items for unconnected graphs: `It is possible to construct a
noncrossing acyclic digraph on the vertices $i, \dots, j$ that is not
edge"-covered and has exactly two weakly connected components.'
The integer sequence for weakly connected noncrossing acyclic digraphs
is:
\begin{flushleft}
  1, 2, 18, 242, 3890, 69074, 1306466, 25809826, 526358946, 10997782882, \dots
\end{flushleft}

\subsection{Unrestricted Noncrossing Digraphs}

To obtain a deduction system for \emph{unrestricted} (not necessarily
acyclic) noncrossing digraphs, one does away with the items for
minmax"-connected and maxmin"-connected graphs, and deletes all rules
that reference them -- with the exception of rules 01 and 02
(concatenating two edge"-covered graphs with the same directionality
of the covering edge), which should be changed to produce
mix"-connected items.
This yields the following integer sequence for unrestricted
noncrossing digraphs:
\begin{flushleft}
  1, 4, 64, 1792, 62464, 2437120, 101859328, 4459528192, 201889939456, \dots
\end{flushleft}

\subsection{Noncrossing Undirected Graphs}

By removing rules 24--26 (or 21--23), one obtains a tabulation of
noncrossing \emph{undirected} graphs.
This is also known as the class of (undirected) graphs with
pagenumber~1 under a fixed ordering of the vertices along the spine.
This class is counted by A054726 resp.\ A007297 (if additionally one
requires the graph to be connected) in the OEIS \citep{oeis}:
\begin{flushleft}
  1, 1, 2, 8, 48, 352, 2880, 25216, 231168, 2190848, \dots\\
  1, 4, 23, 156, 1162, 9192, 75819, 644908, 5616182, 49826712, \dots
\end{flushleft}

\section*{Acknowledgments}

The decomposition that is the basis for the tabulation presented in
this note was inspired by a counting technique for noncrossing acyclic
digraphs proposed by \citet{tirrell2014number}.
I benefited greatly from discussions with the participants of the
Dagstuhl Seminar 15122 `Formal Models of Graph Transformation in
Natural Language Processing'.

\section*{Document history}

\begin{description}
\item[2014-08-12] First version.
\item[2014-08-13] Add a section on derived tabulations (weakly
  connected noncrossing digraphs, unrestricted noncrossing digraphs).
\item[2015-04-20] Add a mention that the tabulation can be used to
  count the number of noncrossing undirected graphs.
\end{description}

\bibliographystyle{plainnat}
\bibliography{mcqm}

\end{document}


\section{Metrics}
\label{sec:Metrics}

\newcommand{\metrictypeI}[3]
{
  This metric interface directly with the metric available within \textit{#1}.
  The specifications of this metric must be defined within the XML block \xmlNode{#2}.
  This XML node needs to contain the following subnode:

  \begin{itemize}
    \item \xmlNode{metricType}\texttt{#3}\xmlNode{/metricType}, \xmlDesc{vertical bar (\texttt{|}) separated
      string, required field}.
  \end{itemize}

}
\newcommand{\metrictypeII}[3]
{
  \metrictypeI{#1}{#2}{#3}

  In addition to this XML subnode, the users can also specify the weights for given metric:
  \begin{itemize}
    \item \xmlNode{w}, \xmlDesc{comma separated floats, optional parameter}, the weights for each value in \textit{u}
      and \textit{v}. Default is None, which gives each value a weight of 1.0.
  \end{itemize}
}

\newcommand{\metrictypeIII}[3]
{
  \metrictypeI{#1}{#2}{#3}

  In addition to this XML subnode, the users can also specify the weights for given metric:
  \begin{itemize}
    \item \xmlNode{sample\_weight}, \xmlDesc{comma separated floats, optional parameter}, the weights for each value in \textit{u}
      and \textit{v}. Default is None, which gives each value a weight of 1.0.
  \end{itemize}
}

The Metrics block allows the user to specify the similarity/dissimilarity metrics to be used for other
RAVEN entities, such as \textbf{PostProcessors}, and \textbf{HybridModel}.

In the RAVEN input file these metrics are defined as follows:
\begin{lstlisting}[style=XML]
<Simulation>
  ...
  <Metrics>
    ...
    <Metric name='metricName' subType="MetricID">
      ...
     <param1>value</param1>
      ...
    </Metric>
    ...
  </Metrics>
  ...
</Simulation>
\end{lstlisting}

The metrics available in RAVEN can be categorized into several main classes:
\begin{itemize}
  \item \textbf{Paired Distance Metric}, distance metrics between two variables $u$ and $v$, such as \xmlString{euclidean},
    \xmlString{manhattan}, \xmlString{minkowski} and so on.
  \item \textbf{Regression Metric}, measure the regression performance, such as \xmlString{mean\_squared\_error},
    \xmlString{r2\_score}, \xmlString{explained\_variance\_score} and \xmlString{mean\_absolute\_error}.
  \item \textbf{Boolean Metric}, distance metrics between two boolean variables $u$ and $v$, such as
    \xmlString{dice}, \xmlString{hamming}, \xmlString{yule} and so on.
  \item \textbf{Pairwise Metric}, compute the distance or kernel between each pair of the two collections of input
    or observations in n-dimensional space.
    \nb These metrics can be only used in the clustering post-processor of data mining.
  \item \textbf{Other metric}, such as \xmlString{DTW}.
\end{itemize}

The valid \textbf{MetricID}s are: \xmlAttr{SKL}, \xmlAttr{ScipyMetric}, \xmlAttr{DTW}, \xmlAttr{CDFAreaDifference}, \xmlAttr{PDFCommonArea}, and \xmlAttr{DSS}. This XML node requires the following attributes:
\begin{itemize}
  \item \xmlAttr{name}, \xmlDesc{required string attribute}, user-defined name of this metric. \nb As with other
    objects, this name can be used to refer to this specific entity from other input blocks in the XML.
  \item \xmlAttr{subType}, \xmlDesc{required string attribute}, the desired type of Metric to use.
\end{itemize}

\nb If you are using \xmlAttr{ScipyMetric}, please pay more attention on the weight associated with the metric
calculations. Scipy does not normalize the weight during the calculation, and the results can be significant difference
from the normalized weight.

In RAVEN, lots of metrics are interfaces directly coupled with metrics available within \textbf{Scipy} and
\textbf{SciKit-Learn}. In this case, the algorithm for the metrics is choosen by the subnode \xmlNode{metricType}
under the parent node with \xmlAttr{subType} of either \xmlString{SKL} (metric from SciKit-Learn) or
\xmlString{ScipyMetric} (metric from Scipy). For
example, \xmlNode{metricType}\xmlString{paired\_distance|euclidean}\xmlNode{/metricType}.

In the following sub-sections, the input requirements for all of the metrics are presented in the following sections.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% paired_distance metric
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Paired Distance Metric}
\label{subsection:pairedDistance}

\subsubsection{Euclidean}
This metric compute the paired euclidean distances between $u$ and $v$, i.e.
\begin{equation}
  {||u-v||}_2
\end{equation}

\metrictypeI{SciKit-Learn}{SKL}{paired\_distance|euclidean}

\subsubsection{Cosine}
This metric computes the paired cosine distances between $u$ and $v$, i.e.
\begin{equation}
  1 - \frac{u \cdot v}{||u||_2 ||v||_2}
\end{equation}
where $u \cdot v$ is the dot product of $u$ and $v$

\metrictypeI{SciKit-Learn}{SKL}{paired\_distance|cosine}

\subsubsection{Manhattan}
This metric computes the L1 distances between $u$ and $v$, i.e.
\begin{equation}
  \sum_i {\left| u_i - v_i \right|}
\end{equation}

\metrictypeI{SciKit-Learn}{SKL}{paired\_distance|manhattan}

\subsubsection{Braycurtis}
This metric computes the Bray-Curtis distances between $u$ and $v$, i.e.
\begin{equation}
  \sum{|u_i-v_i|} / \sum{|u_i+v_i|}
\end{equation}
The Bray-Curtis distance is in the range $[0, 1]$.
\metrictypeII{Scipy}{ScipyMetric}{paired\_distance|braycurtis}

\subsubsection{Canberra}
This metric computes the Canberra distance between $u$ and $v$, i.e.
\begin{equation}
  d(u,v) = \sum_i \frac{|u_i-v_i|}{|u_i|+|v_i|}
\end{equation}

\metrictypeII{Scipy}{ScipyMetric}{paired\_distance|canberra}

\subsubsection{Correlation}
This metric computes the correlation distance between $u$ and $v$, i.e.
\begin{equation}
  1 - \frac{(u - \bar{u}) \cdot (v - \bar{v})}{{||(u - \bar{u})||}_2 {||(v - \bar{v})||}_2}
\end{equation}
where $\bar{u}$ is the mean of the elements of $u$

\metrictypeII{Scipy}{ScipyMetric}{paired\_distance|correlation}

\subsubsection{Minkowski}
This metric computes the Minkowski distance between $u$ and $v$, i.e.
\begin{equation}
  {||u-v||}_p = (\sum{|u_i - v_i|^p})^{1/p}
\end{equation}

\metrictypeII{Scipy}{ScipyMetric}{paired\_distance|minkowski}

\begin{itemize}
  \item \xmlNode{p}, \xmlDesc{float, required field}, value for the parameter $p$
\end{itemize}

In the RAVEN input file, these metrics are defined as follows:
\begin{lstlisting}[style=XML]
<Simulation>
  ...
  <Metrics>
    <Metric name="euclidean" subType="SKL">
        <metricType>paired_distance|euclidean</metricType>
    </Metric>
    <Metric name="cosine" subType="SKL">
        <metricType>paired_distance|cosine</metricType>
    </Metric>
    <Metric name="manhattan" subType="SKL">
        <metricType>paired_distance|manhattan</metricType>
    </Metric>
    <Metric name="braycurtis" subType="ScipyMetric">
      <metricType>paired_distance|braycurtis</metricType>
    </Metric>
    <Metric name="canberra" subType="ScipyMetric">
        <metricType>paired_distance|canberra</metricType>
    </Metric>
    <Metric name="correlation" subType="ScipyMetric">
        <metricType>paired_distance|correlation</metricType>
    </Metric>
    <Metric name="minkowski" subType="ScipyMetric">
        <metricType>paired_distance|minkowski</metricType>

5

        <w>0.1, 0.1, 0.1, 0.1, 0.1</w>
    </Metric>
  </Metrics>
  ...
</Simulation>
\end{lstlisting}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% regression  metric
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Regression Metric}
\label{subsection:regression}

\subsubsection{Explained variance score}
This metric computes the explained variance regression score, i.e.
\begin{equation}
  1.0 - \frac{Var[u-v]}{Var[u]}
\end{equation}
The best possible score is 1.0, lower values are worse.

\metrictypeIII{Scikit-Learn}{SKL}{regression|explained\_variance\_score}

\subsubsection{Mean absolute error}
This metric computes mean absolute error, a risk metric corresponding to the expected value of the absolute
error loss or \textit{l1}-norm loss.
\begin{equation}
  \frac{1}{n_{samples}}\sum_{i=0}^{n_{samples}-1}|u_i-v_i|
\end{equation}

\metrictypeIII{Scikit-Learn}{SKL}{regression|mean\_absolute\_error}

\subsubsection{Mean squared error}
This metric computes mean square error, a risk metric corresponding to the expected value of the
squared error or loss.
\begin{equation}
  \frac{1}{n_{samples}}\sum_{i=0}^{n_{samples}-1}(u_i-v_i)^2
\end{equation}

\metrictypeIII{Scikit-Learn}{SKL}{regression|mean\_squared\_error}

\subsubsection{R2 score}
This metric computes the coefficient of determination, i.e.
\begin{equation}
  1.0-\frac{\sum_{i=0}^{n_{samples}-1}(u_i-v_i)^2}{\sum_{i=0}^{n_{samples}-1}(u_i-mean[u])^2}
\end{equation}
It provides a measure of how well future samples are likely to be predicted by the model.
Best possible score is 1.0 and it can be negative.

\metrictypeIII{Scikit-Learn}{SKL}{regression|r2\_score}

In the RAVEN input file, these metrics are defined as follows:
\begin{lstlisting}[style=XML]
<Simulation>
  ...
  <Metrics>
    <Metric name="explained_variance_score" subType="SKL">
        <metricType>regression|explained_variance_score</metricType>
        <sample_weight>0.1,0.1,0.1,0.05,0.05</sample_weight>
    </Metric>
    <Metric name="mean_absolute_error" subType="SKL">
        <metricType>regression|mean_absolute_error</metricType>
        <sample_weight>0.1,0.1,0.1,0.05,0.05</sample_weight>
    </Metric>
    <Metric name="r2_score" subType="SKL">
        <metricType>regression|r2_score</metricType>
        <sample_weight>0.1,0.1,0.1,0.05,0.05</sample_weight>
    </Metric>
    <Metric name="mean_squared_error" subType="SKL">
        <metricType>regression|mean_squared_error</metricType>
        <sample_weight>0.1,0.1,0.1,0.05,0.05</sample_weight>
    </Metric>
  </Metrics>
  ...
</Simulation>
\end{lstlisting}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% boolean  metric
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Boolean Metric}
\label{subsection:boolean}

\subsubsection{Dice}
This metric computes the Dice dissimilarity between two boolean variables $u$ and $v$
\begin{equation}
  \frac{c_{TF} + c_{FT}}{2c_{TT} + c_{FT} + c_{TF}}
\end{equation}
where $c_{ij}$ is the number of occurrences of $\mathtt{u[k]} = i$ and $\mathtt{v[k]} = j$ for $k < n$

\metrictypeII{Scipy}{ScipyMetric}{boolean|dice}

\subsubsection{Hamming}
This metric computes the Hamming distance between two boolean variables $u$ and $v$, i.e.
\begin{equation}
  \frac{c_{01} + c_{10}}{n}
\end{equation}
where $c_{ij}$ is the number of occurrences of $\mathtt{u[k]} = i$ and $\mathtt{v[k]} = j$ for $k < n$

\metrictypeII{Scipy}{ScipyMetric}{boolean|hamming}

\subsubsection{Jaccard}
This metric computes the Jaccard-Needham dissimilarity distance between two boolean variables $u$ and $v$, i.e.
\begin{equation}
  \frac{c_{TF} + c_{FT}}{c_{TT} + c_{FT} + c_{TF}}
\end{equation}
where $c_{ij}$ is the number of occurrences of $\mathtt{u[k]} = i$ and $\mathtt{v[k]} = j$ for $k < n$

\metrictypeII{Scipy}{ScipyMetric}{boolean|jaccard}

\subsubsection{Kulsinski}
This metric computes the Kulsinski dissimilarity distance between two boolean variables $u$ and $v$, i.e.
\begin{equation}
  \frac{c_{TF} + c_{FT} - c_{TT} + n}{c_{FT} + c_{TF} + n}
\end{equation}
where $c_{ij}$ is the number of occurrences of $\mathtt{u[k]} = i$ and $\mathtt{v[k]} = j$ for $k < n$

\metrictypeII{Scipy}{ScipyMetric}{boolean|kulsinski}

\subsubsection{Rogerstanimoto}
This metric computes the Rogers-Tanimoto dissimilarity distance between two boolean variables $u$ and $v$, i.e.
\begin{equation}
  \frac{R}{c_{TT} + c_{FF} + R}
\end{equation}
where $c_{ij}$ is the number of occurrences of $\mathtt{u[k]} = i$ and $\mathtt{v[k]} = j$
for $k < n$ and $R = 2(c_{TF} + c_{FT})$

\metrictypeII{Scipy}{ScipyMetric}{boolean|rogerstanimoto}

\subsubsection{Russellrao}
This metric computes the Russell-Rao dissimilarity distance between two boolean variables $u$ and $v$, i.e.
\begin{equation}
  \frac{n - c_{TT}}{n}
\end{equation}
where $c_{ij}$ is the number of occurrences of $\mathtt{u[k]} = i$ and $\mathtt{v[k]} = j$ for $k < n$

\metrictypeII{Scipy}{ScipyMetric}{boolean|russellrao}

\subsubsection{Sokalmichener}
This metric computes the Sokal-Michener dissimilarity distance between two boolean variables $u$ and $v$, i.e.
\begin{equation}
  \frac{R}{S + R}
\end{equation}
where $c_{ij}$ is the number of occurrences of $\mathtt{u[k]} = i$ and $\mathtt{v[k]} = j$ for
$k < n$, $R = 2 * (c_{TF} + c_{FT})$ and $S = c_{FF} + c_{TT}$

\metrictypeII{Scipy}{ScipyMetric}{boolean|sokalmichener}

\subsubsection{Sokalsneath}
This metric computes the Sokal-Sneath dissimilarity distance between two boolean variables $u$ and $v$, i.e.
\begin{equation}
  \frac{R}{c_{TT} + R}
\end{equation}
where $c_{ij}$ is the number of occurrences of $\mathtt{u[k]} = i$ and $\mathtt{v[k]} = j$
for $k < n$ and $R = 2(c_{TF} + c_{FT})$

\metrictypeII{Scipy}{ScipyMetric}{boolean|sokalsneath}

\subsubsection{Yule}
This metric computes the Yule dissimilarity distance between two boolean variables $u$ and $v$, i.e.
\begin{equation}
  \frac{R}{c_{TT} * c_{FF} + \frac{R}{2}}
\end{equation}
where $c_{ij}$ is the number of occurrences of $\mathtt{u[k]} = i$ and $\mathtt{v[k]} = j$ for
$k < n$ and $R = 2.0 * c_{TF} * c_{FT}$

\metrictypeII{Scipy}{ScipyMetric}{boolean|yule}

% TODO: the following metrics require different function interfaces
%  \item From scipy.spatial.distance
%       and $x \cdot y$ is the dot product of $x$ and $y$
%       \item mahalanobis: $\sqrt{ (u-v) V^{-1} (u-v)^T }$ where $V$ is the covariance matrix.  Note that the argument $VI$ is the inverse of $V$
%       \item seuclidean: $\sqrt{\sum {(u_i-v_i)^2 / V[x_i]}}$ where $V$ is the variance vector; $V[i]$ is the variance computed over all the i'th components of the points.
%        If not passed, it is automatically computed.
%       \item sqeuclidean: ${||u-v||}_2^2$

An example of Boolean metric defined in RAVEN is provided below:
\begin{lstlisting}[style=XML]
<Simulation>
  ...
  <Metrics>
    ...
    <Metric name="rogerstanimoto" subType="ScipyMetric">
        <metricType>boolean|rogerstanimoto</metricType>
    </Metric>
    <Metric name="dice" subType="ScipyMetric">
        <metricType>boolean|dice</metricType>
    </Metric>
    <Metric name="hamming" subType="ScipyMetric">
        <metricType>boolean|hamming</metricType>
    </Metric>
    <Metric name="jaccard" subType="ScipyMetric">
        <metricType>boolean|jaccard</metricType>
    </Metric>
    <Metric name="kulsinski" subType="ScipyMetric">
        <metricType>boolean|kulsinski</metricType>
    </Metric>
    <Metric name="russellrao" subType="ScipyMetric">
        <metricType>boolean|russellrao</metricType>
    </Metric>
    <Metric name="sokalmichener" subType="ScipyMetric">
        <metricType>boolean|sokalmichener</metricType>
    </Metric>
    <Metric name="sokalsneath" subType="ScipyMetric">
        <metricType>boolean|sokalsneath</metricType>
    </Metric>
    <Metric name="yule" subType="ScipyMetric">
        <metricType>boolean|yule</metricType>
    </Metric>
    ...
  </Metrics>
  ...
</Simulation>
\end{lstlisting}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Dynamic Time Warping}
\label{subsection:DTW}
The Dynamic Time Warping (DTW) is a distance metrice that is used to measure similarity
between two sequences, i.e. temporal sequences.

The specifications of a DTW distance must be defined within the \xmlNode{Metric} XML block.

This XML node needs to contain the attributes:

\begin{itemize}
  \item \xmlNode{order},          \xmlDesc{int, required field},    order of the DTW calculation: $0$ specifies a classical DTW calculation and $1$ specifies
                                                                    a derivative DTW calculation
  \item \xmlNode{localDistance},  \xmlDesc{string, required field}, the ID of the distance function to be employed to determine the local distance
                                                                    evaluation of two time series. Available options are provided by the Scipy
                                                                    pairwise distances (cityblock, cosine, euclidean, $l1$, $l2$, manhattan,
                                                                    braycurtis, canberra, chebyshev, correlation, dice, hamming, jaccard,
                                                                    kulsinski, mahalanobis, matching, minkowski, rogerstanimoto, russellrao,
                                                                    seuclidean, sokalmichener, sokalsneath, sqeuclidean, yule)
\end{itemize}

An example of Minkowski distance defined in RAVEN is provided below:
\begin{lstlisting}[style=XML]
<Simulation>
  ...
  <Metrics>
    ...
    <Metric name="example" subType="DTW">
      <order>0</order>
      <localDistance>euclidean</localDistance>
    </Metric>
    ...
  </Metrics>
  ...
</Simulation>
\end{lstlisting}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{CDFAreaDifference}
\label{subsubsec:metric_CDFAreaDifference}
This calculates the difference in area between the two CDFs.  This
metric supports using distributions as input.  Other inputs are
converted to a CDF.

\begin{equation}
  \text{CDF area difference} = \int_{-\infty}^{\infty}{\|CDF_a(x)-CDF_b(x)\|dx}
\end{equation}

This metric has the same units as $x$.  The closer the number is
to zero, the closer the match.  A perfect match would be 0.0.

An example is provided below:
\begin{lstlisting}[style=XML]
<Simulation>
  ...
  <Metrics>
    ...
    <Metric name="cdf_diff" subType="CDFAreaDifference"/>
    ...
  </Metrics>
  ...
</Simulation>
\end{lstlisting}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{PDFCommonArea}
\label{subsubsec:metric_PDFCommonArea}
This calculates the common area between the two PDFs.  The higher the
value the closer the PDFs are.  This metric supports distributions as
inputs.  Other inputs are converted to a PDF.

\begin{equation}
  \text{PDF common area} = \int_{-\infty}^{\infty}{\min(PDF_a(x),PDF_b(x))}dx
\end{equation}

A perfect match would be 1.0.

An example is provided below:
\begin{lstlisting}[style=XML]
<Simulation>
  ...
  <Metrics>
    ...
    <Metric name="pdf_area" subType="PDFCommonArea"/>
    ...
  </Metrics>
  ...
</Simulation>
\end{lstlisting}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Pairwise metric
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Pairwise Metric}
\label{subsection:pairwiseMetric}
This calculates the pairwise distance or kernel between each row of the two collections of inputs. This
metric can be only used in the \textbf{DataMining} post-processor.

\subsubsection{Polynomial}
Compute the polynomial kernel between $X$ and $Y$:
\begin{equation}
  K(X, Y) = (gamma <X, Y> + coef0)^{degree}
\end{equation}
\metrictypeI{Scikit-Learn}{PairwiseMetric}{kernel|Polynomial}
In addition to this XML subnode, the users can also specify the following subnodes:
\begin{itemize}
  \item \xmlNode{degree}, \xmlDesc{integer, optional parameter}, default `3'
  \item \xmlNode{gamma}, \xmlDesc{float, optional parameter}, default $1.0/numberColumnsInX$
  \item \xmlNode{coef0}, \xmlDesc{integer, optional parameter}, default `1'
\end{itemize}

\subsubsection{additive\_chi2}
Computes the additive chi-squared kernel between observations in $X$ and $Y$
The chi-squared kernel is computed between each pair of rows in $X$ and $Y$. $X$ and $Y$ have to be non-negative.
This kernel is most commonly applied to histograms.
The chi-squared kernel is given by:
\begin{equation}
  K(x, y) = - Sum [(x - y)^2 / (x + y)]
\end{equation}

\metrictypeI{Scikit-Learn}{PairwiseMetric}{kernel|additive\_chi2}

\subsubsection{chi2}
Computes the exponential chi-squared kernel between observations in $X$ and $Y$
The chi-squared kernel is computed between each pair of rows in $X$ and $Y$. $X$ and $Y$ have to be non-negative.
This kernel is most commonly applied to histograms.
The chi-squared kernel is given by:
\begin{equation}
  K(x, y) = exp(- gamma * Sum [(x - y)^2 / (x + y)])
\end{equation}

\metrictypeI{Scikit-Learn}{PairwiseMetric}{kernel|chi2}
In addition to this XML subnode, the users can also specify the following subnodes:
\begin{itemize}
  \item \xmlNode{gamma}, \xmlDesc{float, optional parameter}, default `1'
\end{itemize}

\subsubsection{cosine\_similarity}
Compute the cosine similarity between $X$ and $Y$:
\begin{equation}
  K(X, Y) = <X, Y> / (||X||*||Y||)
\end{equation}

\metrictypeI{Scikit-Learn}{PairwiseMetric}{kernel|cosine\_similarity}

\subsubsection{laplacian}
Computes the laplacian kernel between observations in $X$ and $Y$
The laplacian kernel is given by:
\begin{equation}
  K(x, y) = exp(- gamma * ||x - y||_1)
\end{equation}
for each pair of rows $x$ in $X$ and $y$ in $Y$.
\metrictypeI{Scikit-Learn}{PairwiseMetric}{kernel|laplacian}
In addition to this XML subnode, the users can also specify the following subnodes:
\begin{itemize}
  \item \xmlNode{gamma}, \xmlDesc{float, optional parameter}, default $1.0/numberColumnsInX$
\end{itemize}

\subsubsection{linear}
computes the linear kernel between $X$ and $Y$
\begin{equation}
  K(X, Y) = X^T * Y
\end{equation}
\metrictypeI{Scikit-Learn}{PairwiseMetric}{kernel|linear}

\subsubsection{rbf}
Computes the laplacian kernel between observations in $X$ and $Y$
The laplacian kernel is given by:
\begin{equation}
  K(x, y) = exp(- gamma * ||x - y||^2)
\end{equation}
for each pair of rows $x$ in $X$ and $y$ in $Y$.
\metrictypeI{Scikit-Learn}{PairwiseMetric}{kernel|rbf}
\begin{itemize}
  \item \xmlNode{gamma}, \xmlDesc{float, optional parameter}, default $1.0/numberColumnsInX$
\end{itemize}

\subsubsection{sigmoid}
Compute the sigmoid kernel between $X$ and $Y$:
\begin{equation}
  K(X, Y) = tanh(gamma <X, Y> + coef0)
\end{equation}
\metrictypeI{Scikit-Learn}{PairwiseMetric}{kernel|sigmoid}
\begin{itemize}
  \item \xmlNode{gamma}, \xmlDesc{float, optional parameter}, default $1.0/numberColumnsInX$
  \item \xmlNode{coef0}, \xmlDesc{integer, optional parameter}, default `1'
\end{itemize}

\subsubsection{Distance Based Metric}

\metrictypeI{Scipy or Scikit-Learn}{PairwiseMetric}{pairwise|`metric'}

\nb \textbf{`metric'}, the distance metric to use, this can be `braycurtis', `canberra', `chebyshev', `correlation',
`cosine', `dice', `euclidean', `hamming', `jaccard', `kulsinski', `matching', `minkowski', `rogerstanimoto',
`russellrao', `sokalmichener', `sokalsneath', `yule', `manhatten'. The definition for each metric can be found
in previous sections.

In addition to this XML subnode, the users can also specify the corresponding parameters for each `metric' according to
previous sections.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Dynamical System Scaling}
\label{subsection:DSS}
The Dynamical System Scaling (DSS) is a distance metrics that is used to measure the separation
between two time-dependent data sets.

The specifications of a DSS metric is defined within the \xmlNode{Metric} XML block. The XML node \xmlAttr{subType} must be \textbf{PPDSS} (see \ref{subsubsec:Validation}) in the \xmlNode{PostProcessor} for the outputs of the post-processor to be in the right format for DSS metric inputs.

An example of DSS  defined in RAVEN is provided below:
\begin{lstlisting}[style=XML]
<Simulation>
  ...
  <Metrics>
    ...
    <Metric name="example" subType="DSS">
    </Metric>
    ...
  </Metrics>
  ...
</Simulation>
\end{lstlisting}


\section{The Measurements}

After predicting what the state will look like at the next timestep, we need a way to check this prediction against the real world. Since we don't know the true values of our state variables unless we're working exclusively in simulation, we can't simply compare them to some ground truth to evaluate our filter's accuracy.

An important step in the EKF cycle is the \textit{Update} phase, in which the current values of all sensors are recorded. Sensors tend to have different update frequencies, so in my code I have a ``buffer'' vector that is updated anytime new sensor values are received from a ROS topic, and on the \textit{Update} step, all values in the buffer are loaded into the actual measurement vector, $\boldsymbol{z}$.

\begin{equation}
    \boldsymbol{z} =
    \begin{pmatrix}
    x & y & \phi & \dot{\phi} & v_l & v_r
    \end{pmatrix} ^T
\end{equation}

These first two entries correspond to the $x$ and $y$ position of the robot. We can't directly measure these, but we can include our GPS measurements in order to give the filter more information to work with. We use the fact that in a small, localized area, GPS coordinates can be linearly converted to meters without requiring complex calculations involving the radius of the earth. We use the website \url{http://www.csgnetwork.com/degreelenllavcalc.html} and enter the coordinates of the venue we will be using. For our simulator, we use the OU football stadium; for the IGVC competition, we looked up the GPS coordinates of the host school, Oakland University. It is very simple to update these values once on-site, as we can use our GPS sensor to grab the longitude and latitude around the center of the course, and use the linked website to acquire new conversion factors. These values appear in my EKF code as \textit{LAT\_TO\_M} and \textit{LON\_TO\_M}.

The next two measured values are the yaw and yaw rate, taken from the IMU. An IMU typically outputs a quaternion, so we use the transformations package to convert this into an euler tuple of yaw, pitch, and roll, which are much more easily human-comprehensible. These are simple to compare to the state, as we're tracking something we can directly measure.

The final two measured values are left and right wheel velocities obtained from encoders on the drive wheels. In our case, the encoders publish linear velocities in m/s, but we convert them to angular velocities using the known wheel radius before saving them as a measurement.

With our measurements obtained, we need a way to compare them to the predictions and update the state. This is where our measurement model comes in.


\chapter{Introduction}

The study of programming languages in Computer Science involves, in large part, the study of type systems. Many of the interesting differences between programming languages lie not in their syntax, but in their semantics; in their behaviour. Since types govern the behaviour of languages, it is fair to say that the difference in type systems between languages forms a large part of what individuals like or dislike about programming in a specific language. Part of why assembly language can be so difficult to reason about at scale is because it is untyped; everything is a byte. C and other higher-level languages introduce \emph{type systems} for the programmer's benefit. With higher levels of abstraction, and more complex type systems, can come greater safety, as well as more predictable program behaviour.

Programming languages have type systems for the main purpose of avoiding errors~\cite{cardellitypes}. A \emph{type error} is an error caused by attempting to perform an operation on something which does not support that specific operation. For example, it makes no logical sense to add the number 3 to a dog. This stems from the fact that ``3'' and ``dog'' support different behaviours\footnote{For instance, dogs can bark, but the number 3 cannot.}. Therefore, in a programming context, ``3'' and ``dog'' could be modelled with distinct types; 3 as a number, and a dog as an animal. By assigning types to values, programmers and the languages they use have a straightforward way to determine the valid operations on a value, and avoid type errors through misuse.

A notable area in which languages differ is \emph{when} they detect type errors. A \emph{static} type system is one in which type errors are detected before the program is run (during compilation), and a \emph{dynamic} type system is one in which type errors are detected while the program is running. A static type system is preferable for runtime safety, since it ensures that any running program will avoid (at least some) type errors.

Of course, as programming languages evolve, many have begun to address more and more errors through the type system. Features similar to optional types have been added to languages such as Java\footnote{\url{https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html}} and C\#\footnote{\url{https://docs.microsoft.com/en-us/dotnet/csharp/nullable-references}}, and languages like Rust have pioneered ways of safely handling dynamic allocation through ownership types\footnote{\url{https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html}}. Many compilers now force the developer to handle classes of errors that previously could only be encountered at runtime, such as null pointer exceptions.

However, \emph{logical errors}, rooted in some (typically domain-specific) behaviour, tend to nimbly evade type systems as they are not general errors that are worthy of exclusion as standard. Runtime features such as exceptions can be leveraged to discover and deal with logical errors and misuse of APIs. Enforcement of domain-specific invariants and rules is typically dynamic; if a check fails, an exception is thrown and potentially handled. However, if a programmer forgets to implement such a check, the program's behaviour can become unpredictable. A 2007 study~\cite{exceptionsusedpoorly} on Java and .NET codebases indicates that exceptions are rarely used to recover from errors, and a 2016 analysis of Java codebases~\cite{badjavaexceptions} reveals that exceptions are commonly misused in Java.

Haskell, a purely functional programming language, has been in use for over 30 years. In that time, it has become a vehicle for programming language research, and is always evolving as a result. In the last 10 years especially, Haskell's type system became a major focus, growing closer and closer to a dependent type system and providing the programmer with tools to express computation through the types of their programs. A type system with \emph{dependent types} is one in which the types themselves depend on runtime values, and can be treated as values within the program. These additions to Haskell's type system extend the language itself in many cases, and are introduced as extensions to the \emph{Glasgow Haskell Compiler} (GHC).

These extensions have utility in real-world programs: we could avoid the aforementioned exception misuse in Haskell by employing logical invariant checks at the type-level, rather than at runtime. Recent versions of GHC support programming at the type level, allowing programmers to compute with types in the same way that languages like C or Python compute with values~\cite{givingpromotion}, using \emph{type families}~\cite{opentfs,closedtfs} that act as functions over types. These computations run at compile time, before the compiler generates an executable of the source code, allowing programmers to transform logical errors into type errors~\cite{twt}.

A growing number of new languages have type systems which support dependent types. The programming language Idris is similar to Haskell, but allows the programmer to pass around types at runtime, and write functions which operate on those types. Many of Haskell's language extensions add to its type system, moving the language closer and closer towards dependently typed programming~\cite{singletons}. Such a type system has obvious benefits, since constraining the types means constraining the values without dynamic runtime checks. For example, in a dependently typed environment, runtime array bounds checks can be eliminated at runtime by limiting the ranges of the input indices through the type system~\cite{dependentarray}.

However, as we explain above, Haskell's type system (though mature) is still evolving; Haskell does not have a fully dependent type system yet. Currently, Haskell imposes separation between values and types; programmers must use GHC extensions in creative ways to work around this separation.

Since they are relatively recent developments, there are few examples of using these extensions to model complex rule sets. It is therefore valuable, for the purpose of evaluating the maturity of these extensions to Haskell's type system, to model complex rule systems. To this end, we present \emph{Chesskell}: a type-level model of the FIDE laws of Chess, with an associated Haskell-Embedded Domain-Specific Language (DSL), for describing games of Chess. This Embedded DSL (EDSL) is modelled on Algebraic Notation, a method of writing down the moves associated with a particular match of Chess. We implement the full, official International Chess Federation (FIDE) ruleset for Chess.

Consider a Pawn (one of the pieces in Chess) which moves from square e2 to square e5, as shown in \cref{badpawnmove}. This move is not allowed in Chess, but a human could accidentally miss such an invalid move. In Chesskell, we express this move as \inline{pawn e2 to e5} and, if we try to compile a game containing only this move with GHC, we receive the following type error from the compiler:

\begin{verbatim}
* There is no valid move from E2 to E5.
The Pawn at E2 can move to: E3, E4.
\end{verbatim}

In fact, if any FIDE 2018 Chess rule is violated, the described game will simply not compile. The type error produced by Chesskell also explains the cause of the problem to the user and suggests corrective action: the Pawn moved to a square that it cannot reach. To rectify the problem, we can move the Pawn to e3 or e4 instead, one of the squares mentioned by the error message. The resulting program then compiles successfully.

\begin{figure}[h]
    \centering
    \vspace*{1cm}
    \fenboard{8/8/8/8/8/8/4P3/8 w - - 0 1}
    \showboard
    \quad
    \fenboard{8/8/8/4P3/8/8/8/8 w - - 0 1}
    \showboard
    \caption{A White Pawn moves from e2 to e5: an invalid move.}
    \label{badpawnmove}
\end{figure}

\section{Related Work}

Chesskell is, at the time of writing, unique; we are aware of no other type-level Chess implementations. There have been allusions to Chess at the type-level through solving the N-queens problem in dependently typed languages, such as Idris\footnote{\url{https://github.com/ExNexu/nqueens-idris}}. The N-queens problem makes use of some Chess rules, including the Queen's attack positions\footnote{A Queen can attack in a straight line in any direction.}; but as the end goal is not to successfully model a game of Chess, it is not a full type-level Chess implementation.

However, Chesskell draws from, and owes much to, many well-established research areas, including type-level rule checking, EDSLs, and Chess programming in general. This section of the report will detail related work, and how Chesskell differs from existing literature.

\subsection{Type-level Rule Checking}

The idea of using types to enforce rules on behaviour is hardly specific to Haskell; after all, C and C-like languages attempt to ensure that you only apply specific operations on values of certain types. The programming language Rust\footnote{\url{https://www.rust-lang.org/}} has been voted the most loved language (by StackOverflow developers) 5 years running\footnote{\url{https://insights.stackoverflow.com/survey/2020\#technology-most-loved-dreaded-and-wanted-languages}}. Rust is touted as a systems language that guarantees memory safety and thread safety; and it achieves this through its type system. By enforcing strict ownership rules, Rust can guarantee that compiling programs avoid data races and that all memory is freed once (and not used after being freed). This is a clear example of types enforcing runtime behaviour; a series of memory safety rules are being enforced. In fact, Haskell type-level constructs can be used to enforce basic ownership rules through a method colloquially known as the ``ST Trick''~\cite{twt}.

Of course, type-level rule checking in Haskell is very possible. Through creative use of types, Lindley and McBride's merge sort implementation~\cite{hasochism} is guaranteed to produce sorted outputs. Unit tests for the sorting implementation become unnecessary, since the GHC type checker is used to ensure that the sort itself behaves correctly. The type system is leveraged to enforce the rule that sorted data should be in sort order.

The above demonstrate the fact that type-level behaviour enforcement is neither new nor specific to Haskell. Though type systems can be complex, since many languages are designed to be general-purpose their type systems are also designed to be so. Chesskell represents an attempt at capturing domain-specific knowledge at the type level, and using that knowledge to maintain safe behaviour. Chesskell, and other type-level behaviour enforcers, are uncommon simply because logic errors are usually dealt with through dynamic checks (it is certainly easier to write dynamic unit tests than it is to model your application domain with types).

\subsection{Haskell-Embedded Domain-Specific Languages}

Despite the apparent lack of work on Chess at the type level specifically, there is work on Haskell-Embedded DSLs in other domains to enforce certain behaviour at compile time. DSLs exist for the purpose of modelling some domain in a language; so Haskell-Embedded DSLs are a natural use case for domain-specific modelling with types. If an EDSL comes with the guarantee that all compiling programs written in that language will not exhibit invalid behaviour, then the EDSL becomes an attractive way to interact with that domain.

Mezzo~\cite{mezzohaskellsymposium} is an EDSL for music composition, which checks if the described piece of music conforms to a given musical ruleset during compilation of the program. For instance, one can apply classical harmony rules to ensure that the piece of music you compose would not go against the rules of that musical period. This EDSL is similar to Chesskell in aim, if not in application domain; performing compile-time checks of rule sets that are commonly checked dynamically. Mezzo is an example of a complex domain with complex rules (classical harmony) being modelled and enforced at the type-level. This is similar to Chesskell's objectives, and was a direct inspiration for the project.

As another example, BioShake~\cite{bioshake} is an EDSL for creating performant bioinformatics computational workflows. The correctness of these workflows is checked during compilation, preventing any from being created if their execution would result in certain errors. For bioinformatics workflows especially, this is ideal since many of these workflows are lengthy. BioShake goes further, however; providing tools to allow parallel execution of these workflows. While it is encouraging to see BioShake and other EDSLs~\cite{aplite} focus on (and achieve) high performance, Chesskell has no such focus. This is primarily because very few parts of the rule-checking process can be parallelised; much of the move handling and order of rule checks must be done sequentially.

\subsection{Chess in Computer Science}

Chess has a rich history as a study area of Computer Science. Getting computers to play Chess was tackled as far back as 1949~\cite{1949chess}, and since then many developments have been made in the field. Chess has been used to educate~\cite{chesseducation}, to entertain, and to test out machine learning approaches~\cite{chessml}. Due to its status as a widely known game of logic, with a well-defined rule set, it is a prime candidate to act as a general setting for programming problems. Indeed, the famous NP-Complete problem referenced above, the N-Queens Problem~\cite{nqueensnp}, relies on the rules of Chess.

Many of these Chess-related programs are written in Haskell, and are publicly available\footnote{\url{https://github.com/mlang/chessIO}}\footnote{\url{https://github.com/nionita/Barbarossa}}. A large number are Chess engines, which take in a board state and output the move(s) which are strongest, and therefore perform move checking at the value-level to ensure that the generated moves are valid. Chesskell differs from these in function, in that the end software does not output a list of strong moves; it simply takes in the moves performed, and states whether they are valid Chess moves or not. We are not aware of any such type-level Chess implementations in Haskell, or any other language.

Game development, as a more general field of Computer Science, has many Chess-based and Chess-related games available. However, the intention in these cases is usually to facilitate real-time play between multiple players (or indeed a single player with a competitive AI), rather than to teach or program a machine to consistently beat players. There is overlap with Chesskell; Chess as a computer game must necessarily perform move validation (to disallow cheating) and ensure that players take turns. However, Chesskell is intended to check over a complete game, rather than to enable people to conduct a game in real-time with Chesskell as a mediator.

\subsection{Why Haskell?}

Given the previous discussion on dependent type systems, and how Haskell is inching towards one, it begs the question; why not use a dependently typed language, like the aforementioned Idris, to develop Chesskell? The simple answer is because it would be trivial. Writing type-level code in Idris (or any other dependently typed language) would be near indistinguishable from writing a Chess validity checker, bundled within an EDSL, at the value-level. Such a feat is both simple and unoriginal.

However, choosing to write Chesskell in Haskell means figuring out how to perform typically value-level computation at the type-level. Indeed, the majority of the code for Chesskell is reusable, since much of it is not specifically about expressing the rules of Chess, but building components to enable complex computation with types. The project is both more difficult, and more interesting, for having been completed in a language without a fully dependent type system.

\section{Objectives} \label{introobjectives}

The objective of this project is to develop a model of Chess at the type level in Haskell, such that the compiler will reject any program that does not describe a valid game of Chess. The primary method of interfacing with this type level model will be via a custom EDSL, through which Chess games are expressed. During compilation, the game of Chess will be simulated, such that any invalid move (or the lack of a move where one should have occurred) will result in a type error. The main goals are thus:

\begin{itemize}
    \item Develop a type-level model of a Chess board;
    \item Develop a type-level move-wise model of a Chess game;
    \item Develop an EDSL to express these type-level Chess games in, which is typed with the type-level model of Chess to enable GHC to validate moves;
    \item Ensure (through testing) that valid Chess games compile, and invalid Chess games do not.
\end{itemize}

We define a ``valid Chess game'' as any game which adheres to the FIDE 2018 Laws of Chess~\cite{lawsofchess}. The FIDE laws also contain rules for the players themselves to adhere to; but these are outside the scope of the project, since they are not directly concerning the game of Chess itself.

The final source code will be made public, as a GitHub repository\footnote{\url{https://github.com/Proxymoron461/3rd-year-project}}. Making the end product open source enables others to make use of and extend the code, should they wish to.


\section{Anti-derivatives}


% ---------------------------------------------------------
% Project: PhD KAPPA
% File: appendix.tex
% Author: Andrea Discacciati
%
% Purpose: Appendix
% ---------------------------------------------------------

\chapter{Supplementary figures}

\begin{sidewaysfigure}
\centering
\includegraphics[width=\linewidth]{figures/appendix_ir_cosm.pdf}
\caption[Incidence rate of prostate cancer in the COSM by calendar year, attained age, and enrollment county]{Incidence rate of prostate cancer in the COSM, conditional on calendar year, attained age, and enrollment county (Västmanland/Örebro). The red line is the model-based predicted incidence rate for Västmanland county. The blue line is the model-based predicted incidence rate for Örebro county. The IRs between the 2 counties are forced to be proportional within calendar year. The $p_{\textrm{heterogeneity}}$ of the $\mathrm{IRR}_{\textrm{Västmanland vs. Örebro}}$ by calendar year was less than 0.001.}
\label{fig:appendix_ir_cosm}
\end{sidewaysfigure}

\begin{figure}[p]
\centering
\includegraphics[width=\linewidth]{figures/smr_cage.pdf}
\caption[Standardized Mortality Ratio of prostate cancer by attained age]{SMRs of prostate cancer by attained age. The solid line is the model-based predicted SMR, while dashed lines are 95\% confidence intervals. The hollow circles represent the observed SMRs by 5-year categories of attained age together with 95\% confidence intervals. The confidence interval for $\SMR_{2, \LargerCdot}$ was not displayed since extremely wide, as it was based on 1 death only. Moreover, given that no deaths were observed in the category 45--49 years of attained age, the graph starts at age 50 years (see Table \ref{table:appendix_smr_table}). The vertical axis is on the natural log scale.}
\label{fig:appendix_smr_cage}
\end{figure}

\begin{figure}[p]
\centering
\includegraphics[width=.8\linewidth]{figures/paper1_30.pdf}
\caption[Associations of BMI at age 30 years with localized, advanced, and fatal prostate cancer]{Multivariable-adjusted associations of BMI at age 30 years (\kgmsq) with IR of localized and advanced prostate cancer, and with MR of fatal prostate cancer in the updated analysis of \citetalias{discacciati_body_2011}. BMI was modeled using RCS with 4 knots (blue line) and linearly (red line).  The referent value was set at 22 \kgmsq. Vertical lines above the curves represent cases of prostate cancer. The vertical axes are on the natural log scale.}
\label{fig:paper1_30}
\end{figure}

\begin{figure}[p]
\centering
\includegraphics[width=\linewidth]{figures/ss_adv1.pdf}
\caption[Study-specific dose--response associations between BMI and incidence of advanced prostate cancer]{Study-specific dose--response associations between BMI and incidence of advanced prostate cancer in the updated meta-analysis including 18 prospective studies. BMI was modeled using RCS with 3 knots positioned at the 10th, 50th, and 90th percentiles of the overall BMI distribution (blue line) and in a linear fashion (red line). Dashed black lines represent the 95\% CI for the RCS models. The vertical axes are on the natural log scale. Figure continued on next page.}
\label{fig:ss_adv}
\end{figure}

\begin{figure}[p]
\centering
\includegraphics[width=\linewidth]{figures/ss_adv2.pdf}
\end{figure}

\begin{figure}[p]
\centering
\includegraphics[width=\linewidth]{figures/fp_adv.pdf}
\caption[Forest plot for the association between BMI and incidence of advanced prostate cancer]{RRs of advanced prostate cancer for every 5-unit increment in BMI for the updated dose--response meta-analysis on 18 prospective studies. The size of each square is proportional to the weight of the study (inverse of within- plus between-study variances)}
\label{fig:fp_adv}
\end{figure}

%--tables
\chapter{Supplementary tables}

\begin{table}
\caption[Observed and expected number of prostate cancer cases in the COSM by calendar year and attained age]{Observed number of incident prostate cancer cases in the COSM by calendar year and attained age (top entry), and expected number of cases obtained by applying Swedish national rates to the COSM calendar-year and age structure (bottom entry).}
\centering
\begin{stlog}
{\input{sir.table.log.tex}\nullskip}
\end{stlog}
\label{table:appendix_sir_table}
\end{table}

\begin{table}
\caption[Observed and expected number of prostate cancer deaths in the COSM by calendar year and attained age]{Observed number of prostate cancer deaths in the COSM by calendar year and attained age (top entry), and expected number of deaths obtained by applying Swedish national rates to the COSM calendar-year and age structure (bottom entry).}
\centering
\begin{stlog}
{\input{smr.table.log.tex}\nullskip}
\end{stlog}
\label{table:appendix_smr_table}
\end{table}

\begin{sidewaystable}[]
\centering
\caption[Associations between categories of BMI at baseline age and localized, advanced, and fatal prostate cancer]{Multivariable-adjusted IRRs of localized and advanced prostate cancer, and MRRs of fatal prostate cancer by categories of BMI at baseline age in the updated analysis of \citetalias{discacciati_body_2011}.}
\label{table:paper1_1997}
\begin{adjustbox}{max width=\textwidth}
\begin{tabular}{lccccccc}
\hline
\multicolumn{8}{c}{{\bf BMI at baseline age, \kgmsq{}}}                                                                                \\ \hline
                                & {\bf \textless 21.0}         & {\bf 21.0--22.9}     & {\bf 23.0--24.9}     & {\bf 25.0--27.4}     & {\bf 27.5--29.9}     & {\bf $\ge$ 30.0}       & {\bf \begin{tabular}[c]{@{}c@{}}For every \\ 5-unit BMI\\ increment\end{tabular}} \\ \hline
{\bf Localized prostate cancer} & \multicolumn{1}{l}{} & \multicolumn{1}{l}{} & \multicolumn{1}{l}{} & \multicolumn{1}{l}{} & \multicolumn{1}{l}{} & \multicolumn{1}{l}{} & \multicolumn{1}{l}{}                                                              \\
No. of cases/person-years       & 84/21,290            & 323/61,897           & 532/115,888          & 651/136,921          & 283/68,009           & 164/42,705           & \multicolumn{1}{l}{}                                                              \\
IRR (95\% CI)                   & 0.77 (0.60--0.98)    & 1 (ref)              & 0.89 (0.77--1.02)    & 0.92 (0.79--1.06)    & 0.80 (0.67--0.95)    & 0.79 (0.64--0.98)    & ---                                                                               \\
                                &                      &                      &                      &                      &                      &                      &                                                                                \\
{\bf Advanced prostate cancer}  &                      &                      &                      &                      &                      &                      &                                                                                \\
No. of cases/person-years       & 30/21,290            & 91/61,897            & 208/115,888          & 202/136,921          & 111/68,009           & 65/42,705            &                                                                                \\
IRR (95\% CI)                   & 0.89 (0.58--1.34)    & 1 (ref)              & 1.25 (0.98--1.61)    & 1.06 (0.82--1.37)    & 1.23 (0.91--1.65)    & 1.35 (0.95--1.92)    & 1.11 (0.96--1.27)                                                                 \\
                                &                      &                      &                      &                      &                      &                      &                                                                                \\
{\bf Fatal prostate cancer}     &                      &                      &                      &                      &                      &                      &                                                                                \\
No. of cases/person-years       & 25/23,153            & 77/68,197            & 136/127,667          & 137/150,490          & 75/74,306            & 45/36,362            &                                                                                \\
MRR (95\% CI)                   & 0.85 (0.54--1.35)    & 1 (ref)              & 1.00 (0.76--1.33)    & 0.92 (0.69--1.23)    & 1.10 (0.78--1.54)    & 1.25 (0.83--1.89)    & 1.12 (0.95--1.32)                                                                 \\ \hline
\end{tabular}
\end{adjustbox}
\end{sidewaystable}

\begin{sidewaystable}[]
\centering
\caption[Associations between categories of BMI at age 30 years and localized, advanced, and fatal prostate cancer]{Multivariable-adjusted IRRs of localized and advanced prostate cancer, and MRRs of fatal prostate cancer by categories of BMI at age 30 years in the updated analysis of \citetalias{discacciati_body_2011}.}
\label{table:paper1_30}
\begin{adjustbox}{max width=\textwidth}
\begin{tabular}{lccccccc}
\hline
\multicolumn{8}{c}{{\bf BMI at age 30 years, \kgmsq{}}}                                                                                \\ \hline
                                & {\bf \textless 21.0} & {\bf 21.0--22.9}     & {\bf 23.0--24.9}     & {\bf 25.0--27.4}     & {\bf 27.5--29.9}     & {\bf $\ge$ 30.0}       & {\bf \begin{tabular}[c]{@{}c@{}}For every \\ 5-unit BMI\\ increment\end{tabular}} \\ \hline
{\bf Localized prostate cancer} & \multicolumn{1}{l}{} & \multicolumn{1}{l}{} & \multicolumn{1}{l}{} & \multicolumn{1}{l}{} & \multicolumn{1}{l}{} & \multicolumn{1}{l}{} & \multicolumn{1}{l}{}                                                              \\
No. of cases/person-years       & 391/81,774           & 714/144,676          & 631/139,388          & 220/59,843           & 61/13,895            & 20/7,133             & \multicolumn{1}{l}{}                                                              \\
IRR (95\% CI)                   & 0.94 (0.82--1.07)    & 1 (ref)              & 0.97 (0.87--1.08)    & 0.88 (0.75--1.04)    & 1.14 (0.87--1.50)    & 0.77 (0.48--1.21)    & 1.00 (0.90--1.12)                                                                 \\
                                &                      &                      &                      &                      &                      &                      &                                                                                \\
{\bf Advanced prostate cancer}  &                      &                      &                      &                      &                      &                      &                                                                                \\
No. of cases/person-years       & 133/81,774           & 247/144,676          & 220/139,388          & 86/59,843            & 14/13,895             & 7/7,133              &                                                                                \\
IRR (95\% CI)                   & 0.97 (0.58--1.34)    & 1 (ref)              & 0.93 (0.77--1.12)    & 0.96 (0.74--1.24)    & 0.74 (0.43--1.29)    & 0.75 (0.35--1.61)    & 0.92 (0.77--1.10)                                                                 \\
                                &                      &                      &                      &                      &                      &                      &                                                                                \\
{\bf Fatal prostate cancer}     &                      &                      &                      &                      &                      &                      &                                                                                \\
No. of cases/person-years       & 103/89,861           & 172/159,460          & 153/152,789          & 50/65,330            & 11/15,145            & 6/7,691              &                                                                                \\
MRR (95\% CI)                   & 1.08 (0.84--1.39)    & 1 (ref)              & 0.94 (0.75--1.17)    & 0.82 (0.59--1.14)    & 0.86 (0.46--1.61)    & 0.98 (0.43--2.26)    & 0.84 (0.67--1.04)                                                                 \\ \hline
\end{tabular}
\end{adjustbox}
\end{sidewaystable}


\section{Line Integral Flowchart}

\begin{figure}[h]
	\centering
	\hspace*{-1.5in}
	\includegraphics[width=\paperwidth]{Images/additionalMaterials/Line_Integral_Flowchart}
\end{figure}

\pagebreak


\chapter{Package MARSS:  Object structures}

\section*{Model objects: class marssMODEL}
Objects of class `marssMODEL'\index{objects!marssMODEL} specify Multivariate Autoregressive State Space (MARSS) models. The \verb@model@ component of an ML estimation object (class marssMLE; see below) is a marssMODEL object. These objects have the following components:

  \begin{description}
    \item[\textbf{data}]{ An optional matrix (not dataframe), in which each row is a time series (time across columns). }
    \item[\textbf{fixed}]{ A list with 8 matrices Z, A, R, B, U, Q, x0, V0, specifying which elements of each parameter are fixed. }
    \item[\textbf{free}]{ A list with 8 matrices Z, A, R, B, U, Q, x0, V0, specifying which elements of each parameter are to be estimated. }
    \item[\textbf{M}]{ An array of dim $n \times n \times T$ (an $n \times n$ missing values matrix for each time point).  Each matrix is diagonal with 0 at the $i,i$ value if the $i$-th value of $\yy$ is missing, and 1 otherwise.}
    \item[\textbf{miss.value}]{ Deprecated. Replace missing values with NAs before passing to MARSS. }
  \end{description}

  The matrices in \verb@fixed@ and \verb@free@ work as pairs to specify the fixed and free elements for each model parameter. The dimensions for \verb@fixed@ and \verb@free@ matrices are as follows, where $n$ is the number of observation time series and $m$ is the number of state processes:
  \begin{description}
    \item[\textbf{Z}]{ n x m }
    \item[\textbf{B}]{ m x m }
    \item[\textbf{U}]{ m x 1 }
    \item[\textbf{Q}]{ m x m }
    \item[\textbf{A}]{ n x 1 }
    \item[\textbf{R}]{ n x n }
    \item[\textbf{x0}]{ m x 1 }
    \item[\textbf{V0}]{ m x m }
  \end{description}

Use \verb@is.marssMODEL()@\index{functions!is.marssMODEL} to check whether an marssMODEL object is correctly specified. The MARSS package includes an \verb@as.marxssMODEL()@\index{functions!as.marssMODEL} method to convert objects of class popWrap (see next section) to objects of class marssMODEL.

\section*{MARSSinputs}\index{objects!inputs}

All the user inputs to a MARSS() call are put into a list and then passed to a function called MARSS.form() (where form is the text specified by the form argument, e.g. MARSS.marss()).  This function is used to create the marssMODEL object and then MARSScheckinputs() is called to error check the other arguments.

  \begin{description}

  \item[\textbf{data}]{ A matrix (not dataframe) of observations (rows) $\times$ time (columns).  }
  \item[\textbf{model}]{ The specification is form dependent.  For the default marxss form, the inputs are a list with up to 14  elements Z, A, R, B, U, Q, x0, V0, C, c, D, d, tinitx, diffuse }
  \item[\textbf{inits}]{ A list with up to 10 matrices Z, A, R, B, U, Q, x0, V0, C, D specifying initial values for parameters. Dimensions are given in the class `marssMODEL' section. }
  \item[\textbf{miss.value}]{ Deprecated. Specifies missing value representation (default is NA). }
  \item[\textbf{method}]{ The method used for estimation: `kem' for EM, `BFGS' for quasi-Newton.}
  \item[\textbf{form}]{ The form to use to interpret the `model' argument and create the marssMODEL object.}
  \item[\textbf{control}]{ List of estimation options. These are method dependent. }
  \end{description}

\section*{ML estimation objects: class marssMLE}\index{objects!marssMLE}

Objects of class marssMLE\index{objects!marssMLE} specify maximum-likelihood estimation for a MARSS model, both before and after fitting. A minimal marssMLE object contains components \verb@model, start@ and \verb@control@, which must be present for estimation by functions like \verb@MARSSkem()@\index{functions!MARSSkem}.

  \begin{description}
    \item[\textbf{model}]{ MARSS model specification (an object of class `marssMODEL'). }
    \item[\textbf{start}]{ List with 7 matrices A, R, B, U, Q, x0, V0, specifying initial values for parameters. Dimensions are given in the class marssMODEL section. }
    \item[\textbf{control}]{ A list specifying estimation options. For \verb@method="kem"@, these are
    \begin{description}
      \item[\textit{minit}]{ Minimum number of iterations in the maximization algorithm. }
      \item[\textit{maxit}]{ Maximum number of iterations in the maximization algorithm. }
      \item[\textit{abstol}]{ Optional tolerance for log-likelihood change.  If log-likelihood decreases less than this amount relative to the previous iteration, the EM algorithm exits. }
      \item[\textit{trace}]{ A positive integer. If not zero, a record will be created of each variable the maximization iterations. The information recorded depends on the maximization method.}
      \item[\textit{safe}]{If TRUE, \verb@MARSSkem()@ will rerun \verb@MARSSkf()@ after each individual parameter update rather than only after all parameters are updated.  }
      \item{\textit{silent}}{ Suppresses printing of progress bar and convergence information. }
    \end{description}
  }
  \end{description}

\verb@MARSSkem()@\index{functions!MARSSkem} appends the following components to the marssMLE' object:

  \begin{description}
  \item[\textbf{method}]{ A string specifying the estimation method (`kem' for estimation by \verb@MARSSkem()@). }
  \item[\textbf{par}]{ A list with 8 matrices of estimated parameter values Z, A, R, B, U, Q, x0, V0. If there are fixed elements in the matrices, the corresponding elements in \verb@$par@ are set to the fixed values.}
  \item[\textbf{kf}]{ A list containing Kalman filter/smoother output. See Chapter \ref{chap:mainfunctions} }
  \item[\textbf{numIter}]{ Number of iterations required for convergence. }
  \item[\textbf{convergence}]{ Convergence status. }
  \item[\textbf{logLik}]{ the exact Log-likelihood. See Section \ref{sec:exactlikelihood}.}
  \item[\textbf{errors}]{ any error messages }
  \item[\textbf{iter.record}]{ record of the parameter values at each iteration (if \verb@control$trace=1@) }
\end{description}

Several functions append additional components to the `marssMLE' object\index{objects!marssMLE} passed in. These include:

  \begin{description}
  \item{\verb@MARSSaic@}{ Appends \verb@AIC, AICc, AICbb, AICbp@, depending on the AIC flavors requested.\index{functions!MARSSaic} }
  \item{\verb@MARSShessian@}{ Appends \verb@Hessian, gradient, parMean@ and \verb@parSigma@.\index{functions!MARSShessian} }
  \item{\verb@MARSSparamCIs@}{ Appends \verb@par.se, par.bias, par.upCI@ and \verb@par.lowCI@.\index{functions!MARSSparamCIs}}
  \end{description}