%% It is just an empty TeX file.
%% Write your code here.
\graphicspath{{sec06/images/}{sec06/code/}}
\lstset{inputpath=sec06/code/}

\subsection{Define macros}

\begin{frame}\relax

{\centering\Huge \TeX\ is Turing-complete language

}
\inclassFrag{Who understand, what does it means?}
In basic words, it means, that you can write in \TeX\ and \LaTeX\ any algoritms, that you can write in C++, Java, Python... Moreover, some \TeX syntax is really familiar to functional languages
\skfootnote{\vspace{-3ex}\stExC{https://stackoverflow.com/questions/2968411/ive-heard-that-latex-is-turing-complete-are-there-any-programs-written-in-late} \overC{https://www.overleaf.com/learn/latex/Articles/LaTeX_is_More_Powerful_than_you_Think_-_Computing_the_Fibonacci_Numbers_and_Turing_Completeness} \url{http://sdh33b.blogspot.com/2008/07/icfp-contest-2008.html}}

\end{frame}

\begin{frame}{Define macros \tW\magicPage}
     In \TeX\ you can define new macros via \ccol\def.

\twocolImg{
\lstinputlisting[linerange={8-9, 14-16}]{commandwith.tex}
}{commandwith}

    Use \ccol\global\ prefix to define macros not just inside ``group''.

    Use \ccol\long\ prefix to define macros that can have multiple paragraphs as an argument.

    \skfootnote{\tugC{https://www.tug.org/utilities/plain/cseq.html\#def-rp} \knuthc{20}[209]}
\end{frame}

\begin{frame}{Define with pattern matching\tw\magicPage}\relax

The syntax with writing each argument seems to be an over-use. But it is needed because of \textit{pattern matching}

\twocolImg{
\lstinputlisting[linerange={11-13}]{commandpattern.tex}
}{commandpattern}

\end{frame}

\subsection{Conditions}

\begin{frame}[fragile]{Compare strings (macros)\tW\magicPage}\relax

\twocolImg{
\lstinputlisting[linerange={12-21}]{ifmy.tex}
}{ifmy}

    {\csk \verb|\ifx\<first>\<second>  <code1>  [\else  <code2>]  \fi|}

\end{frame}

\begin{frame}[fragile]{Compare numbers\tW\magicPage}\relax

\twocolImg{
\lstinputlisting[linerange={12-20}]{ifnummy.tex}
}{ifnummy}

    {\csk \verb|\ifnum<first><operator><second>  <code1>  [\else  <code2>]  \fi|}. Only ``='', ``>'' or ``<'' are allowed.

    Use {\csk \verb|\ifcase|} to check different stuff.

    Also use {\csk \verb|\ifodd|} to check if num is odd or even

\end{frame}

\begin{frame}[fragile]{Check modes\tW\magicPage}\relax

\twocolImg{
\lstinputlisting[linerange={12-22}]{ifmodemy.tex}
}{ifmodemy}
\begin{itemize}
    \item {\csk\verb|\ifmmode|} to check if in mathematical mode
    \item {\csk\verb|\ifvmode|} to check if in vertical mode
    \item {\csk\verb|\ifhmode|} to check if in horizontal mode
    \item {\csk\verb|\ifinner|} to check if \TeX\ is in internal vertical mode, or restricted horizontal mode, or (nondisplay) mathmode

\end{itemize}

\skfootnote{other ``if'''s can be found in \knuthc{20}[221]}
\end{frame}

\begin{frame}{Compare in \LaTeX\lW\magicPage}\relax
\twocolImg{
\lstinputlisting[linerange={7-7, 12-16}]{ifstring.tex}
}{ifstring}
      \ncol\usepackage{xstring}

      also see \ncol\usepackage{ifthen}

      \hrule

      you can check if you are in \XeLaTeX by \ncol\usepackage{ifxetex}

      \skfootnote{read about the xstring package! It has lots of things: strings, substrings,.. what to do with them,.. replace strings etc\\ \stExC{https://tex.stackexchange.com/questions/47576/combining-ifxetex-and-ifluatex-with-the-logical-or-operation}}
\end{frame}

\subsection{Loops and recursion}

\begin{frame}[fragile]{Loop \tW\magicPage}\relax
\twocolImg{
\lstinputlisting[linerange={12-17}]{loopmy.tex}
}{loopmy}

\ccol\loop\ for start loop, <code> inside, then {\csk\verb|\if<..>|}-family, another bunch of <code>, ended with \ccol\repeat.

     \skfootnote{\knuthc{20}[228]}
\end{frame}

\begin{frame}[fragile]{Reqursion \tW\magicPage}\relax
\twocolImg{
\lstinputlisting[linerange={12-13}]{reqmy.tex}
}{reqmy}

\end{frame}

\begin{frame}[fragile]{For loop\lW\magicPage}\relax
\twocolImg{
\lstinputlisting[linerange={8-8, 13-16}]{forloopmy.tex}
}{forloopmy}
\ncol \usepackage{forloop}

\twocolImg{
\lstinputlisting[linerange={8-8, 13-15}]{foreachmy.tex}
}{foreachmy}

\ncol \usepackage{pgffor}, part of pgf, part of TikZ

\skfootnote{\stExC{https://stackoverflow.com/questions/2561791/iteration-in-latex}}
\end{frame}

\subsection{Related things to macros creation}

\begin{frame}[fragile]{``let'' command\magicPage}\relax

\twocolImg{
\lstinputlisting[linerange={11-21}]{letmy.tex}
}{letmy}

The statement ``\ccol\let\verb|\a=\b|'' gives \string\a\ the current meaning of \string\b. If \string\b\ changes after the assignment is made, \string\a\ does not change.

\skfootnote{\knuthc{20}[217] \tugc{https://www.tug.org/utilities/plain/cseq.html\#let-rp}}

\end{frame}

\begin{frame}[fragile]{Usecase with \ccol\let: ``decorator''\magicPage}\relax

Imagine: you have some \string\command used inside the document multiple times. You want to \textit{add some addition behaviour} to the command -- decorate (or ``wrap'', or ``redefine with the use of itself''). You can do it with \ccol\let:

\begin{lstlisting}
\let\oldCommand=\command
\def\command#1{<some code>\oldCommand}
\end{lstlisting}

And the same for enviruments using \ncol\usepackage{etoolbox} or \ccol{\g@addto@macro}

\skfootnote{\stExC{https://tex.stackexchange.com/questions/47351/can-i-redefine-a-command-to-contain-itself} \stExC{https://tex.stackexchange.com/questions/467435/environment-decorators}}

\end{frame}

\subsection{Programming examples}

\begin{frame}{99 Bottles of Beer\magicPage}\relax

\twocolImg{
\lstinputlisting[linerange={9-26}]{bottles.tex}
}{bottles}

\skfootnote{\url{https://rosettacode.org/wiki/99_Bottles_of_Beer#LaTeX}}

\end{frame}

\begin{frame}{not-AND logical gate\magicPage}\relax

\twocolImg{
\lstinputlisting[linerange={11-29}]{nand.tex}
}{nand}

\skfootnote{\url{https://rosettacode.org/wiki/99_Bottles_of_Beer#LaTeX}}
\end{frame}

\begin{frame}{Split words\magicPage}\relax
\twocolImg{
\lstinputlisting[linerange={11-31}, basicstyle=\tiny]{splitmy.tex}
}{splitmy}

     \skfootnote{\stExC{https://tex.stackexchange.com/questions/12810/how-do-i-split-a-string/12811}}
\end{frame}


\section{\textbf{Atomic MRSW Register}}
% -------------------------------------------------------------------------------- %
\subsection{Particular Case}
\par
The characteristics of this type of register are:
\begin{itemize}
\item It should never happen that $R^{i} \rightarrow W^{i}$
\item It should never happen that for any ${j}$, ${W^{i} \rightarrow W^{j} \rightarrow R^{j}}$
\item If ${R^{i} \rightarrow R^{j}}$ then ${i \leq j}$
\end{itemize}
The book proposes to do this by using multiple SRSW registers.
% -------------------------------------------------------------------------------- %
\subsection{Solution}
The algorithm then requires a 2 dimensional table. When a writer decides to
update the register, it has to update the values in cells $A[i][i]$, where $i$
is the thread id. Apart from writing the value, it has to also update the cell
with a timestamp.
\par
In the other hand, when a reader wants to read from the register, it checks the
timestamp of the cell $A[i][i]$. After that, it has to check other cells in the
same column (i.e., cells $A[x][i]$) to see if there has been an update in between.
That is done by comparing the timestamps. If there is a newer timestamp, the
reader has then to update all cells in its row (i.e. $A[i][x]$). This is the way
to indicate subsequent readers which version of the value has the previous
reader retrieved.
\par
It is easy to see that the first property is satisfied because there is no way
to read a future value. In order to read a value, this value has to be written
before.
\par
The second property is also satisfied because when a reader reads the value, it
reads the one with the most recent timestamp by scanning the timestamps in its
corresponding column. This reader also helps subsequent readers by updating all
cells in its row. Forcing property 3 to be satisfied as well.
\par
The \textit{read()} and \textit{write()} methods are shown next:
\par
\begin{lstlisting}[style=numbers]
  public synchronized T read() {
    int me = ThreadID.get();
    StampedValue<T> value = a_table[me][me];
    for (int i = 0; i < a_table.length; i++) {
      value = StampedValue.max(value, a_table[i][me]);
    }
    for (int i = 0; i < a_table.length; i++) {
      a_table[me][i] = value;
    }
    return value.value;
  }

  public synchronized void write(T v) {
    int me = ThreadID.get();
    long stamp  = lastStamp.get() + 1;
    lastStamp.set(stamp); // remember for next time
    StampedValue<T> value = new StampedValue<T>(stamp, v);
    for (int i = 0; i < a_table.length; i++) {
      a_table[me][i] = value;
    }
  }
\end{lstlisting}
\hfill
% -------------------------------------------------------------------------------- %
\subsection{Experiment Description}
\par
The two test cases presented demonstrates the same as previous examples so we
will not describe the experiment further.
\par
% -------------------------------------------------------------------------------- %
\subsection{Sample Results}
\par
For this test, the results were always successful. Here is the sample output:
\begin{verbatim}
.sequential read and write
.parallel read

Time: 0.004

OK (2 tests)
\end{verbatim}
\par
% -------------------------------------------------------------------------------- %
\subsection{Interpretation}
\par
In this experiment we observed a way of implementing MRSW registers. We saw
that, at least in the processor we used, the algorithm seems to work correctly.
\par
It would have been great, though, to also have test cases that demonstrate that this
particular register satisfies property 3 which is the one that makes it
different from the Safe version.
% -------------------------------------------------------------------------------- %


\documentclass[11pt, oneside]{article}
\usepackage[a4paper,bindingoffset=0.2in,%
            left=1in,right=1in,top=1in,bottom=1in,%
            footskip=.25in]{geometry}
\usepackage{graphicx}
\usepackage{enumerate}
\usepackage{url}
\usepackage{hyperref}
\usepackage{pbox}
\usepackage{CJKutf8}

\begin{document}
\title{Part III Eigen Decomposition and SVD (Introduction)}
\author{Xiyou Zhou, 13307130189 \\ Computer Science and Technology}
\maketitle
\section{Question}
What's the relationship between eigendecomposition and singular value decomposition?
\section{Math Perspective}

Considering eigendecomposition in the form of $A = PDP^{-1}$ and SVD $A=U\Sigma{}V^*$.\\

For Hermitian matrices, there is no fundamental difference between the SVD and eigenvalue decompositions. The squared singular values are eigenvalues of the normal matrix:
$$\sigma_i(A)=\sqrt{\lambda_i(AA^*)}=\sqrt{\lambda_i(AA^*)}$$
Where
$$A^*A=(V\Sigma{}U^*)(U\Sigma{}V^*)=V\Sigma^2V^*$$

For other matrices, SVD can be applied to any kind of rectangular or square matrix while the eigendecomposition can only be applied to some of the square matrices. SVD requires the diagonal matrix $\Sigma$ to be real and non-negative while in eigendecomposition the entries of D can be complex value. Other difference can be directly derived from the form of decomposition.

\section{Code Implementation Perspective}
SVD can be a more general implementation for eigendecomposition calculation on Hermitian (symmetric) matrices.

Specifically, we can derive all eigenvalues in $O(n^3)$ then calculate the eigendecomposition value. The SVD can be computed by performing an eigenvalue computation for the normal matrix $A^*A$ (a positive-semidefinite matrix) in $\sim{}O(mn^2)$ time.

\begin{thebibliography}{9}
\bibitem{Lecture5handout}
Aleksandar Donev: Scientific Computing-Eigen and Singular Values,
\\\texttt{http://cims.nyu.edu/~donev/Teaching/SciComp-Spring2012/Lecture5.handout.pdf}

\bibitem{Svdnote}
Frank Dellaert: Singular Value and Eigenvalue Decompositions
\\\texttt{http://www.cc.gatech.edu/~dellaert/pub/svd-note.pdf}
\end{thebibliography}

\end{document}


\documentclass[11pt]{article}

\usepackage{fullpage}  % More space
\usepackage{tgpagella} % Better font
\usepackage{microtype} % Slightly improved typography

\usepackage{hyperref}
\usepackage{cleveref}
\usepackage{todonotes}

\usepackage{amsmath, amsfonts, amsthm, amssymb, mathtools} % math
\usepackage{mathpartir}

\usepackage{syntax}
\setlength{\grammarindent}{4em} % increase separation between LHS/RHS

\usepackage{macro/generic}
\usepackage{macro/code}

%=====================================================================
% Author
%=====================================================================

\title{A Regular Expression Library for Haskell}
\author{Josh Acay \\ \href{mailto:ca483@cornell.edu}{ca483@cornell.edu}}
\date{May 22, 2018}

%=====================================================================
% Macros
%=====================================================================

\newtheorem{theorem}{Theorem}
\newtheorem{example}{Example}

\DeclareMathOperator{\lang}{\mathcal{L}}
\DeclareMathOperator{\derivative}{D}
\DeclareMathOperator{\nullable}{nullable}

\newcommand{\transpose}{^\top}

\newcommand{\by}[1]{\parens{\text{#1}}}
\newcommand{\since}[1]{\parens{\text{since #1}}}
\newcommand{\eqBy}[1]{\braces{\text{#1}}}

\newcommand{\haskell}{\lstinline}

\begin{document}
\maketitle

\begin{abstract}
  I detail the implementation of a regular expression library for Haskell.\footnote{%
    Available online at \url{https://github.com/cacay/regexp}.}
  Unlike similar libraries in the wild, this one supports more than just matching strings: it can compute intersections and complements, take derivatives \'a la Brzozowski \cite{Brzozowski64}, check for equivalence, and solve systems of linear equations with regular expression coefficients. In addition, the library is designed to be generic over the alphabet (even allowing infinite ones) so it is not tied to Haskell's builtin \haskell{Char} and \haskell{String} types.
\end{abstract}

\section{Introduction}
  Regular expressions provide a simple yet powerful language for string searching and matching. They are expressive enough to describe many common patterns that arise in practice (e.g.\ alternatives and repetition) but restrictive enough that many desirable properties are effectively decidable (e.g.\ equivalence and containment checking). Additionally, regular languages are closed under intersection, union, and complement making it possible to expose a natural interface that uses familiar connectives like ``and'', ``or'', and ``not''.

  Unfortunately, practical implementations of regular expressions focus too much on string matching and forego all the benefits of having a restricted language. For instance, I was
  unable to find a single popular regular expression library (for any programming language) that supports equivalence checking.
  % Very few support complement and/or intersection, but do so by extending the language
  % rather than computing the complement or intersection in terms of the basic operators.
  In fact, many modern implementations add features such as capture groups and backreferences which break most closure properties and make equivalence checking undecidable \cite{CampeanuSY03}.

  Although string matching is sufficient for many application, there are cases where the additional power is useful (e.g.\ during design and development) or necessary.\footnote{%
    I sketch the application this library was built for in \cref{application}.}
  Here, I detail the design and development of a Haskell library that exposes this additional power to the user.

\section{Specification}

Given an alphabet $\Sigma$, regular expressions have the following syntax:
\begin{grammar}
  <exp> ::= 1
  \alt <exp> + <exp>
  \alt <exp> $\cdot$ <exp>
  \alt <exp>$^*$
  \alt $l \subseteq \Sigma$
\end{grammar}

The interpretation of these expressions is standard:
$1$ matches the empty word,
$e_1 + e_2$ matches either $e_1$ or $e_2$,
$e_1 \cdot e_2$ matches $e_1$ followed by $e_2$,
$e^*$ matches zero or more copies of $e$,
and the literal $l$ matches single character words $a$ where $a \in l$.
This is a generalization of the standard syntax which only allows single characters as literals rather than sets of characters or \emph{character classes} and encodes the set $\set{a_1, a_2, \ldots, a_n}$ as $a_1 + a_2 + \cdots + a_n$. I use character classes directly since they generalize to infinite alphabets (which I will discuss in \cref{effective-boolean-algebra}) and are more efficient to implement. The expression 0---which matches no strings---is represented with the empty character class $\emptyset$.

It is easy enough to define a parametrized algebraic data type \haskell{RegExp $\Sigma$} that mirrors this syntax. I implement the following operations on regular expressions:
\begin{itemize}
  \item \haskell{matches :: RegExp $\Sigma$ -> [$\Sigma$] -> Bool}\\
    \haskell{matches $e$ $w$} returns \haskell{True} whenever the expression $e$ matches the word $w$.

  \item \haskell{complement :: RegExp $\Sigma$ -> RegExp $\Sigma$}\\
    \haskell{complement $e$} returns a regular expression that matches precisely the words $e$ does not match.

  \item \haskell{intersection :: RegExp $\Sigma$ -> RegExp $\Sigma$ -> RegExp $\Sigma$}\\
    \haskell{intersection $e_1$ $e_2$} returns a regular expression that matches words both $e_1$ and $e_2$ match.

  \item \haskell{equivalent :: RegExp $\Sigma$ -> RegExp $\Sigma$ -> Either [$\Sigma$] ()}\\
    \haskell{equivalent $e_1$ $e_2$} returns \haskell{Right ()} (i.e.\ ``true'') if $e_1$ and $e_2$ are equivalent, and \haskell{Left $w$} otherwise. Here, the word $w$ is a counterexample that is matched by one expression but not the other.

  \item \haskell{solve :: LinearSystem $\Sigma$ -> RegExp $\Sigma$}: given a system of linear equations of the form:
    \begin{gather*}
      X_1 = e_1^0 + e_1^1 X_1 + e_1^2 X_2 + \cdots e_1^n X_n\\
      X_2 = e_2^0 + e_2^1 X_1 + e_2^2 X_2 + \cdots e_2^n X_n\\
          \vdots\\
      X_m = e_m^0 + e_m^1 X_1 + e_m^2 X_2 + \cdots e_m^n X_n
    \end{gather*}
    where each $e_i^j$ is non-nullable (i.e.\ doesn't match the empty string), solve for $X_1$.\footnote{%
    Actual type of \haskell{solve} is slightly different, but amounts to the same thing.} Note that all coefficients need to be on the same of the variables to ensure there is a solution. I arbitrarily pick left.

    \haskell{solve} is a versatile and powerful function. It can derive \haskell{intersection}, \haskell{complement}, and many other operators. However, I observed that going through deterministic finite automata gives more succinct expressions.
\end{itemize}

\section{Implementation}

\subsection{Derivatives of Regular Expressions}

The entirety of this library reduces to Brzozowski derivatives, deterministic finite state automata (DFAs), and the correspondence between them. The derivative of a regular expression $e$ with respect to a character $a \in \Sigma$ is a regular expression $e'$ such that $e'$ matches a word $w$ if and only if $e$ matches $a w$. Brzozowski showed that derivatives always exist and that they could be computed syntactically \cite{Brzozowski64}. This has an obvious extension to arbitrary words $w$, which I denote by $\derivative_w{(e)}$. This gives a trivial way to implement matching:
\begin{equation*}
  \haskell{matches $e$ $w$ = nullable ($\derivative_w{(e)}$)}
\end{equation*}
where \haskell{nullable $e$} if and only if $e$ can match the empty word. There is no need to explicitly convert to a DFA, although one might still want to for efficiency's sake.

\subsection{Computing Intersection and Complement}

To compute intersection and complement, I go through the standard motions of converting regular expressions to DFAs, performing the relevant operation on the DFA representations (product construction for intersection and flipping accepting/non-accepting states for complement), and converting back. Although the concept of going through DFAs is not new, the methods I use are hard to come by in real-world code (even though they are not novel theoretically).

In the forward direction, I construct a DFA directly from a regular expression using Brzozowski derivatives instead of determinizing a nondeterministic finite state automaton, which is what most implementations do. The idea is simple: derivatives of a regular expression are the states of the deterministic automaton and there is an $a$ transition from $e$ to $e'$ if $\derivative_a{(e)} = e'$. Considering the derivative with respect to all words gives the full automaton. Brzozowski showed in \cite{Brzozowski64} that this process generates only finitely many states as long as regular expressions are compared modulo associativity, commutativity, and idempotence of $+$ (ACI). I achieve this by keeping the type \haskell{RegExp} abstract and only exposing ``smart'' constructors that normalize regular expressions with respect to the following equalities:
\begin{mathpar}
(r + s) + t = r + (s + t)
\and r + s = s + t
\and r + r = r
%
\\ 0 + r = r
%
\\ (r \cdot s) \cdot t = r \cdot (s \cdot t)
\and 1 \cdot r = r = r \cdot 1
\and 0 \cdot r = 0 = r \cdot 0
%
\\ (r^*)^* = r^*
\and 0^* = 1
\and 1^* = 1
\end{mathpar}
The first three equalities are required for termination as discussed; others reduce the number of states generated which speeds up execution and results in smaller more readable expressions. To get even smaller expressions, I keep regular expressions in strong star normal form, which was introduced as a linear time simplification method in \cite{GruberG10}. Very basically, the strong star normal form limits applications of $^*$ to non-nullable expressions, so $(1 + a)^*$ would get converted to the equivalent $a^*$.

The other direction, converting a DFA into a regular expression, is essentially unimplemented: I was unable to find a single library, or even a single piece of working code that does it\footnote{%
  I did find a Coq library described in \cite{DoczkalKS13} that implements DFA to regular expression conversion and does so in a mechanically verified way, but being a constructive proof, the implementation was so inefficient it was unable to convert the expression $0$ to a DFA and back.}.
  Worse yet, a web search yields no results that are easy to turn into an algorithm. Most sources talk about solving a system of linear equations but offer no insight into how. Such methods might work if one is doing this by hand, but of course a computer requires a more formal specification.

  The method I settled on is due to Kozen \cite{Kozen94}. The idea is simple and elegant: represent the DFA in matrix form as a triple $\angled{u, M, v}$ where $u$ and $v$ are $\set{0, 1}$ vectors representing starting and accepting states, respectively, and $M$ is the transition matrix. Then, $u\transpose M^* v$ gives a regular expression that matches the set of words accepted by this DFA\@. I use a home-baked implementation of sparse vectors and sparse matrices to represent DFAs since I was unable to find an existing Haskell library that was up to the task. The most interesting part of this is the implementation of Kleene star for matrices, which uses the divide-and-conquer method of \cite{Kozen94}. Further details on the technique can be found in \cite{Kozen94}.

\subsection{Equality Checking}

I use Hopcroft and Karp's bisimulation algorithm for checking DFA equivalence \cite{HopcroftK71} modified to use a union-find structure as described in \cite{BonchiP11}. However, I generate the DFAs on the fly using Brzozowski derivatives instead of computing them upfront. This gives the algorithm a chance to fail early and avoid the exponential time process of converting to a DFA\@. The implementation is able to generate a counterexample if the expressions are not equivalent.

\subsection{Solving Systems of Linear Equations}

Given a system of linear equations of the form
\begin{gather*}
  X_1 = e_1^0 + e_1^1 X_1 + e_1^2 X_2 + \cdots e_1^n X_n\\
  X_2 = e_2^0 + e_2^1 X_1 + e_2^2 X_2 + \cdots e_2^n X_n\\
      \vdots\\
  X_m = e_m^0 + e_m^1 X_1 + e_m^2 X_2 + \cdots e_m^n X_n
\end{gather*}
where $e_i^j$ are non-nullable, it is possible to solve for $X_1$ using Arden's lemma and Gaussian elimination. Arden's lemma states that the unique solution to the equation $X = A \cdot X + B$ is $A^* B$ as long as $A$ is non-nullable. Using the lemma, it is possible to eliminate variables one at a time by walking down the list\footnote{%
Apply the lemma to the first equation to get an equation for $X_1$ that doesn't refer to itself, then substitute it in for $X_1$ in all following equations. Rinse and repeat until you reach the bottom.} until $X_m$ is reached. At this point, the equation for $X_m$ only refers to itself, so apply Arden's lemma to get a closed expression for $X_m$. This can be propagated back using substitution by walking up the list. At each step, the equation for a variable will only contain that variable so Arden's lemma gives a closed form solution.

Linear equation solving is useful for many applications, one of which is computing intersection and complement. It is easy to see that
\[ \haskell{intersection $e_1$ $e_2$}
  = (\haskell{nullable $e_1$} = \haskell{nullable $e_2$}) + \sum_{a \in \Sigma}{a  \cdot \haskell{intersection (derivative $a$ $e_1$) (derivative a $e_2$)}}
\]
and
\[ \haskell{complement $e$}
  = \neg(\haskell{nullable $e$}) + \sum_{a \in \Sigma}{a \cdot \haskell{complement (derivative $a$ $e$)}}
\]
(interpreting booleans as regular expressions in the expected way). Unfolding these definitions indefinitely and treating every application of the operator to unique input(s) as a fresh variable results in a finite system of linear equations since every regular expression has a finite set of derivatives modulo ACI as discussed.

\subsection{Generalizing Literals}\label{effective-boolean-algebra}

Rather than fixing literals to be sets of characters, I define them to be elements of an effective boolean algebra $\angled{\Sigma, U, \bracks{\cdot}, \sqcup, \sqcap, \bot, \top}$.
The implementation closely follows the presentation in \cite{KeilT14} so I will elide the details. The important thing to note is that effective boolean algebras have many useful instantiations including finite subsets of a finite alphabet, finite and cofinite (a set whose complement is finite) subsets of an infinite alphabet, a logic of decidable propositions over an alphabet and so on.

My implementation is generic against this abstract interface so all these options can be made to work easily, but I only provide an implementation of finite and cofinite subsets of a \emph{finite} alphabet. One might wonder the point of supporting cofinite subsets of a finite alphabet since they are finite sets after all. The reason is that supporting cofinite subsets gives major speedups when working with very large alphabets such as the set of Unicode characters. For example, the representation of \haskell{complement $\set{a}$} is simply the complemented set $\neg\set{a}$ which needs to list a single element. Representing this set directly would require listing all characters that are not ``a'' of which there are millions.

\section{Testing and Verification}

I employ a mix of static and dynamic techniques to ensure correctness. Static guarantees are a result of Haskell's incredibly powerful type system. For example, I use algebraic data types to ensure all regular expressions conform to the syntax described in this paper. With normalized regular expressions, I had to go a step further and use generalized algebraic data types (a.k.a.\ indexed algebraic data types) \cite{CheneyH03} to check invariants such as ``Kleene star is only applied to non-nullable regular expressions''. This is achieved by indexing the data type of regular expression by a boolean \haskell{isNullable} with the obvious meaning. The implementation of sparse vectors and sparse matrices goes yet another step further straight into the dependently typed territory. These types are indexed by their size to enforce invariants such as ``only vectors of equal length are added together''. I use the singletons library \cite{Singletons} for this purpose, which gives Haskell limited dependent programming capabilities. I insert dynamic assertions wherever the type system falls short. These dynamic checks are useful for two reasons: (1) they increase the likelihood of catching bugs, and (2) they make tracking down the root cause of said bugs much easier.\footnote{%
  I discovered one bug due to an assertion failure. A different unrelated bug in the regular expression to DFA conversion code was discovered during testing by manual inspection of output, but I tracked it down by inserting dynamic checks (which, in hindsight, should have been there to begin with).
}

In addition to static checks, I use unit tests and property testing to further increase the confidence in the library. Unit tests are assertions on ground terms such as
  \[ \haskell{intersection $(a + b)^*$ $a^*$} = a^* \]
  where $a$, $b$ are concrete elements of a concrete type $\Sigma$, say, \haskell{Char}.  Haskell's hspec library\footnote{%
  \url{https://hackage.haskell.org/package/hspec}
} provides a good framework for writing such tests. I use SmallCheck \cite{SmallCheck} and QuickCheck \cite{QuickCheck} for property testing. These libraries allow one to write logical assertions such as
\[ \forall e_1, e_2. \haskell{equivalent $e_1$ $e_2$} = \haskell{Right ()}
   \implies \forall w. \haskell{matches $e_1$ $w$} = \haskell{matches $e_2$ $w$}
 \]
and verifies these assertions by instantiating them with concrete terms. QuickCheck randomly generates a fixed number of examples whereas SmallCheck systematically generates \emph{all} inputs. I use QuickCheck to test against a large alphabet (Unicode characters), and SmallCheck to tests against a very small alphabet with three characters. SmallCheck was very helpful for catching bugs at corner cases and generating simple counterexamples (since the alphabet is very small).

During random testing, I frequently ran into exponential behavior with functions \haskell{equivalent}, \haskell{intersection}, and \haskell{complement}. These operations have proven lower bounds \cite{Kozen77,GeladeN12} so occasional bad behavior is unavoidable, but the usual claim is that they fare much better on real-world inputs (see \cite{FosterKM0T15} for instance). It is interesting to note that this claim apparently does not extend to \emph{random} inputs. As a solution, I limit the size of randomly generated regular expressions to 4 or 5 operators which is sufficient to get high code coverage.

This was the first time I took testing seriously and it certainly paid off. I had been of the opinion that having the backing of a powerful type system like Haskell's and writing well-structured code would make it nigh impossible to introduce bugs. However, despite being extra careful and utilizing Haskell's type system to its fullest, I discovered half a dozen bugs during testing. On the plus side, I was able to focus on writing ``interesting'' tests thanks to Haskell's type system (users of untyped languages have to write hundreds of tests essentially asserting their program is well-typed). This goes on to show that type systems and testing go hand in hand.

\section{An Application: Unicode Grapheme Cluster Breaks}\label{application}

In this section, I briefly talk about the reason this library exists in the first place.

Unicode has become the de facto standard for international text. However, it is such a complicated beast that most people have misconceptions about how Unicode works. One of these misconceptions is the idea that each character you see on the screen corresponds to a single Unicode code point. This is a reasonable expectation since ``a'', ``!'', and ``$\Omega$'' are all Unicode code points. However, there are ``characters'' that require more than one Unicode code point to represent. For example, G with acute accent \'G requires two. Such a group of code points that represent a single user-perceived character is called a grapheme cluster.

Unicode strings are transmitted as flat sequences of code points, so breaking them up into their grapheme clusters might (and should) be a first step in any code that is to handle Unicode correctly. The Unicode standard gives a declarative specification of how this should be done\footnote{\url{http://unicode.org/reports/tr29}} using an ordered list of rules with the following two forms: $e_1 \times e_2$ meaning break at positions where the left-hand side matches $e_1$ and the right-hand side matches $e_2$, and $e_1 \div e_2$ meaning do not break at matching positions. When rules overlap, the first one in the list applies. The Unicode technical report claims without proof that these rules can be converted into a regular expression that can be used to extract grapheme clusters (by repeating a longest match for example).

I thought this was an interesting way to specify text segmentation rules, so I wanted to come up with an algorithm to do this translation for the general case. I had a translation in mind that used intersection and complement extensively, so I implemented this library to see the algorithm in action. Unfortunately, that algorithm was not correct, and fixing it is left for future work.

\section{Conclusion and Future Work}
  I presented a regular expressions library for Haskell that implements very well-known theoretical results that somehow never made their appearance in popular tools. As always, some work remains to be done. First, there is significant room for optimization.  My implementation of sparse vectors and sparse matrices could use a lot of work, and suppressing Haskell's default lazy semantics in computation heavy regions might lead to significant speedups. Second, I would like to implement DFA minimization and use it to simplify regular expressions generated by \haskell{intersection} and \haskell{complement} operations. Normalizing regular expressions already simplifies them quite a bit, and going through DFAs using Brzozowski derivatives generally produces readable (and perhaps even minimal) expressions, but there are cases where the output is quite hairy. I'm hoping minimizing DFAs could remedy this situation. Finally, the interface could use some work. The code is modularized in a way that makes sense from the implementer's perspective, but it is not the interface that should be exposed to the user.

%=====================================================================
% Bibliography
%=====================================================================

\bibliographystyle{acm}
\bibliography{bibliography,bibliography-extra}

\end{document}


% This is the results section og the report on homework-2.
% Author(s) : Vivek Kumar / Victor Charpentier
% Last Updated : 04/03/2018
%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Results and Discussion}
The first result we present is that of cross-validation performed on the split data to determine the best for each prediction. The total train data (obtained from {\ttfamily train.csv}) was divided randomly into a 50:50 split. The cross-validation score chosen for comparison was mean-squared-error (MSE). The results for each are displayed in Table [\ref{tab:mse_cross_continuous}].
\begin{table}[H]
\centering
	\begin{tabular}{|c|c|c|c|}
	\hline
	Method & GPA MSE & Grit MSE & Material Hardship MSE\\
	\hline
	Random Forest Regressor	&	0.221031	&	0.153470	&	0.015116	\\
	AdaBoost Regressor		&	0.250311	&	0.156094	&	0.017874	\\
	LassoLarsCV				&	0.232776	&	0.153386	&	0.016869	\\
	ElasticNet				&	0.379290	&	0.252420	&	0.017385	\\
	Extra Trees Regressor		&	0.219626	&	0.162074	&	0.016035	\\
	MLP Regressor			&	157140	&	190226	&	305336	\\
	\hline
	\end{tabular}
	\caption{Mean-Squared-Error score for various methods obtained in cross-validation for continuous variables}
	\label{tab:mse_cross_continuous}
\end{table}
\vspace{-10pt}
\begin{table}[H]
\centering
	\begin{tabular}{|c|c|c|c|}
	\hline
	Method & Eviction MSE & Layoff MSE & Job Training MSE\\
	\hline
	Quadratic Discriminant Analysis	&	0.053004	&	0.119698	&	0.163054	\\
	Random Forest Classifier		&	0.042568	&	0.101568	&	0.122916	\\
	Adaboost Classifier				&	0.200811	&	0.224494	&	0.230679	\\
	MLP Classifier				&	0.051826	&	0.232274	&	0.232747	\\
	ExtraTreesRegressor		&	0.041886	&	0.102059	&	0.123275	\\
	\hline
	\end{tabular}
	\caption{Mean-Squared-Error score for various methods obtained in cross-validation for discrete variables}
	\label{tab:mse_cross_discrete}
\end{table}
Using the best method the leaderboard scores were :
\begin{align*}
\mathrm{GPA \ Score \ :} \ 0.36792  && \mathrm{Grit \ Score \ :} \ 0.21894  && \mathrm{Material \ Hardship \ Score \ :} \ 0.02531
\end{align*}
The bootstrapping was performed on the training data set to determine the minimum and maximum error obtained for each prediction. Here we have used RandomForestRegressor as the method for predicting the results. The results are plotted in the Figure [\ref{fig:bootstrapping}]. These results clearly show that there are multiple cases when the method is expected to fail. These cases, could be identified and further studied. The cases could be used to further train a more deep training data, say a neural network.\\
\begin{figure}[H]
\centering
\includegraphics[width=0.8\textwidth]{bootstrapping}
\caption{Bootstrapping results}
\label{fig:bootstrapping}
\end{figure}
Further to understand, which features were most important the {\ttfamily mutual\_info\_regression} from {\ttfamily feature\_seclection} of sklearn was used. The plot shows the mutual information between each feature and the target prediction shown in Figure [\ref{fig:mutual_info}]
\begin{figure}[H]
\centering
\includegraphics[width=0.49\textwidth]{feature_selection_gpa_scores}
\includegraphics[width=0.49\textwidth]{feature_selection_grit_scores}
\includegraphics[width=0.49\textwidth]{feature_selection_hardship_scores}
\caption{Mutual Information Score for various parameters to predict}
\label{fig:mutual_info}
\end{figure}
We also employed the principal component analysis (PCA) for dimension-reduction. Instead of showing the individual results we compare how the methods performed when various feature selection or dimension reduction techniques were employed. Based on the figure [\ref{fig:mutual_info}] the mutual info score cutoff was set at 0.1. For PCA the features were selected so as to explain 99\% of the variance.
\begin{table}[H]
\centering
	\begin{tabular}{|c|c|c|c|}
	\hline
	Method & None & Mutual Info ($>$ 0.1) & PCA(99\% variance)\\
	\hline
	RandomForestRegressor	&	0.221031	&	0.226496	&	0.239838	\\
	AdaBoostRegressor		&	0.250311	&	0.240569	&	0.279977	\\
	LassoLarsCV				&	0.232776	&	0.233773	&	0.241419	\\
	ElasticNet				&	0.379290	&	0.245301	&	0.241284	\\
	ExtraTreesRegressor		&	0.219626	&	0.223951	&	0.239640	\\
	MLPRegressor			&	157140	&	51837	&	4.548522	\\
	\hline
	\end{tabular}
	\caption{Mean-Squared-Error score for GPA with and without dimension reduction/ feature-selection}
\end{table}


\section{Experimental Evaluation}
\label{sec:Eval}

This section presents experiments to evaluate how much running time costs in terms of performance. The experiments will show that, in practice, \dyntset is faster by a factor of $O(\log n)$ per operation than that of the theoretical analysis (Section\ref{sec:TechDes}).

This section is organised as follows. Firstly, we describe the experimental setup. Secondly, a brief description in the implementation of test sets is provided. We then present experimental studies of the three different operations in \dyntset. Finally, we present an additional experiment for the cases where laziness as speeding up factor in favor of the running times for the dynamic tree operations.

\subsection{Experimental Setup}
Functions \link, \cut, \conn, \code{root} and \code{reroot} were implemented by the author in Haskell and compiled with \code{ghc} version 8.0.1 with optimisation \code{-O2}. The experiments were performed on a 2.2 GHz Intel Core i7 MacBook Pro with 16 GB 1600 MHz DDR3 running macOS High Sierra version 10.13.1 (17B1003). We imported the following libraries into our code from the online package repository Hackage: \cite{HaskellFT} code for finger trees, \cite{HaskellSet} for conventional sets and \cite{HaskellEdison} for lazy sets.

The running time of a given computation was determined by the mean of three executions.

\subsection{Data structure}

The values maintained by the data structures (sets and finger trees) are stored as fixed-precision \code{Int} types, holding values from $-2^{29}$ up to $2^{28}$ although we test only the positive values.

The structures are initialized with a fixed number of nodes (or vertices) $n$; this number does not change during the execution. This allow us to know the initial size of the forest and we subtract it from the benchmarking.

Since \dyntset is not called by any application, the random generation of nodes for \link or \cut does not necessarily be effective. Actually, around 70\% of the generated nodes $x$ and $y$ passed to \link and \cut were not valid, that is, their result turned out to be the original forest. In order to overcome this, we stored the random generated nodes that were effective into a plain files and from there benchmarking the dynamic tree operations.

\subsection{Incremental operations}
We start with an empty forest (just singleton-trees); given $n=20,000$ nodes we perform $1 \ldots 20,000$ \link operations. Upon reaching a target length, we plot the total time taken. Then, we divide the time taken by the number of operations to calculate the time per operation and then multiply it by a constant (x1000) to make the curve visible in the same chart.

\begin{figure}[H]
\begin{center}
\includegraphics[scale=0.4]{./Images/plotLink}
\end{center}
\caption{Sequence of {\link}s from empty forest up to a single tree in such forest}
\label{fig:incLink}
\end{figure}

\textit{\emph{Results}}. The behaviour of the curve regarding the time per \link operation shows that in practice it takes $O(1)$ against $O(\log n^2)$ in theory back in Section~\ref{sec:TechDes}, or the linear behaviour by the \link operations in bulk.

\subsection{Fully dynamic operations}
We start with the incremental process as before for $n=10,000$. Then, for \cut we start in the opposite direction, that is, cutting from a single tree in the forest until only singleton-trees remain in such forest. To this performance we subtract the time take for the incremental bit. For \conn performance we compute first an interleaved operation of \link and \cut (not necessarily in this order). We measure the time taken for \conn followed by the corresponding \link or \cut and then we subtract the interleaved process. The following figures show our three dynamic operations in bulk and per operation.

\begin{figure}[H]
\centering
\begin{subfigure}{.5\textwidth}
  \centering
  \includegraphics[scale=0.38]{./Images/plotEach}
  \caption{In bulk}
%  \label{fig:sub1}
\end{subfigure}%
\begin{subfigure}{.5\textwidth}
  \centering
  \includegraphics[scale=0.38]{./Images/plotOpsIndiv}
  \caption{Per operation}
%  \label{fig:sub2}
\end{subfigure}
\caption{Time taken by operation, and interleaved \link and \cut}
\label{fig:EachOp}
\end{figure}

\textit{\emph{Results}}. We observe that \cut and \conn obey the same pattern as \link. That is, $O(1)$ time per operation being \textit{connectivity} the fastest of the dynamic tree operations, as expected.

From the above analyses, we notice that \link performs better when is interleaved with \cut. To see this behaviour closer, we present the bulk and individual cases in the following charts varying the forest size under the same amount of operations.

\begin{figure}[H]
\centering
\begin{subfigure}{.5\textwidth}
  \centering
  \includegraphics[scale=0.38]{./Images/plotForests}
  \caption{In bulk}
%  \label{fig:sub1}
\end{subfigure}%
\begin{subfigure}{.5\textwidth}
  \centering
  \includegraphics[scale=0.38]{./Images/plotLCForests}
  \caption{Per operation}
%  \label{fig:sub2}
\end{subfigure}
\caption{Time taken when \link and \cut are interleaved with different forest sizes}
\label{fig:EachOp}
\end{figure}

\subsection{Selection of the set data structure}
The set-like data structure is crucial in our implementation and testing of \dyntset since is the search engine for the nodes when any operation is applied to a forest. There are plenty of implementations for such set-like structure, mostly as binary balanced search trees. In our case, where Haskell is a lazy-evaluation language by default, we select two main choices to compare: \code{Data.Set} which is a strict data type definition and \code{Data.Edison.Coll.LazyPairingHeap} which is semi-lazy or semi-strict data type. The following figure shows the performance for each.

\begin{figure}[H]
\begin{center}
\includegraphics[scale=0.4]{./Images/plotSets}
\end{center}
\caption{Dynamic operations through different sets structures as monoidal annotations}
\label{fig:plotSets}
\end{figure}

The above curves show that, although by a constant factor, laziness speeds up the running time in the computation of dynamic tree operations through the set-like data structures.

\tcb{Amortised over what??}


\section{Time Integration} \label{se:TimeIntegration}

Suppose that an algebraic closure based on Fermi-Dirac statistics is used (i.e., the Eddington factor satisfies Eq.~\eqref{eq:eddingtonFactorBounds}).
Here we consider the construction of an Implicit-Explicit (IMEX) time integration scheme that maintains the bounds in Eq.~\eqref{eq:MomentsBounds}.
The semi-discretization of the two-moment model results in a system of ordinary differential equations of the form
\begin{equation}
  \dot{\vect{u}} = \vect{\cT}(\vect{u}) + \vect{\cQ}(\vect{u}),
\end{equation}
where the solution vector
\begin{equation}
  \vect{u}(t) = \left( \bcM_{1}(t),\ldots,\bcM_{N}(t)\right) ^{T}
\end{equation}
is the collection of all cell-averaged moments, $\vect{\cT}$ is the transport operator, corresponding to the first term on the right-hand side of Eq.~\eqref{eq:SemiDiscretizatedMomentEquation}, and $\vect{\cQ}$ is the collision operator, corresponding to the second term on the right-hand side of Eq.~\eqref{eq:SemiDiscretizatedMomentEquation}.

Since the set of realizable moments is convex, convex-invariant schemes, which map the initial values into this set, can be used to design realizability-preserving methods for the two-moment model.
Ideally, the scheme should also be high-order accurate and work well in the asymptotic diffusion limit (characterized by frequent collisions and long time scales).
The following discussion considers the construction of such convex-invariant schemes.

\subsection{Standard IMEX Schemes}

Treating the transport operator explicitly and the collision operator implicitly, a standard $s$-stage IMEX scheme takes the following form~\cite{pareschiRusso_2005}:
\begin{align}
  \vect{u}^{(i)}
  &=\vect{u}^{n}
  +\dt\sum_{j=1}^{i-1}\tilde{a}_{ij}\,\vect{\cT}(\vect{u}^{(j)})
  +\dt\sum_{j=1}^{i}a_{ij}\,\vect{\cQ}(\vect{u}^{(j)}),
  \quad i=1,\ldots,s, \label{imexStages} \\
  \vect{u}^{n+1}
  &=\vect{u}^{n}
  +\dt\sum_{i=1}^{s}\tilde{w}_{i}\,\vect{\cT}(\vect{u}^{(i)})
  +\dt\sum_{i=1}^{s}w_{i}\,\vect{\cQ}(\vect{u}^{(i)}), \label{imexIntermediate}
\end{align}
where $(\tilde{a}_{ij})$ and $(a_{ij})$, coefficients of the $i$-th stage, are elements of matrices $\tilde{A}$ and $A$, respectively.
The matrices $\tilde{A}$ and $A$ are lower triangular.
($\tilde{A}$ is strictly lower triangular so that the transport part is explicit.)
The vectors $\tilde{\vect{w}}=(\tilde{w}_{1},\ldots,\tilde{w}_{s})^{T}$ and $\vect{w}=(w_{1},\ldots,w_{s})^{T}$ are the weights in the assembly step in Eq.~\eqref{imexIntermediate}.
These coefficients and weights must satisfy certain order conditions for consistency, accuracy, and other properties.
For second-order temporal accuracy, the following conditions are required~\cite{hairer_1981}:
\begin{equation}
  \sum_{i=1}^{s}\tilde{w}_{i}=\sum_{i=1}^{s}w_{i}=1,
  \label{orderConditions1}
\end{equation}
and
\begin{equation}
  \sum_{i=1}^{s}\tilde{w}_{i}\,\tilde{c}_{i}
  =\sum_{i=1}^{s}\tilde{w}_{i}\,c_{i}
  =\sum_{i=1}^{s}w_{i}\,\tilde{c}_{i}
  =\sum_{i=1}^{s}w_{i}\,c_{i}=\f{1}{2},
  \label{orderConditions2}
\end{equation}
where $\tilde{c}_{i} = \sum_{j=1}^{s}\tilde{a}_{ij}$ and $c_{i}=\sum_{j=1}^{s}a_{ij}$.

The IMEX scheme is called globally stiffly accurate (GSA) if the coefficients satisfy~\cite{dimarcoPareschi2013}:
\begin{equation}
  a_{si}=w_{i} \quad\text{and}\quad \tilde{a}_{si}=\tilde{w}_{i}, \quad \text{for} \quad i=1,\ldots,s.
\end{equation}
Then, $\vect{u}^{n+1} = \vect{u}^{(s)}$, which is simplifying because the assembly step in Eq.~\eqref{imexIntermediate} is omitted.
IMEX schemes are further classified by the structure of the implicit matrix $A$.
If $A$ is invertible, the IMEX scheme is of type~A~\cite{pareschiRusso_2005}.
If $a_{i1} = 0$ for $i=1,\ldots,s$, $w_{1} = 0$, and the submatrix consisting of the last $s-1$ rows and columns is invertible, the IMEX scheme is of type~ARS~\cite{ascher_etal_1997,pareschiRusso_2005}.

\subsection{Convex-Invariant IMEX Schemes}

To be convex-invariant, the coefficients and weights defining the IMEX scheme must satisfy additional constraints.
Our goal is to find constraints on $a_{ij}$, $\tilde{a}_{ij}$, $\tilde{w}_{i}$, and $w_{i}$ that enable each $\vect{u}^{(i)}$ in Eq.~\eqref{imexStages} to be expressed as a convex combination of realizable states.
Following Hu et al.~\cite{hu_etal_2018}, the stage values in Eq.~\eqref{imexStages} can be rewritten as
\begin{equation}
  \vect{u}^{(i)}
  =\sum_{j=0}^{i-1}c_{ij}\Big[\,\vect{u}^{(j)}+\hat{c}_{ij}\,\dt\,\vect{\cT}(\vect{u}^{(j)})\,\Big] + a_{ii}\,\dt\,\vect{\cQ}(\vect{u}^{(i)}),\quad i=1,\ldots,s,
  \label{eq:imexStagesRewrite}
\end{equation}
where $c_{ij}$ and $\hat{c}_{ij}\equiv\tilde{c}_{ij}/c_{ij}$ are defined in terms of $a_{ij}$ and $\tilde{a}_{ij}$.
For IMEX schemes of type~ARS, $c_{ij}$ and $\tilde{c}_{ij}$ are given by~\cite{hu_etal_2018}
    \begin{equation}
     \begin{aligned}
      c_{i0} &= 1-\sum_{j=2}^{i-1}\sum_{l=j}^{i-1}a_{il}b_{lj}, \quad &
      c_{ij} &= \sum_{l=j}^{i-1}a_{il}b_{lj}, \\
      \tilde{c}_{i0} &= \tilde{a}_{i1}+\sum_{j=2}^{i-1}a_{ij}\tilde{b}_{j1}, \quad &
      \tilde{c}_{ij} &= \tilde{a}_{ij}+\sum_{l=j+1}^{i-1}a_{il}\tilde{b}_{lj},
     \end{aligned}
     \label{eq:positivityCoefficientsARS}
    \end{equation}
    \begin{equation}
      b_{ii} = \f{1}{a_{ii}}, \quad
      b_{ij} = -\f{1}{a_{ii}}\sum_{l=j}^{i-1}a_{il}b_{lj}, \quad
      \tilde{b}_{ij} = -\f{1}{a_{ii}}\Big(\tilde{a}_{ij}+\sum_{l=j+1}^{i-1}a_{il}\tilde{b}_{lj}\Big).
    \end{equation}
Note that $c_{i1}=\tilde{c}_{i1}=0$ in Eq.~\eqref{eq:positivityCoefficientsARS}, so that $\sum_{j=0}^{i-1}c_{ij}=1$.

If the IMEX scheme is GSA, $\vect{u}^{n+1} = \vect{u}^{(s)}$.
Moreover, if $c_{ij},\tilde{c}_{ij}\ge0$ and $a_{ii}>0$, each stage in Eq.~\eqref{eq:imexStagesRewrite} is a convex combination of explicit Euler steps (with time step $\hat{c}_{ij}\dt$), followed by an implicit Euler step.
Each of the explicit Euler steps has a time step condition that ensures its realizability given by $\hat{c}_{ij}\,\dt\leq\dx$; the CFL condition of the scheme.
Using results proved in~\cite{chu_etal_2018} and discussed in Section~\ref{se:SpatialDiscretization}, the IMEX scheme is convex-invariant and realizability-preserving for the two-moment model in Section~\ref{se:SpatialDiscretization} provided
\begin{equation}
  \max(\hat{c}_{ij})\,\dt \leq \dx.
\end{equation}
(This CFL condition becomes more restrictive with high-order DG spatial discretization~\cite{chu_etal_2018}.)

\subsection{Diffusion Accurate, Convex-Invariant IMEX Schemes}

Accuracy in the diffusion limit is another important property to consider when an IMEX scheme is applied to the two-moment model.
In the diffusion limit, the distribution function is nearly isotropic, so $\vect{\cK}\approx\f{1}{3}\,\cJ\,\vect{I}$ and $\vect{\cH}\approx-\f{1}{3}\,\tau\,\nabla\cJ$, and the two-moment model is approximately governed by (e.g., \cite{jinLevermore_1996})
\begin{equation}
  \pd{\cJ}{t} + \nabla\cdot\vect{\cH} = 0
  \quad\text{and}\quad
  \vect{\cH} = - \tau\,\nabla\cdot\vect{\cK}.
  \label{eq:diffusionLimit}
\end{equation}
In the context of IMEX schemes, the above relationships imply that the following relations should hold~\cite{chu_etal_2018}:
\begin{equation}
   \vect{e}_{i}^{T}A^{-1}\tilde{A}\,\vect{e} = 1, \quad i=1,\ldots,s,
   \label{diffusionAccuracy}
\end{equation}
where $\vect{e}_{i}$ is the $i$th column of the $s\times s$ identity matrix, $\vect{e}$ is the vector of ones, and $A$ and $\tilde{A}$ are the matrices of the coefficients $(\tilde{a}_{ij})$ and $(a_{ij})$.
Eq.~\eqref{diffusionAccuracy} implies:
\begin{equation}
  c_{i} = \tilde{c}_{i}, \quad i=1,\ldots,s.
\end{equation}
We have proved in \cite{chu_etal_2018} that only IMEX schemes of type~ARS can be both diffusion accurate and convex-invariant.
(Another short proof follows from the fact that IMEX schemes of type~A have $\tilde{c}_1 = 0$ while $c_i \neq 0$.)

\subsection{PD-ARS IMEX schemes}

Unfortunately, coefficients satisfying the order conditions in Eqs.~\eqref{orderConditions1}-\eqref{orderConditions2} and the conditions for convex-invariance do not exist for the standard IMEX scheme in Eqs.~\eqref{imexStages}-\eqref{imexIntermediate}, unless a small time step is invoked that makes the scheme essentially explicit.
To circumvent this problem, correction steps can be introduced after the assembly step in Eq.~\eqref{imexIntermediate} (e.g., \cite{chertock_etal_2015,hu_etal_2018}).
However, the correction steps can impose time step constraints for realizability or accuracy in the diffusion limit that ruin the efficiency gains expected from the IMEX scheme.
Because of this, we sacrifice overall high-order accuracy, and aim for IMEX schemes that are high-order accurate in the streaming limit, diffusion accurate, and convex-invariant.
Combining these requirements we seek GSA IMEX schemes of type~ARS with coefficients satisfying the following constraints~\cite{hu_etal_2018,chu_etal_2018}:
\begin{enumerate}
    \item Consistency of the implicit coefficients:
    \begin{equation}
      \sum_{i=1}^{s}w_{i}=1.
    \end{equation}
    \item High-order accuracy in the streaming limit.
    For second-order accuracy:
    \begin{equation}
      \sum_{i=1}^{s}\tilde{w}_{i}=1
      \quad\text{and}\quad
      \sum_{i=1}^{s}\tilde{w}_{i}\,\tilde{c}_{i}=\f{1}{2}.
      \label{eq:orderConditionsEx}
    \end{equation}
    For third-order accuracy:
    \begin{equation}
    \sum_{i=1}^{s}\tilde{w}_{i}=1,
          \quad
          \sum_{i=1}^{s}\tilde{w}_{i}\,\tilde{c}_{i}=\f{1}{2},
          \quad
          \sum_{i=1}^{s}\tilde{w}_{i}\,\tilde{c_{i}}^2 = \f{1}{3}
          \quad\text{and}\quad
          \sum_{i=1}^{s}\tilde{w}_{i}\,\tilde{a_{ij}}\tilde{c}_{j}= \f{1}{6}.
    \end{equation}
    \item Diffusion accuracy:
    \begin{equation}
      c_{i}=\tilde{c}_{i}, \quad i=1,\ldots,s.
      \label{eq:diffusionCondition}
    \end{equation}
    \item Convex-invariance:
    \begin{align}
      &a_{ii}>0, \quad c_{i0},\tilde{c}_{i0}\ge0, \quad \text{for} \quad i=2,\ldots,s, \nonumber \\
      &\text{and} \quad c_{ij},\tilde{c}_{ij}\ge0, \quad \text{for} \quad i=3,\ldots,s, \quad\text{and}\quad j=2,\ldots,i-1,
      \label{eq:convexInvariant}
    \end{align}
    with $\sum_{j=0}^{i-1}c_{ij}=1$, for $i=1,\ldots,s$, and $c_{\Sch}:=\min_{\substack{i = 2,\ldots,s \\
                  j = 0,2,\ldots,i-1}}\,\f{1}{\hat{c}_{ij}}>0$.

    (Note that the greater the $c_{\Sch}$, the larger the time step can be.
    And $c_{\Sch} \leq 1$.)
    \item Having less than five stages ($s\le4$)\label{cod:statges}.
    \item Are globally stiffly accurate: $a_{si}=w_{i}$ and $\tilde{a}_{si}=\tilde{w}_{i},\quad i=1,\ldots,s$.
\end{enumerate}
Fortunately, these IMEX schemes are easy to find.
(The constraint in \eqref{cod:statges} is introduced from efficiency considerations to limit the number of implicit solves.)
We call the IMEX schemes satisfying the above conditions {PD-ARS} (see also Definition~3 in~\cite{chu_etal_2018}), and we provide two optimal PD-ARS schemes below: PD-ARS2 and PD-ARS3, each limiting to the optimal second-order and third-order SSPRK schemes from~\cite{shuOsher_1988}, respectively.
\subsubsection{PD-ARS2}

The optimal 3-stage PD-ARS, PD-ARS2, in the standard double Butcher tableau form, with explicit tableau ($\tilde{A}$) on the left and implicit tableau ($A$) on the right, is given by
\begin{align}
  &\begin{array}{c | c c c}
  	0 & 0   & 0 & 0 \\
  	1 & 1   & 0 & 0 \\
  	1 & 1/2 & 1/2 & 0 \\ \hline
  	  & 1/2 & 1/2 & 0
  \end{array}
  \qquad
  \begin{array}{c | c c c}
  	0 & 0 & 0            & 0            \\
  	1 & 0 & 1            & 0            \\
  	1 & 0 & 1/2 & 1/2 \\ \hline
  	  & 0 & 1/2 & 1/2
  \end{array}
\end{align}
Note its explicit tableau is SSPRK2.
For this scheme, only two implicit solves are needed per time step and $c_{\Sch}= 1$, which implies that the time step restriction for preserving moment realizability is only due to the explicit part.

\subsubsection{PD-ARS3}

The optimal 4-stage PD-ARS, PD-ARS3, is given in its standard double Butcher tableau form (explicit tableau on the left and implicit tableau on the right) by
\begin{align}
  &\begin{array}{c | c c c c}
  	    &     &     &     &  \\
  	 1  & 1   &     &     &  \\
  	1/2 & 1/4 & 1/4 &  \\
  	 1  & 1/6 & 1/6 & 2/3 &  \\ \hline
  	    & 1/6 & 1/6 & 2/3 &
  \end{array}
  \qquad
  \begin{array}{c | c c c c}
  	0 & 0 & 0            & 0            \\
  	1 & 0 & 1            & 0            \\
  	1/2 & 0 & 1/4 & 1/4 \\
  	1 & 0 & 1/6 & 1/6 & 2/3\\\hline
  	  & 0 & 1/6 & 1/6 & 2/3
  \end{array}
\end{align}
Its explicit tableau is SSPRK3.
This scheme requires three implicit solves per time step, and $c_{\Sch}= 1$.
Since PD-ARS3 is not more accurate than PD-ARS2 in collision-dominated regions (see our results in Section~\ref{se:NumericalTests}), it may not offer any practical advantage over PD-ARS2.


\input{wpg03_notation_define.tex}

%%%
\chapter{WPG v.03: WPG considering external forces}

\gbox{
    \red{Warning:}
    This module is unsupported -- the documentation may contain errors. Refer
    to \cite{Agravante2016preprint} and \cite{Agravante2016icra} for more
    information.
}

This version of the pattern generator is based on a model that considers external forces.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Model}
Separating the coplanar contact forces $\fCoplanar$ and an external wrench in the CoM frame:
$[\fExt^\top ~ \tExt^\top]^\top$, the equations of motion are:

\begin{align}
 m(\comA + \gravity) &= \fExt + \sum_i \fCoplanar  \\
 \momAngD &= \tExt + \sum_i (\pCoplanar - \comP) \times \fCoplanar
\end{align}

By following the derivations:
\begin{equation}
 m \comP \times (\comA + \gravity) + \momAngD - \tExt - (\comP \times \fExt)
 =
 \sum_i \pCoplanar \times \fCoplanar
\end{equation}

Dividing to get the Center of Pressure expression on the right hand part:
\begin{equation}
 \frac{m \comP \times (\comA + \gravity) + \momAngD - \tExt - (\comP \times \fExt) }
 {m(\ddot{c}^z + g^z) - f_{ext}^z}
 =
 \frac{\sum_i \pCoplanar \times \fCoplanar}
 {\sum_i f_i^z}
\end{equation}

For a flat ground $p_i^z = 0$ and $\gravity^{x,y} = \mathbf{0}$ and using the approximations: $\ddot{c}^z = 0$ and $\momAngD = 0$ the ZMP in the
plane is:
\begin{equation}
 \zmp^{x,y}
 =
 \frac{\sum_i f^z_i \pCoplanar^{x,y}}{\sum_i f_i^z}
 =
 \left( \frac{m g^z}{m g^z - f^z_{ext}} \right)
 \left( \comP^{x,y} - \frac{c^z}{g^z} \comA^{x,y} \right)
 -
 \mathbf{S}
 \left( \frac{\tExt^{x,y} + (\comP \times \fExt)^{x,y} }{mg^z - f^z_{ext}} \right)
\end{equation}
where
\begin{equation}
 \mathbf{S} =
 \begin{bmatrix}
  0 & -1 \\
  1 & 0
 \end{bmatrix}
\end{equation}

Developing further:

\begin{equation}
 \zmp^{x,y}
 =
 \left( \frac{m g^z}{m g^z - f^z_{ext}} \right)
 \left( \comP^{x,y} - \frac{c^z}{g^z} \comA^{x,y} \right)
 -
 \mathbf{S}
 \left( \frac{\tExt^{x,y} }{mg^z - f^z_{ext}} \right)
 -
 \left( \frac{\comP^{x,y}\fExt^z - \comP^z\fExt^{x,y}}{mg^z - f^z_{ext}} \right)
\end{equation}

Grouping the terms:
\begin{equation}
 \zmp^{x,y}
 =
 \left( \comP^{x,y} - \left( \frac{c^z}{g^z} \right) \left( \frac{m g^z }{m g^z - f^z_{ext}} \right) \comA^{x,y}  \right)
 -
 \mathbf{S}
 \left( \frac{\tExt^{x,y} }{mg^z - f^z_{ext}} \right)
 +
 \left( \frac{\comP^z\fExt^{x,y}}{mg^z - f^z_{ext}} \right)
\end{equation}

\section{MPC}
The model in $x$ is:
\begin{equation}
 \begin{bmatrix}
 \dot{c}^x \\
 \ddot{c}^x \\
 \dddot{c}^x
 \end{bmatrix}
 =
 \begin{bmatrix}
  0 & 1 & 0 \\
  0 & 0 & 1 \\
  0 & 0 & 0
 \end{bmatrix}
 \begin{bmatrix}
 c^x \\
 \dot{c}^x \\
 \ddot{c}^x
 \end{bmatrix}
 +
 \begin{bmatrix}
 0 \\
 0 \\
 1
 \end{bmatrix}
 \dddot{c}^x
\end{equation}

\begin{equation}
 z^x
 =
 \begin{bmatrix}
 1 &
 0 &
 -\frac{m g^z}{(m g^z - f^z_{ext} ) \omega^2}
 \end{bmatrix}
 \begin{bmatrix}
 c^x \\
 \dot{c}^x \\
 \ddot{c}^x
 \end{bmatrix}
 +
 \frac{n^y_{ext} + c^z f^x_{ext}}{mg^z - f^z_{ext}}
\end{equation}

Rewriting:
\begin{equation}
 \begin{bmatrix}
 \dot{c}^x \\
 \ddot{c}^x \\
 \dddot{c}^x
 \end{bmatrix}
 =
 \begin{bmatrix}
  0 & 1 & 0 \\
  0 & 0 & 1 \\
  0 & 0 & 0
 \end{bmatrix}
 \begin{bmatrix}
 c^x \\
 \dot{c}^x \\
 \ddot{c}^x
 \end{bmatrix}
 +
 \begin{bmatrix}
  0 \\
  0 \\
  1
 \end{bmatrix}
 \dddot{c}^x
\end{equation}

\begin{equation}
 z^x
 =
 \begin{bmatrix}
  1 &
  0 &
  -\frac{m g^z}{(m g^z - f^z_{ext} ) \omega^2}
 \end{bmatrix}
 \begin{bmatrix}
 c^x \\
 \dot{c}^x \\
 \ddot{c}^x
 \end{bmatrix}
 +
 \begin{bmatrix}
  \frac{1}{m g^z - f^z_{ext}} &
  \frac{c^z}{m g^z - f^z_{ext}}
 \end{bmatrix}
 \begin{bmatrix}
  n^y \\
  f^x
 \end{bmatrix}
\end{equation}

The model is of the form
\begin{align}
 \mathbf{\dot{x}} &= \mathbf{A} \mathbf{x} + \mathbf{B} \mathbf{u} \\
 \mathbf{y} &= \mathbf{D} \mathbf{x} + \mathbf{G} \mathbf{f}
\end{align}

Discretization and concatenating the $x$ and $y$ DOFs leads to:
\begin{align}
 \cstate_{k+1}	=& \M{A}_k \cstate_k	  + \M{B}_k \mathbf{u}_k \\
 \cop_{k+1} 	=& \M{D}_{k+1} \cstate_{k+1} + \M{G}_{k+1} \mathbf{f}_{k+1} \\
		=& \M{D}_{k+1}\M{A}_k\cstate_{k} + \M{D}_{k+1}\M{B}_k \mathbf{u}_k + \M{G}_{k+1} \mathbf{f}_{k+1}
\end{align}
\begin{equation}
\M{A}_k =
\begin{bmatrix}
    1       & T_k   & T_k^2/2   & 0 & 0 & 0\\
    0       & 1     & T_k       & 0 & 0 & 0\\
    0       & 0     & 1         & 0 & 0 & 0\\
    0 & 0 & 0                   & 1       & T_k   & T_k^2/2   \\
    0 & 0 & 0                   & 0       & 1     & T_k       \\
    0 & 0 & 0                   & 0       & 0     & 1         \\
\end{bmatrix}
\quad
\M{B}_k =
\begin{bmatrix}
    T_k^3/6 & 0 \\
    T_k^2/2 & 0 \\
    T       & 0 \\
    0       & T_k^3/6 \\
    0       & T_k^2/2 \\
    0       & T
\end{bmatrix}
\end{equation}

\begin{equation}
\M{D}_{k} =
\begin{bmatrix}
    1 & 0 & -\frac{m g^z}{(m g^z - f^z_k ) \omega_k^2}
  & 0 & 0 & 0 \\

    0 & 0 & 0
  & 1 & 0 & -\frac{m g^z}{(m g^z - f^z_k ) \omega_k^2}  \\
\end{bmatrix}
\M{G}_{k} =
\begin{bmatrix}
  \frac{1}{m g^z - f^z_k}  & \frac{c^z_k}{m g^z - f^z_k} & 0 & 0 \\
  0 & 0 & -\frac{1}{m g^z - f^z_k}  & \frac{c^z_k}{m g^z - f^z_k}  \\
\end{bmatrix}
\end{equation}
\begin{equation}
 \omega_k = \sqrt{\frac{g}{c^z_k}}
 \quad
 \mathbf{u}_k =
 \begin{bmatrix}
  \dddot{c}^x_k \\
  \dddot{c}^y_k
 \end{bmatrix}
 \quad
 \mathbf{f}_k =
 \begin{bmatrix}
  n^y_k \\
  f^x_k \\
  n^x_k \\
  f^y_k
 \end{bmatrix}
\end{equation}

Condensing the model results in:
\begin{align}
    \begin{bmatrix}
        \cstate_1 \\
        \vdots\\
        \cstate_{N}\\
    \end{bmatrix}
    =&
    \M{U}_x \cstate_0
    +
    \M{U}_u
    \begin{bmatrix}
        \mathbf{u}_0 \\
        \vdots \\
        \mathbf{u}_{N-1} \\
    \end{bmatrix} \\
%
    \begin{bmatrix}
        \cop_1 \\
        \vdots \\
        \cop_{N} \\
    \end{bmatrix}
    =&
    \M{O}_x \cstate_0
    +
    \M{O}_u
    \begin{bmatrix}
        \mathbf{u}_0 \\
        \vdots \\
        \mathbf{u}_{N-1} \\
    \end{bmatrix}
    +
    \M{O}_f
    \begin{bmatrix}
        \mathbf{f}_1 \\
        \vdots \\
        \mathbf{f}_{N} \\
    \end{bmatrix} \\
\end{align}

or:
\begin{align}
    \cState
    =&
    \M{U}_x \cstate_0
    +
    \M{U}_u
    \dddot{\M{C}}\\
%
    \hat{\M{Z}}
    =&
    \M{O}_x \cstate_0
    +
    \M{O}_u
    \dddot{\M{C}}
    +
    \M{O}_f
    \hat{\M{F}}\\
\end{align}

expressing the ZMP to local coordinates:
\begin{align}
    \cState
    =&
    \M{U}_x \cstate_0
    +
    \M{U}_u
    \dddot{\M{C}}\\
%
    \left(
        \M{V}_0 \fp_0
        +
        \M{V} \FP
        +
        \diag{k = 1 \dots N}{\M[\hat{p}_k][]{R}}
        \CoP
    \right)
    =&
    \M{O}_x \cstate_0
    +
    \M{O}_u
    \dddot{\M{C}}
    +
    \M{O}_f
    \hat{\M{F}}\\
\end{align}

rearranging and grouping the unknowns: $\dddot{\M{C}}$ and $\FP$
\begin{align}
    \cState
    =&
    \underbrace{
    \begin{bmatrix}
        \M{U}_u    &   \M{0} \\
    \end{bmatrix}
    }_{\M{S}}
    \underbrace{
    \begin{bmatrix}
        \dddot{\M{C}}\\
        \FP\\
    \end{bmatrix}
    }_{\V{X}}
    +
    \underbrace{
    \M{U}_x \cstate_0
    }_{\V{s}}\\
%
    \CoP
    =&
    \underbrace{
    \begin{bmatrix}
        \diag{k = 1 \dots N}{\M[\hat{p}_k][]{R}^\top} \M{O}_u    &
       -\diag{k = 1 \dots N}{\M[\hat{p}_k][]{R}^\top} \M{V} \\
    \end{bmatrix}
    }_{\M{S}_{z}}
    \underbrace{
    \begin{bmatrix}
        \dddot{\M{C}}\\
        \FP\\
    \end{bmatrix}
    }_{\V{X}}
    +
    \underbrace{
    \diag{k = 1 \dots N}{\M[\hat{p}_k][]{R}^\top}
    \left(
    \M{O}_x \cstate_0
    +
    \M{O}_f \hat{\M{F}}
    -
    \M{V}_0 \fp_0
    \right)
    }_{\V{s}_{z}}\\
\end{align}

The CoM velocity is:
\begin{equation}
    \cVel =
        \diag{N}{\M{I}_{v}} \cState =
        \diag{N}{\M{I}_{v}} \left( \M{S}\V{X} + \V{s} \right)=
        \M{S}_v \V{X} + \V{s}_v
\end{equation}

\section{QP}
The Constraints are:

CoP positions
\begin{align}
  \ubarV{Z} \le \CoP \le \barV{Z} \\
  \ubarV{Z} \le \M{S}_{z} \V{X} + \V{s}_{z} \le \barV{Z}
\end{align}

Foot positions
\begin{equation}
  \ubarV{P} \le \FP \le \barV{P}
\end{equation}

The Objectives are:

Tracking a reference velocity:
\begin{equation}
    \NORME{\cVel - \cVel_{ref}} = \NORME{\M{S}_v \V{X} + \V{s}_v - \cVel_{ref}},
\end{equation}

Minimize CoM jerk:
\begin{equation}
    \NORME{\dddot{\M{C}}},
\end{equation}

Minimize the distance between the CoP positions and the centers of the feet
\begin{equation}
    \NORME{\CoP} = \NORME{\M{S}_{z} \V{X} + \V{s}_{z}}.
\end{equation}

\section{General notes on the external wrench term}

\subsection{Prediction of future values}
Knowledge of future forces and torques $f^x, f^y, n^x, n^y$ is required in the vector $\hat{\M{F}}$ and $f^z$ in the matrices $\M{D}_{k}, \M{G}_{k}$
and consequently $\M{O}_{x}, \M{O}_{u}, \M{O}_{f}$. Note, $n^z$ was implicitly ignored during the modeling.

Here, we assume knowledge of the present wrench $\mathbf{h}_0$. So a prediction model is required to obtain $\mathbf{h}_1 \ldots \mathbf{h}_N$

Some simple models can be used (mostly for testing):

Constant throughout the preview horizon
\begin{equation}
 \mathbf{h}_1 = \mathbf{h}_2 = \ldots = \mathbf{h}_N = \mathbf{h}_0
\end{equation}

Linear
\begin{equation}
 \mathbf{h}_k = m k T_k +  \mathbf{h}_0
\end{equation}

Other prediction models are also presented in the specific use cases

\subsection{Frame of reference}
Note that the modeling placed the external wrench in the CoM frame. However, $\mathbf{h}_0$ may be expressed in another frame, the hand force sensor
frames for example. For this, the wrench transformation matrix $^{com}\M{H}^{ref}$ can be used:
\begin{equation}
 \mathbf{h}_k = {}^{com}\M{H}^{ref}_k ~^{ref}\mathbf{h}
\end{equation}

where:
\begin{equation}
  \M{H}
  =
  \begin{bmatrix}
  \M{R} & \M{0}\\
  [\mathbf{t}]_\times \M{R} & \M{R}
 \end{bmatrix}
\end{equation}

\section{Case 1: Solo-carrying an object}
For an object of known mass $m^{obj}$ and location (relative to the CoM), the external wrench is:
\begin{equation}
 \mathbf{h}_k
  =
 \begin{bmatrix}
  \M{I} & \M{0}\\
  [\mathbf{t}_k]_\times & \M{I}
 \end{bmatrix}
 \begin{bmatrix}
  0\\
  0\\
  m^{obj} g^z\\
  0\\
  0\\
  0
 \end{bmatrix}
 =
 \begin{bmatrix}
  0\\
  0\\
  m^{obj} g^z\\
  y_k m^{obj} g^z\\
 -x_k m^{obj} g^z\\
  0
 \end{bmatrix}
\end{equation}
where $x$ and $y$ are the distances between the 2 CoMs (object and robot)

In general:
\begin{equation}
 \mathbf{t}_k = {}^{rob}\mathbf{t}_k^{obj} = {}^w\mathbf{t}_k^{obj} - {}^{w}\mathbf{t}_k^{com}
\end{equation}

A first approximation is to assume $x_0, y_0$ from the current configuration remains constant.
\begin{equation}
 \mathbf{t}_1 = \mathbf{t}_2 = \ldots = \mathbf{t}_N = \mathbf{t}_0
\end{equation}

A better model might be to use: the future com positions from the model $\hat{\M{C}}$
\begin{equation}
    \cPos =
        \diag{N}{\M{I}_{p}} \cState =
        \diag{N}{\M{I}_{p}} \left( \M{S}\V{X} + \V{s} \right)=
        \M{S}_p \V{X} + \V{s}_p
\end{equation}

Along with this, knowledge of the future object position in the plane ${}^wx_k, {}^wy_k$ is required. If a trajectory is available, it can be used to
obtain
this.

Without having the object trajectory, one approximation is that the reference com velocity is
perfectly imparted on the object such that:
\begin{equation}
 \hat{\V{t}} =
 \begin{bmatrix}
  x_1 \\
  y_1 \\
  \vdots \\
  x_N \\
  y_N
 \end{bmatrix}
 =
 \begin{bmatrix}
  1 & 0 \\
  0 & 1 \\
  \vdots \\
  1 & 0 \\
  0 & 1 \\
 \end{bmatrix}
 \begin{bmatrix}
  x_0 \\
  y_0
 \end{bmatrix}
 +
 \diag{k = 1 \dots N}{k T_k} \cVel_{ref}
 -
 \M{S}_p \V{X} - \V{s}_p
\end{equation}

Finally, the external wrench vector required in the QP is:
\begin{equation}
 \hat{\V{F}}
 =
 \begin{bmatrix}
  n_1^y \\
  f_1^x \\
  n_1^x \\
  f_1^y \\
  \vdots \\
  n_N^y \\
  f_N^x \\
  n_N^x \\
  f_N^y
 \end{bmatrix}
 =
 \diag{N}{\begin{bmatrix}
           -1 & 0 \\
            0 & 0 \\
            0 & 1 \\
            0 & 0
          \end{bmatrix}}
 \hat{\V{t}}
 ~
 (m^{obj} g^z)
\end{equation}

This slightly changes the ZMP formulation for the QP since $\hat{\V{F}}$ is now a function of $\V{X}$

\section{Case 2: Collaborative-carrying}
% One general thing to exploit could be giving a meaning to the weights of the QP objectives. The external wrench term only appears in the CoP and
% there is already an objective where an external CoM velocity is given. Using these 2 tasks together can be seen as a form of damping control, with the
% ratio of these task weights the damping factor.

\subsection{As leader}
For leading, a clear and independent intention is necessary. However, a good leader still needs to account for what the follower is doing, this is
where the external wrench model comes in.

% often we use the reference CoM velocity $\cVel_{ref}$.
%
% Another idea is to add the external wrench as a decision variable of the QP, trying to track the result as a target force in the whole-body control
% part

\textbf{Idea 1: Reference trajectory tracking}

If a clear trajectory is known before hand, a better objective for the leader might be a ``trajectory tracking task'' instead of just a reference
velocity . This can be formulated as:
\begin{equation}
  \NORME{
  g_m(\cAcc_{ref} - \cAcc) +
  g_b(\cVel_{ref} - \cVel) +
  g_k(\cPos_{ref} - \cPos)
  }
\end{equation}
where $g_m, g_b, g_k$ are gains. To be concise, an appropriate gain matrix can be used:
\begin{equation}
  \NORME{
  \M{G}_{mbk}(\cState_{ref} - \cState)
  }
\end{equation}

\textbf{Idea 2: Wrench in the QP decision variables}

Another idea was to place the external wrench as a decision variable of the QP. This will result in:
\begin{align}
    \cState
    =&
    \underbrace{
    \begin{bmatrix}
        \M{U}_u    &   \M{0}  &   \M{0}\\
    \end{bmatrix}
    }_{\M{S}}
    \underbrace{
    \begin{bmatrix}
        \dddot{\M{C}}\\
        \FP\\
        \hat{\M{F}}
    \end{bmatrix}
    }_{\V{X}}
    +
    \underbrace{
    \M{U}_x \cstate_0
    }_{\V{s}}\\
%
    \CoP
    =&
    \underbrace{
    \begin{bmatrix}
        \diag{k = 1 \dots N}{\M[\hat{p}_k][]{R}^\top} \M{O}_u    &
       -\diag{k = 1 \dots N}{\M[\hat{p}_k][]{R}^\top} \M{V} &
	\diag{k = 1 \dots N}{\M[\hat{p}_k][]{R}^\top} \M{O}_f
    \end{bmatrix}
    }_{\M{S}_{z}}
    \underbrace{
    \begin{bmatrix}
        \dddot{\M{C}}\\
        \FP\\
        \hat{\M{F}}
    \end{bmatrix}
    }_{\V{X}}
    +
    \underbrace{
    \diag{k = 1 \dots N}{\M[\hat{p}_k][]{R}^\top}
    \left(
    \M{O}_x \cstate_0
    -
    \M{V}_0 \fp_0
    \right)
    }_{\V{s}_{z}}\\
\end{align}

As the force is part of the ZMP expression, this might allow the robot to balance itself by applying the appropriate forces. For
safety, the applied wrench may need to be constrained
\begin{equation}
  \hat{\ubarV{F}} \le \hat{\M{F}} \le \hat{\barV{F}}
\end{equation}

and/or minimized as:
\begin{equation}
  \NORME{\hat{\M{F}}}
\end{equation}

\subsection{As follower}
For following, the robot needs to act based on the leader's intention.

% To do this, we used to change the target reference $\cVel_{ref}$ as a function
% of the sensed force (a damping-based control). With the new model, it might be possible to do the same concept but using the QP weights.

\textbf{Idea 1: Impedance control objective}

It may be possible to do planar impedance control, first defining the selection matrix $\M{S}_{xy}$ to select only the $f^x, f^y$ components. The
impedance parameter matrix $\M{G}_{mbk}$ is defined similar to the trajectory tracking task gain.
\begin{equation}
  \NORME{
  \M{G}_{mbk}\cState -\M{S}_{xy}\hat{\M{F}}
  }
\end{equation}

This could replace the reference velocity objective and the external controller to compute this reference.

\textbf{Idea 2: Force prediction models}

A better following behavior requires a ``proactive'' behavior which attempts to predict the intention of the leader. This corresponds
to predicting the future external wrench. A better prediction model should correspond to a better
proactive behavior.

Since the target application is for collaborating with humans, this model amounts to predicting the human partner's intention. One possible
assumption is to take the results presented in Bussy:IROS:2012 and infer from this 2 models to predict the forces:
\begin{enumerate}
 \item constant acceleration model - constant force
 \item constant jerk model - linear force
\end{enumerate}

\subsection{A combined approach}
Once a good leader and follower approach are formulated, it might be possible to reformulate it into a combined approach

\input{wpg03_notation_undefine.tex}


\chapter{Experiment Specifications} \label{sec:Experiment Specifications}
\begin{mydef} \label{def:GPU Speedup}
    GPU Speedup: Ratio of model's execution time with GPU ``set'' to that with CPU ``set''. The script's data preprocessing runtime is ignored but the time taken to transfer data from CPU to GPU is included in calculating GPU ``set'' time elapsed. (Speedup = $\frac{CPU-time}{GPU-time\; +\; Transfer-time}$)
\end{mydef}

We conducted several tests for optimization and GPU Speedup to test both our models. After initializing all parameters randomly (with specific seeds for reproduction and uniformity between tests), the models were run for 1000 or 10000 epochs depending on the complexity of the model.

\section{Datasets} \label{sec:Datasets}
We conducted two types of tests: \textbf{optimization tests on original datasets} and \textbf{GPU Speedup tests on randomly generated datasets}. Data was loaded or generated as Floating Point 32 (FP32) units but was stored with less precision (up to 15 significant figures) to reduce secondary memory usage.

The original dataset available from eBird observations contained 173 time units ($T$) and 116 Avicache locations ($J$) \cite{EBird}. For the GPU Speedup runs, a random dataset of 173 time units ($T$) and 232 locations ($J$) was generated beforehand using NumPy (without any seed). The number of locations in the random dataset was higher than that in the original dataset to aim for a clear trend if the models were to be scaled. We believe that speedup tests on original datasets would give similar results, though we used randomly generated datasets because the original dataset could not be flawlessly extrapolated. The models were timed for the executed operations in a neural network and the LP, including transfer times of tensors between the RAM and GPU's internal memory. Time taken for preprocessing was ignored.

\section{Test-Machine Configuration} \label{sec:Test-Machine Configuration}
Hardware specifications and software versions used for the experiments are listed in \Cref{tab:Hardware Specifications and Software Versions Used for Experiments}. Though we couldn't eliminate extraneous computing usage by background processes on the test-machine, we restricted it by switching off X (Graphical User Interface for Ubuntu OS) and performing tests in CLI (Command Line Interface), and ending user processes. One should obtain similar GPU Speedup results when repeating the experiments, though background processes and threads might give varying runtime values.
\begin{table}[!htbp]
    \centering
    \caption{Hardware Specifications and Software Versions Used for Experiments}
    \label{tab:Hardware Specifications and Software Versions Used for Experiments}
    \begin{tabular}{|c|c|}
        \hline
        \multicolumn{2}{c}{\textbf{Hardware}}\\
        \hline
        \textbf{Type} & \textbf{Unit/Specs}\\
        \hline
        Desktop & Dell Precision Tower 3620\\
        CPU & Intel Core i7-7700K\tablefootnote{Hyper-threaded with 4 cores, 8 threads @ 4.20-4.50 GHz}\\
        RAM & 16GB\\
        GPU & NVIDIA Quadro P4000\tablefootnote{1792 CUDA Cores @ 1.2-1.5 GHz}\\
        \hline
    \end{tabular}\quad
    \begin{tabular}{|c|c|}
        \hline
        \multicolumn{2}{c}{\textbf{Software}}\\
        \hline
        \textbf{Library/Package} & \textbf{Version}\\
        \hline
        Ubuntu OS & 16.04.2 LTS x86\textunderscore64\\
        CUDA & 8.0\\
        cuDNN & 5.1.10\\
        MKL & 2017.0.3\\
        Python & 2.7.13 (Anaconda)\\
        PyTorch & 0.1.12\textunderscore2\\
        NumPy & 1.12.1\\
        SciPy & 0.19.0\\
        \hline
    \end{tabular}
\end{table}

\paragraph{GPU ``set'' and CPU ``set'' Clarification}
By GPU ``set'' we mean \textit{distributing} operations in the scripts between CPU and GPU, while by CPU ``set'' we mean that the operations were executed \textit{only} on the CPU. Since GPUs are inferior than CPUs at handling most operations other than simple arithmetic matrix ones due to parallelism (see \Cref{sec:Computation Using GPUs}), we used --- and recommend using --- both the CPU and the GPU in GPU ``set'' to handle operations each is superior at (useful for large datasets). However, since the models in \Cref{alg:Algorithm for the Identification Problem,alg:Solving the Pricing Problem} (not the full scripts) primarily comprise of arithmetic operations on  tensors, it is clear that they were executed on the GPU when it was ``set'' and on the CPU when the CPU was ``set''. Other than this optimization, we did not specifically design any parallelized algorithm for either configurations, relying on the PyTorch's and NumPy-SciPy's inbuilt implementation.

\section{Algorithm Choice} \label{sec:Algorithm Choice}
On the algorithm side, we used Adam's algorithm for \textsc{Gradient-Descent}($\cdot$), after testing performances of several algorithms\footnote{PyTorch lets you choose the corresponding function/module} including, but not limited to, Stochastic Gradient Descent (SGD) \cite{SGD}, Adam's Algorithm \cite{Adam} and Adagrad \cite{Adagrad}. In \Cref{sec:Results}, we only discuss and show tests using the Adam's algorithm, since it was found to work best with both models over all test runs.

\section{Running the Identification Problem's Model} \label{sec:Running the Identification Problem's Model}
\subsection{Optimizing the Original Dataset} \label{sec:Identification Problem-Optimizing the Original Dataset}
The 3-layered neural network was run for 10000 epochs on the original dataset, which was split 80:20 along ($T$) for training and testing sets, with different learning rates = $\{10^{-2}, 10^{-3}, 10^{-4}, 10^{-5}\}$. Since we were aiming for optimization, we ran multiple tests (5 different seeds with each learning rate) of the model only with the GPU ``set''.

To compare this model's optimization results with other model structures, the previously studied 2-layered network \cite{Xue2016Avi2} and a 4-layered neural network were used. The 4-layered network had another hidden layer with reLU, equivalent to the hidden layer in the current 3-layered network in \Cref{fig:3-dimensional view of the network slice taking in Fv}. The results from the 2-layered network were obtained from the previous study, and those from the 4-layered network were attained on the same original dataset with same specifications (learning rates, epochs etc.).

\subsection{Testing GPU Speedup on the Random Dataset} \label{sec:Identification Problem-Testing GPU Speedup on the Random Dataset}
After generating a random dataset and splitting it 80:20 for training and testing (to emulate testing on the original dataset), we ran our 3-layered model with different batch-sizes $J = \{11,37,63,90,116,145,174,203,232\}$ ($T = 173$) and different seeds with both GPU and CPU ``set'', logging the elapsed time for model execution. The total time elapsed was averaged for a batch-size on a device, which were used to generate scatter/line plots (see \Cref{sec:IdProbRes - GPU}).

\section{Running the Pricing Problem's Model} \label{sec:Running the Pricing Problem's Model}
\subsection{Optimizing the Original Dataset} \label{sec:Pricing Problem-Optimizing the Original Dataset}
After obtaining the set of weights $\matr{w_1}$ and $\matr{w_2}$ optimized using different seeds, we tested to find the best rewards (with the lowest loss --- \Cref{eqn:pricing_problem}) with random $\vect{r}$ initialization. To obtain the best rewards, the model was run on all sets of weights obtained from the Identification Problem for 1000 epochs with different learning rates. In search for the best rewards with the minimum loss, we took this approach:
\begin{enumerate}
    \item Run differently seeded rewards on all sets of weights obtained from the Identification Problem, and identify a set of weights which performed better than the others (low $Z_I$ --- \Cref{eqn:pricing_problem}) on average. The learning rate was fixed to $10^{-3}$ in this case.
    \item Use that set of weights to run a number of tests with varying seeds and learning rates = $\{10^{-2}, 5 \times 10^{-3}, 10^{-3}, 5 \times 10^{-4}, 10^{-4}, 5 \times 10^{-5}, 10^{-5}\}$, and choose the rewards that gave the lowest loss value $Z_I$ during execution\footnote{This means that we selected the rewards before completion if the loss at that epoch was lower than that in the end.}.
\end{enumerate}

Two sets of rewards were tested for loss values as baseline comparisons to our model --- a randomly generated set, and another with elements inversely proportional to the number of visits at each location. While the former was a random baseline, the latter captured the idea of allocating higher rewards to relatively under-sampled locations. The best loss values were compared for all tests with the baselines.

\subsection{Testing GPU Speedup on the Random Dataset} \label{sec:Pricing Problem-Testing GPU Speedup on the Random Dataset}
Initially, we ran the Pricing Problem's model with different batch-sizes $J = \{11, 37, 63, 90, 116\}$ ($T = 173$), different seeds with both GPU and CPU ``set'', and learning rate = $10^{-3}$ for 1000 epochs. Since we couldn't find a clear trend, we tested on more locations $J = \{145, 174, 203, 232\}$.

We relied on SciPy's Optimize Module to solve our LP sub-problem (see \Cref{sec:Constraining Rewards}) because PyTorch does not provide a GPU-accelerated Simplex LP solver. Since SciPy's implementation does not utilize the GPU, we expected the LP problem to be executed on the CPU, thus delivering equal runtimes in both GPU and CPU ``set'' configurations.


\section{Introduction}
\label{intro}

{\em Haskore} is a collection of Haskell modules designed for
expressing musical structures in the high-level, declarative style of
{\em functional programming}.  In Haskore, musical objects consist of
primitive notions such as notes and rests, operations to transform
musical objects such as transpose and tempo-scaling, and operations to
combine musical objects to form more complex ones, such as concurrent
and sequential composition.  From these simple roots, much richer
musical ideas can easily be developed.

Haskore is a means for describing {\em music}---in particular Western
Music---rather than {\em sound}.  It is not a vehicle for synthesizing
sound produced by musical instruments, for example, although it does
capture the way certain (real or imagined) instruments permit control
of dynamics and articulation.

Haskore also defines a notion of {\em literal performance} through
which {\em observationally equivalent} musical objects can be
determined.  From this basis many useful properties can be proved,
such as commutative, associative, and distributive properties of
various operators.  An {\em algebra of music} thus surfaces.

In fact a key aspect of Haskore is that objects represent both {\em
abstract musical ideas} and their {\em concrete implementations}.
This means that when we prove some property about an object, that
property is true about the music in the abstract {\em and} about its
implementation.  Similarly, transformations that preserve musical
meaning also preserve the behavior of their implementations.  For this
reason Haskell is often called an {\em executable specification
language}; i.e.~programs serve the role of mathematical specifications
that are directly executable.

Building on the results of the functional programming community's
Haskell effort has several important advantages: First, and most
obvious, we can avoid the difficulties involved in new programming
language design, and at the same time take advantage of the many years
of effort that went into the design of Haskell.  Second, the resulting
system is both {\em extensible} (the user is free to add new features
in substantive, creative ways) and {\em modifiable} (if the user
doesn't like our approach to a particular musical idea, she is free to
change it).

In the remainder of this paper I assume that the reader is familar
with the basics of functional programming and Haskell in particular.
If not, I encourage reading at least {\em A Gentle Introduction to
Haskell} \cite{haskell-tutorial} before proceeding.  I also assume
some familiarity with {\em equational reasoning}; an excellent
introductory text on this is \cite{birdwadler88}.

\subsection{Acknowledgements}

Many students have contributed to Haskore over the years, doing for
credit what I didn't have the spare time to do!  I am indebted to them
all: Amar Chaudhary, Syam Gadde, Bo Whong, and John Garvin, in
particular.  Thanks also to Alastair Reid for implementing the first
Midi-file writer, to Stefan Ratschan for porting Haskore to GHC, and
to Matt Zamec for help with the Csound compatibility module.  I would
also like to express sincere thanks to my friend and talented New
Haven composer, Tom Makucevich, for being Haskore's most faithful
user.