\documentclass{article}

% the purpose of this particular document is to serve as a staging area potential blog posts, for the purpose of editing, revision, and review.

% packages
	\usepackage{amsmath, amsthm, mathtools}
	\usepackage{mdframed}
	\usepackage{geometry, enumerate}
	\usepackage{parskip}
	\usepackage{graphicx}

% theorems and such
  	\newtheorem{theorem}{Theorem}
  	\newtheorem{corollary}{Corollary}
  	\newtheorem{lemma}[theorem]{Lemma}
  	\newtheorem*{remark}{Remark}
  	\newtheorem*{exe}{Exercise}
  	\newtheorem{prop}{Proposition}

% custom commands
	\newcommand{\ceil}[1]{\left \lceil #1 \right \rceil}
	\newcommand{\floor}[1]{\lfloor #1 \rfloor}
	\newcommand{\X}[1]{\, \text{mod} \, #1}
	\newcommand{\divv}{\,|\,}
	\newcommand{\GCD}[2]{GCD\,(#1, #2)}
	\newcommand{\LCM}[2]{LCM\,(#1, #2)}

\begin{document}

\title{Elementary Number Theory : \S 1}
\author{Henry Slayer $|$ University of California, Santa Cruz}
\date{}
\maketitle

\section*{The Euclidean Algorithm}
The first scientific study of the numbers is typically attributed to the Greeks, who began classifying and categorizing the numbers (odd, even, etc…) in around 600 BC. It is Euclid, however, who transformed the theory of numbers into a deductive science. His \textit{Elements} was truly a master work of geometry and number theory, and in Book VII, the Euclidean Algorithm was born. Euclid's algorithm is an iterated process of division with remainder on two positive integers. Though simple, it is the foundation upon which much of number theory stands. For more on the \textit{Elements}, David Joyce has an interactive (albeit dated) browser version of the text, with Java applets to boot.
\begin{verbatim} https://mathcs.clarku.edu/~djoyce/java/elements/elements.html
\end{verbatim}

For what follows, we’ll take a leaf out of Weissman’s book, and start by exploring the dynamic nature of numbers in pairs. In other words, if we treat numbers as moves or units of measure, where can we go? What can we scale? The answer will lead us right into the hands of Euclid’s numerical disassembly.
\subsubsection*{Compound Moves}
The dynamic interpretation of division with remainder is best served by an example. Suppose we have two measuring sticks, one that measures 61 units, and another that measures 39 units. Using only these two rulers, what can we measure? All multiples of 39 and 61, surely, but we can do better. How? We build a new measuring stick out of our first two. Lining up the two side-by-side, we can measure out a new ruler, from the difference, which is 61 - 39 = 22 units long. Nice! Now, we can measure anything that’s 61, 39, or 22 units long. What if we did it again? Taking the smaller of our two original numbers, we could use the difference of the 39-unit rule and the 22-unit rule to measure out lengths of 17.

\begin{figure}[h!]
%\begin{mdframed}
	\center{\includegraphics[width=.8\textwidth]
		{figEA.png}}
%\end{mdframed}
\end{figure}
And again, taking the 22 unit rule and the 17 unit rule, we get down to a precision of 5. If we take 3 of our new 5-unit rulers, we can compare the three stacked together to the 17 unit rule and measure lengths of 2. Taking two of the two unit rules with 5 gets us down to a single unit. Scaling our single-unit ruler allows us to measure anything that we want.

Fundamentally, the Euclidean algorithm is no different. It is an iterative process of division with remainder. The steps that we took above are the same steps as the Euclidean algorithm, just written down a bit differently. In fact, if we wanted to formalize our process above, we would write
\begin{align*}
	61 &= 1(39) + 22\\
	39 &= 1(22) + 17 \\
	22 &= 1(17) + 5 \\
	17 &= 3(5) + 2 \\
	5 &= 2(2) + 1
\end{align*}

\subsubsection*{The Euclidean Algorithm}

The Euclidean algorithm starts with two positive integers, $a$ and $b$. Assuming $a > b$, our first line step is to break down $a$ using division with remainder.
\[a = q(b) + r\]
Where $r$ is a whole remainder, and $0 \leq r < b$. The only rule that we follow, for now, is that $r$ is the least possible remainder. (The Euclidean algorithm actually comes in two flavors, as we’ll see, but for now, we assume that our remainders are whole, positive numbers).
Then, we swap. The divisor ($b$) becomes the dividend (formerly $a$), and we divide our new divisor by the previous remainder.
That can be a little tricky in words, but it’s swingin’ in practice.
In equations:

\begin{align*}
a &= q_1(b) + r_1 \\
b &= q_2(r_1) + r_2 \\
r_1 &= q_3(r_2) + r_3)\\
&\vdots \\
r_{f-2} &= q_{f}(r_{f-1}) + r_f \\
r_{f-1} &= q_{f+1}(r_f) + 0
\end{align*}

When the remainder is zero (and we always reach zero because of the well-ordering principle) the process is over, and we stop.

% provide another example here… maybe one with small numbers and one with large numbers

\subsubsection*{The Euclidean Algorithm and the GCD}

The Euclidean Algorithm is a powerful tool for systematically obtaining the greatest common divisor of two integers.
We mentioned the greatest common divisor last time, but to review, the GCD of two integers a and b is another number g with the following properties:
\begin{enumerate}[(i)]
\item g is a common divisor of a and b
\item if a and b have any other common divisors, those divisors also divide g
\end{enumerate}
We can make several observations about the greatest common divisor.
\begin{mdframed}
\begin{lemma} Let $a$ be an integer. Then
\[GCD(a, 0) = a\]
\end{lemma}
\begin{proof} Everything divides zero. That is to say, zero is a multiple of anything (we just multiply by zero). The greatest divisor of a is a itself. So, the greatest divisor of any integer a and 0 will be a itself.
\end{proof}
\end{mdframed}
\begin{mdframed}
\begin{lemma}Suppose a, b, q, r are integers such that a = q(b) + r. Let g be another number. Then, g is the greatest common divisor of a and b if and only if g is the greatest common divisor of b and r.
\end{lemma}
\begin{proof}
Fill in.
\end{proof}
\end{mdframed}
These two lemmas tie the Euclidean algorithm to the greatest common divisor.
\begin{mdframed}
\begin{theorem}
Assume a and b are natural numbers, at least one of which is nonzero. Then, the final nonzero remainder produced by applying the Euclidean algorithm to a and b is the greatest common divisor of a and b.
\end{theorem}
\begin{proof} In the terminal line of the euclidean algorithm, we see something of the sort
\[a_n = q_n(b_n) + 0\]
where $b_n$ is the final nonzero remainder. By what we’ve shown previously, $GCD(b_n, 0) = 0$. So, we walk up a line, which gives
\[a_{n-1} = q_{n-1}(a_n) + b_n\]
Then, by the second lemma, the \(GCD(a_{n-1}, a_n) = GCD(a_n, b_n) = GCD(b_n, 0) = b_n\).
Iterating this up our chain of divisions, we find that \(GCD(a, b) = \cdots = GCD(b_n, 0) = b_n\), the final nonzero remainder.
\end{proof}
\end{mdframed}
\subsubsection*{GCD / LCM Product Formula}

We’ll close by examining some of the properties of the greatest common divisor, as well as the least common multiple.
The least common multiple ($LCM$) of two integers is another integer $l$, such that $l$ is a multiple of both $a$ and $b$ ($b\divv l$, $a\divv l$), such that any other multiple of $a$ and $b$ is larger. That is, if there exists some other multiple $m$, $l\divv m$.

The greatest common divisor, the least common multiple, and the numbers that they’re defined by are all intimately related.
\begin{mdframed}
\begin{theorem} Let a and b be positive integers. Then
	\[GCD(a, b) \cdot LCM(a, b) = ab\]
\end{theorem}
\begin{proof}  Let $GCD$ and $LCM$ denote the greatest common divisor and least common multiple, respectively, of a and b. The $GCD$ is a divisor of both $a$ and $b$, and the $LCM$ is a multiple of both $a$ and $b$, so
\begin{align*}
a = n\cdot GCD \quad&\quad b = m \cdot GCD \\
LCM = x \cdot a \quad&\quad LCM = y \cdot b \\
\end{align*}
The $LCM$ is a multiple of $a$ and $b$, so it must be a multiple of $ab$ for some integer $g$. Similarly, we see that the $GCD$ of $a$ and $b$ is also a multiple of $ab$. So, with $g$ and $l$ as integers,
\begin{align*}
ab &= nm \cdot GCD = l \cdot GCD \\
ab &= LCM \cdot g
\end{align*}
Using these  6 relations, we can deduce the following:
\begin{align*}
ab = LCM \cdot g &= x \cdot a \cdot g  \quad \Rightarrow \quad  b = gx \\
ab = LCM \cdot g &= y \cdot b \cdot g  \quad \Rightarrow \quad  a = gy
\end{align*}
So, $g\divv a$, $g\divv b$, and by definition, $g\divv GCD$.
Secondly, we can observe that
\[ab = l \cdot GCD \quad\Rightarrow am = l\]
\[ab = l \cdot GCD \quad\Rightarrow  bn = l\]
So, l is a common multiple of both a and b. By definition, then, $a\divv l$, $b\divv l$, and $LCM\divv l$.
Now, we can assemble a tower of divisibilities.
\begin{enumerate}[]
\item $a = g \cdot LCM$ and $g\divv GCD$, so, $a = (g \cdot LCM) \divv (GCD \cdot LCM)$
\item Similarly, the $LCM\divv l$ as $l$ is a common multiple of $a$ and $b$, and $GCD\cdot l = ab$
\end{enumerate}
Thus:
\[ab = (g \cdot LCM) \divv (GCD \cdot LCM) \divv (GCD \cdot l) = ab\]
The $ab$ bookends tell us that all of the terms in the middle must be equal, and  $ab = LCM \cdot GCD$, as desired.
\end{proof}
*Note* For the greatest common divisor, $\GCD{a}{b} = \GCD{|a|}{|b|}$
\end{mdframed}

\subsubsection*{Other GCD / LCM Properties}
The $GCD$ and $LCM$ are relatively predictable under uniform scaling, which leads us to the next two results. We’ll be able to say even more about the $GCD$ and $LCM$ after we study prime factorization.

\begin{mdframed}
\begin{prop} Let $g$, $a$, and $b$ be integers, with $g > 0$. Then
\[\GCD{ga}{gb} = g\cdot\GCD{a}{b}\]
\end{prop}
\begin{proof} Clearly, $g$ is a common divisor of both $ga$ and $gb$. Consequently, the \textit{greatest} common divisor of $ga$ and $gb$ must take the form $g\cdot d$, where $d$ is a common divisor of $a$ and $b$. $g\cdot d$ will reach a maximum value when $d$ is the greatest divisor shared between $a$ and $b$, which is precisely $\GCD{a}{b}$. So,
\[\GCD{ga}{gb} = g\cdot\GCD{a}{b}\]
We can verify this with the $GCD/LCM$ product theorem.
\end{proof}
\end{mdframed}

\begin{mdframed}
\begin{corollary}
Suppose that $a$ and $b$ are nonzero integers, and $g = \GCD{a}{b}$. Then
\[GCD \bigg(\frac{a}{g}\,, \,\frac{b}{g}\bigg) = 1\]
\end{corollary}
\begin{proof}
Apply $g$ to each side. The rest follows from Proposition 1.
\[g\cdot GCD \bigg(\frac{a}{g}\,, \,\frac{b}{g}\bigg) = 1\cdot g \]
\[GCD \bigg(\frac{a\cdot g}{g}\,, \,\frac{b\cdot g}{g}\bigg) = g\]
\[\GCD{a}{b} = g \]
\end{proof}
\end{mdframed}

% need to cite weissman's source here
\begin{mdframed}
\begin{exe} Let $a$ and $b$ be nonzero positive integers. Then, $\GCD{a}{b} = 1$ if and only if $\GCD{a^2}{b^2} = 1$.
\end{exe}
\begin{proof}
\end{proof}
\end{mdframed}

\end{document}


% Created 2017-02-22 Wed 11:51
% Intended LaTeX compiler: pdflatex
\documentclass[presentation]{beamer}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{grffile}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\usetheme{Madrid}
\author{Clarissa Littler}
\date{\today}
\title{If all math was computable\ldots{}}
\hypersetup{
 pdfauthor={Clarissa Littler},
 pdftitle={If all math was computable\ldots{}},
 pdfkeywords={},
 pdfsubject={},
 pdfcreator={Emacs 24.5.1 (Org mode 9.0.3)},
 pdflang={English}}
\begin{document}

\maketitle

\section{Talk}
\label{sec:org2e66927}

\begin{frame}[label={sec:orge0c899c}]{You wake up}
\end{frame}
\begin{frame}[label={sec:org6560e10}]{Programming class}
\begin{block}{}
\end{block}
\end{frame}
\begin{frame}[label={sec:orgbc548ad}]{Anti-virus}
\begin{block}{A virus is a self-replicating program}
\end{block}
\end{frame}

\begin{frame}[label={sec:org66acbfc}]{The new Hello World}
\begin{block}{Travelling Salesman}
\begin{center}
\includegraphics[width=.9\linewidth]{2000px-Hamiltonian_path.svg.png}
\end{center}
\end{block}
\end{frame}
\begin{frame}[label={sec:orge85e13e}]{Banking}
\begin{block}{Dedicated lines}
\begin{center}
\includegraphics[width=.9\linewidth]{Telegraph_Cable_Office.jpg}
\end{center}
\end{block}
\end{frame}
\begin{frame}[label={sec:org3aa09b8}]{Who uses passwords?}
\begin{block}{}
\end{block}
\end{frame}
\begin{frame}[label={sec:org7667ee8}]{Choice}
\end{frame}
\begin{frame}[label={sec:org7047978}]{Reverse engineering}
\end{frame}
\begin{frame}[label={sec:org275239c}]{Intellectual property}
\begin{center}
\includegraphics[width=.9\linewidth]{Felix_3D_Printer_-_Printing_Head.JPG}
\end{center}
\end{frame}
\begin{frame}[label={sec:org0e6d1fc}]{\ldots{}wait?}
\begin{block}{}
Something occurs to you
\end{block}
\end{frame}
\begin{frame}[label={sec:orge643353}]{Finite programs}
\begin{block}{}
Finite keyboards + finite length = countable number of programs
\end{block}
\end{frame}
\begin{frame}[label={sec:orgadc44d3}]{Reals and Integers}
\begin{block}{All the real numbers between 0 and 1}
\begin{center}
\begin{tabular}{lllll}
\(a_1\) & \(a_2\) & \(a_3\) & \(a_4\) & \ldots{}\\
\(b_1\) & \(b_2\) & \(b_3\) & \(b_4\) & \ldots{}\\
\(c_1\) & \(c_2\) & \(c_3\) & \(c_4\) & \ldots{}\\
\(d_1\) & \(d_2\) & \(d_3\) & \(d_4\) & \ldots{}\\
\ldots{} & \ldots{} & \ldots{} & \ldots{} & \ldots{}\\
\end{tabular}
\end{center}
\end{block}
\end{frame}
\begin{frame}[label={sec:orga059993}]{A table of programs}
\end{frame}
\begin{frame}[label={sec:org31e98b8}]{If we fuss with the diagonal}
\end{frame}
\begin{frame}[label={sec:orgd75fb14}]{A program that can't exist}
\end{frame}
\begin{frame}[label={sec:org2489ca5}]{You wake up}
\end{frame}
\begin{frame}[label={sec:org75bb20e}]{The Real World: Programming is \alert{hard}}
\end{frame}
\begin{frame}[label={sec:org88b31cc}]{The Real World: Programming is \alert{finite}}
\begin{block}{The finite nature of}
\end{block}
\end{frame}
\begin{frame}[label={sec:org1c34829}]{Thank you}
\begin{block}{}
{\Huge
Thank you for coming out!
}
\end{block}
\end{frame}
\end{document}


\chapter{Orthorectification and Map Projection}\label{sec:Ortho}

\begin{figure}[h]
  \begin{tikzpicture}[scale=0.25]
    \tiny
    \draw[fill=black!10] (-1,-12) rectangle (53,17);
     \foreach \x in {5,...,1}
       \draw[fill=red] (\x,\x) rectangle +(4,4);
     \node[fill=black!10, text width= 1.2cm] (InputSeries) at
       (3,-1) {Input Series};

     \draw[->,thick] (9,5) --  +(3,0);

     \draw[fill=black!30,rounded corners=2pt] (12.2,3) rectangle +(6,4);
     \node[text width= 0.7cm] (SensorModel) at (15,5) {Sensor Model};

     \draw[fill=red!30] (1,-10) rectangle +(4,4);
     \node[fill=black!10, text width= 1.2cm] (DEM) at
       (5,-11) {DEM};

     \draw[->,thick] (3,-5.5) --  ++(0,3) -- ++(12,0) -- ++(0,5);

     \draw[->,thick] (18.5,5) --  +(3,0);

     \foreach \x in {5,...,1}
       \draw[fill=blue,xshift=600pt] (\x,\x) rectangle +(4,4);
     \node[fill=black!10, text width= 2.8cm] (GeographicGeometry) at
       (28,-1) {Geographic Geometry};

       \draw[->,thick] (25.5,8.5) --  +(0,3);

     \draw[fill=black!30,rounded corners=2pt] (22,12) rectangle +(6.5,4);
     \node[text width= 0.7cm] (HomPoExtr) at (24,14) {Homologous
     Points};

     \draw[->,thick] (21.5,14) --  +(-2.5,0);

     \draw[fill=black!30,rounded corners=2pt] (12,12) rectangle +(6.5,4);
     \node[text width= 1.3cm] (BBAdj) at (15.5,14) {Bundle-block
     Adjustment};

     \draw[->,thick] (15,11.5) --  +(0,-4);

      \draw[->,thick] (30,5) --  +(3,0);

     \draw[fill=black!30,rounded corners=2pt] (33.2,3) rectangle +(6,4);
     \node[text width= 0.7cm] (MapProjection) at (36,5) {Map Projections};

     \draw[->,thick] (39.5,5) --  +(3,0);

     \foreach \x in {5,...,1}
       \draw[fill=green,xshift=1200pt] (\x,\x) rectangle +(4,4);
     \node[fill=black!10, text width= 1.8cm] (CartographicGeometry) at
       (47,-1) {Cartographic Geometry};

     %\draw[->,thick] (36,2) --  ++(0,-10) -- ++(-30,0);

  \end{tikzpicture}
  \itkcaption[Image Ortho-registration Procedure]{Image Ortho-registration Procedure.}
\label{fig:ImageOrtho-registrationProcedure}
\end{figure}

This chapter introduces the functionnalities available in OTB for
image ortho-registration. We define ortho-registration as the
procedure allowing to transform an image in sensor geometry to a
geographic or cartographic projection.\\

Figure \ref{fig:ImageOrtho-registrationProcedure} shows a synoptic
view of the different steps involved in a classical ortho-registration
processing chain able to deal with image series. These steps are the following:
\begin{itemize}
  \item Sensor modelling: the geometric sensor model allows to convert
  image coordinates (line, column) into geographic coordinates
  (latitude, longitude); a rigorous modelling needs a digital
  elevation model (DEM) in order to take into account the terrain
  topography.
  \item Bundle-block adjustment: in the case of image series, the
  geometric models and their parameters can be refined by using
  homologous points between the images. This is an optional step and
  not currently implemented in OTB.
  \item Map projection: this step allows to go from geographic
  coordinates to some specific cartographic projection as Lambert,
  Mercator or UTM.
\end{itemize}

\section{Sensor Models}
\ifitkFullVersion
\label{sec:SensorModels}
\fi

A sensor model is a set of equations giving the relationship between
image pixel $(l,c)$ coordinates and ground $(X,Y)$ coordinates for every
pixel in the image. Typically, the ground coordinates are given in a
geographic projection (latitude, longitude). The sensor model
can be expressed either from image to ground -- forward model -- or
from ground to image -- inverse model. This can be written as follows:

\begin{displaymath}
  \begin{array}{cc}
    Forward & \\
    X = f_x(l,c,h,\vec\theta) & Y = f_y(l,c,h,\vec\theta)\\
     & \\
    Inverse & \\
    l = g_l(X,Y,h,\vec\theta) & c = g_c(X,Y,h,\vec\theta)
  \end{array}
\end{displaymath}

Where $\vec\theta$ is the set of parameters which describe the sensor
and the acquisition geometry (platform altitude, viewing angle, focal
length for optical sensors, doppler centroid for SAR images, etc.).\\

In OTB, sensor models are implemented as \doxygen{itk}{Transform}s
(see section \ref{sec:Transforms} for details), which is the
appropriate way to express coordinate changes. The base class for
sensor models is \doxygen{otb}{SensorModelBase} from which the classes
\doxygen{otb}{InverseSensorModel} and
\doxygen{otb}{ForwardSensorModel} inherit.\\

As one may note from the model equations, the height of the ground, $h$,
must be known. Usually, it means that a Digital Elevation Model,
DEM, will be used.\\

\subsection{Types of Sensor Models}
\label{sec:TypesofSensorModels}
There exists two main types of sensor models. On one hand, we have the
so-called {\em physical models}, which are rigorous, complex,
eventually highly non-linear equations of the sensor geometry. As
such, they are difficult to inverse (obtain the inverse model from the
forward one and vice-versa). They have the significant advantage of having
parameters with physical meaning (angles, distances, etc.). They are
specific of each sensor, which means that a library of models is
required in the software. A library which has to be updated every time a new
sensor is available.\\

On the other hand, we have general analytical models, which
approximate the physical models. These models can take the form of
polynomials or ratios of polynomials, the so-called rational
polynomial functions or Rational Polynomial Coefficients, RPC, also
known as {\em Rapid Positioning Capability}.
Since they are approximations, they are less accurate than the
physical models. However, the achieved accuracy is usually high: in
the case of Pl\'eiades, RPC models have errors lower than 0.02 pixels
with respect to the physical model. Since these models have a standard
form they are easier to use and implement. However, they have the
drawback of having parameters (coefficients, actually) without
physical meaning.\\

OTB, through the use of the OSSIM library --
\url{http://www.ossim.org} -- offers models for most of current
sensors either through a physical or an analytical approach. This is
transparent for the user, since the geometrical model for a given
image is instantiated using the information stored in its meta-data. The
search for a sensor model is not straightforward. It is done in 3 steps :
\begin{enumerate}
  \item Search in the OSSIM plugin factory for a suitable model
(\code{ossimplugins::ossimPluginProjectionFactory}). For instance, this
factory contains Pl\'eiades and TerraSar sensor models.
  \item If no model was found, search in the OSSIM projection factory
(\code{ossimProjectionFactoryRegistry}). For instance this factory contains
Spot5, Landsat and Quickbird sensor models.
  \item If still no model was found, search for a valid sensor model defined
 in an external \code{.geom} file. If no model is found, check if there are
any RPC tags embedded within the image (GDAL is used to detect those RPC
tags). When the tags are present, an \code{ossimRpcModel} is created.
\end{enumerate}

\subsection{Using Sensor Models}
\label{sec:UsingSensorModels}

The transformation of an image in sensor geometry to geographic
geometry can be done using the following steps.
  \begin{enumerate}
    \item Read image meta-data and instantiate the model with the
    given parameters.
  \item Define the ROI in ground coordinates (this is your output
  pixel array)
  \item Iterate through the pixels of coordinates $(X,Y)$:
    \begin{enumerate}
      \item Get $h$ from the DEM
      \item Compute $(c,l) = G(X,Y,h,\vec\theta)$
      \item Interpolate pixel values if $(c,l)$ are not grid coordinates.
    \end{enumerate}
  \end{enumerate}

Actually, in OTB, you don't have to manually instantiate the sensor
model which is appropriate to your image. That is, you don't have to
manually choose a SPOT5 or a Quickbird sensor model. This task is
automatically performed by the \doxygen{otb}{ImageFileReader} class in
a similar way as the image format recognition is done. The appropriate
sensor model will then be included in the image meta-data, so you can
access it when needed.

\ifitkFullVersion
\input{SensorModelExample.tex}
\fi

\subsection{Evaluating Sensor Model}
\label{sec:EvaluatingSensorModels}

If no appropriate sensor model is available in the image meta-data,
OTB offers the possibility to estimate a sensor model from the image.

\input{EstimateRPCSensorModelExample.tex}

\subsection{Limits of the Approach}
\label{LimitsoftheApproach}

As you may understand by now, accurate geo-referencing needs accurate
DEM and also accurate sensor models and parameters. In the case where
we have several images acquired over the same area by different
sensors or different geometric configurations, geo-referencing (geographical coordinates) or ortho-rectification
(cartographic coordinates) is not usually enough. Indeed, when working
with image series we usually want to compare them (fusion, change
detection, etc.) at the pixel level.\\

Since common DEM and sensor parameters do not allow for such an
accuracy, we have to use clever strategies to improve the
co-registration of the images. The classical one consists in refining
the sensor parameters by taking homologous points between the images
to co-register. This is called bundle block adjustment and will be
implemented in coming versions of OTB.

Even if the model parameters are refined, errors due to DEM accuracy
can not be eliminated. In this case, image to image registration can
be applied. These approaches are presented in chapters
\ref{chap:ImageRegistration} and \ref{sec:DisparityMapEstimation}.

%% \section{Bundle-block adjustment}
%% Problem position
%%   \begin{itemize}
%%     \item The image series is geo-referenced (using the available DEM,
%%     and the prior sensor parameters).
%%     \item We assume that homologous points (GCPs, etc.) can be easily
%%     obtained from the geo-referenced series : $HP_i = (X_i,Y_i,h_i)$
%%     \item For each image, and each point, we can write:
%%     $(l_{ij},c_{ij}) = G_j(X_i,Y_i,h_i,\vec\theta_j)$
%%   \end{itemize}

%% \begin{tikzpicture}[scale=0.15]
%% \draw[fill=yellow!20] (-5.5,-15.5) rectangle (5.5,-5.5);
%%     \draw[step=0.5, gray, very thin] (-5.5,-15.5) grid (5.5,-5.5);

%%     \draw[fill=green!20,rotate=10] (-15.5,0.5) rectangle (-5.5,10.5);
%%     \draw[step=0.5, gray, very thin,rotate=10] (-15.5,0.5) grid>
%%     (-5.5,10.5);

%%     \draw[fill=blue!20,rotate=-10] (5.5,0.5) rectangle (15.5,10.5);
%%     \draw[step=0.5, gray, very thin,rotate=-10] (5.5,0.5) grid
%%     (15.5,10.5);

%%     \draw[fill=red!70] (1,-11) circle (0.2);

%%     \draw (1,-11) .. controls +(30:1cm) and +(60:1cm) .. (-10,7);

%%     \draw[fill=red!70] (-10,7) circle (0.2);

%%     \node (eq1) at (-12.2,-4) {$\scriptstyle{G_1(X_i,Y_i,h_i,\vec\theta_1)}$};

%%     \draw (1,-11) .. controls +(-30:1cm) and +(-60:1cm) .. (10,7);

%%     \draw[fill=red!70] (10,7) circle (0.2);

%%     \node (eq2) at (7.2,-3) {$\scriptstyle{G_2(X_i,Y_i,h_i,\vec\theta_2)}$};

%% \end{tikzpicture}
%% \begin{itemize}
%%       \item Everything is known.
%% \end{itemize}

%% Model refinement
%%   \begin{itemize}
%%     \item If we define $\vec\theta_j^R = \vec\theta_j +
%%     \vec{\Delta\theta_j}$ as the refined parameters,
%%     $\vec{\Delta\theta_j}$ are the unknowns of the model refinement
%%     problem.
%%     \item We have much more equations than unknowns if enough HPs are
%%     found.
%%     \item We solve using non-linear least squares estimation.
%%       \begin{itemize}
%% 	\item The derivatives of the sensor model with respect to its
%% 	parameters are needed.
%%       \end{itemize}
%%   \end{itemize}

%% Homologous point extraction
%% From manual to automatic procedures
%% \begin{itemize}
%%   \item Manual extraction can be used for a few images and for a few
%%   points
%%   \item We are interested in many images (long time series) and many
%%   points (in order to reduce registration errors)
%%   \item Proposed procedure
%%     \begin{enumerate}
%%       \item Choose candidate points
%%       \item Define a similarity measure
%%       \item Optimize the measure
%%     \end{enumerate}
%% \end{itemize}

%% Salient points
%% Similarity measures

\section{Map Projections}
\ifitkFullVersion
\label{sec:MapProjections}
\fi

Map projections describe the link between geographic coordinates and
cartographic ones. So map projections allow to represent a 2-dimensional manifold of a
3-dimensional space (the Earth surface) in a 2-dimensional space (a
map which used to be a sheet of paper!). This geometrical
transformation doesn't have a unique solution, so over the cartography
history, every country or region in the world has been able to express
the belief of being the center of the universe. In other words, every
cartographic projection tries to minimize the distortions of the 3D to
2D transformation for a given point of the Earth surface\footnote{We
  proposed to optimize an OTB map projection for Toulouse, but we
  didn't get any help from OTB users.}.

In OTB the \doxygen{otb}{MapProjection} class is derived from the
\doxygen{itk}{Transform} class, so the coordinate transformation
points are overloaded with map projection equations. The
\doxygen{otb}{MapProjection} class is templated over the type of
cartographic projection, which is provided by the OSSIM library. In
order to hide the complexity of the approach, some type definitions
for the more common projections are given in the file
\code{otbMapProjections.h} file.

Sometimes, you don't know at compile time what map projection you will need in
your application. In this case, the \doxygen{otb}{GenericMapProjection}
allow you to set the map projection at run-time by passing the WKT identification
for the projection.

\input{MapProjectionExample.tex}

You will seldom use a map projection by itself, but rather in an
ortho-rectification framework. An example is given in the next section.

\section{Orthorectification with OTB}
\ifitkFullVersion
\label{sec:OrthorectificationwithOTB}
\fi
\input{OrthoRectificationExample.tex}

\section{Vector data projection manipulation}
\ifitkFullVersion
\label{sec:VectorDataProjection}
\fi
\input{VectorDataProjectionExample.tex}

\section{Geometries projection manipulation}
\ifitkFullVersion
\label{sec:GeometriesProjection}
\fi
\input{GeometriesProjectionExample.tex}

\section{Elevation management with OTB}
\input{DEMHandlerExample.tex}

\section{Vector data area extraction}
\ifitkFullVersion
\label{sec:VectorDataAreaExtraction}
\fi
\input{VectorDataExtractROIExample.tex}


\documentclass[]{article}   % list options between brackets
\usepackage{verbatim}
\usepackage{graphicx}
\usepackage[margin=0.75in]{geometry}            % list packages between braces

% type user-defined commands here

\begin{document}

\title{infer\_sde user manual}   % type title between braces
\author{Cyril Galitzine}         % type author(s) between braces
\date{\today}    % type date between braces
\maketitle

\section{Introduction}     % section

infer\_sde is a Python code that allows the inference of the distribution of the rates of a stochastic differential equation (SDE) from a single or multiple noisy observation(s) of its trajectory. It is based on a Markov chain Monte Carlo (MCMC) method which samples from the posterior rate distribution. The likelihood of the data is estimated via a particle filter method. Further details about the inference method can be found in \cite{Galitzine}

 It was initially created to infer the rates governing peroxisome dynamics \cite{Galitzine}. In such situation, we are interested in inferring three rates $k_{d}, k_{f}, \gamma$ and the standard deviation of the measurement error $\sigma$. The peroxisome count $X_{t}$ at time $t$ is governed by the following SDE:
\begin{equation}
d X_{t} = \left[k_{d} + \left(k_{f} - \gamma\right) X_{t} \right] dt + \left[k_{d} + \left(k_{f} + \gamma\right) X_{t} \right]^{1/2} d W_{t}
\label{BDI}
\end{equation}
which corresponds to a birth-death-immigration (BDI) stochastic process.
We simultaneously observe multiple \emph{realizations} of this SDE by measuring the $X_{t}$ time course in multiple cells. Each realization of the stochastic process is called a \emph{replicate} in the following the biology terminology.

The code can readily be extended to other types of SDEs because of its modular object oriented design.

\section{Running the code}     % section 2.1
\subsection{Input files}
	\subsubsection{sim.dat}
	This file is used to simulate data which is then stored the data.csv file. A typical sim.dat file is reproduced below:
	\verbatiminput{sim.dat}
The different lines of the file are described below:
\begin{itemize}
\item {\tt{Equation\_sim}}: Name of the SDE to simulate. Currently the following SDE are available:
\begin{description}
 \item {\tt BDI}: Eq.~(\ref{BDI}) with parameters $k_{d},k_{f} \textrm{ and } \gamma$ (in that order). In this case the equivalent master equation is simulated via the Gillespie algorithm. This potentially avoid any error in the simulation of the SDE.
\end{description}
\item {\tt{Error\_model\_sim}}: Error model to use to simulate data. Currently the following models are available:
\begin{description}
 \item {\tt Normal}: Measured values $x_{\textrm{measured}}$ are obtained from the true hidden values, $x_{\textrm{hidden}}$ following $x_{\textrm{measured}} \sim \textrm{Normal}\left(\mu =  x_{\textrm{hidden}}, \sigma = \mathtt{error\_sim} \right)$. The standard deviation is assumed to be constant with time and the same for all replicates.
\end{description}
\item {\tt{Nrep\_sim}}: Number of replicates to simulate
\item {\tt{param\_sim}}: Value of the parameters used to simulate data. The order of the parameters has to correspond to that required by the SDE type.
\item {\tt{Rate\_heterogeneity\_model\_sim}}:
Heterogeneity model for the rates between replicates
\begin{description}
\item{\tt{Homogeneous}}: The data of all replicates is generated with the exact same rates
\item{\tt{Heterogeneous}}: Rates vary between replicates following a gamma distribution for each rate. When this option is used {\tt param\_sim} does not specify directly the rates of the SDE but instead the mean and standard deviation of the gamma distribution of each rate. Assuming that the standard deviation is 10\% of the rate mean, {\tt param\_sim} would become instead {\tt [7.75e-4,7.75e-5,4.0e-5,4.0e-6,4.0e-5,4.0e-6]} of {\tt [7.75e-4,4.0e-5,4.0e-5} for {\tt Homogeneous} rate model.
\end{description}
\item {\tt{Error\_heterogeneity\_model\_sim}}:
\begin{description}
\item{\tt{Homogeneous}}: The data of all replicates is generated with the same error standard deviation.
\end{description}
\item {\tt{X0\_sim}}: Initial value at time $t=0$. This value should be specified for each {\tt N\_rep\_sim} replicate. If it is not the initial value is determined via Poisson distribution with $\lambda=$ {\tt X0\_sim}.
\item {\tt{Ntime\_sim}}: Number of time points (A constant $\Delta t$ is used)
\item {\tt{T\_sim}}: Overall simulation time (has to be in the same time unit as the rate specified with {\tt{param\_sim}}).
 \end{itemize}

      \subsubsection{data.csv}
      data.csv contains the time course data that is used for the inference. It can be either generated by simulation or obtained through experimental measurement. The first few lines of typical data.csv file are reproduced below:
	\verbatiminput{data.csv}
      The first column corresponds to the index of the DataFrame is not important. It does not need to be specified. The following comma separated columns: {\tt replicate, t, x} should always be present. The number of replicate starts at 0 and should always be specified even if there is only a single replicate.
\newpage
  \subsubsection{inference.dat}

  The inference.dat file controls the inference procedure. A typical inference.dat file (the one used in example BDI\_4rep\_homogeneous\_rates\_parallel) is detailed below:
        \verbatiminput{inference.dat}

\begin{itemize}
\item {\tt{Simulate\_data}}: 0: Read existing data.csv file (if it exists), 1: Simulate new data
\item {\tt{Equation}}: Name of the SDE to simulate. Currently the following SDE(s) are available:
\begin{description}
 \item {\tt BDI}: Eq.~(\ref{BDI}) with parameters $k_{d},k_{f} \textrm{ and } \gamma$ (in that order).
\end{description}
\item {\tt{Error\_model}}: Error model for the data. Currently the following models are available:
\begin{description}
 \item {\tt Normal}: Measured values $x_{\textrm{measured}}$ are obtained from the true hidden values, $x_{\textrm{hidden}}$ following $x_{\textrm{measured}} \sim \textrm{Normal}\left(\mu =  x_{\textrm{hidden}}, \sigma = \mathtt{error\_sim} \right)$. The standard deviation is assumed to be constant with time for each replicate.
\end{description}
\item {\tt{Nsamp}}: Number of accepted MCMC samples to calculate. MCMC sample proposals that are not accepted are not counted.
\item {\tt{Npart}}: Number of particles to use for the particle filter
\item {\tt{param}}: Initial starting value for the parameters at step 0. The parameters have to be in the correct order dictated by {\tt Equation}.
\item {\tt{param\_infer}}: Infer parameter of {\tt param} 0/1 = Yes/No. In case param\_infer=0 for a particular parameter, its value is assumed constant and equal to that specified in {\tt param}.
\item {\tt{param\_error}}: Initial starting value for the error parameter at step 0. The names specified for the error parameters do not matter. Typically one error parameter is inferred for each replicate such as here.
\item {\tt{param\_error\_infer}}: Infer parameter of {\tt param\_error} 0/1 = Yes/No. In case param\_error\_infer=0 for a particular parameter, its value is assumed constant and equal to that specified in {\tt param\_error}.
\item {\tt{Rate\_heterogeneity\_model}}:
Heterogeneity model for the rates between replicates
\begin{description}
\item{\tt{Homogeneous}}: Assume that all replicates are governed by the exact same rates.
\item{\tt{Heterogeneous}}: Assume that rates vary between replicates following a gamma distribution for each rate. When this option is used {\tt param} does not specify directly the initial rate values of the SDE but instead the initial mean and standard deviation of the gamma distribution of each rate. Assuming that initially the standard deviation is 10\% of the rate mean, {\tt param\_sim} would become instead

 {\tt [7.75e-4,7.75e-5,4.0e-5,4.0e-6,4.0e-5,4.0e-6]} of {\tt [7.75e-4,4.0e-5,4.0e-5} for {\tt Homogeneous} rate model.
\end{description}
 \item {\tt{Error\_heterogeneity\_model}}:
 Heterogeneity model for the measurement error between replicates
 \begin{description}
\item{\tt{Homogeneous}}: Assumes that each replicate has a different error standard deviation. This terminology might be misleading but it used for consistency with the rate heterogeneity model. When this model is used, {\tt param\_error} needs to contain one error standard deviation for each replicate.
\end{description}
 \item {\tt{sd\_MH}}:
Parameter controlling the step size of the Metropolis Hastings algorithm. It should be adjusted so that the average acceptance rate is around 0.3.
 \item {\tt{MH\_step\_scaling}}: Metropolis Hasting stepping method. The following methods are available:
\begin{description}
\item{\tt{exponential}}: New samples are generated following a log-normal distribution centered on the current value, i.e.~$x^{n+1} = x^{n}\exp\left(Z\right)$ with $Z \sim \mathcal{N}\left(0,\sigma_{\textrm{MH\_step\_scaling}}\right)$. This stepping method ensures that each rate step is always properly scaled that the rates remains positive (rates are always defined to be positive).
\end{description}
 \end{itemize}

\subsection{Output files}

\subsubsection{out.dat}

This file contains the accepted MCMC samples (rejected samples are not recorded) for each of the parameter listed in the inference.dat file. It also contains the overall likelihood of the data. The out.dat file obtained with the inference.dat file shown above looks like this: (in small fonts to show everything...)
{\tiny \verbatiminput{out.dat}}
The columns correspond to the samples for rates specified in {\tt parama} and {\tt param\_error} (in the same order). The last column is the log likelihood calculated for that particular set of parameters.

\section{Running the code}

\subsection{Overall workflow}

\subsection{Simulating data with infer\_sde\_serial.py}

To simulate data, remove any existing data.csv file and run the serial inference code: {\tt python infer\_sde\_serial.py} . You should have all the *.py files in the directory where you execute this command as well as the following required input files: {\tt sim.dat}, {\tt inference.dat}.
 If you do not wish to perform inference simply stop the executing of the code after a few steps once you are sure that data.csv has been generated.

You can plot the trajectories that you just generated in the {\tt data.csv} file by running {\tt python plot\_traj.py} which will produce a plot: {\tt data.png}

It is also likely that you will have to modify the code in time\_series.py to generate simulated data that conforms to your desired specifications This is because simulating data according to sim.dat can only produce a very narrow set of data types. For instance, it cannot generate replicates with different numbers of time points or overall times.

\subsection{Running the serial inference code with infer\_sde\_serial.py}

The inference code is executed by typing {\tt python infer\_sde\_serial.py}
You should have all the *.py files in the directory where you execute this command as well as the following required input files: {\tt sim.dat}, {\tt inference.dat} of course the data file {\tt data.csv}. When the code runs, it will output for each accepted sample the value of the parameters and measurement errors, the log likelihood (L), the max log likelihood (called Lmin) and the average acceptance ratio AR. The value of {\tt sd\_MH} in {\tt inference.dat} should be adjusted so that the acceptance ratio is around 0.3 (i.e.~the optimum acceptance ratio for the Metropolis Hastings algorithm).

\subsection{Running the parallel inference code with infer\_sde\_parallel.py}

The inference code was parallelized across replicates using a python version of the MPI library mpi4py. This allows us to split the calculation of the overall log likelihood across multiple CPUs to speed up the sampling procedure (but only when multiple replicates are considered). The $N_{\textrm{rep}}$ replicates are distributed as uniformly as possible across CPUs. Each CPU then calculates the sum of the log likelihoods of all the replicates that are assigned to it. The log likelihoods sums are then summed again across cpus to calculate the overall log likelihood. When using $N_{\textrm{CPU}}$ to run the inference, one CPU (the master CPU) will not be performing calculations. As such the calculation will be distributed among the remaining $N_{\textrm{CPU}} -1$ CPUs. For instance, if want to infer the rates for $N_{\textrm{rep}} = 4$ replicates and use  $N_{\textrm{CPU}}=5$, each CPU will calculate the likelihood of one replicate which leads to the optimal speedup. If $N_{\textrm{CPU}}=4$ are used for the same 4 replicates, the replicates will be split as follows across CPUs: $\overbrace{\textrm{Rep1}}^{\textrm{CPU 2}} \vert \overbrace{\textrm{Rep2}}^{\textrm{CPU 3}} \vert \overbrace{\textrm{Rep3},\textrm{Rep4}}^{\textrm{CPU 4}}$ The fourth CPU will calculate the likelihood of two replicates) while CPU 1, the master CPU, is not involved in the calculation of likelihoods. If $N_{\textrm{CPU}}=3$, we would obtain the following: $\overbrace{\textrm{Rep1},\textrm{Rep2}}^{\textrm{CPU 2}} \vert \overbrace{\textrm{Rep3},\textrm{Rep4}}^{\textrm{CPU 3}}$. $N_{\textrm{CPU}}=2$ should not be employed since the it will less efficient than the serial code the due to the master CPU.\\

To run the inference with, e.g. NCPUS = 4 the following should be executed:\\
{\tt mpirun -np 4 python3 infer\_sde\_parallel.py}

The inputs and outputs of the parallel code are identical to those of the serial code.

\subsection{Analyzing results with analyze\_mcmc.py}

The inference code (serial or parallel) produces an {\tt out.dat} file with the posterior rate samples. Plots of the distribution of the rates can be obtained by running {\tt python analyze\_mcmc.py}. This produces density (*\_density.pdf) and correlation (*\_corr.pdf) plots for the inferred parameters. The sampling frequency of the parameters ({\tt frequency} variable) in {analyze\_mcmc.py} should be adjusted so that the consecutive samples are not too correlated which otherwise results in an inaccurate estimation of the densities.

\newpage
\section{Test cases}
\subsection{BDI {(\small birth death immigration)} SDE: $dX_{t} =  \left[k_{d} + \left(k_{f} - \gamma\right) X_{t} \right] dt + \left[k_{d} + \left(k_{f} + \gamma\right) X_{t} \right]^{1/2} d W_{t}$}

\subsubsection{1 replicate, serial (EXAMPLES/BDI\_1rep)}

All the input, output files and results of the inference can be found in folder EXAMPLES/BDI\_1rep. Data was simulated according to the following sim.dat for a single replicate:
\verbatiminput{../EXAMPLES/BDI_1rep/sim.dat}
The serial inference code, {\tt infer\_sde\_serial.py}, was run for 24 hours and the results were analyzed with {\tt analyze\_mcmc.py}.

\subsubsection{4 replicates, Homogeneous rates, serial (EXAMPLES/BDI\_4rep\_homogeneous\_rates\_serial)}

All the input, output files and results of the inference can be found in folder EXAMPLES/BDI\_1rep.
Data was simulated according to the following sim.dat for 4 replicates (homogeneous rates):
\verbatiminput{../EXAMPLES/BDI_4rep_homogeneous_rates_serial/sim.dat}
The serial inference code, {\tt infer\_sde\_serial.py}, was run for 24 hours and the results were analyzed with {\tt analyze\_mcmc.py}.

\subsubsection{4 replicates, Homogeneous rates, parallel (EXAMPLES/BDI\_4rep\_homogeneous\_rates\_parallel)}
The same data as for case BDI\_4rep\_homogeneous\_rates\_serial was used. The parallel inference code was run for 24 hours using 5 CPUs with {\tt mpirun -np 5 python infer\_sde\_parallel.py}. Results were then analyzed with {\tt analyze\_mcmc.py}.

\subsubsection{4 replicates, Heterogeneous rates, parallel (EXAMPLES/BDI\_4rep\_heterogeneous\_rates\_parallel)}
All the input, output files and results of the inference can be found in folder EXAMPLES/BDI\_4rep\_heterogeneous\_rates\_parallel.
Data was simulated according to the following sim.dat for 4 replicates (heterogeneous rates between replicates):
\verbatiminput{../EXAMPLES/BDI_4rep_heterogeneous_rates_parallel/sim.dat}

\bibliography{bib.bib}

\bibliographystyle{plain}
\end{document}


\subsection{Sliding Window Filter} \label{sliding_window_filter}
This section explains a sliding window filter and the way to embed the filter into a sliding window application as
described in section \ref{sliding_window_technique}. A time series filter is in general a function that takes a time
series as argument and returns true or false. One possible underlying inner functionality approach of the filter is
presented later in this section. The previous version of a sliding window application is extracting the current time
series window and passes it directly to a time series classificator. This approach is extended by embedding a time
series filter directly after the extraction and ahead of the time series classificator. The time series filter has the
task to prune the amount of time series windows that reach the classificator. Time series windows which would be
assessed as unclassifiable by the classificator should be blocked by the filter as much as possible. Figure
\ref{fig:swf} illustrates the way of embedding the time series filter into the workflow of a sliding window application.
\clearpage
\begin{figure}
    \begin{center}
        \resizebox {\textwidth} {!} {
            {\tiny
                \begin{tikzpicture}[node distance = 1.5cm, auto]
                    \node [block] (sod) {sensors or devices};
                    \node [block, right of=sod, node distance=6cm, text width=2cm] (extract) {Extract last subsequence from Q of size $w$, $Q[t-w,t]$};
                    \node [block, draw=blue, right of=extract, node distance=4cm, text width=2cm] (filter) {Time series filter};
                    \node [decision, draw=blue, below of=filter] (filterdecide) {$Q[t-w,t]$ can pass?};
                    \node [block, below of=filterdecide, node distance=2cm, text width=2cm] (nnc) {Time series classificator};
                    \node [decision, below of=nnc] (decide) {$Q[t-w,t]$ classifiable?};
                    \node [block, left of=decide, node distance=3cm] (sleeps) {Sleep for $s$ time};
                    \node [block, below of=decide, node distance=2cm, text width=2cm] (action) {Trigger event that $Q[t-w,t]$ has been classified and sleep for $w$ time};

                    \path [line,dashed] (sod) -- node (ctss) {Continuous time series stream $Q$} (extract);
                    \path [line] (extract) -- node {$Q[t-w,t]$} (filter);
                    \path [line] (filter) -- (filterdecide);
                    \path [line] (filterdecide) -- node {yes} (nnc);
                    \path [line] (filterdecide) -| node [near start] {no} (sleeps);
                    \path [line] (nnc) -- (decide);
                    \path [line] (decide) -- node {no} (sleeps);
                    \path [line,dashed] (sleeps) -| (ctss);
                    \path [line] (decide) -- node {yes} (action);
                    \path [line,dashed] (action) -| (ctss);
                \end{tikzpicture}
            }
        }
    \end{center}
    \caption{Extended design for a sliding window application as in figure \ref{fig:swt}, plus the additional filter
    highlighted in blue. The current time is stored in variable $c$. The variables $w$ for the window size and $s$ for
    the step size are predefined.}
    \label{fig:swf}
\end{figure}

The integration of the time series filter into a sliding window application is described above. An underlying inner
functionality approach of a time series filter is the usage of a simple time series measures function. The argument of
such a time series measure function should be one time series and the result should be an element of $\mathbb{R}$.
Linear time and memory complexity are basic requirements for a measure to ensure an acceptable performance of the
filter. A filter instance based on a suitable time series measure has access to the same training set of time series as
the classificator. The measure executed on every time series in the training set results in a maximum and a minimum
value. Both values together are creating an interval. This interval is called filter interval. Every measure value of the
training set is inside of the boundaries of the filter interval. The approach of a measure based filter is that many
classifiable time series windows should have a measure value inside of the interval and many unclassifiable time series
windows should have a measure value outside of the interval boundaries. Incoming time series windows with a measure
function value inside the interval boundaries can pass to the classification. All other windows are blocked by the
filter. A factor can expand the filter interval to avoid the mistakenly blocking of classifiable time series windows.
This factor is called blur factor and is expressed as a percentage number. Assumed is a simple example, the left
boundary of the filter interval is 10 and the right boundary is 20. A blur factor of 160\% will result in a new filter
interval of 7 and 23. The filter interval will be expanded artificially on the left and the right side. Possible time
series measure functions are mentioned in \ref{complexity_estimate} and \ref{sample_variance}.


\documentclass[12pt]{article}
\usepackage[pdftex]{graphicx}

\usepackage{qtree}

\usepackage{xspace}

\usepackage{setspace}
\usepackage{float}

\usepackage{stmaryrd}
\usepackage{mathptmx}% http://ctan.org/pkg/mathptmx
\usepackage{times}
\usepackage{amsmath}
\usepackage{amsthm}
\usepackage{amsfonts}
\usepackage{amssymb}

\theoremstyle{definition}
\newtheorem{definition}{Definition}[section]
\newtheorem{lemma}{Lemma}[section]
\newtheorem{thm}{Theorem}[section]

\usepackage{natbib}

\title{The math of the \textsc{cath}}
\author{Meaghan ``geitje'' Fowlie and Floris ``konijntje'' van Vugt}

\begin{document}

\maketitle

\section{Definitions}

%\newcommand\STATES{\mathcal{S}}
\newcommand\STATES{\ensuremath{\mathbb{S}}\xspace}
%\newcommand\OPS{\mathcal{O}}
\newcommand\OPS{\ensuremath{\mathbb{O}}\xspace}
%\newcommand\BIGR{\mathcal{B}}
\newcommand\BIGR{\ensuremath{\mathbb{B}}\xspace}
\newcommand\FSA{\textsc{FSA}\xspace}
%\newcommand\PARSES{\mathcal{P}}
\newcommand\PARSES{\ensuremath{\mathbb{P}}}
\newcommand\SC{\text{\textsc{sc}}}
\newcommand\TC{\text{\textsc{tc}}}
\newcommand\UC{\text{\textsc{uc}}}
\newcommand\BC{\text{\textsc{bc}}}
\newcommand\N{\ensuremath{\mathbb{N}}}
\newcommand\sg{\ensuremath{\Sigma}\xspace}
\newcommand\la{\ensuremath{\langle}\xspace}
\newcommand\ra{\ensuremath{\rangle}\xspace}
\newcommand\arr{\ensuremath{\rightarrow}\xspace}
\newcommand\emp{\ensuremath{\epsilon}\xspace}

\newcommand\op{\text{\textsl{op}}\xspace}
\newcommand\mg{\text{\textsl{mg}}\xspace}
\newcommand\cp{\text{\textsl{copy}}\xspace}
\newcommand\cl{\text{\textsl{clear}}\xspace}
\newcommand\ed{\text{\textsl{end}}\xspace}
\newcommand\start{\text{\textsl{start}}\xspace}

\newcommand\expr{\text{\textsl{expr}}\xspace}
\newcommand\Lex{\text{\textsl{Lex}}\xspace}
\newcommand\fea[1]{\text{\texttt{#1}}\xspace}
\newcommand\LBOUND{\ensuremath{\rtimes}}
\newcommand\RBOUND{\ensuremath{\ltimes}}
\newcommand\OURG{\text{\textsc{cath}}\xspace}

\newcommand\llb{\ensuremath{\llbracket}}
\newcommand\rrb{\ensuremath{\rrbracket}}

\newcommand\IF{\text{ if }\xspace}
\newcommand\der{\leftarrow}
%\newcommand\der{\text{:-}}

We define a deterministic finite state automaton over operations and a Markov chain over the alphabet. these two components make up the grammar. \\

\noindent\textbf{Notation} the size of a set or sequence $A$ is notated $|A|$ or $\#A$. The \textit{i}th member of a sequence $A$ is notated $A(i)$, the last member $A(-1)$, and all but the first $A(1:)$. $\emp$ is the empty sequence.

\subsection{The Grammar}
\label{sec:grammar}

\begin{definition}[Deterministic Finite State Automaton]
  A deterministic finite state automaton (DFSA) is a five-tuple
\[\la \sg, Q, q_0, F, \delta  \ra  \]
where:

\noindent $\sg$ is an alphabet\\
$Q$ is a finite set (\textit{states})\\
$q_0\in Q$ is the designated \textit{start state}\\
$F\subseteq Q$ is the set of \textit{final states}\\
$\delta: Q\times \sg \arr Q$ is the \textit{transition function}

A string $s\in\sg^*$ is accepted/generated by a DFSA $A$ iff
$\exists \mathbf{q} \in Q_A^*$ such that $\mathbf{q}(0)=q_0$, $\mathbf{q}(-1)\in F_A$, and $\forall i<|s|$, $\delta(\mathbf{q}(i),s(i))=\mathbf{q}(i+1)$
\label{def:dfsa}
\end{definition}

\begin{definition}
  We say a triple $(q,e,q')$ where $q,q'\in Q$ and $e\in\sg$ is a \textit{transition} of an
  FSA iff $\delta(q,e)=q'$.
\end{definition}

We define a grammar which generates a language \textit{surface strings} over an alphabet \sg by application of operations $\OPS=\{\mg,\cl,\cp,\ed\}$. The choice of operation is governed by a DFSA in which the operations are the emissions of transitions.

In our operations FSA \OPS, the set of all possible states is \STATES=\{S,NotCL,CL$_S$,CL,F\} and the alphabet is the set of all operations is $O=\{\mg,\cl,\cp,\ed\}$. The bigram set or transition set, is $\BIGR\subseteq\sg^*$.

\begin{definition}[Operations FSA]
  The operations FSA is a deterministic finite state automaton over states \STATES and alphabet \OPS.
\end{definition}

\begin{definition}[Transition Probabilities]

  A probability assignment $\phi$ is a function from transitions of the operations FSA to [0,1] such that

$$\forall q\in \STATES,~~\sum_{e\in\OPS,q'\in \STATES} \phi(q,e,q') = 1 $$

\end{definition}

\begin{definition}[Markov Chain]
  A Markov chain is a 4-tuple $\la \sg, S, B, \phi  \ra $ where

\sg  is a finite alphabet of symbols,

$S\subseteq \sg$ is a set of start categories,

$B\subseteq \sg\times\sg$ is a set of transitions between members of \sg, and

$\phi: \sg \times \sg \arr [0,1]$ is a probability distribution over transitions such that

$$\forall a\in \sg,~~\sum_{b\in\sg} \phi(a,b) = 1 $$

A sequence $s$ is accepted/generated by the chain iff $s$ is a sequence of alphabet items such that $s(0) \in S$ and $\forall i<|s|$, $\phi(s(i),s(i+1))>0$

\end{definition}

\begin{definition}[route]
  A \emph{route} is a route through the $\FSA$ of say $n$ steps, defined as a tuple $(Q,E)$ where $Q$ is the sequence of states visited, i.e.
%  $Q=\la q_i\in\STATES|i<n\ra$, and $E$ is the sequence of emissions.
 $E=\la e_i\in\OPS|i<n-1\ra$ such that $\forall i<n,~ \delta(q_i,e_i)=q_{i+1}$.

\end{definition}

\begin{definition}[\OURG]
  \OURG = \la \OPS,\BIGR\ra  where

  $\OPS = \la \{\mg,\cp,\cl,\ed\}, \{S,NotCL,CL_S,CL,F\}, S, \{F\}, \phi_\OPS\ra$ is the DFSA given in Figure \ref{fig:ops}

  $\BIGR = \la \sg\cup\{{\LBOUND}\}, \{\LBOUND\}, B, \phi_\BIGR \ra$ is a Markov Chain  for some alphabet \sg and a left boundary marker \LBOUND.

\end{definition}

\begin{figure}[H]
  \centering
  \includegraphics[width=5in]{ops.png}
  \caption{\OPS}
  \label{fig:ops}
\end{figure}

\begin{definition}[Derivation of \OURG]
  A \textit{derivation} of a grammar \OURG = \la\OPS,\BIGR\ra is a pair (ops,bis) where $ops\in
  L(\OPS)^*$ and $bis\in L(\BIGR)$, and  $|bis|=|ops\restriction\mg| $
\end{definition}

\begin{thm}
  A derivation (ops,bis) is valid iff:

  \begin{enumerate}
  \item ops[0]=\mg
  \item There is exactly one \ed and it is the last element of ops.
  \item $(ops\restriction \{\cp,cl\})[-1]\neq\cl$
  \item $(ops\restriction \{\cp,cl\})$ has no contiguous subsequence \cl \cl
\end{enumerate}

\label{thm:valid-properties}
\end{thm}

\begin{definition}[Derivation Tree grammar]
  The derivation tree grammar for \OURG is defined by the following CFG. Note that this overgenerates, in that there are dts for invalid derivations among the parse trees.
  \begin{itemize}
  \item \cp \arr \cp $|$ \mg
  \item \cl \arr \cp $|$ \mg
  \item \ed \arr \cp $|$ \mg
  \item \mg \arr \op a ~~~~~~ $\forall \op\in O\cup\{\start\}, \forall a\in\sg$
  \end{itemize}

  The set of parse trees for this grammar is $T_{O\cup\sg\cup\start}$.

\end{definition}

\begin{definition}[Derivation trees of \OURG (DT(\OURG))]
  The derivation tree for a derivation (ops,bis) is defined by the function $D:O^* \times \sg^* \times T_{O\cup\sg\cup\start} \arr (O^* \times \sg^* \times T_{O\cup\sg\cup\start}) \cup T_{O\cup\sg\cup\start}$ as follows:\\

  $D(ops,bis,t)=
  \begin{cases}
    t & \text{ if } ops=bis=\emp\\
    D(ops(1:),bis(1:),\mg(t,bis(0))) & \text{ if } ops(0)=\mg ~\&~ bis\neq\emp\\
    D(ops(1:),bis,\op(t)) & \text{ if } ops(0)\neq\mg\\
    \text{undefined} & \text{ otherwise}
  \end{cases}
  $

  We say t is the derivation tree for the derivation (ops,bis) iff D(ops,bis,\start) = t.
\end{definition}

At this point we just need to interpret t as string-pair operations, but I will add an intermediate step to ease our proof that \OURG is context-sensitive.

We define a tree homomorphism from DT to a set of string derivation trees in

\begin{definition}[string derivation trees (ST)]
  The parse trees of this grammar form ST.\\

\noindent  \cp \arr \cp $|$ $\bullet$\\
  \cl \arr \cp $|$ $\bullet$\\
  \ed \arr \cp $|$ $\bullet$\\
  $\bullet$ \arr \op a ~~~~ $\forall \op\in \{\bullet,\cp,\cl,(\emp,\emp)\}, \forall a\in\sg$
\end{definition}

\begin{definition}[Tree homomorphism for ST ($h_s$)]

  For $t\in DT$,

  $
  h_s(t) =
  \begin{cases}
    (\emp,\emp) & \text{ if } t = \start\\
    t & \text{ if } t\in\sg\\
    \op(h_s(t')) & \text{ if } \exists \op \in \{\cp,\cl,\ed\}, \exists t'\in DT (t=\op(t'))\\
    \bullet(h_s(t'), h_s(a)) & \text{ if } \exists t'\in DT \exists a\in\sg (t=\mg(t',a))\\
  \end{cases}
  $
\end{definition}

\begin{definition}[\OURG algebra]
  A \OURG algebra is an algebra with signature $\la (\sg^*\times\sg^*)\cup\{\sg^*\},\bullet,\cp,\cl,\ed\ra$

  If $t\in ST$, we define its interpretation into the string pair algebra as follows:

   $
  \llb t \rrb_s =
  \begin{cases}
    t & \text{ if } t = t()\\
    \llb\op\rrb(s,b)(\llb t'\rrb) & \text{ if } \exists \op \in \{\cp,\cl,\ed\}, \exists t'\in ST (t=\op(t'))\\
    \llb\bullet\rrb(\llb t'\rrb), \llb a\rrb) & \text{ if } \exists t'\in ST \exists a\in\sg (t=\mg(t',a))\\
  \end{cases}
  $

  where the operations are interpreted as the following functions in the algebra:

\noindent  $\llb\bullet((s,b),a)\rrb_s = (sa,ba)$\\
  $\llb\cp((s,b))\rrb_s = (sb,bb)$\\
  $\llb\cl((s,b))\rrb_s = (s,\emp)$\\
  $\llb\ed((s,b))\rrb_s = s$\\

\end{definition}

\textbf{Example:}  let d = (\ed \cp \mg \mg, a b) be a derivation in \OURG.

  D(d) = \Tree[.\ed~ [.\cp~ [.\mg~ [.\mg~ \start~ a ] b ]]]\\\\

  $h_s(D(d))$ = \Tree[.\ed~ [.\cp~ [.$\bullet$ [.$\bullet$ (\emp,\emp) a ] b ]]]

  $\llb h_s(D(d)) \rrb_s = abab$\\

In full:

  \begin{align*}
    \llb h_s(D(d)) \rrb_s & = \llb \ed(\cp(\bullet(\bullet((\emp,\emp),~a),~b))) \rrb \\
    & = \llb \ed\rrb (\llb\cp(\bullet(\bullet((\emp,\emp),~a),~b)) \rrb)\\
    &  = \llb \ed\rrb(\llb\cp\rrb(\llb\bullet(\bullet((\emp,\emp),~a),~b)\rrb))\\
    &  = \llb \ed\rrb(\llb\cp\rrb(\llb\bullet\rrb(\llb\bullet((\emp,\emp),a)\rrb,~b)))\\
    &  = \llb \ed\rrb(\llb\cp\rrb(\llb\bullet\rrb(\llb\bullet\rrb((\emp,\emp),~a),~b)))\\
    &  = \llb \ed\rrb(\llb\cp\rrb(\llb\bullet\rrb((a,a),~b)))\\
    &  = \llb \ed\rrb(\llb\cp\rrb((ab,ab)))\\
    &  = \llb \ed\rrb((abab,abab))\\
    & = abab
  \end{align*}

\subsection{PMCFG}
\label{sec:pmcfg}

Why did we bother with both $h_s$ and $\llb\cdot\rrb_s$ instead of interpreting the derivation tree directly in the string algebra? In order to facilitate the proof that \OURG is mildly context sensitive; specifically that it is weakly equivalent to a parallel multiple context free grammar. We define a second tree homomorphism $h_p$ into the derivations of a PMCFG and show that the homomorphism is in fact an isomorphism.

\begin{definition}[PMCFG $P$]

  Let $a,c$ be metavariables over \sg. The PMCFG P(g) for (\OPS,\BIGR) for some \OURG g is defined as follows:

  $P(g)=\la \{C^{(2)},T^{(3)},S^{(1)},W^{(1)}\}, \sg^{(0)}, S, V=\{x,y,z\}, R \ra$

Where the productions rules R given below. For our convenience, each rule is given a (not necessarily unique) name; this is used in the proof below.\\

These are called Horn clauses.

$R=  \begin{array}{r | r c l l}
       \text{name} & rules\\
       \hline
       \cl & C(s,x) &\der& T(s,b,x)\\
       \cp & T(sb,bb,x) &\der& T(s,b,x)\\
       \mg & T(sa,ba,a) &\der& T(s,b,c), a & \forall (c,a)\in\BIGR\\
       \mg & T(sa,a,a) &\der& C(s,c), a & \forall (c,a)\in\BIGR\\
       \ed & S(s) &\der& T(s,b,x)\\
       \text{\textsl{start}} & C(\emp,\LBOUND) &\der&\\
                   & W(a) &\der& &\forall a\in\sg\\

     \end{array}$

     The set of parse trees for this grammar is PT.

 \end{definition}

 \textbf{Example:} abab

 \Tree[.S(abab) [.T(abab,abab,b) [.T(ab,ab,b) [.T(a,a,a) C(\emp,\LBOUND) W(a) ] W(b) ]]]

 \textbf{Example:} abb

 \Tree[.S(abab) [.T(abb,abb,b) [.T(ab,b,b) [.C(a,a) [.T(a,a,a) C(\emp,\LBOUND) W(a) ] ] W(b) ]]]   \\

 \begin{definition}[derivation tree of an MCFG \citep{makoto-kanazawa-lecture-notes-2016}]
   In order to get derivation trees of an MCFG that are defined over a finite alphabet, we label our internal nodes with the rules themselves. For each node p, if p is labelled $B(\alpha_1,...,\alpha_n)\der B_1(\mathbf{x_{11},...x_{1r_1}}),\dots,B_n(\mathbf{x_{n1},...x_{nr_n}})$
   then p has n daughters, and $\forall i\leq n$, the $i$th daughter is $B_i(t_1,\dots, t_{r_i})$, $t$s trees.
 \end{definition}

 \begin{definition}
   The derived string of a derivation tree $B(\alpha_1,...,\alpha_n)\der daughters (t_1,\dots t_n)$  is calculates as follows: For every $t_i$, if $derstr(t_i) = (s_{i1},\dots,s_{ir_i})$ then $derstr(t)=(\alpha_1,\dots,\alpha_n)\sigma$, where $\sigma$ is the substitution $[\mathbf{x}_{ij}\der w_{ij}]$
 \end{definition}

We can simplify our rule names as follows, making the trees easier to read, and making the relationship between the MCFG dt and the \OURG dt clear:

$R=  \begin{array}{r | r c l l}
       \text{name} & rules\\
       \hline
       \cl & C(s,x) &\der& T(s,b,x)\\
       \cp & T(sb,bb,x) &\der& T(s,b,x)\\
       \mg_{Tca} & T(sa,ba,a) &\der& T(s,b,c), a & \forall (c,a)\in\BIGR\\
       \mg_{Cca} & T(sa,a,a) &\der& C(s,c), a & \forall (c,a)\in\BIGR\\
       \ed & S(s) &\der& T(s,b,x)\\
       \text{\textsl{start}} & C(\emp,\LBOUND) &\der&\\
       & W(a) &\der & &\forall a\in\sg\\
     \end{array}$\\

 \textbf{Example:} abab parse tree, derivation tree, more readable derivation tree

 {\small
 \Tree[.S(abab) [.T(abab,abab,b) [.T(ab,ab,b) [.T(a,a,a) C(\emp,\LBOUND) W(a) ] W(b) ]]]
 \Tree[.{S(\textbf{x})$\der$ T(\textbf{x,y,z})} [.{T(\textbf{xy,yy,z})$\der$ T(\textbf{x,y,z})} [.{T(\textbf{x}b,\textbf{y}b,b)$\der$ T(\textbf{x,y},a), W(a)} [.{T(\textbf{x}a,a,a)$\der$ C(x,\LBOUND),W(a)} C(\emp,\LBOUND) W(a) ] {W(b)} ]]]
 \Tree[.\ed~ [.\cp~ [.$\mg_{Tab}$ [.$\mg_{C\LBOUND a}$ {C(\emp,\LBOUND)} W(a) ] W(b) ]]]
}\\\\

We define a tree transducer $h_p$ from the derivation trees of \OURG DT to the derivation trees of the equivalent MCFG PDT as follows:

\begin{definition}[Tree transducer from DT to PDT]

  $T=\la Q, O\cup\sg, PO\cup\sg, Q_f, \delta \ra$

  Where PO is the set of rule names in table \ref{tab:mcfg-names}, Q is the set of states defiuned below, $Q_F = \{q_f\}$ and $\delta$ is the transition function defined as follows:

  $\begin{array}[H]{r c l l}
     \delta(a) & = & q_a(W(a)) & \forall a\in\sg\\
     \delta(\start) & = & q_{C\LBOUND}(C(\emp,\LBOUND))\\
     \delta(\ed(q(t))) & = & q_f(\ed(t)) & \forall q\in Q\\
     \delta(\cp(q(t)) & = & q(\cp(t)) & \forall q\in Q\\
     \delta(\cl(q(t)) & = & q_{Cx}(\cl(t)) & \IF \exists x\in\sg (q=q_{Tx})\\
     \delta(\mg(q_1(t_1),q_2(t_2))) & = & q_{Ty}(\mg_{Zxy}(t_1,t_2)) & \IF \exists Z\in\{T,C\} \exists x,y\in\sg (q_1=q_{Zx} \& q_2=q_{Zy})
  \end{array}
$\\

$Q=\{q_x | x\in\sg\}\cup \{q_{Zx} | x\in\sg ~\&~ Z\in\{T,C\}\}\cup\{q_f\} $

\end{definition}

Since we rely on the states to get the right \mg functions, this is not a tree homomorphism, since a tree homomorphism is a tree transducer with only one state \citep{schieber-2004-TAG+}. I don't think this is a problem though because T generates derivation trees isomorphic to their preimage.

Example:

\Tree[.\ed~ [.\cp~ [.\mg~ [.\mg~ \start~ a ] b ]]] $\Rightarrow$
\Tree[.\ed~ [.\cp~ [.\mg~ [.\mg~ [.$q_{C\LBOUND}$ C(\emp,\LBOUND) ] [.$q_a$ W(a) ] ] [.$q_b$ W(b) ]]]] $\Rightarrow$
\Tree[.\ed~ [.\cp~ [.\mg~ [.$q_{Ta}$ [.$\mg_{C\LBOUND a}$ C(\emp,\LBOUND)   W(a)  ]] [.$q_b$ W(b) ]]]]  $\Rightarrow$
\Tree[.\ed~ [.\cp~ [.$q_{Tb}$ [.$\mg_{Tab}$ [.$\mg_{C\LBOUND a}$ C(\emp,\LBOUND)   W(a)  ] W(b) ]]]]
$\Rightarrow$
\Tree[.\ed~ [.$q_{Tb}$ [.\cp~  [.$\mg_{Tab}$ [.$\mg_{C\LBOUND a}$ C(\emp,\LBOUND)   W(a)  ] W(b) ]]]]
$\Rightarrow$
\Tree[.$q_{f}$ [.\ed~  [.\cp~  [.$\mg_{Tab}$ [.$\mg_{C\LBOUND a}$ C(\emp,\LBOUND)   W(a)  ] W(b) ]]]]\\\\

Note that this transducer doesn't enforce all the rules of the grammar. If there are bad derivation trees they'll be interpreted as uninterpretable dts in the PMCFG. I think right now I havne't distinguished the co-domain from the yield. Haffoo do that.

% \begin{definition}
%   $h_p(t) =\\
%   \begin{cases}
%     C(\emp,\LBOUND) & \IF t=\start\\
%     t & \IF t\in\sg\\
%     S(x)((T(x,y,z)(h_p(t''))) &\IF \exists t'\in DT (t=\ed(t')) ~\&~ \exists x,y,z\in V ~\&\\
%     &~~~~~\exists t''\in PT~ (h_p(t') = T(x,y,z)(t'')))\\
%     C(x,z)((T(x,y,z)(h_p(t''))) &\IF \exists t'\in DT (t=\cl(t')) ~\&~ \exists x,y,z\in V ~\&\\
%     &~~~~~\exists t''\in PT~ (h_p(t') = T(x,y,z)(t'')))\\
%     T(xy,yy,z)((T(x,y,z)(h_p(t''))) &\IF \exists t'\in DT (t=\cp(t')) ~\&~ \exists x,y,z\in V ~\&\\
%     &~~~~~\exists t''\in PT~ (h_p(t') = T(x,y,z)(t'')))\\
%     T(xa,ya,a)((T(x,y,c)(h_p(t'')), a) &\IF \exists t'\in DT \exists a\in\sg (t=\mg(t'),a) ~\&~ \exists x,y,z\in V ~\&\\
%     &~~~~~\exists t''\in PT~ (h_p(t') = T(x,y,z)(t'')))\\
%     T(xa,ya,a)((C(x,c)(h_p(t'')), a) &\IF \exists t'\in DT \exists a\in\sg (t=\mg(t'),a) ~\&~ \exists x,z\in V ~\&\\
%     &~~~~~\exists t''\in PT~ (h_p(t') = C(x,z)(t'')))\\

%   \end{cases}
% $
% \end{definition}

% OK, I think this is not a tree homomorphism because the internal node labels do not form a finite set. However, it should be easy to see that the trees are isomorphic modulo labelling. Which should give us homomorphism anyway, assuming $h_p$ is defined for every DT. Is it rather that you can't have a tree homomorphism between a tree language over a finite alphabet and one over an infinite alphabet?

%Probably then everything is fine anyway. We want to show that the two tree languages are isomorphic:

\begin{thm}[$DT \simeq PT$]
  The set of derivation trees for a given \OURG is isomorphic to the
  set of derivation trees of $P(\OURG)$. Moreover, if the isomorphism
  maps $t_1$ to $t_2$, $\llb t_1 \rrb = \llb t_2 \rrb$.
\end{thm}

\begin{proof}

  Let $G$ be a \OURG grammar, and let  $t\in DT(G)$. Let
  $t'=\mathbb{A}(t)$. We show by induction on the tree depth that
  $t\simeq t'$ and $\llb t \rrb = \llb t' \rrb$ .

  \begin{enumerate}
  \item $t$ has depth 0 or 1 or whatever. Then t=\start or
    $t\in\sg$. If t=\start, $t'=C(\LBOUND,\emp)$ by the definition of
    $\mathbb{A}$. If $t\in\sg$, $t'=W(t)$, so the trees are
    isomorphic. $\llb t \rrb t = \llb W(t) \rrb$
  \item Suppose $t$ has depth $i$ and $\mathbb{A}(t)\simeq t$.
    \begin{description}
    \item[\ed] $\mathbb{A}(\ed(t)) = \ed(\mathbb{A}(t))$ by definition
      of A.
    \end{description}
  \end{enumerate}

\end{proof}

\subsection{Alexander's way}
\label{sec:alexanders-way}

\begin{enumerate}
\item Define IRTG with \OURG algebra
\item algebra homomorphism H:'OURG \arr DSTA(G) = Dumb ...? an algegra of simple rules for putting together pairs of sets of strings etc like concatenate and wrap (TAGs)
\item see if IRTGs with DSTA(G) (which requires a non-linear homomorphism) are $\subset$ PMCFG
\item \OURG \arr DT \arr$_{hom}$ \OURG algebra \arr$_{H}$ DSTA(G) $\subset$ L(PMCFG)
\end{enumerate}

\subsubsection{IRTG}
\label{sec:irtg}

Derivation tree language is regular.\footnote{It occurs to me that
  in a way it makes more sense to make the right daughters of \mg be
  bigrams. Then (a) the automaton is regular and (b) every node is
  labelled by a transition from one of the FSAs.}

Let  $\Gamma = \{\ed^{(1)},\cp^{(1)},\cl^{(1)},\mg^{(2)}\}\cup\sg^{(0)}\cup\{(\emp,\emp)^{(0)}\}$

$DT \subset T(\Gamma)$ (Terms over a ranked alphabet).

For a given \BIGR, given $t\in T(\Gamma)$, $t\in DT$ iff $t$ is accepted by the non-deterministic BUTA $\mathbb{A}$, defined below.

\begin{definition}[Tree automaton for \OURG with bigrams \BIGR ($\mathbb{A_{\BIGR}}$)]
  $\mathbb{A} = \la \Gamma, Q, q_f, \Delta\ra$ where:
  \begin{description}

  \item[alphabet] $\Gamma = \{\ed^{(1)},\cp^{(1)},\cl^{(1)},\mg^{(2)}\}\cup\sg^{(0)}\cup\{(\emp,\emp)^{(0)}\}$

  \item[states]
    $Q = \left\{
    \begin{array}[H]{c l l}
      & \{\fea{F} , (\LBOUND,\fea{-cl},\fea{-buf})\} & \ed, \start\\
    \cup & \{\fea{=ab} | (a,b)\in\BIGR \} & \text{lexicon}\\
    \cup & \{(\fea{x},\alpha\fea{cl}, \beta\fea{buf}) ~|~  x\in\sg, \alpha,\beta\in\{+,-\}& \text{internal nodes}\\
    \end{array}
\right\}$

  \item[Final state] $q_f=\fea{F}$

  \item[Transitions]\

    $
  \begin{array}[H]{r c l l}
    \Delta & = & \{\la \ed(\fea{(x,-cl,+buf)}), \fea{F}\ra | \fea{x}\in\sg\} & \ed\\
           & \cup & \{\la b, \fea{=ab}\ra | ((a,b)\in\BIGR)\}& \text{lexical rules}\\
           & \cup & \{\la (\emp,\emp),((\fea{\LBOUND,-cl,-buf)}) \ra\}& \start\\
           & \cup & \{\la \cl(\fea{(x,-cl,+buf)}), (\fea{(x,+cl,-buf)})\ra | \fea{x}\in\sg\} & \cl\\
           & \cup & \{\la \cp((\fea{x},\alpha\fea{cl,+buf})), (\fea{(x,-cl,+buf)}) \ra | \fea{x}\in\sg, \alpha\in\{+,-\} \} & \cp\\
           & \cup & \{\la \mg((\fea{x},\alpha\fea{cl},\beta\fea{buf}), \fea{=xy}),(\fea{y},\alpha\fea{cl},+\fea{buf})\ra | \fea{x,y}\in\sg, \alpha,\beta\in\{+,-\} \} & \mg\\
  \end{array}
  $
\end{description}

\end{definition}

Example run:

\Tree[.\ed~ [.\cp~ [.\mg~ [.\mg~ (\emp,\emp) a ] b ]]]
$\Rightarrow$
\Tree[.\ed~ [.\cp~ [.\mg~ [.\mg~ \fea{(\LBOUND,-cl,-buf)} \fea{=\LBOUND a} ] \fea{=ab} ]]]
$\Rightarrow$
\Tree[.\ed~ [.\cp~ [.\mg~ \fea{(a,-cl,+buf)}  \fea{=ab} ]]]
$\Rightarrow$
\Tree[.\ed~ [.\cp~ \fea{(b,-cl,+buf)} ]]
$\Rightarrow$
\Tree[.\ed~ \fea{(b,-cl,+buf)} ]
$\Rightarrow$
\Tree[.\fea{F} ]

Example 2: nondeterminism can lead to bad state choices. We can't get past the lower \mg node.

\Tree[.\ed~ [.\cp~ [.\mg~ [.\mg~ (\emp,\emp) a ] b ]]]
$\Rightarrow$
\Tree[.\ed~ [.\cp~ [.\mg~ [.\mg~ \fea{(\LBOUND,-cl,-buf)} \fea{=b a} ] \fea{=ab} ]]]

Example 3: pointless \cl

\Tree[.\ed~ [.\cp~ [.\mg~ (\emp,\emp) a ]]]
$\Rightarrow$
\Tree[.\ed~ [.\cl~ [.\mg~ \fea{(\LBOUND,-cl,-buf)} \fea{=\LBOUND a} ]]]
$\Rightarrow$
\Tree[.\ed~ [.\cl~  \fea{(a,-cl,+buf)} ]]
$\Rightarrow$
\Tree[.\ed~ \fea{(a,+cl,-buf)} ]

If we show this is in fact a BUTA, and this is in fact the set of derivation trees of \OURG, we've shown the language of derivation trees is regular.

\begin{thm}
  D is 1-1 so D restricted to
\end{thm}

\begin{thm}[Equivalence of $\mathbb{A}$ and \OURG]
  $L(\mathbb{A}_\BIGR)=\{D(ops,bis,\start) ~|~  (ops,bis)\in L(\OURG)\}$
\end{thm}

\begin{proof}
  \begin{enumerate}
  \item
    $L(\mathbb{A}_\BIGR)\subseteq\{D(ops,bis,\start) ~|~ (ops,bis)\in L(\OURG)\}$:

    Let $t\in L(\mathbb{A}_\BIGR)$. Every internal node has arity 1 or is \mg. For all transitions in which the first element is $\mg(q_1,q_2)$, $\exists \fea{x,y}\in\sg$ such that  $(q_2=\fea{=xy}$. The only transitions that have such a state as their second element are the lexical rules, so the second daughter of \mg is always from \sg.

    For all transitions in which the first element is \op(q) for some $\op\in O$, q is a triple. Similarly, for the transitions in which the first element is $\mg(q_1,q_2)$, $q_1$ is a triple. The only transitions that have a triple as their second element are those whose first element is \op(q') for some q' or (\start,\fea{(\LBOUND,-cl,-buf)}). Therefore every element on the path down the only and left daughters is an operation or \start. The only transition in which \start is the first element is a lexical rule, and the only lexical transition in which the second element is a triple is (\start,\fea{(\LBOUND,-cl,-buf)}). Therefore, the path down the only and left daughters is a sequence which consists of all the operations in the tree, followed by \start.
    All of the right daughters proper are lexical items.

    $t$ is therefore in the domain of $D^{-1}$.

    $D^{-1}(x) =
    \begin{cases}
      (ops,bis) & \IF x=(ops,bis,\start)\\
      D^{-1}(\emp,\emp,x) & \IF x\in DT\\
      D^{-1}(\op::ops,bis,t') & \IF x = (\op(t'),ops,bis) \& \op\neq\mg\\
      D^{-1}(\mg::ops,a::bis,t') & \IF x = (\mg(t',a),ops,bis)\\
    \end{cases}
    $

    $D^{-1}(t) = (ops,bis)$ for some $ops\in O^*, bis\in\sg^*$:

    $D^{-1}(t) = D^{-1}(\emp,\emp,t))$. We already saw that every subtree of $t$ is of the form $\op(t') (\op\in\{\ed,\cp,\cl\})$, or $\mg(t',a) (a\in\sg)$, or $a\in\sg$, or \start, so  $D^{-1}$ is defined for every subtree. Internal nodes are always labelled with operations, so only operations will be added to ops. Items are added to bis when they occur as the second daughter of \mg, which we have seen is always a lexical item. The one and only left daughter that is a leaf is \start, and when that leaf is reached it is the complete tree, triggering the first case, which returns (ops, bis) without adding \start to the list.

    Now we show $(ops,bis)\in L(\OPS)\times L(\BIGR)$ such that $|ops\restriction\mg|=|bis|$.

    $|ops\restriction\mg|=|bis|$ is clearly true.

    To show that $ops\in L(\OPS)$, note that the feature configurations $\pm\fea{cl}, \pm\fea{buf}$ correspond to states in \OPS.

    \begin{figure}[H]
      \centering
      \includegraphics[width=4in]{ops.png}
      \caption{\OPS}
      \label{fig:ops}
    \end{figure}

    We designed the grammar so that we never copy or clear vacuously. This means that we only copy or clear if there is something in the buffer to copy or clear, and also that we only clear if that act of clearing will define the start of a copy. The former is accomplished by adding a state for when the buffer is empty, from which we can only Merge. The latter is done by adding a new state that we move to when we clear, and from which we can't clear again, nor can we end without first actually copying. When we put these strategies together, we have five states. The start state has no buffer so we can only Merge. From there we go to NotCL, because we have not recently cleared. From here we can do anything, but if we clear, we move to CL$_S$ in which we have cleared (so we can't clear or end) but we also have no buffer so we can't copy either. We Merge and move to CL from which we can't clear or end. If we copy, we move back to NotCL.

In other words, our states are \fea{F} plus the full complement of $\pm$buffer, $\pm$cleared:

\begin{table}[H]
  \centering
  \begin{tabular}[H]{c|c  c}
  & \fea{+clear} &  \fea{-clear}\\
\hline
 \fea{+buffer}& CL  & NotCL\\
 \fea{-buffer}& CL$_S$ & S\\
\end{tabular}
\end{table}

ops[0]=\mg because the only $\mathbb{A}$ transitions with \fea{-buf} in their first element are \mg transitions. $\forall o\in L(\OPS)$, o[0] = \mg since that's the only transition out of the start state S.

ops[-1] = \ed because the only $\mathbb{A}$-transitions to F are for
\ed-rooted trees. No other nodes are labelled \ed because there are no
transitions in which \texttt{F} occurs in the first element.

Let $C=ops\restriction \{\cp,\cl\}$

Observe the following:

\begin{enumerate}
\item Only \cl changes \fea{-cl} to \fea{+cl}, meaning the only $\mathbb{A}$-transitions whose first element
\end{enumerate}

$C[-1] \neq \cl$: the only $\mathbb{A}$-transitions to F are from states \fea{(x,-cl,+buf)}. \fea{-cl} is only changed to \fea{+cl} by transitions for \cl-rooted trees.  \mg-rooted trees always keep their \fea{cl} value, and \cp-rooted trees always transition to a state with \fea{-cl}. We already saw that every tree has a \start node as its only left leaf, and the state for \start has \fea{-cl}. Therefore any sequence of operations in $t$ that ends with a state with \fea{-cl} either has no \cl nodes -- so the original \fea{-cl} is kept --, or all \cl nodes have a later \cp node that changes the state to \fea{-cl}.

$ \not\exists i<|C|$ s.t. $C[i]=C[i+1]=\cl$: the transition rules for \cl-rooted trees are defined only from states with \fea{-cl}. \mg does not change the value of \fea{cl}, and \cl transitions always end with a \fea{+cl} state. Only \cp higher in the tree can change the \fea{+cl} to \fea{-cl}, making a \cl node possible again.

By Theorem \ref{thm:valid-properties} these are the valid derivations.

\item  $\{D(ops,bis,\start) | ops\in L(\OPS),bis\in
    L(\BIGR)\} \subseteq L(\mathbb{A}_\BIGR) $:

\end{enumerate}
\end{proof}

\end{document}

%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End:


\documentclass[amsmath,
               amssymb,
               superscriptaddress,
               %groupedaddress,
               %unsortedaddress,
               %runinaddress,
               %frontmatterverbose,
               %showpacs,preprintnumbers,
               %nofootinbib,
               %nobibnotes,
               %bibnotes,
               aps,
               %prl,
               %jcp,
               %pra,
               %prb,
               %rmp,
               %prstab,
               %prstper,
               %longbibliography,
               floats,
               %floatfix,
               %lengthcheck,%
               showkeys,
               %preprint,
               %reprint,
               notitlepage, % remove page break after title
               ]{revtex4-1}

\usepackage[utf8]{inputenc}
\usepackage{indentfirst}

\usepackage{graphicx}% Include figure files
\usepackage{dcolumn}% Align table columns on decimal point
\usepackage{bm}% bold math
%\usepackage[mathlines]{lineno}% Enable numbering of text and display math
%\linenumbers\relax % Commence numbering lines

\usepackage{latexsym}
\usepackage{pstricks}
\usepackage{graphics}
\usepackage{epsfig}
\usepackage{longtable}
\usepackage{enumerate}
\usepackage{subfigure}
\usepackage{cancel}
%\usepackage{float}

\newcommand{\ud}{\mathrm{d}}
\newcommand{\Nat}{\mathbb{N}}
\newcommand{\Reals}{\mathbb{R}}
\newcommand{\du}{\partial}
\newcommand{\Energy}{\mathcal{E}}
\newcommand{\Acal}{\mathcal{A}}
\newcommand{\Bcal}{\mathcal{B}}
\newcommand{\Ccal}{\mathcal{C}}
\newcommand{\Ecal}{\mathcal{E}}
\newcommand{\Kcal}{\mathcal{K}}
\newcommand{\Lcal}{\mathcal{L}}
\newcommand{\Wcal}{\mathcal{W}}
\newcommand{\eqspace}{\phantom{=}\,\,\,\:\!}
\newcommand{\half}{\frac{1}{2}}
\newcommand{\thalf}{\tfrac{1}{2}}
\newcommand{\abs}[1]{\lvert#1\rvert}
\newcommand{\expo}[1]{\mathrm{e}^{#1}}
\newcommand{\dt}[1]{\left|#1\right|}
\newcommand{\bas}[1]{\left\lbrace{\text{#1}}\right\rbrace}
\newcommand{\mint}[2]{\left[{#1}\middle|{#2}\right]}

%bold symbols
\newcommand{\mb}[1]{\boldsymbol{#1}}
\newcommand{\br}{\mb{r}}
\newcommand{\bx}{\mb{x}}

%creation and annihilation operators
\newcommand{\crea}[1]{\hat{#1}^{\dagger}}
\newcommand{\anni}[1]{\hat{#1}^{\vphantom{\dagger}}}

%Extra operators
\DeclareMathOperator{\Fourier}{\mathcal{F}}
\DeclareMathOperator{\Imag}{Im}
\DeclareMathOperator{\Real}{Re}
\DeclareMathOperator*{\Residual}{\mathrm{Res}}
\DeclareMathOperator{\sgn}{sgn}
\DeclareMathOperator{\Time}{\mathcal{T}}
\DeclareMathOperator{\Trace}{\mathrm{Tr}}

%Integral operators
\newcommand{\integ}[1]{\int\!\!\!\:\ud{#1}\:}
\newcommand{\iinteg}[2]{\integ{#1}\!\!\!\integ{#2}}
\newcommand{\iiinteg}[3]{\integ{#1}\!\!\!\integ{#2}\!\!\!\integ{#3}}

%Brakets
\newcommand{\bra}[1]{\langle{#1}|}
\newcommand{\ket}[1]{|{#1}\rangle}

\newcommand{\abraket}[2]{\left\langle{#1}\middle|{#2}\right\rangle}
\newcommand{\braket}[2]{\langle{#1}|{#2}\rangle}
\newcommand{\bigbraket}[2]{\bigl\langle{#1}\big|{#2}\bigr\rangle}
\newcommand{\abrakket}[3]{\left\langle {#1}\middle|{#2}\middle|{#3} \right\rangle}
\newcommand{\brakket}[3]{\langle{#1}|{#2}|{#3}\rangle}
\newcommand{\bigbrakket}[3]{\bigl\langle{#1}\big|{#2}\big|{#3}\bigr\rangle}

%sqrt not scaling with the superscript
\newlength{\back}
\newcommand{\tsqrt}[2]{%
\settowidth{\back}{${#1}^{#2}$}%
\sqrt{\vphantom{#1}\hphantom{{#1}^{#2}}}\hskip-\back{#1}^{#2}%
}

%temporary counters
\newcounter{saveCounter1}
\newcounter{saveCounter2}
\newcounter{backupCounter}

%allow page breaks for equations (\\* prevents them at that line)
%\allowdisplaybreaks[2]

%figure directory
\def\figdir{../figures}

% change the section numbering to roman
%\renewcommand \thesection{\Roman{section}}

% thick line for tabular header and foot
\newcommand{\thline}{\noalign{\hrule height 1.0pt}}

% abbreviations for the spin components
\newcommand{\aaaa}{\alpha\alpha\alpha\alpha}
\newcommand{\abab}{\alpha\beta\alpha\beta}
\newcommand{\baba}{\beta\alpha\beta\alpha}
\newcommand{\abba}{\alpha\beta\beta\alpha}
\newcommand{\baab}{\beta\alpha\alpha\beta}
\newcommand{\bbbb}{\beta\beta\beta\beta}
\newcommand{\aabb}{\alpha\alpha\beta\beta}
\newcommand{\bbaa}{\beta\beta\alpha\alpha}

\definecolor{zgreen}{RGB}{134, 164, 57}
\definecolor{zred}{RGB}{206, 46, 41}

\begin{document}
\title{}
\thanks{}
\author{\L{}. M. Mentel}
\email{Email: l.m.mentel@vu.nl}
\affiliation{Section Theoretical Chemistry, VU University, Amsterdam, The Netherlands}
\affiliation{Pohang University of Science and Technology, Pohang, South Korea}

\date{\today}

\begin{abstract}
abstract
\end{abstract}

\keywords{keywords}%Use showkeys class option if keyword display desired
\maketitle

\section{intro}

\begin{align}\notag
{\color{zred}n_{\textrm{Na}_2\textrm{O}}} &= w^{\textrm{Na}_2\textrm{O}}_{\textrm{NaOH}} \cdot {\color{zgreen}x_{\textrm{NaOH}}} \\ \notag
{\color{zred}n_{\textrm{K}_2\textrm{O}}} &= w^{\textrm{K}_2\textrm{O}}_{\textrm{KOH}} \cdot {\color{zgreen}x_{\textrm{KOH}}} \\ \notag
{\color{zred}n_{\textrm{Al}_{2}\textrm{O}_{3}}} &= w^{\textrm{Al}_{2}\textrm{O}_{3}}_{\textrm{Al(OC}_{3}\textrm{H}_{7}\textrm{)}_{3}} \cdot {\color{zgreen}x_{\textrm{Al(OC}_{3}\textrm{H}_{7}\textrm{)}_{3}}} \\ \notag
{\color{zred}n_{\textrm{SiO}_{2}}} &= w^{\textrm{SiO}_{2}}_{\textrm{SiO}_{2}} \cdot {\color{zgreen}x_{\textrm{SiO}_{2}}} \\ \notag
{\color{zred}n_{\textrm{H}_2\textrm{O}}} &=
w^{\textrm{H}_2\textrm{O}}_{\textrm{NaOH}} \cdot {\color{zgreen}x_{\textrm{NaOH}}}
+ w^{\textrm{H}_2\textrm{O}}_{\textrm{KOH}} \cdot {\color{zgreen}x_{\textrm{KOH}}}
+ w^{\textrm{H}_{2}\textrm{O}}_{\textrm{Al(OC}_{3}\textrm{H}_{7}\textrm{)}_{3}} \cdot {\color{zgreen}x_{\textrm{Al(OC}_{3}\textrm{H}_{7}\textrm{)}_{3}}}
+ w^{\textrm{H}_2\textrm{O}}_{\textrm{H}_2\textrm{O}} \cdot {\color{zgreen}x_{\textrm{H}_2\textrm{O}}}  \\ \notag
%{\color{zred}n_{\textrm{TMACl}}} &= w^{\textrm{TMACl}}_{\textrm{TMACl}} \cdot {\color{zgreen}x_{\textrm{TMACl}}} \\ \notag
\end{align}

$$
\begin{bmatrix}
w^{\textrm{Na}_2\textrm{O}}_{\textrm{NaOH}} & 0 & 0 & 0 & 0 \\
0 & w^{\textrm{K}_2\textrm{O}}_{\textrm{KOH}} & 0 & 0 & 0 \\
0 & 0 & w^{\textrm{Al}_{2}\textrm{O}_{3}}_{\textrm{Al(OC}_{3}\textrm{H}_{7}\textrm{)}_{3}} & 0 & 0\\
0 & 0 & 0 & w^{\textrm{SiO}_{2}}_{\textrm{SiO}_{2}} & 0 \\
w^{\textrm{H}_2\textrm{O}}_{\textrm{NaOH}} & w^{\textrm{H}_2\textrm{O}}_{\textrm{KOH}} & w^{\textrm{H}_{2}\textrm{O}}_{\textrm{Al(OC}_{3}\textrm{H}_{7}\textrm{)}_{3}} & 0 & w^{\textrm{H}_2\textrm{O}}_{\textrm{H}_2\textrm{O}}\\
\end{bmatrix}
\cdot
\begin{bmatrix}
{\color{zgreen}x_{\textrm{NaOH}}} \\
{\color{zgreen}x_{\textrm{KOH}}} \\
{\color{zgreen}x_{\textrm{Al(OC}_{3}\textrm{H}_{7}\textrm{)}_{3}}} \\
{\color{zgreen}x_{\textrm{SiO}_{2}}} \\
{\color{zgreen}x_{\textrm{H}_2\textrm{O}}} \\
\end{bmatrix}
=
\begin{bmatrix}
{\color{zred}n_{\textrm{Na}_2\textrm{O}}} \\
{\color{zred}n_{\textrm{K}_2\textrm{O}}} \\
{\color{zred}n_{\textrm{Al}_{2}\textrm{O}_{3}}} \\
{\color{zred}n_{\textrm{SiO}_{2}}} \\
{\color{zred}n_{\textrm{H}_2\textrm{O}}} \\
\end{bmatrix}
$$

\section{first section}

$$
\begin{bmatrix}
B_{11} & B_{12} & B_{13} & \cdots & B_{1m}\\
B_{21} & B_{22} & B_{23} & \cdots & B_{2m}\\
B_{31} & B_{32} & B_{33} & \cdots & B_{3m}\\
\vdots & \vdots & \vdots & \ddots & \vdots \\
B_{n1} & B_{n2} & B_{n3} & \cdots & B_{nm}\\
\end{bmatrix}
\cdot
\begin{bmatrix}
r_{1} \\
r_{2} \\
r_{3} \\
\vdots \\
r_{m} \\
\end{bmatrix}
=
\begin{bmatrix}
z_{1} \\
z_{2} \\
z_{3} \\
\vdots \\
z_{n} \\
\end{bmatrix}
$$

$$
\mathbf{B}\mathbf{r}=\mathbf{z}
$$

$$
\mathbf{r}=\mathbf{B}^{-1}\mathbf{z}
$$

$$
\mathbf{r}=\left(\mathbf{B}^{\textrm{T}}\mathbf{B}\right)^{-1}\mathbf{B}^{\textrm{T}}\mathbf{z}
$$

$$\mathbf{r}_{i},\quad\mathbf{z}_{i}$$

$$\mathbf{r}=\left(\mathbf{B}\mathbf{B}^{\textrm{T}}\right)^{-1}
\mathbf{B}^{\textrm{T}}\mathbf{z}$$

\begin{acknowledgments}
 acknowledgements
\end{acknowledgments}

\appendix
\section{appendix section title}

\bibliography{libraryfile}

\end{document}


\documentclass[a4paper]{article}

\usepackage{array}
\usepackage{gensymb}
\usepackage{graphicx}
\usepackage{pgfplots}
\usepackage{siunitx}

\title{Determining the Effect of Ramp Incline on Acceleration}
\date{3 October 2014}
\author{Tarik Onalan}

\begin{filecontents}{data.dat}
    xVal   yVal     xDel  yDel
    0.6016 0.034414 0.075 0.003536
    1.249  0.1666   0.075 0.0019
    2.057  0.30314  0.075 0.00964
    2.981  0.4459   0.075 0.0048
    3.750  0.58386  0.075 0.00484
\end{filecontents}

\begin{document}
    \maketitle
    \section{Introduction}
        The goal of this lab was to determine the effect of ramp incline on the
        acceleration of a cart. I predict that as ramp incline increases, acceleration
        of the cart will increase linearly.
    \section{Materials}
        \begin{enumerate}
            \item 1 Cart
            \item 1 Ramp
            \item 1 Ruler
            \item 1 Vernier Logger
            \item 1 Position Tracker
            \item 1 Computer
            \item 5 Books
        \end{enumerate}
    \section{Procedure}
        \begin{enumerate}
            \item Set up Vernier box with position logger
            \item Place one book on a flat surface
            \item Indicate a constant distance on the ramp
            \item Lay one end of the ramp on the book
            \item Place position logger on the elevated end of the ramp
            \item Place cart at beginning of indicated distance
            \item Let go of cart, track acceleration of cart
            \item Record average acceleration for the cart
            \item Repeat steps 2-7, iterating the book count (\(1\to5\))
        \end{enumerate}
    \section{Data}
        \noindent\resizebox{\textwidth}{!}{
            \Huge
            \begin{tabular}{|c|c||c|c|c|c|c|c|} \hline
                Height & Slope & Trial 1 & Trial 2 & Trial 3 & Trial 4 & Trial 5 & Average \\\hline
                \SI{1.5}{\cm} & \(0.6016\degree\) & \SI{0.03172}{\m\per\second\squared} & \SI{0.03257}{\m\per\second\squared} & \SI{0.03346}{\m\per\second\squared} & \SI{0.03795}{\m\per\second\squared} & \SI{0.03637}{\m\per\second\squared} & \SI{0.034414}{\m\per\second\squared} \\\hline
                \SI{3.1}{\cm} & \(1.249\degree\) & \SI{0.1659}{\m\per\second\squared} & \SI{0.1670}{\m\per\second\squared} & \SI{0.1683}{\m\per\second\squared} & \SI{0.1647}{\m\per\second\squared} & \SI{0.1671}{\m\per\second\squared} & \SI{0.1666}{\m\per\second\squared} \\\hline
                \SI{5.1}{\cm} & \(2.057\degree\) & \SI{0.3036}{\m\per\second\squared} & \SI{0.3099}{\m\per\second\squared} & \SI{0.3007}{\m\per\second\squared} & \SI{0.3080}{\m\per\second\squared} & \SI{0.2935}{\m\per\second\squared} & \SI{0.30314}{\m\per\second\squared} \\\hline
                \SI{7.4}{\cm} & \(2.981\degree\) & \SI{0.4492}{\m\per\second\squared} & \SI{0.4431}{\m\per\second\squared} & \SI{0.4485}{\m\per\second\squared} & \SI{0.4476}{\m\per\second\squared} & \SI{0.4411}{\m\per\second\squared} & \SI{0.4459}{\m\per\second\squared} \\\hline
                \SI{9.3}{\cm} & \(3.750\degree\) & \SI{0.5887}{\m\per\second\squared} & \SI{0.5813}{\m\per\second\squared} & \SI{0.5839}{\m\per\second\squared} & \SI{0.5808}{\m\per\second\squared} & \SI{0.5846}{\m\per\second\squared} & \SI{0.58386}{\m\per\second\squared} \\\hline\hline
                \multicolumn{8}{|c|}{Uncertainty}\\\hline
                \SI{0.05}{\cm} & \(0.075\degree\) & \SI{0.003536}{\m\per\second\squared} & \SI{0.0019}{\m\per\second\squared} & \SI{0.00964}{\m\per\second\squared} & \SI{0.0048}{\m\per\second\squared} & \SI{0.00484}{\m\per\second\squared} &\\\hline
            \end{tabular}
        }\\

        \begin{tabular}{|c|c|c|c|}
            \hline
            Start Point & End Point & Length of Track & Uncertainty \\\hline
            \SI{50}{\cm} & \SI{192.2}{\cm} & \SI{142.2}{\cm} & \SI{0.1}{\cm} \\
            \hline
        \end{tabular}

        \begin{tikzpicture}
            \begin{axis}[
                scale=1.75,
                title={Acceleration Relative to Ramp Incline},
                xlabel={Slope [\(\degree\)]},
                ylabel={Acceleration [\si{\m\per\second\squared}]},
                xmin=0.0, xmax=4.0,
                ymin=0.0, ymax=0.75,
                legend pos=north west,
                ymajorgrids=true,
                grid style=dashed
            ]
                \addplot [
                    color=blue,
                    mark=*
                ] plot [
                    error bars/.cd,
                        x dir=both,
                        y dir=both,
                        x explicit,
                        y explicit
                ] table [
                    x=xVal,
                    y=yVal,
                    x error=xDel,
                    y error=yDel
                ]{data.dat};

                \addplot [
                    color=red,
                    mark=none,
                    domain=0:4
                ]{0.171249*x-0.0575874};

                \draw [
                    red,
                    thin
                ] (axis cs:0.5266,0.030878) rectangle (axis cs:0.6766,0.03795);

                \draw [
                    red,
                    thin
                ] (axis cs:1.174,0.1647) rectangle (axis cs:1.324,0.1685);

                \draw [
                    red,
                    thin
                ] (axis cs:1.982,0.2935) rectangle (axis cs:2.132,0.31278);

                \draw [
                    red,
                    thin
                ] (axis cs:2.906,0.4411) rectangle (axis cs:3.056,0.4507);

                \draw [
                    red,
                    thin
                ] (axis cs:3.675,0.57902) rectangle (axis cs:3.825,0.5887);

                \addlegendentry{Average}
                \addlegendentry{0.171249x-0.0575874}
            \end{axis}
        \end{tikzpicture}
    \section{Analysis}
        The collected data was remarkably consistent with the linear approximation
        of the acceleration, with an \(R^{2}\) value of \(0.998\). However, there
        is one error with the data: the acceleration is predicted to be zero when
        the angle of the ramp is \(0.3363\degree\), when the expected value would
        be \(0\degree\). This could be caused by human error at cart launch (pushing
        the cart forward at launch), of which there were many during data collection,
        requiring that we repeated some trials. Obviously not all errors were
        corrected, but this is expected with human uncertainty in data collection.
        The simple fact is, however, that acceleration increases as ramp incline
        increases, which supports my prediction.
\end{document}