% 04submersionsimmersionsembeddings.tex
% Fund Science! & Help Ernest finish his Physics Research! : quantum super-A-polynomials - a thesis by Ernest Yeung
%
% http://igg.me/at/ernestyalumni2014
%
% Facebook     : ernestyalumni
% github       : ernestyalumni
% gmail        : ernestyalumni
% google       : ernestyalumni
% linkedin     : ernestyalumni
% tumblr       : ernestyalumni
% twitter      : ernestyalumni
% youtube      : ernestyalumni
% indiegogo    : ernestyalumni
%
% Ernest Yeung was supported by Mr. and Mrs. C.W. Yeung, Prof. Robert A. Rosenstone, Michael Drown, Arvid Kingl, Mr. and Mrs. Valerie Cheng, and the Foundation for Polish Sciences, Warsaw University.

\emph{rank} - dim. of its image \\

\emph{smooth immersions} - whose differentials are injective everywhere \\
\emph{smooth embeddings} - injective smooth immersions that are also homeomorphisms onto their images

\subsection*{Maps of Constant Rank}

Suppose smooth manifolds $M,N$ with or without boundary.

%If smooth $F:M\to N$, rank of $F$ at $p\in M$ to be rank of linear $F_*:T_pM \to T_{F(p)}N$, \, $\text{dim}{\Im{F_*}}$ with $\Im{F_*} \subset T_{F(p)}N$ \\
%If $F$ has same rank $k$ at every pt., $F$ has constant rank, $\text{rank}{F} =k$ \\

\textbf{rank of $F$ at $p$ } - given smooth $F: M \to N$, \, $p\in M$, \\
\quad rank of linear $dF_p : T_pM \to T_{F(p)}N$, i.e. rank of Jacobian of $F$ or dim. of $\text{Im}{ dF_p} \subseteq T_{F(p)}N$ \\
\textbf{constant rank } - if $F$ has same rank $r$ at any pt.

smooth $F:M \to N$ smooth submersion if $F_*$ surjective at every pt.  $\Longleftrightarrow \text{rank}{F} = \text{dim}{N} \quad \, (\text{dim}{M} \geq \text{dim}{N})$ \\
\phantom{smooth $F:M \to N$} smooth immersion if $F_*$ injective at every pt. $\Longleftrightarrow \text{rank}{F} = \text{dim}{M} \quad \, (\text{dim}{M} \leq \text{dim}{N})$

EY : 20150717 I get confused between the rank of $F$ and the rank of $DF$.  I'm going to rewrite the above in my notation:

\begin{tikzpicture}
  \matrix (m) [matrix of math nodes, row sep=3.8em, column sep=4.8em, minimum width=2.2em]
  {
M & N \\
};
  \path[->]
  (m-1-1) edge node [above] {$F$} (m-1-2)
  ;
\end{tikzpicture} \quad \quad \quad \, \begin{tikzpicture}
  \matrix (m) [matrix of math nodes, row sep=3.8em, column sep=4.8em, minimum width=2.2em]
  {
T_pM &  T_{F(p)}N \\
p &  F(p) \\
};
  \path[|->]
  (m-2-1) edge node [above] {$$} (m-1-1)
          edge node [auto]  {$F$} (m-2-2)
  (m-2-2) edge node [auto]  {$$} (m-1-2);
  \path[->]
  (m-1-1) edge node [above] {$DF_p$} (m-1-2);
\end{tikzpicture}

Let \quad \, $\begin{aligned} & \quad \\
 &  \text{dim}M = \text{dim}T_pM = m \\
 &  \text{dim}N = \text{dim}T_{F(p)}N = n
\end{aligned}$

Now $DF_p : T_pM \to \text{im}(DF_p) \subseteq T_{F(p)}N$

Let $r = \text{rank}DF_p = \text{dim}\text{im}(DF_p)$.

$r\leq n$ (clearly, since $\text{im}(DF_p) \subseteq T_{F(p)}N$)

Recall nullity-rank theorem: For linear $T: V \to T(V) = \text{im}T$, \\
\phantom{Recall} $\text{dim}\text{im}T + \text{ker}T = \text{dim}V$ \\
\phantom{Recall} $\Longrightarrow \text{dim}\text{im}T = \text{dim}V - \text{ker}T \leq \text{dim}V$.  \\
$\Longrightarrow r \leq m$

\begin{definition}
        For smooth $F: M \to N$ \\
        \textbf{smooth submersion} $F$ if $dF$ surjective $\Longleftrightarrow  \text{rank}DF_p = \text{dim} T_{F(p)}N$ i.e. $r=n$ \\
        \textbf{smooth immersion} $F$ if $dF$ injective $\Longleftrightarrow  \text{rank}DF_p = \text{dim} T_{p}M$ i.e. $r=m$ \\
\end{definition}

\exercisehead{4.4} cf. \url{http://www.math.ucla.edu/~iacoley/hw/diffhwfall/HW%202.pdf} For $q=F(p)$,

If $DF_p$, $DG_q$ surjective, $DG_q\circ DF_p = D(G\circ F)_p$ surjective.  $G\circ F$ smooth submersion.  \\
If $DF_p$, $DG_q$ injective, $DG_q\circ DF_p = D(G\circ F)_p$ injective.  $G\circ F$ smooth immersion.   \\

It'd be instructive to view this as a commutative diagram.  For

$\begin{aligned} & \quad \\
                 & F: M \to N \\
                 & G : N \to P \\
                 & p \in M \\
                 & q = F(p) \in N \\
                 & G(q) \in P \end{aligned}$ \begin{tikzpicture}
  \matrix (m) [matrix of math nodes, row sep=3.8em, column sep=4.8em, minimum width=2.2em]
  {
T_pM & T_{F(p)}M  &  T_{G(q)}P = T_{G\circ F(p)}P \\
p & F(p) & G(q) \\
};
  \path[->]
  (m-1-1) edge node [above] {$DF_p$} (m-1-2)
  edge[bend left=25] node [above] {$D(G\circ F) = DG_q\circ DF_p$} (m-1-3)
  edge node [auto] {$$} (m-2-1)
  (m-1-2) edge node [above] {$DG_q$} (m-1-3)
  edge node [auto] {$$} (m-2-2)
  (m-1-3) edge node [auto] {$$} (m-2-3)
  (m-2-1) edge node [above] {$F$} (m-2-2)
  edge[bend right=25] node [below] {$G\circ F$} (m-2-3)
  (m-2-2) edge node [above] {$G$} (m-2-3)
;
\end{tikzpicture}

\subsection*{ The Inverse Function Theorem and Its Friends }

\begin{theorem}[7.6] (\textbf{Inverse Function Theorem}). Suppose open $U,V \subset \mathbb{R}^n$, smooth $F: U \to V$ \\
If $DF(p)$ nonsingular, $p \in U$, $\exists \, $ connected neighborhood $\begin{aligned} & \quad \\ & U_0 \subset U \ni p \\ & V_0 \subset V \ni F(p) \end{aligned}$

s.t. $\left. F \right|_{U_0} : U_0 \to V_0$ diffeomorphism.
\end{theorem}

Let $X$ metric space.  $G:X \to X$ contraction if $\exists \, \lambda <1$ s.t. $d(G(x), G(y)) \leq \lambda d(x,y)$, \, $\forall \, x, y \in X$.  \\
Clearly, $\forall \, $ contraction is cont.

\begin{lemma}[7.7] (Contraction Lemma)
Let $X$ complete metric space \\
$\forall \,$ contraction $G: X \to X$, \, $\exists \, !$ fixed pt., i.e. $x\in X$ s.t. $G(x) = x$
\end{lemma}

\begin{theorem}[7.9] (Implicit Function Theorem)
  Let open $U \subset \mathbb{R}^n \times \mathbb{R}^k$, $(x,y) = (x^1 \dots x^n, y^1 \dots y^k)$ coordinates on $U$.  \\

Suppose $\Phi : U \to \mathbb{R}^k$ smooth.  $(a,b) \in U$, $c = \Phi(a,b)$

If $k\times k$ matrix
\[
\frac{ \partial \Phi^i }{ \partial y^j }(a,b)
\]
nonsingular, \\
then $\exists \, $ neighborhoods $\begin{aligned} & \quad \\
  & V_0 \subset \mathbb{R}^n \\
  & W_0 \subset \mathbb{R}^k \end{aligned}$,  \\
smooth $F: V_0 \to W_0$ s.t. \\
$(\Phi^{-1}(c) ) V_0 \times W_0$ is the graph of $F$, i.e. $\Phi(x,y) = c$, $\forall \, (x,y) \in V_0 \times W_0$ iff $y= F(x)$

\end{theorem}

\subsection*{Embeddings}

\begin{definition}
\textbf{smooth embedding} of $M$ into $N$, $F$, if \\
\phantom{ \quad \, } smooth immersion $F: M\to N$ and \\
\phantom{ \quad \quad \, } $F$ topological embedding i.e. $F$ homeomorphism onto its image $F(M) \subseteq N$ in subspace topology.

\end{definition}

\exercisehead{4.16}

Let $\begin{aligned} & \quad \\
    & F : M \to N \\
    & G:N \to P \end{aligned}$.  \\
$F,G$ smooth immersions so $G\circ F$ smooth immersion (cf. Exercise 4.4, idea is composition of $DF, DG$ is injective).  \\
Now $(G \circ F)(M) = G(F(M))$ \\
$F,G$ bijective onto $F(M)$, $G(N)$.  $G$ bijective on $F(M) \subseteq N$ onto $G(F(M))$.  Then $G\circ F$ bijective on $M$ onto $G(F(M))$ \\
$F,G$ cont., so $G\circ F $ cont.  \\
$F^{-1},G^{-1}$ cont., so $(G\circ F)^{-1}= F^{-1} \circ G^{-1}$ cont.  \\
$G\circ F$ homeomorphism onto $G\circ F(M) \subseteq P$.

So $G\circ F$ is a smooth embedding.

\begin{proposition}[4.22]
        Suppose smooth manifolds $M,N$, with or without boundaries, and \\
injective smooth immersion $F:M\to N$

If any of the following holds, then $F$ is a smooth embedding.
\begin{enumerate}
        \item[(a)] $F$ open or closed map
        \item[(b)] $F$ proper map
        \item[(c)] $M$ compact
        \item[(d)] $M$ has empty boundary and $\text{dim}M = \text{dim}N$
\end{enumerate}
\end{proposition}


\documentclass{memoir}
\usepackage{notestemplate}

%\logo{~/School-Work/Auxiliary-Files/resources/png/logo.png}
%\institute{Rice University}
%\faculty{Faculty of Whatever Sciences}
%\department{Department of Mathematics}
%\title{Class Notes}
%\subtitle{Based on MATH xxx}
%\author{\textit{Author}\\Gabriel \textsc{Gress}}
%\supervisor{Linus \textsc{Torvalds}}
%\context{Well, I was bored...}
%\date{\today}

%\makeindex

\begin{document}

% \maketitle

% Notes taken on 05/28/21

\section{Characteristic and Minimal Polynomials}
\label{sec:characteristic_and_minimal_polynomials}

\subsection{Cayley-Hamilton Theorem}
\label{subsec:cayley_hamilton_theorem}

\begin{defn}[Characteristic Polynomial]
	Let \(V\) be a vector space and \(T\) an operator on \(V\). Let \(\lambda_1,\ldots,\lambda_m\) be the distinct eigenvalues of \(T\) with multiplities \(d_1,\ldots,d_m\). Then we denote the \textbf{characteristic polynomial} of \(T\) by
	\begin{align*}
		(x-\lambda_1)^{d_1} \ldots (x-\lambda_m)^{d_m}.
	\end{align*}
\end{defn}
The characteristic polynomial turns out to be a convenient characterization and a powerful tool.

\begin{prop}
	Let \(V\) be a vector space, \(T\) an operator on \(V\), and \(q\) the characteristic polynomial of \(T\). Then \(q\) has degree \(\textrm{dim}(V)\) and the zeroes of \(q\) are exactly the eigenvalues of \(T\).
\end{prop}
This trivially holds by the definition. Note that now we need to make an important distinction-- if \(V\) is a real-valued vector space instead of a complex vector space, then the eigenvalues of \(T\) are instead the real zeroes of \(q\). We need to make a couple adjustments along the way for these kinds of cases.

\begin{thm}[Cayley-Hamilton Theorem]
	Let \(V\) be a vector space, \(T\) an operator on \(V\), and \(q\) the characteristic polynomial of \(T\). Then \(q(T) = 0\).
\end{thm}

\begin{proof}[Cayley-Hamilton]

\end{proof}

\subsection{Minimal Polynomial}
\label{subsec:minimal_polynomial}

\begin{defn}[Minimal Polynomial]
	Suppose \(T \in \mathcal{L}(V)\). Then there is a unique monic polynomial \(p\) such that \(p(T) = 0\). We refer to \(p\) as the \textbf{minimal polynomial}.
\end{defn}
If there is a non-monic polynomial \(q\) such that \(q(T)=0\), then \(q = ps\) for some polynomial \(s\). Of course, the reverse holds as well.

\begin{prop}
	Let \(V\) be a vector space and \(T\) an operator over \(V\). Then the characteristic polynomial of \(T\) is a polynomial multiple of the minimal polynomial of \(T\).
\end{prop}
Furthermore, we have that the zeroes of the minimal polynomial of \(T\) are precisely the eigenvalues of \(T\). This makes it clear that our minimal polynomial looks similar to our characteristic polynomial of \(T\), but with smaller exponents.

% \printindex
\end{document}


\section{Motivation \& Background}

\begin{frame}[t]{The probability distribution revolution}
	\begin{multicols}{2}
		\begin{itemize}
			\item Karl Pearson (1857-1936) came with the idea that scientific measurements should be conceived as coming from probability distributions.
			\item Scientific measurements are just random reflections of the underlying truth that is the distribution.
			\item “A great book on the
history of statistics” $\rightarrow$ Aaron
			\item
		\end{itemize}

		\columnbreak

		\includegraphics[width=0.25\textwidth]{media/distribution}
		\linebreak
		\includegraphics[width=0.25\textwidth]{media/book}
	\end{multicols}

	\note{Lets start with a bit of history. The idea that scientific measurements are best understood as reflecting underlying probabilities distributions is a relatively new idea.

It was a now famous thinker and scientist, Karl Pearson (of the Pearson correlation coefficient) who conceived the idea in late 18 hundreds.

He realized randomness was inherent part of nature and of scientific measure, and he formulated the idea that all measurments should be conceived of as coming from an underlying probability distributions.

In other words, the underlying truth is the distrubutions, and the measurements are just random reflections of this truth.  At the time, this was a revolutionary idea.}
\end{frame}

\begin{frame}[t]{The power of probability distributions}
	Distributions allow scientists to:
	\begin{itemize}
		\item Understand scientific measurement
		\item Predict the probability of specific data
		\item Test specific hypothesis (p-values)
		\item Produce generative models
		\item Better conceptual understanding data.
	\end{itemize}
	\note{And it was an idea that revolutized science.

	It allowed scientists to:
	\begin{itemize}
		\item Better understand their measurements.
		\item To make predictions about what data they should expect to observe.
		\item To test scientific hypotheses in a mathematically rigorous way.
		\item To build generative models of their data, and to test how well those models explain the observed measurments.
		\item And in general to have a better conceptual understanding of the data they generated.
	\end{itemize}
}
\end{frame}
%--- Next Frame ---%

\begin{frame}[t]{Estimating distributions from data}
	\begin{multicols}{2}
		Low-Dimensional:
		\begin{itemize}
			\item Great tools to fit and understand the underlying probability distribution of data.
		\end{itemize}
		\vfill\columnbreak
		High-Dimensional:
		\begin{itemize}
			\item In some cases, classical statistical tools are insufficient.
			\item Problematic for modern neuroscience: \begin{itemize}
				\item Thousands of electrodes.
				\item Millions of voxels.
			\end{itemize}
		\end{itemize}
	\end{multicols}
	\note{Since Pearson’s early work, scientists and statisticians have devised an enormous number of related tools.

For example they’ve defined many many distributions, and they’ve created tools for working with those distrubitons (calculating likelihoods and fitting them).

One class of tools aim to estimate the underlying distribution that generated an observed empirical measurment.

These tools are highly effective when data is low dimensional, but they are sometimes insufficient when data is high dimensional.}
\end{frame}
%--- Next Frame ---%

\begin{frame}[t]{How can we build statistical distributions for neuroscience datasets?}
	\movie[]{\includegraphics[width=0.7\textwidth,center]{media/zfish_first.png}}{media/zfish_imaging.mp4}
	\nakedfootnote{\url{https://www.youtube.com/watch?v=CXYp9xCUhe0}}
	\note{For example, consider whole brain imaging data from the zebrafish.  This data can have millions of dimensions, which makes estimating the understanding joint probability distribution difficult.  The number of possible states is enormous.  The voxels are not independent.  You can’t simply make a histogram or a heat-map.
			}
\end{frame}


\section{The Type Theory}
\label{sec:type-theory}

One challenge in writing this paper is to extricate our account of datatypes from what else is new in Epigram 2. In fact, we demand relatively little from the setup, so we shall start with a `vanilla' theory and add just what we need. The reader accustomed to dependent types will recognise the basis of her favourite system; for those less familiar, we try to keep the presentation self-contained.

\subsection{Base theory}

\begin{wstructure}
<- Presentation of the formalism
    <- Standard presentation
        -> No novelty here
    <- 3 judgments [equation]
        -> Context validity
        -> Typing judgements
        -> Equality judgements
\end{wstructure}

We adopt a traditional presentation for our type
theory, with three mutually defined systems of judgments:
\emph{context validity}, \emph{typing}, and \emph{equality},
with the following forms:
%
\[
\begin{array}{ll}
\G \vdash \Valid                & \mbox{\(\G\) is a valid context, giving types to variables} \\
\G \vdash \Bhab{\M{t}}{\M{T}}           & \mbox{term \(\M{t}\) has type \(\M{T}\) in context \(\G\)} \\
\G \vdash \Bhab{\M{s} \equiv \M{t}}{\M{T}}  & \mbox{\(\M{s}\) and \(\M{t}\) are equal at type \(\M{T}\) in context \(\G\)} \\
\end{array}
\]

\begin{wstructure}
    <- Invariants [equation]
        -> By induction on derivations
\end{wstructure}

The rules are formulated to ensure that the
following `sanity checks' hold by induction on derivations
%
\[
\begin{array}{l@{\;\Rightarrow\;\;}l}
\G            \vdash \Bhab{\M{t}}{\M{T}}
    & \G \vdash \Valid\; \wedge\; \G\vdash\Type{\M{T}} \\
\G            \vdash s \equiv \Bhab{\M{t}}{\M{T}}
    & \G \vdash \Bhab{s}{T} \;\wedge\; \G\vdash \Bhab{\M{t}}{\M{T}}
\end{array} \]
%
and that judgments \(\M{J}\) are preserved by well-typed instantiation.
%
\[
\G ; \xS ; \Delta \vdash \M{J}            \;\Rightarrow\;
    \G \vdash \Bhab{\M{s}}{\M{S}} \;\Rightarrow\;
          \G ; \Delta[\M{s}/\x] \vdash \M{J}[\M{s}/\x]
\]

%We are not going to prove the validity of these invariants. They
%follow rather straightforwardly from the induction rules. For formal
%proofs, we refer the reader to standard presentations of type theory,
%such as Luo's seminal work \cite{luo:utt}.

\begin{wstructure}
    <- Judgemental equality
        <- Presentation independent of particular implementation choice
        -> Model in Agda, intensional
        -> Used in Epigram, OTT
\end{wstructure}

We specify equality as a judgment, leaving open the details of its implementation, requiring only a congruence including ordinary computation (\(\beta\)-rules), decided, e.g., by testing \(\alpha\)-equivalence of \(\beta\)-normal forms~\cite{DBLP:journals/jfp/Adams06}. Coquand and Abel feature prominently in a literature of richer equalities, involving \(\eta\)-expansion, proof-irrelevance and other attractions~\cite{DBLP:journals/scp/Coquand96,DBLP:conf/tlca/AbelCP09}. Agda and Epigram 2 support such features, Coq currently does not, but they are surplus to requirements here.

% Therefore, we are not tied to a particular implementation
%choice. In particular, our system has been modelled in Agda, which
%features an intensional equality. On the other hand, it is used in
%Epigram, whose equality has a slightly extensional
%flavor~\cite{altenkirch:ott}. We expect users of fully extensional
%systems to also find their way through this presentation.

\begin{wstructure}
<- Context validity [figure no longer]
    <- Not much to be said
\end{wstructure}

Context validity ensures that variables inhabit well-formed
sets.
%
\[
%% Empty context validity
\Axiom{\vdash \Valid}
\qquad
%% Extend context
\Rule{\G       \vdash \Type{\M{S}}}
     {\G ; \xS \vdash \Valid}\;\x\not\in\G
\]
%
\begin{wstructure}
<- Typing judgements [figure]
    <- Set in Set
        -> For simplicity of presentation
        -> Assume that a valid stratification can be inferred
            <- Harper-Pollack, Luo, Courant
        -> See later discussion
    <- Standard presentation of Pi and Sigma types
\end{wstructure}
%
The basic typing rules
% (Fig.~\ref{fig:typing-judgements})
for tuples and functions are also standard, save that we locally adopt
\(\Set:\Set\) for presentational purposes. Usual techniques to resolve
this \emph{typical ambiguity} apply~\cite{harper:implicit-universe,
  luo:utt, courant:explicit-universe}. A formal treatment of
stratification for our system is a matter of
ongoing work.
%%  putting presentation before paradox~\cite{girard:set-in-set}.
%% The usual remedies apply, \emph{stratifying}
%% \(\Set\)~\cite{harper:implicit-universe, luo:utt,
%%   courant:explicit-universe}.
%%
\input{figure_typing_judgements}

\paragraph{Notation.} We subscript information needed for type synthesis
but not type checking, e.g., the domain of a \(\LAMBINDER\)-abstraction,
and suppress it informally where clear. Square brackets denote tuples,
with a LISP-like right-nesting convention: \(\sqr{a\;b}\) abbreviates
\(\pair{a}{\pair{b}{\void}{}}{}\).

%We recognise the standard presentation of $\Pi$ and $\Sigma$
%types, respectively inhabited by lambda terms and dependent
%pairs. Naturally, there are rules for function application and
%projections of $\Sigma$-types. Equal types can be substituted, thanks
%to the conversion rule.

%For the sake of presentation, we postulate a $\Set$ in $\Set$
%rule. Having this rule makes our type theory inconsistent, by Girard's
%paradox~\cite{girard:set-in-set}. However, it has been
%shown~\cite{harper:implicit-universe, luo:utt,
%  courant:explicit-universe} that a valid stratification can be
%inferred, automatically or semi-automatically. In the remaining of our
%presentation, we will assume that such a stratification exists, even
%though we will keep it implicit. We shall discuss this assumption in
%Section~\ref{sec:discussion}.

%\begin{figure}
%
%\input{figure_typing_judgements}
%
%\caption{Typing judgements}
%\label{fig:typing-judgements}
%
%\end{figure}

\begin{wstructure}
<- Judgemental equality [figure]
    <- symmetry, reflexivity, and transitivity
    <- beta-rules for lambda and pair
    <- xi-rule for functions
    -> Agnostic in the notion of equality
        <- Doesn't rely on a ``propositional'' equality
        -> Key: wide applicability of our proposal
\end{wstructure}

The judgmental equality comprises the computational rules below,
closed under reflexivity,
symmetry, transitivity and structural congruence, even under binders.
We omit the mundane rules which ensure these closure properties for
reasons of space.
\input{figure_judgemental_equality}
Given a suitable stratification of \(\Set\), the
computation rules yield a terminating evaluation procedure, ensuring
the decidability of equality and thence type checking.

%Finally, we define the rules governing judgemental equality in
%Figure~\ref{fig:judgemental-equality}. We implicitly assume that
%judgemental equality respects symmetry, reflexivity, and
%transitivity. We capture the computational behavior of the language
%through the $\beta$-rules for function application and pairs. Finally,
%we implicitly assume that it respects purely syntactic and structural
%equality. This includes equality under lambda ($\xi$-rule).

%Crucially, being judgemental, this presentation is agnostic in the
%notion of equality actually implemented. Indeed, our typing and
%equality judgements do not rely on a ``propositional'' equality. This
%freedom is a key point in favour of the wide applicability of our
%proposal. This judgemental presentation must be read as a
%\emph{specification}: our proposal works with any propositional
%equality satisfying this specification. Moreover, our lightweight
%requirements do not endanger decidability of equality-checking.
%Obviously, when implementing our technology in an existing
%type-theory, some opportunities arise. We will present some of them
%along the course of the paper.

%\begin{figure}

%\input{figure_judgemental_equality}
%
%\caption{Judgemental equality}
%\label{fig:judgemental-equality}
%
%\end{figure}

\begin{wstructure}
!!! Need Help !!!
<- Meta-theoretical properties
    <- Assuming a stratified discipline
    <> The point here is to reassert that dependent types are not evil,
       there is no non-terminating type-checker, or such horrible lies <>
    -> Strongly normalising
        -> Every program terminates
    -> Type-checking terminates
    ???
\end{wstructure}

%This completes our presentation of the type theory. Assuming a
%stratified discipline of universe, the system we have described enjoy
%some very strong meta-theoretical properties. Unlike simply typed
%languages, such as Haskell, dependently-typed systems are
%\emph{strongly normalising}: every program that type-checks
%terminates. Moreover, type-checking is decidable and can therefore be
%implemented by a terminating algorithm.
%\note{Need some care here. Expansion would be good too. I wanted to
%  carry the intuition that we are not the bad guys with a
%  non-terminating type-checker.}

\subsection{Finite enumerations of tags}
\label{sec:finite-sets}

\begin{wstructure}
<- Motivation
    <- Finite sets could be encoded with Unit and Bool
        /> Hinder the ability to name things
    <- W-types considered harmful?
        ???
    -> For convenience
        <- Named elements
        <- Referring by name instead of code
        -> Types as coding presentation
            /> Also as coding representation!
\end{wstructure}

It is time for our first example of a \emph{universe}. You might
want to offer a choice of named constructors in your datatypes: we shall
equip you with sets of tags to choose from. Our plan
is to implement (by extending the theory, or by encoding) the signature
%
\[
  \Type{\EnumU}\qquad \Type{\EnumT{(\Bhab{\M{E}}{\EnumU})}}
\]
%
where some value \(E:\EnumU\) in the `enumeration universe' describes
a type of tag choices \(\EnumT{E}\). We shall need
some tags---valid identifiers, marked to indicate that
they are data, not variables scoped and substitutable---so we hardwire these
rules:
%
\[
%% UId
\Rule{\Gamma \vdash \Valid}
     {\Gamma \vdash \Type{\UId}}
\qquad
%% Tag
\Rule{\Gamma \vdash \Valid}
     {\Gamma \vdash \Bhab{\Tag{\V{s}}}{\UId}}\;\V{s}\: \mbox{a valid identifier}
\]
%
Let us describe enumerations as lists of tags, with signature:
%
\[
\Bhab{\NilE}{\EnumU}\qquad
\Bhab{\ConsE{(\Bhab{\M{t}}{\UId})}{(\Bhab{\M{E}}{\EnumU})}}{\EnumU}
\]
%
What are the \emph{values} in \(\EnumT{E}\)? Formally, we represent
the choice of a tag as a numerical index into \(E\), via new rules:
%
\[
%% Ze
\Rule{\Gamma \vdash \Valid}
     {\Gamma \vdash \Bhab{\Ze}{\EnumT{(\ConsE{\M{t}}{\M{E}})}}}
\qquad
%% Su
\Rule{\Gamma \vdash \Bhab{\M{n}}{\EnumT{\M{E}}}}
     {\Gamma \vdash \Bhab{\Su{\M{n}}}{\EnumT{(\ConsE{\M{t}}{\M{E}})}}}
\]
%
However, we expect that in practice, you might rather refer to these
values \emph{by tag}, and we shall ensure that this is possible in due course.

%As a motivating example, we are now going to extend the type theory
%with a notion of finite set. One could argue that there is no need for
%such an extension: finite sets, just as any data-structure, can be
%encoded inside the type theory. A well-known example of such encoding
%is the Church encoding of natural numbers, which is isomorphic to
%finite sets. \note{Shall we talk about W-types encoding?}

%However, using encodings is impractical. In the case of finite sets,
%for instance, we would like to name the elements of the sets. Then, we
%need to be able to manipulate these elements by their name, instead of
%their encoding. While we are able to give names to encodings, it is
%extremely tedious to map the encodings back to a name. Whereas these
%objects have a structure, the structure is lost during the encoding,
%when they become anonymous inhabitants of a $\Pi$ or $\Sigma$-type.

%In the simply-typed world, we are used to see types as a coding
%presentation -- presentation of invariants, presentation of
%properties. In the dependently-typed world, we also learn to use types
%as a coding representation: finite sets being good citizens, they
%ought to be democratically represented at the type level. As we will
%see, this gives us the ability to name and manipulate them (this is
%were the democracy analogy goes crazy, I think).
%\note{Did I got the coding presentation vs. coding representation
%  story right? No.}

\begin{wstructure}
<- Implementation [figure]
    <- Tags
        -> Purely informational token
    <- EnumU
        -> Universe of finite sets
    <- EnumT e
        -> Elements of finite set e
\end{wstructure}

%The specification of finite sets is presented in
%Figure~\ref{fig:typing-finite-set}. It is composed of three
%components. First, we define tags as inhabitants of the $\UId$ type. A
%tag is solely an informative token, used for diagnostic
%purposes. Finite sets inhabits the $\EnumU$ type. Unfolding the
%definition, we get that a finite set is a list of tags. Finally,
%elements of a finite set $\V{u}$ belong to the corresponding $\EnumT{\V{u}}$
%type. Intuitively, it corresponds to an index -- a number -- pointing
%to an element of $\V{u}$.

%\begin{figure}

%\input{figure_finite_sets}

%\caption{Typing rules for finite sets}
%\label{fig:typing-finite-set}

%\end{figure}

\begin{wstructure}
<- Equipment
    <- \spi operator
        <- Equivalent of Pi on finite sets
        <- First argument: (finite) domain
        <- Second argument: for each element of the domain, a co-domain
        -> Inhabitant of \spi: right-nested tuple of solutions
            <- Skip code for space reasons
    <- switch operator
        <- case analyses over x
        <- index into the \spi tuple to retrieve the corresponding result
\end{wstructure}

Enumerations come with further machinery. Each \(\EnumT{E}\) needs an
eliminator, allowing us to branch according to a tag choice. Formally,
whenever we need such new computational facilities, we add primitive
operators to the type theory and extend the judgmental equality with
their computational behavior. However, for compactness and readability, we
shall write these operators as functional programs (much as we
model them in Agda).

We first define the `small product' $\SYMBspi$ operator:
%
\[\stk{
%% spi
\spi{}{}: \PITEL{\V{E}}{\EnumU}\PITEL{\V{P}}{\EnumT{\V{E}} \To \Set} \To \Set \\
\begin{array}{@{}l@{\:}l@{\;\;\mapsto\;\;}l}
\spi{\NilE}{& \V{P}}        & \Unit \\
\spi{(\ConsE{\V{t}}{\V{E}})}{& \V{P}} & \TIMES{\V{P}\: \Ze}{\spi{\V{E}}{\LAM{\V{x}} \V{P}\: (\Su{\V{x}})}}
\end{array}
}\]
%
This builds a right-nested
tuple type, packing a $\V{P}\:\V{i}$ value for each $\V{i}$ in the given
domain. The step case exposes our notational convention that
binders scope rightwards as far as possible. These tuples are `jump tables', tabulating dependently
typed functions.
We give this functional
interpretation---the eliminator we need---by the
$\SYMBswitch$ operator, which, unsurprisingly, iterates projection:
%
\[\stk{
%% switch
\begin{array}{@{}ll}
\SYMBswitch : \PITEL{\V{E}}{\EnumU}
               \PITEL{\V{P}}{\EnumT{\V{E}} \To \Set} \To
              \spi{\V{E}}{\V{P}} \To
               \PITEL{\V{x}}{\EnumT{\V{E}}} \To \V{P}\: \x
\end{array} \\
\begin{array}{@{}l@{\:\mapsto\:\:}l}
\switch{(\ConsE{\V{t}}{\V{E}})}{\V{P}}{\V{b}}{\Ze}      & \fst{\V{b}} \\
\switch{(\ConsE{\V{t}}{\V{E}})}{\V{P}}{\V{b}}{(\Su{\V{x}})} & \switch{\V{E}}{(\LAM{\V{x}} \V{P}
  (\Su{\V{x}}))}{(\snd{\V{b}})}{\V{x}}
\end{array}
}\]

%Again, there is a clear equivalent in the full-$\Set$ world: function
%application. The operational behaviour of $\F{switch}$ is
%straightforward: $\V{x}$ is peeled off as we move deeper inside the nested
%tuple $\V{b}$. When $\V{x}$ equals $\Ze$, we simply return the value we are
%pointing to.

\begin{wstructure}
<- Equivalent to having a function space over finite sets
    /> Made non-obvious by low-level encodings
        <- General issue with codes
             -> Need to provide an attractive presentation to the user
    -> Types seem to obfuscate our reading
        <- Provide ``too much'' information
        /> False impression: information is actually waiting to be used more widely
        -> See next Section
\end{wstructure}

The $\SYMBspi$ and $\SYMBswitch$ operators deliver dependent
elimination for finite enumerations, but are rather awkward to
use directly. We do not write the range for a \(\LAMBINDER\)-abstraction, so
it is galling to supply \(\V{P}\) for functions defined by $\SYMBswitch$.
Let us therefore find a way to recover the tedious details of the
encoding from types.

%, they also
%come with a notion of finite function space. However, we had to
%extract that intuition from the type, by a careful reading. This seems
%to contradict our argument in favour of types for coding
%representation. Here, we are overflown by low-level, very precise type
%information.

%However, our situation is significantly different from the one we
%faced with encoded data: while we were suffering from a crucial lack
%of information, we are now facing too much information, hence losing
%focus. This is a general issue with the usage of codes, as they convey
%much more information than what the developer is willing to see.

%As we will see in the following section, there exists a cure to this
%problem. In a nutshell, instead of being overflown by typing
%information, we will put it at work, automatically. The consequence is
%that, in such system, working with codes is \emph{practical}: one
%should not be worried by information overload, but how to use it as
%much as possible. Therefore, we should not be afraid of using codes for
%practical purposes.

\subsection{Type propagation}
\label{sec:type-propagation}

\begin{wstructure}
<- Bidirectional type-checking [ref. Turner,Pierce]
    -> Separating type-checking from type synthesis
    <- Type checking: push terms into types
        <- Example: |Pi S T :>: \ x . t| allows us to drop annotation on lambda
    <- Type synthesis: pull types out of terms
        <- Example: |x : S l- x :<: S| gives us the type of x
\end{wstructure}

Our approach to tidying the coding cruft is deeply rooted in the
bidirectional presentation of type checking from Pierce and
Turner~\cite{pierce:bidirectional-tc}. They divide
type inference into two communicating components. In
\emph{type synthesis}, types are \emph{pulled} out of terms. A
typical example is a variable in the context:
%
\[
\Rule{\G ; \xS ; \Delta \vdash \Valid}
     {\G ; \xS ; \Delta \vdash \Bhab{\V{x}}{\M{S}}}
\]
%
Because the context stores the type of the variable, we can extract the
type whenever the variable is used.

On the other hand, in the \emph{type checking} phase, types are
\emph{pushed} into terms. We are handed a type together with a term,
our task consists of checking that the type admits the term. In doing
so, we can and should use the information
provided by the type. Therefore, we can relax our requirements on the
term. Consider \(\LAMBINDER\)-abstraction:
%
\[
\Rule{\G       \vdash \Type{\M{S}} \quad
      \G ; \xS \vdash \Bhab{\M{t}}{\M{T}}}
     {\G \vdash \Bhab{\PLAM{\x}{\M{S}} \M{t}}{\PIS{\xS} \M{T}}}
\]
%
The official rules require an annotation specifying the domain.
However, in type \emph{checking}, the \(\Pi\)-type we push in determines
the domain, so we can drop the annotation.

\begin{wstructure}
<- Formalisation: type propagation
    <- Motivation
        -> High-level syntax
            -> exprIn: types are pushed in
                <- Subject to type *checking*
            -> exprEx: types are pulled from
                <- Subject to type *synthesis*
        -> Translated into our low-level type theory
        -> Presented as judgements
    -> Presentation mirrors typing rule of [figure]
        -> Ignore identical judgements
\end{wstructure}

We adapt this idea, yielding a \emph{type
propagation} system, whose purpose is to elaborate compact
\emph{expressions} into the terms of our underlying type theory, much
as in the definition of Epigram
1~\cite{mcbride.mckinna:view-from-the-left}.  We divide expressions
into two syntactic categories: $\exprIn$ into which types are pushed,
and $\exprEx$ from which types are extracted. In the
bidirectional spirit, the $\exprIn$ are subject to type
\emph{checking}, while the $\exprEx$---variables and elimination
forms---admit type \emph{synthesis}. We embed $\exprEx$ into
$\exprIn$, demanding that the synthesised type coincides with the type
proposed. The other direction---only necessary to apply
abstractions or project from pairs---takes a type annotation.

% As the presentation largely
%mirrors the inference rules of the type theory, we will ignore the
%judgments that are identical. We refer our reader to the associated
%technical report~\cite{chapman:desc-tech-report} for the complete
%system of rules.

\begin{wstructure}
<- Type synthesis [figure]
    <- Pull a type out of an exprEx
    <- Result in a full term, together with its type
    -> Do *not* need to specify types
        -> Extracting a term from the context
        -> Function application
        -> Projections
\end{wstructure}

Type synthesis (Fig.~\ref{fig:type-synthesis}) is the \emph{source} of
types. It follows the \(\exprEx\) syntax, delivering both the
elaborated term and its type. Terms and expressions never mix: e.g.,
for application, we instantiate the range with the \emph{term}
delivered by checking the argument \emph{expression}. Hardwired
operators are checked as variables.

\begin{figure}
\input{figure_type_synthesis}
\caption{Type synthesis}
\label{fig:type-synthesis}
\end{figure}

\begin{wstructure}
<- Type checking [figure]
    <- Push a type in an exprIn
    <- Result in a full term
    -> *Use* the type to build the term!
        -> Domain and co-domain propagation for Pi and Sigma
        -> Translation of 'tags into EnumTs
        -> Translation of ['tags ...] into EnumUs
        -> Finite function space into switch
\end{wstructure}

Dually, type checking judgments (Fig.~\ref{fig:type-checking})
are \emph{sinks} for types. From an
$\exprIn$ and a type pushed into it, they elaborate a low-level
term, extracting information from the type. Note that we inductively ensure the following `sanity checks':
%
\[\stkc{
\Gamma\Vdash\propag{e}{\pull{t}{T}} \Rightarrow
  \Gamma\vdash t:T \\
\Gamma\Vdash\push{\propag{e}{t}}{T} \Rightarrow
  \Gamma\vdash t:T
}\]

Canonical set-formers are \emph{checked}: we could exploit
\(\Set:\Set\) to give them synthesis rules, but this would prejudice
our future stratification plans. Note that abstraction and pairing are
free of annotation, as promised. Most of the propagation rules are
unremarkably structural: we have omitted some mundane rules which just
follow the pattern, e.g., for \(\UId\).

\begin{figure}
\input{figure_type_checking}
\caption{Type checking}
\label{fig:type-checking}
\end{figure}

However, we also add abbreviations. We write \(\spl{\M{f}}\),
pronounced `uncurry \(\M{f}\)' for the function which takes a pair and
feeds it to \(\M{f}\) one component at a time, letting us name
them individually. Now, for the finite enumerations, we go to work.

Firstly, we present the codes for enumerations as right-nested tuples
which, by our LISP convention, we write as unpunctuated lists of tags
\(\sqr{\etag{t_0}\ldots\etag{t_n}}\).
Secondly, we can denote an element \emph{by its
name}: the type pushed in allows us to recover the numerical
index. We retain the numerical forms to facilitate
\emph{generic} operations and ensure that shadowing is punished
fittingly, not fatally.
Finally, we express functions from enumerations as tuples.
Any tuple-form, \(\void\) or \(\pair{\_}{\_}{}\), is accepted by the
function space---the generalised product---if it is accepted by the
small product. Propagation fills in the appeal to $\SYMBswitch$,
copying the range information.

Our interactive development tools also perform the
reverse transformation for intelligible output.
The encoding of any specific enumeration is thus hidden by these
translations. Only, and rightly, in enumeration-generic programs is the
encoding exposed.

\begin{wstructure}
<- Summary
    -> Not a novel technique [refs?]
        /> Used as a boilerplate scrapper
    -> Make dealing with codes *practical*
        <- Example: Finite sets/finite function space
        -> We should not restrain our self in using codes
            <- We know how to present them to the user
-> Will extend this machinery in further sections
\end{wstructure}

%In this section, we have developed a type propagation system based on
%bidirectional type-checking. Using bidirectional type-checking as a
%boilerplate scrapper is a well-known
%technique~\cite{pierce:bidirectional-tc,
%  xi:bidirectional-tc-bound-array, chlipala:strict-bidirectional-tc}
%\note{Everybody ok with the citations?}. In our case, we have shown
%how to instrument bidirectionality to rationalise the expressivity of
%dependent types. We have illustrated our approach with finite sets. We
%have abstracted away the low-level presentation of finite sets,
%offering a convenient syntax instead.

%This example teaches us that we should not be afraid of codes, as soon
%as type information is available. We have shown how to rationalise
%this information in a formal presentation. Hence, we have shown that
%programming with such objects is practical. As we introduce more codes
%in our theory, we will show how to extend the framework we have
%developed so far.

Our type propagation mechanism does no constraint
solving, just copying, so it is just the thin end of the elaboration wedge.
It can afford us this `assembly
language' level of civilisation as \(\EnumU\) universe
specifies not only the \emph{representation} of the
low-level values in each set as bounded numbers, but also the
\emph{presentation} of these values as high-level tags. To encode only
the former, we should merely need the \emph{size} of enumerations, but
we extract more work from these types by making them more informative.
We have also, \emph{en passant}, distinguished enumerations which have
the same cardinality but describe distinct notions:
\(\EnumT{\sqr{\etag{\CN{red}}\,\etag{\CN{blue}}}}\) is not
\(\EnumT{\sqr{\etag{\CN{green}}\,\etag{\CN{orange}}}}\).


\documentclass{article}
\usepackage[minionint,mathlf,textlf]{MinionPro} % To gussy up a bit
\usepackage[margin=1in]{geometry}
\usepackage{graphicx} % For .eps inclusion
%\usepackage{indentfirst} % Controls indentation
\usepackage[compact]{titlesec} % For regulating spacing before section titles
\usepackage{adjustbox} % For vertically-aligned side-by-side minipages
\usepackage{array, mathrsfs, mhchem, amsmath} % For centering of tabulars with text-wrapping columns
\usepackage{hyper ref}
\usepackage[autolinebreaks,framed,numbered]{mcode}
\pagenumbering{gobble}
\setlength\parindent{0 cm}
\begin{document}
\large

These derivations follow van Kampen (3rd ed.) but summarize only points related to the description of Poisson processes.

\section*{Characteristic functions}
The characteristic function for a random variable $X$ on the reals is defined as:
\[ G(k) =\left< e^{ikX} \right> = \int_{-\infty}^{\infty} e^{ikx} P(x)\, dx \]
Its Taylor expansion is:
\[ G(k) =  \int_{-\infty}^{\infty} \left[ \sum_{\ell=0}^{\infty} \frac{\left(ik \right)^{\ell}x^{\ell}}{\ell!} \right] P(x)\, dx = \sum_{\ell=0}^{\infty} \frac{\left(ik \right)^{\ell}}{\ell!}  \int_{-\infty}^{\infty} x^{\ell} P(x)\, dx =  \sum_{\ell=0}^{\infty} \frac{\left(ik \right)^{\ell}}{\ell!} \mu_{\ell}\]
where $\mu_{\ell}$ is the $\ell$th moment of $X$. The characteristic function is therefore also the moment generating function.\\

For a random variable $X$ defined only on the integers,
\begin{eqnarray*}
 P(X=n) = \sum_{n \in \mathbb{Z}} p_n \delta(x-n) \implies G(k) = \sum_{n \in \mathbb{Z}} p_n e^{ikn} \label{eqn:discretechar}
 \end{eqnarray*}

\section*{Point processes}
A \textit{point process} is a ``random set of points": for example, it might be the set of times at which a chemical reaction (or any other event) occurs. A sample is described by the ordered set of $\sigma$ real numbers (times) $\tau_1, \tau_2, \ldots$. The first $s$ events in this series are represented by $\tau_1,\ldots, \tau_s$. The normalized probability distribution is expressed in terms of functions $P_s(\tau_1,\ldots,\tau_s)$:
\[ P_0 + \int_{-\infty}^{\infty} P_1(\tau_1) \, d\tau_1 + \int_{\tau_1}^{\infty}\left[  \int_{-\infty}^{\infty}  P_2(\tau_1,\tau_2) \, d\tau_1 \right] \, d\tau_2 + \ldots = 1 \]
If we restrict the requirement that the $\tau_i$ are in chronological order, then noting that there are $s!$ permutations of the set ${\tau_1,\ldots,\tau_s}$ and requiring that $P_s$ is symmetric in all its variables (i.e. one event is not more likely to occur at a certain time than any other), then we can rewrite the above normalization as:
\begin{eqnarray}
P_0 + \sum_{s=1}^{\infty} \frac{1}{s!} \int_{\mathbb{R}^{s}} P_s(\tau_1,\ldots,\tau_s) \, d\tau_1 \, \ldots d\tau_s = 1 \label{eqn:normpoint}
\end{eqnarray}
Suppose we would like to know the average number of events occurring within an interval $(t_a,t_b)$. We introduce the indicator function $f(t)=1 \, \forall\,  t \in (t_a,t_b)$, and zero otherwise. Then of $s$ events, the number that occur within this interval is $N = \sum_{k=1}^s f(\tau_k)$, and
\begin{eqnarray*}
\left< N \right> & = & \left< \sum_{k=1}^{s} f(\tau_k) \right>\\
& = & \sum_{s=1}^{\infty} \int_{\mathbb{R}^{s}} \left( \sum_{k=1}^{s} f(\tau_k) \right) P_s(\tau_1,\ldots,\tau_s) \, d\tau_1 \, \cdots d\tau_s\\
& = & \sum_{s=1}^{\infty} \frac{1}{s!}  \int_{-\infty}^{\infty} s f(\tau_1) \left[  \int_{\mathbb{R}^{s-1}}  P_s(\tau_1,\ldots,\tau_s) \, d\tau_2 \, \cdots d\tau_s \right] \, d \tau_1\\
& = & \sum_{s=1}^{\infty} \frac{1}{(s-1)!}  \int_{t_a}^{t_b}  \left[  \int_{\mathbb{R}^{s-1}}  P_s(\tau_1,\ldots,\tau_s) \, d\tau_2 \, \cdots d\tau_s \right] \, d \tau_1\\
\end{eqnarray*}

\section*{Poisson processes}
For a process in which all of the $\tau_i$ are independent and identically distributed, the $P_s$ can be factorized in the form
\[ P_s(\tau_1,\ldots, \tau_s) = e^{-v} P(\tau_1) \cdots P(\tau_s), \hspace{2 cm} \textrm{ where } v = \int_{-\infty}^{\infty} P(\tau) \, d\tau \]
is a normalization constant which follows from equation \ref{eqn:normpoint}. The formula for the average number of events in an interval can now be simplified:
\begin{eqnarray}
\left< N \right> & = & e^{-v} \int_{t_a}^{t_b} P(\tau) \, d \tau \left( \sum_{s=1}^{\infty} \frac{1}{(s-1)!}   \left[  \int_{-\infty}^{\infty} P(\tau) \, d\tau \right]^{s-1} \right) \nonumber \\
& = &  \int_{t_a}^{t_b} P(\tau) \, d \tau \label{eqn:avgpoisson}
\end{eqnarray}
It is no harder to show that for this type of process,
\[ \sigma_N^2 = \left< N^2 \right> - \left< N \right>^2 = \left< N \right> \]
To learn more about the probability distribution of $N$, we find its characteristic function:
\begin{eqnarray*}
\left< e^{ikN} \right> & = & \sum_{s=0}^{\infty} \frac{1}{s!} \int_{\mathbb{R}^{s}} e^{ikN} P_s(\tau_1,\ldots,\tau_s) \, d\tau_1 \, \ldots d\tau_s  \\
& = & e^{-v} \sum_{s=0}^{\infty} \frac{1}{s!} \left[ \int_{-\infty}^{\infty} e^{ikf(\tau)} P(\tau) \, d\tau \right]^s\\
& = & \exp \left[\int_{-\infty}^{\infty} e^{ikf(\tau)} P(\tau) \, d\tau  - \int_{-\infty}^{\infty} P(\tau) \, d\tau \right]\\
& = & \exp \left[  \left( e^{ik} - 1 \right) \int_{t_a}^{t_b} P(\tau) \, d\tau \right] \hspace{ 1 cm} \textrm{which by equation \ref{eqn:avgpoisson} is}\\
& = & \exp \left[  \left( e^{ik} - 1 \right)  \left< N \right> \right] = e^{-\left< N \right>} \sum_{k=0}^{\infty} \frac{\left< N \right>^k e^{ikN}}{k!}\\
\end{eqnarray*}
But as we also know from equation \ref{eqn:discretechar} that $G(k) = \sum_{n \in \mathbb{Z}} p_n e^{ikn}$ since $N$ can take on only integral values, then by comparing terms:
\[ p(N=k) =   \sum_{k=0}^{\infty} \frac{\left< N \right>^k e^{-\left< N \right>}}{k!}, \hspace{2cm} \textrm{ which is the Poisson pdf with } \lambda = \left< N \right>\]
It is hopefully now clear why processes with events that are independent and identically distributed are called Poisson processes.\\

When $P(\tau)=v/(t_b-t_a)$ is constant on the interval, as $v,t_b-t_a \to \infty$ with $P(\tau)$ fixed, the distribution of $\tau_i$ approaches a stationary distribution called \textit{shot noise}.
\end{document}

lectures/Lecture 22 - Stochastic Simulation/poisson processes.tex


\chapter*{Appendix D - Reimplementation of sorting}
\addcontentsline{toc}{chapter}{Appendix D}

\par The following sorting functions that operate on numbers have been suggested\footnote{by Matt8898 and Umnikos; Matt8898 have admitted themselves that the "quicksort" implementation doesn't implement a quicksort} as demonstration programs for MalbolgeLISP v1.1:

\begin{minted}{lisp}
(defun filter (f l) (cond
    ((= l null) null)
    ((f (car l)) (cons (car l) (filter f (cdr l))))
    (1 (filter f (cdr l)))))

(defun append (a b) (if (= null a) b (cons (car a) (append (cdr a) b) )))
(defun append3 (a b c) (append a (append b c)))
(defun list>= (m list) (filter (lambda (n) (! (< n m))) list))
(defun list< (m list) (filter (lambda (n) (< n m)) list))

(defun qsort (l) (
    if (= null l)
        null
        (append3
            (qsort (list< (car l) (cdr l)))
            (cons (car l) null)
            (qsort (list>= (car l) (cdr l))))))

(qsort '(6 8 1 0 6 8 2))

; -------------

(defun insert (i l) (
    if (= null l)
        (cons i l)
        (if (> i (car l))
            (cons (car l) (insert i (cdr l)))
            (cons i l))))

(defun insertsort (l) (
    if (= null l)
        null
        (insert (car l) (insertsort (cdr l)))))

(insertsort '(6 8 1 0 6 8 2))
\end{minted}

\par The second algorithm is faster than the first one, even though the first one has lower computational complexity. This is related to the code size (the first implementation is being parsed for much longer than the first one) and the complexity (insertion sort works well for small vectors).


    \filetitle{portest}{Portmanteau test for autocorrelation in VAR residuals}{VAR/portest}

	\paragraph{Syntax}\label{syntax}

\begin{verbatim}
[Stat,Crit] = portest(V,Data,H)
\end{verbatim}

\paragraph{Input arguments}\label{input-arguments}

\begin{itemize}
\item
  \texttt{V} {[} VAR \textbar{} swar {]} - Estimated VAR from which the
  tested residuals were obtained.
\item
  \texttt{Data} {[} tseries {]} - VAR residuals, or VAR output data
  including residuals, to be tested for autocorrelation.
\item
  \texttt{H} {[} numeric {]} - Test horizon; must be greater than the
  order of the tested VAR.
\end{itemize}

\paragraph{Output arguments}\label{output-arguments}

\begin{itemize}
\item
  \texttt{Stat} {[} numeric {]} - Portmanteau test statistic.
\item
  \texttt{Crit} {[} numeric {]} - Portmanteau test critical value based
  on chi-square distribution.
\end{itemize}

\paragraph{Options}\label{options}

\begin{itemize}
\itemsep1pt\parskip0pt\parsep0pt
\item
  \texttt{'level='} {[} numeric \textbar{} \emph{\texttt{0.05}} {]} -
  Requested significance level for computing the criterion
  \texttt{Crit}.
\end{itemize}

\paragraph{Description}\label{description}

\paragraph{Example}\label{example}


\section{Technical Data}

\subsection{Execution Speed on digital Output}
\label{sec_lpc1768_bitflip}
A task, which sets and resets a bit on the Lpc17xxDigitalOut runs with
a speed of $650 \mu s$ per loop cycle.

\subsection{ALL .. ACTIVATE}
A task which will be started cyclic with the ALL statement may be scheduled
with a timing resolution of $10 \mu s$. In the test case, the task
flips a bit of the Lpc17xxDigitalOut. The minimum rate for the activation is
$1,1 ms$ due the task setup operations and task execution.
In consideration of the timing in section \ref{sec_lpc1768_bitflip}
the task setup needs $650 \mu s$.


\subsection{CDCL(\T)}

\begin{frame}
  \frametitle{CDCL(\T)}

  \scriptsize

  The interaction described naturally falls within the
  CDCL style, enriched with a \tsolver
      $$\varphi \equiv
      (x=3 \vee \neg (x<3))\ \swedge\
      (x=3 \vee \neg (x>3))\ \swedge\
      (x>3 \vee \neg (x<3))\ \swedge\
      (x>3 \vee \neg (x=3))$$
  \vfill
  \begin{columns}

    \begin{column}{.5cm}
      \vspace{-165pt}
      $\babst{\varphi} \equiv$
    \end{column}

    \begin{column}{5cm}
      $(\coltwoat{\coloneat{a_1}{8-13}}{2-6} \vee \coltwoat{\neg a_2}{9-13})$ \\
      $(\coltwoat{\coloneat{a_1}{8-13}}{2-6} \vee \coltwoat{\coloneat{\neg a_3}{3-6}}{10-13})$ \\
      $(\coloneat{\coltwoat{a_3}{3-6}}{10-13} \vee \coltwoat{\neg a_2}{9-13})$ \\
      $(\coloneat{\coltwoat{a_3}{3-6}}{10-13} \vee \coloneat{\coltwoat{\neg a_1}{8-13}}{2-6})$ \\
      \onslide<6->{$(\coloneat{\coltwoat{\neg a_1}{10-13}}{6} \vee \coltwoat{\coloneat{\neg a_3}{6}}{10-13})$ \\}
      \onslide<7->{$(\coltwoat{\neg a_1}{8-13})$ \\}
      \onslide<13->{$(\coloneat{a_1}{13} \vee \coloneat{a_2}{13} \vee \coloneat{a_3}{13})$ \\}
      \onslide<14->{$(\ )$ \\}
      \bigskip
      $a_1 \equiv x=3$ \\
      $a_2 \equiv x<3$ \\
      $a_3 \equiv x>3$ \\
      \bigskip
      $\babst{\mu}$: $\{\ \only<2-6|handout:0>{a_1}\only<3-6|handout:0>{, a_3}\only<8-13|handout:0>{\neg a_1}\only<9-13|handout:0>{, \neg a_2}\only<10-13|handout:0>{, \neg a_3}\ \}$ \\
      \bigskip
      \begin{tabular}{rl}
      SAT-solver: & \only<1,4-5,11-12|handout:0>{Idle}\only<2|handout:0>{Decision}\only<3,8-10|handout:0>{BCP}\only<6,13|handout:0>{Learn}\only<7,14|handout:0>{Conf. Analysis, Backtrack}\only<15>{UNS} \\
        \tsolver: & \only<1,2,3,6-10,13->{Idle}\only<4,5,11,12|handout:0>{Is $\babst{\mu}$ \T-satisfiable ?}\only<5,12|handout:0>{ NO}
      \end{tabular}
    \end{column}

    \begin{column}{5cm}
      \begin{overlayarea}{5cm}{5cm}
	\only<1|handout:0>{\scalebox{.6}{\input{search_0.pdf_t}}}
	\only<2|handout:0>{\scalebox{.6}{\input{search_1.pdf_t}}}
	\only<3,4,5|handout:0>{\scalebox{.6}{\input{search_2.pdf_t}}}
	\only<6,7|handout:0>{\scalebox{.6}{\input{search_3.pdf_t}}}
	\only<8|handout:0>{\scalebox{.6}{\input{search_4.pdf_t}}}
	\only<9|handout:0>{\scalebox{.6}{\input{search_5.pdf_t}}}
	\only<10-12|handout:0>{\scalebox{.6}{\input{search_6.pdf_t}}}
	\only<13->{\scalebox{.6}{\input{search_7.pdf_t}}}
      \end{overlayarea}
    \end{column}

  \end{columns}

\end{frame}

\begin{frame}
  \frametitle{Early Pruning}

  \scriptsize

  Notice that there is no need to wait until a (partial) Boolean model is found to
  call \tsolver
  \vfill
  Suppose that the first Boolean model is
  $$\babst{\mu} = \{ x < y, x = y, \ldots (\mbox{ 1000 other constraints }) \}$$
  This Boolean model is \T-unsatisfiable already at $\{ x < y, x = y \}$, and could have been stopped much earlier
  \vfill
  \pause
  \begin{center}
  \scalebox{.3}{\input{ep.pdf_t}}
  \end{center}
  \vfill
  \pause
  However, do not call \tsolver too often, as it may slow things down
  \vfill
  Good heuristic: call \tsolver just after any BCP

\end{frame}

\begin{frame}
  \frametitle{The CDCL Procedure}

  \scriptsize

  \vfill

  \begin{tabbing}
  as \= a \= a \= a \= as \= asdfsdfasdfasdfasdfasdfasdfasdfasdfasdf \= \kill
  \> $dl = 0$; $trail = \{\ \}$;                              \> \> \> \> \> // Decision level, assignment\\ \\
  \> while ( $true$ ) \\ \\
  \> \> if ( BCP( ) == conflict )                                \> \> \> \> // Do BCP until possible \\
  \> \> \> if ( $dl == 0$ ) return $unsat$;                         \> \> \> // Unresolvable conflict \\
  \> \> \> $C,dl =$ {\sc AnalyzeConflict}( );                           \> \> \> // Compute conf. clause, and dec. level \\
  \> \> \> {\sc AddClause}( $C$ );                                      \> \> \> // Add $C$ to clause database \\
  \> \> \> {\sc BacktrackTo}( $dl$ );                                   \> \> \> // Backtracking (shrinks $trail$) \\
  \> \> else \\
  \> \> \> if ( ``all variables assigned'' ) return $sat$;          \> \> \> // $trail$ holds satisfying assignment \\
  \> \> \> $l = $ {\sc Decision}( );                                      \> \> \> // Do another decision \\
  \> \> \> $trail = trail \cup \{ l \}$ \\
  \> \> \> $dl = dl + 1$;                                           \> \> \> // Increase decision level \\
  \end{tabbing}

  \vfill

\end{frame}

\begin{frame}
  \frametitle{The (basic) CDCL(\T) Procedure}

  \scriptsize

  \vfill

  \begin{tabbing}
  as \= a \= a \= a \= as \= asdfsdfasdfasdfasdfasdfasdfasdfasdfasdf \= \kill
  \> \textcolor{red}{class {\sc Theory};}                         \> \> \> \> \> // \tsolver \\
  \\
  \> $dl = 0$; $trail = \{\ \}$;                                  \> \> \> \> \> // Decision level, assignment\\ \\
  \> while ( $true$ ) \\ \\
  \> \> if ( {\sc BCP}( ) == conflict )                                    \> \> \> \> // Do BCP until possible \\
  \> \> \> if ( $dl == 0$ ) return $unsat$;                             \> \> \> // Unresolvable conflict \\
  \> \> \> $C,dl =$ {\sc AnalyzeConflict}( );                           \> \> \> // Compute conf. clause, and dec. level \\
  \> \> \> {\sc AddClause}( $C$ );                                      \> \> \> // Add $C$ to clause database \\
  \> \> \> {\sc BacktrackTo}( $dl$ );                                   \> \> \> // Backtracking (shrinks $trail$) \\
  \> \> \textcolor{red}{else if ( {\sc Theory.Check}( $trail$ ) == $unsat$ )}               \> \> \> \> // \tsolver check \\
  \> \> \> \textcolor{red}{{\sc AddClause}( $\neg trail$ );}                             \> \> \> // Add clause that is now unsat \\
  \> \> else \\
  \> \> \> if ( ``all variables assigned'' ) return $sat$;              \> \> \> // $trail$ holds satisfying assignment \\
  \> \> \> $l = $ {\sc Decision}( );                                    \> \> \> // Do another decision \\
  \> \> \> $trail = trail \cup \{ l \}$ \\
  \> \> \> $dl = dl + 1$;                                               \> \> \> // Increase decision level \\
  \end{tabbing}

  \vfill

\end{frame}


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

\begin{document}

\section*{Ricci scalar}

Here we compute the Ricci scalar $R$ in terms of the BSSN data.

Note that this expression for $R$ will only be used when evaluating the constraints. It
will \emph{not} be used in the evolution equations so the advice that the evolved
${\bar\Gamma}^{i}$ should be expressed in terms of ${\bar g}_{ij}$ does not apply here.

\begin{cadabra}
   from shared import *
   import cdblib

   jsonfile = 'bssn-ricci-scalar.json'
   cdblib.create (jsonfile)

   defRab = cdblib.get ('defRab','bssn-eqtns-14.json')

   # --------------------------------------------------------------------------

   defG2GBarU := g^{a b} -> \exp(-4\phi) gBar^{a b}.

   Rscalar := R.                                      # cdb(Rscalar.00,Rscalar)
   Rscalar := g^{a b} R_{a b}.                        # cdb(Rscalar.01,Rscalar)

   substitute (Rscalar, defRab)                       # cdb(Rscalar.02,Rscalar)
   substitute (Rscalar, defG2GBarU)                   # cdb(Rscalar.03,Rscalar)
   distribute (Rscalar)                               # cdb(Rscalar.04,Rscalar)

   Rscalar = product_sort (Rscalar)                   # cdb(Rscalar.05,Rscalar)

   rename_dummies (Rscalar)                           # cdb(Rscalar.06,Rscalar)
   canonicalise   (Rscalar)                           # cdb(Rscalar.07,Rscalar)

   foo := gBar^{b c} \partial_{a}{gBar_{b c}} -> 0.   # follows from det(g) = 1

   substitute (Rscalar, foo)                          # cdb(Rscalar.08,Rscalar)

   foo := gBar_{a b} gBar^{a b} -> 3.
   bah := gBar_{a b} gBar^{a c} -> gBar_{b}^{c}.
   moo := gBar^{c d} gBar^{e f} \partial_{a}{gBar_{c e}} -> - \partial_{a}{gBar^{d f}}.

   substitute (Rscalar, foo)                          # cdb(Rscalar.09,Rscalar)
   substitute (Rscalar, bah)                          # cdb(Rscalar.10,Rscalar)
   substitute (Rscalar, moo)                          # cdb(Rscalar.11,Rscalar)
   eliminate_kronecker (Rscalar)                      # cdb(Rscalar.12,Rscalar)
   rename_dummies (Rscalar)                           # cdb(Rscalar.13,Rscalar)
   canonicalise   (Rscalar)                           # cdb(Rscalar.14,Rscalar)

   foo := gBar^{a b} gBar^{c d} \partial_{c}{gBar_{b d}} -> - \partial_{c}{gBar^{a c}}.
   bah := \partial_{b}{gBar^{a b}} -> - GammaBar^{a}.  # prd62.eqn17

   substitute (Rscalar, foo)                          # cdb(Rscalar.15,Rscalar)
   substitute (Rscalar, bah)                          # cdb(Rscalar.16,Rscalar)

   Rscalar = product_sort (Rscalar)                   # cdb(Rscalar.17,Rscalar)

   rename_dummies (Rscalar)                           # cdb(Rscalar.18,Rscalar)
   canonicalise   (Rscalar)                           # cdb(Rscalar.19,Rscalar)

   foo := gBar^{a b} gBar^{c d} \partial_{a b}{gBar_{c d}} ->
        - gBar^{a b} \partial_{a}{gBar_{c d}} \partial_{b}{gBar^{c d}}. # follows from det(g) = 1

   substitute (Rscalar, foo)                          # cdb(Rscalar.20,Rscalar)
   factor_out (Rscalar, $\exp(-4\phi)$)               # cdb(Rscalar.21,Rscalar)

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

\clearpage

\begin{dgroup*}
   \begin{dmath*}
      \cdb{Rscalar.00}
         = \Cdb*{Rscalar.01}
         = \Cdb*[\hskip2.0cm\hfill]{Rscalar.02}
         = \Cdb*[\hskip2.5cm\hfill]{Rscalar.03}
         = \Cdb*{Rscalar.04}
         = \Cdb*{Rscalar.05}
         = \Cdb*{Rscalar.06}
   \end{dmath*}
\end{dgroup*}

\clearpage

\begin{dgroup*}
   \begin{dmath*}
      \cdb{Rscalar.00}
         = \Cdb*{Rscalar.07}
         = \Cdb*{Rscalar.08}
         = \Cdb*{Rscalar.09}
         = \Cdb*{Rscalar.10}
         = \Cdb*{Rscalar.11}
         = \Cdb*{Rscalar.12}
   \end{dmath*}
\end{dgroup*}

\clearpage

\begin{dgroup*}
   \begin{dmath*}
      \cdb{Rscalar.00}
         = \Cdb*[\hskip2.5cm\hfill]{Rscalar.13}
         = \Cdb*[\hskip2.5cm\hfill]{Rscalar.14}
         = \Cdb*{Rscalar.15}
         = \Cdb*{Rscalar.16}
         = \Cdb*{Rscalar.17}
         = \Cdb*{Rscalar.18}
         = \Cdb*{Rscalar.19}
         = \Cdb*{Rscalar.20}
         = \Cdb*{Rscalar.21}
   \end{dmath*}
\end{dgroup*}

\end{document}


\lab{Data Structures}{Data Structures}
\label{lab:Python_DataStructures}
\objective{Empower students with basic knowledge of the fundamental, canonical data structures in order to understand performance and runtime characteristics.}

Both storing and retrieving data take time. As a data set grows, so too does the time required to manipulate it.
The overhead associated with working with large data sets makes it crucial that we have a fundamental knowledge of the data structures used to store them.
As we understand the characteristics of such data structures, we will be able to choose the data structure that will help us most efficiently access the data that we need.

\section*{Abstract Data Types}
The fundamental way to store data is via \emph{primitive data types}.
We are actually already quite familiar with these data types: booleans, strings, floats, and integers.
Most information that we care to store is in one of these forms; however, these primitive types can quickly become unwieldy for storing large amounts of information, especially since we rarely want to store a single string, float or integer. Rather, we want to organize our data in different ways depending on what we intend to do with it.
We can do this by using primitive data types, along with arrays, as our building blocks.
More complex data structures are called \emph{abstract data types}.
Typically, the performance of each abstract data type slows down as the size of the data structure increases.
However, some data structures slow down more slowly or gracefully than others.
This is why it is so important that we understand the underlying advantages and disadvantages of these structures.
Such an understanding allows us to choose the most optimal structure for our purposes.

Most abstract data types use an object called a \emph{node} to store data.
A node essentially acts as a box in which we store an arbitrary piece of data.
It usually serves as a building block for whichever kind of data structure we want to create; it is whatever we want it to be and it contains whatever we need it to contain.
This versatility lets us to define nodes to store absolutely anything; what they contain both depends on the data structure itself and data that is actually being stored.
Using nodes allows us to store extra information pertinent to the functioning of the datastructure.
For example, the node of a binary search tree (which we will later discuss in section \ref{Binary Search Tree}) contains three things: a piece of data, a reference to its left child, and a reference to its right child.
The node of a singly linked list contains only two things: a piece of data and a reference to the next node in the list.

\section*{Linked Lists}
\emph{Linked lists} are one of the most simple of all abstract data structures.
A linked list, in essence, is simply a list of nodes that are linked together.
There are two main types of linked lists: singly-linked (figure \ref{fig:singly_linked} and doubly-linked (figure \ref{fig:doubly_linked}.

\begin{figure}
\centering
\begin{tikzpicture}[->,>=stealth',shorten >=1pt,auto, node distance=1.5cm,thick,main node/.style={rectangle,draw}, minimum size=.5cm]
\tikzset{rect node/.style={rectangle, draw, minimum height = .5cm, minimum width=.2cm}}
  \node[main node] (1) {B};
  \node[main node] (2) [right of=1] {F};
  \node[main node] (3) [right of=2] {G};
  \node[main node] (4) [right of=3] {C};
  \node[draw = none, black!20!blue, node distance=1.5cm] [above left of=1](H) {Head};
\foreach \r in {1, 2, 3, 4}{
  \node[rect node][right of=\r, node distance = .36cm]{};}
\node[draw = none, node distance = 1.5cm] [right of=4]{};  % Centralize this particular figure
\foreach \s/\t  in {1/2, 2/3, 3/4}{
	\path[draw](\s) edge[shorten <=.1cm](\t);}
  \draw[black!20!blue] (H) edge (1.north);
\end{tikzpicture}
\caption{Singly-linked List}
\label{fig:singly_linked}
\end{figure}

A singly-linked node stores a piece of data (its value), and a single reference that points to the next node in the list.
Doubly-linked nodes have two references: one that points to the previous node and one that points to the next node in the list.
This allows for a doubly-linked list to be traversed in both directions, whereas a singly-linked list can only be traversed in one direction.
We begin to implement a singly-linked node class as follows:
\begin{lstlisting}
class Node(object):
    def __init__(self, data):
        self.next = None
        self.value = data
\end{lstlisting}

\begin{figure}
\centering
\begin{tikzpicture}[->,>=stealth',shorten >=1pt,auto, node distance=1.5cm, thick,main node/.style={rectangle,draw}, minimum size=.5cm]
\tikzset{rect node/.style={rectangle, draw, minimum height = .5cm, minimum width=.9cm}}
  \node[main node] (1) {B};
  \node[main node] (2) [right of=1] {F};
  \node[main node] (3) [right of=2] {G};
  \node[main node] (4) [right of=3] {C};
  \node[draw = none, black!20!blue, node distance = 1.5cm] [above right of=4] (T) {Tail};
  \node[draw = none, black!20!blue, node distance = 1.5cm] [above left of=1] (H) {Head};
  \node[rect node](1.5)[]{};
  \node[rect node](2.5)[right of=1.5]{};
  \node[rect node](3.5)[right of=2.5]{};
  \node[rect node](4.5)[right of=3.5]{};

\foreach \s/\t  in {1/2, 2/3, 2/1, 3/2, 3/4, 4/3}{
	\path[draw](\s) edge[shorten <=.1cm, shorten >=.1cm](\t);}
  \draw[black!20!blue] (H) edge (1.north);
  \draw[black!20!blue] (T) edge (4.north);
\end{tikzpicture}
\caption{Doubly-linked List}
\label{fig:doubly_linked}
\end{figure}

We begin constructing a singly-linked list class with a reference to the head node:
\begin{lstlisting}
class SLinkedList(object):
    def __init__(self):
        self.head = None
\end{lstlisting}

Linked lists may also have a reference to the tail node and a size counter to keep track of the size of the list.
Including a tail reference allows us to avoid traversing the entire list each time we wish to insert at the end.
Similarly, without a size counter we would have to recount the list every time we wanted to know its size.
\begin{lstlisting}
class SLinkedList(object):
    def __init__(self):
        self.head = None
        self.tail = None
        self.size = 0

    def __len__(self):
        return self.size
\end{lstlisting}

\subsection*{Searching, Inserting and Removing}
To locate a node, our linked must start at the head of the list and follow references to other nodes until the desired node is found.
In a singly-linked list, it is also often a good idea to track the node prior to our index; this will prove useful for our insertion and removal methods.
We add a find method to our \li{SLinkedList} class:
\begin{lstlisting}
# Returns the node at the given index and the node previous to it.
def find(self, index):
    if index >= len(self):
        raise IndexError

    nfind = self.head
    nprev = None
    # Keeps track of the index of nfind.
    count = 0

    # Update nprev and nfind until we reach the node at the index desired.
    # nfind.next evaluates to True while nfind.next != None
    while count < index and nfind.next:
        count += 1
        nprev = nfind
        nfind = nfind.next
    return nprev, nfind
\end{lstlisting}

In order to insert or delete nodes found in the middle of the list, we must first locate the correct node by traversing the list, starting at the head and visiting each node.
Insertion itself is a very efficient procedure, but traversing the list to find the insert location takes longer as the size of the list grows.
However, because we already have head and tail references, nodes can be inserted or removed from either end of a linked list very efficiently, regardless of the size of the list.

When inserting into a list, we must remember to update the all the appropriate references.
To insert into a linked list, we consider three cases: head insertion, tail insertion, and middle insertion.
\begin{lstlisting}
def insert(self, index, data):
    if index > len(self):
        raise IndexError

    # Initialize a temporary node to store the desired piece of data.
    n = Node(data)

    if index == 0:
        # Inserting at the head
        # Assign old head node as n.next
        n.next = self.head
        # Set n as the new head node
        self.head = n

        # If n is the only node, set as the tail also
        if len(self) == 0:
            self.tail = self.head
    elif index == len(self):
        # Inserting at the tail
        self.tail.next = n
        # Set n as the new tail
        self.tail = n
    else:
        # Middle insertion
        nprev, nindex = self.find(index)
        n.next = nindex
        nprev.next = n
    self.size += 1
\end{lstlisting}

\begin{problem}
Removing a node is similar to inserting a node, we must consider removing from the head, tail, or middle of the list.
Implement a \li{remove(self, index)} method in your \li{SLinkedList} class.
Be sure to update your size and references appropriately as you compensate for all possible situations (the index corresponds to a list with a single node, the index is out of range, etc.)

The code below provides a few additional methods to supplement your \li{SLinkedList} class: one that will clear the list and one that will represent the list as a string.
These functions may be useful for testing your removal method.
\begin{lstlisting}
def clear(self):
    self.head = None

def __str__(self):
    return '[' + ','.join(map(str, iter(self))) + ']'

def __iter__(self):
    temp = self.head
    while temp:
        yield temp.value
        temp = temp.next
\end{lstlisting}
\emph{Note}: Because Python is able to keep track of the variables we use, it will automatically delete a variable if there is no access to it.
In our \li{clear} method, this property allows us to set the reference to the head to be \li{None} which, in turn, allows Python to clean up the leftover nodes (in other languages, this might cause serious memory leaks).
\label{prob:LinkedList}
\end{problem}

\section*{Stacks, Queues, and Deques}
Stacks, queues (pronounced `cues'), and deques (pronounced `decks') can be thought of as types of linked lists where access is restricted.
Rather than accessing data anywhere in the list, we only add and remove from certain areas, which means that the methods of these structures operate independent of the list size.

\begin{itemize}
\item \emph{Stacks}: These are built on the `last in, first out' principle, meaning that the last item that was put in the stack will be the first one to leave.
You can imagine this as a pile of plates in the kitchen cupboard.
This means that the last plate put in will be the first one taken out.
To implement this, we would only insert and remove from the same end of a linked list.
\item \emph{Queues}: Queues use a `first in, first out' implementation, meaning that the first thing put in will be the first thing taken out.
This is similar to people waiting in line.
The first person in line will be the first served and taken out of the line.
This is implemented as a linked list where we insert on one end and remove on the opposite end.
\item \emph{Deques}: This structure is a double-ended queue; we can insert and remove from either end of a deque.
Really the only difference between this and a linked list is that we cannot add and remove from the middle.
Python's collections module already contains a deque object, which is discussed on page \pageref{deques} of our initial lab, \nameref{lab:Standard Library}.
\end{itemize}

\section*{Trees}
\label{Binary Search Tree}
Donald Knuth, author of \emph{The Art of Computer Programming}, once said that ``Trees sprout up just about everywhere in computer science.''
We can create many different types of trees by the way we organize the nodes within them.
One of the simplest of these trees is called a \emph{binary search tree}(BST).

A binary search tree is a tree that has a root node with a maximum of two children, commonly referred to as a left child and a right child.
They are commonly ordered such that the left child of the root node contains elements less than the root, and the right child contains elements greater than the root.
The tree is a recursive structure, where each child node is potentially the root of a subtree with the same properties.
This type of organization substantially reduces search time, making trees an excellent data structure to use when our primary goal is efficient searching.
By simply knowing that our target element is less than or greater than the root, we can immediately eliminate half of the binary tree from the search.
Because the process of locating a node is so quick, the processes of inserting and removing nodes are similarly efficient.

We begin building a BST by defining our node class.
A node in a binary search tree holds a piece of data as well as references to its left and right children which can, in turn, be the roots of subtrees.
We call a node without any children a \emph{leaf} node.
\begin{lstlisting}
class Node(object):
    def __init__(self, data):
        self.value = data
        self.left = None
        self.right = None
\end{lstlisting}
We initialize our BST similarly to a linked list, with a reference to the root and to a size counter to keep track of the size.
\begin{lstlisting}
class BinarySearchTree(object):
    def __init__(self):
        self.root = None
        self.size = 0

    def __len__(self):
        return self.size
\end{lstlisting}

\subsection*{Inserting}
Inserting a node into a binary search tree is a simple procedure.
Our goal is to insert into a leaf node, so we travel to the right if the element is greater than the current node or travel to the left if the element is less than the current node.
Once we reach a node without a subtree in the appropriate location, we add our new node as its new child node.
This way, we insert only leaf nodes into a BST.

Let's demonstrate this process with an example.

\begin{minipage}{0.35\textwidth}
    \begin{tikzpicture}[thick]
      \node[circle, draw, minimum size = 1cm]{23};
    \end{tikzpicture}
\end{minipage}\hfill
\begin{minipage}{0.55\textwidth}
    We start with an empty tree, and add our root node: $23$.
\end{minipage}

\begin{minipage}{0.35\textwidth}
    \begin{tikzpicture}[
      node distance = 1.5cm,
      level distance=1.5 cm,
      level 1/.style={sibling distance=3cm},
      level 2/.style={sibling distance=1.5cm},
      thick, minimum size=1cm]
      \node[circle,draw](23) {23}
	    child {
	    node [circle,draw](17){17}
	    }
	    child{node[circle,draw](476){476}
	    };
      \path[->, >=stealth', shorten >=1pt, auto]
	    (23) edge[bend right, blue] (17)
	    (23) edge[bend left, red] (476);
    \end{tikzpicture}
\end{minipage}\hfill
\begin{minipage}{0.55\textwidth}
    Now we add two children: $17$ and $476$.
    Clearly, $17$ becomes the left child because $17 < 23$, and $476$ becomes the right child because $476 > 23$.
\end{minipage}

\begin{minipage}{0.35\textwidth}
    \begin{tikzpicture}[
      node distance = 1.5cm,
      level distance=1.5 cm,
      level 1/.style={sibling distance=3cm},
      level 2/.style={sibling distance=1.5cm},
      thick, minimum size=1cm]
      \node[circle,draw] {23}
	    child {
	    node [circle,draw]{17}
	    }
	    child{node[circle,draw]{476}
		    child{node[circle,draw](28){28}}
		    child[fill=none] {edge from parent[draw=none]}
	    };
      \path[->, >=stealth', shorten >=1pt, auto]
      (23) edge[bend left, red] (476)
      (476) edge [bend right, blue] (28);
    \end{tikzpicture}
\end{minipage}\hfill
\begin{minipage}{0.55\textwidth}
    What happens if we add $28$? Starting at the root, we move to the right because $28 > 23$.
    However, there is already a right subroot there!
    $28$ must then take $476$ as its parent node and, because $28 < 476$, it is placed as the left child of $476$.
\end{minipage}

To begin writing an insertion method for our \li{BinarySearchTree} class, we consider BST's themselves.
BSTs are a recursive data structure because each of the left and right subtrees of a parent node are, themselves, BSTs.
Therefore, many of the algorithms for working with binary search trees can also be recursive.
A recursive function is a function that calls itself until it reaches a base case.
In the case of a BST, the recursive function allows us to travel right or left as appropriate until we reach a missing subtree.
To supplement our \li{insert} method, we will write a recursive function to call within our insert function:
\begin{lstlisting}
def insert(self, data):
    def _recur_insert(node, item):
        # This is the base case; we have reached the proper node for insertion
        # and we now return the data as a Node to the previous function call,
        # setting it as the right or left node of its parent.
        if node is None:
            return Node(item)
        else:
            # Recursively travel through the tree until you reach a leaf node
            if item < node.value:
                node.left = _recur_insert(node.left, item)
            elif item > node.value:
                node.right = _recur_insert(node.right, item)

        # After the base case, each of the previous calls to the
        # recursive function finishes by returning the previous node.
        return node

    self.root = _recur_insert(self.root, data)
    self.size += 1
\end{lstlisting}
We call this recursive function and set it equal to the root node.
The function will continually call itself until it finds an empty node.
It inserts the data as a node, and then \li{return node} will finish each of the previous calls to the recursive function.
(It simply returns each of the parents it recursively visited prior, re-setting them equal to themselves, until it finally returns to \li{self.root}.)
Finally, we finish our insertion method by updating our size.

\subsection*{Searching}
Although recursive functions are often useful and intuitive with trees, we are by no means required to use them.
In fact, for large trees, a recursive algorithm may incur a large overhead.
When writing a method to search for nodes in a BST, we may either use recursion or an alternate method to ascertain whether a piece of data is to be found within the tree.

\begin{problem}
Add a method for finding nodes to your binary tree class. If a node containing your data exists within the tree, return the node.
If no such node exists, return \li{False}.
\label{prob:Finding Nodes}
\end{problem}

\subsection*{Removing}
Removing nodes is only slightly more complicated.
We have three cases to consider:
\begin{enumerate}
\item No children.
This is the most straightforward case.
If the node we want to delete has no children then we simply remove the node.
\begin{center}
\begin{minipage}{0.3\textwidth}
    \begin{tikzpicture}[
      level distance=1.5 cm,
      level 1/.style={sibling distance=3cm},
      level 2/.style={sibling distance=1.5cm},
      thick, minimum size=1cm]
      \node[circle,draw](23) {23}
	    child {
	    node [circle,draw](17){17}
	    }
	    child{node[circle,draw](476){476}
	    	child{node[circle,draw=red, fill=red!20!](28){28}}
	    	child[fill=none] {edge from parent[draw=none]}
	    };
    \end{tikzpicture}
\end{minipage}
\begin{minipage}{0.2\textwidth}
   \begin{center}
     \begin{tikzpicture}[]
        \draw[->, double, double equal sign distance, -implies, thick] (0,0) -- (1.25,0);
    \end{tikzpicture}
   \end{center}
\end{minipage}
\begin{minipage}{0.3\textwidth}
    \begin{tikzpicture}[
      level distance=1.5 cm,
      level 1/.style={sibling distance=3cm},
      level 2/.style={sibling distance=1.5cm},
      thick, minimum size=1cm]
      \node[circle,draw](23) {23}
	    child {
	    node [circle,draw](17){17}
	    }
	    child{node[circle,draw](476){476}
	    };
    \end{tikzpicture}
\end{minipage}
\end{center}

\item One child.
In this case, we have to worry about children.
If we were to just delete the node, we would lose the entire subtree.
The solution, however, is simple enough: we promote the single child to take the place of the node we are deleting.
This preserves the binary search property.
\begin{center}
\begin{minipage}{0.3\textwidth}
    \begin{tikzpicture}[
      level distance=1.5 cm,
      level 1/.style={sibling distance=3cm},
      level 2/.style={sibling distance=1.5cm},
      thick, minimum size=1cm]
      \node[circle,draw](23) {23}
	    child {
	    node [circle,draw](17){17}
	    }
	    child{node[circle,draw=red, fill = red!20!](476){476}
	    	child{node[circle,draw](28){28}}
	    	child[fill=none] {edge from parent[draw=none]}
	    };
     \path[->, >=stealth', shorten >=1pt, auto]
      (28) edge[bend left, red] (476);
    \end{tikzpicture}
\end{minipage}
\begin{minipage}{0.2\textwidth}
   \begin{center}
     \begin{tikzpicture}[]
        \draw[->, double, double equal sign distance, -implies, thick] (0,0) -- (1.25,0);
    \end{tikzpicture}
   \end{center}
\end{minipage}
\begin{minipage}{0.3\textwidth}
    \begin{tikzpicture}[
      level distance=1.5 cm,
      level 1/.style={sibling distance=3cm},
      level 2/.style={sibling distance=1.5cm},
      thick, minimum size=1cm]
      \node[circle,draw](23) {23}
	    child {
	    node [circle,draw](17){17}
	    }
	    child{node[circle,draw](28){28}
	    };
    \end{tikzpicture}
\end{minipage}
\end{center}
\item Two children.
We need to be a little careful in this case.
We can't simply promote a child node.
Indeed, how would we decide which child to promote?
Fortunately, we can reduce this case down to one of the previous two cases.
Suppose we are removing node $23$, which has two children.
We first locate either the smallest node of the right subtree or the greatest node of the left subtree.
In this case, we identify node $28$ as the smallest node in the right subtree.
Because $28$ is the smallest node of the right subtree, it cannot have a child to its left, which implies it either has one child to the right or no children at all.
We swap the data of nodes $28$ and $23$ (so node $28$ now has the data that $23$ had and vice versa).
This swap still preserves the binary search property of the tree and removing $23$ has been reduced to a simpler case.
\begin{minipage}{0.3\textwidth}
\begin{tikzpicture}[
  level distance=1.5 cm,
  level 1/.style={sibling distance=3cm},
  level 2/.style={sibling distance=1.5cm},
  thick, minimum size=1cm]
  \node[circle,draw=red, fill = red!20!](23) {23}
	child {
	node [circle,draw]{17}
	}
	child{node[circle,draw]{476}
		child{node[circle,draw](28){28}}
		child[fill=none] {edge from parent[draw=none]}
	};
  \path[->, >=stealth', auto]
     (23) edge[out = 5, in=15, blue, looseness=1.5] (28)
     (28) edge[bend left, red] (23);
\end{tikzpicture}
\end{minipage}
\begin{minipage}{0.2\textwidth}
   \begin{center}
     \begin{tikzpicture}[]
        \draw[->, double, double equal sign distance, -implies, thick] (0,0) -- (1.25,0);
    \end{tikzpicture}
   \end{center}
\end{minipage}
\begin{minipage}{0.3\textwidth}
    \begin{tikzpicture}[
      level distance=1.5 cm,
      level 1/.style={sibling distance=3cm},
      level 2/.style={sibling distance=1.5cm},
      thick, minimum size=1cm]
      \node[circle,draw](28) {28}
	    child {
	    node [circle,draw](17){17}
	    }
	    child{node[circle,draw](476){476}
	    };
    \end{tikzpicture}
\end{minipage}
\end{enumerate}

\begin{problem}
Provided below is a removal method for binary search trees.
The \li{_recur_remove} method takes two arguments: the parent node, n; and the candidate for removal, cand.
For this problem, edit the following code by inserting comments explaining each step of the removal method.

\begin{lstlisting}
def remove(self, item):
    def _recur_remove(n, cand):
        if n is None:
            return
        else:
            if cand < n.value:
                n.left = _recur_remove(n.left, cand)
            elif cand > n.value:
                n.right = _recur_remove(n.right, cand)
            elif cand == n.value:
                if n.left is None and n.right is None:
                    return
                elif n.left is not None and n.right is None:
                    nleft = n.left
                    del n
                    return nleft
                elif n.left is None and n.right is not None:
                    nright = n.right
                    del n
                    return nright
                else:
                    nmin = n.right
                    while nmin.left is not None:
                        nmin = nmin.left
                    n.value, nmin.value = nmin.value, n.value
                    n.right = _recur_remove(n.right, nmin.value)
                    return n
            return n
    if self.root is None:
        return
    else:
        self.root = _recur_remove(self.root, item)
    self.size -= 1
\end{lstlisting}
\label{prob:Binary Removal}
\end{problem}

If data we put in a binary search tree is ordered, we lose the efficiency advantage of these trees.
We can use a balanced binary search tree to avoid this issue and retain the efficiency of binary search trees for any kind of data.

\section*{Hash Tables}
A \emph{hash table} is a very simple data structure that trades memory space for speed.
The key advantage of a hash table is this speed; most of the operations of a hash table execute very efficiently, independent of its size.
As such, hash tables have very fast lookup times; they form the underlying data structure for Python's set and dictionary types.

One of the key components of a hash table is a \emph{hash function}.
A hash function takes a piece data as an input and outputs a natural number which corresponds to the index for that piece of data.
Since the hash function must be executed to perform any operation on the hash table (e.g. insertion or lookup), it is imperative that the hash function execute quickly.
Thus, the heart of a hash table is a good hash function.

We begin defining our \li{HashTable} class, then, by allocating space within a one-dimensional array (in this case, a Python list) and by taking both the array size and the hash function as arguments.
\begin{lstlisting}
class HashTable(object):
    def __init__(self, capacity):
        # Efficiently extend a list to the designated hash table size
        self.hashtable = [None] * capacity
        # Keeps track of the number of elements within the hash table
        self.size = 0
        # Indicates the size of the hash table
        self.capacity = capacity

    def load_factor(self):
        # The load factor tells how saturated a hash table is
        return float(self.size)/self.capacity
\end{lstlisting}

A good hash function will execute quickly and distribute items uniformly throughout the table.
In the hash tables in this lab, we will use Python's built-in \li{hash} function.
This code demonstrates the principle steps of inserting into a hash function.
Instead of using our \li{HashTable} class, however, we simply use a similar construct to show how the steps might be implemented in a specific instance:
\begin{lstlisting}
>>> capacity = 5
>>> table = [None] * capacity
>>> hash('three')
8354070563160704301
>>> hash('three') % capacity
1
>>> table[1] = 'one'
>>> print table
[None, 'three', None, None, None]
>>> table[hash('four') % capacity] = 'four'
>>> table[hash('five') % capacity] = 'five'
>>> print table
['four', 'three', 'five', None, None]

# We can locate 'five' quickly
# Notice that is faster than the list's builtin methods
>>> %timeit table.index('five')
1000000 loops, best of 3: 190 ns per loops
>>> %timeit table[hash('five') % capacity]
10000000 loops, best of 3: 111 ns per loop
>>> table[hash('two') % capacity] = 'two'
# Note that our load factor is 4/5.
>>> print table
['four', 'three', 'five', 'two', None]

# When our load factor passes a certain threshold, we need to make the hash table bigger
# Resizing the hash table means rehashing everything in it
>>> def resize(table, new_cap):
        new_table = [None] * new_cap
        for i in table:
            new_table[hash(i) % new_cap] = i
        return new_table
>>> table = resize(table, 7)
>>> print table
[None, None, None, 'two', None, None, 'four']
\end{lstlisting}

The ideal hash function maps unique inputs to unique outputs that are uniformly distributed over the hash space.
However, it is extremely difficult to create an ideal hash function; most hash functions will experience hash collisions.
Hash collisions are when two unique inputs are mapped to the same index in the hash table (in our example above, resizing the hash table resulted in hash collisions that lost half the strings we stored in the table).
Fortunately, there are ways to handle hash collisions.

\paragraph{Probing.}
One method that we can use to resolve hash collisions is probing.
A short example will be succintly illustrate this method.
\begin{lstlisting}
>>> capacity = 5
>>> table = [None] * capacity
# Now we add the words 'one' and 'two'
# Notice what happens when we add 'two'
>>> table[hash('one') % capacity] = 'one'
>>> print table
[None, None, None, 'one', None]
>>> table[hash('two') % capacity]
'one'

# We can resolve the collision by looking for the next available index
# Starting at index 3, we look at index 3+1 % capacity, 3+2 % capacity, 3+3 % capacity, ..., until we find and empty index
# Seeing that index 4 is None, we store 'two' there
>>> table[4] = 'two'
>>> print table
[None, None, None, 'one', 'two']
\end{lstlisting}
This is called linear probing.
There are other variations of this idea which are more optimal.

\paragraph{Chaining.}
Another method for resolving hash collisions is chaining.
This method slightly alters the structure of our hash table, so that at each index, a list is stored.
When an item is mapped to an index, it is appeneded to the list at that index.
\begin{lstlisting}
>>> capacity = 5
>>> table = [list() for i in xrange(capacity)]

# Now we add the words 'one' and 'two'
# Notice what happens when we add 'two'
>>> table[hash('one') % capacity].append('one')
>>> print table
[[], [], [], ['one'], []]
>>> table[hash('two') % capacity].append('two')
>>> print table
[[], [], [], ['one', 'two'], []]
\end{lstlisting}

\begin{problem}
Using the concepts illustrated in the examples above, and an insert method to your \li{HashTable} class.
Don't forget to update your size for the number of elements within the hashtable!
Use chaining to handle hash collisions (namely, implement your insert method via chaining).

Then, create a method for your hash table to resize.
Implement this method such that, when your hash table exceeds a load factor of $.8$, it will resize the hash table so that the load factor is below $.3$.
Don't forget to rehash the elements already within your table!

Initialize a hash table of size 4 and insert the following felines: `lion', `tiger', `cheetah', `cougar', `colocolo', `cat', `clouded leopard', and `jaguar'.
Print your hash table.
\label{prob:hash_table}
\end{problem}

\begin{info}
Usually exisiting implementations of data structures are better to use.
The implementations of linked lists, trees, and hash tables in this lab were designed to familiarize you with the data structure's mechanics through example and practice.
In real situations, you will likely use Python's deques, sets, or dictionaries.
Python doesn't have a built-in implementation of trees, but there are several Python libraries that have highly optimized implementations of trees.

Performance tuning for data structures can be tricky even for professionals.
For this reason, it is better to avoid writing your implementation when one already exists.
\end{info}


\section{Throwing Booth}
\label{sec:booth}
The booth is constructed from Item aluminium profiles.
The background of the images shall remain the same, regardless of the current location.
Therefore, a white side wall opposite the camera is used.
When creating the booth design, care was taken to ensure that the size corresponds to the width of a table (\SI{750}{mm}).
This also defined the distance between the camera and the side wall.
With the opening angle of the lens, the minimum required size of the rear wall can be calculated as in equation \ref{eq:Fieldwith}.
This size is called field of view.

\begin{equation}
	f_\text{w} = 2 \cdot a \cdot \tan\left( \frac{\vartheta}{2}\right) = \SI{690}{mm}
	\label{eq:Fieldwith}
\end{equation}

\begin{tabular}{rl}
	$f_\text{w} =$ & width of the field of view \\
	$a =$ & distance camera to side panel = \SI{630}{mm} \\
	$\vartheta =$ & horizontal angle of view = \SI{57.4}{\degree} \cite{baumer_lense} \\
\end{tabular}

%Whereby the following applies:
%\begin{itemize}
%	\item $f_\text{w}$ = width of the field of view
%	\item $a$ = Distance camera to back panel = \SI{630}{mm}
%	\item $\vartheta$ = horizontal angle of view = \SI{57.4}{\degree} \cite{baumer_lense}
%\end{itemize}

Given that the picture format is 1280 $\times$ \SI{1024}{px}, the height of the field of view $f_\text{h}$ is equal to

\begin{equation}
	f_\text{h} = f_\text{w} \cdot \frac{\SI{1024}{px}}{\SI{1280}{px}} = \SI{552}{mm}.
	\label{eq:Fieldhight}
\end{equation}

The objects should be thrown as far away from the camera as possible to be able to take more pictures per throw.
To ensure that the objects are thrown through the field of view and as far away from the camera as possible, there is a hole in the rear wall as a target.
It is located on the right side of the rear wall, which is further away from the camera.
If the objects are shot through the hole in the rear wall, they end up in a net.

The rear panel is made of a \SI{5}{mm} thick ABS plate.
This material is robust and withstands the impacts of the throwing objects.
The side wall is made of foamed PVC.
Due to the manufacturing process, the plate is less smooth, which results in less light reflections and therefore better pictures.
The drawings of the two plates can be found in appendix \ref{app:drawings_rear_panel} and \ref{app:drawings_side_panel}.

The whole throwing booth is drawn in the CAD tool Inventor. It is designed with all its components using a 3D model.
The camera is mounted on an Item profile with an aluminum mounting adapter which is shown in figure \ref{fig:mounting_adapter} and protected from damage with an aluminum sheet.
Both components have slotted holes to allow fine adjustments during assembly.
The drawings of these parts can be found in appendix \ref{app:drawings_camera_protection} and \ref{app:drawings_mounting_adapter}.

\begin{figure}[h]
	\centering
	\includegraphics[width=0.4\textwidth]{graphics/mounting_adapter.png}
	\caption{Camera mounting adapter}
	\label{fig:mounting_adapter}
\end{figure}
\clearpage
The power supplies for all electronic components are placed in a box together with the Ultra96-V2.
The box is a case from Fibox with a transparent cover to give visitors an impression of the way it works.
It features a \SI{230}{VAC} power cable, a \SI{24}{VDC} output for lighting, a Mini DisplayPort cable for the monitor and the USB cable for the camera.
In addition, there are three fans on the walls to ensure that the Ultra96-V2 is cooled.
The box also contains terminal blocks and cable trunking to store cables that are too long.
Figure \ref{fig:fibox3d} shows a 3D model of the box. The construction drawings for the Fibox case can be found in appendix \ref{app:drawings_fibox_bottom}.

\begin{figure}[h]
	\centering
	\includegraphics[width=0.6\textwidth]{graphics/case.png}
	\caption{3D model of the Fibox case}
	\label{fig:fibox3d}
\end{figure}