%\documentclass[runningheads,oribibl]{llncs}
\documentclass[runningheads]{llncs}
\usepackage{natbib}
% \usepackage{stmaryrd}
% \usepackage{proof}
% \usepackage{amsmath}
% \usepackage{amssymb}
% \usepackage{color}
% \usepackage{bbm}
% \usepackage[greek,english]{babel}
% \usepackage{ucs}
% \usepackage[utf8x]{inputenc}
% \usepackage{autofe}
\usepackage{agda}
\usepackage{revsymb}
\usepackage{semantic}
\usepackage{graphicx}
\usepackage{url}
\renewcommand\UrlFont{\color{blue}\rmfamily}
\usepackage{stix}
\setcitestyle{round,aysep={}}

\begin{document}
\title{Programming Language Foundations in Agda}
\author{Philip Wadler}
\authorrunning{P. Wadler}
\institute{University of Edinburgh\\
  \email{wadler@inf.ed.ac.uk}}
\maketitle
%
\begin{abstract}
One of the leading textbooks for formal methods is
\emph{Software Foundations} (SF), written by Benjamin Pierce in
collaboration with others, and based on Coq. After five years using SF
in the classroom, I have come to the conclusion that Coq is not the
best vehicle for this purpose, as too much of the course needs to
focus on learning tactics for proof derivation, to the cost of
learning programming language theory.  Accordingly, I have written a
new textbook, \emph{Programming Language Foundations in Agda} (PLFA).
PLFA covers much of the same ground as SF, although it is not a
slavish imitation.

What did I learn from writing PLFA? First, that it is possible. One
might expect that without proof tactics that the proofs become too
long, but in fact proofs in PLFA are about the same length as those in
SF. Proofs in Coq require an interactive environment to be understood,
while proofs in Agda can be read on the page.  Second, that
constructive proofs of preservation and progress give immediate rise
to a prototype evaluator. This fact is obvious in retrospect but it is
not exploited in SF (which instead provides a separate normalise
tactic) nor can I find it in the literature.  Third, that using raw
terms with a separate typing relation is far less perspicuous than
using inherently-typed terms. SF uses the former presentation, while
PLFA presents both; the former uses about 1.6 as many lines of Agda
code as the latter, roughly the golden ratio.

The textbook is written as a literate Agda script, and can be found here:
\begin{center}
\url{http://plfa.inf.ed.ac.uk}
\end{center}
\keywords{Agda \and Coq \and lambda calculus \and dependent types.}
\end{abstract}

\section{Introduction}

The most profound connection between logic and computation is a pun.
The doctrine of Propositions as Types asserts that a certain kind of formal
structure may be read in two ways: either as a proposition in logic or
as a type in computing.  Further, a related structure may be read as
either the proof of the proposition or as a programme of the
corresponding type.  Further still, simplification of proofs
corresponds to evaluation of programs.

Accordingly, the title of this paper, and the corresponding textbook,
\emph{Programming Language Foundations in Agda} (hence, PLFA)
also has two readings.  It may be parsed as ``(Programming Language)
Foundations in Agda'' or ``Programming (Language Foundations) in
Agda''---specifications in the proof assistant Agda both describe
programming languages and are themselves programmes.

Since 2013, I have taught a course on Types and Semantics for
Programming Languages to fourth-year undergraduates and masters
students at the University of Edinburgh.  An earlier version of that
course was based on \emph{Types and Programming Languages} by
\citet{Pierce-2002}, but my version was taught from its successor,
\emph{Software Foundations} (hence, SF) by \citet{Pierce-et-al-2010},
which is based on the proof assistance Coq \citep{Huet-et-al-1997}.
I am convinced by the claim of \citet{Pierce-2009}, made in his ICFP
Keynote \emph{Lambda, The Ultimate TA}, that basing a course around a
proof assistant aids learning.

However, after five years of experience, I have come to the conclusion
that Coq is not the best vehicle.  Too much of the course needs to
focus on learning tactics for proof derivation, to the cost of
learning the fundamentals of programming language theory.  Every
concept has to be learned twice: e.g., both the product data type, and
the corresponding tactics for introduction and elimination of
conjunctions.  The rules Coq applies to generate induction hypotheses
can sometimes seem mysterious.  While the \texttt{notation} construct
permits pleasingly flexible syntax, it can be confusing that the same
concept must always be given two names, e.g., both
\texttt{subst~N~x~M} and \texttt{N~[x~:=~M]}.  Names of tactics are
sometimes short and sometimes long; naming conventions in the standard
library can be wildly inconsistent.  \emph{Propositions as types} as a
foundation of proof is present but hidden.

I found myself keen to recast the course in Agda \citep{Bove-et-al-2009}.
In Agda, there is
no longer any need to learn about tactics: there is just
dependently-typed programming, plain and simple. Introduction is
always by a constructor, elimination is always by pattern
matching. Induction is no longer a mysterious separate concept, but
corresponds to the familiar notion of recursion. Mixfix syntax is
flexible while using just one name for each concept, e.g.,
substitution is \texttt{\_[\_:=\_]}. The standard library is not perfect, but
there is a fair attempt at consistency. \emph{Propositions as types} as a
foundation of proof is on proud display.

Alas, there is no textbook for programming language theory in
Agda.  \emph{Verified Functional Programming in Agda} by \citep{Stump-2016}
covers related ground, but focusses more on programming with dependent
types than on the theory of programming languages.

The original goal was to simply adapt \emph{Software Foundations},
maintaining the same text but transposing the code from Coq to Agda.
But it quickly became clear to me that after five years in the
classroom I had my own ideas about how to present the material.  They
say you should never write a book unless you cannot \emph{not} write the
book, and I soon found that this was a book I could not not write.

I am fortunate that my student, Wen Kokke, was keen to help.  She
guided me as a newbie to Agda and provided an infrastructure that is
easy to use and produces pages that are a pleasure to view.
The bulk of the book was written January--June 2018, while on
sabbatical in Rio de Janeiro.

This paper is a personal reflection, summarising what I learned in the
course of writing the textbook. Some of it reiterates advice that is
well-known to some members of the dependently-typed programming
community, but which deserves to be better known.  The paper is
organised as follows.

Section~2 outlines the
topics covered in PLFA, and notes what is omitted.

Section~3 compares Agda and Coq as vehicles for pedagogy.  Before
writing the book, it was not obvious that it was even possible;
conceivably, without tactics some of the proofs might
balloon in size. In fact, it turns out that for the results in PLFA
and SF, the proofs are of roughly comparable size, and (in my opinion)
the proofs in PLFA are more readable and have a pleasing visual
structure.

Section~4 observes that constructive proofs of progress and
preservation combine trivially to produce a constructive evaluator for
terms.  This idea is obvious once you have seen it, yet I cannot
find it described in the literature.  For instance, SF separately
implements a \texttt{normalise} tactic that has nothing to do with
progress and preservation.

Section~5 claims that raw terms should be avoided in favour of
inherently-typed terms.  PLFA develops lambda calculus with both raw
and inherently-typed terms, permitting a comparison.  It turns out the
former is less powerful---it supports substitution only for closed
terms---but significantly longer---about 1.6 times as many lines of code,
roughly the golden ratio.

I will argue that Agda has advantages over Coq for
pedagogic purposes.  My focus is purely on the case of a proof assistant
as an aid to \emph{learning} formal semantics using examples of
\emph{modest} size.  I admit up front that
there are many tasks for which Coq is better suited than Agda.
A proof assistant that supports tactics, such as Coq or Isabelle,
is essential for formalising serious mathematics,
such as the Four-Colour Theorem \citep{Gonthier-2008},
the Odd-Order Theorem \citep{Gonthier-et-al-2013},
or Kepler's Conjecture \citep{Hales-et-al-2017},
or for establishing correctness of software at scale,
as with the CompCert compiler \citep{Leroy-2009,Kastner-et-al-2017}
or the SEL4 operating system \citep{Klein-2009,O'Connor-2016}.

\section{Scope}

PLFA is aimed at students in the last year of an undergraduate
honours programme or the first year of a master or doctorate degree.
It aims to teach the fundamentals of operational semantics of
programming languages, with simply-typed lambda calculus as the
central example.  The textbook is written as a literate script in Agda.
As with SF, the hope is that using
a proof assistant will make the development more concrete
and accessible to students, and give them rapid feedback to find
and correct misaprehensions.

The book is broken into two parts. The first part, Logical Foundations,
develops the needed formalisms.  The second part, Programming Language
Foundations, introduces basic methods of operational semantics.
(SF is divided into books, the first two of which have the same names
as the two parts of PLFA, and cover similar material.)

Each chapter has both a one-word name and a title, the one-word name
being both its module name and its file name.

\subsection*{Part I, Logical Foundations}

\paragraph{Naturals: Natural numbers}
Introduces the inductive definition of natural numbers in terms of
zero and successor, and recursive definitions of addition,
multiplication, and monus. Emphasis is put on how a tiny description
can specify an infinite domain.

\paragraph{Induction: Proof by induction}
Introduces induction to prove properties
such as associativity and commutativity of addition.
Also introduces dependent functions to express universal quantification.
Emphasis is put on the correspondence between induction and recursion.

\paragraph{Relations: Inductive definitions of relations}
Introduces inductive definitions of less than or equal on natural numbers,
and odd and even natural numbers.
Proves properties such as reflexivity, transitivity, and
anti-symmetry, and that the sum of two odd numbers is even.
Emphasis is put on proof by induction over evidence that a relation holds.

\paragraph{Equality: Equality and equational reasoning}
Gives Martin L\"of's and Leibniz's definitions of equality, and proves
them equivalent, and defines the notation for equational reasoning used
throughout the book.

\paragraph{Isomorphism: Isomorphism and embedding}
Introduces isomorphism, which plays an important role in the
subsequent development.  Also introduces dependent records, lambda
terms, and extensionality.

\paragraph{Connectives: Conjunction, disjunction, and implication}
Introduces product, sum, unit, empty, and function types, and their
interpretations as connectives of logic under Propositions as Types.
Emphasis is put on the analogy between these types and product, sum,
unit, zero, and exponential on naturals; e.g., product of numbers is
commutative and product of types is commutative up to isomorphism.

\paragraph{Negation: Negation, with intuitionistic and classical logic}
Introduces logical negation as a function into the empty
type, and explains the difference between classical and intuitionistic
logic.

\paragraph{Quantifiers: Universals and existentials}
Recaps universal quantifiers and their correspondence to dependent
functions, and introduces existential quantifiers and their
correspondence to dependent products.

\paragraph{Decidable: Booleans and decision procedures}
Introduces booleans and decidable types, and why the latter is to be
preferred to the former.

\paragraph{Lists: Lists and higher-order functions}
Gives two different definitions of reverse and proves them equivalent.
Introduces map and fold and their properties, including that fold left
and right are equivalent in a monoid.  Introduces predicates that hold
for all or any member of a list, with membership as a specialisation
of the latter.

\subsection*{Part II, Programming Language Foundations}

\paragraph{Lambda: Introduction to lambda calculus}
Introduces lambda calculus, using a representation with named
variables and a separate typing relation. The language used is PCF
\citep{Plotkin-1977}, with variables, lambda abstraction, application,
zero, successor, case over naturals, and fixpoint. Reduction is
call-by-value and restricted to closed terms.

\paragraph{Properties: Progress and preservation}
Proves key properties of simply-typed
lambda calculus, including progress and preservation.  Progress and
preservation are combined to yield an evaluator.

\paragraph{DeBruijn: Inherently typed de Bruijn representation}
Introduces de Bruijn indices and the inherently-typed representation.
Emphasis is put on the structural similarity between a term and its
corresponding type derivation; in particular, de Bruijn indices
correspond to the judgment that a variable is well-typed under a given
environment.

\paragraph{More: More constructs of simply-typed lambda calculus}
Introduces product, sum, unit, and empty types as well as lists and let bindings
are explained.  Typing and reduction rules are given informally; a few
are then give formally, and the rest are left as exercises for the reader.
The inherently typed representation is used.

\paragraph{Bisimulation: Relating reduction systems}
Shows how to translate the language with ``let'' terms
to the language without, representing a let as an application of an abstraction,
and shows how to relate the source and target languages with a bisimulation.

\paragraph{Inference: Bidirectional type inference}
Introduces bidirectional type inference, and applies it to convert from
a representation with named variables and a separate typing relation
to a representation de Bruijn indices with inherent types. Bidirectional
type inference is shown to be both sound and complete.

\paragraph{Untyped: Untyped calculus with full normalisation}
As a variation on earlier themes, discusses an untyped (but inherently
scoped) lambda calculus.  Reduction is call-by-name over open terms,
with full normalisation (including reduction under lambda terms).  Emphasis
is put on the correspondence between the structure of a term and
evidence that it is in normal form.

\subsection*{Discussion}

PLFA and SF differ in several particulars.  PLFA begins with a computationally
complete language, PCF, while SF begins with a minimal language, simply-typed
lambda calculus with booleans.  PLFA does not include type annotations in terms,
and uses bidirectional type inference, while SF has terms with unique types and
uses type checking.  SF also covers a simple imperative language with Hoare logic,
and for lambda calculus covers subtyping, record types, mutable references, and normalisation
---none of which are treated by PLFA.  PLFA covers an inherently-typed de Bruijn
representation, bidirectional type inference, bisimulation, and an
untyped call-by-name language with full normalisation---none of which
are treated by SF.

SF has a third volume, written by Andrew Appel, on Verified Functional
Algorithms. I'm not sufficiently familiar with that volume to have a view
on whether it would be easy or hard to cover that material in Agda.
And SF recently added a fourth volume on random testing of Coq specifications
using QuickChick.  There is currently no tool equivalent to QuickChick
available for Agda.

There is more material that would be desirable to include in PLFA
which was not due to limits of time.  In future years, PLFA may be
extended to cover additional material, including mutable references,
normalisation, System F, pure type systems, and denotational
semantics.  I'd especially like to include pure type systems as they
provide the readers with a formal model close to the dependent types
used in the book.  My attempts so far to formalise pure type systems
have proved challenging, to say the least.

\section{Proofs in Agda and Coq}

\begin{figure}[t]
  \includegraphics[width=\textwidth]{figures/plfa-progress-1.png}
  \caption{PLFA, Progress (1/2)}
  \label{fig:plfa-progress-1}
\end{figure}

\begin{figure}[p]
  \includegraphics[width=\textwidth]{figures/plfa-progress-2.png}
  \includegraphics[width=\textwidth]{figures/plfa-progress-3a.png}
  \caption{PLFA, Progress (2/2)}
  \label{fig:plfa-progress-2}
\end{figure}

\begin{figure}[t]
  \includegraphics[width=\textwidth]{figures/sf-progress-1.png}
  \caption{SF, Progress (1/2)}
  \label{fig:sf-progress-1}
\end{figure}

\begin{figure}[t]
  \includegraphics[width=\textwidth]{figures/sf-progress-2.png}
  \caption{SF, Progress (2/2)}
  \label{fig:sf-progress-2}
\end{figure}

% \begin{figure}[t]
%   \includegraphics[width=\textwidth]{figures/sf-progress-3.png}
%   \caption{SF, Progress (3/3)}
%   \label{fig:sf-progress-3}
% \end{figure}

The introduction listed several reasons for preferring Agda over Coq.
But Coq tactics enable more compact proofs. Would it be possible for
PLFA to cover the same material as SF, or would the proofs
balloon to unmanageable size?

As an experiment, I first rewrote SF's development of simply-typed
lambda calculus (SF, Chapters Stlc and StlcProp) in Agda.  I was a
newbie to Agda, and translating the entire development, sticking as
closely as possible to the development in SF, took me about two days.
I was pleased to discover that the proofs remained about the same
size.

There was also a pleasing surprise regarding the structure of the
proofs. While most proofs in both SF and PLFA are carried out by
induction over the evidence that a term is well typed, in SF the
central proof, that substitution preserves types, is carried out by
induction on terms for a technical reason
(the context is extended by a variable binding, and hence not
sufficiently ``generic'' to work well with Coq's induction tactic). In
Agda, I had no trouble formulating the same proof over evidence that
the term is well typed, and didn't even notice SF's description of the
issue until I was done.

The rest of the book was relatively easy to complete.  The closest to
an issue with proof size arose when proving that reduction is
deterministic.  There are 18 cases, one case per line.  Ten of the
cases deal with the situation where there are potentially two
different reductions; each case is trivially shown to be
impossible.  Five of the ten cases are redundant, as they just involve
switching the order of the arguments.  I had to copy the cases
suitably permuted. It would be preferable to reinvoke the proof on
switched arguments, but this would not pass Agda's termination checker
since swapping the arguments doesn't yield a recursive call on
structurally smaller arguments.  I suspect tactics could cut down the
proof significantly. I tried to compare with SF's proof that reduction
is deterministic, but failed to find that proof.

SF covers an imperative language with Hoare logic, culminating in
code that takes an imperative programme suitably decorated with preconditions
and postconditions and generates the necessary
verification conditions. The conditions are then verified by a custom
tactic, where any questions of arithmetic are resolved by the
``omega'' tactic invoking a decision procedure.  The entire
exercise would be easy to repeat in Agda, save for the last step: I
suspect Agda's automation would not be up to verifying the generated
conditions, requiring tedious proofs by hand.  However, I had already
decided to omit Hoare logic in order to focus on lambda calculus.

To give a flavour of how the texts compare, I show the
proof of progress for simply-typed lambda calculus from both texts.
Figures~\ref{fig:plfa-progress-1} and \ref{fig:plfa-progress-2}
are taken from PLFA, Chapter Properties,
while Figures~\ref{fig:sf-progress-1} and \ref{fig:sf-progress-2}
are taken from SF, Chapter StlcProp.
Both texts are intended to be read online,
and the figures were taken by grabbing bitmaps of the text as
displayed in a browser.

PLFA puts the formal statements first, followed by informal explanation.
PLFA introduces an auxiliary relation \texttt{Progress} to capture
progress; an exercise (not shown) asks the reader to show it isomorphic
to the usual formulation with a disjunction and an existential.
Layout is used to present the auxiliary relation in inference rule form.
In Agda, any line beginning with two dashes is treated as a comment, making
it easy to use a line of dashes to separate hypotheses from conclusion
in inference rules.  The proof of proposition \texttt{progress} (the different
case making it a distinct name) is layed out carefully. The neat
indented structure emphasises the case analysis, and all right-hand
sides line-up in the same column.  My hope as an author is that students
will read the formal proof first, and use it as a tabular guide
to the informal explanation that follows.

SF puts the informal explanation first, followed by the formal proof.
The text hides the formal proof script under an icon;
the figure shows what appears when the icon is expanded.
As a teacher I was aware that
students might skip it on a first reading, and I would have to hope the
students would return to it and step through it with an interactive
tool in order to make it intelligible.  I expect the students skipped over
many such proofs.  This particular proof forms the basis for a question
of the mock exam and the past exams, so I expect most students will actually
look at this one if not all the others.

\newcommand{\ex}{\texttt{x}}
\newcommand{\why}{\texttt{y}}
\newcommand{\EL}{\texttt{L}}
\newcommand{\EM}{\texttt{M}}
\newcommand{\EN}{\texttt{N}}
\newcommand{\tee}{\texttt{t}}
\newcommand{\tick}{\texttt{\lq}}
\newcommand{\GG}{\Gamma}
\newcommand{\AY}{\texttt{A}}
\newcommand{\BE}{\texttt{B}}

(For those wanting more detail: In PLFA, variables and abstractions and
applications in the object language are written $\tick\;\ex$ and
$\lambdabar\;\ex\;{\Rightarrow}\;\EN$ and $\EL\;{\cdot}\;\EM$.  The
corresponding typing rules are referred to by ${\vdash}\tick\;()$
and ${\vdash}\lambdabar\;{\vdash}\EN$ and ${\vdash}\EL\;{\cdot}\;{\vdash}\EM$, where
${\vdash}\EL$, ${\vdash}\EM$, ${\vdash}\EN$ are the proofs that terms
$\EL$, $\EM$, $\EN$ are well typed, and `()` denotes that there cannot
be evidence that a free variable is well typed in the empty context.
It was decided to overload infix dot for readability, but not other
symbols. In Agda, as in Lisp, almost any sequence of characters is a
name, with spaces essential for separation.)

(In SF, variables and abstractions and applications in
the object language are written $\texttt{tvar}~\ex$ and
$\texttt{tabs}~\ex~\tee$ and $\texttt{tapp}~\tee_1~\tee_2$.
The corresponding typing rules are referred to as
$\texttt{T\_Var}$ and $\texttt{T\_Abs}$ and $\texttt{T\_App}$.)

Both Coq and Agda support interactive proof.  Interaction in Coq is
supported by Proof General, based on Emacs, or by CoqIDE, which
provides an interactive development environment of a sort familiar to
most students.  Interaction in Agda is supported by an Emacs mode.

In Coq, interaction consists of stepping through a proof script, at
each point examining the current goal and the variables currently in
scope, and executing a new command in the script.  Tactics are a whole
sublanguage, which must be learned in addition to the language for
expressing specifications.  There are many tactics one can invoke in
the script at each point; one menu in CoqIDE lists about one hundred
tactics one might invoke, some in alphabetic submenus.  A Coq
script presents the specification proved and the tactics executed.
Interaction is recorded in a script, which the students
may step through at their leisure.  SF contains some prose descriptions
of stepping through scripts, but mainly contains scripts that students
are encouraged to step through on their own.

In Agda, interaction consists of writing code with holes, at each
point examining the current goal and the variables in scope, and
typing code or executing an Emacs command.  The number of commands
available is much smaller than with Coq, the most important ones being
to show the type of the hole and the types of the variables in scope;
to check the code; to do a case analysis on a given variable; or to
guess how to fill in the hole with constructors or variables in scope.
An Agda proof consists of typed code.  The interaction is \emph{not}
recorded.  Students may recreate it by commenting out bits of code and
introducing a hole in their place.   PLFA contains some prose descriptions
of interactively building code, but mainly contains code that students
can read.  They may also introduce holes to interact with the code, but
I expect this will be rarer than with SF.

SF encourages students to interact with all the scripts in the text.
Trying to understand a Coq proof script without running it
interactively is a bit like understanding a chess game by reading
through the moves without benefit of a board, keeping it all in your
head.  In contrast, PLFA provides code that students can read.
Understanding the code often requires working out the types, but
(unlike executing a Coq proof script) this is often easy to do in your
head; when it is not easy, students still have the option of
interaction.

While students are keen to interact to create code, I have found they
are reluctant to interact to understand code created by others. For
this reason, I suspect this may make Agda a more suitable vehicle for
teaching.  Nate Foster suggests this hypothesis is ripe to be tested
empirically, perhaps using techniques similar to those of
\citet{Danas-et-al-2017}.

Neat layout of definitions such as that in
Figure~\ref{fig:plfa-progress-2} in Emacs requires a monospaced font
supporting all the necessary characters.  Securing one has proved
tricky. As of this writing, we use FreeMono, but it lacks a few
characters ($\typecolon$ and $\qed$) which are loaded from fonts with a different
width.  Long arrows are necessarily more than a single character wide.
Instead, we compose reduction —→ from an em dash — and an arrow →.
Similarly for reflexive and transitive closure —↠.

\section{Progress + Preservation = Evaluation}

\begin{figure}
  \includegraphics[width=\textwidth]{figures/plfa-eval.png}
  \caption{PLFA, Evaluation}
  \label{fig:plfa-eval}
\end{figure}

A standard approach to type soundness used by many texts,
including SF and PLFA, is to prove progress and preservation,
as first suggested by \citet{Wright-and-Felleisen-1994}.

\begin{theorem}[Progress] Given term $M$ and type $A$ such that
$\emptyset \vdash M : A$ then either $M$ is a value or
$M \longrightarrow N$ for some term $N$.
\end{theorem}

\begin{theorem}[Preservation] Given terms $M$ and $N$ and type $A$
such that $\emptyset \vdash M : A$ and $M \longrightarrow N$, then
$\emptyset \vdash N : A$.  \end{theorem}

A consequence is that when a term reduces to a value it retains
the same type.  Further, well-typed terms don't get stuck:
that is, unable to reduce further but not yet reduced to a value.
The formulation neatly accommodates the case of non-terminating
reductions that never reach a value.

One useful by-product of the formal specification of a programming
language may be a prototype implementation of that language.  For
instance, given a language specified by a reduction relation, such
as lambda calculus, the prototype might accept a term and apply reductions
to reduce it to a value.  Typically, one might go to some extra work to
create such a prototype.  For instance, SF introduces a \texttt{normalize}
tactic for this purpose.  Some formal methods frameworks, such as
Redex \citep{Felleisen-et-al-2009} and K \citep{Rosu-Serbanuta-2010},
advertise as one of their advantages that they can generate
a prototype from descriptions of the reduction rules.

I was therefore surprised to realise that any constructive proof of
progress and preservation \emph{automatically} gives rise to such a
prototype.  The input is a term together with evidence the term is
well-typed.  (In the inherently-typed case, these are the same thing.)
Progress determines whether we are done, or should take another step;
preservation provides evidence that the new term is well-typed, so we
may iterate. In a language with guaranteed termination, we cannot
iterate forever, but there are a number of well-known techniques to
address that issue; see, e.g., \citet{Bove-and-Capretta-2001},
\citet{Capretta-2005}, or \citet{McBride-2015}.
We use the simplest, similar to McBride's \emph{petrol-driven} (or
\emph{step-indexed}) semantics: provide a maximum number of steps to
execute; if that number proves insufficient, the evaluator returns the
term it reached, and one can resume execution by providing a new
number.

Such an evaluator from PLFA is shown in Figure~\ref{fig:plfa-eval},
where (inspired by cryptocurrencies) the number of steps
to execute is referred to as \emph{gas}. All of the example reduction
sequences in PLFA were computed by the evaluator and then edited to
improve readability; in addition, the text includes examples of
running the evaluator with its unedited output.

It is immediately obvious that progress and preservation make it
trivial to construct a prototype evaluator, and yet I cannot find such
an observation in the literature nor mentioned in an introductory
text.  It does not appear in SF, nor in \citet{Harper-2016}.  A plea
to the Agda mailing list failed to turn up any prior mentions.
The closest related observation I have seen in the published
literature is that evaluators can be extracted from proofs of
normalisation \citep{Berger-1993,Dagand-and-Scherer-2015}.

(Late addition: My plea to the Agda list eventually bore fruit.  Oleg
Kiselyov directed me to unpublished remarks on his web page where he
uses the name \texttt{eval} for a proof of progress and notes ``the
very proof of type soundness can be used to evaluate sample
expressions'' \citep{Kiselyov-2009}.)

\section{Inherent typing is golden}

\begin{figure}[p]
  \includegraphics[width=\textwidth]{figures/raw.png}
  \caption{Raw approach in PLFA}
  \label{fig:raw}
\end{figure}

\begin{figure}[t]
  \includegraphics[width=\textwidth]{figures/inherent.png}
  \caption{Inherent approach in PLFA}
  \label{fig:inherent}
\end{figure}

The second part of PLFA first discusses two different approaches to
modelling simply-typed lambda calculus.  It first presents raw
terms with named variables and a separate typing relation and
then shifts to inherently-typed terms with de Bruijn indices.
Before writing the text, I had thought the two approaches
complementary, with no clear winner.  Now I am convinced that the
inherently-typed approach is superior.

Figure~\ref{fig:raw} presents the raw approach.
It first defines $\texttt{Id}$, $\texttt{Term}$,
$\texttt{Type}$, and $\texttt{Context}$, the abstract syntax
of identifiers, raw terms, types, and contexts.
It then defines two judgements,
$\GG\:{\ni}\:\ex\:{\typecolon}\:\AY$ and
$\GG\:{\vdash}\:\EM\:{\typecolon}\:\AY$,
which hold when under context $\GG$ the variable $\ex$
and the term $\EM$ have type $\AY$, respectively.

Figure~\ref{fig:inherent} presents the inherent approach.
It first defines $\texttt{Type}$ and $\texttt{Context}$, the abstract syntax
of types and contexts, of which the first is as before and the second is
as before with identifiers dropped.  In place of the two judgements,
the types of variables and terms are indexed by a context and a type,
so that $\GG\:{\ni}\:\AY$ and $\GG\:{\vdash}\:\AY$ denote
variables and terms, respectively, that under context $\GG$ hae type $\AY$.
The indexed types closely resemble the previous judgements:
we now represent a variable or a term by the proof that it is well-typed.
In particular, the proof that a variable is well-typed in the raw approach
corresponds to a de Bruijn index in the inherent approach.

The raw approach requires more lines of code than
the inherent approach.  The separate definition of raw
terms is not needed in the inherent
approach; and one judgement in the raw approach needs to check that
$\ex \not\equiv \why$, while the corresponding judgement in the
inherent approach does not.  The difference becomes more pronounced
when including the code for substitution, reductions, and proofs of
progress and preservation.  In particular, where the raw approach
requires one first define substitution and reduction and then prove
they preserve types, the inherent approach establishes substitution at
the same time it defines substitution and reduction.

Stripping
out examples and any proofs that appear in one but not the other (but
could have appeared in both), the full development in PLFA for the raw approach takes 451
lines (216 lines of definitions and 235 lines for the proofs) and the
development for the inherent approach takes 275 lines (with
definitions and proofs interleaved).  We have 451 / 235 = 1.64,
close to the golden ratio.

The inherent approach also has more expressive power.  The raw
approach is restricted to substitution of one variable by a closed
term, while the inherent approach supports simultaneous substitution
of all variables by open terms, using a pleasing formulation due to
\citet{McBride-2005}, inspired by \citet{Goguen-and-McKinna-1997} and
\citet{Altenkirch-and-Reus-1999} and described in
\citet{Allais-et-al-2017}. In fact, I did manage to write a variant of
the raw approach with simultaneous open substitution along the lines
of McBride, but the result was too complex for use in an introductory
text, requiring 695 lines of code---more than the total for the other
two approaches combined.

The text develops both approaches because the raw approach is more
familiar, and because placing the inherent approach first would
lead to a steep learning curve.  By presenting the more long-winded
but less powerful approach first, students can see for themselves the
advantages of de Bruijn indices and inherent types.

There are actually four possible designs, as the choice of named
variables vs de Bruijn indices, and the choice of raw vs
inherently-typed terms may be made independently.  There are synergies
beween the two.  Manipulation of de Bruijn indices can be notoriously
error-prone without inherent-typing to give assurance of correctness.
In inherent typing with named variables, simultaneous substitution by
open terms remains difficult.

The benefits of the inherent approach
are well known to some. The technique was introduced by
\citet{Altenkirch-and-Reus-1999}, and widely used elsewhere,
notably by \citet{Chapman-2009} and \citet{Allais-et-al-2017}.
I'm grateful to David Darais for bringing it to my attention.

\section{Conclusion}

I look forward to experience teaching from the new text,
and encourage others to use it too.  Please comment!

\paragraph{Acknowledgements}

A special thank you to my coauthor, Wen Kokke.  For inventing ideas on
which PLFA is based, and for hand-holding, many thanks to Conor
McBride, James McKinna, Ulf Norell, and Andreas Abel.  For showing me
how much more compact it is to avoid raw terms, thanks to David
Darais.  For inspiring my work by writing SF, thanks to Benjamin
Pierce and his coauthors.  For comments on a draft of this paper, an
extra thank you to James McKinna, Ulf Norell, Andreas Abel, and
Benjamin Pierce. This research was supported by EPSRC Programme Grant
EP/K034413/1.

\bibliographystyle{plainnat}
%\bibliographystyle{splncsnat.bst}
\bibliography{PLFA}

\end{document}


\section{Introduction}

\begin{frame}{Lecture 2 -- Outline}
  In the first lecture, we covered the basic concepts of proofs. This lecture, we we continue this study and introduce a very important proof method: {\bf Induction}.
  \bigskip

  \begin{itemize}
    \item {\bf Section 1:} Sets and Relations;
    \item {\bf Section 2:} Proof by Induction;
    \item {\bf Section 3:} State Machines;
  \end{itemize}

  \bigskip
  \begin{block}{}
  This lecture covers the textbook's chapters 4, 5 and 6 (and a little of 7).
  \end{block}
\end{frame}


\documentclass[12pt]{article}
\usepackage{titlesec}
\usepackage{hyperref}
\usepackage{graphicx}
\usepackage{booktabs}
\titlelabel{\thetitle.\quad}
\title{Applied Numerical Computing\\ for Scientists and Engineers}
\date{In-Class Problem: \LaTeX{} Basics}
\author{Dr. Ford Versypt}
\begin{document}

\maketitle

Use the built-in article class in \LaTeX{} and the use the booktabs package as in the tutorial with Overleaf as the editor to create a document that has a table and a cross-reference to a table.

\section{Part 1}
\begin{enumerate}
\item Write the \LaTeX{} code to reproduce Table \ref{table:first}. Note that the parameters use the inline math notation surrounded by pairs of \$'s and that superscripts or subscripts require inline math notation.
\item Write the \LaTeX{} code to cross reference Table \ref{table:first}.
\end{enumerate}

\begin{table}[htbp]
\begin{center}
\caption{Parameter values for two cases}
\begin{tabular}{llll}\toprule
Parameter & Units & Case 1 & Case 2 \\ \midrule
$a$ & h & 1.0 & 1.0 \\
$b_1$ & h & 1.0  & 1.0 \\
$b_2$ & ng h ml$^{-1}$ & 1.0 & 1.0 \\
\bottomrule
\end{tabular}
\label{table:first}
\end{center}
\end{table}

\section{Part 2}
\begin{enumerate}
\item Write the \LaTeX{} code to reproduce Table \ref{table:multicolumn}. You are welcome to search the internet for ideas, packages, or code snippets for formatting multicolumn tables.
\item Write the \LaTeX{} code to cross reference Table \ref{table:multicolumn}.
\end{enumerate}

\begin{table}[htbp]
\begin{center}
\caption{Parameter values for two cases with some values reported and others calculated}
\begin{tabular}{llll}\toprule
Parameter & Units & Case 1 & Case 2 \\ \midrule
\multicolumn{4}{c}{Reported in the literature}\\ \midrule
$a$ & h & 1.0 & 1.0 \\
$b_1$ & h & 1.0  & 1.0 \\
$b_2$ & ng h ml$^{-1}$ & 1.0 & 1.0 \\ \midrule
\multicolumn{4}{c}{Calculated from literature values}\\ \midrule
$c$ & h$^{-1}$ & 2.0 & 2.0  \\
$d$ & h$^{-1}$ & 2.0 & 2.0 \\
\bottomrule
\end{tabular}
\label{table:multicolumn}
\end{center}
\end{table}

\end{document}

CHEclassFa20/In Class Problem Solutions/LaTeX/ICP LaTeX Basics.tex


\chapter*{Abstract}
\addcontentsline{toc}{chapter}{Abstract}
\thispagestyle{plain}
Correctly estimating the volume of glaciers is essential to accurately predict future in sea level change and water availability. To compute the volume of a glacier, an estimate of its thickness distribution is needed. Ice thickness measurements are sparse and spatially incomplete. Numerical and statistical modeling therefore is necessary to estimate the full ice thickness distribution. Recently, the Ice Thickness Models Intercomparison eXperiment (ITMIX) evaluated the accuracy of 17 ice thickness estimation models. 15 of those models rely on glacier physics and numerical modeling in order to estimate the ice thickness distribution. Because data was so sparse, statistical models trained with ice thickness observations have not been used extensively by the glaciological community. The recent publication of the Glacier Thickness Database (GlaThiDa), a data-set aiming at collecting all glacier ice thickness observations worldwide, and the advancement in the field of machine learning, opened up to the possibility of a glacier ice thickness estimation model based on machine learning algorithms.

In this thesis, three different machine learning algorithms have been trained using ice thickness observations from the GlaThiDa for glaciers in the Alps. Linear regression, random forest regression and support vector regression have been used to create models to estimate glaciers ice thickness from surface data such as: altitude above sea level, distance from the glacier border, slope angle and mass balance. Parts of the ice thickness observations have been used to train the models and other parts to test their accuracy. With this cross-validation method, 20 different samples have been created to train and test the models. The highest R2 coefficient has been registered by the support vector machine, with an average R2 = 0.55 across the different samples. The algorithms tuned with a cross validation process have then been trained using all the available ice thickness observations for glaciers in the alps. With this training method, the highest R2 = 0.57 has been registered for the random forest regression, which could however be subject to bias towards the data used for training it.

The three models trained using all the available observations, have then been used to estimate the total volume of glaciers in the alps. The results have been compared to the findings from Farinotti et al. (2019), who estimated the volume of glaciers globally using five established physically based models. Comparing the ice volume for glaciers in the Alps, the linear regression model predicted a total volume 9.8\% larger than the reference estimate. The random forest regression a volume 22.1\% lower and the support vector machine a volume 25.1\% lower. The last two models have been found unable to correctly estimate ice thicknesses for large glaciers in the Alps. The results indicate that the machine learning algorithms trained in this thesis are not fit to estimate large ice thickness values for the alpine region. Further work could be done by training the models with different input data such as climate data and a mass balance taking into account the catchment basins of the glacier. Training the models with data from other regions could also lead to better performances. The availability of ice thickness observations covering a wider spectrum of glaciers, and particularly large glaciers, could result in the biggest improvement in the models accuracy, and is a point to take into account when organizing future campaigns to collect ice thickness measurements.


\chapter{Introduction}
\label{chapter:introduction}

\setlength{\epigraphwidth}{0.43\textwidth}
\epigraph{
Out of S. Okubo's effect\\
At high temperature\\
A fur coat is sewed for the Universe\\
Shaped for its crooked figure
}{A. D. Sakharov \cite{Sakharov1991}}

We interact with matter every day. Even you, the reader, are probably made out of matter! However, antimatter is so rare that it is considered to cost a few hundred millions Swiss francs per gram \cite{DeRujula2001}, making it the most expensive substance in the universe. Why does such a stunning difference in the abundance exist?

First step to solving this problem is to define what are the required conditions that would allow the disbalance to evolve. Those conditions \cite{Dubbers2011} were described \cite{Sakharov1991} by Andrei Sakharov in 1967:

\begin{itemize}
	\item Violation of baryon number conservation.
	\item \textit{C}- and \textit{CP}-symmetry violation.
	\item Processes take place far from thermal equilibrium.
\end{itemize}

Let us take a look at the \textit{CP}-symmetry and prove that a non-zero electric dipole moment of an elementary particle would indeed break it. We would select neutron as a particle of choice.

The neutron in the ground state has spin of $I = 1/2$ and can be characterised completely by a single quantum number of a spin projection $m_I = \pm 1/2$. We can write down a Hamiltonian \cite{Golub1994} of this neutron in external electric and magnetic fields $\vec{E}$ and $\vec{B}$:

\begin{equation}
	\mathcal{H} = -\frac{d_n \vec{I} \cdot \vec{E} + \mu_n \vec{I} \cdot \vec{B}}{I}
	\label{eq:neutron_hamiltonian}
\end{equation}

with $d_n$ and $\mu_n$ being the electric and magnetic moments of the neutron \cite{Golub1972}.

It does not make sense to discuss the potential violation of the symmetries before we define them.  Fundamental symmetries are blended into the fabric of our Universe by providing sufficient conditions \cite{Noether1918} for the conservation laws. In our analysis we would consider three symmetries of the Standard Model: \textit{C}, \textit{P} and \textit{T}.

\begin{itemize}
	\item (C)harge –-- replaces every particle with its antiparticle: $q \rightarrow -q$.
	\item (P)arity --- inverts the physical space: $\vec{r} \rightarrow -\vec{r}$.
	\item (T)ime --- turns the time back: $t \rightarrow -t$.
\end{itemize}

How would the \textit{P} and \textit{T} inversions affect \cite{Dubbers2011} the Hamiltonian from Eq. \ref{eq:neutron_hamiltonian}?

Parity transformation only act on a polar vector of the electric field: $\vec{E} \rightarrow -\vec{E}$, both $\vec{B}$ and $\vec{I}$ are conserved. This brings us to
\begin{equation}
	\textit{P}\mathcal{H} = -\frac{d_n \vec{I} \cdot \left(-\vec{E}\right) + \mu_n \vec{I} \cdot \vec{B}}{I} \neq \mathcal{H}.
	\label{eq:neutron_hamiltonian_P}
\end{equation}

Time reversal would only affect the axial vectors $\vec{B}$ and $\vec{I}$: $\vec{B} \rightarrow -\vec{B},\ \vec{I} \rightarrow -\vec{I}$, the field $\vec{E}$ is left as is:
\begin{equation}
	\textit{T}\mathcal{H} = -\frac{d_n \left(-\vec{I}\right) \cdot \vec{E} + \mu_n \left(-\vec{I}\right) \cdot \left( -\vec{B} \right)}{I} \neq \mathcal{H}.
	\label{eq:neutron_hamiltonian_T}
\end{equation}

Assuming that the \textit{CPT} invariance \cite{Schwinger1951} is conserved we derive the violation of a \textit{CP}-symmetry which provides us the motivation to measure the EDM of a neutron.

\textit{"Wait a minute,"} could have said an attentive reader at this point. "Does not Standard Model predict a non-zero EDM of the neutron already? I am still not convinced why would you want to conduct this experiment."

And an attentive reader would have had a completely fair point! Indeed, Standard Model predicts \cite{Khriplovich1982} the following:
\begin{equation}
	d_n \approx 2 \cdot 10^{-32}\ e \cdot \text{cm}.
\end{equation}

However, we would still like to measure $d_n$ for the reasons listed below:
\begin{itemize}
	\item The only way to prove the theory is to check it experimentally. So far no one has measured $d_n$ with a precision close to the predicted value.
	\item The result that can be achieved by using Standard Model is too weak to explain the baryogenesis \cite{Dubbers2011}, yet baryogenesis has clearly happened.
	\item If we go beyond Standard Model to find a mechanism through which the Universe as we know it could have been formed, we need to cut off theories that do not agree with experimental data. This is something that this experiment does perfectly: on the Fig. \ref{fig:edm_history} one can see all theoretical models that the measurement of the neutron EDM has ruled out, allowing the scientists to focus on more prominent leads.
\end{itemize}

\begin{figure}[h]
	\includegraphics[width=\textwidth]{img/history_of_nedm_measurements}
	\caption{Measurement history of the neutron EDM, graph taken from \cite{Golub1994}.}
	\label{fig:edm_history}
\end{figure}

Hopefully these reasons would convince even the most demanding reader in the need to conduct the n2EDM experiment. But what is \textit{n2EDM} exactly? We will try to explain that in the next chapter.


\title{How to make a Linked List in C++}
\author{
        Jake Billings \\
        Department of Computer Science\\
        Rensselaer Polytechnic Institute\\
        Troy, NY
}
\date{October 1, 2018}

\documentclass[12pt]{article}

\usepackage{hyperref}
\usepackage{listings}
\usepackage{graphicx}
\graphicspath{ {./} }

\begin{document}
\maketitle

\begin{abstract}
	This article contains a brief description of and a tutorial for the creation of the linked list data structure. It is intended for fellow computer science students in a data structures course.
\end{abstract}

\newpage

\section{What is a Linked List?}
If you're reading this, there's a good chance that you're a computer science student just like me. In that case, you probably have a good idea of what a Linked List is, so I won't spend too much time explaining it. Here's a brief refresher:

According to \href{https://www.cs.cmu.edu/~adamchik/15-121/lectures/Linked Lists/linked lists.html}{this page from Carnegie Mellon Unversity} (CMU),

\begin{quote}
	A linked list is a linear data structure where each element is a separate object. Each element (we will call it a node) of a list is comprising of two items - the data and a reference to the next node. The last node has a reference to null. The entry point into a linked list is called the head of the list. It should be noted that head is not a separate node, but the reference to the first node. If the list is empty then the head is a null reference.
\end{quote}

\includegraphics[width=\textwidth]{linked_list_diagram}

\paragraph{Why?}
	We use linked lists for their relatively quick insertion times. You'll see later. Inserting into a Linked List requires only a single O(1) operation. Linked Lists are not well-suited to applications where the end of the list is read frequently. Since lookup times near the end of the list are O(n) where n is the number of elements in the list, these lookups are inefficient compared to other data structures.

\newpage

\section{Implementation}

The following code listing will highlight the important pieces of a C++ linked list implementation:

\subsection{Node}

\includegraphics{node_diagram}

\begin{lstlisting}[language = C++]
template<typename T>

class Node {
private:
/**
* the actual data that this node holds
*/
T data;

/**
* a pointer to the next node in the linked list
*  this will be nullptr if this is the last node in the list
*/
Node *next;
public:
//getters, setters, and stream operators omitted for brevity
};
\end{lstlisting}

\newpage

\subsection{LinkedList Fields}

\begin{lstlisting}[language = C++]
template<typename T>
class LinkedList {
private:
/**
* head
*
* Node<T> pointer
*
* this is a pointer to the first node of the linked list
*/
Node<T> *head;
\end{lstlisting}

\paragraph{LinkedList}
In this example, the LinkedList class has one private field, which is the head pointer. The list manipulation functions in the LinkedList class all use this pointer to begin data access. No other references to elements of the list are stored.
\newpage

\subsection{Insert at Front}

\begin{lstlisting}[language = C++]
/**
* push_front()
*
* adds an element to the front of this linked list by wrapping it
* in a new node object, placing it on the heap,
*  and updating the head pointer
*
* @param  value the value to place into the LinkedList
* (type T from template)
*/
void push_front(T value) {
	//Allocate a new node on the heap that points
	//to the old head node
	Node<T> *n = new Node<T>(value, this->head);

	//Set head to point at the new node on the heap
	this->head = n;
}
\end{lstlisting}

\paragraph{push\_front()}
Inserting at the front of a LinkedList is easy. Just create a new node that points to the head pointer. Then, point the head pointer at the new node. This operation has complexity \textbf{O(1)}.

\newpage

\subsection{Insert at Back}

\begin{lstlisting}[language = C++]
/**
* push_back()
*
* adds an element to the back of this LinkedList by iterating
* through all the elements, then creating a new node,
*  placing it on the heap, then setting the next pointer of
* the last node
*/
void push_back(T value) {
//If the list is already empty, use the simpler algorithm
//from push_front to insert the
// value then return
if (this->head == nullptr) {
return this->push_front(value);
}

//Now, we can assume the head pointer is a node (not nullptr).
// We iterate until we find the last node
Node<T> *cur = this->head;
while (cur->getNext() != nullptr) {
cur = cur->getNext();
}

//Allocate a new node on the heap that points to nullptr
//(since it's the last element of the list)
Node<T> *n = new Node<T>(value, nullptr);

//Update the ptr of the node that used to be the last
//node to point at the new node
cur->setNext(n);
}

\end{lstlisting}

\paragraph{push\_back()}
Inserting at the back of a LinkedList is hard. You must follow every single pointer until you reach the end of the list. Then, you can point the final pointer at your new node. This operation has complexity \textbf{O(n)}.

\newpage

\subsection{Full Implementation}
Only a few functions are documented in this tutorial. I have a complete implementation available on GitHub. It contains operations for adding and removing elements at any position in the list. It also manages the allocation and freeing of memory in constructors and destructors. This implementation has been verified using automated testing.\\

\href{https://github.com/jake-billings/edu-csci2312/tree/master/hw06}{https://github.com/jake-billings/edu-csci2312/tree/master/hw06}

\newpage

\section{Additional Links}

\noindent
Other Projects:
\href{https://github.com/jake-billings/}{https://github.com/jake-billings/}\\

\noindent
Data Structures: \href{https://github.com/jake-billings/edu-csci2421}{https://github.com/jake-billings/edu-csci2421}\\

\noindent
Medium: \href{https://github.com/jake-billings/edu-csci2421}{https://github.com/jake-billings/edu-csci2421}

\end{document}


%-- summary: Template for lecture notes with a lot of useful snippets.

\documentclass{article}

% Title for the `compact-header` snippet
\newcommand\HeaderTitle{\textbf{CS 124~~~Lecture Notes} by Timur Kuzhagaliyev}

%-- Rammy start ----------------
\input{../snippets/symbols.tex} %-- snippet: symbols
\input{../snippets/compact-header.tex} %-- snippet: compact-header
\input{../snippets/urls.tex} %-- snippet: urls
\input{../snippets/figures.tex} %-- snippet: figures
\input{../snippets/code.tex} %-- snippet: code
\input{../snippets/misc.tex} %-- snippet: misc
%-- Rammy end ------------------

% Don't wrap long matrices
\setcounter{MaxMatrixCols}{20}

\begin{document}

%-- example usage start
\begin{center}
{\LARGE CS 124~~~Operating Systems}
\vspace{10px}\\
\end{center}

\section{Lecture notes template}
This template was meant to be used for lecture notes. It has a lot of useful
shorthand commands, packages and settings defined to make lecture note writing
an effortless process. Refer to section \ref{sec:features} for some examples.

\section{Features}\label{sec:features}
Most of the features of this template come from different TeX snippets defined
in the \code{latex-common} Rammy module. Check
\href{th://github.com/TimboKZ/latex-common}{its GitHub page} for the full list
of a available snippets.

\subsection{Snippet: \texttt{compact-header}}
The small header you see at the top of this page is a part of this template.
You can customise its content by (re)defining the \code{\textbackslash
HeaderTitle} command.

This snippet also defines the page margins.

\subsection{Snippet: \texttt{symbols}}

This template includes a lot of useful Math symbols. Here's a quick preview:

\[
\begin{array}{|c|c|c|}%
    \hline
    \R^n \x \R^m & \qquad \M_{r \x k} \qquad & \C, \Z, \Q \\
    \hline
    f: \R^n \ra \R & \qquad \frac{df}{dt}\evalat_{t=4} \qquad & A \tens B \\
    \hline
    \inr{v, u} & \qquad \inner \qquad & \norm{A} \\
    \hline
    \E \left[ x \right] & U \indep V & \Pr (x \given y) \\
    \hline
\end{array}
\]

See the source code of the \code{symbols} snippet for more info.

\subsection{Snippet: \texttt{code}}

As the name implies, this snippet adds a bunch of code-related features.
Code snippets should be inserted using the \code{lstlisting} environment:

\begin{lstlisting}[language=javascript]
/**
  * This code snippet was taken from Rammy CLI tests.
  */
describe('rammy init', () => {
    it('should succeed in an empty directory', () => {
        TU.removeFixture(configName);
        assertRammyCommand('init', 0);
        assert.isTrue(TU.hasFixture(configName), 'Config file was not created!');
    });
    it('should fail when a project has already been initialised', () => {
        assertRammyCommand('init', 1);
    });
});
\end{lstlisting}

Additionally, the \code{\textbackslash code} command can be used to insert
inline code snippets.

\subsection{Other snippets and features}

This template has coloured links:
\url{https://github.com/TimboKZ/latex-common}. It also supports long matrices:

\[
Z =
\begin{bmatrix}
    q_{sum1} & q_{sum2} & q_{sum3} & 0 & 0 & 0 & 0 & 0 & 0 & m & 0 & 0 \\
    0 & 0 & 0 & q_{sum1} & q_{sum2} & q_{sum3} & 0 & 0 & 0 & 0 & m & 0 \\
    0 & 0 & 0 & 0 & 0 & 0 & q_{sum1} & q_{sum2} & q_{sum3} & 0 & 0 & m \\
    x_{11} & x_{21} & x_{31} & 0 & 0 & 0 & 0 & 0 & 0 & q_{sum1} & 0 & 0 \\
    x_{12} & x_{22} & x_{32} & 0 & 0 & 0 & 0 & 0 & 0 & q_{sum2} & 0 & 0 \\
    \hdotsfor{12} \\
    \hdotsfor{12} \\
    \hdotsfor{12} \\
    \hdotsfor{12} \\
    \hdotsfor{12} \\
    \hdotsfor{12} \\
    0 & 0 & 0 & 0 & 0 & 0 & x_{13} & x_{23} & x_{33} & 0 & 0 & q_{sum3} \\
\end{bmatrix}
\]

This template doesn't use standard \LaTeX fonts - it uses a sans-serif font for
the main text and Inconsolota as the monospace font. The packages needed for
common figure functionality are also included via the \code{figures} snippet.
%-- example usage end

\end{document}


\documentclass[a4paper, 11 pt, article, accentcolor=tud7b]{tudreport}

\usepackage[utf8]{inputenc}
\usepackage{amsmath}
\usepackage{placeins}

\title{CNuVS Exercise 5}
\author{Nils Rollshausen, Daniel Drodt}
\subtitle{Nils Rollshausen, Daniel Drodt}

\begin{document}
	\maketitle
	\section{IP Addressing}
	\subsection*{a) Checksum}
	  The checksum field in the IPv4 header is 16 bit long. Its value is calculated as the binary inverse of the sum of all 16 bit fields of the header (where the checksum is assumed to be zero). The addition is performed in the one's complement, meaning that a potential carry-out or 17th bit is added to the total sum.

	\subsection*{b) Class-full networks}
	In class-full IP addressing, there can be no more than 126 Class-A networks ($2^7 - 2$ or 7 bit without the all-one and all-zero cases).

	\subsection*{c) IP dissection}
	The IP address 51.101.193.69 is 00110011.01100101.11000001.01000101 in binary representation. As the first bit is zero, the network is a class-A network, the full network part is 51.0.0.0 or 00110011.0.0.0 in binary. The host part is everything after the 19th bit, so 0.0.1.69 or 0.0.00000001.01000101. This leaves the subnet part as the 9th to 19th bits - 0.101.192.0 and 0.01100101.11000000.0. \\
	The subnet mask is 255.255.192.0 or 11111111.11111111.11000000.00000000.

	\subsection*{d) Class-less vs. class-full}
	In class-full IP addressing, the networks and network sizes are statically determined and clustered into few different network types, resulting in many organizations having networks much larger than they actually need. In class-less IP addressing, the network and subnet size is flexible and can be chosen to fit a specific network topology.

	\section{Subnet Masks}

	\subsection*{a) Class and default subnet mask}
	The IP 80.74.0.0 belongs to a class A network, therefore the default netmask is 255.0.0.0.

	\subsection*{b) Alternate subnet mask}
	The administrator likely needs to address more than 510 nodes in a single subnet but wants to retain a maximum possible number of subnets. Thus a netmask of 255.255.255.0 would not allow enough nodes in a single subnet while a netmask of 255.255.0.0 would not provide the optimal number of possible subnets. With the given netmask, $2^{10} - 2 = 1022$ hosts can be addressed in a given subnet.

	\section{Variable Length Subnet Masks}

	\subsection*{a) Subnet mask}

	The subnet mask for the network is 255.252.0.0 or 11111111.11111100.00000000.00000000

	\subsection*{b) Usable host addresses}
	The subnet part takes 3 bit, leaving 18 bit for the host part. This means that the number of usable host addresses in each subnet is given by $2^{18} - 2 = 262.142$.

	\newpage

	\subsection*{c) Subnet addresses}

	\begin{table}[h]
	  \centering
	  \begin{tabular}{| c | l | l |}
	    \hline
	    Subnet & Subnet address & Broadcast address \\ \hline
	    A & 97.0.0.0/14 & 97.3.255.255 \\ \hline
	    B & 97.4.0.0/14 & 97.7.255.255 \\ \hline
	    C & 97.8.0.0/14 & 97.11.255.255 \\ \hline
	    D & 97.12.0.0/14 & 97.15.255.255 \\ \hline
	    E & 97.16.0.0/14 & 97.19.255.255 \\ \hline
	    F & 97.20.0.0/14 & 97.23.255.255 \\ \hline
	    G & 97.24.0.0/14 & 97.27.255.255 \\ \hline
	    H & 97.28.0.0/14 & 97.31.255.255 \\ \hline
	  \end{tabular}
	  \caption{Subnet addresses}
	\end{table}

	\section{Address Aggregation \& NAT}

	\subsection*{a) Aggregation}
	The IP addresses 8.42.192.0/22, 8.42.196.0/22, 8.42.200.0/22 and 8.42.204.0/22 can be aggregated into 8.42.192.0/20. This is possible because all addresses share the first 20 bit and, when combined, they cover all possible combinations for the 21st and 22nd bits.

	\subsection*{b) Multiple interfaces}
	The routing table will contain the entry 21.242.112.0/22 for interface two and the entries 21.242.0.0/18 and 21.242.112.0/20 for interface one. (Alternatively, the two entries may be combined to 21.242.0.0/17)

	\subsection*{c) NAT Motivation}
	The main reason for deploying NAT on a large scale is the increasing scarcity of available IPv4 addresses. NAT allows a single router with one IP address to represent many individual hosts, which do not need globally unique IP addresses anymore.

	\subsection*{d) IPv6 NAT}
	IPv6 provides an abundant amount of addresses, which is why NAT as a measure to reduce address consumption is generally speaking not necessary.

\end{document}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%2345678901234567890123456789012345678901234567890123456789012345678901234567890
%        1         2         3         4         5         6         7         8

\documentclass[letterpaper, 10 pt, conference]{ieeeconf}  % Comment this line out if you need a4paper

%\documentclass[a4paper, 10pt, conference]{ieeeconf}      % Use this line for a4 paper

\IEEEoverridecommandlockouts                              % This command is only needed if
                                                          % you want to use the \thanks command

\overrideIEEEmargins                                      % Needed to meet printer requirements.

%In case you encounter the following error:
%Error 1010 The PDF file may be corrupt (unable to open PDF file) OR
%Error 1000 An error occurred while parsing a contents stream. Unable to analyze the PDF file.
%This is a known problem with pdfLaTeX conversion filter. The file cannot be opened with acrobat reader
%Please use one of the alternatives below to circumvent this error by uncommenting one or the other
%\pdfobjcompresslevel=0
%\pdfminorversion=4

% See the \addtolength command later in the file to balance the column lengths
% on the last page of the document

% The following packages can be found on http:\\www.ctan.org
%\usepackage{graphics} % for pdf, bitmapped graphics files
%\usepackage{epsfig} % for postscript graphics files
%\usepackage{mathptmx} % assumes new font selection scheme installed
%\usepackage{times} % assumes new font selection scheme installed
%\usepackage{amsmath} % assumes amsmath package installed
%\usepackage{amssymb}  % assumes amsmath package installed
\usepackage{graphicx}
\usepackage[caption=false]{subfig}
\usepackage{hyperref}

\title{\LARGE \bf
Report to head pose estimation using CNN
}

\author{Songlin Piao$^{1}$
\thanks{$^{1}$Songlin Piao -
        {\tt\small piaosonglin1985@hotmail.com}}%
}

\begin{document}

\maketitle
\thispagestyle{empty}
\pagestyle{empty}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{abstract}

This is a technical report about head pose estimation. The baseline paper is from N. Ruiz et al.~\cite{Ruiz2017}. Authors use ResNet50~\cite{He2015} to build a CNN network for estimating head pose (roll, pitch and yaw) from 2D images. This report tried to describe all the possible solutions to improve this baseline method.

\end{abstract}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Topic1}

Authors build a so-called hopenet using ResNet50 as a backbone. They conducted the tests on the AFLW2000 dataset. The results are shown in the Table 1 in the paper ~\cite{Ruiz2017}. Through looking at the source code written by authors, it is found that authors used 66 bins in the range between -99$^\circ$ and 99$^\circ$.
Following solutions could improve the accuracy, but they are not yet proved due to the limited time and training resources.

\begin{itemize}
	\item change the 66 bins to 99 bins and 132 bins
	\item test with ResNet 101 and 152, but this may slow down the speed.
\end{itemize}

\section{Topic2}

In order to make the algorithm satisfy the real time requirement, MobileNet is recommended. I have conducted a test with MobileNet V2. Please have a look at the file train\_mobilenet2.py. The new network is trained with exactly same hyper parameters mentioned in the paper~\cite{Ruiz2017}. It is trained for 25 epochs using Adam optimization with a learning rate of $0.00001$. The training time takes approximately 10.5 hours with GTX 1050Ti Laptop GPU.

\begin{table}[h]
	\caption{Error Comparison between ResNet50 and MobileNet V2 on the AFLW2000 dataset.}
	\label{tb:table_error_compare}
	\begin{center}
		\begin{tabular}{|c|c|c|c|c|}
			\hline
			 & Yaw & Pitch & Roll & MAE \\
			\hline
			Multi-Loss ResNet50 ($\alpha = 1$) & 6.920 & 6.637 & 5.674 & 6.410 \\
			\hline
			Multi-Loss MobileNet-V2 ($\alpha = 1$) & 10.9175 & 7.1786 & 6.6814 &  8.259 \\
			\hline
		\end{tabular}
	\end{center}
\end{table}

Table~\ref{tb:table_error_compare} shows error comparison of ResNet50 and MobileNet V2 on the AFLW2000 dataset. There is slight performance decrease in the case of MobileNet V2. As an opposite, MobileNet V2 has a faster inference speed and very small model size compared to ResNet50 as shown in Table~\ref{tb:table_compare2}.

\begin{table}[h]
	\caption{Speed and Model Size Comparison between ResNet50 and MobileNet V2.}
	\label{tb:table_compare2}
	\begin{center}
		\begin{tabular}{|c|c|c|}
			\hline
			& inference time & model size \\
			\hline
			Multi-Loss ResNet50 ($\alpha = 1$) & 5.5845ms & 95.9Mb \\
			\hline
			Multi-Loss MobileNet-V2 ($\alpha = 1$) & 4.6118ms & 10.1Mb \\
			\hline
		\end{tabular}
	\end{center}
\end{table}

\begin{figure}[ht]
	\centering
	\subfloat[]{\includegraphics[width=0.48\linewidth, height=3.75cm]{mobile1.jpg}} \hspace*{0.5cm}
	\subfloat[]{\includegraphics[width=0.48\linewidth, height=3.75cm]{hopenet1.jpg}} \\
	\subfloat[]{\includegraphics[width=0.48\linewidth, height=3.75cm]{mobile2.jpg}} \hspace*{0.5cm}
	\subfloat[]{\includegraphics[width=0.48\linewidth, height=3.75cm]{hopenet2.jpg}} \\
	\subfloat[]{\includegraphics[width=0.48\linewidth, height=3.75cm]{mobile3.jpg}} \hspace*{0.5cm}
	\subfloat[]{\includegraphics[width=0.48\linewidth, height=3.75cm]{hopenet3.jpg}} \\
	\caption{The left column are the results from MobileNet V2 and the right column are the results from Hopenet.}
	\label{fig:result_images}
\end{figure}

Fig.~\ref{fig:result_images} shows the visualization of the head pose estimation from MobileNet V2 and Hopenet. Although MobileNet V2 shows higher error in the Table 1, but
it seems in the first two images, the results from MobileNet V2 make more sense than the results from Hopenet. This needs to be further investigated.

\section{Further Improvements}

So far, the input size 224x224 is used for training and testing. It is necessary to test with smaller input sizes such as 168x168 or 112x112.
If the test results are not so bad, this would increase inference speed tremendously.

\section{Newly Added Source Codes}
\begin{itemize}
	\item extract\_valid\_files.py is used for extracting valid samples so that all roll, pitch and yaw are between -99$^\circ$ and 99$^\circ$
	\item mobilenetv2.py is the implementation of MobileNet V2.
	\item train\_mobilenet2.py is the training script using MobileNet V2.
	\item test\_mobilenet2.py is the evaluation script using MobileNet V2.
	\item demo\_mobilenet2\_webcam.py is the demo program to estimate head pose from Webcam using MobileNet V2.
	\item the implementation of MobileNet V2 based model is added inside the file hopenet.py.
	\item MobileNet V1 is also implemented but not used yet.
\end{itemize}

In order to initialize the weights of MobileNet V2, the model mobilenetv2\_1.0-0c6065bc.pth from \url{https://github.com/d-li14/mobilenetv2.pytorch} is used.

{\small
	\bibliographystyle{IEEEtran}
	\bibliography{library}
}

\end{document}


\section {Reaching Definitions}
\setlength{\parindent}{0pt}
(Prepared by Sameer V. Pande)

\vspace{0.3cm}

Reaching definitions is a more-detailed dataflow analysis, which contains the "possible" definitions a variable can take at a program point, unlike available-expression analysis, which indicates the value that a variable definitely takes.
This is more fine-grained because it doesn't declare variable values as $\bot$ when a variable can potentially have more than one value (depending on the path taken to reach the point), unlike available-expression analysis.
\newline
\includegraphics[scale=0.3]{images/90_1.png}

Consider the example above, and assume that program usually spends most of its execution time in the loop. In the loop, the variable "b" can have two values "1"/"y+z". If we use reaching-definitions analysis we can know that only two values of "b" are possible (one of which is a constant) and we can \textbf{specialize} the code (as seen in right-figure), by replicating the branch and specializing one of the branch on a constant value of b.

\subsection{Gen/Kill Sets and Meet for Reaching Definitions}
It is a forward dataflow analysis. Gen(S) of a statment S, contains all the new definitions generated by the S. And kill contains all definitions killed.
Hence for the example "S:x=y+z", Gen(S) = \{(x,y+z)\} and Kill(S) = \{(x,*)\}.
\newline
In reaching definitions the \textbf{meet operator is union}. Meet is union operator because we want the definitions which can reach the program point via \textbf{any} path.

\subsection{Reaching Definitions vs Available Expressions}
\includegraphics[scale=0.3]{images/90_2.png}
It is important to note that "Reaching-Defintions" is analysis involving definitions and "Available-Expressions" involves expressions.
From above figure, we can see that Gen() is very similar for both. But there are important differences in the following
\begin{itemize}
    \item Kill Set: In addition to (x,*), available-expressions also kills (*, ...x...) i.e. all variables with values dependent on previous value of x. This is not present in reaching-defintions since we are only worried about "definitions", we don't have to deal with this case (where x also appears in rhs).
    \item Meet Operator: The meet operator of reaching definitions is \textbf{union} because we want to consider \textbf{any} defintion of a varialbe that can reach at current program point \textbf{through any path}.
    Whereas available-expressions requires the same expression to reach the current program point through \textbf{all possible paths}. Hence \textbf{intersection} is suitable for available expressions.
\end{itemize}


 \chapter{Introduction}

\section{Math 597:  Deep Neural Networks}

\subsection*{Course info}
\begin{itemize}
\item Instructor:  Professor Jinchao Xu, 314 McAllister Building, {\color{blue}\tt xu@math.psu.edu }, {\color{blue}\tt http://www.math.psu.edu/xu/}
\item Time: Tuesday and Thursday 12:05pm-1:20pm, 114 McAllister Building
\item Office hours: Tuesday and Thursday 3:00pm-4:00pm
\item PREREQUISITE:
A good knowledge of multi-variable calculus, linear
algebra and basic numerical analysis

\item REQUIREMENT: $\quad$

  \begin{itemize}
  \item Homework and programming assignments  (60\%)
\item Take-Home Midterm (20\%) Take-Home Final (20\%)
  \end{itemize}
\item REFERENCES: PDF files of detailed lectures notes will be available to
the  class
\end{itemize}

\subsection*{Topics}
\begin{itemize}
\item Elements of probability and statistics
\item Basic theory of machine learning
\item Basic structure of deep neural networks
\item Approximation properties of DNN
\item Convolutional neural networks
\item Recurrent neural networks
\item Generative Adversarial Networks
\item Stochastic gradient descent methods
\item DNN and finite element methods
\item Multigrid methods
\item MgNet
\item Python
\item MNIST
\item TensorFlow, PyTorch
\end{itemize}

\section{AI era}
\subsection{Four major methods of scientific research}
\begin{figure}[H]
\centering
\subfigure{
\begin{minipage}[b]{0.46\textwidth}
\includegraphics[width=\textwidth]{Experimental} \\
\includegraphics[width=\textwidth]{Computational}
\end{minipage}
}
\subfigure{
\begin{minipage}[b]{0.45\textwidth}
\includegraphics[width=\textwidth]{Theoretical} \\
\includegraphics[width=\textwidth]{Data}
\end{minipage}
}
\end{figure}

\subsection{The era of the artificial intelligence}
\begin{figure}[H]
\centering
\includegraphics[width=.9\linewidth]{figures/aiera}
\end{figure}

\subsection{Example: different approaches to language learning}
\begin{itemize}
	\item Non-Native speakers (more a theoretical approach )
	\begin{itemize}
	\item Rules of pronunciation,  syntax, ...
	\end{itemize}
    \item Native speakers (more a data approach )
	\begin{itemize}
	\item Imitating ...
	\end{itemize}
Which one is more scientific or more effective?
\end{itemize}

\section{Classification problem }
\subsection{A basic AI problem: classification}
\begin{itemize}
	\item Can a machine (function) tell the difference ?
\end{itemize}
\begin{figure}
\centering
\includegraphics[width=.7\textwidth]{figures/cat-dog-1.png}
\end{figure}

\subsection{Supervised learning $\leftrightarrow$ Function interpolation}
\begin{itemize}
\item Each image = a big vector of pixel values
\begin{itemize}
	\item $n=1280\times720\times3$ (width$\times$ height $\times$ RGB channel) $\approx$ 3M.
\end{itemize}

\item 3 different sets of points in $\mathbb{R}^n$, are they separable?
\begin{figure}
\centering
		\includegraphics[width=.4\textwidth]{figures/cat-dog-2.png}   \quad \quad  \quad \quad
		\includegraphics[width=.4\textwidth]{figures/cat-dog-3.png}
\end{figure}
\item Mathematical problem: Find $f(\cdot; \Theta): \mathbb{R}^n \to \mathbb{R}^3$ such that:
$$
f(\includegraphics[width=.07\textwidth]{figures/cat.png}; \Theta)
\approx \begin{pmatrix}
1\\ 0 \\ 0
\end{pmatrix}
\quad
f(\includegraphics[width=.07\textwidth]{figures/dog.png}; \Theta)
\approx \begin{pmatrix}
0\\ 1 \\ 0
\end{pmatrix}
\quad
f(\includegraphics[width=.07\textwidth]{figures/rabbit.png};
    \Theta) \approx
\begin{pmatrix}
0\\ 0 \\ 1
\end{pmatrix}
$$
\end{itemize}

\subsection{One core problem of AI: clustering}
One simple example
\begin{itemize}
	\item A collection of points $\mathbb{R}^{N}$ is separated into several classes somehow ...
    \item The object is to construct a function y=f(x). The input x of the function is the coordinated of the points in the space and the output y is the cluster the point belongs to.
\begin{figure}[H]
\centering
\includegraphics[width=.45\textwidth]{figures/dots}
\end{figure}
\end{itemize}

\section{Recent applications}
\subsection{Graph Recognition}
\begin{itemize}
\item In 1998, LeCun etc. proposed the neural network LeNet-5 based on the convolution and applied to the hand-written digits recognition successfully. Hence LeNet-5 is also called the first convolutional neural network(CNN) successfully applied.
\item In 2012, Hinton and his student Alex joined the graph recognition competition by ImageNet and improved the accuracy significantly with the CNN AlexNet.
\item Afterwards CNN is widely used in the field of computer vision and breaks the records ceaselessly.
\end{itemize}

\begin{figure}
\centering
\includegraphics[width=.6\textwidth]{figures/ImageNet}
\end{figure}

\subsection{AlphaGo $\&$ AlphaZero}
One simple example
\begin{itemize}
	\item From 2016 to 2017, the AI program AlphaGo developed by Google DeepMind beat down all the Go champions worldwide.

    \item 2018 AlphaZero gave a unified principle for many other board games.
    \item The CEO of Google DeepMind Demis Hassabis announced to integrate AlphaGo with medical, robots and so on. They can learn by themselves since they are artificial intelligence, and transfer learning can be done with enough data.
\end{itemize}

\begin{figure}
\centering
\includegraphics[width=.8\textwidth]{figures/Alphago2}
\end{figure}

\subsection{Auto-driving (the next competition in AI)}
\begin{itemize}
\item In 2009, Google proposed the plan to replace human driving with softwares.

\item Afterwards, many large technology companies such as Tesla, Google, Uber and Benz devoted a lot on investigating the technology of automated driving.

\item In many countries, road examination autonomous vehicles are allowed with applications.

\item In China, Baidu established the division of intelligent car and opened the platform of automated driving to the public.

\end{itemize}

\begin{figure}[H]
\centering
\includegraphics[width=.6\textwidth]{figures/AutomatedDriving1}\\
\includegraphics[width=.6\textwidth]{figures/AutomatedDriving2}
\end{figure}

\subsection{Speech recognition}
\begin{itemize}
\item Recently, the application of recurrent neural network(RNN) and attention model on the speech recognition has achieved great breakthrough on the accuracy of AI speech recognition.

\item On October 18 2016, during the Smartisan mobile phone launch event, the input speed of iFLY surpassed that of the real keyboards and achieved 100\% in accuracy.

\item In Nov 2016, IFLYTEK, Baidu, Sogou announced they achieved 97\% in the accuracy of Chinese speech recognition respectively.

\item 2018, Google propose the BERT as a evolutionary model in NLP field.
\end{itemize}
\begin{figure}[H]
\centering
\includegraphics[width=.6\textwidth]{figures/SpeechRecognition1}\\
\includegraphics[width=.6\textwidth]{figures/SpeechRecognition2}
\end{figure}

\subsection{Machine translation}

\begin{itemize}
\item On Sep 27 2016,  Google posed a paper in ArXiv.org about Google's Neural Machine Translation (GNMT). On 28th, to the extremely difficult Chinese-English translation.

\item 2018, Baidu, Microsoft, Google announced that they proposed some model to translate better than humans in some certain fields and languages.
\end{itemize}
\begin{figure}[H]
\centering
\includegraphics[width=\textwidth]{figures/MachineTranslation1}\\
\includegraphics[width=\textwidth]{figures/MachineTranslation2}
\end{figure}

\subsection{Future smart healthcare}

\begin{itemize}
\item In 2015, Watson diagnosed leukemia for a 60-year old woman within 10 minutes and proposed adequate therapeutic schedule to Institute of medical science, University of Tokyo

\item On the world cancer day in 2017, Watson wrote a prescription for a patient with advanced gastric cancer within 10 seconds in Tianjin third central hospital

\item The future scope of the big data on medical and smart healthcare is broad.
\end{itemize}
\begin{figure}[H]
\centering
\includegraphics[width=.6\textwidth]{figures/Watson1}\\
\includegraphics[width=.6\textwidth]{figures/Watson2}
\end{figure}

\section{Some similar concepts}
\subsection{Artificial intelligent}
\begin{figure}[H]
\centering
\includegraphics[width=.9\textwidth]{figures/AI}
\end{figure}

\subsection{Machine learning}
\begin{figure}[H]
\centering
\includegraphics[width=.9\textwidth]{figures/ML}
\end{figure}

\subsection{Deep learning}
\begin{figure}[H]
\centering
\includegraphics[width=.9\textwidth]{figures/DL}
\end{figure}

\section{Biological intuition}
\subsection{Neurons of animals}

\begin{itemize}
\item Dendrite: receive the electric signal from other neurons

\item Cell body: process the electric signal from other neurons

\item Axon: send the electric signal to other neurons

\item Activation: the intensity of the signal is larger than the threshold

\end{itemize}

\begin{figure}[H]
\centering
\includegraphics[width=0.9\textwidth]{figures/cell}
\end{figure}

\subsection{Artificial neuron}

\begin{itemize}
\item An artificial neuron consists of
\begin{itemize}
\item An affine transformation:  g(x)=Wx+b

\item A nonlinear function(activation fuction): $\phi$
\end{itemize}
\item The output of the neuron is $y=\phi(g(x))$
\end{itemize}

\begin{figure}[H]
\centering
\includegraphics[width=0.9\textwidth]{figures/neuron}
\end{figure}

\section{Models and structure}
\subsection{Major models in deep learning}
\begin{figure}[H]
\centering
\includegraphics[width=0.9\textwidth]{figures/models}
\end{figure}

\subsection{Basic CNN model structure}
\begin{figure}[H]
\centering
\includegraphics[width=0.9\textwidth]{figures/CNNPic}
\end{figure}

\begin{itemize}
\item General convolutional neural network consists of:
\begin{itemize}
\item Convolution layers
\item Nonlinear layers(activation function)
\item Pooling layers
\item Fully-connected layers

\end{itemize}
\end{itemize}

\subsection{Convolution layer}
\begin{figure}[H]
\centering
\includegraphics[width=0.45\textwidth]{figures/CNNLayer1}
\includegraphics[width=0.45\textwidth]{figures/CNNLayer2}
\end{figure}

\subsection{Convolutional kernel}

\begin{itemize}
\item A convolutional layer consists of multiple convolutional kernel
\item Each convolutional kernel extract a certain feature/channel
\item The graph processed after convolutional layer is called feature mapping
\end{itemize}

\begin{figure}[H]
\centering
\includegraphics[width=\textwidth]{figures/kernel}
\end{figure}

\subsection{Activation function}
\begin{figure}[H]
\centering
\includegraphics[width=0.9\textwidth]{figures/activate}
\end{figure}

\subsection{Pooling layer}
\begin{figure}[H]
\centering
\includegraphics[width=.6\textwidth]{figures/PoolingLayer1}
\end{figure}

\begin{figure}[H]
\centering
\includegraphics[width=.6\textwidth]{figures/PoolingLayer2}
\end{figure}

\subsection{Fully-connected layers (DNN)}
\begin{figure}[H]
\centering
\includegraphics[width=.4\textwidth]{figures/FC}
\end{figure}

\begin{minipage}[c][0.45\textheight][c]{\linewidth}
\begin{itemize}
\item Each neuron in the previous layer is connected with each neuron in the latter layer
\item A fully-connected layer can be represented with the following linear function
$$y=Wx+b$$
\begin{itemize}
\item $x$ --- input
\item $y$ --- output
\item $W,b$--- parameters

\end{itemize}
\item Fully-connected layer makes classification with the features extracted by the convolutional layer

\end{itemize}

\end{minipage}

\subsection{A typical machine learning process}
  \begin{enumerate}
  \item Dimension reduction (linear or nonlinear)
    \begin{itemize}
    \item Convolutional Neural Networks (CNN)
    \end{itemize}
\item Classifier (linear)
  \begin{itemize}
  \item Fully connected layer
  \end{itemize}
  \end{enumerate}
\begin{figure}[H]
\centering
		\includegraphics[width=.9\textwidth]{figures/CNNKernel}
\end{figure}

\subsection{A complete convolutional neural network example}

\begin{figure}[H]
\centering
\includegraphics[width=\linewidth]{figures/CNN2}
%\caption{First convolutional neural network: LeNet-5 (Y. LeCun, L. Bottou, Y. Bengio, and P. Haffner, 1998)}
\end{figure}

\begin{itemize}
\item Convolutional layer: extract the features of the graphs
\item Fully-connected layer: make classification with the extracted features
\end{itemize}

\subsection{An example of convolutional neural network: AlphaGo}
\begin{figure}[H]
\centering
\includegraphics[width=0.9\textwidth]{figures/Alphago3}
\end{figure}

\subsection{Deep convolutional neural network}
\begin{figure}[H]
\centering
\includegraphics[width=0.9\textwidth]{figures/deepcnn}
\end{figure}

\section{Learning(training)}
The process of learning is the process to minimize the loss function
$\min_{W\in \mathbb{R}^n}\frac{1}{m}\Sigma^m_{i=1}L(f(X^i;W),Y^i)$

\begin{itemize}
\item Training methods in common use: gradient descend, stochastic gradient descend, simulating annealing, etc.

\item The training time is extremely long for the current deep neural network due to the plentiful parameters. It takes several weeks to train a traditional deep learning model
\begin{itemize}
\item AlexNet: takes 5-6 days to train on two GTX 580 3GB GPU
\item VGGNet: takes 2-3 weeks to train on NVIDIA Titan Black GPU
\item ResNet-50: 30 hours on DGX-1, 224 seconds on (Nvidia V100*2176 $\approx \$$ 13M)
\end{itemize}
\item Research direction: improvement on the models and training algorithms
\begin{itemize}
\item Construct more efficient neural network model: deep or shallow?

\item Implement efficient and stable training algorithms

\item GPU? TPU? Or CPU only?
\end{itemize}
\end{itemize}

\section{Medical AI}
\subsection{Medical AI - I }
\begin{itemize}
\item Images
\begin{itemize}
\item Medical images screening
\item Image registration
\item Organ segmentation in images
\item Diseased region extraction
\item Lesion feature classification
\end{itemize}

\item Biological parameters
\begin{itemize}
\item Disease diagnosis or alert based on the blood glucose, heart rate, ECG, etc.
\item Noninvasive detection of biological parameters such as blood glucose and blood fat
\end{itemize}

\item others
\begin{itemize}
\item Operation result prediction
\item Online medical
\end{itemize}

\end{itemize}

\begin{figure}[H]
\centering
\includegraphics[width=.6\textwidth]{figures/aimedical}
\end{figure}

\subsection{Medical AI - II}
\begin{itemize}
\item 1970s --- 1990s: traditional methods: manual set rules + mathematical modeling
\item 1990s --- 2000s: manual feature extraction+ supervised learning
\item 2000s --- 2010s:  end to end(automatic feature extraction+ learning)
\end{itemize}
\begin{figure}[H]
\centering
\includegraphics[width=\textwidth]{figures/medicalai}
\end{figure}

\subsection{Medical AI - III}
AI can automatically diagnose the cancer
\begin{itemize}
\item In 2017,  a team in Stanford University achieved AI automatic diagnosis of the skin cancer with the CNN, the accuracy of which is as high as a human expert.
\item This model is trained based on a public model  by Google, while the original model is only used to classify the cats and dogs in photos.
\end{itemize}

\begin{figure}[H]
\centering
\includegraphics[width=\textwidth]{figures/medicalai1}
\end{figure}

\subsection{Medical AI - IV}
The deep neural network has achieved the recognition of focus position in medical images:
\begin{itemize}
\item During 2016 to 2017, two famous data competition platforms Kaggle and Ali yuntianchi held competitions of pulmonary nodules intelligent diagnosis based on the CT images
\item The winner team used the U-Net model based on the CNN and achieved high accuracy
\end{itemize}
\begin{figure}[H]
\centering
\includegraphics[width=\textwidth]{figures/medicalai2}
\end{figure}

\subsection{Medical AI - V}
AI can generate the diagnosis report automatically
\begin{itemize}
\item By combining CNN and RNN, learned with X-Ray images of chest and corresponding diagnosis report data, it can be achieved for classification of chest X-Ray and generate the diagnosis report automatically
\end{itemize}
\begin{figure}[H]
\centering
\includegraphics[width=0.8\textwidth]{figures/medicalai3}
\end{figure}

\section{Generative Adversarial Networks}
\begin{figure}[H]
\centering
\includegraphics[width=0.9\textwidth]{figures/gan}
\end{figure}

\subsection{GAN: similar to word embedding }
\begin{figure}[H]
\centering
\includegraphics[width=0.9\textwidth]{figures/gan2}
\end{figure}

\subsection{Text to Image, by conditional GAN}
\begin{figure}[H]
\centering
\includegraphics[width=0.9\textwidth]{figures/gan3}
\end{figure}

\subsection{Text to Image, by conditional GAN}
\begin{figure}[H]
\centering
\includegraphics[width=0.9\textwidth]{figures/gan4}
\end{figure}

\section{2019-summer undergraduate course}
\begin{figure}[H]
\centering
\includegraphics[width=\linewidth]{figures/flyer.pdf}
\end{figure}


% Created 2011-04-18 Mon 03:20
\documentclass[presentation]{beamer}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{fixltx2e}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{float}
\usepackage{wrapfig}
\usepackage{soul}
\usepackage{textcomp}
\usepackage{marvosym}
\usepackage{wasysym}
\usepackage{latexsym}
\usepackage{amssymb}
\usepackage{hyperref}
\tolerance=1000
\usepackage[english]{babel} \usepackage{ae,aecompl}
\usepackage{mathpazo,courier,euler} \usepackage[scaled=.95]{helvet}
\usepackage{listings}
\lstset{language=Python, basicstyle=\ttfamily\bfseries,
commentstyle=\color{red}\itshape, stringstyle=\color{darkgreen},
showstringspaces=false, keywordstyle=\color{blue}\bfseries}
\providecommand{\alert}[1]{\textbf{#1}}

\title{modules.rst.org}
\author{}
\date{\today}

\usetheme{Warsaw}\usecolortheme{default}\useoutertheme{infolines}\setbeamercovered{transparent}
\begin{document}

\maketitle

\begin{frame}
\frametitle{Outline}
\setcounter{tocdepth}{3}
\tableofcontents
\end{frame}

\section{Using Python modules}
\label{sec-1}

We shall, in this section, see how to run Python scripts from the
command line, and more details about importing modules.

Let us create a simple python script to print hello world. Open your
text editor and type the following, and save the script as \texttt{hello.py}.

\begin{verbatim}
print "Hello world!"
\end{verbatim}

Until now we have been running scripts from inside IPython, using

\begin{verbatim}
%run -i hello.py
\end{verbatim}

But, as we know, IPython is just an advanced interpreter and it is not
mandatory that every one who wants to run your program has IPython
installed.

So, the right method to run the script, would be to run it using the
Python interpreter. Open the terminal and navigate to the directory
where \texttt{hello.py} is saved.

Then run the script by saying,

\begin{verbatim}
python hello.py
\end{verbatim}

The script is executed and the string \texttt{Hello World!} has been printed.

Now let us run a script that plots a simple sine curve in the range -2pi
to 2pi, using Python, instead of running it from within IPython.

Type the following lines and save it in \texttt{sine\_plot.py} file.

\begin{verbatim}
x = linspace(-2*pi, 2*pi, 100)
plot(x, sin(x))
show()
\end{verbatim}

Now let us run sine\_plot.py as a python script.

\begin{verbatim}
python sine_plot.py
\end{verbatim}

Do we get the plot? No! All we get is error messages. Python complains
that \texttt{linspace} isn't defined. What happened? Let us try to run the same
script from within IPython. Start IPython, with the \texttt{-pylab} argument
and run the script. It works!

What is going on, here? IPython when started with the \texttt{-pylab} option,
is importing a whole set of functionality for us to work with, without
bothering about importing etc.

Let us now try to fix the problem by importing \texttt{linspace}.

Let's add the following line as the first line in the script.

\begin{verbatim}
from scipy import *
\end{verbatim}

Now let us run the script again,

\begin{verbatim}
python sine_plot.py
\end{verbatim}

Now we get an error, that says \texttt{plot} is not defined. Let's edit the
file and import this from pylab. Let's add the following line, as the
second line of our script.

\begin{verbatim}
from pylab import *
\end{verbatim}

And run the script,

\begin{verbatim}
python sine_plot.py
\end{verbatim}

Yes! it worked. So what did we do?

We actually imported the required functions and keywords, using
\texttt{import}. By using the *, we are asking python to import everything from
the \texttt{scipy} and \texttt{pylab} modules. This isn't a good practice, as 1. it
imports a lot of unnecessary things 2. the two modules may have
functions with the same name, which would cause a conflict.

One of the ways out is to import only the stuff that we need,
explicitly.

Let us modify sine\_plot.py by replacing the import statements with the
following lines.

\begin{verbatim}
from scipy import linspace, pi, sin
from pylab import plot, show
\end{verbatim}

Now let us try running the code again as,

\begin{verbatim}
python show_plot.py
\end{verbatim}

As expected, this works. But, once the number of functions that you need
to import increases, this is slightly inconvenient. Also, you cannot use
functions with the same name, from different modules. To overcome this,
there's another method.

We could just import the modules as it is, and use the functions or
other objects as a part of those modules. Change the import lines, to
the following.

\begin{verbatim}
import scipy
import pylab
\end{verbatim}

Now, replace \texttt{pi} with \texttt{scipy.pi}. Similarly, for \texttt{sin} and \texttt{linspace}.
Replace \texttt{plot} and \texttt{show} with \texttt{pylab.plot} and \texttt{pylab.show},
respectively.

Now, run the file and see that we get the output, as expected.

We have learned how to import from modules, but what exactly is a
module? How is one written?

A module is simply a Python script containing the definitions and
statements, which can be imported. So, it is very easy to create your
own modules. You just need to stick in all your definitions into your
python file and put the file in your current directory.

When importing, Python searches the locations present in a variable
called the Python path. So, our module file should be present in one of
the locations in the Python path. The first location to be searched is
the current directory of the script being run. So, having our module
file in the current working directory, is the simplest way to allow it
to be used as a module and import things from it.

Python has a very rich standard library of modules. It is very
extensive, offering a wide range of facilities. Some of the standard
modules are,

for Math: math, random for Internet access: urllib2, smtplib for System,
Command line arguments: sys for Operating system interface: os for
regular expressions: re for compression: gzip, zipfile, tarfile And
there are lot more.

Find more information at Python Library reference,
\texttt{http://docs.python.org/library/}

There are a lot of other modules like pylab, scipy, Mayavi, etc which
are not part of the standard Python library.

This brings us to the end of our discussion on modules and running
scripts from the command line.
\section{Writing modules}
\label{sec-2}

In this section we shall look at writing modules, in some more detail.
Often we will have to reuse the code that we have previously written. We
do that by writing functions. Functions can then be put into modules,
and imported as and when required.

Let us first write a function that computes the gcd of two numbers and
save it in a script.

\begin{verbatim}
def gcd(a, b):
    while b:
        a, b = b, a%b
    return a
\end{verbatim}

Now, we shall write a test function in the script that tests the gcd
function, to see if it works.

\begin{verbatim}
if gcd(40, 12) == 4 and gcd(12, 13) == 1:
    print "Everything OK"
else:
    print "The GCD function is wrong"
\end{verbatim}

Let us save the file as gcd\_script.py in \texttt{/home/fossee/gcd\_script.py}
and run it.

\begin{verbatim}
$ python /home/fossee/gcd_script.py
\end{verbatim}

We can see that the script is executed and everything is fine.

What if we want to use the gcd function in some of our other scripts.
This is also possible since every python file can be used as a module.

But first, we shall understand what happens when you import a module.

Open IPython and type

\begin{verbatim}
import sys
sys.path
\end{verbatim}

This is a list of locations where python searches for a module when it
encounters an import statement. Hence, when we just did \texttt{import sys},
python searches for a file named \texttt{sys.py} or a folder named \texttt{sys} in all
these locations one by one, until it finds one. We can place our script
in any one of these locations and import it.

The first item in the list is an empty string which means the current
working directory is also searched.

Alternatively, we can also import the module if we are working in same
directory where the script exists.

Since we are in /home/fossee, we can simply do

\begin{verbatim}
import gcd_script
\end{verbatim}

We can see that the gcd\_script is imported. But the test code that we
added at the end of the file is also executed.

But we want the test code to be executed only when the file is run as a
python script and not when it is imported.

This is possible by using \texttt{\_\_name\_\_} variable.

Go to the file and add

\begin{verbatim}
if __name__ == "__main__":
\end{verbatim}

before the test code and indent the test code.

Let us first run the code.

\begin{verbatim}
$ python gcd_script.py
\end{verbatim}

We can see that the test runs successfully.

Now we shall import the file

\begin{verbatim}
import gcd_script
\end{verbatim}

We see that now the test code is not executed.

The \texttt{\_\_name\_\_} variable is local to every module and it is equal to
\texttt{\_\_main\_\_} only when the file is run as a script. Hence, all the code
that goes in to the if block, \texttt{if \_\_name\_\_ =} ``__main__'':= is executed
only when the file is run as a python script.

\end{document}