\chapter{Translation to \Java}
\index{Java@\Java!translation to $\sim$|(}

In this chapter we show how to translate simple functional programs to
\Java, illustrating what may be called a functional style in an
object\hyp{}oriented language. We will make no use of
side\hyp{}effects, so all variables are assigned only once. Objects
programmed in this manner are sometimes called \emph{functional
  objects}. The difficulties we face have to do with the type system
of \Java, since our functional language is untyped. As a consequence,
some programs cannot be translated and others require intermediary
translations, called \emph{refinements}, before the equivalent \Java
program is produced.

In the introduction, \vpageref{par:java}, we laid out the design
pattern for modelling stacks: an abstract class \texttt{Stack<Item>}
parameterised over the type of its contents \texttt{Item} and two
extensions, \texttt{EStack<Item>} for empty stacks and
\texttt{NStack<Item>} for non\hyp{}empty stacks. It is important to
understand the rationale behind this pattern, because it is perhaps
more likely to find an imperative implementation in the following
lines:
\begin{alltt}
\public \class Stack<Item> \{\hfill// Stack.java
  \private Item head;
  \private Stack<Item> tail;

  \public Stack() \{ head = \nullX; tail = \nullX; \}

  \public \booleanX empty() \{ \return head == \nullX; \}

  \public Item pop() \throws EmptyStack \{
    \ifX (empty()) \throw \new EmptyStack();
    \final Item orig = head;
    \ifX (tail.empty()) head = \nullX; \elseX head = tail.pop();
    \return orig; \}

  \public \void push(\final Item item) \{
    Stack<Item> next = \new Stack<Item>();
    next.head = head;
    next.tail = tail;
    head = item;
    tail = next; \}
\}

// EmptyStack.java
\public \class EmptyStack \extends Exception \{\}
\end{alltt}
This encoding has several defaults. Firstly, it is incorrect if the
top of a stack (\texttt{head}) is a \texttt{null} reference. This can
be remedied by adding a level of indirection, that is, by creating a
private class holding \texttt{head} and \texttt{tail} or modelling the
empty stack with \texttt{null}, which entails to check for
\texttt{null} before calling any method. Secondly, pervasive use of
\texttt{null} references increases the risk of an invalid
access. Thirdly, the code for \texttt{pop} and \texttt{push} already
suggests that further operations will lead to lengthy reference
manipulations. Fourthly, persistence, for example, keeping successive
versions of a stack, is not easy.

A thorough study of the issues of null references in programming
language design is given by \cite{ChalinJames_2007,Cobbe_2008} and
\cite{Hoare_2009}. One practical inconvenience of such references is
that they render the composition of methods cumbersome and, for
example, instead of writing \texttt{s.cat(t).push(x).rev()}, we would
have to check if each call returns \texttt{null} or not.

The design we presented in the introduction avoids all the problems
and limitations previously mentioned. Of course, this comes with a
cost, which we will discuss in a couple of occasions. For now, let us
recall the \Java program of the introduction, which will be completed
further in this chapter:
\begin{alltt}
// Stack.java
\public \abstractX \class Stack<Item> \{
  \public \final NStack<Item> push(\final Item item) \{
    \return \new NStack<Item>(item,\this); \}
  \public \abstractX Stack<Item> cat(\final Stack<Item> t); \}

// EStack.java
\public \final \class EStack<Item> \extends Stack<Item> \{
  \public Stack<Item> cat(\final Stack<Item> t) \{ \return t; \}
\}

// NStack.java
\public \final \class NStack<Item> \extends Stack<Item> \{
  \private \final Item head;
  \private \final Stack<Item> tail;

  \public NStack(\final Item item, \final Stack<Item> stack) \{
    head = item; tail = stack;
  \}

  \public NStack<Item> cat(\final Stack<Item> t) \{
    \return tail.cat(t).push(head);
  \}
\}
\end{alltt}
Notice that we eschewed defining any method \texttt{pop}. The reason
is that it is intrinsically a partial function, undefined when its
argument is the empty stack, and this is why we had to resort to the
exception \texttt{EmptyStack} above. In practice, anyway, this method
is hardly useful as it would be implicit in an algorithm, for example,
in the definition of \texttt{cat} in class \texttt{NStack<Item>}. More
fundamentally, because \texttt{head} and \texttt{tail} are part of the
data structure itself, there is no need for a \texttt{pop} method.

\section{Single dispatch}
\label{sec:single_dispatch}
% \extends Comparable<? \super Item>

\paragraph{Stack reversal}
\index{stack!reversal!$\sim$ in \Java|(}

As we have seen in equation~\eqref{def:rev} \vpageref{def:rev}, the
efficient manner to reverse a stack in our functional language
consists in using an accumulator as follows:
\begin{equation*}
\fun{rev}(s) \xrightarrow{\smash{\epsilon}}
             \fun{rcat}(s,\el).\quad\;\;
\fun{rcat}(\el,t) \xrightarrow{\smash{\zeta}} t;\quad\;\;
\fun{rcat}(\cons{x}{s},t) \xrightarrow{\smash{\eta}}
                          \fun{rcat}(s,\cons{x}{t}).
\end{equation*}
Function \fun{rev/1} is defined with one rule which does not
discriminate on the nature of its parameter. Therefore, its
translation will be one method in the abstract class
\texttt{Stack<Item>}:
\begin{alltt}
// Stack.java
\public \abstractX \class Stack<Item> \{
  ...
  \public Stack<Item> rev() \{
    \return rcat(\new EStack<Item>()); \}
\}
\end{alltt}
An examination of the patterns defining the rules of function
\fun{rcat/2} shows that only the first parameter is constrained, more
precisely, it is either expected to be an empty stack or a
non\hyp{}empty stack. This simple kind of functional definition is
easily translated by relying upon the \emph{single dispatch} feature
of \Java, that is, the dynamic class of an object determines the
method being called. When, in a rule, exactly one parameter is
constrained, it is thus the natural candidate for single dispatch. For
example,
\begin{alltt}
// Stack.java
\public \abstractX \class Stack<Item> \{
  ...
  \public \abstractX Stack<Item> rcat(\final Stack<Item> t);
\}
\end{alltt}
Class \texttt{EStack<Item>} contains the translation of rule~\(\zeta\):
\begin{alltt}
// EStack.java
\public \final \class EStack<Item> \extends Stack<Item> \{
  ...
  \public Stack<Item> rcat(\final Stack<Item> t) \{ \return t; \}
\}
\end{alltt}
Class \texttt{NStack<Item>} holds the translation of rule~\(\eta\)
(\texttt{tail} is~\(s\), \texttt{head} is~\(x\)):
\begin{alltt}
// NStack.java
\public \final \class NStack<Item> \extends Stack<Item> \{
  ...
  \public Stack<Item> rcat(\final Stack<Item> t) \{
    \return tail.rcat(t.push(head));
  \}
\}
\end{alltt}
\index{stack!reversal!$\sim$ in \Java|)}

\paragraph{Skipping}
\index{stack!skipping an item!$\sim$ in \Java|(}

Let us recall the function \fun{sfst/2} in
section~\vref{sec:skipping}:
\begin{equation*}
\fun{sfst}(\el,x)          \xrightarrow{\smash{\theta}} \el;\quad\;\;
\fun{sfst}(\cons{x}{s},x)  \xrightarrow{\smash{\iota}}  s;\quad\;\;
\fun{sfst}(\cons{y}{s},x)  \xrightarrow{\smash{\kappa}}
                                         \cons{y}{\fun{sfst}(s,x)}.
\end{equation*}
This definition cannot be translated as it is because it contains an
implicit equality test in its patterns \(\iota\)~and~\(\kappa\), hence
it cannot solely rely on single dispatch. Perhaps the easiest way to
proceed is to extend our functional language with a conditional
expression \(\fun{if} \dots \fun{then} \dots \fun{else} \dots\) and
refine the original definition to use it. Here, we obtain
\begin{equation*}
\fun{sfst}(\el,x)          \xrightarrow{\smash{\theta}} \el;\quad\;\;
\fun{sfst}(\cons{y}{s},x)  \xrightarrow{\smash{\iota+\kappa}}
\fun{if} \; x = y \; \fun{then} \; s \;
\fun{else} \; \cons{y}{\fun{sfst}(s,x)}.
\end{equation*}
Now that pattens do not overlap anymore, we can translate to
\Java. First, we must not forget to expand the abstract class
\texttt{Stack<Item>}:
\begin{alltt}
// Stack.java
\public \abstractX \class Stack<Item> \{
  ...
  \public \abstractX Stack<Item> sfst(\final Item x);
\}
\end{alltt}
The translation of rule~\(\theta\) goes into the class
\texttt{EStack<Item>}:
\begin{alltt}
// EStack.java
\public \final \class EStack<Item> \extends Stack<Item> \{
  ...
  \public EStack<Item> sfst(\final Item x) \{ \return \this; \}
\}
\end{alltt}
The joint translation of \(\iota\)~and~\(\kappa\) is
\begin{alltt}
// NStack.java
\public \final \class NStack<Item> \extends Stack<Item> \{
  ...
  \public Stack<Item> sfst(\final Item x) \{
    \return head.compareTo(x) == 0 ?
           tail : tail.sfst(x).push(head); \}
\}
\end{alltt}
This last step reveals a mistake and a limitation of our method: in
order to compare two values of class \texttt{Item} like \texttt{head}
and~\texttt{x}, we need to specify that \texttt{Item} extends the
predefined class \texttt{Comparable}. Therefore, we must rewrite our
class definitions as follows:
\begin{alltt}
\public \abstractX \class Stack<Item
\hfill\extends Comparable<? \super Item>> \{
  ...
\}
\public \class EStack<Item \extends Comparable<? \super Item>>
       \extends Stack<Item> \{
  ...
\}
\public \class NStack<Item \extends Comparable<? \super Item>>
       \extends Stack<Item> \{
  ...
\}
\end{alltt}
It is a limitation because we must constrain \texttt{Item} to be
comparable even if some methods do not require this, like
\texttt{rev}, which is purely structural. Also, the abstract class
must be updated every time a new operation is added. (For a detailed
understanding of generics in \Java, see \cite{NaftalinWadler_2006}.)
\index{stack!skipping an item!$\sim$ in \Java|)}

\paragraph{Insertion sort}
\index{insertion sort!$\sim$ in \Java|(}
\index{Java@\Java|see{insertion sort}}

Insertion sort was defined in section~\vref{sec:straight_ins} as
\begin{equation*}
\begin{array}{@{}r@{\;}l@{\;}lr@{\;}l@{\;}l@{}}
  \fun{ins}(\cons{y}{s},x)
& \xrightarrow{\smash{\kappa}}
& \cons{y}{\fun{ins}(s,x)}, \,\text{if \(x \succ y\)};
& \fun{isrt}(\el)
& \xrightarrow{\smash{\mu}}
& \el;\\
  \fun{ins}(s,x)
& \xrightarrow{\smash{\lambda}}
& \cons{x}{s}.
& \fun{isrt}(\cons{x}{s})
& \xrightarrow{\smash{\nu}}
& \fun{ins}(\fun{isrt}(s),x).
\end{array}
\end{equation*}
Function \fun{isrt/1} is easy to translate because it only needs
single dispatch. Function \fun{ins/2} too, but first requires a refinement
introducing a conditional. Easy things first:
\begin{alltt}
// Stack.java
\public \abstractX \class Stack<Item
\hfill\extends Comparable<? \super Item>> \{
  ...
  \public \abstractX Stack<Item> isrt();
\}
// EStack.java
\public \class EStack<Item \extends Comparable<? \super Item>>
       \extends Stack<Item> \{
  ...
  \public EStack<Item> isrt() \{ \return \this; \}
\}
// NStack.java
\public \class NStack<Item \extends Comparable<? \super Item>>
       \extends Stack<Item> \{
  ...
  \public NStack<Item> isrt() \{\return tail.isrt().ins(head);\}
\}
\end{alltt}
Notice how \(\fun{ins}(\fun{isrt}(s),x)\) became
\texttt{tail.isrt().ins(head)}. The general method consists, firstly,
in translating \(x\)~and~\(s\) into \texttt{x}~and~\texttt{tail};
secondly, in finding a possible order of evaluation (there may be more
than one) and laying out the translations of each function call from
left to right, separated by full stops. In the case at hand,
\(\fun{isrt}(s)\) is evaluated first and becomes \texttt{tail.isrt()},
then \(\fun{ins}(\texttt{\textvisiblespace},x)\), which yields
\texttt{\textvisiblespace.ins(head)}.

The refinement of \fun{ins/2} is
\begin{equation*}
\begin{array}{@{}r@{\;}l@{\;}l@{}}
\fun{ins}(\cons{y}{s},x) & \rightarrow & \fun{if} \; x \succ y \;
\fun{then} \; \cons{y}{\fun{ins}(s,x)} \; \fun{else} \; \cons{x}{s};\\
\fun{ins}(\el,x) & \rightarrow & [x].
\end{array}
\end{equation*}
Note how we split rule~\(\lambda\) in two cases: \(\el\) and
\(\cons{y}{s}\), so the latter can be merged with rule~\(\kappa\) and
partake to the conditional. We can now translate to \Java:
\begin{alltt}
// Stack.java
\public \abstractX \class Stack<Item
\hfill\extends Comparable<? \super Item>> \{
  ...
  \protectedX \abstractX NStack<Item> ins(\final Item x);
\}
// EStack.java
\public \class EStack<Item \extends Comparable<? \super Item>>
       \extends Stack<Item> \{
  ...
  \protectedX NStack<Item> ins(\final Item x) \{\return push(x);\}
\}
// NStack.java
\public \class NStack<Item \extends Comparable<? \super Item>>
       \extends Stack<Item> \{
  ...
  \protectedX NStack<Item> ins(\final Item x) \{
    \return head.compareTo(x) < 0 ?
           tail.ins(x).push(head) : push(x); \}
\}
\end{alltt}
The method \texttt{ins} is declared \texttt{protected}, because it is
erroneous to insert an item into a non\hyp{}ordered stack.
\index{insertion sort!$\sim$ in \Java|)}

\paragraph{Testing}
\index{testing|(}

To test these definitions, we need a method \texttt{print}:
\begin{alltt}
\public \abstractX \void print();\hfill// Stack.java
\public \void print() \{ System.out.println(); \}\hfill// EStack.java
\public \void print() \{\hfill// NStack.java
  System.out.print(head + " "); tail.print(); \}
\end{alltt}
Finally, the \texttt{Main} class would look like
\begin{alltt}
\public \class Main \{\hfill // Main.java
  \public \static \void \main (String[] args) \{
    Stack<Integer> nil = \new EStack<Integer>();
    Stack<Integer> s = nil.push(5).push(2).push(7);
    s.print();\hfill// 7 2 5
    s.rev().print();\hfill// 5 2 7
    Stack<Integer> t = nil.push(4).push(1);\hfill// 1 4
    s.cat(t).print();\hfill// 7 2 5 1 4
    t.cat(s).isrt().print(); \}\hfill// 1 2 4 5 7
\}
\end{alltt}
The properties we proved earlier on the functional source codes are
transferred to the \Java target codes. In particular, the costs are
left invariant and they count the number of method calls needed to
compute the value of a method call, \emph{assuming that we do not
  account for the calls to \texttt{push}}: this method, which was
intended as a commodity, was declared \texttt{final} in the hope that
the compiler might inline its definition.  \index{testing|)}

\paragraph{Cutting}
\index{stack!cutting!$\sim$ in \Java|(}

In section~\vref{sec:cutting}, we saw how to cut a stack in two stacks
by specifying the length of the prefix:
\begin{equation*}
\begin{array}{@{}r@{\;}l@{\;}lr@{\;}l@{\;}l@{}}
\fun{cut}(s,0) & \rightarrow & \pair{\el}{s};
& \fun{push}(x,\pair{t}{u}) & \rightarrow & \pair{\cons{x}{t}}{u}.\\
\fun{cut}(\cons{x}{s},k) & \rightarrow
& \fun{push}(x,\fun{cut}(s,k-1)).
\end{array}
\end{equation*}
Here, we have another instance of a rule which covers two different
cases: in the first rule of \fun{cut/2}, either \(s\)~is empty or
not. If the latter, the translation of the rule must be merged with
the translation of the second rule. There is an additional difficulty
in the fact that \Java does not provide native pairs to translate
\(\pair{t}{u}\) immediately. Fortunately, it is not difficult to
devise a class for pairs if we realise that, abstractly, a pair is a
thing that has two properties: one informing about its `first
component' and another about its `second component.' We have
\begin{alltt}
// Pair.java
\public \class Pair<Fst,Snd> \{
  \protectedX \final Fst fst;
  \protectedX \final Snd snd;
  \public Pair(\final Fst f, \final Snd s) \{fst = f; snd = s;\}

  \public Fst fst() \{ \return fst; \}
  \public Snd snd() \{ \return snd; \}
\}
\end{alltt}
Now we can proceed as follows:
\begin{alltt}
// Stack.java
\public \abstractX \class Stack<Item
\hfill\extends Comparable<? \super Item>> \{
  ...
  \public \abstractX
            Pair<Stack<Item>,Stack<Item>> cut(\final int k);
\}
\end{alltt}
Notice that, as usual, a function with \(n\)~parameters is translated
into a method with \(n-1\) parameters because one of them is used to
perform the single dispatch or, in terms of the type system, it
supports \emph{subtype polymorphism} \citep{Pierce_2002}.
\begin{alltt}
// EStack.java
\public \class EStack<Item \extends Comparable<? \super Item>>
       \extends Stack<Item> \{
  ...
  \public Pair<Stack<Item>,Stack<Item>> cut(\final int k) \{
    \return \new Pair<Stack<Item>,Stack<Item>>(\this,\this);
  \}
\}
// NStack.java
\public \class NStack<Item \extends Comparable<? \super Item>>
       \extends Stack<Item> \{
  ...
  \public Pair<Stack<Item>,Stack<Item>> cut(\final int k) \{
    \ifX (k == 0)
       \return \new Pair<Stack<Item>,Stack<Item>>
                      (\new EStack<Item>(),\this);
    Pair<Stack<Item>,Stack<Item>> p = tail.cut(k-1);
    \return \new Pair<Stack<Item>,Stack<Item>>
                   (p.fst().push(head),p.snd());
  \}
\}
\end{alltt}
Finally, the~\texttt{Main} class could look like
\begin{alltt}
// Main.java
\public \class Main \{
  \public \static \void \main (String[] args) \{
    Stack<Integer> nil = \new EStack<Integer>();
    Stack<Integer> s = nil.push(5).push(2).push(7);\hfill// 7 2 5
    Stack<Integer> t = nil.push(4).push(1);\hfill// 1 4
    Pair<Stack<Integer>,Stack<Integer>> u = s.cat(t).cut(2);
    u.fst().print();\hfill// 7 2
    u.snd().print();\hfill// 5 1 4
  \}
\}
\end{alltt}
A translation may or must enjoy different interesting properties. For
example, it must be correct in the sense that the result of the
evaluation of a call in the source language is, in a certain sense,
equal to the result of the evaluation of the translated call. This is
what we wanted for our translation from our functional language to
\Java. Additionally, it could be required that erroneous behaviours
also translate into erroneous behaviours. For example, it may be
desirable that infinite loops translate into infinite loops and that
run\hyp{}time errors in evaluations in the source langage correspond
to similar errors in the target. (The translation of \fun{cut/2} does
not preserve all errors. Why?)\index{stack!cutting!$\sim$ in \Java|)}

\section{Binary dispatch}
\index{Java@\Java|see{merge sort}}

Functions defined by matching two or more stacks in the same pattern
call for \emph{multiple dispatch} in a target object\hyp{}oriented
language. Unfortunately, \Java only features single dispatch, in other
words, only one parameter of the source function supports subtype
polymorphism in the target. In case of \emph{binary
  dispatch}\index{Java@\Java!binary dispatch}, we can refine the
source definition into an equivalent definition which can, in turn, be
translated with single dispatch alone. This technique was proposed a
long time ago by \cite{Ingalls_1986} and a practical overview was
published by \cite{MuscheviciPotaninTemperoNoble_2008}.

\paragraph{Merge sort}

For example, let us consider again the definition of \fun{mrg/2} in
\fig~\vref{fig:tms}:
\begin{equation*}
\begin{array}{@{}r@{\;}l@{\;}l@{}}
\fun{mrg}(\el,t)         & \rightarrow & t;\\
\fun{mrg}(s,\el)         & \rightarrow & s;\\
\fun{mrg}(\cons{x}{s},\cons{y}{t}) & \rightarrow
                         & \cons{y}{\fun{mrg}(\cons{x}{s},t)},\;
                           \text{if \(x \succ y\)};\\
\fun{mrg}(\cons{x}{s},t) & \rightarrow & \cons{x}{\fun{mrg}(s,t)}.
\end{array}
\end{equation*}
We need to rewrite this definition so only one stack is inspected in
the patterns. In order to do so, we choose arbitrarily one stack
parameter, let us say the first, and match it against the empty and
non\hyp{}empty patterns as follows:
\begin{equation*}
\begin{array}{@{}r@{\;}l@{\;}l@{}}
\fun{mrg}(\el,t)         & \rightarrow & t;\\
\fun{mrg}(\cons{x}{s},t) & \rightarrow & \fun{mrg}_0(x,s,t).\\
\\
\fun{mrg}_0(x,s,\el)     & \rightarrow & \cons{x}{s};\\
\fun{mrg}_0(x,s,\cons{y}{t}) & \rightarrow
& \fun{if} \; x \succ y \; \fun{then} \;
  \cons{y}{\fun{mrg}(\cons{x}{s},t)} \;
  \fun{else} \; \cons{x}{\fun{mrg}(s,\cons{y}{t})}.
\end{array}
\end{equation*}
Note how we had to introduce an auxiliary function \fun{mrg\(_0\)/3}
to handle the matching of the second argument, \(t\), of
\fun{mrg/2}. We also made use of a conditional construct in the last
rule of \fun{mrg\(_0\)/3}, where we can also avoid the
memory\hyp{}consuming pushes \(\cons{x}{s}\) and \(\cons{y}{t}\) by,
respectively, calling \(\fun{mrg}_0(x,s,t)\) and
\(\fun{mrg}_0(y,t,s)\). The latter call is a consequence of the
theorem that merging is a symmetric function: \(\fun{mrg}(s,t) \equiv
\fun{mrg}(t,s)\). We have now
\begin{equation*}
\begin{array}{@{}r@{\;}l@{\;}l@{}}
\fun{mrg}(\el,t)         & \rightarrow & t;\\
\fun{mrg}(\cons{x}{s},t) & \rightarrow & \fun{mrg}_0(x,s,t).\\
\\
\fun{mrg}_0(x,s,\el)     & \rightarrow & \cons{x}{s};\\
\fun{mrg}_0(x,s,\cons{y}{t}) & \rightarrow
& \fun{if} \; x \succ y \; \fun{then} \;
  \cons{y}{\fun{mrg}_0(x,s,t)} \;
  \fun{else} \; \cons{x}{\fun{mrg}_0(y,t,s)}.
\end{array}
\end{equation*}
Then we have two functions that can be translated to \Java only using
single dispatch:\index{merge sort!merging!$\sim$ in \Java|(}
\begin{alltt}
// Stack.java
\public \abstractX \class Stack<Item
\hfill\extends Comparable<? \super Item>> \{
  ...
  \public \abstractX Stack<Item> mrg(\final Stack<Item> t);
  \public \abstractX Stack<Item> mrg0(\final Item x,
                                   \final Stack<Item> s);
\}
// EStack.java
\public \class EStack<Item \extends Comparable<? \super Item>>
       \extends Stack<Item> \{
  ...
  \public Stack<Item> mrg(\final Stack<Item> t) \{ \return t; \}
  \public Stack<Item> mrg0(\final\! Item x,\final Stack<Item> s)\{
    \return s.push(x); \}
\}
// NStack.java
\public \class NStack<Item \extends Comparable<? \super Item>>
       \extends Stack<Item> \{
  ...
  \public Stack<Item> mrg(\final Stack<Item> t) \{
    \return t.mrg0(head,tail); \}

  \public Stack<Item> mrg0(\final Item x,
                          \final Stack<Item> s) \{
    \return x.compareTo(head) > 0 ?
           tail.mrg0(x,s).push(head)
         : s.mrg0(head,tail).push(x); \}
\}
\end{alltt}
Keep in mind that the pattern \(\fun{mrg}_0(x,s,\cons{y}{t})\) means
that \(\cons{y}{t}\) translates as \texttt{this}, so the target code
should go in the class \texttt{NStack<Item>}, where \texttt{head} is
the translation of~\(y\) and \texttt{tail} is the image of~\(t\).
Finally,\index{merge sort!merging!$\sim$ in \Java|)}
\begin{alltt}
\public \class Main \{\hfill // Main.java
  \public \static \void \main (String[] args) \{
    Stack<Integer> nil = \new EStack<Integer>();
    Stack<Integer> s = nil.push(5).push(2).push(7);\hfill// 7 2 5
    Stack<Integer> t = nil.push(4).push(1);\hfill// 1 4
    s.isrt().mrg(t.isrt()).print();\hfill// 1 2 4 5 7
    t.isrt().mrg(s.isrt()).print();\hfill// 1 2 4 5 7
  \}
\}
\end{alltt}
At this point, it could be argued that our translation scheme leads to
cryptic \Java programs. But this critique is valid only because it
forgets to take into account any specification. We propose that the
functional program \emph{is} the specification of the \Java program
and should accompany it. A translation to \Erlang could be performed
first, due to its simplicity, and it would in turn be translated into
\Java, while remaining as a comment in the target code and its
documentation. For example, we would write
\begin{alltt}
// NStack.java
\public \class NStack<Item \extends Comparable<? \super Item>>
       \extends Stack<Item> \{
  ...
  // mrg0(X,S,[Y|T]) -> case X > Y of
  //                      true  -> [Y|mrg0(X,S,T)];
  //                      false -> [X|mrg0(Y,T,S)]
  //                    end.
  //
  \public Stack<Item> mrg0(\final Item x,
                          \final Stack<Item> s) \{
    \return x.compareTo(head) > 0 ?
           tail.mrg0(x,s).push(head)
         : s.mrg0(head,tail).push(x); \}
\}
\end{alltt}
(We could even go a step further and rename the \Erlang parameters
\texttt{Y} and~\texttt{T}, respectively, as \texttt{Head} and
\texttt{Tail}.) This has the additional advantage that the
specification is executable, so the result of running the \Erlang
program can be expected to be equal to the result of the translated
run in \Java, which is a significant help for the test phase.

Let us finish now the translation of top\hyp{}down merge sort in
\fig~\vref{fig:tms}. We have
\begin{equation*}
\fun{tms}(\cons{x,y}{t}) \xrightarrow{\smash{\alpha}}
 \fun{cutr}([x],\cons{y}{t},t);\qquad
\fun{tms}(t) \xrightarrow{\smash{\beta}} t.
\end{equation*}
A refinement is necessary because rule~\clause{\beta} covers the case
of the empty stack and the singleton stack. Let us make all these
cases explicit and reorder them as follows:
\begin{equation*}
\fun{tms}(\el)            \rightarrow  \el;\quad
\fun{tms}([x])            \rightarrow  [x];\quad
\fun{tms}(\cons{x,y}{t})  \rightarrow
                          \fun{cutr}([x],\cons{y}{t},t).
\end{equation*}
Now, we must fuse the two last rules because they are covered by the
case 'non\hyp{}empty stack' and introduce an auxiliary function
\fun{tms\(_0\)/2} whose role is to distinguish between the singleton
and longer stacks. Whence
\begin{equation*}
\begin{array}{@{}r@{\;}l@{\;}l@{\qquad}r@{\;}l@{\;}l@{}}
  \fun{tms}(\el)             & \xrightarrow{\smash{\gamma}} & \el;
& \fun{tms}_0(x,\el)         & \xrightarrow{\smash{\epsilon}} & [x];\\
\fun{tms}(\cons{x}{t})       & \xrightarrow{\smash{\delta}}
                             & \fun{tms}_0(x,t).
& \fun{tms}_0(x,\cons{y}{t}) & \xrightarrow{\smash{\zeta}}
                             & \fun{cutr}([x],\cons{y}{t},t).
\end{array}
\end{equation*}
At this point, both \fun{tms/1} and \fun{tms\(_0\)/2} can be
translated into \Java using single dispatch but, before doing so, we
must check whether the final refinement is indeed equivalent to the
original program. We can test some calls whose partial
evaluations\index{functional language!evaluation!partial $\sim$} make
use, as a whole, of all the rules in the refined program and then
compare them with the partial evaluations in the original
program. (This is an instance of \emph{structural
  testing}\index{testing!structural $\sim$}, more precisely,
\emph{path testing}\index{testing!path $\sim$}.) Here, we found out
that three cases are distinguished: empty stack, singleton and longer
stacks. In the refined program, we have the interpretations
\begin{equation*}
\begin{array}{@{}r@{\;}l@{\;}l@{}}
\fun{tms}(\el) & \xrightarrow{\smash{\gamma}} & \el.\\
\fun{tms}([x]) & \xrightarrow{\smash{\delta}} & \fun{tms}_0(x,\el)
                 \xrightarrow{\smash{\epsilon}} [x].\\
\fun{tms}(\cons{x,y}{t})
  & \xrightarrow{\smash{\delta}} & \fun{tms}_0(x,\cons{y}{t})
    \xrightarrow{\smash{\zeta}} \fun{cutr}([x],\cons{y}{t},t).
\end{array}
\end{equation*}
We can now compare with the same calls being partially computed with
the original program:
\begin{equation*}
\begin{array}{@{}r@{\;}l@{\;}l@{}}
\fun{tms}(\el) & \xrightarrow{\smash{\beta}} & \el.\\
\fun{tms}([x]) & \xrightarrow{\smash{\beta}} & [x].\\
\fun{tms}(\cons{x,y}{t}) & \xrightarrow{\smash{\alpha}}
                         & \fun{cutr}([x],\cons{y}{t},t).
\end{array}
\end{equation*}
These calls agree and cover all the arrows in all the definitions. We
can now translate the refined program:\index{merge sort!top-down
  $\sim$!$\sim$ in \Java|(}
\begin{alltt}
// Stack.java
\public \abstractX \class Stack<Item
\hfill\extends Comparable<? \super Item>> \{
  ...
  \public \abstractX Stack<Item> tms();
  \protectedX \abstractX Stack<Item> tms0(\final Item x);
\}
// EStack.java
\public \class EStack<Item \extends Comparable<? \super Item>>
       \extends Stack<Item> \{
  ...
  \public Stack<Item> tms() \{ \return \this; \}
  \protectedX Stack<Item> tms0(\final Item x) \{
    \return push(x);
  \}
\}

// NStack.java
\public \class NStack<Item \extends Comparable<? \super Item>>
       \extends Stack<Item> \{
  ...
  \public Stack<Item> tms() \{ \return tail.tms0(head); \}

  \protectedX Stack<Item> tms0(\final Item x) \{
    \return tail.cutr(\new EStack<Item>().push(x),\this);
  \}
\}
\end{alltt}
\index{merge sort!top-down $\sim$!$\sim$ in \Java|)} Notice again how
auxiliary functions result in \texttt{protected} methods and how they
add to the overall cost, compared to the functional program: this is a
limitation on how properties on the source transfer to the
target. However, the asymptotic cost is the same as in the original
functional program. A closer look at \texttt{tms0} shows that we
translated \(\cons{y}{t}\) by \texttt{this} instead of
\texttt{tail.push(head)}, as an optimisation. Moreover, we dispatch
\texttt{cutr} on \texttt{tail} because we already know that this is
the parameter we are going to distinguish when translating
\fun{cutr/3} defined in \fig~\vref{fig:tms}:
\begin{equation*}
\begin{array}{@{}r@{\;}l@{\;}l@{}}
\fun{cutr}(s,\cons{y}{t},\cons{a,b}{u})
                       & \rightarrow & \fun{cutr}(\cons{y}{s},t,u);\\
\fun{cutr}(s,t,u)      & \rightarrow
                       & \fun{mrg}(\fun{tms}(s),\fun{tms}(t)).
\end{array}
\end{equation*}
We remark that two stacks are matched by the first pattern so some
refinement is called for and we must choose one parameter to start
with. A little attention reveals that the third one is the best
choice, because if it does not contain at least two items, it is
simply discarded. We need to introduce two auxiliary functions,
\fun{cutr\(_0\)/3} and \fun{cutr\(_1\)/3}, that check, respectively,
whether the third parameter contains at least two items and whether
the second contains at least one. The result is shown in
\fig~\ref{fig:cutr}.
\begin{figure}
\begin{equation*}
\boxed{
\begin{array}{@{}r@{\;}l@{\;}l@{}}
\fun{cutr}(s,t,\el)     & \rightarrow
                        & \fun{mrg}(\fun{tms}(s),\fun{tms}(t));\\
\fun{cutr}(s,t,\cons{a}{u})
                        & \rightarrow & \fun{cutr}_0(s,t,u).\\
\\
\fun{cutr}_0(s,t,\el)   & \rightarrow
                        & \fun{mrg}(\fun{tms}(s),\fun{tms}(t));\\
\fun{cutr}_0(s,t,\cons{b}{u})
                        & \rightarrow & \fun{cutr}_1(s,t,u).\\
\\
\fun{cutr}_1(s,\el,u)   & \rightarrow & \fun{tms}(s);\\
\fun{cutr}_1(s,\cons{y}{t},u)
                        & \rightarrow
                        & \fun{cutr}(\cons{y}{s},t,u).
\end{array}}
\end{equation*}
\caption{Cutting and merging top-down\label{fig:cutr}}
\end{figure}
Note how \(\fun{cutr}_1(s,\el,u) \rightarrow
\fun{mrg}(\fun{tms}(s),\fun{tms}(\el))\) was simplified using the
theorems \(\fun{tms}(\el) \equiv \el\) and \(\fun{mrg}(s,\el) \equiv
s\). The translation is now direct:\index{merge sort!top-down
  $\sim$!$\sim$ in \Java|(}
\begin{alltt}
// Stack.java
\public \abstractX \class Stack<Item
\hfill\extends Comparable<? \super Item>> \{
  ...
  \public    \abstractX Stack<Item> cutr(\final Stack<Item> s,
                                      \final Stack<Item> t);
  \protectedX \abstractX Stack<Item> cutr0(\final Stack<Item> s,
                                       \final Stack<Item> t);
  \protectedX \abstractX Stack<Item> cutr1(\final Stack<Item> s,
                                       \final Stack<Item> u);
\}

// EStack.java
\public \class EStack<Item \extends Comparable<? \super Item>>
       \extends Stack<Item> \{
  ...
  \public Stack<Item> cutr(\final Stack<Item> s,
                          \final Stack<Item> t) \{
    \return s.tms().mrg(t.tms()); \}

  \protectedX Stack<Item> cutr0(\final Stack<Item> s,
                              \final Stack<Item> t) \{
    \return s.tms().mrg(t.tms()); \}

  \protectedX Stack<Item> cutr1(\final Stack<Item> s,
                              \final Stack<Item> u) \{
    \return s.tms();
  \}
\}

// NStack.java
\public \class NStack<Item \extends Comparable<? \super Item>>
       \extends Stack<Item> \{
  ...
  \public Stack<Item> cutr(\final Stack<Item> s,
                          \final Stack<Item> t) \{
    \return tail.cutr0(s,t);
  \}

  \protectedX Stack<Item> cutr0(\final Stack<Item> s,
                              \final Stack<Item> t) \{
    \return t.cutr1(s,tail);
  \}

  \protectedX Stack<Item> cutr1(\final Stack<Item> s,
                              \final Stack<Item> u) \{
    \return u.cutr(s.push(head),tail);
  \}
\}
\end{alltt}
Note that it is of the utmost importance to constantly mind the
parameter in the source function whose translation will be the base
for dispatch. Finally, the \texttt{Main} class might look like
\begin{alltt}
// Main.java
\public \class Main \{
  \public \static \void \main (String[] args) \{
    Stack<Integer> nil = \new EStack<Integer>();
    Stack<Integer> s = nil.push(5).push(2).push(7);\hfill// 7 2 5
    Stack<Integer> t = nil.push(4).push(1);\hfill// 1 4
    s.tms().print();\hfill// 2 5 7
    s.cat(t).tms().print();\hfill// 1 2 4 5 7
  \}
\}
\end{alltt}
\index{merge sort!top-down $\sim$!$\sim$ in \Java|)}
\index{Java@\Java!translation to $\sim$|)}


\documentclass{article}
\usepackage[utf8]{inputenc}
\setlength{\parindent}{0em}
 \textwidth=6.5in
 \oddsidemargin=0pc
 \evensidemargin=0pc
 \topmargin=-2pc
 \headsep=0.05in
 \headheight=0pc
 \textheight=9.0in
 \setlength{\parskip}{2em}

\usepackage[shortlabels]{enumitem}
\usepackage{array}
\usepackage{wrapfig}
\usepackage{multirow}
\usepackage{tabu}
\usepackage{comment}
\usepackage{amsmath}
\usepackage{algorithm}
\usepackage{algpseudocode}
\usepackage[table]{xcolor}
\usepackage{verbatim}
%this I used to draw a row major graph
\usepackage{tikz}
\newcommand\x{\times}
\newcommand\y{\cellcolor{olive!10}}
\usepackage{color,soul}
\newcommand{\hlc}[2][yellow]{ {\sethlcolor{#1} \hl{#2}} }

%how do you make roman numerals in the title ??
\title{Data Structure and algorithm II\\Homework 4}
\author{Jue,Guo}
\date{April 2019}

\begin{document}
\maketitle
Note: contain useful resources and reading material but not solution \\
Reference: \\
1. https://www.cs.princeton.edu/~wayne/kleinberg-tardos/pdf/05DivideAndConquerII.pdf \Comment{relationship between dot product and matrix multiplication}\\
2. https://www.purplemath.com/modules/inductn3.htm \Comment{Geometric series and its related math problem}\\
3. Introduction to Algorithms 3rd edition CH.27 \Comment{On the idea and concept of Parallel for}\\

\section{Recurrence and Time Complexity}
    At the first glance, this cannot be solved using master theorem. Since the f(n) here is $\Theta(\log ^{k} n)$, and our master theorem ask for $n^d$. So it does not conform.
    To fix it, we need to draw a recurrence tree of,

   \begin{equation*}
    T(n)=\left\{\begin{array}{l}{\theta(1) \text { if } \mathrm{n}=1} \\ {T\left(\frac{n}{2}\right)+\theta\left(\log ^{k} n\right) \quad \text { if } n>1}\end{array}\right.
    \end{equation*}

    This table contains the information of our recurrence tree:

    % this align the table content to the middle, sure better hope this works
    \begin{tabu}  { | X[c] | X[c] | X[c] | X[c]|}
    \hline
        level&cost/problem&\# of nodes & cost/level \\
    \hline
        0&$\log ^{k} n$&1&$1(\log ^{k} n)$ \\
    \hline
        1&$\log ^{k} \frac{n}{2}$&1&$1*(\log ^{k} \frac{n}{2})$ \\
    \hline
        2&$\log ^{k} \frac{n}{4}$&1&$1*(\log ^{k} \frac{n}{4})$ \\
    \hline
        ...&...&...&... \\
    \hline
        i&$\log ^{k} \frac{n}{2^i}$&1& $1*(\log ^{k} \frac{n}{2^i})$ \\
    \hline
         ...&...&...&... \\
    \hline
        n &$\log ^{k} \frac{n}{2^n}$&1& $1*(\log ^{k} \frac{n}{2^n})$ \\
    \hline

\end{tabu}
So, what is our "n"? It turns out that if we keep dividing our problems, we will end up of a problem size of 1. Solve for $\frac{n}{2^i}=1\ \text{and}\ n= \log_{2}n$. And the the worst case is:\ $\log n* \log^{k}n = \log^{k+1}n$.(Note: all level share the time complexity of $\log^{k}n$)\\
Now, we need to prove the best case scenario,$\Omega$,and one of the ideas I had is to expand out or some people like to say "unrolling" the  recurrence.
Let us take\ $n=2^m \ and \ m=logn$.Rewrite the recurrence:
%note to my self * is like reference symbol
\begin{equation*}
\begin{split}
T(n)&=T(2^m)\\&=T(\frac{2^m}{2})+\log^{k} 2^m\\
    &=T(2^{m-1})+ (m\log2)^k\\&=T(2^{m-1})+ (m)^k\\
    \end{split}\end{equation*}

This looks a bit messy too, so lets simplify it further, letting $T(2^m)=f(m)$\\
Rewrite:
\begin{equation*}
\begin{split}
f(m)&=f(m-1)+m^k\\&=f(m-2)+(m-1)^k+m^k\\
    &=f(m-3)+(m-2)^k+(m-1)^k+m^k\\
    &=f(m-4)+(m-3)^k+(m-2)^k+(m-1)^k+m^k\\
    &=f(0)+...+f(m-4)+(m-3)^k+(m-2)^k+(m-1)^k+m^k\\
    \end{split}\end{equation*}
\text{Note: $n=2^m$,and that is why we went all the way to $f(0)$} \\
To be honest: we can also use this to prove our $O$, but I am late to the party,so...\\
Let's prove lower bound \ $\Omega$, like a computer scientist or a mathematician, let's write it out in English, so everyone knows what is going on here;\
We now have:
\begin{equation*}
\begin{split}
 f(m)&=f(0)+...+f(m-4)+(m-3)^k+(m-2)^k+(m-1)^k+m^k\\
        &=f(0)+1^k+2^k+3^k+.....+m^k \\
    \end{split}\end{equation*}
Now we simply need to prove the $\Omega$ of $1^k+2^k+3^k+.....+m^k$.
And, we can prove this by "throwing away half of the item"
\begin{equation*}
    \begin{split}
1^k+2^k+3^k+.....+m^k &> (\frac{m}{2})^k+ (\frac{m}{2}+1)^k +...+m^k\\
                     &>\underbrace{\left(\frac{m}{2}\right)^{k}+\left(\frac{m}{2}\right)^{k}+\ldots+\left(\frac{m}{2}\right)^{k}}_{\frac{m}{2} \text { terms }}\\
                     &=\frac{m}{2}\left(\frac{m}{2}\right)^{k}\\
                     &=(\frac{m}{2})^{k+1}\\
    \end{split}
\end{equation*}

Therefore,$f(m)=\Omega(m^{k+1})$,because $f(m)>c*(m^{k+1})$ and $c=\frac{1}{2^{k+1}}$\\
In other word, our $T(n)=\Omega(log^{k+1}n)$.We already proved our worst case using recursion tree $T(n)=O(log^{k+1}n)$,So we have $T(n)=\Theta(log^{k+1}n)$.
 \newpage
\section{Matrix Multiplication}
\begin{enumerate}[(a)] % (a), (b), (c), ...

\item Time complexity of parallel dot product

\begin{center}
\algrenewcommand\textproc{}
\begin{algorithm}
\renewcommand{\thealgorithm}{2.a):}
\caption{Multi-thread Dot product}
\begin{algorithmic}[1]

    \Function{d=PAR-DOT-PROD}{x,y}
\If{length(x)=1}
\State \textbf{return} $x\cdot y$
   % \\ \Return $\vars{x\cdot y}$
\EndIf
\State split $x =[x_L\ x_R]$ and $y=[y_L\  y_R]$
\State\textbf{spawn} $d_L=$ PAR-DOT-PROD$(x_L,y_L)$
\State$d_R=$ PAR-DOT-PROD$(x_R,y_R)$
\State\textbf{sync}
\State\textbf{return} $d_L + d_R$
\EndFunction
\end{algorithmic}
\end{algorithm}
\end{center}
To solve work,$T_1$,we need to cover up the spawn part of the code:
\begin{center}
   \textbf{spawn} $d_L=$ PAR-DOT-PROD$(x_L,y_L)$\\
   \textbf{spawn} $d_R=$ PAR-DOT-PROD$(x_R,y_R)$\\
\end{center}
So,what I see is it is doing 2 recursive calls, and the problem size is divided into 2 parts. So our a=2 and our b=2 in our recursive function,\ $T_1=2T(\frac{n}{2})+O(1)$ and our span is: $T_\infty=T(\frac{n}{2})+O(1)$. \\
Looks like we can use Master Theorem to solve this and get time complexity of this recurrence:

%This block is master theorem. Reuse-able.
$\text {Master theorem} \text { If } T(n)=a T(\lceil n / b\rceil)+O\left(n^{d}\right) \text { for some constants } a>0, b>1, \text { and } d \geq 0$ \text{,then}
\begin{equation*}
T(n)=\left\{\begin{array}{ll}{O\left(n^{d}\right)} & {\text { if } d>\log _{b} a\text{\ $\cdot \cdot \cdot $ case 1}} \\ {O\left(n^{d} \log n\right)} & {\text { if } d=\log _{b} a\text{\ $\cdot \cdot \cdot$ case 2}} \\ {O\left(n^{\log _{b} a}\right)} & {\text { if } d<\log _{b} a\text{\ $\cdot \cdot \cdot $ case 3}}\end{array}\right.
\end{equation*}\\
Therefore, \\
1.$T_1(n)=2T(\frac{n}{2})+O(1)$ has $a=2,b=2,d=0$,so $\log_{2}2=1>d=0$ and this is case 3 of master theorem: $T_1={O(n^{\log_{2}2})=O(n)}$. \\
2.$T_\infty(n)=T(\frac{n}{2})+O(1)$ has $a=1,b=2,d=0$,so $\log_{2}1=0=d=0$ and this is case 2 of master theorem: $T_\infty=O(n^0\log n)=O(\log n)$
\newpage
\item Use parallel dot product as subroutine\\
To figure out the algorithm, we try go back all the way to the understanding of the the basic idea of the dot product and its relationship with the matrix multiplication.

\begin{equation*}
c=a \cdot b = \sum_{i=1}^{n} a_{i} b_{i}
\end{equation*}

This might seem too abstract, so lets use example to help us:\footnote{"L" and "R" refer to Algorithm:2.a)}
\begin{equation*}
\begin{split}
a&=\left[\begin{array}{lll}{.70} & {.20} & {.10}\end{array}\right]\\
b&=\left[\begin{array}{lll}{.30} & {.40} & {.30}\end{array}\right]\\
a\cdot b&=\underbrace{(.70 \times .30)}_{L}+(.20 \times .40)+\underbrace{(.10 \times .30)}_{R}=.32\\
\end{split}
\end {equation*}
And how does dot product help us with the matrix multiplication:
For example if we have $n\times n$ matrix A,B,C and let C=AB and for me cause I like to think what looks like when I actually write in code: what is the right value to fill in my matrix C.
\begin{equation}
c_{i j}=\sum_{k=1}^{n} a_{i k} b_{k j}
\end{equation}
Visually,
%n by n matrix multiplication reusable
\begin{equation*}\left[ \begin{array}{cccc}{c_{11}} & {c_{12}} & {\cdots} & {c_{1 n}} \\ {c_{21}} & {c_{22}} & {\cdots} & {c_{2 n}} \\ {\vdots} & {\vdots} & {\ddots} & {\vdots} \\ {c_{n 1}} & {c_{n 2}} & {\cdots} & {c_{n n}}\end{array}\right]=\left[ \begin{array}{cccc}{a_{11}} & {a_{12}} & {\cdots} & {a_{1 n}} \\ {a_{21}} & {a_{22}} & {\cdots} & {a_{2 n}} \\ {\vdots} & {\vdots} & {\ddots} & {\vdots} \\ {a_{n 1}} & {a_{n 2}} & {\cdots} & {a_{n n}}\end{array}\right] \times \left[ \begin{array}{cccc}{b_{11}} & {b_{12}} & {\cdots} & {b_{1 n}} \\ {b_{21}} & {b_{22}} & {\cdots} & {b_{2 n}} \\ {\vdots} & {\vdots} & {\ddots} & {\vdots} \\ {b_{n 1}} & {b_{n 2}} & {\cdots} & {b_{n n}}\end{array}\right]\end{equation*}
What looks using an example:
%this is how you highlight a column
\begin{equation*}
    \left[ \begin{array}{ccc}
    .59 & \y.32 & .41 \\
    .31 & .36 & .25 \\
    .45 & .31 & .42\end{array}\right]
    =
    \left[ \begin{array}{ccc}
     \rowcolor{olive!20}
    .70 & .20 & .10 \\
    {.30} & {.60} & {.10} \\
    {.50} & {.10} & {.40}
    \end{array}\right]
    \times
    \left[ \begin{array}{c>{\columncolor{olive!20}}cc}
    {.80} & {.30} & {.50} \\
    {.10} & {.40} & {.10} \\
    {.10} & {.30} & {.40}
    \end{array}\right]
\end{equation*}

%block comment(Later I gave it some thought and do not think this is useful BUT keeping it because it is row major graph and it is fun)
\begin{comment}
I think I will use row major for my algorithm:
\begin{center}
\begin{tikzpicture}[>=stealth,x=0.75pt,y=0.75pt,yscale=-1,xscale=1.25,color=black,line width=1.25mm, opacity=1]
%xscale = 1.25 will increase horizontal size and spacing
%yscale with a negative sign makes the (0,0) at the top right corner

%boxes with numbers
 \foreach \x in  {0,...,4}
    \foreach \y in  {0,...,4 }
     \foreach \position in {(50*\x,50*\y)}
            { \draw[thick] \position rectangle +(30,30) node[pos=0.5] {(\y,\x)} ;}

%lines through the boxes
\tikzstyle{arrow} = [->,>=stealth,color=black,line width=1.25mm, opacity=1]
\foreach \x in {0,...,5}
\foreach \y in {0,...,4}
{\draw  (-20+50*\x,15+50*\y) -- (00+50*\x,15+50*\y);
}
\draw[arrow] (230,215) -- (270,215);  %arrow head at box (4,4)

%arcs at the end
\foreach \y in {0,...,3}
{\draw  (250,15+50*\y) arc(270:455:12.5);
\draw (-20,65+50*\y) arc(90:270:12.5);
\draw (-22,40+50*\y) -- (251, 40+50*\y);
}
\end{tikzpicture}
\end{center}
\end{comment}

%some new ideas
%Algorithm 2.b)
Referring to the idea from above and let's write out the algorithm:
\algrenewcommand\textproc{}
\begin{algorithm}
\renewcommand{\thealgorithm}{2.b):}
\caption{Matrix Multiplication}\Comment{$c_{i j}=\sum_{k=1}^{n} a_{i k} b_{k j}$}\\
\textbf{Input}: $n\times n$ Matrix A and B \\
\textbf{Output}: $n\times n$ Matrix C
\begin{algorithmic}[1]
\Function{PAR-MATMUL}{A,B}
\State $k= $A.row  \Comment{$\sum_{k=1}^{n} $}\\
\   \ \textbf{para for} i=0 to k
\State\textbf{para for} j=0 to k
\State $c_{ij}=$PAR-DOT-PROD($A_{ik},B_{kj}$) \\
\Comment{$a_{i k} b_{k j}$ \&$A_{ik}$,$B_{kj}$ represent corresponding row of A and and column of B like marked gray as above } \\
\ \ \textbf{end para for}
\State\Return C
\EndFunction
\end{algorithmic}
\end{algorithm}
\newpage
Complexity Analysis of \textbf{2.b)}: \\
If I remember correctly from class:
A compiler can implement each parallel for loop as a divide-and-conquer subroutine using nested parallelism.Cover up the \textbf{para for} when finding the work:

$T_{1}(n)$= $n*n*T^{'}_1(n)$, and$ T^{'}_1(n)$ represent the work of PAR-DOT-PROD(), so we have $T_{1}(n)$=$O(n^3)$

To find the span: the inner \textbf{parallel for} has complexity of
$O(\log n)$ and it dominate the constant time work of each iteration and the logic apply to outer \textbf{parallel for} as well. So,
$T_{\infty}(n)$=$O(\log{n})$

\end{enumerate}
\section{All-Pairs Shortest Paths}

\algrenewcommand\textproc{}
\begin{algorithm}
\renewcommand{\thealgorithm}{3:}
\caption{All-Pairs Shortest Paths}
\begin{algorithmic}[1]
\Function{C = APSP}{A}
\If {dimension(A) = 1}
\State \textbf{return} 0
\EndIf
\State partition A=$\left[ \begin{array}{ll}{A_{11}} & {A_{12}} \\ {A_{21}} & {A_{22}}\end{array}\right]$and C= $\left[ \begin{array}{ll}{C_{11}} & {C_{12}}\\ {C_{21}} & {C_{22}}\end{array}\right]$
into equal-sized quadrants
\State \hlc[red]{C11 = APSP(A11)}
\State \hl{\textbf{spawn} A12 = par-trop-matmul(A11, A12)}
\State \hl{A = par-trop-matmul(A21, A11}
\State \textbf{sync}
\State \hl{$A_{22}$= min\{$A_{22}$, par-trop-matmul($A_{21}, A_{12}$)\} }
\State \hlc[red]{$C_{22}$ = APSP($A_{22}$)}
\State \hl{\textbf{spawn} $A_{12}$ = par-trop-matmul($A_{12}$, $A_{22}$)}
\State \hl{$A_{21} = \text{par-trop-matmul}(A_{22}, A_{21})$}
\State \textbf{sync}
\State \hl{$A_{11} = min\{A_{11},\text{par-trop-matmul} (A_{12}, A_{21})\}$}
\State \textbf{return} C
\EndFunction
\end{algorithmic}
\end{algorithm}

After talking with professor Ballard about the question, I think I have an idea of how to do this. I learned that  $A_{22}$= $min$\{$A_{22}$, par-trop-matmul($A_{21}, A_{12}$)\} and $min\{A_{11},\text{par-trop-matmul} (A_{12}, A_{21})\}$
are like $C+AB$ and we can see this of having the same time complexity as our PAR-MATUAL. So,our work will be
\begin{equation*}
\begin{split}
  T_{\infty}(n)&=\underbrace{2T_1(\frac{n}{2})}_{APSP}+\underbrace{6P((\frac{n}{2}))}_{par-trop-matmul}\\
  &=2T_1(\frac{n}{2})+6*O((\frac{n}{2})^3) \ \  \text{Note: Ignore constant $\frac{6}{8}$}\\
  &=2T_1(\frac{n}{2})+O(n^3) \end{split}\end{equation*}

Looks like we can apply master theorem: $a=2, b=2,\text{and}\ d=3$ and our $\log_{2}2 =1$, which $d=3>1$ meaning case 1 of master theorem applies and $ T_{1}(n)=O(n^3).$

Span: \begin{equation*}
\begin{split}
  T_{\infty}(n)&=\underbrace{2T_1(\frac{n}{2})}_{APSP}+\underbrace{4P((\frac{n}{2}))}_{par-trop-matmul}\\
  &=2T_1(\frac{n}{2})+4*O(\log\frac{n}{2}) \ \  \text{Note: Ignore constant $4$ and $\log2=1$}\\
  &=2T_1(\frac{n}{2})+O(\log n) \end{split}\end{equation*}

Looks like master theorem is a no go. So let's use our dear old friend recurrence tree:

\begin{tabu}  { | X[c] | X[c] | X[c] | X[c]|}
    \hline
        level&cost/problem&\# of nodes & cost/level \\
    \hline
        0    &$\log ^{k} n$&1&$1(\log ^{k} n)$ \\
    \hline
        1&$\log ^{k} \frac{n}{2}$&2&$2*(\log ^{k} \frac{n}{2})$ \\
    \hline
        ...&...&...&... \\
    \hline
        i&$\log ^{k} \frac{n}{2^i}$& $2^i$ & $2^i*(\log ^{k} \frac{n}{2^i})$ \\
    \hline
         ...&...&...&... \\
    \hline
        $L=\log_{2}n$ &$1$& $2^L$ & n  \\
    \hline

\end{tabu}

OK,this is math. We need to do it no matter what! Let's add cost of each level up. Are you excited? If you start grading from top to bottom, probably not, but I am. We did this prove on $M_1$ of parallel merge sort, but I will clarify and format it.
\begin{equation*}
    \begin{split}
       T_\infty(n)&=\underbrace{\log _{2} n+2 \log _{2}\left(\frac{n}{2}\right)+4 \log _{2}\left(\frac{n}{4}\right)+8 \log _{2}\left(\frac{n}{8}\right)+\ldots}_{\log _{2} n \operatorname{tines}}\\
       &=\sum_{i=0}^{\log_{2}n} 2^i \log (\frac{n}{2^i})\\
       &=\sum_{i=0}^{\log _{2} n} 2^{i}\left(\log n-\log 2^{i}\right)\\
       &=\sum_{i=0}^{\log _{2} n} 2^{i} \log n-\sum_{i=0}^{\log _{2} n} 2^{i} \log 2^{i}\\
       &=\sum_{i=0}^{\log _{2} n} 2^{i} \log n -\sum_{i=0}^{\log _{2} n} i \cdot 2^{i}\\
       &=\log n\sum_{i=0}^{\log _{2} n} 2^{i}-\sum_{i=0}^{\log _{2} n} i \cdot 2^{i}
       \ \rightarrow\text{Geometric series:$
\sum_{i=1}^{n} a_{1} r^{i-1}=S_{n}=\frac{a_{1}\left(1-r^{n}\right)}{1-r} , r \neq 1
$}\\
       &= \log n \sum_{i=0}^{\log _{2} n}\left(2^{i-1}\right) \cdot 2-\sum_{i=0}^{\log _{2} n} i \cdot 2^{i}\\
       &= -2\log n +2n -\sum_{i=0}^{\log _{2} n} i \cdot 2^{i} \ \rightarrow\text{refer to James Stewart Calculus$\sum_{k=1}^{n} k 2^{k}=2\left(2^{n} n-2^{n}+1\right)$}\\
       &=-2\log n +2n-2 \cdot\left(2^{\log _{2} n} \cdot \log _{2} n-2^{\log _{2} n}+1\right)\\
       &=-2\log n +2n-2( n \log n-n+1)\\
       &=2\log n -2n\log n +4n -2 \\
       &=O(n)\\
    \end{split}
\end{equation*}

\end{document}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% CS637: Database-Backed Websites
% Copyright 2015 Pejman Ghorbanzade <pejman@ghorbanzade.com>
% Creative Commons Attribution-ShareAlike 4.0 International License
% More info: https://github.com/ghorbanzade/beacon
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section*{Question 2}

Explain why modified version of the \texttt{index.php} and \texttt{display\_result.php} files in previous question, are not following the Model View Control rules.
given below.
\begin{enumerate}
\item Controller code generates no HTML. Instead, it forwards to view files that do have HTML generation, or do a redirect (which has no HTML).
\item Calls to the model code occur only in controller code. The controller interprets incoming parameters and assembles the data the view needs before forwarding to view code.
\end{enumerate}
Modify \texttt{index.php} and \texttt{display\_result.php} files to comply with MVC rules. Argue which code should be designated as control code, and which code should be view code. Note that there is no model code here.

\subsection*{Solution}

File \texttt{index.php} and \texttt{display\_result.php} in previous question do not comply with MVC requirements in that HTML codes are generated within both files that contain controller code as well.

To modify the program such that it follows MVC requirements, the file structure depicted in Figure \ref{fig21} is proposed. As is shown, \texttt{header.php} and \texttt{footer.php} view files are placed in a separate \texttt{view} folder and \texttt{index.php} files serve as controllers that, after preparing data, call view files \texttt{showForm.php} and \texttt{display\_result.php} for HTML generation.

\begin{figure}[H]\centering
\tikzstyle{every node}=[anchor=west]
\tikzstyle{file}=[]
\begin{tikzpicture}[%
  grow via three points={one child at (0.5,-0.7) and
  two children at (0.5,-0.7) and (0.5,-1.4)},
  edge from parent path={(\tikzparentnode.south) |- (\tikzchildnode.west)}]
  \node {root}
    child { node {result}
      child { node [file] {display\_result.php} }
      child { node [file] {index.php} }
    }
    child [missing] {}
    child [missing] {}
    child { node {view}
      child { node [file] {header.php} }
      child { node [file] {footer.php} }
    }
    child [missing] {}
    child [missing] {}
    child { node {form}
      child { node [file] {showForm.php} }
    }
    child [missing] {}
    child { node [file] {index.php} }
    ;
\end{tikzpicture}
\caption{Program file structure compliant to MVC conventions}\label{fig21}
\end{figure}

Following is the content for each file in this new file structure.

\begin{enumerate}
\item file \texttt{/view/header.php}
\lstset{language=php,tabsize=2}
\begin{lstlisting}
<!DOCTYPE html>

	<title>Future Value Calculator</title>
	<link rel="stylesheet" type="text/css" href="main.css">

Future Value Calculator

\end{lstlisting}

\item file \texttt{/view/footer.php}
\lstset{language=php,tabsize=2}
\begin{lstlisting}

\end{lstlisting}

\item file \texttt{/index.php}
\lstset{language=php,tabsize=2}
\begin{lstlisting}
<?php
	//set default value of variables for initial page load
	if (!isset($investment)) { $investment = ''; }
	if (!isset($interest_rate)) { $interest_rate = ''; }
	if (!isset($years)) { $years = ''; }
	if (!empty($error_message)) {
		echo "
".htmlspecialchars($error_message)."
";
	}
	include 'form/showForm.php';
\end{lstlisting}

\item file \texttt{/form/showForm.php}
\lstset{language=php,tabsize=2}
\begin{lstlisting}
<form action="result/" method="post">

			Investment Amount
			<input type="text" id="investment" name="investment" value="<?php echo $investment; ?>" tabindex="1">

			Yearly Interest Rate
			<input type="text" id="interest_rate" name="interest_rate" value="<?php echo $interest_rate; ?>" tabindex="2">

			Number of Years
			<input type="text" id="years" name="years" value="<?php echo $years; ?>" tabindex="3">

		<input type="submit" value="Calculate" tabindex="4">

</form>
\end{lstlisting}

\item file \texttt{/result/index.php}
\lstset{language=php,tabsize=2}
\begin{lstlisting}
<?php
	// get the data from the form
	$investment = filter_input(INPUT_POST, 'investment', FILTER_VALIDATE_FLOAT);
	$interest_rate = filter_input(INPUT_POST, 'interest_rate', FILTER_VALIDATE_FLOAT);
	$years = filter_input(INPUT_POST, 'years', FILTER_VALIDATE_INT);
	// validate investment
	if ($investment === FALSE ) {
		$error_message = 'Investment must be a valid number.';
	} else if ( $investment <= 0 ) {
		$error_message = 'Investment must be greater than zero.';
	// validate interest rate
	} else if ( $interest_rate === FALSE )  {
		$error_message = 'Interest rate must be a valid number.';
	} else if ( $interest_rate <= 0 ) {
		$error_message = 'Interest rate must be greater than zero.';
	// validate years
	} else if ( $years === FALSE ) {
		$error_message = 'Years must be a valid whole number.';
	} else if ( $years <= 0 ) {
		$error_message = 'Years must be greater than zero.';
	} else if ( $years > 30 ) {
		$error_message = 'Years must be less than 31.';
	// set error message to empty string if no invalid entries
	} else {
		$error_message = '';
	}
	// if an error message exists, go to the index page
	if ($error_message != '') {
		include('index.php');
		exit();
	}
	// calculate the future value
	// Developing investment class
	class Investment {
		private $amount;
		private $interest;
		private $year;
		public function __construct($amount, $interest, $year) {
			$this->amount = $amount;
			$this->interest = $interest;
			$this->year = $year;
		}
		public function findFutureValue() {
			$future_value = $this->amount;
			for ($i = 1; $i <= $this->year; $i++) {
				$future_value += $future_value * ($this->interest) * 0.01;
			}
			return $future_value;
		}
		public function getAmount() {
			return $this->amount;
		}
		public function getInterest() {
			return $this->interest;
		}
	}
	// Object instantiation and use
	$investment = new Investment($_POST['investment'], $_POST['interest_rate'], $_POST['years']);
	$future_value = $investment->findFutureValue();
	// apply currency and percent formatting
	$investment_f = '$'.number_format($investment->getAmount(), 2);
	$yearly_rate_f = $investment->getInterest().'%';
	$future_value_f = '$'.number_format($future_value, 2);
	include 'display_results.php';
?>
\end{lstlisting}

\item file \texttt{/result/display\_result.php}
\lstset{language=php,tabsize=2}
\begin{lstlisting}
<!DOCTYPE html>

	<title>Future Value Calculator</title>
	<link rel="stylesheet" type="text/css" href="main.css">

Future Value Calculator

		Investment Amount:
		<?php echo $investment_f; ?>

		Yearly Interest Rate:
		<?php echo $yearly_rate_f; ?>

		Number of Years:
		<?php echo $years; ?>

		Future Value:
		<?php echo $future_value_f; ?>

\end{lstlisting}
\end{enumerate}


\chapter{The computing Miniproject}
\label{chap:miniproj}

We have talked a lot about workflows and confronting models with data.
It's time to do something concrete with all the techniques you have learnt!

The CMEE Miniproject gives you an opportunity to try the ``whole nine yards''
of developing and implementing a workflow and delivering a ``finished
product'' --- where you ask and answer a scientific question in biology
(potentially involving multiple sub-questions/hypotheses).

The miniproject will give you an opportunity to perform a ``dry run''
of executing your actual dissertation project, and you may use it to
trial some of the techniques and/or explore some of the data/theory
you might use in your Dissertation project.

\section {Objectives}

{\bf The general question you will address is:}

\begin{center}

\it What mathematical model best fits an empirical dataset?

\end{center}

You may think of this as testing a set of alternative hypotheses ---
arguably every alternative hypothesis is nothing but an alternative model to
describe an observed phenomenon (more on this in the Primer on Model
Fitting Lectures delivered during the Miniproject week).

You may choose any dataset and set of alternative models, provided that
the work can feasibly be done in the time you have for your miniproject
(see the CMEE Guidebook for the submission deadline). You may choose a
problem and dataset that is a related to, or even preliminary work for
your main Masters project (to give you a reality/feasibility) check.

{\it Please read the papers in the Readings and Resources section of
this chapter} --- these will help you make a decision about what data
and what models to use.

You will also be give lectures on model fitting in Ecology ad Evolution
at the start of the Miniproject week.

The Miniproject must satisfy the following criteria:
\begin{enumerate}

	\item It should employ all the biological computing tools you
	have learned so far: shell (bash) scripting, git, \LaTeX, R, and
	Python. Using these tools, you will build a workflow that starts with
	the data and ends with a written report (in \LaTeX).

	\item {\it At least} two different models (hypotheses) must be fitted
	to the data. The models should be fitted and selected using an
	appropriate method (e.g., non-linear least squares for model fitting and
	the Akaike Information Criterion for model selection, respectively).
	You will be given a primer on model fitting before you start on your
	Miniproject.

	\item The project should be fully reproducible --- a script should
	glue the workflow together and run it. I should be able to run just
	this script to get everything to work, from data processing to model
	fitting to plotting (e.g., in {\tt R}) to compilation of the \LaTeX
	written report. ({\it More detailed instructions on this below}).

\end{enumerate}

If you are unable to find a dataset and/or problem that you would like
to tackle, you may use the ``TPC problem'' given below.

\section{The Report}

	The report should,
	\begin{compactitem}
		\item be written in \LaTeX~ using the {\tt article} document class,
		in 11pt (any font will do, within reason!)

		\item be double-spaced, with {\it continuous} line numbers

		\item have a title, author name with affiliation and wordcount
		(next point) on a separate title page.

		\item have an introduction with objectives of the study, and
		appropriate additional sections such as methods, data, results,
		discussion, etc.
		\item should contain in the Methods a sub-section called
		``Computing languages'' which states briefly how each of the three
		scripting language (bash, R, Python) was used, and a justification
		of why.
		\item must contain $\leq$3500 words {\it excluding the contents of
		the title page, references, and Figure or Table captions+legends};
		there should be a word count at the beginning of the document (I
		suggest using {\tt texcount}).

		\item have references properly cited using bibtex.

	\end{compactitem}

For the writeup, you probably should read the {\it general} ( {\it
not} word count, formatting etc.) dissertation writing guidelines given
in the Silwood Masters Student Guidebook.

\section{Patching together your computing workflow components}

Use Python and/or bash scripting for this. If using bash, call it  {\tt
run\_MiniProject.sh} and if using Python, called it {\tt
run\_MiniProject.py}. It should run all the components of the project's
workflow, including compilation of the \LaTeX document. Look back at
the notes to see how you would run these different components. For
example, we have covered how to run {\tt R} and compile \LaTeX using {\tt
subprocess} in python.

\section{Submission}

Commit and push all your work to your bitbucket repository using a
directory called {\tt CMEEMiniProject} at the same level as the {\tt
Week1}, {\tt Week2} etc. directories, by the Miniproject deadline given
in your CMEE course guidebook.

At this stage, I am not going to tell you how to organize your project
--- that's one of my marking criteria (see next section).

\subsection {Marking criteria}

{\it Equal weightage will be given to the code+workflow and writeup
components --- each component will be marked to a max of 100 pts and
then rescaled to a single mark / 100 using equal weightage}

I will be looking for the following while assessing your submission:

\begin{compactitem}

	\item A well-organized project where code, results, data, etc., are
	easy to locate, inspect, and use. In the project's README also
	include:
	\begin{itemize}
	\item Any dependencies or special packages I should be aware of
	\item What each package you used is for
	\item Version of each language used
	\end{itemize}

	\item A python or bash script called {\tt run\_MiniProject.py} or {\tt
	run\_MiniProject.sh} respectively, that runs the project

	\item A report that contains all the components indicated above in
	``The Report'' subsection --- I will be looking for some original
	thought and synthesis in the Intro and Discussion

	\item Quality of the presentation of the graphics and tables in your
	report, as well as any plots showing model fits to the data.

\end{compactitem}

The marking criteria you may refer to is the summative marking criteria
given in Appendix \ref{chap:Appendices} titled ``MARKING CRITERIA for
EXAMS and ESSAYS and COURSEWORK''.

\section {A Candidate Problem: Fitting TPCs}

One choice you have is to use a large dataset that we can provide to
address the following question:

{\it How well do different mathematical models, based upon biochemical
principles vs. phenomenological ones, fit to the thermal responses of
metabolic traits (rates)?}

This is currently a ``hot'' (no pun intended!) topic in biology, with
both ecological and evolutionary consequences, as we discussed in the
modelling lecture. On the {\it ecological side}, because the
temperature-dependence of metabolic rate sets the rate of intrinsic
$r_{max}$ (papers by Savage et al., Brown et al.) as well as
interactions between species, it has a strong effect on population
dynamics. In this context, note that 99.9\% of life on earth is
ectothermic! On the {\it evolutionary side}, the temperature-dependence
of fitness and species interactions also means that warmer environments
may have stronger rates of evolution. This may be compounded by the
fact that mutation rates may also increase with temperature (papers by
Gillooly et al.).

\subsection{The Data}

The dataset is called {\tt BiotraiTPCdata.csv} and contains hundreds of
``thermal responses'' for growth, respiration and photosynthesis rates
in plants and bacteria (both aquatic and terrestrial). These data were
collected through lab experiments across the world, and compiled by
various people over the years. A subset of this BioTraits database used
as an example in the Databases section of Chapter \ref{chap:pythonII}.

\subsection {The Models}

There are multiple models that might best describe these data.

The Schoolfield model (paper is in {\tt Readings} directory) is one
mechanistic option (\ref{fig:schoolf}) that is based upon
thermodynamics and enzyme kinetics:

\begin{equation} \label{eq:schoolf}
	\begin{aligned}
	  B = \frac{B_0 e^{\frac{-E}{k} (\frac{1}{T} - \frac{1}{283.15})}}
    { 1 + e^{\frac{E_l}{k} (\frac{1}{T_l} - \frac{1}{T})} +
    e^{\frac{E_h}{k} (\frac{1}{T_h} - \frac{1}{T})}}
	\end{aligned}
\end{equation}

{\it Please also have a look at the Delong et al 2017 paper, which lists
this and other mechanistic TPC models} (see the Readings and
Resources section). Youy may choose additional models listed in that
paper for comparison, if you want.

Here, $k$ is the Boltzmann constant ($8.617 \times 10^{-5}$ eV $\cdot$
K$^{-1}$), $B$ the value of the trait at a given temperature $T$ (K) (K
= $\degree$C + 273.15), while $B_0$  is the trait value at 283.15 K
(10\degree C) which stands for the value of the  growth rate at low
temperature and controls the vertical offset of the curve. $E_l$ is the
enzyme's low-temperature de-activation energy (eV) which controls the
behavior of the enzyme (and the curve) at very low temperatures, and
$T_l$ is the at which the enzyme is  50\% low-temperature deactivated.
$E_h$ is the enzyme's high-temperature de-activation energy (eV) which
controls the behavior of the enzyme (and the curve) at very high
temperatures, and $T_h$ is the at which the enzyme is  50\%
high-temperature deactivated. $E$ is  the activation energy (eV) which
controls the rise of the curve up to the peak in the ``normal operating
range'' for the enzyme (below the peak of the curve and above $T_h$).

\begin{figure}\label{fig:schoolf}
		\centering \includegraphics[width=.6\textwidth]{SchoolfEx.pdf}
		\caption{Example of a unimodal thermal response curve for a
		biological trait with the Schoolfield model fitted (Equation
		\ref{eq:schoolf}).}
\end{figure}

In many cases, a simplified Schoolfield model would be more appropriate
for thermal response data, because low temperature inactivation is
weak, or is undetectable in the data because low-temperature
measurements were not made.

\begin{equation} \label{eq:schoolfHi}
	\begin{aligned}
	  B = \frac{B_0 e^{\frac{-E}{k} (\frac{1}{T} - \frac{1}{283.15})}}
    { 1 +  e^{\frac{E_h}{k} (\frac{1}{T_h} - \frac{1}{T})}}
	\end{aligned}
\end{equation}

In other cases, a different simplified Schoolfield model would be more
appropriate, because high temperature inactivation was not detectable
in the data because measurements were not made at sufficiently high
temperatures:

\begin{equation} \label{eq:schoolfLo}
	\begin{aligned}
	  B = \frac{B_0 e^{\frac{-E}{k} (\frac{1}{T} - \frac{1}{283.15})}}
    { 1 +  e^{\frac{E_l}{k} (\frac{1}{T_l} - \frac{1}{T})}}
	\end{aligned}
\end{equation}

In addition, there are phenomenological alternatives. These include the
general cubic polynomial model:

\begin{equation}\label{eq:cubic}
	B = B_0 + B_1 T + B_2 T^2 + B_3 T^3
\end{equation}
with the parameters $B_0$, $B_1$, $B_2$ and $B_3$ not having any
mechanistic underpinnings. Note that the cubic model has the same
number of parameters as the the reduced Schoolfield model
\ref{eq:schoolfH}. The parameter ($T$) of the cubic model (Equation
\ref{eq:cubic}) are in $\degree$C.

{\it All the above parameters and equations are in SI units}.

\subsection {Fitting models to the TPC data}

You will use Nonlinear Least Squares (NLLS) to fit the alternative
models above (eqns \ref{eq:schoolf} -- \ref{eq:cubic}) to data,
followed by model selection with AIC and BIC (also known as the
Schwartz Criterion --- {\it read the Johnson and Omland 2005 paper}).

\subsection {The Workflow}

You will build a workflow that starts with the data and ends with a
report written in \LaTeX. I suggest the following components and
sequence in your workflow (you can choose to do it differently!):

\begin{enumerate}\itemsep0pt
	\item A Python or R script that imports the data and prepares it for
	NLLS fitting, with the following features:
		\begin{compactitem}
			\item It should create unique ids so that you can identify unique
			thermal responses (what does this mean?)
			\item It should filter out datasets with less than 5 data points
			(why?)
			\item It should deal with negative and zero trait values (why?)
			\item The script should add columns containing starting values
			of the model parameters for the NLLS fitting (how will you get
			these?)
			\item Save the modified data to a new csv file.
		\end{compactitem}
	\item A Python script that opens the new modified dataset (from
	step 1) and does the NLLS fitting, with the following features:
			\begin{compactitem}
				\item Uses {\tt lmfit} --- look up submodules {\tt minimize},
				{\tt Parameters}, {\tt Parameter}, and {\tt report\_fit}.\\
				{\it Have a look through}
				\url{http://lmfit.github.io/lmfit-py}, especially
				\url{http://lmfit.github.io/lmfit-py/fitting.html#minimize}\\

				You will have to install lmfit using {\tt pip} or {\tt
				easy\_install} - use {\tt sudo} mode.
				In addition to the lmfit example in class, you may want to look
				for others online.

				\item Will use the {\tt try} construct because not all runs
				will converge. Recall the {\tt try} example from R

				\item The more thermal response curves you are able to fit, the
						better --- that is part of the challenge!

				\item Will calculate AIC, BIC, R$^{2}$, and other statistical
				measures of fit (you decide what you want to include)

				\item Will export the results to a csv that the plotting R
				script (next item) can read.

		\end{compactitem}

	\item A {\tt R} script that imports the results from the previous
	step and plots every thermal response with both models (or none, if
	nothing converges) overlaid --- all plots should be saved in a
	single separate sub-directory. {\it Use {\tt ggplot} for pretty
	results!}

	\item \LaTeX~source code that generates your report.

	\item A Python script (saved in {\tt Code}) called {\tt
	run\_MiniProject.py} that runs the whole project, right down to
	compilation of the \LaTeX~ document.

\end{enumerate}

Doing all this may seem a bit scary at the start. However, you need to
approach the problem systematically and methodically, and you will be
OK. I suggest the following to get you started:

\begin{compactitem}

	\item Explore the data in R and get a preliminary version of the
	plotting script without the fitted models overlaid worked out. That
	will also give you a feel for the data.

	\item Explore the two models -- be able to plot them. Write them as
	functions in your {\tt python} script, because that's where you
	will use them (step 2 above) (you can use {\tt matplotlib} for
	quick and dirty plotting and then suppress those code lines later).

	\item Figure out, using a minimal example (say, with one,
	"nice-looking" thermal response dataset) to see how the {\tt python}
	{\tt lmfit} module works. Kartik can help you work out the minimal
	example, including the usage of {\tt try} to catch errors in case the
	fitting doesn't converge.

	\item One thing to note is that you will need to do the NLLS fitting
	on the logarithm of the the function to facilitate convergence ---
	please ask me or Sam Thompson if you need help on this.

\end{compactitem}

\section{Readings and Resources}

All these papers are in pdf format in the {\tt Readings} directory on the CMEE master repository.

\begin{compactitem} \itemsep6pt
\item Levins, R. (1966) The strategy of model building in population
biology. Am. Sci. 54, 421--431.

\item Johnson, J. B. \& Omland, K. S. (2004) Model selection in ecology
and evolution. Trends Ecol. Evol. 19, 101--108.

\item Bolker, B. M. et al.  (2013) Strategies for fitting nonlinear ecological models in R, AD Model Builder, and BUGS. Methods Ecol. Evol. 4, 501--512 .

\item Some illustrative examples of (nonlinear) model-fitting to
ecological/evolutionary data
\url{https://groups.nceas.ucsb.edu/non-linear-modeling/projects}

\item For the suggested fitting TPCs project: Papers in the {\tt
Temperature\_response\_papers} directory within , but especially :

\begin{itemize}

\item Schoolfield, R. M., Sharpe, P. J. \& Magnuson, C. E. (1981) Non-linear
regression of biological temperature-dependent rate models based on
absolute reaction-rate theory. J. Theor. Biol. 88, 719--31.

\item DeLong, J. P. et al. (2017) The combined effects of reactant kinetics and enzyme stability explain the temperature dependence of metabolic rates. Ecol. Evol. 7, 3940--3950 .

\end{itemize}

\end{compactitem}