\documentclass[11pt]{article}

\title{Clebsch-Gordan coefficients\footnote
{Copyright 2007 by Edmond Orignac.
This file is released under the terms of the GNU General Public License, version 2.}}

\begin{document}

\maketitle

\section{Wigner recoupling coefficients}

The Maxima script \texttt{clebsch\_gordan.mac} defines the $3j,6j$ and $9j$
 coefficients that are used in the theory of addition of angular momenta
in quantum mechanics\cite{landau_mecaq,messiah_field_chapter}.

% The Book of Messiah is available from Dover in an english translation.
% Angular momenta and Wigner coefficients can be found in Appendix C.
% An online reference is:
% Weisstein, Eric W. "Wigner 9j-Symbol." From MathWorld--A Wolfram Web Resource.% http://mathworld.wolfram.com/Wigner9j-Symbol.html

\subsection{Wigner $3j$ coefficients}

The Maxima function \texttt{wigner\_3j(j1,j2,m1,m2,j,m)} computes the $3j$
coefficient of Wigner.

The Wigner $3j$ coefficient appears in the addition of a pair of angular
momenta in Quantum Mechanics.
It is defined as\cite{landau_mecaq,messiah_field_chapter}:
\begin{equation}
  \label{eq:3j-def}
  \left(\begin{array}{ccc} j_1 & j_2 & j \\ m_1 & m_2 & m\end{array} \right) = (-1)^{j_1-j_2-m} \frac 1 {\sqrt{2j+1}} \langle j_1,m_1; j_2, m_2 | j,-m\rangle,
\end{equation}

where $ \langle j_1,m_1; j_2, m_2 | j,m\rangle$ is the
Clebsch-Gordan coefficient. The Clebsch-Gordan coefficient is used to
construct the state of total angular momentum $j$ and total projection
of angular momentum $m$ as a linear combination of states of angular momenta
$j_1$ and $j_2$ and respective projections $m_1$ and $m_2$.
One has:
\begin{equation}
  |j,m\rangle = \sum_{m_1,m_2} \langle j_1,m_1;j_2,m_2|j,m\rangle |j_1,m_1\rangle  |j_2,m_2\rangle
\end{equation}
The advantage of working with the $3j$ coefficients instead of the
Clebsch-Gordan coefficients is that the former are more symmetric\cite{landau_mecaq}.

The $3j$ coefficient is computed by application of
Eq. (27.9.1) p. 1006 of \cite{abramowitz_math_functions}.

\subsection{Wigner $6j$ coefficients}

The Maxima function \texttt{wigner\_6j(j1,j2,j3,j4,j5,j6)} computes the $6j$
coefficient of Wigner.

The Wigner $6j$ coefficients appears in the addition of three angular momenta.
When one is adding three angular momenta, one can form a first
pair of angular momenta, add them together to form a new angular momentum
using the $3j$ coefficients, and add the resulting angular momenta with the
remaining angular momentum\cite{landau_mecaq,messiah_field_chapter}.
There are 3 different ways of grouping the angular momenta, which leads to
different representations of the total angular momentum.
The Wigner $6j$ coefficients are used to pass from one representation to the
other.

The notation for the $6j$ symbols is:
\begin{equation}
  \left\{\begin{array}{ccc}j_1 & j_2 & j_3 \\ j_4 & j_5 & j_6\end{array} \right\}
\end{equation}

The $6j$ coefficient is computed by application of the formula  p. 513 Eq. (108,10) of \cite{landau_mecaq} or the equivalent formula  p. 915, Eq. (36) of \cite{messiah_field_chapter}.

\subsection{Wigner $9j$ coefficients}

The function\texttt{wigner\_9j(a,b,c,d,e,f,h,i,j)} computes
the $9j$ coefficient of Wigner.

The $9j$ coefficients appears in the addition of four angular momenta.
To add these angular momenta, one can first form two pairs of angular
momenta and add them together to form the two resulting angular momenta
and then add together the two resulting angular momenta.
There are different ways to form the two pairs of angular momenta, and
the $9j$ coefficient is used to transform from one representation to
the other\cite{landau_mecaq,messiah_field_chapter}.

The notation for the $9j$ coefficient is:
\begin{equation}
  \left\{\begin{array}{cccc} a & b & c \\ d & e & f \\ h & i & j \end{array} \right\}
\end{equation}

The $9j$ coefficient is computed by applying Eq. (41) p. 917, of \cite{messiah_field_chapter}.

\section{Limitations}

The $3nj$ with $n\ge 4$ (addition of $n+1$ angular momenta) are not
implemented. The theory of these coefficients
can be found in the book Edmonds Angular momentum
in quantum Mechanics (Princeton University Press).

Various other coefficients can be defined that are related to the $3nj$
coefficients such as the Racah $W$ or $X$ coefficients\cite{messiah_field_chapter}. These coefficients are not implemented.

As the computation is done using exact formulas, it will break down if the
angular momenta that are entered are too large. For these cases, one should
implement recurrence formulas or use asymptotic expansions.

\begin{thebibliography}{1}

\bibitem{abramowitz_math_functions}
{\sc Abramowitz, M., and Stegun, I.}
\newblock {\em Handbook of mathematical functions}.
\newblock Dover, New York, 1972.

\bibitem{landau_mecaq}
{\sc Landau, L.~D., and Lifshitz, E.~M.}
\newblock {\em Quantum Mechanics : non-relativistic theory}.
\newblock perg, New York, 1962.

\bibitem{messiah_field_chapter}
{\sc Messiah, A.}
\newblock {\em M\'ecanique Quantique}, vol.~2.
\newblock Dunod, Paris, 1995.

\end{thebibliography}

\end{document}


\documentclass[12pt]{article}
\usepackage[]{algorithm2e}
\usepackage{ amssymb }
\usepackage{amsmath}
\usepackage[hyphens]{url}
\usepackage{listings}
\usepackage{xcolor}

\definecolor{listinggray}{gray}{0.9}
\definecolor{lbcolor}{rgb}{0.9,0.9,0.9}
\lstset{
	backgroundcolor=\color{lbcolor},
	tabsize=4,
	language=C++,
	captionpos=b,
	tabsize=3,
	frame=lines,
	numbers=left,
	numberstyle=\tiny,
	numbersep=5pt,
	breaklines=true,
	showstringspaces=false,
	basicstyle=\footnotesize,
	%  identifierstyle=\color{magenta},
	keywordstyle=\color[rgb]{0,0,1},
	commentstyle=\color{Darkgreen},
	stringstyle=\color{red}
}

\begin{document}

\title{Project 01 CS-790}
\author{Brandon Bluemner}
\date{2017}
\maketitle
% //Start
\begin{abstract}
Analysis of c++11 implementation of Dijkstra's algorithm.

\end{abstract}

% ==========================================================================================================================
%  Algorithm Section 1
% ==========================================================================================================================
\section[Algorithm]{Algorithm}

Algorithm taken from class with some additional information for wiki \cite{ Wikipedia}.
\begin{algorithm}

\KwData{  \textit{source:} source node, \textit{$goal_v$:} collection or goals,\\ \textit{cost:} function that returns cost between edge $u \to u_i$, \\ \textit{succ:} function that returns the neighbors of node u   }
\KwResult{ \textit{path:} collection to store path in}
\SetKwProg{Fn}{Function}{}{}
\Fn{run(source, $goal_v$, path, cost, succ)}{
	$I$ u;
	$T$ \_cost $\leftarrow \infty$;
	$frontier.push( {0,source})$ // priority que \\
	$current.insert(source)$ //keep track of current node in frontier \\
	$map<I,T> g $ // This will keep track of cost for node I cost T\\
	$g[source]$  $\leftarrow$  0;
	$I _goal$ $\leftarrow goal_v.at(0)$\\
	\While{ $frontier.empty() = false$}{
		$u$ $\leftarrow$ frontier.top() // get next node \\
		$frontier.pop()$  // move remove the next from the que \\
		$current.erase(current.find(u))$ // remove u from current \\
		\For{$auto goal$ $\in$ $goal_v$}{
			\If{$ u = goal$ and $g[goal]<$\_cost}{
				\_cost  $\leftarrow g[goal]$;
				\_goal  $\leftarrow goal$ \\
			}
		}
		$explored.insert(u)$;
		$vector<Edge> successor$; $ succ(u,successor)$;
		\\
			\For{$ auto$ $s : successor $} {
				$I ui \leftarrow s.get_target()$\\
				// ui not in E and ui not in f\\
				\If{$explored.find(ui) = explored.end() and current.find(ui) = current.end()$}{
						$g[ui] \leftarrow g[u] + cost(u,ui) frontier.push({g[ui],ui})$\\
						$current.insert(ui)$;
						$path[ui] \leftarrow u$
				}
				\ElseIf{$current.find(ui) \neq current.end()$}{
					\If{ $g[u] + cost(u,ui) < g[ui]$ }{
						$g[ui] \leftarrow g[u] + cost(u,ui)$;
						$path[ui] \leftarrow u$
					}
				}
				\ElseIf{$explored.find(ui) \neq explored.end()$}
				{
					\If{ $g[u] + cost(u,ui) < g[ui] $}{
						$explored.erase(explored.find(ui))$;
						$frontier.push({g[ui],ui})$;
						$current.insert(source)$;
					}
				}
		}
	}
}
\end{algorithm}
\clearpage
% ==========================================================================================================================
%  Implementation Section 2
% ==========================================================================================================================
\section[Implementation]{Implementation}
The implementation of Dijkstra utilizes several of the c++11 standard library data structures,
Below is how the data structures are defined and the running time of each function\cite{ northwestern}.
The core algorithm will be implemented under the betacore namespace.
%----------------------------------------
%	Std::Vector
% ---------------------------------------
\subsection{std::vector}
\begin{lstlisting}
	template<
    class T,
    class Allocator = std::allocator<T>
> class vector;
\end{lstlisting}
\begin{tabular}{ l l l }
\textbf{Constructors} & \textbf{Description} & \textbf{Big - OH}\\
vector$<$T$>$ v; & Make an empty vector. & O(1)\\
vector$<$T$>$ v(n); & Make a vector with N elements. & O(n)\\
vector$<$T$>$ v(n, value); & Make a vector with N elements, initialized to value. & O(n)\\
vector$<$T$>$ v(begin, end); & Make a vector and copy the elements from begin to end & O(n)\\
\end{tabular}
\\
\\
\\
\begin{tabular}{ l l l }
\textbf{Accessors} & \textbf{Description} & \textbf{Big - OH}\\
v[i]; & Return (or set) the I'th element. & O(1)\\
v.at(i); & Return (or set) the I'th element, with bounds checking. & O(1)\\
v.size(); & Return current number of elements. & O(1)\\
v.empty(); & Return true if vector is empty. & O(1)\\
v.begin(); & Return random access iterator to start. & O(1)\\
v.end(); & Return random access iterator to end. & O(1)\\
v.front(); & Return the first element. & O(1)\\
v.back(); & Return the last element. & O(1)\\
v.capacity(); & Return maximum number of elements. & O(1)\\
\end{tabular}
\\
\\
\\
\begin{tabular}{ l l l }
\textbf{Modifiers} & \textbf{Description} & \textbf{Big - OH}\\
v.push\_back(value); & Add value to end. & O(1) (amortized)\\
v.insert(iterator, value); & Insert value at the position indexed by iterator. & O(n)\\
v.pop\_back(); & Remove value from end. & O(1)\\
v.erase(iterator); & Erase value indexed by iterator. & O(n)\\
v.erase(begin, end); & Erase the elements from begin to end & O(n)\\
\end{tabular}
\clearpage
%----------------------------------------
%	Std::priority queue
% ---------------------------------------
\subsection{std::priority\_queue}\label{pq}
\begin{tabular}{ p{5cm} p{7cm} p{5cm}}
\textbf{Constructors} & \textbf{Description} & \textbf{Big - OH}\\
priority\_queue$<$T,  container$<$T$>$,  comparison$<$T$>$ $>$ q & Make an empty priority queue using the given container to hold values, and comparison to compare values. container defaults to vector$<$T$>$ and comparison defaults to less$<$T$>$. & O(1)\end{tabular}
\\
\\
\\
\begin{tabular}{ l l l }
\textbf{Accessors} & \textbf{Description} & \textbf{Big - OH}\\
q.top(); & Return the ``biggest'' element. & O(1)\\
q.size(); & Return current number of elements. & O(1)\\
q.empty(); & Return true if priority queue is empty. & O(1)
\end{tabular}
\\
\\
\\
\begin{tabular}{ l l l }
\textbf{Modifiers} & \textbf{Description} & \textbf{Big - OH}\\
q.push(value); & Add value to priority queue. & O(log n)\\
q.pop(); & Remove biggest value. & O(log n)\\
\end{tabular}
\clearpage
%----------------------------------------
%	Std::Set
% ---------------------------------------
\subsection{std::set} \label{stdset}
\begin{tabular}{ p{5cm} p{7cm} p{5cm}}
\textbf{Constructors} & \textbf{Description} & \textbf{Big - OH}\\
set $<$type, compare$>$ s; & Make an empty set. compare should be a binary predicate for ordering the set. It's optional and will default to a function that uses operator$<$. & O(1)\\
set $<$type, compare$>$ s(begin, end); & Make a set and copy the values from begin to end. & O(n log n)
\end{tabular}
\\
\\
\\
\begin{tabular}{ p{5cm} p{7cm}  p{5cm}}
\textbf{Modifiers} & \textbf{Description} & \textbf{Big - OH}\\
s.find(key) & Return an iterator pointing to an occurrence of key in s, or s.end() if key is not in s. & O(log n)\\
s.lower\_bound(key) & Return an iterator pointing to the first occurrence of  an item in s not less than key, or s.end() if no such item is found. & O(log n)\\
s.upper\_bound(key) & Return an iterator pointing to the first occurrence of  an item greater than key in s, or s.end() if no such item is found. & O(log n)\\
s.equal\_range(key) & Returns pair$<$lower\_bound(key), upper\_bound(key)$>$. & O(log n)\\
s.count(key) & Returns the number of items equal to key in s. & O(log n)\\
s.size() & Return current number of elements. & O(1)\\
s.empty() & Return true if set is empty. & O(1)\\
s.begin() & Return an iterator pointing to the first element. & O(1)\\
s.end() & Return an iterator pointing one past the last element. & O(1)
\end{tabular}
\clearpage
%----------------------------------------
%	Std::Map
% ---------------------------------------
\subsection{std::Map}
\begin{tabular}{ p{5cm} p{7cm}  p{5cm} }
\textbf{Constructors} & \textbf{Description} & \textbf{Big - OH}\\
map$<$ key\_type, value\_type, key\_compare $>$ m; & Make an empty map. key\_compare should be a binary predicate for ordering the keys. It's optional and will default to a function that uses operator$<$. & O(1)\\
map$<$ key\_type, value\_type, key\_compare $>$ m(begin, end); & Make a map and copy the values from begin to end. & O(n log n)
\end{tabular}
\\
\\
\\
\begin{tabular}{ p{5cm} p{7cm}  p{5cm} }
\textbf{Accessors} & \textbf{Description} & \textbf{Big - OH}\\
m[key] & Return the value stored for key. This adds a default value if key not in map. & O(log n)\\
m.find(key) & Return an iterator pointing to a key-value pair, or m.end() if key is not in map. & O(log n)\\
m.lower\_bound(key) & Return an iterator pointing to the first pair containing key, or m.end() if key is not in map. & O(log n)\\
m.upper\_bound(key) & Return an iterator pointing one past the last pair containing key, or m.end() if key is not in map. & O(log n)\\
m.equal\_range(key) & Return a pair containing the lower and upper bounds for key. This may be more efficient than calling those functions separately. & O(log n)\\
m.size(); & Return current number of elements. & O(1)\\
m.empty(); & Return true if map is empty. & O(1)\\
m.begin() & Return an iterator pointing to the first pair. & O(1)\\
m.end() & Return an iterator pointing one past the last pair. & O(1) n)
\end{tabular}
\\
\\
\\
\begin{tabular}{ p{5cm} p{7cm}  p{5cm} }
\textbf{Modifiers} & \textbf{Description} & \textbf{Big - OH}\\
m[key] = value; & Store value under key in map. & O(log n)\\
m.insert(pair) & Inserts the <key, value> pair into the map. Equivalent to the above operation. & O(log n)
\end{tabular}
\subsection{std::pair}
\begin{tabular}{ p{5cm} p{10cm} }
default (1) & constexpr pair\\
copy / move (2) & template$<$class U, class V$>$ pair (const pair$<$U,V$>$\& pr);
					template$<$class U, class V$>$ pair (pair$<$U,V$>$\&\& pr);
					pair (const pair\& pr) = default;
					pair (pair\&\& pr) = default;\\
initialization (3) & pair (const first\_type\& a, const second\_type\& b);
					template$<$class U, class V$>$ pair (U\&\& a, V\&\& b);\\
piecewise (4) &
					template $<$class... Args1, class... Args2$>$
  					pair (piecewise\_construct\_t pwc, tuple$<$Args1...$>$ first\_args,
                                   tuple$<$Args2...$>$ second\_args);

\end{tabular}
\begin{lstlisting}

template <class T1,class T2>
  pair<T1,T2> make_pair (T1 x, T2 y)
  {
    return ( pair<T1,T2>(x,y) );
  }
\end{lstlisting}
function to make a std::pair

%----------------------------------------
%	Betacore::Node
% ---------------------------------------
\subsection{Betacore::Node}
\begin{lstlisting}
	template<typename I>
	class Node{
		private:
		I id;
		std::string name;
		public:
			Node(I &id,std::string &name)
			std::string get_name()
			void setName(const std::string &name)
			I get_id()
	};
\end{lstlisting}
Helper class that can store minimal information about a node,
more information can stored in the csv file
%----------------------------------------
%	Betacore::Edge
% ---------------------------------------
\subsection{Betacore::Edge}
\begin{lstlisting}
	template<typename T, typename I>
	class Edge{
		private:
			I id;
			I source;
			I target;
			T cost;
		public:
			Edge(){}
			Edge(I &source, I &target, T &cost)
			I get_source()
			I get_target()
			T get_cost()
	};
\end{lstlisting}
Helper class that can store minimal information about a Edge,
more information can stored in the csv file
%----------------------------------------
%	Betacore::Graph
% ---------------------------------------
\subsection{Betacore::Graph}
\begin{lstlisting}
	template<typename T, typename I>
	class Graph{
		private:
			std::vector<betacore::Node<I>> nodes
			std::vector<betacore::Edge<T,I>> edges
			betacore::Node<I> * source
			std::vector<betacore::Node<I>> targets
			void parse_line(std::string &line)
		public:
			Graph()
			void successor(I &node, std::vector<Edge<T,I>> &result)
			void get_edges(std::vector<betacore::Edge<T,I>> &edges)
			Node<I> get_node(I id)
			void add_node(Node<I> &node)
			void remove_node(I id)
			load_from_file(std::string file_path)
			T cost(I u, I ui)
			void print()
	};
\end{lstlisting}

Betacore::graph is an implementation of a directed graph that reads from a
modified comma delimited file. This allows for the graph state to change
without recompiling the code, however this is a potential bottleneck due to
the read speed of a hard disk (for larger gig size files this should be
be modified to a stream and the graph split up into regions then load each region
only when needed, thus saving memory ).

Template$<$typename T, typename I$>$ allows the precision of the graph type to
be determined by the implementation. T being a float, double, or long double
used for floating point arithmetic. I being a char, int, long, long long int is
used for indexing the nodes. Depending on the size of the graph changing the
data types for T and I can have a performance and precision impact on the graph.

%----------------------------------------
%	Betacore::Dijkstra
% ---------------------------------------
\subsection{Betacore::Dijkstra}  \label{betadij}
\begin{lstlisting}
	struct Dijkstra_Exception : public std::exception {
		const char * what () const throw () {
			return "Dijkstra Exception";
		}
	};

	template<typename T, typename I>
	class Dijkstra{
		private:
			std::priority_queue<std::pair<T,I>,std::vector<std::pair<T,I>>, std::greater<std::pair<T,I>> > frontier;
			std::set<I> current;
			std::set<I> explored;
			T cost();
		public:
			Dijkstra(){
			}
			~Dijkstra(){
			}

			void run (
				I source,
				I goal,
				std::map<I,I> &path,
				std::function<T( I u, I ui)> &cost,
				std::function<void(I &node, std::vector<Edge<T,I>> &result)> &Succ
			 );

			void run (
				I source,
				std::vector<I> &goal_v,
				std::map<I,I> &path,
				std::function<T( I u, I ui)> &cost,
				std::function<void(I &node, std::vector<Edge<T,I>> &result)> &Succ
			 );

	};
\end{lstlisting}

Betacore::Dijkstra implementation utilizes the std::priority\_queue (see section \ref{pq}).
The priority\_queue uses the std::greater function which set the que by the value in edge cost$<$T$>$. The goal is the min value so using the grater function
so the value in first position will be the smallest, thus the shortest edge$<$T$>$.
Limitation of using std::priority\_queue is that their is no contains method. That
problem is overcome by keeping a std::set (see section \ref{stdset}) to keep track of nodes in the frontier.
So the std::priority\_queue frontier keeps the order of the edges and std::set current keeps track of the contains.
This adds double space complexity but saves from have to implement a new child class of std::priority\_queue. Nodes
are know by their index type I and the edges  by the edge class.
\\
\\

\begin{lstlisting}
	std::function<T( I u, I ui)> &cost
\end{lstlisting}
This function passed into the algorithm determines the cost from node $u \to u_i$ and
must be provided by the user and allows for the most flexibility.
\\
\begin{lstlisting}
	std::function<void(I &node, std::vector<Edge<T,I>> &result)> &Succ
\end{lstlisting}
This function passed into the algorithm determines then neighbors nodes of $u$ and
stores the result into a std::vector \&result. To change the implement just make sure
that you add the Edge$<$T,I$>$ index I do the vector list.
% ==========================================================================================================================
%  Proof of correctness Section 3
% ==========================================================================================================================

% \section[Proof of correctness]{Proof of correctness}
\section{Proof of correctness}
Note: running time doesn't include loading from file, its the running time of the algorithm.
Their is an additional graph, not required by assignment,
that was used to verify the algorithm.
Due to simplistic nature of the graph\_01 it can show in an ideal case the algorithm takes shortest path (not ideal being negative cycle),
assuming it is provided by the Succ function(\ref{betadij}).
\subsection{Flight Plans}

Sample Run output:

\begin{lstlisting}
	_______________________________________________________________
	Heuristics
	_______________________________________________________________
	../data/graph_gt_7_3.csv
	N,1,SFO
	N,2,ORD
	N,3,BOS
	N,4,PVD
	N,5,JFK
	N,6,BWI
	N,7,MIA
	N,8,DFW
	N,9,LAX
	#
	E,1,2,1846
	E,2,1,1846
	#
	E,1,8,1464
	E,8,1,1464
	#
	E,1,9,337
	E,9,1,337
	#
	E,2,3,867
	E,3,2,867
	#
	E,2,4,849
	E,4,2,849
	#
	E,2,5,740
	E,5,2,740
	#
	E,2,6,621
	E,6,2,621
	#
	E,2,8,802
	E,8,2,802
	#
	E,3,5,187
	E,5,3,187
	#
	E,3,7,1258
	E,7,3,1258
	#
	E,4,5,144
	E,5,4,144
	#
	E,5,6,184
	E,6,5,184
	#
	E,5,7,1090
	E,7,5,1090
	#
	E,5,8,1391
	E,8,5,1391
	#
	E,6,7,946
	E,7,6,946
	#
	E,7,8,1121
	E,8,7,1121
	#
	E,7,9,2342
	E,9,7,2342
	#
	E,8,9,1235
	E,9,8,1235
	#
	T,1,SFO
	T,9,LAX
	S,6,BWI
	_______________________________________________________________
	Edge:1->2 cost:1846
	Edge:2->1 cost:1846
	Edge:1->8 cost:1464
	Edge:8->1 cost:1464
	Edge:1->9 cost:337
	Edge:9->1 cost:337
	Edge:2->3 cost:867
	Edge:3->2 cost:867
	Edge:2->4 cost:849
	Edge:4->2 cost:849
	Edge:2->5 cost:740
	Edge:5->2 cost:740
	Edge:2->6 cost:621
	Edge:6->2 cost:621
	Edge:2->8 cost:802
	Edge:8->2 cost:802
	Edge:3->5 cost:187
	Edge:5->3 cost:187
	Edge:3->7 cost:1258
	Edge:7->3 cost:1258
	Edge:4->5 cost:144
	Edge:5->4 cost:144
	Edge:5->6 cost:184
	Edge:6->5 cost:184
	Edge:5->7 cost:1090
	Edge:7->5 cost:1090
	Edge:5->8 cost:1391
	Edge:8->5 cost:1391
	Edge:6->7 cost:946
	Edge:7->6 cost:946
	Edge:7->8 cost:1121
	Edge:8->7 cost:1121
	Edge:7->9 cost:2342
	Edge:9->7 cost:2342
	Edge:8->9 cost:1235
	Edge:9->8 cost:1235
	Nodes:1
	Nodes:2
	Nodes:3
	Nodes:4
	Nodes:5
	Nodes:6
	Nodes:7
	Nodes:8
	Nodes:9
	_______________________________________________________________
	Node U::6
	Other Goal Found:1	cost:0
	Other Goal Found:9	cost:0
	Adding to frontier node:2 cost:621
	Adding to frontier node:5 cost:184
	Adding to frontier node:7 cost:946
	Node U::5
	Other Goal Found:1	cost:0
	Other Goal Found:9	cost:0
	Adding to frontier node:3 cost:371
	Adding to frontier node:4 cost:328
	Adding to frontier node:8 cost:1575
	Node U::4
	Other Goal Found:1	cost:0
	Other Goal Found:9	cost:0
	Node U::3
	Other Goal Found:1	cost:0
	Other Goal Found:9	cost:0
	Node U::2
	Other Goal Found:1	cost:0
	Other Goal Found:9	cost:0
	Adding to frontier node:1 cost:2467
	+adding edge:2 cost:1423
	Node U::7
	Other Goal Found:1	cost:2467
	Other Goal Found:9	cost:0
	Adding to frontier node:9 cost:3288
	Node U::8
	Other Goal Found:1	cost:2467
	Other Goal Found:9	cost:3288
	+adding edge:8 cost:2658
	Node U::1
	Min Goal Found:1	cost:2467
	Other Goal Found:9	cost:2658
	Node U::9
	Other Goal Found:1	cost:2467
	Other Goal Found:9	cost:2658
	explored node count:8
	explored node:1
	explored node:2
	explored node:3
	explored node:4
	explored node:5
	explored node:6
	explored node:7
	explored node:8
	frontier node count:0
	path:
	1<-2<-6
	cost:2467
	Running time(includes std::cout):	0.000282s
	cpu start: 0	cpu end:1	CLOCKS_PER_SEC:1000
	cpu time(includes std::cout):	0.001s
	_______________________________________________________________

\end{lstlisting}
* Note the cpu run time may not appear accurate due to the running system (see System \\ information \ref{sysinfo})

Doing the trace by hand yielded similar results with the min path being BWI $\to$ ORD  $\to$ SFO. in the output
the entire search state is dumped (which can hurt performance) so by looking at each choice the algorithm is taking (making sure it's being greedy).
we can verify the correctness for this instance (if the graph was larger test driven development would be advised ).

\subsection{Missionaries and Cannibals}
With run of $n=3$ and $m=2$ \\
The graph in the format:\\
Each node represents the following\\

N: Type of node\\

\#: id of the node\\

Name: LHS(Missionaries\_Cannibals)::Boat(Missionaries\_Cannibals)::RHS(Missionaries\_Cannibals)\\
\\
Each Edge is source, target, cost\\
The Goal is to move from LHS $\to$ RHS
\\
Sample Run output:
\begin{lstlisting}
	_______________________________________________________________
	Heuristics
	_______________________________________________________________
	../data/graph_can_n_3_m_2.csv
	N,0,N::3_2::0_0::0_0
	N,1,N::2_1::1_1::0_0
	N,2,N::3_0::0_2::0_0
	N,3,N::1_2::2_0::0_0
	N,4,N::2_1::0_1::1_0
	N,5,N::2_1::1_0::0_1
	N,6,N::2_0::0_1::0_1
	N,7,N::3_0::0_1::0_1
	N,8,N::1_1::1_1::1_0
	N,9,N::2_0::0_2::1_0
	N,10,N::2_0::1_1::0_1
	N,11,N::1_1::2_0::0_1
	N,12,N::1_1::0_1::2_0
	N,13,N::1_1::1_0::1_1
	N,14,N::2_0::0_1::1_1
	N,15,N::2_0::1_0::0_2
	N,16,N::1_0::2_0::0_1
	N,17,N::1_0::1_1::2_0
	N,18,N::1_0::0_2::2_0
	N,19,N::1_0::0_1::2_1
	N,20,N::0_1::0_1::3_0
	N,21,N::1_0::1_0::1_2
	N,22,N::0_0::1_1::2_1
	N,23,N::0_0_::0_2::3_0
	N,24,N::0_0::0_0::3_2
	E,0,1,1
	E,0,2,1
	E,0,3,1
	E,1,4,1
	E,1,5,1
	E,2,6,1
	E,4,7,1
	E,4,8,1
	E,5,9,1
	E,5,10,1
	E,6,9,1
	E,7,11,1
	E,7,12,1
	E,8,13,1
	E,9,13,1
	E,11,15,1
	E,11,16,1
	E,12,16,1
	E,13,17,1
	E,14,18,1
	E,15,19,1
	E,16,20,1
	E,17,19,1
	E,17,21,1
	E,18,21,1
	E,19,22,1
	E,20,23,1
	E,22,24,1
	E,23,24,1
	S,0,N::3_2::0_0::0_0
	T,24,N::0_0::0_0::3_2
	_______________________________________________________________
	Edge:0->1 cost:1
	Edge:0->2 cost:1
	Edge:0->3 cost:1
	Edge:1->4 cost:1
	Edge:1->5 cost:1
	Edge:2->6 cost:1
	Edge:4->7 cost:1
	Edge:4->8 cost:1
	Edge:5->9 cost:1
	Edge:5->10 cost:1
	Edge:6->9 cost:1
	Edge:7->11 cost:1
	Edge:7->12 cost:1
	Edge:8->13 cost:1
	Edge:9->13 cost:1
	Edge:11->15 cost:1
	Edge:11->16 cost:1
	Edge:12->16 cost:1
	Edge:13->17 cost:1
	Edge:14->18 cost:1
	Edge:15->19 cost:1
	Edge:16->20 cost:1
	Edge:17->19 cost:1
	Edge:17->21 cost:1
	Edge:18->21 cost:1
	Edge:19->22 cost:1
	Edge:20->23 cost:1
	Edge:22->24 cost:1
	Edge:23->24 cost:1
	Nodes:0
	Nodes:1
	Nodes:2
	Nodes:3
	Nodes:4
	Nodes:5
	Nodes:6
	Nodes:7
	Nodes:8
	Nodes:9
	Nodes:10
	Nodes:11
	Nodes:12
	Nodes:13
	Nodes:14
	Nodes:15
	Nodes:16
	Nodes:17
	Nodes:18
	Nodes:19
	Nodes:20
	Nodes:21
	Nodes:22
	Nodes:23
	Nodes:24
	_______________________________________________________________
	Node U::0
	Other Goal Found:24	cost:0
	Adding to frontier node:1 cost:1
	Adding to frontier node:2 cost:1
	Adding to frontier node:3 cost:1
	Node U::1
	Other Goal Found:24	cost:0
	Adding to frontier node:4 cost:2
	Adding to frontier node:5 cost:2
	Node U::2
	Other Goal Found:24	cost:0
	Adding to frontier node:6 cost:2
	Node U::3
	Other Goal Found:24	cost:0
	Node U::4
	Other Goal Found:24	cost:0
	Adding to frontier node:7 cost:3
	Adding to frontier node:8 cost:3
	Node U::5
	Other Goal Found:24	cost:0
	Adding to frontier node:9 cost:3
	Adding to frontier node:10 cost:3
	Node U::6
	Other Goal Found:24	cost:0
	Node U::7
	Other Goal Found:24	cost:0
	Adding to frontier node:11 cost:4
	Adding to frontier node:12 cost:4
	Node U::8
	Other Goal Found:24	cost:0
	Adding to frontier node:13 cost:4
	Node U::9
	Other Goal Found:24	cost:0
	Node U::10
	Other Goal Found:24	cost:0
	Node U::11
	Other Goal Found:24	cost:0
	Adding to frontier node:15 cost:5
	Adding to frontier node:16 cost:5
	Node U::12
	Other Goal Found:24	cost:0
	Node U::13
	Other Goal Found:24	cost:0
	Adding to frontier node:17 cost:5
	Node U::15
	Other Goal Found:24	cost:0
	Adding to frontier node:19 cost:6
	Node U::16
	Other Goal Found:24	cost:0
	Adding to frontier node:20 cost:6
	Node U::17
	Other Goal Found:24	cost:0
	Adding to frontier node:21 cost:6
	Node U::19
	Other Goal Found:24	cost:0
	Adding to frontier node:22 cost:7
	Node U::20
	Other Goal Found:24	cost:0
	Adding to frontier node:23 cost:7
	Node U::21
	Other Goal Found:24	cost:0
	Node U::22
	Other Goal Found:24	cost:0
	Adding to frontier node:24 cost:8
	Node U::23
	Other Goal Found:24	cost:8
	Node U::24
	Min Goal Found:24	cost:8
	explored node count:23
	explored node:0
	explored node:1
	explored node:2
	explored node:3
	explored node:4
	explored node:5
	explored node:6
	explored node:7
	explored node:8
	explored node:9
	explored node:10
	explored node:11
	explored node:12
	explored node:13
	explored node:15
	explored node:16
	explored node:17
	explored node:19
	explored node:20
	explored node:21
	explored node:22
	explored node:23
	explored node:24
	frontier node count:0
	path:
	24<-22<-19<-15<-11<-7<-4<-1<-0
	cost:8
	Running time(includes std::cout):	0.0004963s
	cpu start: 1	cpu end:1	CLOCKS_PER_SEC:1000
	cpu time(includes std::cout):	0s
	_______________________________________________________________

\end{lstlisting}
* Note the cpu run time may not appear accurate due to the running system (see System  information \ref{sysinfo})
\\
\\
The path\\
24$\leftarrow$22$\leftarrow$19$\leftarrow$15$\leftarrow$11$\leftarrow$7$\leftarrow$4$\leftarrow$1$\leftarrow$0
matches the tree state of the problem and is the length of the depth of the tree.
Each edge havening a cost of 1 yields the correct cost which matches the numbers of edges
With run of $n=4$ and $m=3$
The graph in the format:\\
Each node represents the following\\

N: Type of node\\

\#: id of the node\\

Name: LHS(Missionaries\_Cannibals)::Boat(Missionaries\_Cannibals)::RHS(Missionaries\_Cannibals)\\
\\
Each Edge is source, target, cost\\
The Goal is to move from LHS $\to$ RHS

Sample Run output:
\begin{lstlisting}
	_______________________________________________________________
	Heuristics
	_______________________________________________________________
	../data/graph_can_n_4_m_3.csv
	N,0,4_3::0_0::0_0
	N,1,3_2::1_1::0_0
	N,2,4_1::0_2::0_0
	N,3,2_3::2_0::0_0
	N,4,3_2::1_0::0_1
	N,5,3_2::0_1::1_0
	N,6,4_1::0_1::0_1
	N,7,3_1::1_1::0_1
	N,8,2_2::2_0::0_1
	N,9,2_2::1_1::1_0
	N,10,3_1::0_2::1_0
	N,11,4_0::0_2::0_1
	N,12,3_1::1_0::0_2
	N,13,3_1::0_1::1_1
	N,14,2_2::1_0::1_1
	N,15,2_2::0_1::2_0
	N,16,4_0::0_1::0_2
	N,17,2_1::2_0::0_2
	N,18,3_0::1_1::0_2
	N,19,3_0::0_2::1_1
	N,20,2_1::1_1::1_1
	N,21,1_2::2_0::1_1
	N,22,2_1::0_2::2_0
	N,23,2_1::1_0::1_2
	N,24,3_0::1_0::0_3
	N,25,3_0::0_1::1_2
	N,26,2_1::0_1::2_1
	N,27,2_1::1_0::1_2
	N,28,2_0::2_0::0_3
	N,29,2_0::0_2::2_1
	N,30,1_1::1_1::2_1
	N,31,2_0::1_0::1_3
	N,32,2_0::0_1::2_2
	N,33,1_1::0_1::3_1
	N,34,1_1::1_0::2_2
	N,35,1_0::1_1::2_2
	N,36,1_0::0_2::3_1
	N,37,0_1::1_1::3_1
	N,38,0_1::2_0::2_2
	N,39,1_0::1_0::2_3
	N,40,1_0::0_1::3_2
	N,41,0_1::1_0::3_2
	N,42,0_1::0_1::4_1
	N,43,0_0::1_1::3_2
	N,44,0_0::0_2::4_1
	N,45,0_0::0_0::4_3
	E,0,1,1
	E,0,2,1
	E,0,3,1
	E,1,4,1
	E,1,5,1
	E,2,6,1
	E,4,7,1
	E,4,8,1
	E,5,9,1
	E,5,10,1
	E,6,11,1
	E,7,12,1
	E,7,13,1
	E,8,14,1
	E,9,14,1
	E,9,15,1
	E,10,13,1
	E,11,16,1
	E,12,17,1
	E,12,18,1
	E,13,19,1
	E,13,20,1
	E,14,20,1
	E,14,21,1
	E,15,22,1
	E,15,23,1
	E,16,18,1
	E,17,23,1
	E,18,24,1
	E,18,25,1
	E,19,25,1
	E,20,26,1
	E,20,23,1
	E,22,26,1
	E,24,28,1
	E,26,29,1
	E,26,30,1
	E,28,31,1
	E,29,32,1
	E,30,33,1
	E,30,34,1
	E,32,35,1
	E,33,36,1
	E,33,37,1
	E,34,38,1
	E,35,39,1
	E,35,40,1
	E,36,40,1
	E,37,41,1
	E,37,42,1
	E,38,41,1
	E,40,43,1
	E,41,43,1
	E,42,44,1
	E,43,45,1
	E,44,45,1
	S,0,4_3::0_0::0_0
	T,45,0_0::0_0::4_3
	_______________________________________________________________
	Edge:0->1 cost:1
	Edge:0->2 cost:1
	Edge:0->3 cost:1
	Edge:1->4 cost:1
	Edge:1->5 cost:1
	Edge:2->6 cost:1
	Edge:4->7 cost:1
	Edge:4->8 cost:1
	Edge:5->9 cost:1
	Edge:5->10 cost:1
	Edge:6->11 cost:1
	Edge:7->12 cost:1
	Edge:7->13 cost:1
	Edge:8->14 cost:1
	Edge:9->14 cost:1
	Edge:9->15 cost:1
	Edge:10->13 cost:1
	Edge:11->16 cost:1
	Edge:12->17 cost:1
	Edge:12->18 cost:1
	Edge:13->19 cost:1
	Edge:13->20 cost:1
	Edge:14->20 cost:1
	Edge:14->21 cost:1
	Edge:15->22 cost:1
	Edge:15->23 cost:1
	Edge:16->18 cost:1
	Edge:17->23 cost:1
	Edge:18->24 cost:1
	Edge:18->25 cost:1
	Edge:19->25 cost:1
	Edge:20->26 cost:1
	Edge:20->23 cost:1
	Edge:22->26 cost:1
	Edge:24->28 cost:1
	Edge:26->29 cost:1
	Edge:26->30 cost:1
	Edge:28->31 cost:1
	Edge:29->32 cost:1
	Edge:30->33 cost:1
	Edge:30->34 cost:1
	Edge:32->35 cost:1
	Edge:33->36 cost:1
	Edge:33->37 cost:1
	Edge:34->38 cost:1
	Edge:35->39 cost:1
	Edge:35->40 cost:1
	Edge:36->40 cost:1
	Edge:37->41 cost:1
	Edge:37->42 cost:1
	Edge:38->41 cost:1
	Edge:40->43 cost:1
	Edge:41->43 cost:1
	Edge:42->44 cost:1
	Edge:43->45 cost:1
	Edge:44->45 cost:1
	Nodes:0
	Nodes:1
	Nodes:2
	Nodes:3
	Nodes:4
	Nodes:5
	Nodes:6
	Nodes:7
	Nodes:8
	Nodes:9
	Nodes:10
	Nodes:11
	Nodes:12
	Nodes:13
	Nodes:14
	Nodes:15
	Nodes:16
	Nodes:17
	Nodes:18
	Nodes:19
	Nodes:20
	Nodes:21
	Nodes:22
	Nodes:23
	Nodes:24
	Nodes:25
	Nodes:26
	Nodes:27
	Nodes:28
	Nodes:29
	Nodes:30
	Nodes:31
	Nodes:32
	Nodes:33
	Nodes:34
	Nodes:35
	Nodes:36
	Nodes:37
	Nodes:38
	Nodes:39
	Nodes:40
	Nodes:41
	Nodes:42
	Nodes:43
	Nodes:44
	Nodes:45
	_______________________________________________________________
	Node U::0
	Other Goal Found:45	cost:0
	Adding to frontier node:1 cost:1
	Adding to frontier node:2 cost:1
	Adding to frontier node:3 cost:1
	Node U::1
	Other Goal Found:45	cost:0
	Adding to frontier node:4 cost:2
	Adding to frontier node:5 cost:2
	Node U::2
	Other Goal Found:45	cost:0
	Adding to frontier node:6 cost:2
	Node U::3
	Other Goal Found:45	cost:0
	Node U::4
	Other Goal Found:45	cost:0
	Adding to frontier node:7 cost:3
	Adding to frontier node:8 cost:3
	Node U::5
	Other Goal Found:45	cost:0
	Adding to frontier node:9 cost:3
	Adding to frontier node:10 cost:3
	Node U::6
	Other Goal Found:45	cost:0
	Adding to frontier node:11 cost:3
	Node U::7
	Other Goal Found:45	cost:0
	Adding to frontier node:12 cost:4
	Adding to frontier node:13 cost:4
	Node U::8
	Other Goal Found:45	cost:0
	Adding to frontier node:14 cost:4
	Node U::9
	Other Goal Found:45	cost:0
	Adding to frontier node:15 cost:4
	Node U::10
	Other Goal Found:45	cost:0
	Node U::11
	Other Goal Found:45	cost:0
	Adding to frontier node:16 cost:4
	Node U::12
	Other Goal Found:45	cost:0
	Adding to frontier node:17 cost:5
	Adding to frontier node:18 cost:5
	Node U::13
	Other Goal Found:45	cost:0
	Adding to frontier node:19 cost:5
	Adding to frontier node:20 cost:5
	Node U::14
	Other Goal Found:45	cost:0
	Adding to frontier node:21 cost:5
	Node U::15
	Other Goal Found:45	cost:0
	Adding to frontier node:22 cost:5
	Adding to frontier node:23 cost:5
	Node U::16
	Other Goal Found:45	cost:0
	Node U::17
	Other Goal Found:45	cost:0
	Node U::18
	Other Goal Found:45	cost:0
	Adding to frontier node:24 cost:6
	Adding to frontier node:25 cost:6
	Node U::19
	Other Goal Found:45	cost:0
	Node U::20
	Other Goal Found:45	cost:0
	Adding to frontier node:26 cost:6
	Node U::21
	Other Goal Found:45	cost:0
	Node U::22
	Other Goal Found:45	cost:0
	Node U::23
	Other Goal Found:45	cost:0
	Node U::24
	Other Goal Found:45	cost:0
	Adding to frontier node:28 cost:7
	Node U::25
	Other Goal Found:45	cost:0
	Node U::26
	Other Goal Found:45	cost:0
	Adding to frontier node:29 cost:7
	Adding to frontier node:30 cost:7
	Node U::28
	Other Goal Found:45	cost:0
	Adding to frontier node:31 cost:8
	Node U::29
	Other Goal Found:45	cost:0
	Adding to frontier node:32 cost:8
	Node U::30
	Other Goal Found:45	cost:0
	Adding to frontier node:33 cost:8
	Adding to frontier node:34 cost:8
	Node U::31
	Other Goal Found:45	cost:0
	Node U::32
	Other Goal Found:45	cost:0
	Adding to frontier node:35 cost:9
	Node U::33
	Other Goal Found:45	cost:0
	Adding to frontier node:36 cost:9
	Adding to frontier node:37 cost:9
	Node U::34
	Other Goal Found:45	cost:0
	Adding to frontier node:38 cost:9
	Node U::35
	Other Goal Found:45	cost:0
	Adding to frontier node:39 cost:10
	Adding to frontier node:40 cost:10
	Node U::36
	Other Goal Found:45	cost:0
	Node U::37
	Other Goal Found:45	cost:0
	Adding to frontier node:41 cost:10
	Adding to frontier node:42 cost:10
	Node U::38
	Other Goal Found:45	cost:0
	Node U::39
	Other Goal Found:45	cost:0
	Node U::40
	Other Goal Found:45	cost:0
	Adding to frontier node:43 cost:11
	Node U::41
	Other Goal Found:45	cost:0
	Node U::42
	Other Goal Found:45	cost:0
	Adding to frontier node:44 cost:11
	Node U::43
	Other Goal Found:45	cost:0
	Adding to frontier node:45 cost:12
	Node U::44
	Other Goal Found:45	cost:12
	Node U::45
	Min Goal Found:45	cost:12
	explored node count:45
	explored node:0
	explored node:1
	explored node:2
	explored node:3
	explored node:4
	explored node:5
	explored node:6
	explored node:7
	explored node:8
	explored node:9
	explored node:10
	explored node:11
	explored node:12
	explored node:13
	explored node:14
	explored node:15
	explored node:16
	explored node:17
	explored node:18
	explored node:19
	explored node:20
	explored node:21
	explored node:22
	explored node:23
	explored node:24
	explored node:25
	explored node:26
	explored node:28
	explored node:29
	explored node:30
	explored node:31
	explored node:32
	explored node:33
	explored node:34
	explored node:35
	explored node:36
	explored node:37
	explored node:38
	explored node:39
	explored node:40
	explored node:41
	explored node:42
	explored node:43
	explored node:44
	explored node:45
	frontier node count:0
	path:
	45<-43<-40<-35<-32<-29<-26<-20<-13<-7<-4<-1<-0
	cost:12
	Running time(includes std::cout):	0.0010232s
	cpu start: 1	cpu end:2	CLOCKS_PER_SEC:1000
	cpu time(includes std::cout):	0.001s
	_______________________________________________________________

\end{lstlisting}
* Note the cpu run time may not appear accurate due to the running system (see System information \ref{sysinfo})

45$\leftarrow$43$\leftarrow$40$\leftarrow$35$\leftarrow$32$\leftarrow$29$\leftarrow$26$\leftarrow$20$\leftarrow$13$\leftarrow$7$\leftarrow$4$\leftarrow$1$\leftarrow$0
the path can be trace from the source to the sink with the sink\\target state matching the gaol state
\\
The output cost 12 is correct because the depth of the tree which represents
this problem is 12 and because each edge has a weight of 1 the cost should equal the depth of the tree.

\subsection{System information}\label{sysinfo}
clinfo.exe dump of system information.
Note The above runs where running on cl.exe in debug mode on Windows 10 x64
\begin{lstlisting}
Number of platforms:				 1
  Platform Profile:				 FULL_PROFILE
  Platform Version:				 OpenCL 2.0 AMD-APP (2264.11)
  Platform Name:				 AMD Accelerated Parallel Processing
  Platform Vendor:				 Advanced Micro Devices, Inc.
  Platform Extensions:				 cl_khr_icd cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_khr_dx9_media_sharing cl_amd_event_callback cl_amd_offline_devices

  Platform Name:				 AMD Accelerated Parallel Processing
Number of devices:				 2
  Device Type:					 CL_DEVICE_TYPE_GPU
  Vendor ID:					 1002h
  Board name:					 AMD Radeon HD 7800 Series
  Device Topology:				 PCI[ B#1, D#0, F#0 ]
  Max compute units:				 16
  Max work items dimensions:			 3
    Max work items[0]:				 256
    Max work items[1]:				 256
    Max work items[2]:				 256
  Max work group size:				 256
  Preferred vector width char:			 4
  Preferred vector width short:			 2
  Preferred vector width int:			 1
  Preferred vector width long:			 1
  Preferred vector width float:			 1
  Preferred vector width double:		 1
  Native vector width char:			 4
  Native vector width short:			 2
  Native vector width int:			 1
  Native vector width long:			 1
  Native vector width float:			 1
  Native vector width double:			 1
  Max clock frequency:				 860Mhz
  Address bits:					 32
  Max memory allocation:			 1409286144
  Image support:				 Yes
  Max number of images read arguments:		 128
  Max number of images write arguments:		 8
  Max image 2D width:				 16384
  Max image 2D height:				 16384
  Max image 3D width:				 2048
  Max image 3D height:				 2048
  Max image 3D depth:				 2048
  Max samplers within kernel:			 16
  Max size of kernel argument:			 1024
  Alignment (bits) of base address:		 2048
  Minimum alignment (bytes) for any datatype:	 128
  Single precision floating point capability
    Denorms:					 No
    Quiet NaNs:					 Yes
    Round to nearest even:			 Yes
    Round to zero:				 Yes
    Round to +ve and infinity:			 Yes
    IEEE754-2008 fused multiply-add:		 Yes
  Cache type:					 Read/Write
  Cache line size:				 64
  Cache size:					 16384
  Global memory size:				 2147483648
  Constant buffer size:				 65536
  Max number of constant args:			 8
  Local memory type:				 Scratchpad
  Local memory size:				 32768
  Max pipe arguments:				 0
  Max pipe active reservations:			 0
  Max pipe packet size:				 0
  Max global variable size:			 0
  Max global variable preferred total size:	 0
  Max read/write image args:			 0
  Max on device events:				 0
  Queue on device max size:			 0
  Max on device queues:				 0
  Queue on device preferred size:		 0
  SVM capabilities:
    Coarse grain buffer:			 No
    Fine grain buffer:				 No
    Fine grain system:				 No
    Atomics:					 No
  Preferred platform atomic alignment:		 0
  Preferred global atomic alignment:		 0
  Preferred local atomic alignment:		 0
  Kernel Preferred work group size multiple:	 64
  Error correction support:			 0
  Unified memory for Host and Device:		 0
  Profiling timer resolution:			 1
  Device endianess:				 Little
  Available:					 Yes
  Compiler available:				 Yes
  Execution capabilities:
    Execute OpenCL kernels:			 Yes
    Execute native function:			 No
  Queue on Host properties:
    Out-of-Order:				 No
    Profiling :					 Yes
  Queue on Device properties:
    Out-of-Order:				 No
    Profiling :					 No
  Platform ID:					 00007FFE8904B188
  Name:						 Pitcairn
  Vendor:					 Advanced Micro Devices, Inc.
  Device OpenCL C version:			 OpenCL C 1.2
  Driver version:				 2264.11
  Profile:					 FULL_PROFILE
  Version:					 OpenCL 1.2 AMD-APP (2264.11)
  Extensions:					 cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_khr_dx9_media_sharing cl_khr_image2d_from_buffer cl_khr_spir cl_khr_gl_event cl_amd_liquid_flash

  Device Type:					 CL_DEVICE_TYPE_CPU
  Vendor ID:					 1002h
  Board name:
  Max compute units:				 4
  Max work items dimensions:			 3
    Max work items[0]:				 1024
    Max work items[1]:				 1024
    Max work items[2]:				 1024
  Max work group size:				 1024
  Preferred vector width char:			 16
  Preferred vector width short:			 8
  Preferred vector width int:			 4
  Preferred vector width long:			 2
  Preferred vector width float:			 8
  Preferred vector width double:		 4
  Native vector width char:			 16
  Native vector width short:			 8
  Native vector width int:			 4
  Native vector width long:			 2
  Native vector width float:			 8
  Native vector width double:			 4
  Max clock frequency:				 3504Mhz
  Address bits:					 64
  Max memory allocation:			 4275856384
  Image support:				 Yes
  Max number of images read arguments:		 128
  Max number of images write arguments:		 64
  Max image 2D width:				 8192
  Max image 2D height:				 8192
  Max image 3D width:				 2048
  Max image 3D height:				 2048
  Max image 3D depth:				 2048
  Max samplers within kernel:			 16
  Max size of kernel argument:			 4096
  Alignment (bits) of base address:		 1024
  Minimum alignment (bytes) for any datatype:	 128
  Single precision floating point capability
    Denorms:					 Yes
    Quiet NaNs:					 Yes
    Round to nearest even:			 Yes
    Round to zero:				 Yes
    Round to +ve and infinity:			 Yes
    IEEE754-2008 fused multiply-add:		 Yes
  Cache type:					 Read/Write
  Cache line size:				 64
  Cache size:					 32768
  Global memory size:				 17103425536
  Constant buffer size:				 65536
  Max number of constant args:			 8
  Local memory type:				 Global
  Local memory size:				 32768
  Max pipe arguments:				 16
  Max pipe active reservations:			 16
  Max pipe packet size:				 4275856384
  Max global variable size:			 1879048192
  Max global variable preferred total size:	 1879048192
  Max read/write image args:			 64
  Max on device events:				 0
  Queue on device max size:			 0
  Max on device queues:				 0
  Queue on device preferred size:		 0
  SVM capabilities:
    Coarse grain buffer:			 No
    Fine grain buffer:				 No
    Fine grain system:				 No
    Atomics:					 No
  Preferred platform atomic alignment:		 0
  Preferred global atomic alignment:		 0
  Preferred local atomic alignment:		 0
  Kernel Preferred work group size multiple:	 1
  Error correction support:			 0
  Unified memory for Host and Device:		 1
  Profiling timer resolution:			 292
  Device endianess:				 Little
  Available:					 Yes
  Compiler available:				 Yes
  Execution capabilities:
    Execute OpenCL kernels:			 Yes
    Execute native function:			 Yes
  Queue on Host properties:
    Out-of-Order:				 No
    Profiling :					 Yes
  Queue on Device properties:
    Out-of-Order:				 No
    Profiling :					 No
  Platform ID:					 00007FFE8904B188
  Name:						 Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz
  Vendor:					 GenuineIntel
  Device OpenCL C version:			 OpenCL C 1.2
  Driver version:				 2264.11 (sse2,avx)
  Profile:					 FULL_PROFILE
  Version:					 OpenCL 1.2 AMD-APP (2264.11)
  Extensions:					 cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_device_fission cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt cl_khr_d3d10_sharing cl_khr_spir cl_khr_gl_event
\end{lstlisting}
% //END

\section{ Sources of Error}
There could be some sources of error in my graph csv files,
incorrectly adding edges or mistyping the graph state for the Cannibals and Missionaries.

\bibliographystyle{unsrt}
\bibliography{bib}

\end{document}


\documentclass[11pt]{article}
\usepackage[top=2cm,bottom=2cm]{geometry}
\usepackage[T1]{fontenc}
\usepackage{url}
\usepackage{hyperref}
\usepackage{xcolor}
%
\usepackage{amsthm}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{ifthen}
\usepackage{mathpartir}
\usepackage{mathtools}
\input{macros}
%
\begin{document}

\title{CO663: Language $\lggeEF$ --- summary\footnote{Adapted from:
    Harper, Robert. Practical foundations for programming
    languages. Cambridge University Press, 2016.}}

\date{\vspace{-7ex}}
\maketitle

% \pagenumbering{gobble}

\newcommand{\lazyeval}[1]{\framebox{\parbox[c][#1]{\textwidth}{
      \color{white}{h}%
    }}}

\section{Syntax}

\[
\begin{array}{llclll}
  & & & \text{abstract syntax} & \text{concrete syntax}
  \\\hline
  \TYPES & \tau & \Coloneqq & \enum{}  & \enum{} & \text{numbers}
  \\
  &&& \estr{} & \estr{} & \text{strings}
  \\
  &&& \ebool{} & \ebool{} & \text{Booleans}
  \\
  &&& \tyarr{\tau_1}{\tau_2}  & \tau_1 \rightarrow \tau_2 & \text{function}
  \\ \\
  %
  \EXPS & e & \Coloneqq  & \var{x} & \var{x} & \text{variable}
  \\
  &&& \enum{n} & n & \text{numeral}
  \\
  &&& \estr{s} & \litstr{s} & \text{literal}
  \\
  &&&  \ktrue & \ktrue
  \\
  &&&  \kfalse & \kfalse
  \\
  &&& \eplus{e_1}{e_2} & e_1 {+} e_2 & \text{addition}
  \\
  &&& \etimes{e_1}{e_2} & e_1 {*} e_2 & \text{multiplication}
  \\
  &&& \ecat{e_1}{e_2} & e_1 \concat e_2 & \text{concatenate}
  \\
  &&& \elen{e} & \lvert e \rvert & \text{length}
  \\
  &&& \eequal{e_1}{e_2} & e_1 \meq e_2 & \text{number equality}
  \\
  &&& \site{e}{e_1}{e_2} & \csite{e}{e_1}{e_2} & \text{if then else}
  \\
  &&& \elet{e_1}{x}{e_2} & \clet{e_1}{x}{e_2} & \text{definition}
  \\
  &&& \elam{\tau}{x}{e} & \clam{\tau}{x}{e} & \text{abstraction}
  \\
  &&& \eapp{e_1}{e_2} & \capp{e_1}{e_2} & \text{application}
\end{array}
\]

\section{Typing rules / Statics}

\[
\tyrule
{\eftyrulename{var}}
{\,}
{\tyjudge{\Gamma_1, \var{x}: \tau, \Gamma_2}{\var{x}}{\tau} }
\qquad
\qquad
\qquad
\tyrule
{\eftyrulename{let}}
{
  \tyjudge{\Gamma}{e_1}{\tau_1}
  \and
  \tyjudge{\Gamma, \var{x} : \tau_1 }{e_2}{\tau}
}
{\tyjudge{\Gamma}{\elet{e_1}{x}{e_2}}{\tau}}
\]
\[
\tyrule
{\eftyrulename{str}}
{\,}
{\tyjudge{\Gamma}{\estr{s}}{\estr{}}}
\qquad\qquad\qquad
\tyrule
{\eftyrulename{num}}
{\,}
{\tyjudge{\Gamma}{\enum{n}}{\enum{}}}
\]
\[
\tyrule
{\eftyrulename{tt}}
{\,}
{\tyjudge{\Gamma}{\ktrue}{\ebool{}}}
\qquad\qquad\qquad
\tyrule
{\eftyrulename{ff}}
{\,}
{\tyjudge{\Gamma}{\kfalse}{\ebool{}}}
\]
\[
\tyrule
{\eftyrulename{plus}}
{
  \tyjudge{\Gamma}{e_1}{\enum{}}
  \and
  \tyjudge{\Gamma}{e_2}{\enum{}}
}
{\tyjudge{\Gamma}{\eplus{e_1}{e_2}}{\enum{}}}
\qquad\qquad\qquad\qquad
\tyrule
{\eftyrulename{times}}
{
  \tyjudge{\Gamma}{e_1}{\enum{}}
  \and
  \tyjudge{\Gamma}{e_2}{\enum{}}
}
{\tyjudge{\Gamma}{\etimes{e_1}{e_2}}{\enum{}}}
%
\]
\[
\tyrule
{\eftyrulename{cat}}
{
  \tyjudge{\Gamma}{e_1}{\estr{}}
  \and
  \tyjudge{\Gamma}{e_2}{\estr{}}
}
{\tyjudge{\Gamma}{\ecat{e_1}{e_2}}{\estr{}}}
\qquad\qquad\qquad
\tyrule
{\eftyrulename{len}}
{
  \tyjudge{\Gamma}{e}{\estr{}}
}
{\tyjudge{\Gamma}{\elen{e}}{\enum{}}}
\]
\[
\tyrule
{\eftyrulename{eq}}
{
  \tyjudge{\Gamma}{e_1}{\enum{}}
  \and
  \tyjudge{\Gamma}{e_2}{\enum{}}
}
{\tyjudge{\Gamma}{\eequal{e_1}{e_2}}{\ebool{}}}
\qquad\qquad\qquad
\tyrule
{\eftyrulename{ite}}
{
  \tyjudge{\Gamma}{e}{\ebool{}}
  \and
  \tyjudge{\Gamma}{e_1}{\tau}
  \and
  \tyjudge{\Gamma}{e_2}{\tau}
}
{\tyjudge{\Gamma}{\site{e}{e_1}{e_2}}{\tau}}
\]
%
%
\[
\tyrule
{\eftyrulename{lam}}
{
  \tyjudge{\Gamma, \var{x} : \tau_1}{e}{\tau_2}
}
{\tyjudge{\Gamma}{\elam{\tau_1}{x}{e}}{\tyarr{\tau_1}{\tau_2}}}
\qquad\qquad\qquad
\tyrule
{\eftyrulename{ap}}
{
  \tyjudge{\Gamma}{e_1}{\tyarr{\tau'}{\tau}}
  \and
  \tyjudge{\Gamma}{e_2}{\tau'}
}
{
  \tyjudge{\Gamma}{\eapp{e_1}{e_2}}{\tau}
}
\]

\section{Semantics / Dynamics}

\subsection{Values}
\[
\semrule{}
{\,}
{\valjudge{\enum{n}}}
\qquad \qquad  \qquad
\semrule{}
{\,}
{\valjudge{\estr{s}}}
\qquad \qquad  \qquad
\semrule{}
{\,}
{\valjudge{\ktrue}}
\qquad \qquad  \qquad
\semrule{}
{\,}
{\valjudge{\kfalse}}
\]

\[
\semrule
{\efsemrulename{lam}}
{\,}
{\valjudge{\elam{\tau}{x}{e}}}
\]
\subsection{Reductions}

The main semantic rules are as follows (the missing ones can easily be
re-constructed).
\[
\semrule
{\efsemrulename{plval}}
{n_1 + n_2 = n}
{\jtrans{\eplus{\enum{n_1}}{\enum{n_2}}}{\enum{n}}}
\qquad \qquad  \qquad
\semrule
{\efsemrulename{pll}}
{\jtrans{e_1}{e'_1}}
{\jtrans{\eplus{e_1}{e_2}}{\eplus{e'_1}{e_2}}}
\]
\[
\semrule
{\efsemrulename{plr}}
{ \valjudge{e_1}
  \and
  \jtrans{e_2}{e'_2}}
{\jtrans{\eplus{e_1}{e_2}}{\eplus{e_1}{e'_2}}}
\]
\[
\semrule
{\efsemrulename{tmval}}
{n_1 \times n_2 = n}
{\jtrans{\etimes{\enum{n_1}}{\enum{n_2}}}{\enum{n}}}
\qquad \qquad  \qquad
\semrule
{\efsemrulename{tml}}
{\jtrans{e_1}{e'_1}}
{\jtrans{\etimes{e_1}{e_2}}{\etimes{e'_1}{e_2}}}
\]
\[
\semrule
{\efsemrulename{tmr}}
{ \valjudge{e_1}
  \and
  \jtrans{e_2}{e'_2}}
{\jtrans{\etimes{e_1}{e_2}}{\etimes{e_1}{e'_2}}}
\]
\[
\semrule
{\efsemrulename{catval}}
{s_1 \concat s_2 = s}
{\jtrans{\ecat{\estr{s_1}}{\estr{s_2}}}{\estr{s}}}
\qquad \qquad  \qquad
\semrule
{\efsemrulename{catl}}
{ \jtrans{e_1}{e'_1}}
{\jtrans{\ecat{e_1}{e_2}}{\ecat{e'_1}{e_2}}}
\]
\[
\semrule
{\efsemrulename{catr}}
{\valjudge{e_1}
  \and
  \jtrans{e_2}{e'_2}}
{\jtrans{\ecat{e_1}{e_2}}{\ecat{e_1}{e'_2}}}
\]
%
\[
\semrule
{\efsemrulename{eqt}}
{n_1 == n_2}
{\jtrans{\eequal{\enum{n_1}}{\enum{n_2}}}{\ktrue}}
\qquad \qquad  \qquad
\semrule
{\efsemrulename{eqf}}
{n_1 /= n_2}
{\jtrans{\eequal{\enum{n_1}}{\enum{n_2}}}{\kfalse}}
\]
\[
\semrule
{\efsemrulename{eql}}
{ \jtrans{e_1}{e'_1}}
{\jtrans{\eequal{e_1}{e_2}}{\eequal{e'_1}{e_2}}}
\qquad \qquad  \qquad
\semrule
{\efsemrulename{eqr}}
{\valjudge{e_1}
  \and
  \jtrans{e_2}{e'_2}}
{\jtrans{\eequal{e_1}{e_2}}{\eequal{e_1}{e'_2}}}
\]
%
\[
\semrule{\efsemrulename{lenv}}
{\lvert s \rvert == n}
{\jtrans{\elen{\estr{s}}}{\enum{n}}}
\qquad \qquad  \qquad
\semrule{\efsemrulename{lene}}
{\jtrans{e}{e'}}
{\jtrans{\elen{e}}{\elen{e'}}}
\]
%
\[
\semrule
{\efsemrulename{itet}}
{\,}
{\jtrans{\site{\ktrue}{e_1}{e_2}}{e_1}}
\qquad \qquad  \qquad
\semrule
{\efsemrulename{itef}}
{\,}
{\jtrans{\site{\kfalse}{e_1}{e_2}}{e_2}}
\]
\[
\semrule
{\efsemrulename{ite}}
{\jtrans{e}{e'}}
{\jtrans{\site{e}{e_1}{e_2}}{\site{e'}{e_1}{e_2}}}
\]

To reduce \texttt{let} constructs, we can use either:
\begin{itemize}
\item Call-by-name (``lazy''):
  \[
  \semrule
  {\efsemrulename{letn}}
  {\,}
  {
    \jtrans{\elet{e_1}{x}{e_2}}{\subs{e_2}{e_1}{x}}}
  \]
\item Call-by-value (``strict''):
  {\color{gray}
    \[
    \semrule
    {\efsemrulename{letm}}
    {\jtrans{e_1}{e'_1}}
    {
      \jtrans{\elet{e_1}{x}{e_2}}{\elet{e'_1}{x}{e_2}}}
    \qquad \qquad  \qquad
    \semrule
    {\efsemrulename{letv}}
    {\valjudge{e_1}}
    {
      \jtrans{\elet{e_1}{x}{e_2}}{\subs{e_2}{e_1}{x}}}
    \]
  }
  %
  %
  %
  \[
  % \qquad \qquad  \qquad
  %
  \semrule
  {\efsemrulename{ap}}
  {\jtrans{e_1}{e'_1}}
  {
    \jtrans{\eapp{e_1}{e_2}}{\eapp{e'_1}{e_2}}
  }
  \]
  To reduce \texttt{ap} constructs (function applications), we can use
  either:
\item Call-by-name (``lazy''):
  \[
  \semrule
  {\efsemrulename{apn}}
  {\,}
  {\jtrans{\eapp{\elam{\tau}{x}{e_1}}{e_2}}{\subs{e_1}{e_2}{x}}}
  \]
\item Call-by-value (``strict''):

  \[
  \semrule
  {\efsemrulename{apr}}
  {\valjudge{e_1}
    \and \jtrans{e_2}{e'_2}
  }
  {\jtrans{\eapp{e_1}{e_2}}{\eapp{e_1}{e'_2}}}
  \qquad \qquad  \qquad
  %
  \semrule
  {\efsemrulename{apl}}
  {\valjudge{e_2}}
  {\jtrans{\eapp{\elam{\tau}{x}{e_1}}{e_2}}{\subs{e_1}{e_2}{x}}}
  \]

\end{itemize}

\section*{\LaTeX\ template}
The \LaTeX\ sources of this document are available in:
\url{https://github.com/ukc-co663/pl-design-latex-template}.

\end{document}

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


\section{Action Planning and Verification (Scott)}

The action planning process involves modeling the manipulator behavior and verifying a controller with respect to the model and any safety conditions specified by the user for a given action.
The trajectory planner is responsible for executing a rough motion of the manipulator to some approximate pose near the final desired location of the end effector (EFF).
In the case of the modular robot assembly, the trajectory planner moves the modular robot component to be attached to a location near the final attachment EFF pose.
The task planner provides the desired translation of the EFF in the global reference frame (necessary for making the connection) to the action planner, which then executes the motion once a controller has been verified.

\subsection{Continuous System Verification}
In order to avoid undesirable robot motions, the user specifies a set of unsafe states of the robot, $\varphi$, for a given action or motion of the manipulator.
For the case of modular robot assembly, the unsafe set is defined to be those poses of the end effector during an attachment motion that may result in a failed attachment or improper connection (magnet misalignment).
A given controller may be verified to cause the system remain within the safe set (no intersection with the unsafe set) by computing the set of all reachable states, $\textit{ReachSet}_{\mbox{\textit{H}}}$, from some initial condition ,$X_0 \subseteq X$.
However, determining the exact set of reachable states is difficult \cite{Henzinger:1995:WDH:225058.225162}, and an over approximation of the reachable set is instead computed.
The controller is verified if the over approximated set is contained within the set of states that satisfy the safety conditions, $\mbox{\textit{ReachSet}}_{\mbox{\textit{H}}} \subseteq \mbox{Sat}(\varphi)$.
The controller and motion are not verified if there is an intersection of the reachable states and the unsafe set, $\mbox{\textit{ReachSet}}_{\mbox{\textit{H}}} \cap \neg \mbox{Sat}(\varphi) \neq \emptyset$.
In the case where some intersection of the unsafe set and reachable set occurs, no conclusions may be drawn from the analysis as the reach set is an over approximation, and re-planning of the manipulator (by the trajectory planner) is required.

This process is similar to the framework in \cite{6016596}, in which the control architectures of an autonomous robotic surgery manipulator are verified for a puncturing task, whereby the EFF (puncturing instrument) is guaranteed to remain within some pose bounds.
In this work, the reachability tool Flow* \cite{Chen2013} is used to over approximate the system dynamics using Taylor Model flowpipes.
Flow* is capable of handling nonlinear systems, but as manipulators are highly nonlinear, the dynamics of the Baxter arms are linearized in an effort to increase computation speed.

\subsection{Manipulator Modeling}
The dynamics of each of the Baxter arms can be represented as:
\begin{equation}
	\mathbf{M}(\underline{q})\ddot{\underline{q}} + \mathbf{C}(\underline{q},\underline{\dot{q}})\dot{\underline{q}} + \mathbf{G}(\underline{q}) = \underline{T}_{eff} + \underline{T}_{in}
\end{equation}
where $\mathbf{M}$ and $\mathbf{C}$ represent the inertial effects, $\mathbf{G}$ represents joint torques due to gravity, $\underline{T}_{EFF}$ represents the joint torques due to EFF load, and $\underline{T}_{in}$ represents the input joint torques.
In this case, linearizing the arm dynamics involves evaluating the nonlinear matrices $\mathbf{M}$, $\mathbf{C}$, and $\mathbf{G}$ for a given arm configuration.
As the action planner only executes arm motions for small EFF motions (and subsequently small changes in joint angle) it is assumed that these matrices remain constant for the duration of the arm motion executed by the action planner.
It should be noted that Coriolis effects, $\mathbf{C}$, are ignored due to the small motions of the arm.

\subsection{ROS Action Server and Code Diagram}
The action planner, comprising the reachability analysis, controller verification, and joint torque controller execution, are implemented as an action server in ROS.
The code block diagram is shown in figure Fig. \ref{fig:actionPlannerFlow}.
The action server, called by the task planner when a connection need to be performed, polls the current state of the arm holding the module to be attached, computes the linearized matrices of the manipulator equation, generates a Flow* file, performs the reachability computation for the given feedback controller, and then executes the motion if the controller/motion is verified.
The server creates an instance of Matlab when launched, which is then used for the kinematics computations and controller design.
The kinematics computations and linear model generation are done using the Matlab Robotics Toolbox \cite{Corke11a}.

Initially, the intent was to model the manipulator and controller(s) as a hybrid system, consisting of the continuous manipulator dynamics coupled with discrete controller states for aligning and approaching a connection.
However, the hybrid system model was discarded due to the complexity of developing a controller for the attachment motions.

\begin{figure}[h]
	\includegraphics[width = 8 cm]{action_server_2.png}
	\caption{Action Planner Module}
	\label{fig:actionPlannerFlow}
\end{figure}

\subsection{Difficulties with Baxter Joint Torque Control}
The initial controller used in the action planner server was a linear quadratic regulator (LQR) controller computed by Matlab.
The LQR controller provided feedback joint torques while a static input was added to counteract gravitational effects ($\mathbf{G}$ torques).
However, this controller, when implemented on the Baxter platform, resulted in erratic arm motions despite satisfactory performance in the Baxter simulator.
The Baxter platform provides a ``zero-gravity'' mode of operation whereby the robot continually provides torques to each joint sufficient to counteract gravitational effects.
The LQR controller, when implemented in ``zero-gravity'' mode (without the added gravitational torque compensation), resulted in arm ``drift,'' whereby the arm would slowly diverge from the initial condition.
Increasing the control effort did not improve the ability of the LQR controller to overcome the perceived arm ``drift.''
When the LQR controller was implemented with the ``zero-gravity'' mode disabled (during which the static gravitational torque inputs were included), the resulting arm motion was wildly erratic.
Operating with the ``zero-gravity'' mode disabled is not recommended.

The controller implemented in the final version of the action planner server (torque control) is a simple PD controller.
The Baxter robot has pre-defined joint spring and damping coefficients that can be called for PD joint torque control.
This controller (when used in ``zero-gravity'' mode) results in stable arm motion, both in simulation and on the physical robot.
However, the default spring and damping values result in significant arm oscillations when the robot is moving from one configuration to another.
As oscillations are undesirable when connecting modular components, the damping values are increased.
It should be noted that both the spring and damping coefficient values are passed in to the action planner server when called and, as such, may be altered at runtime by the task planner.

\subsection{Verified Motion Example}
The results of the execution of a simple motion command on the left arm by the action planner are shown in Figures \ref{fig:effX},\ref{fig:effY}, and \ref{fig:effZ}.
In this example, the input desired EFF motion is appx. 10 cm in the negative z direction (toward the ground) in the Baxter global reference frame, starting in the neutral arm position.
The values plotted are with respect to the starting $x/y/z$ EFF position.

\begin{figure}[h]
	\includegraphics[width = 9 cm]{effx_example.png}
	\caption{Example Action Planner Execution, EFF $X$ motion}
	\label{fig:effX}
\end{figure}

\begin{figure}[h]
	\includegraphics[width = 9 cm]{effy_example.png}
	\caption{Example Action Planner Execution, EFF $Y$ motion}
	\label{fig:effY}
\end{figure}

\begin{figure}[h]
	\includegraphics[width = 9 cm]{effz_example.png}
	\caption{Example Action Planner Execution, EFF $Z$ motion}
	\label{fig:effZ}
\end{figure}

The Flow* approximations, shown in green, show the computed reachable set for each EFF position variable $(x,y,z)$ as a function of time.
The range of the reachable set are small at each time step as the initial conditions for the computation are scalar values rather than a range.
Given a range of initial conditions (representing, for example, error in the measured joint angles) the computed reachable sets would show a greater range of values - the green lines wold appear more like funnels showing the over approximated upper and lower bounds for the variables.
The reachable sets shown here are computed with scalar initial conditions for clarity.

The reachable sets computed from the linear model predict small deviations ($<$ 2 cm) of the $x$ and $y$ EFF values during the motion and show the $z$ value converging to the desired value of -0.1, albeit with some oscillation.
Despite the near 5 cm overshoot in the $z$ direction predicted by the linear model, the small predicted $x$ and $y$ deviations may be sufficient for a successfully attaching a module.
However, the EFF motions recorded in the Baxter simulator and physical robot clearly do not agree with the predicted motions.
The data from the simulated Baxter robot shows significantly increased oscillations and the data from the physical robot shows stiff, heavily damped motions.
The motions of the physical robot during the execution of the action planner were observed to be stiff, jerky, and unrepeatable, likely due to significant, asymmetric friction in the arm joints.
Increasing the damping control term increased the stiff, jerky arm motions and decreasing the damping term resulted in continual oscillations - the damping parameter was ``tuned'' but ultimately the arm behavior was to erratic to be effective.
As such, the output of the reachable set computation is not valid in this case for determining the safety of a given controller.

\subsection{First Order Joint Control for Demonstration}
A first order (joint speed) controller was implemented in an effort to avoid the erratic behavior of the LQR and PD joint torque controllers.
Using the global reference frame Jacobian computed in the Matlab Robotics Toolbox, the required joint velocities are computed for a desired end effector translation.
This controller was used for the demonstration examples.

\subsection{Action Planner - Successes and Failures}
The implementation of the action planner as a ROS action server, integration of Matlab and the Robotics Toolbox, and Flow* model generation and computation were all successful during this project.
However, the torque controller developed for this work was ultimately unsuccessful due to the erratic and unpredictable nature of the arm motions during joint torque control.
Future work on developing an effective joint torque controller for the Baxter robot should focus on characterizing each arm joint with respect to friction and damping.
This characterization may allow for properly determining the PD stiffness and damping terms for each joint for a given motion.

In addition, future work should focus on the validity of the linearized manipulator model.
Bounding the error of the linearizion will allow the reachability computation to formally verify the controller/motion.

\begin{comment}
The action planning stage of the assembly process is broken down into two parts: modeling the manipulator behavior as a hybrid system and verifying safety conditions of the end effector motions (making sure that undesirable motions do not occur).

\subsection{Hybrid system modeling}
The trajectory planner discussed in the previous section is responsible for moving each arm (trajectory execution) to within some bound of the final desired end effector position (determined by the task planner) for either (i) grasping or (ii) component alignment.
The trajectory planner provides to the action planner the final positions of the end effectors with respect to the appropriate blocks for (i) grasping, or (ii) alignment at attachment.
In either case, it is beneficial to avoid damaging a robot module or failing to complete a grasp or attachment due to position and alignment errors.
For the proposed scenario of assembling modular robotic components, we implement a system similar to a framework \cite{6016596} developed to address the verification of control architectures for autonomous robotic surgery manipulation tasks with respect to various safety conditions, denoted as $\varphi$, such as avoiding end effector misalignment or excessive force application.

In the previously mentioned framework, the system is modeled as a hybrid automaton \cite{Alur1993}, composed of discrete states (tasks/behaviors) and continuous dynamics associated with each state or behavior.
In our case of modular robot assembly, each state consists of \textit{fast approach}, which is handled by the trajectory planner, and \textit{slow approach}, \textit{alignment}, \textit{grasping}, and \textit{connecting}, handled by the action planner.
Each state also contains a controller, a set of invariants (conditions required to be true while the automaton is in that state), and a set of guards (conditions that must be true in order for a state transition to take place).

\subsection{Verification of Behaviors}
In order to verify that the safety conditions $\varphi$ are satisfied for the discrete state controllers, the reachable set of the system $\textit{ReachSet}_{\mbox{\textit{H}}}$, which is the set of all reachable states from some initial condition, $X_0$, can be compared to the set of states for which the safety properties are not satisfied, $\neg \mbox{Sat}(\varphi)$.
However, computing the exact set of reachable states is difficult \cite{Henzinger:1995:WDH:225058.225162} and approximations may be used instead.
In this case, a reachability tool (e.g. \textit{SpaceEx}~\cite{rehseGDCRLRGDM11}), which computes approximate reachable sets given the system dynamics and controllers, can be used to over-approximate the reachable set of the hybrid system $\textit{ReachSet}_{\mbox{\textit{H}}}$ such that $\mbox{\textit{ReachSet}}_{\mbox{\textit{H}}} \supseteq \mbox{Sat}(\varphi)$, where $\mbox{Sat}(\varphi)$ is the set of states that satisfies $\varphi$.
If $\mbox{\textit{ReachSet}}_{\mbox{\textit{H}}}$ does not intersect with the set of states for which the safety conditions $\varphi$ is not satisfied, $\mbox{\textit{ReachSet}}_{\mbox{\textit{H}}} \cap \neg \mbox{Sat}(\varphi) = \emptyset$, the safety of the system is verified.

In the case that $\mbox{\textit{ReachSet}}_{\mbox{\textit{H}}} \cap \neg \mbox{Sat}(\varphi) \neq \emptyset$, the inconclusive nature of the system is communicated to the trajectory planner and the system will either (i) re-plan the arm motions or (ii) adjust the boundaries specified in the safety conditions, $\varphi$ and recompute the system reachability.

\end{comment}


\section{Module 70 : Static Single Assignment IR}
Consider the following example

    \[x = y+z\]
    \[x = x+1\]
    \[w=y+z\]
    \[z=x+3\]

In this example, the computation $y+z$ could be reused.
In SSA, we assign versions to variables(as below) and each version has only one assignment to it. SSA stands for single assignment in a static program.
    \[x_1 = y+z\]
    \[x_2 = x_1+1\]
    \[w_1=y+z\]
    \[v_1=x_2+3\]

Using SSA, we can not optimize the code by rewriting $w_1 = y+z$ as $w_1 = x_1$.

    \[x_1 = y+z\]
    \[x_2 = x_1+1\]
    \[w_1=x_1\]
    \[v_1=x_2+3\]

Why SSA? Advantages of SSA:
\begin{itemize}
    \item Optimization algorithms become simpler if each variable has only one definition.
    \item Unrelated uses of same variable become independent.
    \item More values become available at each program point.
\end{itemize}
Therefore, SSA is a very popular method of IR design. LLVM IR is also an SSA IR.

\subsection{Converting to SSA}
\begin{itemize}
    \item Replace the target of each assignment with a new variable.
    \item Replace each use of a variable with the version of the variable reaching that point.
\end{itemize}
Again, taking an example:

    \[x = y+z\]
    \[a = b+x\]
    \[x=a+3\]
    \[y=x-a\]
On applying the two rules for conversion to SSA, these statements change to :
     \[x_1 = y+z\]
    \[a = b+x_1\]
    \[x_2=a+3\]
    \[y=x_2-a\]

\begin{figure*}
\centering
\includegraphics[height=8cm]{images/Example1.png}
\caption{Converting to SSA Example}
\end{figure*}

Consider another example as shown in Figure 1:

In this example, there are 2 variables of interest. $x$ is assigned thrice and $y$ is assigned thrice. On applying the rules of SSA conversion, here is how the code snippet looks like.

The versioning is straightforward for variable $x$. For $y$ in this example, there are two versions reaching at the bottom block from two different paths. The question is how we version the variable $y$ at bottom block. To answer that , we need to understand about basic block
\begin{figure*}
\centering
\includegraphics[height=8cm]{images/Example2.png}
\caption{Converting to SSA Example - With Versions}
\end{figure*}

\subsection{Basic Block}:
A basic block is a maximal set of instructions with
\begin{itemize}
    \item no labels( except at the first instruction)
    \item no jumps (except in the last instruction)
\end{itemize}

In the example, each rectangle is a basic block.
Idea:
\begin{itemize}
    \item Cannot jump into a basic block (except at beginning)
    \item cannot jump out of a basic block (except at end)
    \item Single-entry single-exit straight line code segment
\end{itemize}

At the bottom block, there are two version reaching for variable $y$. To represent that we use $\Phi$ node or $\Phi$ function. So the version of y can be represented as a function of $y_1$ and $y_2$ as shown in figure XXX. This is an ordered set.

\begin{figure*}
\centering
\includegraphics[height=8cm]{images/Example3.png}
\caption{Converting to SSA Example - PHI Nodes}
\end{figure*}

\subsection{PHI($\Phi$) Nodes}
\begin{itemize}
    \item $\Phi$ function chooses the version depending on the incoming edge.
    \item Present only at the beginning of a basic block. Since this is the only place where there are multiple versions flowing through different incoming edges.
\end{itemize}


% Copyright 2018 Melvin Eloy Irizarry-Gelpí
\chapter{Hyper AS Quaternions}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
An exo-1 split binion has the form
\begin{equation}
    a_{0} + a_{1} S + a_{2} W + a_{3} SW
\end{equation}
These follow from a parabolic Cayley-Dickson construct on the split binions.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Arithmetic Operations}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Multiplication}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Conjugate Operations}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Asterisk Conjugation}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Quadrance}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Cloak Conjugation}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Dagger Conjugation}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Hodge Star}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Differential Operators}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
...


\chapter{Introduction and History }

In mathematics, logic, and thoretical computer science, a \textit{Type System} is any of a class of formal systems which can serve as alternative standard logic system of sets. We consider every "\textit{object}" has a "type" and all different kinds of operations are restricted to the objects of only a particular type.\\

\textbf{Type Theory} is closely related to and is often served as the basis of modern computer's type systems, which are a \textit{programming language feature} for common bug reduction. Type theory was studied to avoid paradoxes like \underline{Kleene–Rosser paradox , Rossel's Paradox} \cite{russel} in a variety of formal logics and to rewrite systems. It describes the correctness of step-by-step working of an abstract model of machine. This along with complexity theory does constitute the system theory for complete functioning of any computational machine.\\

Organized research for the mathematics foundation started at the end of the 19th century and formed a new mathematical discipline called mathematical logic, which strongly links to theoretical computer science. It went through a lot of paradoxical results, until the discoveries stabilized during the 20th century with finally imparting mathematical knowledge with several new aspects and components known as  \textit{set theory, model theory, proof theory, etc.} , whose properties are still an active research field. \textit{Stephan Wolfram} in his book titled \underline{New Kind of Science} \cite{newkindofscience} explores the computational aspects of machine and tries to focus on the idea that simple systems can actually reason perfectly for complex behaviour of a large systems. Classical examples of simple Cellular Automaton* and Turing-Complete machines have been studied.\\

Type theory in a similar sense argues that complex working can be induced from logic constraints of simpler systems. A small Type system can thus account for type-safe* behaviour of a computer system. Now for better comprehension we use the concept of $(\lambda)$-calculus to combine abstraction of type models. In mathematics, two well-known type theories that can serve as logic foundation for a system are \textit{Alonzo Church's} \textbf{ typed $(\lambda)$-calculus} \cite{typed_lambda} and \textit{Per Martin-Lof's } \textbf{intuitionistic type theory}\cite{per_martin_tt}.

\section{$\lambda$-Calculus}

Lambda calculus\cite{lambda_calculus} is a formal system in mathematical logic for expressing computation based on function abstraction and its application using variable binding and substitution. It is an accepted universal model of computation based on reduction and abstraction that can be used to theoretically understand behaviour of Turing machine. It was introduced in 1930s by mathematician Alonzo Church. This deals with constructing lambda terms (variable terms which change according to conditions and boundness) and performing reduction operations on them. Reduction Operations consist of $\alpha  and  \beta $ transformations. The former deals with renaming bound variable's name and second with replacing the bound variable with the argument expression in the body of the abstraction.It follows left associtivity i.e \textit{fgh} is just syntactic sugar (alternate form of represetation ) for \textit{(fg)h}.\\

A working thumb rule for performing reductions :
\[
 \boxed {(\lambda param . output)input \implies output [param := input] \implies result }
\]

Example : \[(\lambda x.xy)z \longrightarrow {}_\beta(xy)[x:=z] \longrightarrow {}_\beta (zy) \longrightarrow zy \]

\section{Intuitional Type theory}

Intuitionistic type theory (also known as constructive type theory, or Martin-Lof type theory) has mathematical constructs  built to follow a one-to-one correspondence with logical connectives. For example, the logical connective called implication ( { A$\implies$ B} ) corresponds to the type of a function ( { A$\to$ B}). This correspondence is called the \textit{Curry $–$ Howard isomorphism}. This basically is an equivalent of unique mapping and existence of inverse as in the theory of sets. Previous type theories also followed this isomorphism, but Martin-Lof's was the first to extend it by introducing \textbf{Dependent types} as a basis of \textit{High Order function dependence on basic functions}.\\

\hfill \break \textbf{Machine Assisted Proving} dates back as early as 1976 when the four color theorem was verified using a computer program. Butterfly Effect's discovery also was possible due to computer simulation of program with given some finite initial states. Most computer-aided proofs to date have been implementations of large \textit{Proofs-By-Case} of a mathematical theorem. It is also called as \textit{Proof-By-Induction}  where child cases are considered first in an attempt to fully prove a theorm. Various attempts have been made in the area of \textit{Artificial Intelligence} research to create smaller, explicit proofs of mathematical theorems using machine reasoning techniques such as \textit{heuristic search}.\\

Such \textbf{Automated Theorem Provers} have found new proofs for known theorems also given a number of new results. Additionally, interactive proof assistants allow mathematicians to develop acceptable human-readable proofs which are then again verified too in a similar procedure.

\section{Proof Assistants Introduction}

Machine theorem basically involves model checking, which, in the simplest case involves brute-force enumeration of many possible states (although the actual implementation of model checkers requires much robustness for checking every case, and it does not simply reduce to brute force). There are \textit{hybrid} theorem  proving systems which use model checking as an inference rule. There are also programs which were written to prove a particular theorem, with an assumption that if the program finishes with a certain result, then our proposed theorem is true.\\

In computer science and mathematical logic, a \textbf{Proof Assistant or Interactive Theorem Prover} is a software tool to help with the development of formal proofs. This involves interactive editor, or other interface, with which a human can guide the search for proofs. Some steps are reduced by the computer and base cases are enlisted to be proved. We will discuss this part later. \\

\hfill \break In the present Programming Language research, the correctness of \textit{Computer Programs} is proved using similar notions considering some "pre" and "post" cases. This idea can thus be extended to proving correctness of a programing language semantics. \\

Currently the developments in Quantum Computing strongly uses these proof-based programming language mainly because of the completely random behaviour of a \textit{Quantum states} of \underline{Qubits}. All that we have are probablities of
existence of a given quantum state. Let's say we can we can organize the chaos to some extent by \textit{categorizing} those probabilities in few cases, then later operations and control logics will have to have an inductive transfer of the qubit's states. This is analogus to how we deal with things in Type theory. Therefore developing a strong typed abstract model will benefit quantum computing to a much bigger extent.\\

We will understand the working of proof assistants by firstly revisiting topics in abstract algebra, computer architecture and compiler technology. We will then proceed to introduce the type systems and core elements of type theory in study and finally combine both to reason for correctness of a programming language and a programming stack.\\

I have later introduced concepts of quantum computing followed by the application of type theory in it to put some light on some ongoing active research in that field.\\


% !TEX root = main.tex

\section{Tables}

\subsection{Inline}
An inline \texttt{tabular} environment:
\begin{tabular}{|ccc|}\hline
$\alpha$ & $\beta$ & $\gamma$ \\ \hline
$1/2$ & $1/3$ & $1/6$ \\ \hline
\end{tabular}

\subsection{Display}
A centred \texttt{tabular} environment:
\begin{center}
\begin{tabular}{|c|c|c|}
\hline
a & b & c \\
\hline
d & e & f \\
\hline
\end{tabular}
\end{center}

\subsection{Floats}

A {\tt table} environment:
\begin{table}[htb]
\centering
\begin{tabular}{|c|c||c|c|c|} \hline
Set Theory 		& 			& Logic			&		& \\ \hline
Union			& $A\cup B$	& Disjunction 	& OR 	& $\lor$	\\
Intersection		& $A\cap B$	& Conjunction	& AND 	& $\land$\\
Complement		& $A^c$		& Negation		& NOT 	& $\lnot$	\\ \hline
\end{tabular}
\caption{Logic and Set Theory}
\end{table}

A {\tt table} environment with a starred {\tt caption}:
\begin{table}[ht]
\centering
\begin{tabular}{|c|c|c|}
\hline
a & b & c \\
\hline
d & e & f \\
\hline
\end{tabular}
\caption*{Another table}
\end{table}


\subsection{Scheduling: Preemptive, Size-Based}
\label{sec:Scheduling-Preemptive-Size-Based}

The most common preemptive size-based scheduling policies are

\begin{description}

	\item [Preemptive Shortest-Job-First (PSJF)] the server chooses the job with the smallest size, eventually preempting the current running job.

	\item [Shortest Remaining Process-Time (SRPT)] the server chooses the job with the shortest remaining process time; a new arrival preempts the current job if the new arrival has shorter remaining process time.

\end{description}

Preemptive policies that make use of job sizes can reach high performance biasing towards small jobs.

It is convenient to evaluate PSJF as \textit{preemptive priority queueing} where priority classes are job sizes and a job has higher priority if it has lower job size.

It is not possible to evaluate SRPT with the same model, because the remaining process time changes in time, whereas the preemptive priority model does not allow jobs to change priority.

\subsection{Preemptive Priority Queueing}
\label{sec:P-Priority}

In preemptive priority queueing (P-Priority), one can view the response time as divided into

\begin{description}

	\item [Waiting Time $Wait(x)$] the time until a job first starts serving.

	\item [Residence Time $Res(x)$] the time from when job first gets served until it leaves the system (including all interruptions due to preemption).

\end{description}

In such a model, we have that

\begin{equation}
\label{eqn:P-Priority-Mean-Time-Size}
\expected{T(x)}^{\mathit{P-Priority}}=
\expected{Res(x)}^{\mathit{P-Priority}} + \expected{Wait(x)}^{\mathit{P-Priority}}=
\frac{\expected{S_{x}}}{1-\sum_{i=1}^{x-1}\varrho_{i}}+
\frac{\sum_{i=1}^{x}\frac{\varrho_{i}\expected{S_{i}^{2}}}{2\expected{S_{i}}}}
	 {\Big(1-\sum_{i=1}^{x-1}\varrho_{i}\Big)\Big(1-\sum_{i=1}^{x}\varrho_{i}\Big)}
\end{equation}

To determine $\expected{T}^{\mathit{P-Priority}}$ we need transform analysis.

In $\mathit{P-Priority}$ model, a job of priority $x$ only sees the variability and the load created by the first $x$ classes. Hence, a high priority job (low $x$) wins, even under high-variability job sizes.

We will use these results to analyze PSJF.

\subsection{Scheduling: PSJF}
\label{sec:Scheduling-PSJF}

We model PSJF as P-Priority with infinite priority classes, where the smaller the job, the higher the priority.

By applying \Cref{eqn:P-Priority-Mean-Time-Size}, we obtain:

\begin{equation}
\label{eqn:PSJF-Mean-Time-Size}
\expected{T(x)}^{\mathit{PSJF}}=
\expected{Res(x)}^{\mathit{PSJF}}+\expected{Wait(x)}^{\mathit{PSJF}}=
\frac{x}{1-\varrho_{x}}+
\frac{\frac{\lambda}{2}\int_{0}^{x}f(t)t^{2}\partial t}
{\Big(1-\varrho_{x}\Big)^{2}}
\end{equation}

where $\varrho_{x}=\lambda\int_{t=0}^{x}tf(t)\partial t$ is the load made up by jobs of size less than $x$.

To determine $\expected{T}^{\mathit{PSJF}}$ we need transform analysis.

\subsection{Scheduling: SRPT}
\label{sec:Scheduling-SRPT}

SRPT achieves the lowest possible mean response time on every arrival sequence.

We cannot model SRPT as P-Priority, because the remaining process time changes with time.

We obtain that

\begin{equation}
\label{sec:SRPT-Mean-Time-Size}
\expected{T(x)}^{\mathit{SRPT}}=
\expected{Wait(x)}^{\mathit{SRPT}}+\expected{Res(x)}^{\mathit{SRPT}}=
\frac{\lambda}{2}\frac{\int_{t=0}^{x}t^{2}f(t)\partial t + x^{2}(1-F(x))}{\Big(1-\varrho_{x}\Big)^{2}}+
\int_{t=0}^{x}\frac{1}{1-\varrho_{t}}
\end{equation}

We notice that the response time
(i) is only sensitive of variance of the job size distribution up to size $x$
(ii) is only sensitive of load made up of jobs of size up to size $x$
This is why small jobs win under SRPT.

Let us compare SRPT with PSJF.
The waiting time of SRPT is greater than that for PSJF, but the residence time is smaller because a job must only wait for job with shorter remaining process time whereas under PSJF must wait for all jobs smaller than its original size.
The benefit of $\expected{T}^{\mathit{SRPT}}$ makes SRPT better than PSJF with respect to the mean response time.

Let us compare SRPT with FB.
SRPT and FB are complementary. In SRPT, a job gains priority as it receives more service. In, FB a job loses priority as times goes on.

We have that, in $M/G/1$, for all $x$ and $\varrho$
\begin{equation}
\expected{T(x)}^{\mathit{SRPT}}\leq\expected{T(x)}^{\mathit{FB}}
\end{equation}

Let us compare SRPT with PS.
Seems that large jobs should prefer PS over SRPT, because they have low priority in SRPT, while they are threated equally under PS. This is not true. Under SRPT large jobs start with low priority, but they gain more and more priority from the time they first get served, on.

SRPT is more fair than PS. Even if it does not seem so, large jobs and small jobs have nearly the same Slowdown, because large jobs gain priority with time.

\begin{theorem}[All-Can-Win]
\label{thm:All-Can-Win}
We have that, in $M/G/1$, for all $x$ and $\varrho<\frac{1}{2}$
\begin{equation}
\label{eqn:All-Can-Win}
\expected{T(x)}^{\mathit{SRPT}}\leq\expected{T(x)}^{\mathit{PS}}
\end{equation}
\end{theorem}

The \Cref{thm:All-Can-Win} holds for every job size distribution $G$. For many $G$, the restriction on $\varrho$ is much looser\footnote{If $G$ is a Bounded-Pareto with $\alpha=1.1$, we have that \Cref{thm:All-Can-Win} holds for $\varrho<0.96$.}.