\note{the numbers here are all taken as random as of now and need to be corrected.
The whole chapter should be reread with great care once the actual sample datasets
have appeared...}

This following example presents some of the more sophisticated possibilities
that \period offers in a step by step manner.
Also some basic concepts of signal-processing and their
application in \period will be discussed briefly.

This sample assumes that the basic principles of how to
use \period are well understood and that the user can
reproduce the example in
\helpref{Using \periodname}{HELP_HOWTOUSE}.

The problem presented here is an application
of \period on an extended astronomical dataset.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Footprint of an astronomical time-series photometric data set}

In optical astronomical observations a continuous data set
that is larger than 12 hours is very rare case.
The usual length of a ``run'' is most likely less than 12 hours,
depending on the star itself, the observatory and
season.

But this is not all that can happen during observations.
The technique used to observe a star also introduce
a pattern in time of how often a star will be observed.

Different techniques are used for different kinds of
stars and on the scientific goal for the current observations.
\myitemize{
\item {\bf high speed:} is used to observe stars which show
  frequencies that have periods of less than one hour, as
  long term stability of the instrumentation used may not be
  assumed apriori. Thus sophisticated calibrations
  have to be used to extend to longer periods.
  The data for these kind of observations is mostly equidistant
  and usually at least one measurement is taken every 10 seconds.
  Still some gaps are introduced into the data that are mostly due
  to clouds, instrumental problems or recalibration efforts.

  The usual instrumentation used in this setup is
  a {\it high-speed multichannel photometer}.

\item {\bf multiple star technique:} this technique does not allow
  for high frequency analysis with periods of less than 20 minutes,
  as the average gap in time between measurements is usually 7 to 10
  minutes (depending on the observing program). This gap is introduced
  by the fact that multiple stars are observed once after the other with
  a {\it photometer}.
  Usually at least 3 stars and the sky background are measured one after the other.
  One of these 3 stars is the star of interest. The others are used as
  calibration stars and should {\it not} show variability.
  As each star has first to be centered in the photometer aperture and then
  the integration can be started a measurement, the total time to
  measure {\it one} star is at least 90 seconds. Usually the stars
  are also observed in different {\bf filters}.

\item {\bf CCD photometer:} using a {\it CCD-camera} as acquisition device
  allows for a new hybrid-method of the both above mentioned, as the camera
  allows to measure all of the stars used in the multiple star technique at
  the same time, thus removing the need to reposition the telescope as well.
  The time in between measurements is currently (1997) close to one minute
  and is improving dramatically with each year. On the other hand long term
  stability of the system is also given.

\item {\bf single measurements} for variable stars with long periods
  (month to years) are also possible.
}

Usually time is granted for some telescopes for a few days at least to study
variable stars, so a ``run'' contains daily junks of measurements, which
are combined to a total time string.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Analysis of a run}
For this example data from a 3 star technique observation has been used.
The length of the observation is \toedit days.
The time string {\tt observ.dat} in the {\it samples directory}
should be loaded and then can be examined
in detail using the \helpref{time string graph}{timestring.graph} option of \period.

The time string can now be separated in different sub strings representing different nights.
For this the \helpref{subdivide selection}{timestring.subdivide} option of \period can be used.
The settings should work for the data. Now even the different nights are colored differently
in the \helpref{time string graph window}{timestring.graph}.

\subsection{Fourier analysis}
\subsection{Spectral window}
\subsection{Significance of a frequency}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Multi site campaign}
To decrease the large gaps in time the only possibility is to use
telescopes located all over the world. This means that all of the
telescopes are interconnected.
\myitemize{
\item \urlref{Delta Scuti Network (DSN)}{\DSNHOME},
\item \urlref{Whole Earth Telescope (WET)}{\WETHOME},
\item \urlref{Small Telescope Array with CCD Cameras(STACC)}{\STACCHOME}
}
are a few of the currently better known networks.

These telescopes located over all continents do not only
improve time resolution due to the telescopes situated in
different time zones, but also improves chances for good weather at
at least one site of the globe every day...

As the observations of the dataset loaded were made in \toedit an appropriate
label for that site shall be given by selecting {\it all} data points and
then using the \helpref{Combine substrings}{timestring.rename} to give the
selected time string an new common label of
``\toedit'' in the attribute {\it observatory}.

Now a time string for observations made at additional observatories has
to be appended. With the \menuentry{Import time string} in the
\menu{time string} additional time strings can be loaded.
The time string {\tt sites-u.dat} in the {\it samples directory} is needed now.
This file also contains the appropriate labels for the different
observatories, where the data has been taken. No changes in the
\helpref{import format dialog}{timestring.import.dialog} have to be made.

Examining the whole data with \helpref{time string graph}{timestring.graph} option of \period.

The time string can now be separated in different substrings representing different nights.
For this the \helpref{subdivide selection}{timestring.subdivide} option of \period can be used.
The settings should work for the data. Now even the different nights are colored differently
in the \helpref{time string graph window}{timestring.graph}.

\subsection{Fourier analysis}

\subsection{Spectral window}

\subsection{Period analysis}

\subsection{Phase plot - noise level for different subsets}

\subsection{Using weighted data}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Combining campaigns from different years}

\subsection{Fourier analysis}

\subsection{Spectral window}

\subsection{Period analysis}

\subsection{Phase plot}

\subsection{Amplitude variations}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Other possible applications}
There are a lot of other applications for which \period can be very useful.
Some of then will be presented here.

\subsection{A fit to different filters simultaneously}
As has already been shown \period can create a best fit of amplitudes
for different subsets of a time string. But that is not all, as it allows
to calculate {\bf amplitude and phase} variations at the same time.
This can be used to find a best fit to two substrings that
represent different physical parameters of a certain object,
but which share the same frequency.

One such example is the observation of a star in many different filters.
There are two possibilities to do so:
\myitemize{
\item {\bf ``Normal calculation'' of a fit:} For this a best fit for
  {\bf all} parameters has to be calculated with one of the subsets.
  Then the other subset has to be selected and just Amplitudes and phases
  may be calculated anew (with the use of the \button{Calculate} in the ``Fit'' filer).
  Then the amplitudes and phases for the different subsets may be
  examined and variations can be found.

  \note{The drawback in this case is that the frequency does not get improved,
  and that so the frequency may produce a best fit for one frequency,
  but not a good one for the other. Cross checks with the other subsets used
  to fit the frequencies as well should also be made and care has to be taken.}

  In special cases the \button{Improve Special} in the ``Fit'' filer
  may also be used if the phases should be kept fixed.

\item {\bf Amplitude and phase variation:} With this option \period tries to improve
  a set of amplitudes and phases for each subset (filter) separately, but improving
  the frequency as a common variable.

  \note{The drawback with this method is that the calculation increases for the
  most general case,
  where for all frequencies amplitude and phase-variations are calculated,
  the number of points will increase by a factor of 2 in the most optimistic case,
  but the degrees of freedom will increase by a factor of 5/3 for two subsets.
  So, in the case that the number of points of the second subset are
  less then 2/3 of the number of points then the first one, this does not
  mean numerical improvement of the fit.
  The fit becomes more instable numerically than it has been before!
  In this case the first method should be used with the subset with the
  most points.

  This rational changes, when weighted data is used.
  In that case it is not easy to say, where the borderline would be...
  }
}

\subsection{Asymmetric light-curves}
The light curve of many stars show asymmetries from a sinusoidal
curve, some even bumps in the light curve, so \period can also
cope with this.

Fourier theory offers the general idea to use the harmonics
of a frequency (base frequency times an integer as new frequency)
with a different amplitude and phase, to fit an arbitrary curve.

In the case of an asymmetric light curve, which can be best observed
with the \helpref{phase plot tool}{period.phase} tool of \period,
the Fourier spectrum will show at the frequency, twice the frequency,
etc. a peak, some of which may be very small, others may prove to be
significant.

A detailed description of how to enter harmonics as frequencies can
be found in the \helpref{Fit folder}{period.folder}.

\subsection{Frequency combination}
Linear theory also cannot explain frequency combinations.
That means that a frequency, that is a sum of two other frequencies,
is found to be significant in a light curve of a star.
No bulletproof physical reason has emerged yet, but
{\it mode coupling} one possible explanation.

A detailed description of how to enter frequency combinations as frequencies can
be found in the \helpref{Fit folder}{period.folder}.

\note{Frequency combinations should {\bf only} be used when a frequency looks suspiciously
  like a sum of two others. That means that the difference between the independently
  computed value and the sum of the other two is {\it negligible}.
  In this case the use of frequency combination improves the stability of the
  numerical fit, as the degrees of freedom decrease.}

%%% Local Variables:
%%% mode: latex
%%% TeX-master: "period98"
%%% End:


\section{An overview of the \texttt{Effects} framework}
\label{effects}

\texttt{Effects}~\cite{brady:effects} is an \idris{} library which handles
side-effects such as state, exceptions, and I/O as \emph{algebraic
effects}~\cite{Plotkin2009}. In particular, it supports parameterising effects
by an input and output \emph{state}, which permits effectful programs to track
the progress of a resource usage protocol. Effectful programs are written
in a monadic style, with \texttt{do}-notation, with their type stating which
specific effects are available:
%Effectful
%programs are described using the following data type,
%in the simplest case:

\begin{SaveVerbatim}{efftype}

Eff : (m : Type -> Type) ->
      (es : List EFFECT) -> (a : Type) -> Type

\end{SaveVerbatim}
\useverb{efftype}

\noindent
\texttt{Eff} is parameterised over a \emph{computation context}, \texttt{m},
which describes the context in which the effectful program will be run, a
list of side effects \texttt{es} that the program is permitted to use, and the
program's return type \texttt{a}. The name \texttt{m} for the computation context is
suggestive of a monad, but there is no requirement for it to be so.

For example, the following type carries an integer state,
throws an exception of type \texttt{String} if the state reaches 100,
and runs in a \texttt{Maybe} context:

\begin{SaveVerbatim}{addState}

addState : Eff Maybe [STATE Int, EXCEPTION String] ()
addState = do val <- get
              when (val == 100) (raise "State too big")
              put (val + 1)

\end{SaveVerbatim}
\useverb{addState}

\subsection{Implementing Effects}

Effects such as `State' and `Exception' are described as algebraic data types,
and run by giving \emph{handlers} for specific computation contexts.
Effects have a corresponding \emph{resource} (in the case of state, the
resource is simply the current state). Executing an effectful operation may
change the resource and return a value:

\begin{SaveVerbatim}{efffam}

Effect : Type
Effect = (in_res : Type) -> (out_res : Type) ->
         (val : Type) -> Type

\end{SaveVerbatim}
\useverb{efffam}

\noindent
For example, the state effect is described as follows:

\begin{SaveVerbatim}{stateeff}

data State : Effect where
     Get :      State a a a
     Put : b -> State a b ()

\end{SaveVerbatim}
\useverb{stateeff}

\noindent
That is, \texttt{Get} returns a value of type \texttt{a} without updating
the resource type. \texttt{Put} returns nothing, but has the effect of updating
the resource. To make an effect usable, we implement a handler
for a computation context by making an instance of the following class:

\begin{SaveVerbatim}{effhandler}

class Handler (e : Effect) (m : Type -> Type) where
     handle : res -> (eff : e res res' t) ->
              (k: res' -> t -> m a) -> m a

\end{SaveVerbatim}
\useverb{effhandler}

\noindent
The \texttt{handle} function takes the input resource, an effect which may
update that resource and execute a side-effect, and a continuation \texttt{k}
which takes the updated resource and the return value of the effect. We use
a continuation here primarily because there is no restriction on the number of
times a handler may invoke the continuation (raising an exception, for example,
will not invoke it). Reading and updating states is handled
for all computation contexts \texttt{m}:

\begin{SaveVerbatim}{statehandler}

instance Handler State m where
     handle st Get     k = k st st
     handle st (Put n) k = k n ()

\end{SaveVerbatim}
\useverb{statehandler}

\noindent
Finally, we promote \texttt{State} into a concrete effect \texttt{STATE}, and
the \texttt{Get} and \texttt{Put} operations into functions in \texttt{Eff}, as
follows:

\begin{SaveVerbatim}{stateconc}

STATE : Type -> EFFECT
STATE t = MkEff t State

get : Eff m [STATE x] x
get = Get

put : x -> Eff m [STATE x] ()
put val = Put val

\end{SaveVerbatim}
\useverb{stateconc}

\noindent
A concrete effect is simply an algebraic effect type paired with its current
resource type. This, and other
technical details, are explained in full elsewhere~\cite{brady:effects}.
For the purposes of this paper, it suffices to know how to describe and
handle new algebraic effects.

\subsection{Resource Protocols as Effects}
\label{rp-effects}
\begin{SaveVerbatim}{fileeff}
{-                                             { Input resource type }   { Output resource type } { Value } -}

data FileIO : Effect where
     Open      : String -> (m : Mode) -> FileIO     ()                    (Either () (OpenFile m)) ()
     Close     :                         FileIO     (OpenFile m)          ()                       ()

     ReadLine  :                         FileIO     (OpenFile Read)       (OpenFile Read)          String
     WriteLine : String ->               FileIO     (OpenFile Write)      (OpenFile Write)         ()
     EOF       :                         FileIO     (OpenFile Read)       (OpenFile Read)          Bool
\end{SaveVerbatim}

\begin{figure*}[t]
\begin{center}
\useverb{fileeff}
\end{center}
\caption{File Protocol Effect}
\label{fig:fileeffect}
\end{figure*}
More generally, a program might modify the set of effects available.
This might be desirable for several reasons, such as adding a new
effect, or to update an index of a dependently typed state. In this
case, we describe programs using the \texttt{EffM} data type:

\begin{SaveVerbatim}{effmtype}

EffM : (m : Type -> Type) ->
       (es : List EFFECT) -> (es' : List EFFECT) ->
       (a : Type) -> Type

\end{SaveVerbatim}
\useverb{effmtype}

\noindent
\texttt{EffM} is parameterised over the context and type as before, but
separates input effects (\texttt{es}) from output effects (\texttt{es'}).
In fact, \texttt{Eff}
is defined in terms of \texttt{EffM}, with equal input/output effects.
We can use this to describe how effects follow resource protocols. A simple
example is a file access protocol, where a file must be opened before it
is read or written, and a file must be closed on exit.

Figure \ref{fig:fileeffect} shows how the protocol is encoded as an
effect.
Note that the types of the input and output resources describes how resource
state changes in each operation: opening a file may fail, so
changes an empty resource to
a resource containing either a unit or an open file;
reading a line is only possible if the
resource is a file open for reading, etc.
The handler for this effect for an \texttt{IO} computation context will
execute the required primitive I/O actions.

The following program type checks, and therefore implicitly carries
a proof that the file resource protocol is followed correctly:

\begin{SaveVerbatim}{testfile}

testFile : Eff IO [FILE_IO (), STDIO] ()
testFile = do open "testFile" Read
              if_valid then do str <- readLine
                            close
                            putStrLn str
                       else putStrLn "Error"

\end{SaveVerbatim}
\useverb{testfile}

\noindent
The type of \texttt{testFile} states
that File I/O and console I/O are available effects, and in particular that
the resource associated with the File I/O will be in the same state on entry
and exit. We use \texttt{if\_valid} to handle possible failure---this is
a function provided by the \texttt{Effects} library which checks whether
a resource of type \texttt{Either a b} indicates failure (\texttt{Left a})
or success (\texttt{Right b}). In this case, the initial resource in the valid
branch is \texttt{OpenFile Read}, indicating that the file has been successfully
opened for reading, whereas in the failing branch, the resource remains as \texttt{()}.

Attempting to write to the file, failing to check for
success, or failing to open or close the
file, would cause a \emph{compile-time} error.

We will use this technique extensively
throughout this paper: describe a resource usage protocol in terms of
state transitions; implement an effect which captures that protocol; and implement
programs which, by using this effect, implicitly carry a proof that the resource
protocol has been correctly followed.

% =================================================
% =================================================


\section{Metatheory}
\label{sec:metatheory}

\lstMakeShortInline[keepspaces,style=rule]@

There are several connections between the type system and
the operational semantics, which we state as a single type soundness
theorem.
%
The theorem relies on several standard notions like store typing
$\vdash \Store : \SE$ and agreement of the results in the value environment
with the type environment $\SE \vdash \VEnv:\E$ that we define
formally in~\cref{sec:metatheory:proofs} where we also present selected cases of the
proofs.
%
The non-standard part is the handling of permissions. With
$\Rawloc\Perm$ we extract the underlying raw locations from the
permissions as in $\Rawloc{\Multi\IBORROW\hspace{0.5mm}\Multi\MBORROW\hspace{0.5mm}\Loc} = \Loc$
and with $\Reach\Store\VEnv$ we transitively trace the
addresses reachable from $\VEnv$ in store $\Store$. We write
$\SE\le\SE'$ and $\Store \le \Store'$ for extending the domain of the
store type and of the store, respectively.
%
The permission set contains the set
of addresses that can be used during evaluation. It is managed by the
region expression as well as by creation and use of resources as
shown in \cref{sec:sem}.
%
We distinguish several parts of the value
environment $\VEnv$ that correspond to the different kinds of bindings in the
type environment: $\Active\VEnv$ for active entries of direct
references to linear resources, closures, etc; $\MutableBorrows\VEnv$ for
affine borrows or resources;
$\ImmutableBorrows\VEnv$ for unrestricted values including
unrestricted borrows;
and $\Suspended\VEnv$ for suspended entries. The judgment
$\SE \vdash \VEnv:\E$ is defined in terms of this structure.
We treat
$\Reach\Store\VEnv$ as a multiset to properly discuss linearity and
affinity. We use the notation $\MultiNumber x M$ for the number of
times $x$ occurs in multiset $M$.

\newcommand\resultOk[2]{
  $R#2 = \Ok{\Store#2, \Perm#2, r#2}$
}
\newcommand\resultEnv[2]{
  $\SE#1 \le \SE#2$, $\Store#1 \le \Store#2$, $\vdash \Store#2 : \SE#2$
}
\newcommand\resultPermDom[2]{
  $\Perm#2$ is wellformed and
  $\Rawloc{\Perm#2} \subseteq \Dom{\Store#2} \setminus {\Store#2}^{-1}
  (\StFreed)$.
}
\newcommand\resultReachPerm[2]{
  $\Reach0{r#2} \subseteq \Perm#2$,
  $\Reach{\Store#2}{r#2} \subseteq \Sclos{\Perm#2}$
  % \textcolor{red}{
    $\cap (\Reach{\Store#2}{\VEnv#1} \setminus
    \Reach{\Store#2}{\Suspended{\VEnv#1}}
    \cup \Dom{\Store#2} \setminus \Dom{\Store#1})$.
  % }
}
\newcommand\resultFrame[3]{
  % input, inputenv, output
  Frame: \\
  For all $\Loc \in \Dom{\Store#1} \setminus
  \Rawloc{\Reach{\Store#3}{\VEnv#2}}$ it must be that
  \begin{itemize}
  \item $\Store#3 (\Loc) = \Store#1 (\Loc)$ and
  \item  for any $\Addr$ with $\Rawloc\Addr = \{\Loc\}$,
    $\Addr \in \Perm#1 \Leftrightarrow \Addr\in\Perm#3$.
  \end{itemize}
}
\newcommand\resultImmutables[3]{
  % input, inputenv, output
  Unrestricted values, resources, and borrows: \\
  For all $\Addr \in
  \Reach{\Store#3}{\ImmutableBorrows{\VEnv#2}, \Suspended[\kun]{\VEnv#2}}$ with
  $\Rawloc\Addr = \{\Loc\}$, it must be that
  $\Loc\in\Dom{\Store#1}$,
  $\Store#3 (\Loc) = \Store#1 (\Loc) \ne \StFreed$
  and $\Addr\in\Perm#3$.
}
\newcommand\resultMutables[3]{
  % input, inputenv, output
  Affine borrows and resources:\\
  For all $\Addr \in  \Reach{\Store#3}{\MutableBorrows{\VEnv#2}, \Suspended[\kaff]{\VEnv#2}}$
  with $\Rawloc\Addr = \{\Loc\}$, it must be that
  $\Loc\in\Dom{\Store#1}$. If $\Addr\ne\Loc$, then
  $\Store#3 (\Loc) \ne \StFreed$.
  If $\Addr \in \Reach{\Store#3}{\Suspended[\kaff]{\VEnv#2}}$, then
  $\Addr \in \Perm#3$.
}
\newcommand\resultSuspendedXXX[3]{
  % input, inputenv, output
  Suspended borrows: \\
  For all $\Addr \in \Reach{\Store#3}{\Suspended{\VEnv#2}}$ with
  $\Rawloc\Addr = \{\Loc\}$ it must be that $\Addr \in \Perm#3$
  and  $\Store#3 (\Loc) \ne \StFreed$.
  % \begin{itemize}
  % \item If $\Addr = \IBORROW\Addr'$, then $\Loc\in\Dom{\Store#1}$ and
  %   $\Store#3 (\Loc) = \Store#1 (\Loc) \ne \StFreed$.
  % \item If $\Addr = \MBORROW\Addr'$ and
  %   $\Loc\in\Dom{\Store#1}$, then
  %   $\Store#3 (\Loc) \ne \StFreed$.
  % \end{itemize}
}
\newcommand\resultResources[3]{
  % input, inputenv, output
  Resources: Let $\REACH#1 = \Reach{\Store#1}{\Active{\VEnv#2}}$.  Let
  $\REACH#3 =\Reach{\Store#3}{\Active{\VEnv#2}}$.
  \\
  For all $\Loc\in \REACH#1$ it must be that
  $\MultiNumber\Loc{\REACH#1}=\MultiNumber\Loc{\REACH#3}=1$,
  % \textcolor{red}{
  %   either $\Loc\notin\Perm#3$ and $\Store#3 (\Loc) =\StFreed$
  %   or $\Loc\in\Perm#3$ and $\Loc \in \Reach{\Store#3}{r#3}$.
  % }
  % \textcolor{blue}{
    $\Loc\notin\Perm#3$, and if $\Store#1(\Loc)$ is a resource, then
    $\Store#3 (\Loc) = \StFreed$.
  % }
}
\newcommand\resultThinAir[2]{
  No thin air permission: \\
  $\Perm#2 \subseteq
  \Perm#1 \cup ( \Dom{\Store#2} \setminus \Dom{\Store#1})$.
  % For all $\Addr\in {\Perm#2}$, $\Addr
  % \in \Perm#1 \cup ( \Dom{\Store#2} \setminus \Dom{\Store#1})$.
}
\newcommand\assumeWellformed[1]{
  $\Perm#1$ is wellformed and $\Rawloc{\Perm#1} \subseteq
  \Dom{\Store#1} \setminus {\Store#1}^{-1} (\StFreed)$
}
\newcommand\assumeIncoming[2]{
  Incoming Resources:
  \begin{enumerate}
  \item $\forall \Loc\in \Rawloc{\Reach{\Store#1}{\VEnv#2}}$,
    $\Store#1 (\Loc) \ne \StFreed$.
    % suspended bindings must not point to freed resources
  \item $\forall \Loc \in \REACH#1
    =\Rawloc{\Reach{\Store#1}{\Active{\VEnv#2},\MutableBorrows{\VEnv#2},
      \Suspended[\kaff]{\VEnv#2}}}$,
    % if $\Affine\SE\Loc$ then
    $\MultiNumber\Loc{\REACH#1}= 1$.
  \end{enumerate}
}
\newcommand\assumeReachable[2]{
  $\Reach0{\VEnv#2} \subseteq {\Perm#1}$,
  $\Reach{\Store#1}{\VEnv#2} \subseteq \Sclos{\Perm#1}$.
}

\begin{restatable}[Type Soundness]{theorem}{SoundnessThm}\label{thm:soundness}
  Suppose that
  \begin{enumerate}[({A}1)]
  \item $\inferS{C}{\E}{e}{\tau}$
  \item\label{item:32} $\SE \vdash \VEnv : \E$
  \item\label{item:33} $\vdash \Store : \SE$
  \item\label{item:11} \assumeWellformed{}
  \item\label{item:12} \assumeReachable{}{}
  \item $\Rawloc{\Active\VEnv}$,
    $\Rawloc{\MutableBorrows\VEnv}$,
    $\Rawloc{\ImmutableBorrows\VEnv}$, and
    $\Rawloc{\Suspended\VEnv}$ are all disjoint
  % \item  $\VEnv'$ with $\Rawloc{\VEnv'}
  %   \subseteq \Dom\Store$ and $\Dom\VEnv \cap \Dom{\VEnv'}=\emptyset$
  \item\label{item:15} \assumeIncoming{}{}
  \end{enumerate}
  For all $i\in\Nat$, if
  % Sorry for the ugly fix... I can't get lstinline to behave like
  % \lstMakeShortInline, but copy pasting would also be bad.
  \ \lstinline[style=rule]{R' = eval} $\Store$ $\Perm$ $\VEnv$ \lstinline[style=rule]{i e}
  %$\Store, \Perm, \VEnv \vdash {e}  \Downarrow^i R'$
  and $R'\ne \TimeOut$,
  then
  $\exists$ $\Store'$, $\Perm'$, $r'$, $\SE'$ such that
  \begin{enumerate}[({R}1)]
  \item \resultOk{}{'}
  \item \resultEnv{}{'}
  \item $\SE' \vdash r' : \tau$
  \item \resultPermDom{}{'}
  \item \resultReachPerm{}{'}
  \item \resultFrame{}{}{'}
  \item \resultImmutables{}{}{'}
  \item \resultMutables{}{}{'}
  % \item \resultSuspended{}{}{'}
  \item \resultResources{}{}{'}
  \item \resultThinAir{}{'}
  \end{enumerate}
\end{restatable}

% As customary with the functional style of semantics,
The proof of the
theorem is by functional induction on the evaluation judgment, which
is indexed by the strictly decreasing counter $i$.

The assumptions A1-A3 and results R1-R3 state the standard soundness properties
for lambda calculi with references.

The rest of the statement accounts for the substructural properties and
borrowing in the presence of explicit resource management.
%
% The rest of the statement accounts for the properties and interactions of
% borrowing with explicit resource management via substructural types.
%
% Some explanations are in order for the resource-related assumptions
% and statements.
%
Incoming resources are always active (i.e., not freed).
Linear and affine resources as well as suspended affine borrows have
exactly one pointer in the environment.
%
The Frame condition states that only store locations reachable from
the current environment can change and that all permissions outside
the reachable locations remain the same.
%
Unrestricted values, resources, and borrows do not change their
underlying resource and do not spend their permission.
%
Affine borrows and resources may or may not spend their
permission. Borrows are not freed, but resources may be freed.
%
Incoming suspended borrows have no permission attached to them and
their permission has been retracted on exit of their region.
%
A linear resource is always freed.
%
Outgoing permissions are either inherited from the caller or they
refer to newly created values.

\lstDeleteShortInline@

%%% Local Variables:
%%% mode: latex
%%% TeX-master: "main"
%%% End:


%!TEX root = thesis.tex

\chapter{Summary and Outlook}
\label{chapter-fazit}

In this chapter, a summary of the presented work is given. Additionally, some ideas for future work will be presented.
\section{Summary}
	In this thesis, it has been shown that implementing a monitor for the AUTOSAR Timing Extensions is problematic due to informal definitions. Because of this, the timing constraints defined in the Timing Augmented Description Language v2 (TADL2) were considered for the implementation of a monitoring tool. The TADL2 Timing Constraints were presented and the relations between them and the AUTOSAR Timing Constraints were described.\\
	After the relations between the AUTOSAR Timing Extensions and the timing constraints defined in TADL2 were explained, the term \textit{simple monitorable}, which ensures that a property on a possibly infinite trace can be monitored with finite resources were introduced. This term was expended by the possibility of creating new timestamps, which ensures that a violation of a constraint can be detected as early as possible. These terms were applied to the TADL2 timing constraints, with the result that eight of the constraints are simple monitorable with or without delay and nine constraints are not simple monitorable. Seven of the not simple monitorable constraints have memory requirements, which can be infinite in worst-cases. Two of them always have infinite memory requirements when monitoring infinite streams. The term \textit{simple monitorable} is not applicable to one constraint because it is not defined on event streams.\\
	After the theoretical part, an implementation for all of the TADL2 timing constraints in TeSSLa was given, except for the \textit{ComparionConstraints}, whose functionality was already implemented in TeSSLa. The worst-case runtime per timestamp with input events and the memory usage were analyzed. In the end, the runtime of the implementations was measured on large, generated traces.\\
	The timing constraints defined in TADL2 are not equal to the AUTOSAR Timing Extensions. However, some constraints have equal semantics and the implemented monitors can be used for the TADL2 constraints and the AUTOSAR Timing Extensions. Other TADL2 constraints have a less strict semantic than their AUTOSAR counterparts. For these constraints, the implemented monitors can check the correctness of a trace in parts, but not entirely.\\
\section{Future Work}
	For a real-world use of the monitors, more work on this topic is required. It is possible to map TeSSLa-specifications to reconfigurable hardware like FPGAs~\cite{8342124}. Because of memory and recursion restrictions, this is not possible for all specifications. %TODO Quelle
	The possibility of mapping the implementations on reconfigurable hardware would significantly increase the performance and opens the gate for real-world usage in embedded systems in the automotive industry.

	Some constraints were classified as \textit{not simple monitorable} but could be restricted so that they are \textit{simple monitorable}. For example, the \textit{InputSynchronization-} and \textit{OutputSynchronizationConstraint} are classified as \textit{always not simple monitorable} because they need to store every occurring color and therefore have a continuously growing memory usage. If all events have a minimal distance and the color attribute is defined as integers, which occur strictly ordered, a monitor with a fixed memory limit could be built. Restrictions of this kind may be possible to many of the timing constraints classified as \textit{not simple monitorable}. Further work on these possible restrictions is needed because it must be ensured that the monitored system also fulfills the restrictions.

% TODO manche (patternConstraint) finite monitorable benutzen map/list und sind somit nicht auf FGPA kompilierbar
% TODO Optimierungspotential, z.B. ArbitraryConstraint, OutputSynchronizationConstraint
% TODO einschränkung von Color?
% TODO LOLA_eff = finite monitorable

%TODO infinite monitorable ergänzen, um Bufferung etc

% TODO Laufzeitevalution auf sehr künstlichem Setup

%TODO Implementierung der Synchronization Constraints könnten bei 'Überfüllung' früher false geben


\chapter{Old computation book draft}

\theoremstyle{definition}
\newcounter{thmctr}
\newtheorem{mdef}[thmctr]{Definition}
\newtheorem{mque}[thmctr]{Question}
\newtheorem{mcon}[thmctr]{Conjecture}
\newtheorem{msco}[thmctr]{Strong Conjecture}
\newtheorem{mcor}[thmctr]{Corollary}
\newtheorem{mlem}[thmctr]{Lemma}
\newtheorem{mthm}[thmctr]{Theorem}
\newcommand\sno{\ensuremath{\mathcal N}}
\newcommand\syes{\ensuremath{\mathcal Y}}
\newcommand\Fin{\ensuremath{\operatorname{Fin}}}
\newcommand\powerset{\ensuremath{\mathcal{P}}}
\newcommand\fa[1]{\forall#1\,}
\newcommand\Fa[1]{\forall#1~}
\newcommand\FA[1]{\forall#1~~}
\newcommand\sfT{\mathsf{T}}
\newcommand\Typ{\mathsf{Typ}}
\newcommand\Either[2]{\mathsf{Either}~#1~#2}
\newcommand\Left[1]{\mathsf{Left}~#1}
\newcommand\Right[1]{\mathsf{Right}~#1}
\newcommand\Void{\mathsf{Void}}
\newcommand\Pair[2]{\mathsf{Pair}~#1~#2}
\newcommand\UDMach[1]{\mathsf{UDMach}~#1}
\newcommand\DMach[1]{\mathsf{DMach}~#1}
\newcommand\NMach[1]{\mathsf{NMach}~#1}
\newcommand\Mach[2]{\mathsf{Mach}~#1~#2}
\newcommand\Macha[1]{\mathsf{Mach}~#1}
\newcommand\RecRel{\mathsf{RecRel}}
\newcommand\Kleene[1]{\mathsf{Kleene}~#1}
\newcommand\RecFun{\mathsf{RecFun}}
\newcommand\DTM{\mathsf{DTM}}
\newcommand\NTM{\mathsf{NTM}}
\newcommand\sfDMach{\mathsf{DMach}}
\newcommand\sfNMach{\mathsf{NMach}}
\newcommand\sfFun{\mathsf{Fun}}
\newcommand\sfSet{\mathsf{Set}}
\newcommand\sfRel{\mathsf{Rel}}
\newcommand\sfVec{\mathsf{Vec}}
\newcommand\Vect[2]{\sfVec~#1~#2}
\newcommand\Relab[2]{\sfRel~#1~#2}
\newcommand\Fun[2]{\sfFun~#1~#2}
\newcommand\sfPred{\mathsf{Pred}}
\newcommand\Pred[1]{\sfPred~#1}
\newcommand\setB{\mathbb B}
\newcommand\decset{\mathcal D}
\newcommand\langset{\mathcal L}
% time complexity
\newcommand\TC{\mathcal{T}}
\newcommand\leTC{\ensuremath{\le_\TC}}
% time equivalence class
\newcommand\Teq{\mathbb{T}}
\newcommand\Teqsum{\mathbf{T}}
% space equivalence class
\newcommand\Seq{\mathbb{S}}
\newcommand\Seqsum{\mathbf{S}}
\newcommand\SC{\mathcal{S}}
% \newcommand\hom{\operatorname{hom}}
\newcommand\fite[3]{\text{if}~#1~\text{then}~#2~\text{else}~#3}
\newcommand\id{\ensuremath{\operatorname{id}}}
\newcommand\mE{\ensuremath{\mathcal E}}
\newcommand\mP{\ensuremath{\mathcal P}}
\newcommand\mM{\ensuremath{\mathcal M}}
\newcommand\mL{\ensuremath{\mathcal L}}
\newcommand\bB{\ensuremath{\mathbb B}}
\newcommand\amb{\operatorname{amb}}
\newcommand\ambc{\operatorname{ambc}}
\newcommand\fhead{\ensuremath{\operatorname{head}}}
\newcommand\ftail{\ensuremath{\operatorname{tail}}}
\newcommand\fcons{\ensuremath{\operatorname{cons}}}
\newcommand\aTIME{\operatorname{\alpha-TIME}}
\newcommand\idTIME{\operatorname{id-TIME}}
\newcommand\mPTIME{\operatorname{\mP-TIME}}
\newcommand\TIME{\operatorname{\mathsf{TIME}}}
\newcommand\DTIME{\operatorname{\mathsf{DTIME}}}
\newcommand\NTIME{\operatorname{\mathsf{NTIME}}}
\newcommand\EXPTIME{\ensuremath{\mathsf{EXP}}}
\newcommand\PTIME{\ensuremath{\mathsf{P}}}
\newcommand\NPTIME{\ensuremath{\mathsf{NP}}}
\newcommand\NSPACE{\operatorname{NSPACE}}
\newcommand\DSPACE{\operatorname{DSPACE}}
\newcommand\SDP{\ensuremath{\operatorname{SD}}}

\section{TODO}

cite CMI problem description;
understand Baker-Gill-Solovay (?) theorem and relativization;
read Rogers \cite{Rogers1987};
read Arora and Barak \cite{Arora2009};
read Marek and Remmel \cite{Marek2009};
read Boolos, Burgess, and Jeffrey \cite{Boolos2002}

\section{Diary}

In this document, I use the term \emph{predicate} to always mean
a total function that takes a bit string and gives a bit.
Furthermore, if $f$ is a predicate, then
I may write ``$x$ \emph{satisfies} $f$'' to mean $f(x) = 1$, and
I may write ``$f$ is \emph{satisfiable}'' to mean
that there exists $x$ that satisfies $f$.

\newcommand\encoding[1]{\langle#1\rangle}

I write $\encoding{x}$ to mean a binary encoding of $x$.
I write $\encoding{x,y}$ to mean a binary encoding of $x$
concatenated with a binary encoding of $y$.

The ATMB problem is ``Given a machine $m$, a string $x$,
and a number $n$,
does $m$ accept $x$ in $n$ steps or less?''
This problem is exptime-complete with respect to the length of
$\encoding{m,x,n}$. (cite?)

The bounded halting problem is:
``Given a machine $m$ and a number $n$,
does $m$ accept any string that is at most $n$ bits long?''
This is np-complete? (cite?)
% http://www.ics.uci.edu/~eppstein/161/960312.html
% sat-t-icalp.ps

\begin{enumerate}
\item Show that it is in exptime.
\item Show that it is in exptime-hard.
(This implies that it is not in p.
Show that it is polynomial-time many-one reducible to ATMB?
Use diagonalization perhaps?)
\item Show that it is in np.
\item Congratulations.
\end{enumerate}

\section{Defining computation}

A computation is a repeated application of a function $f$
until the output does not change anymore.
The computation begins with the input $x$ already in place.
Such computation produces the output $y$
in $n$ steps iff $n$ is the smallest number such that $f^{n+1}(x) = f^n(x) = y$
where $f^n(x)$ means $n$ times applying $f$ to $x$.
This function can be thought a transition function that describes
how the entire system (machine state and tape content) changes.
A machine can be seen as a function.

This is a special case of fractal? Chaotic function?

The zero function $f(x) = 0$ corresponds to a machine
that always accepts its input.

The function $f(x) = 2 \cdot x$ corresponds to a machine
that appends a zero bit to the memory, one by one.

What is the essence of computation?
Is it recursion?

This has to do with time-constructibility?

\section{Finding the problem}

Now I try to craft a problem that nondeterministic machines
can solve exponentially faster than deterministic machines can best do.
I am looking for a problem whose best deterministic solution
is an exhaustive search.
Formally, I am looking for a problem that is dexptime-hard but also in np.

``Find a string that satisfies a given satisfiable ptime-predicate,''
where \emph{ptime-predicate} means that
a machine can compute the predicate in an amount of time
that is a polynomial of the number of bits in the input string.

However, there is also an exptime-complete problem:
given a machine and a number $k$, determine if the machine
halts in at most $k$ steps.

What if I combine those problems into this problem:
``Given a ptime-predicate $p$ and a natural number $n$,
determine whether there is an $n$-bit string satisfying $p$?''
Showing that this problem is bounded below by dexptime
and bounded above by np would prove that p and np are not equal.

The input is $(p,n)$.
The output is a bit.

If the problem is to be in ptime,
the length of the string representation of $p$
must be a polynomial of $n$.

Suppose there exists $k$ such that the length of the input is in $\Theta(n^k)$.

Let the input be $(k,p,n)$?

The following question is a generalization of the p vs np problem:
Given the same amount of resources (space and time),
what is the maximum ratio of the number of functions that NTMs can compute
to the number of functions than DTMs can compute?
Informally, what is the maximum speedup
that nondeterminism can give a TM?
The answer of this question will answer the p vs np question.

How do I prove that a problem doesn't have better algorithm than brute force?
I have to see the paper that proves something is dexptime-complete.
Pebble game problem? Kolaitis and Panttaja?
Does that a problem can only be brute-forced at best
depend on the model of computation?
Show that the existence of faster algorithm raises a contradiction?

Should I switch from DTM and NTM to ATM (alternating Turing machine)?
Should I abandon TMs and use pebble games instead?
How about Boolean circuits?

The following is a nondeterminstic algorithm that
builds the string that will satisfy such predicate.
\begin{enumerate}
\item Let the current string be empty.
\item Either skip this step,
or pick a bit and append it to the current string.
\item If the current string satisfies the predicate, halt.
\item Otherwise go to step 2.
\end{enumerate}
The running time of that algorithm is a function of the length
of the shortest string that satisfies the predicate.
Let $s~p$ be the length of the shortest string that satisfies the predicate $p$.
We have just shown that the problem is in $\NTIME(O(s(p)))$.

Now, if we can show that for that problem
there is no better deterministic algorithm than the exhaustive search
(that is if the problem is exptime-hard),
then we prove that P and NP are not equal.

The size of the search space of all deterministic algorithms
that run in $n$ steps is smaller than...
$\DTIME(2^{s(p)})$.

Can the algorithm use any information from
the string representation of the predicate?

Suppose that there is a deterministic algorithm that can
always find an answer in polynomial time.

How many satisfiable predicates are there?
Let $c(n)$ be the number of predicates that can be satisfied
by an input that is not longer than $n$ bits.
\begin{align}
    c(0) &= 2^{2^0} - 1 = 1
    \\
    c(1) &= 2^{2^0 + 2^1} - 1 = 7
    \\
    c(2) &= 2^{2^0 + 2^1 + 2^2} - 1 = 127
    \\
    c(3) &= 2^{2^0 + 2^1 + 2^2 + 2^3} - 1 = 32,767
    \\
    c(n) &= 2^{2^{n+1}-1} - 1
\end{align}

I use the term \emph{$n$-least predicate} to mean that the predicate
can be satisfied by a string that is no longer than $n$ bits.

There exists an $n$-least predicate.

If two predicates differ, then their encodings will also differ.

A predicate can be encoded as a base-2 representation real number
between 0 inclusive and 1 exclusive.
The uncountability of real number implies that there is no algorithm
for determining whether any arbitrary predicate is satisfiable.

However, a predicate can also be encoded as a natural number
(by G\"odel numbering for example).
Natural numbers are countable.

\section{Introduction}

Roughly speaking, we say that a function is \emph{computable} or \emph{recursive}
if and only if it can be stated as a finite arrangement
of certain primitive operations we allow.

For example, if we only allow the constant function,
then the machine will either accept all input or reject all input.

\section{First attempt}

A \emph{recursive predicate} is a function having type $\mathbb N \to \{0,1\}$.
There is a bijection between $\{0,1\}^*$ and $\mathbb N$
so every function having type $\{0,1\}^* \to \{0,1\}$ can also be considPred{a} recursive predicate.
We say that $x$ \emph{satisfies} $p$ iff $px = 1$.
We say that $p$ is \emph{satisfiable} iff there exists $x$ that satisfies $p$.

The \emph{$p$-satisfaction problem}
and asks for the smallest $x$ that satisfies a given predicate $p$.
A related decision problem is the \emph{$p$-satisfiability problem} that
asks whether a given predicate $p$ is satisfiable.
This satisfiability problem allows us to show that $\PTIME \neq \NPTIME$
by constructing a satisfiable recursive predicate
$p$ in $\DTIME(\Theta n)$ such that
the corresponding $p$-satisfiability is in both $\NTIME(On)$ and $\DTIME(\Omega 2^n)$
where $n$ is the length of the shortest string that satisfies $p$.

An \emph{alphabet} is a finite countable non-empty set.

Many things can be \emph{recursive} or \emph{computable}: sets, functions, languages.

Blum \cite{Blum1967} defined a machine-independent complexity measure?
Blum speedup theorem implies $\EXPTIME = \PTIME$?

Rabin \cite{Rabin1977}?

Chow \cite{Chow1976} introduces the theory concisely.

Who? shows that partial computable functions are isomorphic to natural numbers.
This allows category theory to be used on computability theory.
An algorithm is a natural number.
An algorithm for simulating an algorithm: $\mathbb N \to \mathbb N$.
G\"odel numbering of partial recursive functions.
Formal systems.
Relates completeness, consistency, computability, decidability.

We use typed lambda calculus as our model of computation.

Informally, we construct a function $f$ such that $f$ is easy but $\SDP f$ is hard
such that there is no faster deterministic algorithm
than trying every possible subsequence.
A list of length $n$ has at most $2^n$ subsequences.

There is a bijection between $X^*$ and $\mathbb N$.
the empty string, 0, 1, 00, 01, 10, 11, 000, 001, 010, 011, 100, 101, 110, 111
\begin{align}
    \varphi [] &= 0
  \\ \varphi x &= \sum_{k=0}^{\mu x - 1} 2^k + \sum_{k=0}^{\mu x - 1} x_k \cdot 2^k
            \\ &= 2^{\mu x} - 1 + \sum_{k=0}^{\mu x - 1} x_k \cdot 2^k
\end{align}

Time hierarchy theorem?

The deterministic algorithm can use iterative deepening depth-first search:
\begin{align}
    sf &= \text{any $($map $f$ $\xi)$}
    \\
    \xi &= \text{fix} n []
    \\
    nx &= \text{map} (0:) x ++ \text{map} (1:) x
    \\
\end{align}
The nondeterministic algorithm:
\begin{align}
    sf &= gf[]
    \\
    gfx &= fx \vee \ambc (gf(0:x)) (gf(1:x))
\end{align}

\section{Graph theory}

We can see the tuple $(C,f)$ as a \emph{directed graph}
where each configuration is a vertex in the graph
and there is an edge from $x$ to $y$ if and only if $f(x) = y$.
An \emph{initial configuration} is a possible configuration from which the machine starts computing.
An initial configuration contains an input for the algorithm running on the machine.
A deterministic machine always starts computing from an initial configuration
and always either goes into infinite cycle or ends at terminal configuration.

\paragraph{Termination}
A configuration $x$ is \emph{terminal} iff
there is no $y$ such that $(x,y) \in f$.
A vertex is terminal iff its out-degree is zero.

A configuration $x$ \emph{eventually terminates}
iff there exists $n$ such that $f^n(x)$ is terminal.
Such configuration $x$ eventually terminates iff repeated application of $f$ to $x$
eventually produces a terminal configuration.
In the graph, such configuration $x$ eventually terminates iff
there is a path from $x$ to a terminal configuration.

\paragraph{Computation}
A \emph{computation} is a path in the graph.
More precisely, a computation from $x_0$ to $x_{n-1}$
is a path $[x_0, x_1, \ldots, x_{n-1}]$
such that $x_{k+1} = \beta x_k$ for each natural number $k$ from $0$ to $n-1$.
We can see by induction that $x_k = \beta^k x_0$ for each natural number $k$ from $0$ to $n-1$.

A \emph{complete computation} is a computation that begins at an initial configuration
and ends at a terminal configuration.
Subcomputation is to computation as subpath is to path.
The graph can be seen as a set of complete computations.

We say that the deterministic machine $D = (I,\beta)$ \emph{computes} a function
$f : A \to B$
that is isomorphic to
$f_N : \mathbb{N} \to \mathbb{N}$
that is in turn also isomorphic to
$f_D : I \to T$
where $T$ is the set of all terminal configurations of the machine
where $f_D$ is defined as the following function:
\begin{equation}
    f_D = \{ (x,y) \,|\, x \in C \,\wedge\, x \text{ eventually terminates at } y \}
\end{equation}
Formally we say $f_D x = y$ iff there exists
a natural number $n$ such that $\beta^n x = y$ and $y$ is terminal.
The functions $p$ and $q$ are the \emph{input encoding} function
and the \emph{output encoding} function.
If we ignore the time used by the machine,
we can see the machine as a function from $I$ to $T$.
$q \circ f = f_D \circ p$.

State every natural number $n$ as the sum of $p$ and $q$
where $p$ is the biggest prime less than $n$.

The encoding and decoding functions allow us to make
a distinction between a natural number
and the binary representation of natural number.

\section{A universal machine to simulate other machines?}

\[
    \UDMach{c} = \DMach{(\Pair{(\Fun{c}{c})}{c})}
\]

Machine or algorithm can be encoded as string.
\emph{Universal machines} simulate every machine.
A program corresponds to a \emph{partial computable function}.
Partial is not total.
Total function is a function defined for each element in its domain.
Partial function is a function that can be undefined for any number of elements in its domain.

The \emph{$c$-universal machine} of type $\UDMach{c}$ can compute every inhabitant of $\DMach{c}$.
The configuration type of the universal machine is $\Pair{(\Fun{c}{c})}{c}$.
\[
    I_u = \{ (\beta,x) \,|\, (I,\beta) : \DMach c \,\wedge\, x \in I \}
\]
Can a universal machine simulate all universal machines?
Let $t = (\Fun{c}{c},c)$.
Is $|t| = |(\Fun{t}{t},t)|$?
If and only if yes, then a universal machine can simulate all universal machines.

A universal deterministic machine is $U = (C_u, I_u, \beta_u)$
where the universal configuration set is $C_u = (C \to C, C)$.
A configuration of that universal machine is a tuple $(\beta, x)$.
This machine can compute everything every other machine can compute.
The universal machine transitions from $(\beta, x)$ to $(\beta, y)$
if and only if the simulated machine transitions from $x$ to $y$.
Let $u$ be the pairing function, that is $uab = (a,b)$.
Then
\begin{equation}
    u \beta \circ \beta = \beta_u \circ u \beta
\end{equation}
The universal transition function $\beta_u$ can be seen as a set:
\begin{equation}
    \beta_u = \{ ((\beta,x), (\beta,y)) \,|\, (x,y) \in \beta \}
\end{equation}
The inverse of the partially applied pairing function $u a$ is $r$
where $r (a,b) = b$.

\section{Recursive Function over Bitstrings}

Every inhabitant of $\Bit \to \Bit$ is recursive.

Every inhabitant of $\Bit \to \Bit \to \Bit$ is recursive.

For all $a$, the \emph{head} function $f [x 0, x 1, \ldots] = x 0$,
where $f : \List{a} \to a$, is recursive.

For all $a$, the \emph{tail} function $f [x 0, x 1, \ldots] = [x 1, \ldots]$,
where $f : \List{a} \to \List{a}$, is recursive.

Every well-formed well-typed lambda expression
that involves only recursive functions is recursive?

\section{Nondeterminism from two deterministic machines}

The author got the idea of defining a nondeterministic machine
using two deterministic transition functions
from Arora and Barak \cite[p.~40]{Arora2009}.
We can form a nondeterministic machine $N$
from two deterministic machines $D_0 = (C,I,\beta_0)$ and $D_1 = (C,I,\beta_1)$
(both machines must have the same configuration set and the same initial configuration set)
as follows:
\begin{enumerate}
    \item The sets of initial configurations are the same.
    \item If $x$ is a configuration of $D_0$ then $(0,x)$ is also a configuration of $N$.
    \item If $x$ is a configuration of $D_1$ then $(1,x)$ is also a configuration of $N$.
    \item Nothing else is a configuration of $N$.
    \item $\beta = P 0 \beta_0 \cup P 1 \beta_1$ where $P c X = \{ (c,x) \,|\, x \in X \}$.
    \item $x$ is $\beta$-terminal iff $x$ is $\beta_0$-terminal or $\beta_1$-terminal or both.
    \item Nothing else is $\beta$-terminal.
\end{enumerate}

Sum types: $\Either{a}{b} = \Left a | \Right b$.
Iff $x : a$ then $\Left x : \Either{a}{b}$.
Iff $y : b$ then $\Right y : \Either{a}{b}$.
The configuration type is $\Either{c_0}{c_1}$.
\[
    I =
    \{ \Left x \,|\, x \in I_0 \}
    \cup
    \{ \Right x \,|\, x \in I_1 \}
\]
\begin{align*}
    (\Left x, \Left y) \in \beta \iff (x,y) \in \beta_0
    \\
    (\Right x, \Right y) \in \beta \iff (x,y) \in \beta_1
\end{align*}

$\NMach c$.
$\beta : \Relab{c}{c}$.
Does $\Fun{c}{c} < \Relab{c}{c}$ strictly?

We can also form a deterministic machine $D$ from a nondeterministic machine $N$.

A machine computes a function $f : X \to Y$ as follows:
For each $x$ such that $f x$ is defined, the string $\hat x$ (the string encoding of $x$)
is an initial configuration of the machine.
For each $y = fx$, the configuration $\hat y$ (the configuration encoding of $y$)
is a terminal configuration of the machine.
There is a path from $\hat x$ to $\hat y$.
There is a machine that computes this $f$ in unit time: the oracle of $f$.
Then there is another machine that computes it asymptotically slower.
Then there is another machine that computes it even slower asymptotically.
This goes on and on.
We can always invent a slower machine.

\begin{enumerate}
    \item
        Every configuration of $N$ can branch to \emph{at most two} configurations.
        Formally for each configuration set $X$, it holds that $\mu(B X) \le 2 \cdot \mu X$
        where $\mu X$ is the size of $X$.
\end{enumerate}

$\NMach c$.

\section{Nondeterminism}

$N = (I,\beta) : \NMach c$
where $I : \Set{c}$ and $\beta : \Relab{c}{c}$.

Let $N$ be a nondeterministic machine $(C,I,\beta)$ where
Let $\beta \subseteq C \times C$ is the transition relation of $N$.
The tuple $(C,\beta)$ forms a graph.
There is an edge from $x$ to $y$ iff $(x,y)$ is in $\beta$.
with the following properties:
\begin{align}
    B^n X &= \{ (x,y) \,|\, x \in X \wedge (x,y) \in \beta^n \}
\end{align}
where $B X$ means $B^1 X$.

The relation $\beta$ can also be seen as an equivalent function $B : \powerset C \to \powerset C$
where $\powerset C$ is the power set of $C$.
Thus for every nondeterministic machine $(C, I, \beta)$
there is a deterministic machine $(\powerset C, \powerset I, B)$
that computes the same function at the same time.
But this deterministic machine is not countable.
Contradiction.
So nondeterminism bestows some power that deterministic machines cannot have.
There exists nondeterministic machine that cannot be simulated in equal time by deterministic machine.
(Is this a jump in logic? This seems wrong.)

But every deterministic machine can simulate
every nondeterministic machine by using breadth-first search.
So nondeterminism does not add any power?

Every deterministic machine is trivially a
nondeterministic machine since every transition function is a transition relation.

Is the set of functions computable by the nondeterministic machines
the same as that of deterministic machines?
Does it add any power?

\section{Uncomputable functions}

Each machine has infinitely many functions that it \emph{cannot compute}.
We prove this by diagonalization.
Suppose that the set of functions computable by a machine is $F = \{ f_0, f_1, f_2, \ldots \}$.
Suppose also that there is no function outside that set.
Alas, we can define a function $f$
such that $f0 \neq f_0 0$, $f1 \neq f_1 1$, $f2 \neq f_2 2$, and so on
such that $fn \neq f_n n$ for each natural number $n$.
This $f$ is not equal to any function in $F$ so it cannot be in that set.
Contradiction.

Nondeterministic machine is a $\sigma$-algebra of deterministic machine?
Can we relate nondeterminism to topology?

We can make it a topological space?
Nondeterministic reversible computation?
Remember that a configuration of a nondeterministic machine is a set.
Allow the no-computation: for each configuration $x$, make $x \in N x$.
Then make it reversible:
if $y \in N x$ then $x \in N y$.
Then make each subset of $B x$ to be in $N x$.
We can $(C,N)$ where $C$ is the set of all configurations of the machine
and $N : C \to 2^C$ is the neighborhood function.

Ullman? Sipser? defines NTM as DTM with transition relation instead of transition function.

We define $\beta^n$ as a composition of $n$ instances of $\beta$:
$\beta^0 = \text{id}$ and $\beta^1 = \beta$ and $\beta^n = \beta \circ \beta^{n-1}$.
The time complexity of a computation $x$
is the smallest $n$ such that $\beta^{n+1} x = \beta^n x$.

\section{Major theme in computability theory}

The idea is to encode almost \emph{everything}
(machines, algorithms, configurations, computations, numbers, graphs, you name it)
as a \emph{string} and then establish a bijection between strings and natural numbers.

Time-limited simulation of another machine:
simulate the machine as long as the number of steps do not exceed $f n$.
If the number of step exceeds $f n$ and the machine still does not terminate,
output $0$.
Truncated language?

A particular kind of machine called the \emph{recursive machines}
is equivalent to Turing machines with polynomial-time speedup/slowdown.

For each machine with transition function $t$ there exists another machine
with transition function $t' = t^p$
providing polynomial speedup.
Space usage of configuration $x$.
Length of program plus length of input.

\section{Differential topology and computation?}

A configuration is a point.

The transition function.

Unit step is in differential time?

What are we trying to say?


\include{preamble}

\title{Infinite Alphabet Parsing \\ and \\ Compact LR Parser}
\date{July 30, 2017}
\author{Alexei A. Smekalkine <ikle@ikle.ru>}

\begin{document}

\maketitle

\begin{abstract}
This article describes generalization of well-known shift-reduce
parsing techniques to infinite input alphabet and compact LR parser
generator based on this generalization.
\end{abstract}

\section{Base Definitions}
\def\A{\mathcal{A}}
\def\G{\mathcal{G}}
\def\P{\mathcal{P}}

\begin{enumerate}
\item	Let the alphabet $\A$ be a possibly infinite set of terminal
	symbols. We will use lower case Latin letters represented by a
	normal font to denote terminals from other symbols.

\item	Let the generator grammar $\G$ be a non-empty set of generator
	rules of the form $A \rightarrow \P$ where:
	\begin{itemize}
	\item	$A$ is non-terminal symbol. We will use upper case
		Latin letters represented by a normal font to denote
		non-terminals.

	\item	$\P$ is the production of rule defined below.
	\end{itemize}

\item	Let $\alpha$ be a possibly empty sequence of symbols, terminals
	and non-terminals, and $|\alpha|$ be the lenght of this sequence.
	We will use lower case Greek letters represented by a normal
	font to denote such sequences.

\item	Let $\P = \alpha$ be a production of a rule.
\end{enumerate}

\section{Look-Ahead}
\def\L{\mathcal{L}}
\def\F{\mathcal{F}}
\def\e{\varepsilon}
\def\J{\mathcal{J}}

The look ahead is a possibly empty sequence of input symbols (terminals)
that used together with DFA state to resolve conflicts with next state
decision while parsing.

\begin{enumerate}

\item	Let $\L_n$ be look-ahead set of sequences of length upto $n$.

\item	Let $\F_n(\alpha)$ be a set of a prefixes of length upto $n$ of
	sequences of terminals that can be derived from production
	$\alpha$. The special marker $\e$ denotes empty prefix, $|\e| = 0$.

	$$
	\F_0(\alpha) = \emptyset
	$$

	$$
	\F_1(\alpha) =
	\begin{cases}
		\{ \e \},	& \text{if } |\alpha| = 0		\\
		\{ a  \},	& \text{if } \alpha = a \beta		\\
		\F_1(B),	& \text{if }
			\alpha = B \beta \wedge \e \not \in \F_1(B)	\\
		\F_1(B) \cup \F_n(\beta),
				& \text{otherwise}
	\end{cases}
	$$

	where

	$$
	\F_n(B) = \bigcup_{\forall i \wedge A_i = B} \F_n(P_i)
	$$

	Note, we omit now general case for $n > 1$ for simplicity.
%	this will be defined later.
\end{enumerate}

\section{Item Sets}
\def\I{\mathcal{I}}
\def\S{\mathcal{S}}
\def\G{\mathcal{G}}

\begin{enumerate}
\item   Let $\I_{n,i,j,k}$ be the item number $j$ of the rule
	$A_i \rightarrow \P_i$ augmented with a look ahead set
	$\L_n(k,A_i)$ for the state $k$:

	$$
	\I_{n,i,j,k} = [ A_i \rightarrow \alpha \bullet \beta, \L_n(k,A_i) ]
	$$

	where $\alpha \beta = \P_i$, $|\alpha| = j$. We can read $j$ as
	the position of a marker $\bullet$ in the production $\P_i$.

\item	Let $\S_k(B,\G)$ be the start set of items for not-terminal $B$
	on the generator look ahead set $\G$ for state number $k$:

	$$
	\S_k(B,\G) = \{ \I_{i,0,k} | \forall i \wedge A_i = B \}
	$$

	where

	$$
	\L_0(k,B) = \emptyset
	$$

	$$
	\L_1(k,B) =
	\begin{cases}
		\F_1(B), & \text{if } \e \not \in \F_1(B) \\
		\F_1(B) \setminus \{ \e \} \cup \G, & \text{otherwise}
	\end{cases}
	$$

\item	Let $\I_{n,i,j,k}^*(\G)$ be the closure of the item $\I_{n,i,j,k}$
	on the generator look ahead set $\G$:

	$$
	\I_{n,i,j,k}^*(\G) =
	\begin{cases}
	\{ \I_{n,i,j,k} \} \cup \S_k(B,\G)^* \text, &
		\text{if } P_i = \alpha \bullet B \beta \\
	\{ \I_{n,i,j,k} \} \text, & \text{othewise}
	\end{cases}
	$$

	where

	$$
	\S_k(B,\G)^* = \bigcup_{\I \in \S_k(B,\G)} \I^*(\G)
	$$
\end{enumerate}

\section{State}
\def\C{\mathcal{C}}
\def\eoi{\text{\$}}

\begin{enumerate}
\item	Let the core $\C_k$ for the state number $k$ be a set of items.

\item	Let $\C_k^*$ be the closure of the core $\C_k$

	$$
	\C_k^* = \bigcup_{\I \in C_k} \I^*
	$$

\item	Let start state number $0$ be identified by $\C_0^*$ where

	$$
	\C_0 = \I_{n,0,0,0} \text{ and }
	\L_n(0,A_0) = \{ \eoi \} \text{ for } n > 0
	$$

	where $\eoi$ is a special end-of-input terminal.
\end{enumerate}

\iffalse
\section{draft}
	blalba: and for $k > 1$

	$$
	\F_k(\alpha) =
	\begin{cases}
		\J_k(B, \beta),	& \text{if }
			\alpha = B \beta \wedge \e \not \in \F_1(B)	\\
		\J_k(B, \beta) \cup \F_k(\beta),
				& \text{if }
			\alpha = B \beta \wedge \e      \in \F_1(B)
	\end{cases}
	$$

	where

	$$
	\J_k(B, \beta) = \{ a \alpha | a \in \F_1(B) \wedge \alpha \in \F_{k-1}(\beta) \}
	$$

	blabla:
	$$
	\F_k(B) = \bigcup_{\forall A_i = B \wedge \{ l | l \in \L(state) \}}
		\F_k(\P_i || l)
	$$
\fi

\end{document}


\chapter{Conclusion}

\label{ch:conclusion}

This thesis has presented my efforts to create a massively parallel SSFM codebase for the simulation of superfluid vortex dynamics in Bose--Einstein Condensates (BECs).
Starting from the SSFM and a discussion on the dynamics of ultracold atomic systems, I motivated the idea of dynamic quantum state engineering by introducing quantum optimal control and shortcuts to adiabaticity.
Both of these methods were used to show that it is possible to generate macroscopic superposition states in a Tonks--Girardeau gas on a ring with a barrier to break rotational symmetry.
From there, I introduced GPGPU and the GPUE codebase, emphasizing existing challenges in the field and the methods I used to overcome them.
In the process, I also briefly mentioned the challenging problem of memory coalescence when using spectral methods on GPU hardware and proposed an additional software package as method to further optimize the FFT operations with a distributed, multi-GPU transpose.
After this, I introduced an example physical system that showed it is possible to generate chaotic vortex dynamics in few-vortex systems and emphasized the need for vortex tracking and post-processing methods, by calculating the Lyapunov exponent on the vortex trajectories.
Finally, I introduced a three-dimensional example system that generates, controls, and detects vortex ring-like geometries in a toroidally-trapped BEC coupled to the artificial magnetic field generated by an optical nanofiber.

Throughout this work, I have attempted to highlight all future directions when relevant to the chapter.
I will continue the discussion on future research pursuits here, while also presenting new directions not yet considered in this work.

\section{Further development of GPUE}

Though the GPUE codebase is roughly feature complete, there are several directions for future development, many of which were described in Chapter~\ref{ch:gpu}.
In particular, a re-write of GPUE in Julia along with developing an $n$-dimensional, distributed, GPU transpose are currently being worked on.
The former will allow for GPUE to be more maintainable and require less development time in the future.
The latter is applicable to a wide range of spectral methods and might allow for several methods to become relevant on new HPC environment.
As both of these were discussed at length in Chapter~\ref{ch:gpu}, I will not discuss them further here; however,
there are future directions where proper development has not begun, such as new vortex tracking methods and potentially using expression trees for general-purpose Hamiltonian solutions.

\subsection{Vortex tracking in two and three dimensions}

The GPUE codebase currently has the capability of tracking vortices in two dimensions and highlighting vortices in three; however, vortex tracking has yet to be implemented in three dimensions as there are no reliable and general methods for tracking three dimensional vortex structures in some superfluid simulations performed with GPUE.
In addition, the vortex tracking method in GPUE is currently unstable for non-harmonic traps in two dimensions, and in many cases, the user does not know the precise geometry of the trapping system and thus cannot mask out the phase outside of the condensate surface.
Though it is possible to mask out areas without a vortex by multiplying the phase by the condensate density, this has not yet been implemented in GPUE.
As such, generalized vortex tracking methods for two and three-dimensional simulations is desirable.

In 2016, a method for three dimensional vortex tracking was proposed by Villois \textit{et al.}~\cite{villois2016}; however, this method has no computational complexity bound, assumes periodic boundary conditions, and required a large amount of communication between the device and host.
This method begins to search for vortex locations by creating a Boolean domain of locations to search through by locating where the density is below a threshold.
After the Boolean matrix is defined, the search is refined by locating phase plaquettes within this domain and iteratively locating a vortex skeleton.
For the case where the condensate does not extend to the edges of the simulated domain, this method needs further refinement, and
I have considered developing a similar method that leverages GPUE's vortex highlighting scheme to create three-dimensional vortex skeletons for vortex tracking in two and three dimensions.
In this case, rather than simply searching for locations where the density is low, a search would be performed in locations between peaks in the Sobel-filtered density, which correspond to likely vortex locations.
This method could be easily re-worked for two-dimensional simulations as well, creating a dynamic mask every timestep for vortex tracking, thereby eliminated the current, unstable masking procedure.

\subsection{General purpose Hamiltonian solver}

As GPUE can perform multi-component simulations and can also parse expression trees, it is possible to simulate a wide variety of physical systems beyond the GPE.
One such extension involves using the expression tree parser to solve arbitrarily provided Hamiltonians.
In this case, the user would simply provide a string with the Hamiltonian they would like solved, and an expression tree would be generated and reduced for GPU computation.
This might be an interesting application to machine learning, which has been extended to quantum many body problems~\cite{carleo2017}.
Machine learning has recently been applied to many other theoretical~\cite{carrasquilla2017} and experimental~\cite{wigley2016} problems and is a promising future direction or research~\cite{biamonte2017}.
This project would require significant software engineering time apart from GPUE-specific development, as the SSFM is not always the most optimal choice for solving certain quantum systems.
In addition, expression trees can be much more easily created and used in other software frameworks, such as Julia.
Ultimately, other general-purpose libraries already exist for general-purpose simulations of this kind, such as XMDS~\cite{dennis2013}, and if GPUE were to evolve into similar software, several lessons learned in the development of other software suites could be used.

\subsection{Octree grid}

Though the CSSFM method~\cite{bayindir2015} does not provide adequate compression for vortex-based simulations, there is still an interesting open question about whether any grid compression schemes might work with the SSFM.
One such method that has been suggested is an octree-based grid, where each grid element is determined in a finite-volume fashion based on the Sobel filter of the density.
This would allow for higher resolution in areas that have the greatest change in condensate density, which would be around the condensate edges, vortices, and perturbations, such as sound waves.
One advantage of using an octree for this purpose is that FFTs may be performed with small modifications on the grid, thereby allowing for the SSFM with dynamic grids; however, the regridding operation is still computationally intensive and even though it is entirely possible to perform an FFT on this system, such functionality is beyond the scope of CuFFT.
Therefore, significant engineering time must be devoted to either developing a CuFFT competitor for this case or for finding some method to allow CuFFT to be used in this way.
Because the primary advantage of SSFM over other methods is the speed of FFT-based operations, there is likely little reason to use this method over FEM solutions.

\subsubsection{GPUE.jl}

In Chapter~\ref{ch:gpu}, I discussed the advantages of re-writing GPUE in Julia, and in Chapters~\ref{ch:2d} and \ref{ch:vortex_states}, I discussed applications of GPUE and suggested areas where Julia could improve the software.
In these chapters, I mentioned that post-processing operations, such as vortex tracking, calculating of the Lyapunov exponent spectrum, and calculation of the scissors mode oscillation angle, require processing output data from GPUE, and though vortex tracking and highlighting is already in-built to GPUE, it is still computationally complex operation.
For this reason, it would be useful for both the timestepping method and all necessary post-processing tools to be available in the same language, and in Julia, this is possible with little, if any, performance loss.
This would also allow for modular development and maintenance of GPUE in the future, where the timestepping methods remain unchanged as users develop post-processing methods when required.

In addition to these, there are many computer science researchers who are using Julia as a testing-bed for new ideas for software engineering and certain operations, such as GPU-enabled automatic differentiation~\cite{revels2018} could be a useful tool for future quantum simulations like those presented in this work.
At the current data, the GPUE.jl package competes with GPUE (CUDA) in GPU performance; however, expression trees have not been completely implemented.
Even so, as the development of the DistributedTranspose.jl package is in Julia, future development of GPUE.jl should quickly surpass the functionality of its CUDA-based variant.

\section{Future simulations of quantum systems}

In addition to further developments of GPUE and related software packages, there are also several new simulations that can be performed now on GPU hardware, such are multicomponent simulations with gauge fields and dynamic studies of the system introduced in Chapter~\ref{ch:vortex_states}.
Because GPUE allows for the simulation of dynamic control processes through expression trees, further three-dimensional STA studies can also be performed.
Several physical applications of GPUE software have been suggested, such as dynamic turbulence studies, multicomponent heat engines, and three-dimensional vortex studies.
All of these will be discussed further in the near future.

Ultimately, this work has provided a toolbox for the simulation of various quantum phenomenon that were computationally intractable before now, including the three-dimensional simulations of superfluid turbulence without relying on vortex-filament methods, and simulations of multicomponent systems with gauge fields.
It has also developed novel methods for maximizing the size of the simulated domain with the SSFM, along with tools like the DistributedTranspose.jl that allow for spectral methods to be more widely used in HPC environments.


\chapter{Multivariate integration of vector fields}


\chapter{Tool}

This chapter covers the implementation of the \verb!ggt! tool.
The tool provides a common  interface to the different methods.
%
For now, only support for parametric assumptions is finished.

You first have to create an input file the defines the assumption.
We use the following file for the Diffie-Hellman exponent assumption.

\begin{verbatim}
setting symmetric.          (* symmetric (non-leveled) k-linear map *)
arity 2.                    (* fixes the arity k to 2 *)
problem_type decisional.

input
  [ 1
  , Y
  , forall i in [0, l - 1]: X^i
  , forall j in [l + 1, 2*l]: X^j ] @ 1.

challenge Y*X^l @ 2.\end{verbatim}
%
The tool can be used to analyze the assumption as follows.
\begin{verbatim}
$ ./ggt.native dhe.thy
[...]
The assumption is valid.\end{verbatim}


% The layout of this document has been shamelessly stolen from the MIT licensed project:
% https://github.com/davidwhogg/GaussianProductRefactor
% by David W. Hogg, Adrian Price-Whelan, and Boris Leistedt

\documentclass[10pt]{article}

\usepackage{amsmath, bm, mathrsfs, amssymb}
\usepackage[dvipsnames]{xcolor}
\usepackage[hidelinks,
            colorlinks=true,
            linkcolor=NavyBlue,
            citecolor=darkgray,
            urlcolor=NavyBlue]{hyperref}
\usepackage{pifont}
\usepackage{graphicx}
\usepackage{doi}

\usepackage{natbib}
\bibliographystyle{dfm_abbrvnat}
\setcitestyle{round,citesep={,},aysep={}}

% text stuhh
\newcommand{\documentname}{\textsl{Note}}
\newcommand{\sectionname}{Section}
\newcommand{\equationname}{equation}
\newcommand{\notename}{Note}
\renewcommand{\tablename}{Table}
\newcommand{\acronym}[1]{{\small{#1}}}
\newcommand{\code}[1]{\texttt{#1}}
\newcommand{\foreign}[1]{\textsl{#1}}
\newcommand{\etal}{\foreign{et~al.}}

% math stuhh
\newcommand{\hquad}{~~}
\newcommand{\given}{\,|\,}
\newcommand{\dd}{\mathrm{d}}
\newcommand{\T}{^{\!\mathsf{T}\!}}
\newcommand{\inv}{^{-1}}
\newcommand{\scalar}[1]{#1}
\renewcommand{\vector}[1]{\boldsymbol{#1}}
\newcommand{\tensor}[1]{\mathbf{#1}}
\renewcommand{\matrix}[1]{\mathsf{#1}}
\newcommand{\normal}{\mathcal{N}\!\,}

% variables
\newcommand{\celerite}{\code{celerite}}

% Journal keys - kill me now
\newcommand{\aj}{Astron.\,J.}
\newcommand{\apj}{Astrophys.\,J.} % Astrophysical Journal
\newcommand{\apjs}{Astrophys.\,J.\,Supp.\,Ser.} % Astrophysical Journal Supplements

% page layout stuff
\setlength{\topmargin}{0.0in}
\setlength{\headheight}{0.0in}
\setlength{\headsep}{0.0in}
\setlength{\parindent}{\baselineskip}
\setlength{\textwidth}{4.3in}
\setlength{\textheight}{2\textwidth}
\raggedbottom\sloppy\sloppypar\frenchspacing

% this might be crazy, but here's my number
\setlength{\marginparsep}{0.15in}
\setlength{\marginparwidth}{2.7in}
\usepackage{marginfix} % necessary but possibly evil
\newcounter{marginnote}
\setcounter{marginnote}{0}
\renewcommand{\footnote}[1]{\refstepcounter{marginnote}\textsuperscript{\themarginnote}\marginpar{\color{darkgray}\raggedright\footnotesize\textsuperscript{\themarginnote}#1}}
\newcommand{\tfigurerule}{\rule{0pt}{1ex}\\ \rule{\marginparwidth}{0.5pt}\\ \rule{0pt}{0.25ex}}
\newcommand{\bfigurerule}{\rule{0pt}{0.25ex}\\ \rule{\marginparwidth}{0.5pt}\\ \rule{0pt}{1ex}}
\renewcommand{\caption}[1]{\parbox{\marginparwidth}{\footnotesize\refstepcounter{figure}\textbf{\figurename~\thefigure}: {#1}}}

% and make the left margin correct
\setlength{\oddsidemargin}{0.5\paperwidth}
\addtolength{\oddsidemargin}{-1.0in}
\addtolength{\oddsidemargin}{-0.5\textwidth}
\addtolength{\oddsidemargin}{-0.5\marginparwidth}
\addtolength{\oddsidemargin}{-0.5\marginparsep}

\begin{document}

\section*{An insane version of wobble + psoap + etc.}

\noindent\textbf{Daniel Foreman-Mackey}\\
{\footnotesize%
\textsl{Center for Computational Astrophysics, Flatiron Institute, New York, NY, USA}%
}

\medskip\noindent\textbf{Megan Bedell}\\
{\footnotesize%
\textsl{Center for Computational Astrophysics, Flatiron Institute, New York, NY, USA}%
}

\medskip\noindent\textbf{et al.}\\
{\footnotesize%
\textsl{Affiliations}\\
\textsl{More affiliations}%
}

\paragraph{Abstract:}

It's wild.

\section{The basics}

\paragraph{PSOAP}

From \citet{Czekala:2017}.
The idea here was to model all the fluxes in the spectral time series as a sum of GP models where each kernel represented a different component of the system (stars, tellurics, etc.).
The model is evaluated by shifting the wavelength of each component into its rest frame and then evaluating the kernel there.
This is awesome: it's directly modeling the data (no interpolation) assuming only that the spectrum should be smooth.
But, it's also slow (can't use celerite or similar) and (probably) restricted to additive components.

\paragraph{wobble}

From \citet{Bedell:2019}.
Here, the model parameters are the flux values for each spectral component on a fine grid that is interpolated into the observed frame and optimized.
Much more flexible (can easily incorporate any number of additive and multiplicative components) and demonstrated that these high-dimensional optimizations could work.
But, the results are sensitive to grid sizes and regularization parameters, and it's not trivial to incorporate time variability in the spectral shape.

\paragraph{The new thing}

The idea here is to sort of combine these ideas into something that is both flexible and (hopefully!) tractable.
The model parameters are now (like in wobble) the flux as a function of wavelength for each component, but instead of evaluated on a grid, these will be evaluated \emph{at the locations of the observations}.
Therefore, we will have $N$ parameters for each data point (where $N$ is the number of spectral components), and the effective wavelength of each flux parameter will be a function of the RV offsets for each component at each time.
This is mildly insane, but probably possible.
Then, we will use a GP prior on the parameters to enforce a PSOAP-like smoothness constraint on each spectral component.
Then, the model is evaluated as a sum and/or product of each spectral component, and optimized using some likelihood function (possibly including things like baseline normalization, etc.) in the observed space.

This has the benefits of PSOAP: we don't need to choose a grid or regularization parameters.
But it also has the flexibility of wobble (+ some!): we can support any number of spectral components with different observational properties.
Since our flux parameters each have both a time and a rest frame wavelength associated with them, our GP prior can be a function of time and wavelength: enforcing smooth variability in both dimensions.
And, I think I know how to build this model using celerite kernels, so we can probably be fast too!

\paragraph{Open questions}

Is a GP model actually a good model for the spectral dimension?
Is there some way we could make it better?

% Render the references
\clearpage\raggedright
\bibliography{refs}

\end{document}


% Created 2019-06-09 zo 13:35
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\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}
\author{Wiebe-Marten Wijnja}
\date{\today}
\title{}
\hypersetup{
 pdfauthor={Wiebe-Marten Wijnja},
 pdftitle={},
 pdfkeywords={},
 pdfsubject={},
 pdfcreator={Emacs 26.2 (Org mode 9.2.2)},
 pdflang={English}}
\begin{document}

\tableofcontents

\section{Introduction}
\label{sec:org2246baf}

Dear Kevin Clancy, Heather Miller and Christopher Meiklejohn.

I very much enjoyed reading your whitepaper titled \textbf{Monotonicity Types}.
While reading I more and more got the suspicion that it might be possible to implement the essence of Monotonicity Types today in Haskell,
foregoing the need to build a completely separate language and compiler to annotate functions as monotonic, antitonic or neither.

This turned out to be a bit of a challenge, and I learned a lot about the dependently typed features that Haskell (provided you enable some GHC extensions) offers.
I believe the end result to be usable/practical today.

In this literate haskell document, I'll explain the implementation details.
As literate haskell, this org-mode document can be read both as \LaTeX{}-PDF as well as Haskell source code.

\section{Preamble}
\label{sec:orge93588e}
As you can see, we require quite a few extensions. Why we need them will be explained when we require them.
\begin{verbatim}
{-# LANGUAGE DataKinds  #-}
{-# LANGUAGE KindSignatures  #-}
{-# LANGUAGE TypeFamilies  #-}
{-# LANGUAGE PolyKinds  #-}
{-# LANGUAGE GADTs  #-}

\end{verbatim}

Now for the head of the module:

\begin{verbatim}
module MonotonicityTypes where

import qualified Prelude
import Prelude hiding (id, (.))
import qualified Control.Category
import qualified Control.Arrow
\end{verbatim}

\section{Building Sfuns as types that change under composition}
\label{sec:orgf41ff6d}
Let us start by defining a datatype for the different tonicity qualifiers that we want to support.

\begin{verbatim}
{-| Tonicity Qualifiers from section 4.2 of the paper.-}
data TonicityQualifier = Constant | Monotone | Antitone | Unknown | Discarded
\end{verbatim}

But rather than using these as values, we will use them at the type level, restricting the type of \textbf{Sfuns}:

\begin{verbatim}
newtype Sfun (t :: TonicityQualifier) input output = UnsafeMakeSfun { applySfun :: input -> output }
\end{verbatim}

Besides being restricted by `t`, Sfuns are normal functions.
By declaring `UnsafeMakeSfun` as 'unsafe', people are discouraged from using it (but can still do so if they really know what they are doing).
We use it to tag the primitive functions that we know are monotone as such:

\begin{verbatim}
-- A few examples:
incrementSfun :: Num a => Sfun 'Monotone a a
incrementSfun = UnsafeMakeSfun (+ 1)

negateSfun :: Num a => Sfun 'Antitone a a
negateSfun = UnsafeMakeSfun (* (-1))

\end{verbatim}

Normally, people will instead compose Sfuns together, which will result in an Sfun type that is their composition, as per figure 6 in the paper:

\begin{verbatim}
-- The composition of two Sfuns is the composition of their two functions,
-- but with the type restricted to the composition of their tonicity qualifiers.
composeSfuns :: Sfun t1 b c -> Sfun t2 a b -> Sfun (ComposeTonicity t1 t2) a c
composeSfuns (UnsafeMakeSfun f) (UnsafeMakeSfun g) = UnsafeMakeSfun (f Prelude.. g)

type family ComposeTonicity (t1 :: TonicityQualifier) (t2 :: TonicityQualifier)  :: TonicityQualifier where
  ComposeTonicity 'Monotone 'Monotone = 'Monotone
  ComposeTonicity 'Monotone 'Antitone = 'Antitone
  ComposeTonicity 'Antitone 'Antitone = 'Monotone
  ComposeTonicity 'Antitone 'Monotone = 'Antitone
  ComposeTonicity 'Constant other = other
  ComposeTonicity other 'Constant = other
  ComposeTonicity 'Discarded _ = 'Discarded
  ComposeTonicity _ 'Discarded = 'Discarded
  ComposeTonicity _ _ = 'Unknown

\end{verbatim}

Now that we have defined composition, we can compose our sfuns as follows:

\begin{verbatim}
-- result1 :: Num a => Sfun 'Monotone a a
result1 = composeSfuns incrementSfun incrementSfun

-- result2 :: Num a => Sfun 'Antitone a a
result2 = composeSfuns negateSfun incrementSfun

-- result3 :: Num a => Sfun 'Antitone a a
result3 = composeSfuns incrementSfun negateSfun

-- result4 :: Num a => Sfun 'Monotone a a
result4 = composeSfuns negateSfun negateSfun

\end{verbatim}

Those type signatures are inferred. If you were to try for instance to write

\begin{verbatim}
result4' :: Num a => Sfun 'Antitone a a
result4' = composeSfuns negateSfun negateSfun
\end{verbatim}

then GHC will complain with a nice error:

\begin{verbatim}
• Couldn't match type ‘'Monotone’ with ‘'Antitone’
  Expected type: Sfun 'Antitone a a
    Actual type: Sfun (ComposeTonicity 'Antitone 'Antitone) a a
• In the expression: composeSfuns negateSfun negateSfun
  In an equation for ‘result4’:
      result4 = composeSfuns negateSfun negateSfun
\end{verbatim}

The foundation is there. However, to make this somewhat usable, we need to make it as seamless to use Sfuns:
To the user of the library, the fact that these functions are 'special' should mostly be hidden!

It can be recognized that Sfuns are almost an instance of Arrow: The fact that the type might change under composition
is not something that the normal Arrow typeclass can cope with.

Instead, we implement an 'Indexed Category' and an 'Indexed Arrow', which explicity captures this notion of types being able to change under composition.

\begin{verbatim}
-- | Behaves to `Control.Category` but has an extra `index` kind parameter,
-- | whose type-value might change under composition.
class IndexedCategory (ic :: index -> * -> * -> *) where
  type ComposeIndexes (index1 :: index) (index2 :: index) :: index -- ^ The resulting type under composition
  id :: ic (index' :: index) a a
  (.) :: ic i1 b c -> ic i2 a b -> ic (ComposeIndexes i1 i2) a c

-- | Common composition function
infixr 1 >>>
(>>>) :: IndexedCategory ic => ic i1 a b -> ic i2 b c -> ic (ComposeIndexes i2 i1) a c
a >>> b = b . a

infixr 1 <<<
(<<<) :: IndexedCategory ic => ic i1 b c -> ic i2 a b -> ic (ComposeIndexes i1 i2) a c
(<<<) = flip (>>>)

class (IndexedCategory ic) => IndexedArrow ic where
  type DefaultIndex ic :: index
  arr :: (index ~ DefaultIndex ic) => (a -> b) -> ic index a b
  first :: ic index b c -> ic index (b, d) (c, d)

\end{verbatim}

These IndexedCategory and IndexedArrow typeclasses can be seen as a more general variant of the normal Category/Arrow,
since all normal categories/arrows can be lifted to their indexed variant by indexing them by a placeholder type like `()`.

\begin{verbatim}
-- | Wrapper to lift normal categories to 'indexed' categories.
-- | We use the singleton kind `()` as 'index'.
newtype FreeIndexed (c :: * -> * -> *) (single :: ()) a b = FreeIndexed { getCategory :: c a b }

instance Control.Category.Category c => IndexedCategory (FreeIndexed c) where
  type ComposeIndexes a b = '()
  id = FreeIndexed Control.Category.id
  (FreeIndexed a) . (FreeIndexed b) = FreeIndexed (a Control.Category.. b)

instance Control.Arrow.Arrow c => IndexedArrow (FreeIndexed c) where
  type DefaultIndex (FreeIndexed c) = '()
  arr fun = FreeIndexed (Control.Arrow.arr fun)
  first (FreeIndexed cat) = FreeIndexed (Control.Arrow.first cat)

\end{verbatim}

Time to implement the indexed category and indexed arrow instances for our Sfun datatype.

\begin{verbatim}
instance IndexedCategory Sfun where
  type ComposeIndexes i1 i2 = ComposeTonicity i1 i2
  id = UnsafeMakeSfun Prelude.id
  f . g = composeSfuns f g

instance IndexedArrow Sfun where
  type DefaultIndex Sfun = 'Unknown
  arr = UnsafeMakeSfun
  first (UnsafeMakeSfun fun) = UnsafeMakeSfun (Control.Arrow.first fun)

\end{verbatim}

Now we're able to write the earlier compositions in a much nicer way, which feels just the same as composing normal functions:

\begin{verbatim}
-- result1' :: Num a => Sfun 'Monotone a a
result1' = incrementSfun . incrementSfun
\end{verbatim}

\section{Handling multi-parameter functions}
\label{sec:org838430e}
We now can perform the composition of Sfuns. However, if we try to build an Sfun that takes more than one parameter,
Haskell will interpret this in its usual, curried, sense, seeing it as an Sfun that takes one parameter,
and returns a new (non-Sfun) function that takes the rest of the parameters.

This is not what we want, because we want the Sfun to be qualified by the tonicity qualifiers of all of its parameter types,
not only the first.
\end{document}


%!TEX root = ../OGUSAdoc.tex

In this chapter, list the exogenous inputs to the model, options, and where the values come from (weak calibration vs. strong calibration). Point to the respective chapters for some of the inputs. Mention the code \texttt{parameters.py}.

Also go through the output of the model, endogenous variables, and potential tables and pictures to produce.

\section{Exogenous Parameters}\label{SecExEnd_Exog}

  List all the exogenous parameters that are outputs of the model here.

  \begin{table}[htbp] \centering \captionsetup{width=4.7in}
    \caption{\label{TabExogVars}\textbf{List of exogenous parameters and baseline calibration values}}
      \begin{threeparttable}
      \begin{tabular}{>{\footnotesize}c |>{\footnotesize}l |>{\footnotesize}c}
        \hline\hline
        Symbol & \multicolumn{1}{c}{\footnotesize{Description}} & Value \\
        \hline
        $S$ & Maximum periods in economically active & 80 \\[-1.5mm]
        & \quad household life & \\
        $E$ & Number of periods of youth economically & $\text{round}\left(\frac{S}{4}\right)=20$ \\[-1.5mm]
        & \quad outside the model & \\
        $R$ & Retirement age (period) & $E+\text{round}\left(\frac{9}{16}S\right)=65$ \\
        $T_1$ & Number of periods to steady state for initial & 160 \\[-1.5mm]
        & \quad time path guesses & \\
        $T_2$ & Maximum number of periods to steady state & 160 \\[-1.5mm]
        & \quad for nonsteady-state equilibrium & \\
        $\nu$ & Dampening parameter for TPI & 0.4 \\
        \hline
        $\{\{\omega_{s,0}\}_{s=1}^{E+S}\}_{t=0}^{T_2+S-1}$ & Initial population distribution by age & (see Ch. \ref{Chap_Demog}) \\
        $\{f_s\}_{s=1}^{E+S}$ & Fertility rates by age & (see Sec. \ref{SecDemogFert}) \\
        $\{i_s\}_{s=1}^{E+S}$ & Immigration rates by age & (see Sec. \ref{SecDemogMort}) \\
        $\{\rho_s\}_{s=0}^{E+S}$ & Mortality rates by age & (see Sec. \ref{SecDemogImm}) \\

        % $\bm{\hat{\Gamma}}_1$ & Initial distribution of savings & $\bm{\bar{\Gamma}}$ \\

        % $\{e_{j,s}\}_{j,s=1}^{J,S}$ & Deterministic ability process & (see \citealp{DEMPRW2015}) \\
        % $\{\lambda_j\}_{j=1}^J$ & Lifetime income group percentages & $[0.25,0.25,0.20,0.10,0.10,0.09,0.01]$ \\
        % $J$ & Number of lifetime income groups & 7 \\

        % \hline
        % $\tilde{l}$ & Maximum hours of labor supply & 1 \\
        % $\beta$ & Discount factor & $(0.96)^\frac{80}{S}$ \\
        % $\sigma$ & Coefficient of constant relative risk aversion & 1.5 \\
        % $b$ & Scale parameter in utility of leisure & 0.573 \\
        % $\upsilon$ & Shape parameter in utility of leisure & 2.856 \\
        % $\chi^n_s$ & Disutility of labor level parameters & [19.041, 76.623] \\
        % $\chi^b_j$ & Utility of bequests level parameters &  $[9.264 \times 10^{-5}, 118,648]$ \\ %$1.0 \ \forall j$ \\
        % \hline
        % $Z$ & Level parameter in production function & 1.0 \\
        % $\alpha$ & Capital share of income & 0.35 \\
        % $\delta$ & Capital depreciation rate & $1-(1-0.05)^\frac{80}{S}=0.05$ \\
        % $g_y$ & Growth rate of labor augmenting & $(1+0.03)^\frac{80}{S}-1 = 0.03$ \\[-2mm]
        % & \quad technological progress & \\
        % \hline

        \hline\hline
      \end{tabular}
      \end{threeparttable}
    \end{table}

\section{Endogenous Variables}\label{SecExEnd_Endog}

  List all the endogenous variables that are outputs of the model here.


\chapter{Darwinian Network Library}
\label{sec:dn_lib}

\section{Structure}
\label{sec:system:sec1}

The DN library is a simple extension of Darwin, also intended for teaching and prototyping purposes.
Basically, the library inherits the potential manipulation tools from Darwin, ignoring the graphical manipulation ones.
From there, DN library builds the analysis of set of potentials, which forms a DN by definition.
The structure of the library is mainly formed by two classes: \emph{Population} and \emph{DarwinianNetwork}.

The Population class inherits directly from Potential's class in Darwin.
But here, few keywords are override in order to adapt the language for DNs.
For instance, the left and right hand side of the arguments in a Potential are called combative and docile in a Population.
Moreover, a Population have the methods merge and replicate which internally calls multiply (or divide) and marginalize from Potential.
Deciding where it is a division or multiplication is handled internally by the merge method.

DarwinianNetworks is defined with a set of Populations.
This data structure basically offers common methods for set manipulations, for instance, inserting and removing Populations.
Here, the set of populations are stored in an array, in order to allow the multiset populations as defined in DNs.

\section{Features}
\label{sec:system:sec2}

Few features are present in DN library in order to guarantee a smooth use for teaching and prototyping.
Now, we highlight there features of the library: keyword usage, initialization of parameters and drawing of data structure.

When instantiating a Population, the user can use keywords for the combative and docile arguments.
In this way, the user does not need to remember the ordering of the arguments, but only their names.
For example, defining a population $p(a,b)$ can be defined with the below code by using keywords ``combative'' and ``docile'':
\begin{verbatim}
    Population(combative=["a"],docile=["b"])
\end{verbatim}

Also for simplifying usage, the library has standard initialization of internal parameters.
That is, if the user does not pass all the required arguments, the DN library initialize them correctly when possible with standard values.
For example, in the above code the cardinalities of variables ``a'' and ``b'' are set to 2 and the 4 probabilities values are randomly generated between 0 and 1.

Finally, the DN library has a set of procedures for drawing Populations and DarwinianNetworks whenever the user calls them.
Those tools are built using the \emph{matplotlib} \cite{Hunter:2007} library for Python and is the only requirement for the drawings.
If the user wants to see how a population looks like, the user can define the Population and then calls the \emph{draw\_population} function as illustrate below:
\begin{verbatim}
    p = Population(combative=["d"],docile=["f", "b"])
    draw_population(p)
\end{verbatim}
These commands will create a drawing of a population as illustrated in Figure \ref{fig:drawing_pop}.

\begin{figure}[hbt]
    \begin{center}
        \includegraphics[width=0.6\textwidth]{img/drawing_population.png}
    \end{center}
    \caption{Drawing of population $p(d,fb)$ created by the DN library.}
    \label{fig:drawing_pop}
\end{figure}

The same idea works for a whole DN.
After defining a DarwinianNetwork, the user can call \emph{draw\_dn} passing the DN object.
Figure \ref{fig:drawing_dn} shows one example of the drawing of a DN as generated by the DN library.

\begin{figure}[hbt]
    \begin{center}
        \includegraphics[width=0.6\textwidth]{img/drawing_dn.png}
    \end{center}
    \caption{Drawing of the DN $\{p(h,d), p(l,f), p(f), p(b), p(d,fb)\}$ created by the DN library.}
    \label{fig:drawing_dn}
\end{figure}

\section{Usage}
\label{sec:system:sec3}

The use of the two main classes in DN library is introduced now.
The Population class is defined exactly like a Potential, since it inherits from that class.
But the left and right hand side argument names are replaced by combative and docile, respectively.
Two methods are also exposed for quick references: combative and docile, which returns the respective informations for that Population.
A helper method called \emph{from\_potential} is also available in order to convert a Potential object to a Population one.
Moreover, merge receives another Population as argument, while replicate receives a list of variables which will be marginalized from the Population.

The DarwinianNetwork class has a list member where all the Populations are hold.
The methods \emph{add\_population} and \emph{delete\_population} are used for adding and deleting Population, respectively, from the list of Populations
This class has no constructor and the list of Populations is used to simulate the multi-set definition of DNs.