%%%%%%%%%%%%%
% TODO
%%%%%%%
\begin{center}
	{\bf \Large ConFrm: Confidentiality Framework for Crash-Safe Storage Systems}
\end{center}

\vspace{0.3in}
\section{Introduction}
As computation and storage shift toward the cloud, the safety of computation and data is becoming increasingly important. Users expect their data stored in such systems to stay secret against malicious third parties. Precise descriptions of how such a system should behave to ensure confidentiality of the stored data are called confidentiality specifications. A confidentiality specification of a system both forces a system to maintain certain properties, and informs users about the safety guarantees that system provides.

Writing a confidentiality specification is generally more difficult than writing a correctness specification. To demonstrate the possible hardships of writing a specification that can prevent malicious implementations, we can look at a specification for the create() operation from our confidential file system ConFs. create() takes an owner and creates an empty file owned by the provided owner. Upon successful completion, it returns the inode number that identifies the file. A natural correctness specification for its return value could be “create() returns the index of the previously unused inode that now corresponds to the newly created file.” If we were only interested in functional correctness, this would be an acceptable specification. However, there is a substantial confidentiality problem associated with it. create() is allowed to return any inode number as long as it was unused at the time of the call. A malicious implementation of the file system can take advantage of this nondeterminism in the specification to pick the returned inode number and subsequently leak confidential data, e.g., last byte of the return value being equal to the first byte of a block that belongs to another user.

This problem, and others of the same nature, could be solved by writing a fully deterministic specification for create() that exactly pinpoints what it should return and what the file-system state should be after its completion. However, such a specification runs the risk to be overly verbose to a degree that specification is the implementation, obscuring the important parts of the specification, making it difficult to read and comprehend, and defeating one of the key purposes of writing a specification. Therefore, a good confidentiality specification should address such vulnerabilities in its scope, but should also abstract implementation details so it can be read, understood, and reviewed by humans. Finding the right balance between these conflicting requirements is what makes writing a confidentiality specification challenging.

Our proposed solution to the above problems is ConFrm, a framework for
implementing and proving the confidentiality of storage systems in a modular fashion. ConFrm provides a noninterference definition with better guarantees for nondeterministic behavior, as well as the required tools and necessary conditions for safety-preserving abstractions. These two components of ConFrm enable us to overcome the limitations of previous works and provide a simple yet powerful tool for implementing safe storage systems out of composable components..

To test the capabilities of ConFrm, we implemented ConFS, a confidential file system that is crash-resistant via checksum logging, transactional operations, and coarse-grained discretionary access control.

Both ConFrm and ConFS are implemented in Coq. All proofs are fully machine-checked to ensure their correctness.


\input{../../_common/preamble}

\title{Generalised linear models}

\begin{document}

\maketitle

\begin{frame}{Contents}
    \tableofcontents[hideallsubsections]
\end{frame}

\section{Regression models}

\begin{frame}{Regression models}
    Regression models explore associations between:
    \begin{itemize}
        \item A \alert{response} variable $\vec{y}$
        \item \alert{Explanatory} variables (or \alert{predictors})
              $\vec{x_{1}}, \ldots, \vec{x_{p}}$
    \end{itemize}
    \vfill\pause
    \begin{block}{Question}
        Do the $\vec{x_{1}}, \ldots, \vec{x_{p}}$ capture the
        \alert{variability} of $\vec{y}$?
    \end{block}
\end{frame}

\begin{frame}{Regression modelling steps}
    \begin{itemize}
        \item \alert{Formulation}
              \begin{enumerate}
                  \item Error distribution for the response $\vec{y}$
                  \item Combination of predictors
                  \item Link function \\[\bigskipamount]
              \end{enumerate}
        \item \alert{Estimation} of regression coefficients \\[\bigskipamount]
        \item \alert{Diagnostics} (does the model fit the data well?) \\[\bigskipamount]
        \item \alert{Selection} (can we improve the fit?)
    \end{itemize}
\end{frame}

\begin{frame}{Components of regression models}
    \begin{enumerate}[(1)]
        \item A model for the \alert{variability} of the response $\vec{y}$
              \begin{itemize}
                  \item $\vec{y}$ is continuous $\rightarrow$ normal distribution
                  \item $\vec{y}$ is dichotomous $\rightarrow$ binomial distribution \\[\bigskipamount]
              \end{itemize}
        \pause
        \item A \alert{combination of predictors} $\vec{x_{1}}, \ldots, \vec{x_{p}}$
              \begin{itemize}
                  \item Often linear, e.g.\ $2 \vec{x_{1}} + 3 \vec{x_{2}}$
                  \item $\beta_{1} = 2$ and $\beta_{2} = 3$ are
                        \alert{regression coefficients} \\[\bigskipamount]
              \end{itemize}
        \pause
        \item A \alert{link} between the two
              \begin{itemize}
                  \item Often depends on the model for the response
                  \item Linear regression:
                        $\E{\vec{y}} = 2 \vec{x_{1}} + 3 \vec{x_{2}}$
              \end{itemize}
    \end{enumerate}
\end{frame}

\begin{frame}{Predictors and response}
    \begin{block}{Predictors}
        \begin{itemize}
            \item Viewed as \alert{fixed} variables
            \item Assumed not to be affected by \alert{measurement error}
            \item[$\rightarrow$] `Independent' or `exogenous'
        \end{itemize}
    \end{block}
    \vfill
    \begin{block}{Response}
        \begin{itemize}
            \item \alert{Variability is modelled} \\
                  (but could also be attributed to other factors)
            \item[$\rightarrow$] `Dependent' or `endogenous'
        \end{itemize}
    \end{block}
\end{frame}

\section{Linear regression}

\begin{frame}{Simple linear regression}
    \begin{columns}[c]
        \begin{column}{0.5\textwidth}
            \centering
            \includegraphics[width=\textwidth]{figures/lm}
        \end{column}
        \begin{column}{0.5\textwidth}
            {\small%
             For the $i^{\,\text{th}}$ observation:}
            \vspace{-1ex}
            \begin{center}
                $y_{i} = \beta_{0} + \beta_{1}\,x_{i} + \epsilon_{i}$ \\[\bigskipamount]
                \begin{tabular}{ll}
                    \toprule
                    $\beta_{0}$    & Intercept \\
                    $\beta_{1}$    & Slope \\
                    $\epsilon_{i}$ & Individual error term \\
                    \bottomrule
                \end{tabular}
            \end{center}
        \end{column}
    \end{columns}
\end{frame}

\begin{frame}[t]{Regression coefficients}
    \[
        y_{i} = \alert{\beta_{0}} + \alert{\beta_{1}}\,x_{i} + \epsilon_{i}
    \]
    \vfill
    \begin{description}
        \item[\textbf{Intercept}] Average $y$ when $x = 0$
        \item[\textbf{Slope}] Increase in $y$ for a one\hyp{}unit increase in $x$
    \end{description}
    \vfill
    The regression line passes through:\vspace{-1ex}
    \begin{itemize}
        \item The point $(0, \beta_{0})$
        \item The `centre' of the data $(\bar{\vec{x}}, \bar{\vec{y}})$
    \end{itemize}
\end{frame}

\begin{frame}[t]{Error term}
    \[
        y_{i} = \beta_{0} + \beta_{1}\,x_{i} + \alert{\epsilon_{i}}
    \]
    \vfill
    \begin{itemize}
        \item `Sucks up' unaccounted variation in $\vec{y}$
        \item Model assumptions are mostly on $\epsilon$
    \end{itemize}
\end{frame}

\begin{frame}[t]{Multiple linear regression}
    \only<1>{%
        {\small%
         For the $i^{\,\text{th}}$ observation:}
        \vspace{-1ex}
        \begin{center}
            $y_{i} = \beta_{0} + \sum_{j} \beta_{j}\,x_{ij} + \epsilon_{i}$ \\[\bigskipamount]
            \begin{tabular}{ll}
                \toprule
                $\beta_{0}$    & Intercept \\
                $\beta_{j}$    & Slopes \\
                $\epsilon_{i}$ & Individual error term \\
                \bottomrule
            \end{tabular}
        \end{center}
        \vfill
        \begin{description}
            \item[\textbf{Intercept}] Average $y$ when all $x_{\,\cdot\,j} = 0$
            \item[\textbf{Slopes}] Increase in $y$ for a one\hyp{}unit increase
                                   in $x_{\,\cdot\,j}$ \\
                                   \alert{all else being equal}
        \end{description}}
    \only<2>{%
        {\small
         In matrix form:}
        \vspace{-1ex}
        \begin{center}
            $\vec{y} = \mat{X} \vec{\beta} + \vec{\epsilon}$ \\[\bigskipamount]
            \begin{tabular}{ll}
                \toprule
                $\mat{X}$        & Design matrix\\
                $\vec{\beta}$    & Regression coefficients \\
                $\vec{\epsilon}$ & Error term \\
                \bottomrule
            \end{tabular}
        \end{center}}
\end{frame}

\begin{frame}{Gauss--Markov assumptions (plus one)}
    \begin{itemize}
        \item The relationship between $\vec{y}$ and $\mat{X}$ is linear
        \item The $\vec{x_{1}}, \ldots, \vec{x_{p}}$ are not collinear
        \item Exogeneity
              \begin{itemize}
                  \item Given $\mat{X}$, errors have mean 0
                  \item Since $\mat{X}_{i}$ is deterministic, it is uncorrelated
                        with $\epsilon_{i}$
              \end{itemize}
        \item Spherical errors
              \begin{itemize}
                  \item Errors have a fixed variance (homoscedasticity)
                  \item Errors are uncorrelated between observations
                        (no autocorrelation)
              \end{itemize}
        \item (Given $\mat{X}$, errors are normally distributed)
    \end{itemize}
\end{frame}

\begin{frame}[t]{Model fitting by maximum likelihood}
    \begin{center}
        $Y_{i} \sim \Normal{\mu_{i}}{\sigma^{2}}$
        \quad
        where
        \quad
        $\mu_{i} = \beta_{0} + \sum_{j} \beta_{j}\,x_{ij}$
    \end{center}
    \vfill
    \only<1>{%
        \begin{description}
            \item[$\beta_{j}$] `True' values (\alert{fixed but unknown})
            \item[$\hat{\beta}_{j}$] Our estimates for the $\beta_{j}$
                                     (\alert{computed from the data})
        \end{description}
        \vfill
        Given some values for the $\hat{\beta}_{j}$\ldots\vspace{-1ex}
        \begin{itemize}
            \item We can write down the probability of observing each $Y_{i}$
                  alone
            \item Since the $Y_{i}$ are independent by assumption, we can write
                  down the \alert{joint} probability of observing the $Y_{i}$
                  together
            \item[$\rightarrow$] $f\,( \vec{y}\,|\,\hat{\beta}_{j} )$ is the
                                 probability of the data
                                 \alert{given the parameters}
        \end{itemize}}
    \only<2>{%
        \begin{block}{Maximum likelihood principle}
            \begin{itemize}
                \item Consider instead the \alert{likelihood function}
                      $f\,( \hat{\beta}_{j}\,|\,\vec{y} )$
                \item Same as $f\,( \vec{y}\,|\,\hat{\beta}_{j} )$, but
                      interpreted as the probability of certain parameter values
                      \alert{given the data}
                \item[$\rightarrow$] Can optimise to estimate the $\hat{\beta}_{j}$
            \end{itemize}
        \end{block}}
\end{frame}

\begin{frame}{Hypothesis testing for parameters}
    How do we know the \alert{estimates} $\hat{\beta}_{j}$ are not just random
    fluctuations?
    \vfill\pause
    \begin{center}
        Additional assumption: $\epsilon_{i} \simiid \Normal{0}{\sigma^{2}}$ \\[\bigskipamount]
        $\downarrow$ \\[\bigskipamount]
    \end{center}
    \begin{itemize}
        \item Define confidence intervals for $\hat{\beta}_{j}$
        \item Test $H_{0}$ that $\hat{\beta}_{j} = 0$ (no effect)
    \end{itemize}
\end{frame}

\begin{frame}{Diagnostics for linear regression}
    \begin{center}
        \begin{tabular}{llp{0.5\textwidth}}
            \toprule
            \textbf{Assumption violated} & \textbf{Severity} & \textbf{Causes} \\
            \midrule
            Linearity or additivity & ++++ & Model misspecification \\[\medskipamount]
            Independence            & +++  & Autocorrelation \newline (typical of time series) \\[\medskipamount]
            Homoscedasticity        & ++   & $\sigma^{2}$ changes over the range of $\vec{y}$ \\[\medskipamount]
            Normality               & +    & Outliers \\
            \bottomrule
        \end{tabular}
    \end{center}
\end{frame}

\begin{frame}{Many datasets, one regression line}
    \begin{center}
        \includegraphics[height=0.8\textheight]{figures/anscombe}
    \end{center}
\end{frame}

\section{Logistic regression}

\begin{frame}{Classification problems}
    \begin{center}
        What happens if the outcome $\vec{y}$ is dichotomous?
    \end{center}
    \vfill\pause
    We can model the \alert{probability}
    \[
        \Prob{y_{i} = 1 \,\left|\,\vec{x}_{i} \right.\!} = p_{i}\text{,}
    \]
    i.e.\ the probability of belonging to some non\hyp{reference} category, as a
    function of the predictors $\vec{x_{1}}, \ldots, \vec{x_{p}}$
    \vfill
    \begin{flushright}
        \ldots but how?
    \end{flushright}
\end{frame}

\begin{frame}{Logistic regression}
    \begin{block}{Idea}
        Transform the linear predictor to lie on the unit interval \\[\bigskipamount]
        {\small%
         For the $i^{\,\text{th}}$ observation:}
        \[
            \logit\!\left( p_{i} \right)
            = \log\!\left( \frac{p_{i}}{1 - p_{i}} \right)
            = \beta_{0} + \sum_{j} \beta_{j} x_{ij} + \epsilon
        \]
        $\beta_{0}, \ldots, \beta_{p}$ represent the
        \alert{log odds ratios} between classes
    \end{block}
\end{frame}

\begin{frame}{Probability and odds}
    \begin{columns}[c]
        \begin{column}{0.5\textwidth}
            \centering
            \[
                \logit\!\left( p \right) = \log\!\left( \frac{p}{1 - p} \right)
            \]
            \includegraphics[width=0.8\textwidth]{figures/logit}
        \end{column}
        \begin{column}{0.5\textwidth}
            Throw a fair die. \\
            How often will you get a $1$?
            \begin{block}{Probability}
                \[
                    p = \frac{1}{6} \approx 16.67\% \text{ of the time}
                \]
            \end{block}
            \vspace{-0.5em}
            \begin{block}{Odds}
                \[
                    \frac{p}{1 - p} = \frac{1/6}{5/6} = \frac{1}{5} = 0.2
                \]
                {\footnotesize%
                 (once for every $5$ times you don't)}
            \end{block}
        \end{column}
    \end{columns}
\end{frame}

\begin{frame}[t]{Odds ratio}
    \only<1>{%
        \[
            \text{OR} = \frac{\text{odds in some group ($y = 1$)}}
                             {\text{odds in a reference group ($y = 0$)}}
        \]}
    \only<2>{%
        \begin{block}{Example}
            \[
                \text{OR} = \frac{\text{odds of smoking in lung cancer patients}}
                                 {\text{odds of smoking in cancer\hyp{}free individuals}}
            \]
        \end{block}
        \vfill
        \begin{block}{Interpretation}
            \[
                \text{OR}
                \begin{cases}
                    < 1 & \text{smoking is \alert{less likely}} \\
                    = 1 & \text{smoking is \alert{no more likely} in lung cancer patients} \\
                    > 1 & \text{smoking is \alert{more likely}}
                \end{cases}
            \]
        \end{block}}
\end{frame}

\begin{frame}{Logistic regression recap}
    \begin{block}{Model}
        \begin{itemize}
            \item Outcome is the \alert{probability} of being in some
                  non\hyp{}reference class
            \item Regression coefficients represent \alert{log odds ratios}
        \end{itemize}
    \end{block}
    \vfill
    \begin{block}{Interpretation of coefficients}
        \begin{itemize}
            \item $\exp\!\left( \beta \right)$ is the \alert{odds ratio} between
                  $y = 0$ and $y = 1$
            \item $\text{OR} = 1$ is the threshold corresponding to no effect
        \end{itemize}
    \end{block}
\end{frame}

\end{document}


\par
\section{Driver programs for the {\tt Graph} object}
\label{section:Graph:drivers}
\par
This section contains brief descriptions of six driver programs.
\par
%=======================================================================
\begin{enumerate}
%-----------------------------------------------------------------------
\item
\begin{verbatim}
checkComponents msglvl msgFile inGraphFile
\end{verbatim}
This driver program reads in a {\tt Graph} object from a file,
and prints out information about the number of vertices and weights
of the vertices in the components.
\begin{itemize}
\item
The {\tt msglvl} parameter determines the amount of output ---
taking {\tt msglvl >= 3} means that all objects are written
to the message file.
\item
The {\tt msgFile} parameter determines the message file --- if {\tt
msgFile} is {\tt stdout}, then the message file is {\it stdout},
otherwise a file is opened with {\it append} status to receive any
output data.
\item
The {\tt inGraphFile} parameter is the input file for the {\tt Graph}
object. It must be of the form {\tt *.graphf} or {\tt *.graphb}.
The {\tt Graph} object is read from the file via the
{\tt Graph\_readFromFile()} method.
\end{itemize}
%-----------------------------------------------------------------------
\item
\begin{verbatim}
compressGraph msglvl msgFile inGraphFile coarseType outMapFile outGraphFile
\end{verbatim}
This driver program reads in a {\tt Graph} object from a file,
computes the equivalence map to its natural compressed graph
(the first graph need not be unit weight), and constructs the
natural compressed graph.
The equivalence map and compressed graph are optionally written out
to files.
\begin{itemize}
\item
The {\tt msglvl} parameter determines the amount of output ---
taking {\tt msglvl >= 3} means that all objects are written
to the message file.
\item
The {\tt msgFile} parameter determines the message file --- if {\tt
msgFile} is {\tt stdout}, then the message file is {\it stdout},
otherwise a file is opened with {\it append} status to receive any
output data.
\item
The {\tt inGraphFile} parameter is the input file for the {\tt Graph}
object. It must be of the form {\tt *.graphf} or {\tt *.graphb}.
The {\tt Graph} object is read from the file via the
{\tt Graph\_readFromFile()} method.
\item
The {\tt coarseType} parameter defines the type of compressed
graph; valid values are in {\tt [0,3]}.
\item
The {\tt outMapFile} parameter is the output file for the {\tt IV}
object that holds the equivalence map.
If {\tt outMapFile} is {\tt none} then the {\tt IV} object is not
written to a file.
Otherwise, the {\tt IV\_writeToFile()} method is called to write
the {\tt IV} object to
a formatted file (if {\tt outMapFile} is of the form {\tt *.ivf}),
or
a binary file (if {\tt outMapFile} is of the form {\tt *.ivb}).
\item
The {\tt outGraphFile} parameter is the output file for the
compressed {\tt Graph} object.
If {\tt outGraphFile} is {\tt none} then the {\tt Graph} object is not
written to a file.
Otherwise, the {\tt Graph\_writeToFile()} method is called to write
the graph to
a formatted file (if {\tt outGraphFile} is of the form {\tt *.graphf}),
or
a binary file (if {\tt outGraphFile} is of the form {\tt *.graphb}).
\end{itemize}
%-----------------------------------------------------------------------
\item
\begin{verbatim}
expandGraph msglvl msgFile inGraphFile inMapFile outGraphFile
\end{verbatim}
This driver program reads in a {\tt Graph} object and a map {\tt
IV} object from two files.
It then creates a new {\tt Graph} object which is the original
graph ``expanded'' by the map, and optionally writes this object
to a file.
The program {\tt expandGraph} is the inverse of {\tt compressGraph}.
\begin{itemize}
\item
The {\tt msglvl} parameter determines the amount of output ---
taking {\tt msglvl >= 3} means that all objects are written
to the message file.
\item
The {\tt msgFile} parameter determines the message file --- if {\tt
msgFile} is {\tt stdout}, then the message file is {\it stdout},
otherwise a file is opened with {\it append} status to receive any
output data.
\item
The {\tt inGraphFile} parameter is the input file for the {\tt Graph}
object. It must be of the form {\tt *.graphf} or {\tt *.graphb}.
The {\tt Graph} object is read from the file via the
{\tt Graph\_readFromFile()} method.
\item
The {\tt inMapFile} parameter is the input file for the {\tt IV}
object that holds the expansion map.
The {\tt IV\_readFromFile()} method is called to read
the map from
a formatted file (if {\tt inMapFile} is of the form {\tt *.ivf}),
or
a binary file (if {\tt inMapFile} is of the form {\tt *.ivb}).
\item
The {\tt outGraphFile} parameter is the output file for the
compressed {\tt Graph} object.
If {\tt outGraphFile} is {\tt none} then the {\tt Graph} object is not
written to a file.
Otherwise, the {\tt Graph\_writeToFile()} method is called to write
the graph to
a formatted file (if {\tt outGraphFile} is of the form {\tt *.graphf}),
or
a binary file (if {\tt outGraphFile} is of the form {\tt *.graphb}).
\end{itemize}
%-----------------------------------------------------------------------
\item
\begin{verbatim}
mkGridGraph msglvl msgFile stencil n1 n2 n3 outFile
\end{verbatim}
This driver program creates a Graph object for a finite difference
operator on a ${\tt n1} \times {\tt n2} \times {\tt n3}$ regular grid.
\begin{itemize}
\item
The {\tt msglvl} parameter determines the amount of output ---
taking {\tt msglvl >= 3} means that all objects are written
to the message file.
\item
The {\tt msgFile} parameter determines the message file --- if {\tt
msgFile} is {\tt stdout}, then the message file is {\it stdout},
otherwise a file is opened with {\it append} status to receive any
output data.
\item
Valid {\tt stencil} values are
{\tt 5} for a 2-D 5-point operator,
{\tt 7} for a 3-D 7-point operator,
{\tt 9} for a 2-D 9-point operator,
{\tt 13} for a 2-D 13-point operator
and
{\tt 27} for a 3-D 27-point operator.
\item
{\tt n1} is the number of points in the first direction.
\item
{\tt n2} is the number of points in the second direction.
\item
{\tt n3} is the number of points in the third direction,
ignored for {\tt stencil} = {\tt 5}, {\tt 9} and {\tt 13}.
\item
The {\tt Graph} object is written to file {\tt outFile}.
It must be of the form {\tt *.graphf} or {\tt *.graphb}.
The {\tt Graph} object is written to the file via the
{\tt Graph\_writeToFile()} method.
\end{itemize}
%-----------------------------------------------------------------------
\item
\begin{verbatim}
testIO msglvl msgFile inFile outFile
\end{verbatim}
This driver program reads in a {\tt Graph} object from {\tt inFile}
and writes out the object to {\tt outFile}
\par
\begin{itemize}
\item
The {\tt msglvl} parameter determines the amount of output ---
taking {\tt msglvl >= 3} means the {\tt Graph} object is written
to the message file.
\item
The {\tt msgFile} parameter determines the message file --- if {\tt
msgFile} is {\tt stdout}, then the message file is {\it stdout},
otherwise a file is opened with {\it append} status to receive any
output data.
\item
The {\tt inFile} parameter is the input file for the {\tt Graph}
object. It must be of the form {\tt *.graphf} or {\tt *.graphb}.
The {\tt Graph} object is read from the file via the
{\tt Graph\_readFromFile()} method.
\item
The {\tt outFile} parameter is the output file for the {\tt Graph}
object. It must be of the form {\tt *.graphf} or {\tt *.graphb}.
The {\tt Graph} object is written to the file via the
{\tt Graph\_writeToFile()} method.
\end{itemize}
%-----------------------------------------------------------------------
\item
\begin{verbatim}
testIsSymmetric msglvl msgFile inFile
\end{verbatim}
This driver program reads in a {\tt Graph} object and tests whether
it is symmetric using the {\tt Graph\_isSymmetric()} method.
This was useful in one application where the {\tt Graph} object was
constructed improperly.
\par
\begin{itemize}
\item
The {\tt msglvl} parameter determines the amount of output ---
taking {\tt msglvl >= 3} means the {\tt Graph} object is written
to the message file.
\item
The {\tt msgFile} parameter determines the message file --- if {\tt
msgFile} is {\tt stdout}, then the message file is {\it stdout},
otherwise a file is opened with {\it append} status to receive any
output data.
\item
The {\tt inFile} parameter is the input file for the {\tt Graph}
object. It must be of the form {\tt *.graphf} or {\tt *.graphb}.
The {\tt Graph} object is read from the file via the
{\tt Graph\_readFromFile()} method.
\end{itemize}
%-----------------------------------------------------------------------
\item
\begin{verbatim}
testWirebasket msglvl msgFile inGraphFile inStagesFile
               outStagesFile radius
\end{verbatim}
This driver program reads in a {\tt Graph} object and
and a file that contains the stages ids of the vertices,
(stage equal to zero means the vertex is in the Schur complement),
and overwrites the stages vector to specify the stage that the
vertex lies for a wirebasket domain decomposition of the graph.
For a Schur complement vertex, its stage is precisely the number of
domains that lie within {\tt radius} edges of it.
The new stages vector is written to the {\tt outStagesFile} file.
\par
\begin{itemize}
\item
The {\tt msglvl} parameter determines the amount of output ---
taking {\tt msglvl >= 3} means the {\tt Graph} object is written
to the message file.
\item
The {\tt msgFile} parameter determines the message file --- if {\tt
msgFile} is {\tt stdout}, then the message file is {\it stdout},
otherwise a file is opened with {\it append} status to receive any
output data.
\item
The {\tt inGraphFile} parameter is the input file for the {\tt Graph}
object. It must be of the form {\tt *.graphf} or {\tt *.graphb}.
The {\tt Graph} object is read from the file via the
{\tt Graph\_readFromFile()} method.
\item
The {\tt inStagesFile} parameter is the input file for the {\tt IV}
object that holds the component ids.
It must be of the form {\tt *.ivf} or {\tt *.ivb}.
The {\tt IV} object is read from the file via the
{\tt IV\_readFromFile()} method.
\item
The {\tt outStagesFile} parameter is the output file for the
stages {\tt IV} object.
It must be of the form {\tt *.ivf} or {\tt *.ivb}.
The {\tt IV} object is written to the file via the
{\tt IV\_writeToFile()} method.
\item
The {\tt radius} parameter is used to define the stage of a Schur
complement vertex, namely the stage is the number of domains that
are found within {\tt radius} edges of the vertex.
\end{itemize}
The two plots below illustrate the wirebasket stages for a $15
\times 15$ grid.
They show the stages for {\tt radius = 1} on the
left and {\tt radius = 2} on the right.
The domains are $3 \times 3$ subgrids whose vertices have labels
equal to zero.
\begin{center}
\makebox{
% \psfig{file=rad1.eps,width=2.7in,height=2.70in}
\psfig{file=../../Graph/doc/rad1.eps,width=2.7in,height=2.70in}
% \psfig{file=rad2.eps,width=2.7in,height=2.70in}
\psfig{file=../../Graph/doc/rad2.eps,width=2.7in,height=2.70in}
}
\end{center}
%-----------------------------------------------------------------------
\item
\begin{verbatim}
writeMetisFile msglvl msgFile inGraphFile outMetisFile
\end{verbatim}
This driver program reads in an {\tt Graph} object and write it out
to a file in the format required by the {\bf METIS} software
package.
\begin{itemize}
\item
The {\tt msglvl} parameter determines the amount of output ---
taking {\tt msglvl >= 3} means that all objects are written
to the message file.
\item
The {\tt msgFile} parameter determines the message file --- if {\tt
msgFile} is {\tt stdout}, then the message file is {\it stdout},
otherwise a file is opened with {\it append} status to receive any
output data.
\item
The {\tt inGraphFile} parameter is the input file for the {\tt Graph}
object. It must be of the form {\tt *.graphf} or {\tt *.graphb}.
The {\tt Graph} object is read from the file via the
{\tt Graph\_readFromFile()} method.
\item
The {\tt outMetisFile} parameter is the outfile file for the {\bf
METIS} graph object.
\end{itemize}
%-----------------------------------------------------------------------
\end{enumerate}


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

\usepackage{qtree}

\usepackage{setspace}
\usepackage{float}

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

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

\title{People who want to parse bigrams and finite state machines\\good}
\author{Meaghan ``geitje'' Fowlie and Floris ``konijntje'' van Vugt}

\begin{document}

\maketitle

\section{Definitions}

%\newcommand\STATES{\mathcal{S}}
\newcommand\STATES{\ensuremath{\mathbb{S}}}
%\newcommand\OPS{\mathcal{O}}
\newcommand\OPS{\ensuremath{\mathbb{O}}}
%\newcommand\BIGR{\mathcal{B}}
\newcommand\BIGR{\ensuremath{\mathbb{B}}}
\newcommand\FSA{\textsc{FSA}}
%\newcommand\PARSES{\mathcal{P}}
\newcommand\PARSES{\ensuremath{\mathbb{P}}}
\newcommand\SC{\text{\textsc{sc}}}
\newcommand\TC{\text{\textsc{tc}}}
\newcommand\UC{\text{\textsc{uc}}}
\newcommand\BC{\text{\textsc{bc}}}
\newcommand\N{\ensuremath{\mathbb{N}}}
\newcommand\sg{\ensuremath{\Sigma}}
\newcommand\la{\ensuremath{\langle}}
\newcommand\ra{\ensuremath{\rangle}}
\newcommand\arr{\ensuremath{\rightarrow}}
\newcommand\emp{\ensuremath{\epsilon}}
\newcommand\op{\text{\textsl{op}}}
\newcommand\mg{\text{\textsl{mg}}}
\newcommand\cp{\text{\textsl{copy}}}
\newcommand\cl{\text{\textsl{clear}}}
\newcommand\ed{\text{\textsl{end}}}
\newcommand\expr{\text{\textsl{expr}}}
\newcommand\Lex{\text{\textsl{Lex}}}
\newcommand\fea[1]{\text{\texttt{#1}}}
\newcommand\LBOUND{\ensuremath{\rtimes}}
\newcommand\RBOUND{\ensuremath{\ltimes}}
\newcommand\OURG{\text{\textsc{cath}}}

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

\newcommand\der{\leftarrow}
%\newcommand\der{\text{:-}}

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

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

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

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

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

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

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

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

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

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

\begin{definition}[Transition Probabilities]

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

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

\end{definition}

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

\sg~ is a finite alphabet of symbols,

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

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

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

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

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

\end{definition}

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

\end{definition}

  I think we need a homomorphism of the sort in Koller's paper to define the relationship between the operations and the surface strings?

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

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

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

\end{definition}

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

\begin{definition}[expression]
  An expression is anything that can participate in an operation. For \OURG:

  \expr = $(\LBOUND\sg^*\times\sg^*) \cup \sg^*$

\end{definition}

\begin{definition}[Operation]
\label{def:ops}
  Operations are functions from expressions to expressions.

  We have four operations. $O=\{\mg,\cp,\cl,\ed\}$

  \cp, \cl~are  functions between (surface string, buffer) pairs, i.e.

  $\cp,\cl : \LBOUND\sg^* \times \sg^* \arr  \LBOUND\sg^* \times \sg^*$

  \begin{description}
  \item[\cp] $\cp(s,b) = (sb,bb)$ \hfill \cp~copies the buffer and appends it to both the string and the buffer

 \item[\cl] $\cl(s,b) = (s,\epsilon)$ \hfill \cl~clears the buffer

  \end{description}

  \begin{description}
  \item[\ed]   \ed~maps from string, buffer pairs to strings, i.e.

  $\ed : \LBOUND\sg^* \times \sg^* \arr  \sg^*$

  $\ed(\LBOUND s,b) = s$ \hfill \ed~returns the string

  \end{description}

%   Given a bigram set \BIGR, we define \mg~as a function from (string, buffer, $a\in\sg$) triples to (string, buffer) pairs, i.e.

%   $mg : (\sg^* \times \sg^*) \times \sg \arr  \sg^* \times \sg^*$

%   \begin{description}
%   \item[\mg] $\mg((s,b),a) =
%     \begin{cases}
%       (s^\frown a, b^\frown a) & \text{ if } (s(-1),a)\in\BIGR\\
%       \text{undefined} & \text{otherwise}
%     \end{cases}
% $

   \begin{description}

   \item[\mg] \mg~is a probabilistic function $\mg:\LBOUND\sg^*\times\sg^*\arr \LBOUND\sg^*\times\sg^*$, which means actually $\mg:\LBOUND\sg^*\times\sg^* \arr (\LBOUND\sg^*\times\sg^* \arr [0,1])$.
     \mg~adds a symbol to the end of both the string and the buffer if the transition is legal according to \BIGR.

     The subdistribution, call it $\delta$, from $\LBOUND\sg^*\times\sg^*$ to [0,1], is defined as follows, where $\phi_\BIGR$ is the probability function of \BIGR:

for $(s,b)\in\LBOUND\sg^*\times\sg^*$, $\mg(s,b) = \delta_{s,b}$ s.t.

$  \delta_{s,b}(s',b') =
\begin{cases}
  \phi_\BIGR(s'(-2),s'(-1)) & \text{ if } \exists a\in\sg (s' = sa)\\
  0 & \text{otherwise}
\end{cases}
$

When $a\in\sg$ is chosen, we call the operation a \textit{merge of a}.

  \end{description}

\end{definition}

Interpretation function of derivations. Defined recursively.

$I(ops,bis,t) =
\begin{cases}
  \llb t\rrb & \text{ if } ops=bis=\emp\\
  I(ops[1:],bis[1:],\llb ops[0]\rrb(\llb t\rrb,bis[0])) & \text{ if } ops[0]=\mg~ \&~ bis\neq\emp\\
  I(ops[1:],bis,\llb ops[0]\rrb(\llb t\rrb)) & \text{ if } ops[0]\neq\mg\\
  \text{undefined} & \text{ otherwise}
\end{cases}
$

For strings:

\llb\mg\rrb = \mg~as defined in definition \ref{def:ops}

\llb\cp\rrb = \cp~as defined in definition \ref{def:ops}

\llb\cl\rrb = \cl~as defined in definition \ref{def:ops}

\llb\ed\rrb = \ed~as defined in definition \ref{def:ops}

\llb start \rrb = (\LBOUND,\emp)

$s\in L(\OURG)$ iff $\exists ops\in O^*$ that is accepted by \OPS
and $\exists bis\in \sg^*$ that is accepted by \BIGR
such that
$I(ops,bis,start) = s$\\

MCFG:\\

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

   \end{array}$\\\\

Notice that the name and RHS are enough to uniquely identify the
actual rule. So we can interpret the derivation tree output from I in
the MCFG too:

\cl(T(s,b,x)) = C(s,x)\\
\cp(T(s,b,x)) = T(sb,bb,x)\\
\ed(T(s,b,x)) = S(s)\\
\mg(T(s,b,c),a) = T(sa,ba,a) $\forall (c,a)\in\BIGR$\\
\mg(C(s,c),a) = T(sa,a,a) $\forall (c,a)\in\BIGR$\\

\llb start \rrb = C(\emp,\LBOUND)\\
\llb\cl\rrb = the rule named \cl~ in the MCFG above\\
\llb\cp\rrb = the rule named \cp~ in the MCFG above\\
\llb\mg\rrb(t,a) = $
\begin{cases}
  T(sa,ba,a) & \text{ if } t = T(s,b,c) \exists c\in\sg\\
  T(sa,a,a) & \text{ if } t = C(s,c) \exists c\in\sg\\
\end{cases}
$\\

This isn't right yet, or these are two different ways of saying it.

\begin{definition}
  A derivation step is a pair of expressions such that the second is the result of applying one operation to the first.

  Specifically,  $(e_1,e_2)$ is a derivation step iff $\exists \op\in O$ such that $e_2=\op(e_1)$ or $(\op(e_1))(e_2)>0$. The former case is for \cp, \cl, and \ed, and the latter for \mg.

  For $e_i\in\expr$  we write $e_1 \Rightarrow e_2$ if $(e_1,e_2)$ is a derivation step and say that $e_2$ is \textit{derived from} $e_1$.

  If there is a series of $n$ derivation steps $e_0\Rightarrow e_1 \Rightarrow \dots \Rightarrow e_n$, then we write $e_0\Rightarrow^n e_n$, or, in the general case, $e_0\Rightarrow^* e_n$, and say  $e_n$ is \textit{derived from} $e_0$.

  If $e_0\Rightarrow^n s$, a sequence of operations $o_1,o_2,...,o_{n-1}$ such that $\forall i<n-1, e_{i+1}=o_i(e_i)$ or $(\op(e_1))(e_2)>0$ is an \textit{operation string of s}.

%  If there is a finite series of derivation steps $(e_0,e_1),(e_1,e_2)...,(e_{n-1},e_n)$ where for each consecutive pair of steps the second element of the first step is the same as the first element of the second step, then we write $e_0\Rightarrow^* e_n$ and say  $e_n$ is \textit{derived from} $e_0$.

\end{definition}

\begin{definition}[Language defined by \OURG]
$L(\OPS,\BIGR)\subseteq\sg^*$ is the language defined by the grammar (\OPS,\BIGR) defined as follows:   $s\in L(\OPS,\BIGR)$ iff $(\LBOUND,\epsilon)\Rightarrow^*s$ and there is an operation string of $s$ that is accepted by \OPS~with probability greater than 0.
\end{definition}

\subsection{Minimalist Grammars and PMCFGs}
\label{sec:minimalist-grammars}

We can define a parallel multiple context free grammar that is equivalent to our grammar. We add a third element to the (string,buffer) pair to track the most recent merge. The quantifications are short for the full set of rules that satisfy the predicate. The start category is, ironically, \ed.
I think this is a (3,1)-PMCFG. (In terms of the class, is there a problem with the deletion of the buffer? What about the fact that in \cp, $b$ occurs three times, not just 2?)

\begin{definition}[PMCFG]\

  \noindent$NT = \mg,\cp,\cl,\ed$\\
  $T = \sg$\\
  Start category: \ed\\
  Variables: $s,b,x$\\
  Metavariables: $a,c$ over \sg\\

$  \begin{array}{r c l l}
    \cl(s,x) &\der& \mg(s,b,x)\\
    \cl(s,x) &\der& \cp(s,b,x)\\
    \cp(sb,bb,x) &\der& \mg(s,b,x)\\
    \cp(sb,bb,x) &\der& \cp(s,b,x)\\
    \mg(sa,ba,a) &\der& \mg(s,b,c) & \forall (c,a)\in\BIGR\\
    \mg(sa,ba,a) &\der& \cp(s,b,c)&\forall (c,a)\in\BIGR\\
    \mg(sa,a,a) &\der& \cl(s,c) &\forall (c,a)\in\BIGR\\
    \mg(a,a,a) &\der&  &\forall(\LBOUND,a)\in\BIGR\\
    \ed(s) &\der& \mg(s,b,x)\\
    \ed(s) &\der& \cp(s,b,x)\\
   \end{array}$\\\\

   If we're working with right boundary symbols, the two \ed~rules can be replaced by

   $\ed(s)\der\mg(s,b,a) ~~~~~\forall a\in\sg$ s.t. $(a,\RBOUND)\in\BIGR$

   $\ed(s)\der\cp(s,b,a) ~~~\forall a\in\sg$ s.t. $(a,\RBOUND)\in\BIGR$
\label{def:pmcfg}
 \end{definition}

 \begin{thm}
   The PMCFG (call it P) in definition \label{def:pmcfg} is weakly equivalent to the two-part grammar in definition \label{def:g}.
 \end{thm}

 \begin{proof}
   We proceed by induction on the depth of the derivation tree. of zo.

   \begin{enumerate}
   \item a dt of depth 1 would have to be $\ed(a)$ for some $a\in\sg$ since \ed is the start symbol. This is impossible since neither \ed rule is an axiom.
   \item a dt of depth 2 could be \ed(\cp(a)) or \ed(\mg(a)) for some a. The former is impossible since no \cp rule is an axiom. However, \mg has a set of axioms: one for each a with $(\LBOUND,a)\in\BIGR$. \mg(a,a,a) is an RHS for \ed, so $a\in L(P)$ iff $(\LBOUND,a)\in\BIGR$.

     Conversely, $a\in L(\OURG)$ whenever $(\LBOUND,a)\in\BIGR$ since (S,\mg,NotCL) and (NotCL,\ed,F) $\in \OPS$, which generates \ed(\mg(\LBOUND,\emp)), \mg(\LBOUND,\emp) = $\delta_{\LBOUND,\emp}$ and  $\delta_{\LBOUND,\emp}(\LBOUND a,a) = \phi((\LBOUND,a))$

   \end{enumerate}

 \end{proof}

\subsubsection{MGs}
\label{sec:mgs}

We define some weakly and strongly equivalent MGs because that seems smart.

This MG doesn't work quite like ours because you can clear the buffer pretty much whenever.

\begin{definition}[Minimalist Grammar]\

  \begin{description}
  \item[Features] $F=\{\fea{=a, a} | a\in \sg \}\cup\{S,F\}$
    % \begin{itemize}
    % \item Bare features $BF=\sg\cup\{S\}$, $S$ a designated start feature
    % \item $F=BF\cup\{\fea{=a} | a\in sg\}$
    % \end{itemize}

  \item[\Lex]
    \begin{itemize}
    \item $\forall (a,b) \in \BIGR$ we have
      $b::\fea{=ab} \in \Lex$

    \item and $b::\fea{=a}\in\Lex$ OR $\forall (a,b),(b,{]})\in\BIGR, b::\fea{=aF}\in\Lex$
    \item $\forall ({[},a)\in\BIGR$ we have $a::\fea{=Sa}$
    \item $\emp::\fea{S}\in\Lex$
    \end{itemize}

  \item[\mg] $\mg( a::X, (s,b)::\fea{=X}\beta) = (sa,ba)::\beta$
  \item[\cp] $\cp((s,b)::\alpha) = (sb,bb)::\alpha$
  \item[\cl] $\cl((s,b)::\alpha) = (s,\epsilon)::\alpha$ ~~~~if $b\neq\emp$
  \item[\ed] $\ed((s,b)::\fea{F}) = s$

  \end{description}
\end{definition}

\Tree[.\ed\\aabab [.\cp\\(aabab,abab)::\fea{F} [.\mg\\(aab,ab)::\fea{F} [.\mg\\(aa,a)::\fea{a} [.\cl\\(a,\emp)::\fea{a}  [.\mg\\(a,a)::\fea{a} \emp::\fea{S} a::\fea{=Sa} ]] a::\fea{=aa} ] b::\fea{=aF} ]]]\\

% \begin{definition}[Minimalist Grammar 2]\

%   \begin{description}
%   \item[Features] $F=\{\fea{=a,a} | a\in \sg \} \cup\{\fea{S,F,+clear,-clear}\}$
%     % \begin{itemize}
%     % \item Bare features $BF=\sg\cup\{S\}$, $S$ a designated start feature
%     % \item $F=BF\cup\{\fea{=a} | a\in sg\}$
%     % \end{itemize}

%   \item[\Lex]
%     \begin{itemize}
%     \item $\forall (a,b) \in \BIGR$ we have
%       $b::\fea{=ab} \in \Lex$
%     \item $\forall (a,b),(b,{]})\in\BIGR$ (OR $\forall (a,b)$) we have $b::\fea{=aF}\in\Lex$
%     \item $\forall ({[},a)\in\BIGR$ we have $a::\fea{=Sa}\in\Lex$
%     \item $(\emp::\fea{S},\emp::\fea{-clear})\in\Lex$
%     \end{itemize}

%   \item[\mg] $\mg(a::\fea{X},(s::\fea{=X}\beta,b::\fea{\ensuremath{\alpha}clear})) = (sa::\beta,ab::\fea{\ensuremath{\alpha}clear})$
%   \item[\cp] $\cp((s::\beta,b::\pm\fea{clear}) = (sb::\beta, bb::\fea{-clear})$\hfill if $b\neq\emp$
%   \item[\cl] $\cl(s::\beta,b::\fea{-clear}) = (s::\beta,\emp::\fea{+clear})$\hfill if $b\neq\emp$
%   \item[\ed] $\ed(s::\fea{F},b::\fea{-clear}) = s$

%   \end{description}
% \end{definition}

% \Tree[.\ed\\aabab [.\cp\\aabab::\fea{F},abab::\fea{-cl} [.\mg\\aab::\fea{F},ab::\fea{+cl} [.\mg\\aa::\fea{a},a::\fea{+cl} [.\cl\\a::\fea{a},\emp::\fea{+cl}  [.\mg\\a::\fea{a},a::\fea{-cl} \emp::\fea{S},\emp::\fea{-cl} a::\fea{=Sa} ]] a::\fea{=aa} ] b::\fea{=aF} ]]]

\subsubsection{The right one}
\label{sec:right-one}

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

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

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

\caption{Features and equivalent states}
\label{tab:features-states}
\end{table}
We design the MG with features on the string and the buffer. The features on the string model the bigrams \BIGR~and the ones on the buffer model the states \STATES.

\begin{definition}[Minimalist Grammar 2]\

  \begin{description}
  \item[Features] $F=\{\fea{=a,a} | a\in \sg \} \cup\{\fea{S,F,+clear,-clear,+buf,-buf}\}$
    % \begin{itemize}
    % \item Bare features $BF=\sg\cup\{S\}$, $S$ a designated start feature
    % \item $F=BF\cup\{\fea{=a} | a\in sg\}$
    % \end{itemize}

  \item[\Lex]
    \begin{itemize}
    \item $\forall (a,b) \in \BIGR$ we have
      $b::\fea{=ab} \in \Lex$
    \item $\forall (a,b),(b,\RBOUND)\in\BIGR$ (OR $\forall (a,b)$) we have $b::\fea{=aF}\in\Lex$
    \item $\forall (\LBOUND,a)\in\BIGR$ we have $a::\fea{=Sa}\in\Lex$
    \item $(\emp::\fea{S},\emp::\fea{-clear,-buf})\in\Lex$
    \end{itemize}

  \item[\mg] $\mg(a::\fea{X},(s::\fea{=X}\beta,b::\fea{\ensuremath{\alpha}clear,\ensuremath{\gamma}buf})) = (sa::\beta,ab::\fea{\ensuremath{\alpha}clear,+buf})$
  \item[\cp] $\cp((s::\beta,b::\pm\fea{clear,+buf}) = (sb::\beta, bb::\fea{-clear,+buf})$
  \item[\cl] $\cl(s::\beta,b::\fea{-clear,+buf}) = (s::\beta,\emp::\fea{+clear,-buf})$
  \item[\ed] $\ed(s::\fea{F},b::\fea{-clear},\fea{+buf}) = s$

  \end{description}
\end{definition}

\begin{figure}[H]
  \Tree[.\ed\\aabab [.\cp\\aabab::\fea{F},abab::\fea{-cl,+buf}
  [.\mg\\aab::\fea{F},ab::\fea{+cl,+buf}
  [.\mg\\aa::\fea{a},a::\fea{+cl,+buf}
  [.\cl\\a::\fea{a},\emp::\fea{+cl,-buf}
  [.\mg\\a::\fea{a},a::\fea{-cl,+buf}
  \emp::\fea{S},\emp::\fea{-cl,-buf} a::\fea{=Sa} ]] a::\fea{=aa} ]
  b::\fea{=aF} ]]]
  \Tree[.\ed\\aabab [.\cp\\aabab,abab
  [.\mg\\aab,ab
  [.\mg\\aa,a
  [.\cl\\a,\emp~
  [.\mg\\a,a
   a ]] a ]
  b ]]]

  \caption{Example parallel MG and our grammar derivations}
  \label{fig:mg-der}
\end{figure}

\begin{thm}
  Our grammar, which needs a name, is strongly equivalent to MG2.
\end{thm}

\begin{proof}[Proof]
  Every transition in the operations FSA has an equivalent MG rule and vice versa. Every transition in \BIGR is represented as a Merge step of a lexical item.

  \begin{enumerate}
  \item Operations FSA
    We use the feature equivalents of the state names. Note there are nine transitions in the FSA including the start state definition, and there are nine featural configurations in the MG in which an operation is defined, modulo the bigram features \fea{a,=a} etc. All nine are covered here.

In the table below we show the parallel FSA transitions and MG rules. In the MG rules we include only the relevant features for clarity.

    \begin{tabular}[H]{p{0.5\textwidth} | p{0.5\textwidth}}
      Transition & MG\\
      \hline
      $q_o=(\fea{-buf,-clear})$ & The only lexical item that does not select is the start item (\emp::\fea{S},\emp\fea{-buf-clear}). Merge is to the left so this will be the first word of the string. \\      \hline
      (\fea{-buf-clear},\mg,\fea{+buf-clear}) is the only transition from \fea{-buf,-clear}&Only \mg~ is defined for expressions with feature \fea{-buf}. \mg(\fea{-buf,-clear}) = \fea{+buf,-clear} \\
      \hline
      (\fea{-buf+clear},\mg,\fea{+buf+clear}) is the only transition from \fea{-buf,+clear}&Only \mg~ is defined for expressions with feature \fea{-buf}. \mg(\fea{-buf,+clear}) = \fea{+buf,+clear} \\
      \hline
      (\fea{+buf-clear},\mg,\fea{+buf-clear}) & \mg(\fea{+buf,-clear})=\fea{+buf,-clear}\\      \hline
      (\fea{+buf-clear},\cp,\fea{+buf-clear}) & \cp(\fea{+buf,-clear})=\fea{+buf,-clear}\\      \hline
      (\fea{+buf-clear},\cl,\fea{-buf+clear}) & \cl(\fea{+buf,-clear})=\fea{-buf,+clear}\\      \hline
      (\fea{+buf-clear},\ed,\fea{F}) & \ed(s::\fea{F},b::\fea{+buf,-clear})=s\\      \hline
      (\fea{+buf+clear},\mg,\fea{+buf+clear}) & \mg(\fea{+buf,+clear})=\fea{+buf,+clear}\\      \hline
      (\fea{+buf+clear},\mg,\fea{+buf-clear}) & \cp(\fea{+buf,+clear})=\fea{+buf,-clear}\\

    \end{tabular}

  \item \BIGR:
    \begin{itemize}
    \item each bigram $(a,b)\in\BIGR$ such that $a,b\in\sg$ has a
      lexical item in the MG b::\fea{=ab}.
    \item each bigram $({[},a)\in\BIGR$ has a lexical item in the MG a::\fea{=Sa}. There is an empty start item with feature \fea{S}. It is the only LI with category \fea{S}.
    \item If we want to include final bigrams, $(a,{]})$, then we include in the MG LIs a::\fea{=bF} for each $(b,a)\in\BIGR$. Otherwise we include such LIs for all bigrams. This is the equivalent of some or all states of the Markov chain being final states.
    \end{itemize}
Only Merge and End interact in any way with the features that come with the ``string''. These features are the features that are based on the lexical items and \fea{S} and \fea{F}. Merge only allows items to join the derivation if they create legal bigrams and End only allows the derivation to end if we have a final category.

  \end{enumerate}
\end{proof}

As to whether MG3 is equivalent to a parallel MG, we can begin by simplifying the grammar so that we don't care whether or not we Copy or Clear vacuously. The resulting grammar is clearly weakly equivalent to this one: the only difference is that sometimes operations that do nothing to either the string or the buffer are performed. \ed might look a little worrying, but it is fine too since \fea{F} is the final category, and the start LI has feature \fea{S}. Therefore we don't add an empty string to the yield. This is MG1 above.

MG1 is featurally normal for an MG: no weird features like \fea{-clear}. Merge is also defined exactly the same as in an MG. I've simplified the definition to exclude cases that never arise because of the simplicity of the lexicon, but this is unnecessary.

The difference is that we build two strings in parallel, the string and the buffer. The buffer can also be independently emptied. Unlike in a normal MG, these operations are not triggered by features, but rather occur freely. We could add in licensing features to keep everything feature-driven. If we want a model in which whether \mg, \cp, or \cl~occurs depends on what word was most recently merged, we could add features like this. However, we currently want a model in which copy and clear are independent of words.

\subsubsection{Copy-move}
\label{sec:copy-move}

\newcommand\bcp{\text{\textsl{begCP}}}
\newcommand\ecp{\text{\textsl{endCP}}}

Ed also wanted to be able to basically copy-move. We can do this by replacing \cl~with two operations: \bcp, which opens the buffer, and \ecp, which stops writing to the buffer. When the buffer is existent and open we Merge and Copy to it. When it is existent closed we can Copy it.

\begin{definition}[Minimalist Grammar 3]\

  \begin{description}
  \item[Features] $F=\{\fea{=a,a} | a\in \sg \}\cup\{\fea{S,F,-copy,+copy}\}$
    % \begin{itemize}
    % \item Bare features $BF=\sg\cup\{S\}$, $S$ a designated start feature
    % \item $F=BF\cup\{\fea{=a} | a\in sg\}$
    % \end{itemize}

  \item[\Lex]
    \begin{itemize}
    \item $\forall (a,b) \in \BIGR$ we have
      $a::\fea{a}, b::\fea{=ab} \in \Lex$
    \item $\forall (a,b),(b,{]})\in\BIGR$ (OR $\forall (a,b)$) we have $b::\fea{=aF}\in\Lex$
    \item $\forall ({[},a)\in\BIGR$ we have $a::\fea{=Sa}$
    \item $\emp::\fea{S}\in\Lex$
    \end{itemize}

  \item[Merge simple] $\mg( a::\fea{X}, s::\fea{=X}\beta) = sa::\beta$
  \item[Merge and build a copy] $\mg( a::\fea{X}, (s::\fea{=X}\beta,b::\fea{+copy})) = (sa::\beta,ba::\fea{+copy})$
  \item[Merge and hold a copy] $\mg( a::\fea{X}, (s::\fea{=X}\beta,b::\fea{-copy})) = (sa::\beta,b::\fea{-copy})$
  \item[Begin building a copy] $\bcp(s::\beta) = (s::\beta,\emp::\fea{+copy})$
  \item[Store the copy] $\ecp(s::\beta,b::\fea{+copy}) = (s::\beta,b::\fea{-copy})$

  \item[Copy and keep building the copy] $\cp((s::\beta,b::\fea{+copy}) = (sb::\beta, bb::\fea{+copy})$
  \item[Copy and end copy] $\cp((s::\beta,b::\fea{-copy}) = sb::\beta$

  \item[\ed] $\ed(s::\fea{F}) = s$

  \end{description}

\end{definition}

{\small
\Tree[.\ed\\aabab [.\cp\\aabab::\fea{F}~ [.\ecp\\aab::\fea{F},ab::\fea{-copy}  [.\mg\\aab::\fea{F},ab::\fea{+copy} [.\mg\\aa::\fea{a},a::\fea{+copy} [.\bcp\\a::\fea{a},\emp::\fea{+copy}  [.\mg\\a::\fea{a} \emp::\fea{S} a::\fea{=Sa} ]] a::\fea{=aa} ] b::\fea{=aF} ]]]]
\Tree[.\ed\\aabcab [.\cp\\aabcab::\fea{F} [.\mg\\aabc::\fea{F},ab::\fea{-copy}  [.\ecp\\aab::\fea{b},ab::\fea{-copy}  [.\mg\\aab::\fea{b},ab::\fea{+copy} [.\mg\\aa::\fea{a},a::\fea{+copy} [.\bcp\\a::\fea{a},\emp::\fea{+copy}  [.\mg\\a::\fea{a} \emp::\fea{S} a::\fea{=Sa} ]] a::\fea{=aa} ] b::\fea{=ab} ]]  c::\fea{=bF} ] ]]
}

\includegraphics[width=5in]{ops_distance.png}

% \begin{definition}[Trying to make a prolog notation MCSG]
% This is the intuition, but it's not right. We need to include the bigram rules in the category names, thus multiplying the rules all the hell.

%   \begin{eqnarray*}
%   T(\emp,\emp) &\der&\\
%   L(a) &\der& a ~~~~~~~~~~~~~~~~~~~\forall a\in\sg\\
%   T(xa,ya) &\der& T(x,y)~ L(a)  \\
%   T(xy,yy) &\der& T(x,y)\\
%   T(x,\emp) &\der& T(x,y)\\
%   S(x) &\der& T(x,y)\\
%   \end{eqnarray*}

% Assuming (a,b) and (b,a) are legal bigrams we get:

%   \begin{eqnarray*}
%   T(\emp,\emp) &\der&\\
%   A(a) &\der& a \\
%   TA(xz,yz) &\der& T(x,y)~ A(z)  \\
%   TA(xz,yz) &\der& TA(x,y)~ A(z)  \\
%   TA(xz,yz) &\der& TB(x,y)~ A(z)  \\
%   TA(xy,yy) &\der& TA(x,y)\\
%   TA(x,\emp) &\der& TA(x,y)\\
%   S(x) &\der& TA(x,y)\\
%     \\
%   B(b) &\der& b\\
%   TB(xz,yz) &\der& T(x,y)~ B(z)  \\
%   TB(xz,yz) &\der& TA(x,y)~ B(z)  \\
%   TB(xz,yz) &\der& TB(x,y)~ B(z)  \\
%   TB(xy,yy) &\der& TB(x,y)\\
%   TB(x,\emp) &\der& TB(x,y)\\
%   S(x) &\der& TB(x,y)\\
% \\
% etc\\
%   \end{eqnarray*}

% \end{definition}

\subsection{Parser}
\label{sec:parser}

\begin{definition}[parse]

A \textit{parse} for surface string $s$ is a pair $(b,r)$ where $b\in\sg^*$, and $r=(Q,E)$ is a route through the operations $\FSA$ such that there is a derivation of length $|Q|$ from
 $(\epsilon,\epsilon)$ to  $s$ where the $i$th derivation step is an application of $E(i)$ and the $i$th \mg~in $E$ is a merge of $b(i)$.

The set of all parses of sentence $s$ is written $\PARSES(s)$
\end{definition}

\noindent We want some counts from a parse for the learner:

\begin{definition}[state counts]
  Given a route $(Q,E)$, we define $\SC_Q : \STATES \rightarrow\N$ as follows: $\SC_Q(q) = \#\{ i | Q(i)=q \}$
\end{definition}

\begin{definition}[transition counts]
  Given a route $(Q,E)$, we define $\TC_{Q,E} : \FSA \rightarrow\N$ as follows: $\TC_{Q,E}(q,e,q') = \#\{ i<n | Q(i)=q,E(i)=e,Q({i+1})=q'\}$
\end{definition}

\begin{definition}[unigram counts]
  Given a sequence of words $b\in\sg^*$, we define a function $\UC_b : \sg \rightarrow\N$ as follows: $\UC_b(w) = \#\{ i | b(i) = w \}$
\end{definition}

\begin{definition}[bigram counts]
  Given a sequence of words $b\in\sg^*$, we define a function $\BC_{b} : \BIGR \rightarrow\N$ as follows: $\BC_b(a,b) = \#\{ i | b(i)=a \& b(i+1) = b \}$
\end{definition}

\section{Likelihoods}

\begin{definition}[rule probability assignment]
A rule probability assignment is an assignment of a probability to each transition of the operations FSA, i.e. $p(q,e,q')$, such that $\sum_{e,q'}p(q,e,q')=1$, and to each bigram/transition in the Markov chain.
\end{definition}

\begin{definition}[likelihoods]
A rule probability assignment can then be extended in a straightforward way to yield.

The probability of a parse $(b,(Q,E))$ is the product of the probabilities of its transitions in both the operations FSA and the Markov chain. We take the product because the probability of the parse is the probability of this transition \textit{and} this transition \textit{and}... etc

$$p(b,(Q,E)) = \prod_{i<|s|} p(Q(i),E(i),Q(i+1)) \prod_{i<|b|} p(b(i),b(i+1))$$

The probability of a sentence is the sum of the probabilities of its parses. We take the sum because the probability of the sentence is the probability of this parse \textit{or} this parse \textit{or}... etc

$$p(s) = \sum_{(b,r)\in\PARSES(s)} p(b,r)$$

 By extension the probability of a corpus $C$ is the product of the probabilities of the sentences

$$p(C)=\prod_{s\in C}p(s)$$
\end{definition}

So our task is given a corpus $C$ to find a probability assignment that maximises $p(C)$.

Since the search space is large, it may only be possible to find a local maximum and not a global maximum.

We're somewhat unsure how the following achieves this, but it seems to work.

\section{Iterative rule updates}

We want to estimate the likelihood of each rule in a given corpus. For this, we iteratively re-estimate the rule probabilities: given a rule probability assignment, we can re-estimate the probabilities of every parse of a sentence, and then this changes the probabilities that each rule was used.

Roughly speaking, a transition from state $q$ to $q'$ can be estimated to happen with the following likelihood:
$$\phi(q,q') = \frac{\textrm{expected number of times we went }q\rightarrow q'}{\textrm{expected number of times we were in }q}$$

Now, given say a sentence $s$, the expected number of times we used a particular transition, is:
\begin{eqnarray*}
  E_s(q,e,q') & = & \textrm{expected number of times we went }~q\rightarrow^eq'~\textrm{to make sentence}~s \\
  & = & \sum_{(b,r)\in\PARSES(s)}\frac{p_\phi(b,r)}{p_\phi(s)}[\textrm{number of times}~q\rightarrow^eq'\textrm{ occurs in }r ] \\
  & = & \sum_{(b,r)\in\PARSES(s)}\frac{p_\phi(b,r)}{p_\phi(s)}\TC_r(q,e,q')
  \end{eqnarray*}

Why divide by the probability of the sentence? This is because the sentence is given. For example, if a sentence has exactly one parse, but it uses a lot of rules, then the expected number of times a particular rule got used is exactly the number of times it got used in that one parse, \emph{not} dividing by the (very small) probability of that sentence.

Similarly for the Markov chain:

\begin{eqnarray*}
  E_s(x,y) & = & \textrm{expected number of times we went }~x\rightarrow y~\textrm{to make sentence}~s \\
  & = & \sum_{(b,r)\in\PARSES(s)}\frac{p_\phi(b,r)}{p_\phi(s)}[\textrm{number of times}~x\arr y\textrm{ occurs in }b ] \\
  & = & \sum_{(b,r)\in\PARSES(s)}\frac{p_\phi(b,r)}{p_\phi(s)}\BC_b(x,y)
  \end{eqnarray*}

Now given a corpus $C$, we simply add the expected number of times rules got used in each sentence, i.e.
\begin{eqnarray*}
  E_C(q,e,q')& = &\sum_{s\in C}E_s(q,e,q')\\
  E_C(x,y)& = &\sum_{s\in C}E_s(x,y)
\end{eqnarray*}

\begin{definition}[corpus update rule]
  Given a corpus $C$ and given a probability assignment $\phi$ we can define an updated probability assignment $\phi'$ as follows:

  $$\phi_C'(q,e,q') = \frac{\sum_{s\in C}\sum_{(b,r)\in\PARSES(s)} \frac{p_\phi(b,r)}{p_\phi(s)}~ \TC_r(q,e,q')}{\sum_{s\in C}\sum_{(b,r)\in\PARSES(s)} \frac{p_\phi(b,r)}{p_\phi(s)}~ \SC_r(q)}$$

And for the bigrams:

  $$\phi_C'(x,y) = \frac{\sum_{s\in C}\sum_{(b,r)\in\PARSES(s)} \frac{p_\phi(b,r)}{p_\phi(s)}~ \BC_b(x,y)}{\sum_{s\in C}\sum_{(b,r)\in\PARSES(s)} \frac{p_\phi(b,r)}{p_\phi(s)}~ \UC_b(x)}$$

\end{definition}

Equivalently,

$$\phi_C'(q,e,q') = \frac{\sum_{s\in C}\frac{1}{p_\phi(s)}\sum_{(b,r)\in\PARSES(s)} p_\phi(b,r)~ \TC_r(q,e,q')}{\sum_{s\in C}\frac{1}{p_\phi(s)}\sum_{(b,r)\in\PARSES(s)} p_\phi(b,r)~ \SC_r(q)}$$

and

$$\phi_C'(x,y) = \frac{\sum_{s\in C}\frac{1}{p_\phi(s)}\sum_{(b,r)\in\PARSES(s)} p_\phi(b,r)~ \BC_b(x,y)}{\sum_{s\in C}\frac{1}{p_\phi(s)}\sum_{(b,r)\in\PARSES(s)} p_\phi(b,r)~ \UC_b(x)}$$

\subsection{Some basic results}

\begin{lemma}[no-ambiguity]
  If there is no ambiguity, $\phi_C'(q,e,q')$ does not depend on the original rule probability assignment.
\end{lemma}

\begin{proof}
  If there is no ambiguity, for any sentence one parse $(b,r)$ exists for which $p(s)=p(b,r)$. Further, none of the counts depend on rule probability assignment $\phi$. Thus the expected counts of each transition/bigram and each state/unigram are simply their counts in the corpus.

  \begin{eqnarray*}
    \phi_C'(q,e,q')& = &\frac{\sum_{s\in C}\sum_{(b,r)\in\PARSES(s)} \frac{p_\phi(b,r)}{p_\phi(s)}~ \TC_r(q,e,q')}{\sum_{s\in C}\sum_{(b,r)\in\PARSES(s)} \frac{p_\phi(b,r)}{p_\phi(s)}~ \SC_r(q)}\\
    & = &\frac{\sum_{s\in C} 1 \times \TC_r(q,e,q')}{\sum_{s\in C} 1 \times \SC_r(q)}
  \end{eqnarray*}

  \begin{eqnarray*}
    \phi_C'(x,y)& = &\frac{\sum_{s\in C}\sum_{(b,r)\in\PARSES(s)} \frac{p_\phi(b,r)}{p_\phi(s)}~ \BC_b(x,y)}{\sum_{s\in C}\sum_{(b,r)\in\PARSES(s)} \frac{p_\phi(b,r)}{p_\phi(s)}~ \UC_b(x)}\\
    & = &\frac{\sum_{s\in C} 1 \times \BC_b(x,y)}{\sum_{s\in C} 1 \times \UC_b(x)}
  \end{eqnarray*}

\end{proof}

As a corollary, in an unambiguous corpus the algorithm will converge to a global likelihood maximum in one step, irrespective of the original rule probabilities.

\section{Higher level points}
\label{sec:higher-level-points}

\subsection{The hypothesis}
\label{sec:hypothesis}

Songbirds whose songs are made up of a vocabulary of chirps are normally thought to determine their next chirp entirely on the basis of the previous chirp; in other words their grammar is a Markov chain. They have a probability distribution over the bigrams of their vocabulary ($\sg \times \sg \arr [0,1]$) and that is the extent of the complexity of their grammar.

We claim that the California Thrasher has a more complex grammar. We observe that the bird has repeated substrings in its songs, some even embedded inside other repeated fragments. This might just be a coincidence, or it might be that the bird includes copying in its grammar.  A grammar with copying is far above a Markov chain in the Chomsky hierarchy: it is mildly context sensitive, like human language grammars.

\subsection{How we try to answer the question}
\label{sec:how-we-try}

All we have is samples of the bird's song. Naturally, a finite sample can always be generated by the simplest grammar available: a finite grammar of legal songs. We can't ask the bird for grammaticality judgements so all we have to go on is the corpus. We can make up a bigram grammar that generates the corpus, and we can also make up a grammar with copying that generates the corpus, and we can make them up so that they generate exactly the same language.

However, since birds are thought to be stochastic creatures -- they use not just a bigram grammar but a Markov chain, which is a probabilistic bigram grammar -- we have additional evidence for what their grammar might really look like: we have the probability distribution in the corpus. We can therefore compare the performance of two grammars, one with copying and the other without, on the corpus.

To do this we take a part of the corpus and find the best fit of the rule probabilities in each grammar for that part of the corpus. We then test each fitted grammar's ability to predict the rest of the corpus. The grammar that makes a better prediction is a more likely grammar for that corpus.

\subsection{Questions and concerns}
\label{sec:questions-concerns}

\begin{itemize}
\item If you add copying to the grammar of just any bird, will it perform better?
\item Floris's fancy repetition-measurer finds that the bigrams themselves predict \textit{more} copying, not less. On the one hand this is fine: the point is that the bird needs to be able to independently control copying. But on the other hand, this is very weird: we started with this surface observation of copying, and now we claim that the bird is a copy bird based on \textit{less} copying?
\item Do we need to prove that no sub-MCS grammar predicts the corpus as well as the copy grammar in order to be saying anything about the bird's Chomsky-hierarchy status? (note: this is impossible)
\item Do we need to prove that our grammar is indeed copying? Or that it is indeed MCS?
\end{itemize}

\subsection{Notes on the Chomsky hierarchy}
\label{sec:notes-chomsky-hier}

\includegraphics[width=6in]{Chomsky-hierarchy.pdf}

There are certain surface patterns that are known to only be generable with grammars of certain types. For example, $a^nb^n$ famously requires a context free grammar. However, since this is a hierarchy anything you can generate with a lower-level grammar you can also generate with a higher-level grammar. If we have a language or a corpus that is, say, regular, we might still want to say that the grammar that generated it is supra-regular. This would have to be based on either additional facts about the language or corpus, on arguments from parsimony, or on additional information about the source of the corpus.

In our case we argue from the probability distribution in the corpus. If we have reason to think that the bird generates his song probabilistically, then the probabilities in the grammar predict probabilities in the corpus. A grammar with ``room'' in it to include probabilities for copying should better predict the corpus if the bird is indeed copying.

PMCFGs defined in Seki et al , originally in (Kasami 1988a),(Seki 1991). Copy language $ww\in \mathcal{L}(PMCFG)$; $a^{2^n}\in \mathcal{L}(PMCFG)$

Kasami, T. et al. 1988a. "Generalized Context-Free Grammars and Multiple Context-Free Grammars", Trans. IEICE, J71-D-I, 5:758-765.

\subsection{TODO}
\begin{itemize}
\item Prove in a grammar without ambiguity that the algorithm actually moves to the global likelihood maximum.
\item Prove correctness (rule probabilities with the same left hand side sum to one).
\item Prove that each rule update increases the likelihood of the corpus.
\item Prove convergence.
\end{itemize}

\section{Historical and mostly wrong stuff}

Previously we used this update rule:

\begin{definition}[sentence-level update rule]
  Given a sentence $s$ and given a probability assignment $\phi$ we can define an updated probability assignment $\phi'$ as follows:

  $$\phi_s'(q,e,q') = \frac{\sum_{(b,r)\in\PARSES(s)}p_\phi(b,r)~\TC_r(q,e,q')}{\sum_{(b,r)\in\PARSES(s)}p_\phi(b,r)~\SC_r(q)}$$
\end{definition}

%\begin{definition}[sentence-level update rule]
%  Given a sentence $s$ and given a probability assignment $\phi$ we can define an updated probability assignment $\phi'$ as follows:%
%
%  $$\phi_s'(q,e,q') = \sum_{(b,r)\in\PARSES(s)}\frac{p_\phi(b,r)}{\sum_{(b',r')\in\PARSES(s)}p_\phi(b',r')}\frac{\TC_r(q,e,q')}{\SC_r(q)}$$
%\end{definition}

%We can write more simply $p_\phi(s)=\sum_{(b',r')\in\PARSES(s)}p_\phi(b',r')$ so that

%$$\phi_s'(q,e,q') = \frac{1}{p(s)}\sum_{(b,r)\in\PARSES(s)}p(b,r)\frac{\TC_r(q,e,q')}{\SC_r(q)}$$

Similarly, given a corpus, we compute the updates based on all parses in parallel:
\begin{definition}[corpus update rule]
  Given a corpus $C$ and given a probability assignment $\phi$ we can define an updated probability assignment $\phi'$ as follows:

 $$\phi_C'(q,e,q') = \frac{\sum_{s\in C}\sum_{(b,r)\in\PARSES(s)} p_\phi(b,r)~ \TC_r(q,e,q')}{\sum_{s\in C}\sum_{(b,r)\in\PARSES(s)} p_\phi(b,r)~ \SC_r(q)}$$
\end{definition}

%Floris' version:
%$$\phi_C'(q,e,q') = \frac{\sum_{s\in C}p(s)\phi_s'(q,e,q')}{\sum_{s\in C}p(s)}$$

The sums can't be combined into one sum because sometimes there are parses that visit state $q$ but don't follow transition $(q,e,q')$. However, we still want that visit in the state counts for that transition.

We can't use the probability of the whole corpus because not all sentences have parses that visit all states.

\end{document}

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


The \xmlNode{Components} node contains the technical and economic definitions of the components (or
units) within the grid system that needs to be solved. The \xmlNode{Components} node contains many
\xmlNode{Component} nodes defining each of the grid components.

\subsection{Component Activity}
At each time point in a dispatch optimization, HERON attempts to calculate the most optimal usage of
each component in the system. To report the usage of each resource in each unit in the system, HERON
uses some conventions that we explain here.

We can consider two quantities when reporting the activity of a component over time: the quantity of
product consumed or produced, or the rate at which a product is consumed or produced. For instance,
if a Component produces ``widgets'', at a particular hour we can either talk about the total number
of widgets produced during an hour period, or about the rate (in widgets per second) at which they
were produced. Generally, we only track the rate of production for all Components when performing
dispatch optimization; however, for a \xmlNode{Component} who \xmlNode{stores} a resource, we track
the \emph{level} (or \emph{net quantity produced}) instead of the \emph{rate}.

\subsubsection{General Activity}
For most components, when the activity is reported at a particular time for a component, it
represents the instantaneous production level of that component at that time. For example, if a
component's max capacity is given as 10 widgets per second, and the activity reported for hour 2 is
3, then instantaneously at the beginning of hour 2 the unit is assumed to be producing 3 widgets per
second. Simlarly, if a power plant has a capacity of 100 MW and activity is reported as 5 for a
particular hour, then at beginning of that hour the plant is producing 5 MW. Between time points, it
is assumed that the rate of production varies linearly between the reported time points.

\subsubsection{Storage Activity}
Unlike other components, for a storage (a \xmlNode{Component} who \xmlNode{stores} a resource) we
report the instantaneous \emph{level} of the storage instead of the instantaneous production rate.
We formally define the level (or ``net quantity produced'') at a specific time as
\begin{equation}
  L(t) = L_0 + \int_{t_0}^t R(t) dt,
\end{equation}
where:
\begin{itemize}
  \item $L$ is the net quantity produced at time $t$,
  \item $L_0$ is an initial level at the start of the analysis period,
  \item $t$ is the continuous variable for \emph{time},
  \item $t_0$ is the starting time, at which the components has level $L_0$, and
  \item $R(t)$ is the rate of production for the component at time $t$.
\end{itemize}
In discrete terms,
\begin{equation}
  L_k = L_0 + \sum_{i=1}^{k-1} R_i \Delta_k,
\end{equation}
where:
\begin{itemize}
  \item $k$ is an index for discrete time intervals $t_k$,
  \item $L_k$ is the level at the beginning of time interval $t_k$,
  \item $R_k$ is the production rate for the component during time interval $t_k$, and
  \item $\Delta_k$ is the length of the time interval $t_k$.
\end{itemize}
The equivalent continuous production rate for a storage component is therefore
\begin{equation}
  R(t) = \frac{\partial}{\partial t} L(t),
\end{equation}
or, in discrete form given the constant production assumption,
\begin{equation}
  R_k = \frac{L_{k+1} - L_k}{\Delta_k}.
\end{equation}
We want to emphasize this key difference: the \emph{production rate} is interpreted differently for
storage and other producers. For \textbf{storages},
\begin{itemize}
  \item production rate during a time step is considered \emph{discontinuously constant}, and
  \item activity is reported as the \emph{level} of the storage at the beginning of the time step.
\end{itemize}
For \textbf{all other components},
\begin{itemize}
  \item production rate during a time step is considered \emph{continuously linear}, and
  \item activity is reported as the \emph{instantaneous production rate} of the storage at the
        beginning of the time step.
\end{itemize}
This difference has significant impact when developing a \xmlNode{Validator} or plotting dispatch
results. As a demonstration, see Figures \ref{fig:producer_example} and \ref{fig:storage_example}.

In Figure \ref{fig:producer_example}, the black dots indicate the statepoints that HERON reports,
while the green dashed line is the assumed production between statepoints. Note the
$y$-axis is in units of production rate.

\begin{figure}[h!]
  \centering
  \includegraphics[width=0.5\textwidth]{../pics/producer_activity_explained.png}
  \caption{Producer Example}
  \label{fig:producer_example}
\end{figure}

In Figure \ref{fig:storage_example}, the black dots indicate the statepoints that HERON reports,
with units of emph{level}, not production rate. The red dotted line is the assumed level between
statepoints, and the green dashed lines are the equivalent production between each statepoint.
Note the dual $y$-axis: one is in units of production rate (green, left), while the other is in units of level or
quantity (red, right). That is, the storage unit filly slowly, then fills quickly, then totally depletes before
filling again. This same activity can be represented by the production rates in the dashed green
lines, with negative production indicating absorbing into storage and positive production indicating
emission from storage.
\begin{figure}[h!]
  \centering
  \includegraphics[width=0.5\textwidth]{../pics/storage_activity_explained.png}
  \caption{Storage Example}
  \label{fig:storage_example}
\end{figure}


\input{../../utils/header.tex}

\begin{document}

\title{Machine Learning (41204-01)\\HW \#7}
\author{Will Clark and Matthew DeLio \\
\textsf{\{will.clark,mdelio\}@chicagobooth.edu} \\
University of Chicago Booth School of Business}
\date{\today}
\maketitle

\section{Data Summary}

The user that has rated the most video games is \textsf{U584295664}; he has rated 53 games. This user is an extreme outlier, as the median user rated only two games and only one other user rated more than 21 games. This behavior makes him approximately 22 standard deviations above the mean. We can see in \cref{fig:histo_users} just how extreme this outlier is (the maximum value is marked with a red line).

The game that has been rated most frequently is \textsf{I760611623}; it has been rated 200 times. This game is also an extreme outlier, as the median game has been rated three times and the next most-rated game was rated by only 102 users. The rating profile for this game puts it at approximately 15 standard deviations above the mean. We can see in \cref{fig:histo_games} how far from the center of the distribution this game is (the maximum value is again marked in red).

\begin{figure}
\centering
\begin{subfigure}[b]{0.49\textwidth}
\caption{by User}
\includegraphics[width=\textwidth]{histo_users.pdf}
\label{fig:histo_users}
\end{subfigure}
\hfill
\begin{subfigure}[b]{0.49\textwidth}
\caption{by Game}
\includegraphics[width=\textwidth]{histo_games.pdf}
\label{fig:histo_games}
\end{subfigure}
\caption{Distribution of Rating Behavior}
\end{figure}

\section{User Similarity}
To find the user most similar to \textsf{U141954350}, we use RecommenderLab's similarity function.  To compute cosine similarity, we can simply feed the raw ratings data into the similarity function with our user in question, use the argument \textsf{method="cosine"}, and get a list of similarity scores between them and the others.

To compute Jaccard similarity, however, we had to "binarize" the ratings.  To do this, we first normalize the data, which attempts to reduce any user bias by row-centering the data (subtracts the user's mean score from each rating).  With this normalized data, we choose then to use the mean (now 0) as the cutoff between a binary 0/1.  This means that any score above the user's mean is a favorable score (\textsf{=1}), and any below, is a unfavorable (\textsf{=0}).  This binary data is then fed into the similarity function with the \textsf{method="jaccard"} argument which produces similarity scores between the user in question and the others.

%We attempted to use the \textsf{pearson} method, but ran into issues when calculating the similarity matrix (it returned only NAs).

The top 10 scores are listed in \cref{tab:top10}.  These show some good agreement between the two methods with the top 5 matching in exact order.  Furthermore, of the top 10 similar users, 9 appear in both lists.  The closest user to our user in question is \textsf{U887577623}

\input{top10.tex}

\section{Recommendations}

To recommend a particular item to our user \textsf{U141954350} we utilize a ``popular'' recommender (see \vref{lst:code}).  We employ two methods for determining which item to recommend.
\begin{enumerate}
\item \textbf{Top-N List}\\Uses the recommender to produce a top 10 list based on the most popular items.
\item \textbf{Top Predicted Ratings}\\Predicts all ratings for the user, which can then be sorted to produce a top-10 list.
\end{enumerate}

Before beginning this analysis, we would have been surprised if these two lists were drastically different from one another --- in theory, they are supposed to produce the items that are ``best'' for the given user.  We find, however, that they produce completely different lists with drastically different predicted ratings (see \cref{tab:topn,tab:highest}).  Likely the algorithms work differently, one using user-similarity to predict a top list (Top-N List) and the other just producing top ratings with potentially low support (Top Predicted Ratings).  If this is the case, one would expect the Top-N List to represent a more robust list.  Therefore the item that we would recommend to the user is \textsf{I840620023}.

\input{topn.tex}
\input{highest.tex}

\begin{appendices}

\clearpage
\section{Code Listings}
\lstinputlisting[label=lst:code, caption=Code for Homework, language=R]{../hw6.R}

\end{appendices}

\end{document}

% \input{.tex}

% \begin{figure}
%   \centering
%   \begin{subfigure}[b]{0.49\textwidth}
%     \caption{}
%     \includegraphics[width=\textwidth]{.pdf}
%     \label{fig:}
%   \end{subfigure}
%   \hfill
%   \begin{subfigure}[b]{0.49\textwidth}
%     \caption{}
%     \includegraphics[width=\textwidth]{.pdf}
%     \label{fig:}
%   \end{subfigure}
%   \caption{}
% \end{figure}

% \begin{figure}[!htb]
%   \centering
%   \caption{}
%   \includegraphics[scale=.5]{.pdf}
%   \label{fig:}
% \end{figure}