%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% UMB-CS110-2015S: Introduction to Computing
% Copyright 2015 Pejman Ghorbanzade <pejman@ghorbanzade.com>
% Creative Commons Attribution-ShareAlike 4.0 International License
% More info: https://github.com/ghorbanzade/UMB-CS110-2015S
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\def \topDirectory {../..}
\def \texDirectory {\topDirectory/src/main/tex}

\documentclass[10pt, compress]{beamer}

\usepackage{\texDirectory/template/style/directives}
\input{\texDirectory/template/config}
\usepackage{\texDirectory/template/style/beamerthemeUmassLecture}
\doc{number}{7}
%\setbeamertemplate{footline}[text line]{}

\begin{document}
\prepareCover

\section{Course Administration}

\begin{frame}[fragile]
\frametitle{Course Administration}
	Assignment 2 deadline extended to Mar 5, 2015 at 17:30 PM.

	All Submissions should contain only .java files.

	Make sure your submission was sucessful by downloading it from server.
\end{frame}

\begin{frame}[fragile]
	\frametitle{Overview}
	\begin{itemize}
		\item[] Arrays
			\begin{itemize}
				\item[] One-Dimensional Arrays
				\item[] Multi-Dimensional Arrays
			\end{itemize}
	\end{itemize}
\end{frame}

\plain{}{Arrays}

\section{One-Dimensional Arrays}

\begin{frame}[fragile]
	\frametitle{One-Dimensional Arrays}
	\begin{block}{Objective}
		Write a program \texttt{RandomCard.java} that randomly selects a card from a standard 52-card deck and prints its name.
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{One-Dimensional Arrays}
	\begin{block}{\texttt{RandomCard.java} (v1.0)}
		\begin{minted}[fontsize=\small,tabsize=8, linenos, firstnumber=1]{java}
public class RandomCard {
	public static void main(String[] args) {
		int numCard = 52;
		int randNum = 1 +
				(int) Math.floor( Math.random() * numCard );
		// Now I have to print name of the card
		switch (randNum) {
			case 1 : cardName = "Ace of Spades"; break;
			case 2 : cardName = "Two of Spades"; break;
			//... seriously?
			case 51 : cardName = "Queen of Hearts"; break;
			case 52 : cardName = "King of Hearts"; break;
		}
	}
}
		\end{minted}
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{One-Dimensional Arrays}
	\begin{block}{\texttt{RandomCard.java} (v2.0)}
		\begin{minted}[fontsize=\small,tabsize=8, linenos, firstnumber=5]{java}
suitNum = randNum / 13;
switch (suitNum) {
	case 1 : suitName = "Spades"; break;
	case 2 : suitName = "Diamonds"; break;
	case 3 : suidName = "Clubs"; break;
	case 4 : suitName = "Hearts"; break;
}
switch cardNum = numCard % 13;
switch (cardNum) {
	case 1 : cardName = "Ace"; break;
	case 2 : cardName = "Two"; break;
	//... not cool!
	case 12 : cardName = "Queen"; break;
	case 13 : cardName = "King"; break;
}
System.out.println(cardName + " of " + suitName);
		\end{minted}
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{One-Dimensional Arrays}
	\begin{block}{Problem Statement}
		Access to names of values and suits are limited.

		Same code should be executed every time name of card is needed.

		Solution is not expandable.
	\end{block}
	\begin{block}{Clue}
		All cases assign string literals to one single variable.

		Name of $13^{th}$ card numbers for every suit is "King".
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{One-Dimensional Arrays}
	\begin{block}{Proposed Solution}
		Define an ordered collection of card names and get name of a card by calling its position in collection.
		\begin{minted}[fontsize=\small,tabsize=8]{java}
String[] SuitNames = {
	"Spades", "Diamonds", "Clubs", "Hearts"};
String[] CardNames = {
	"Ace", "Two", "Three", "Four", "Five",
	"Six", "Seven", "Eight", "Nine", "Ten",
	"Soldier", "Queen", "King"};
		\end{minted}
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{One-Dimensional Arrays}
	\begin{block}{Definition}
		Array is a data structure that holds a \texttt{fixed} number of elements of a \texttt{single} type.

		Each array element is identified by its \texttt{numerical index}.

		An array is stored based on position of its \texttt{first} element.

		First element of an array has index 0.
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{One-Dimensional Arrays}
	\begin{block}{Definition}
		\begin{minted}[fontsize=\small,tabsize=8]{java}
int[] primes;
primes = new int[4];
primes[0] = 2;
primes[1] = 3;
primes[2] = 5;
primes[3] = 7;
for (int i = 0; i < 4; i++)
	System.out.println("Prime " + (i+1) + " is " + primes[i]);
		\end{minted}
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{One-Dimensional Arrays}
	\begin{block}{\texttt{RandomCard.java} (v3.0)}
		\begin{minted}[fontsize=\small,tabsize=8, linenos, firstnumber=5]{java}
String[] SuitNames = {
	"Spades", "Diamonds", "Clubs", "Hearts"};
String[] CardNames = {
	"Ace", "Two", "Three", "Four", "Five",
	"Six", "Seven", "Eight", "Nine", "Ten",
	"Soldier", "Queen", "King"};
suitNum = randNum / 13;
cardNum = numCard % 13;
suitName = suitNames[suitNum];
cardName = cardNames[cardNum];
System.out.println(cardName + " of " + suitName);
		\end{minted}
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{One-Dimensional Arrays}
	\begin{block}{Advantages}
		\begin{itemize}
			\item[] Data is more organized.
			\item[] Code reuse is now possible.
			\item[] Solution is expandable.
		\end{itemize}
	\end{block}
	\begin{block}{Disadvantages}
		\begin{itemize}
			\item[] Once declared, size of array is fixed.
			\item[] Insertion and deletion are not possible.
		\end{itemize}
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{One-Dimensional Arrays}
	\begin{block}{Objective}
		Write a program \texttt{PrimeNumber.java} that first prints all first 1000 prime numbers.
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{One-Dimensional Arrays}
	\begin{block}{\texttt{PrimeNumber.java} (v1.0)}
		\begin{minted}[fontsize=\small,tabsize=8, linenos, firstnumber=3]{java}
int counter = 0;
int number = 2;
boolean definitelyNotPrime;
while (counter < 1000) {
	definitelyNotPrime = false;
	for (int i = 2; i < number/2; i++)
		if (number % i == 0){
			definitelyNotPrime = true;
			break;
		}
	if (!definitelyNotPrime)
		System.out.printf("%4d: %d\n",++counter,number);
	number++;
}
		\end{minted}
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{One-Dimensional Arrays}
	\begin{block}{Problem Statement}
		To check if number \texttt{N} is prime, it suffices to check whether it is devisible by at least one prime number less than or equal to \texttt{N/2}.
		\begin{itemize}
			\item[] Not necessary to check all numbers less than \texttt{N/2}.
		\end{itemize}
		What if we are asked to print $1^{st}$, $3^{rd}$, $5^{th}$, ... prime numbers, after printing all first 1000 prime numbers?
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{One-Dimensional Arrays}
	\begin{block}{Objective}
		Write a program \texttt{PrimeNumber.java} that first prints all first 1000 prime numbers then prints 500th prime number.
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{One-Dimensional Arrays}
	\begin{block}{\texttt{PrimeNumber.java} (v2.0)}
		\begin{minted}[fontsize=\small,tabsize=8, linenos, firstnumber=3]{java}
int[] primeNumbers = new int[1000];
int counter = 0;
int number = 2;
boolean definitelyNotPrime;
while (counter < primeNumbers.length) {
	definitelyNotPrime = false;
	for (int i = 0; i < counter && !definitelyNotPrime; i++)
		if (number % primeNumbers[i] == 0)
			definitelyNotPrime = true;
	if (!definitelyNotPrime) {
		primeNumbers[counter++] = number;
		System.out.printf("%4d: %d\n",counter,number);
	}
	number++;
}
System.out.printf("%4d: %d\n",500,primeNumbers[499]);
		\end{minted}
	\end{block}
\end{frame}

\section{Multi-Dimensional Arrays}

\begin{frame}[fragile]
	\frametitle{Multi-Dimensional Arrays}
	\begin{block}{Dimension Definition}
		The dimension of an array is the number of indices needed to select an element.
	\end{block}
	\begin{block}{Initialization}
		\begin{minted}[fontsize=\small,tabsize=8]{java}
int[][] matrix = new int[3][3];
for (int i = 0; i < 3; i++)
	for (int j = 0; j < 3; j++)
		matrix[i][j] = 0;
		\end{minted}
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Multi-Dimensional Arrays}
	\begin{block}{Objective}
		Write a program \texttt{MagicMatrix.java} that takes number \texttt{N} and generates a magic matrix of size \texttt{N} using numbers $1$ to $N^2$.
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Multi-Dimensional Arrays}
	\begin{block}{Simplification}
		\begin{itemize}
			\item[] Get matrix size N from user
			\item[] Build an array of length $N^2$ from 1 to N
			\item[] Shuffle the array
			\item[] Convert 1-D Array to 2-D Array
			\item[] Print elements of array
		\end{itemize}
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Multi-Dimensional Arrays}
	\begin{block}{\texttt{MagicMatrix.java} (part 1)}
		\begin{minted}[fontsize=\small,tabsize=8, linenos, firstnumber=1]{java}
public class Array {
	public static void main(String[] args) {
		// get matrix size
		Scanner input = new Scanner(System.in);
		int num = input.nextInt();
		input.close();

		// initialize array
		int[] numbers = new int[num * num];
		for (int i = 0; i < numbers.length; i++)
			numbers[i] = i+1;
		\end{minted}
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Multi-Dimensional Arrays}
	\begin{block}{\texttt{MagicMatrix.java} (part 2)}
		\begin{minted}[fontsize=\small,tabsize=8, linenos, firstnumber=12]{java}
		// shuffle array
		for (int i = 0; i < numbers.length; i++) {
			int j = (int) (i + (numbers.length-i)*Math.random());
			int temp = numbers[j];
			numbers[j] = numbers[i];
			numbers[i] = temp;
		}
		\end{minted}
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Multi-Dimensional Arrays}
	\begin{block}{\texttt{MagicMatrix.java} (part 3)}
		\begin{minted}[fontsize=\small,tabsize=8, linenos, firstnumber=19]{java}
		// convert shuffled array to matrix
		int[][] matrix = new int[num][num];
		for (int i = 0; i < numbers.length; i++) {
			matrix[i/num][i%num] = numbers[i];
		}

		// show matrix
		for (int i = 0; i < num; i++) {
			for (int j = 0; j < num; j++)
				System.out.print(matrix[i][j]);
			System.out.println();
		}
	}
}
		\end{minted}
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Multi-Dimensional Arrays}
	\begin{block}{Higher Dimensional Arrays}
		\begin{minted}[fontsize=\small,tabsize=8, linenos, firstnumber=1]{java}
int num = 1;
int[][][] cubicMatrix = new int[3][3][3];
for (int i = 1; i < 3; i++)
	for (int j = 1; j < 3; j++)
		for (int k = 1; k < 3; k++)
			cubicMatrix[i][j][k] = num++;
		\end{minted}
	\end{block}
\end{frame}

\begin{frame}[fragile]
	\frametitle{Multi-Dimensional Arrays}
	\begin{block}{Remember}
		\begin{itemize}
			\item[] Arrays are simple data structures for data organization
			\item[] Arrays provide an efficient way to access data
			\item[] Elements of array are of same type
			\item[] Arrays have fixed-size
		\end{itemize}
	\end{block}
\end{frame}

\plain{}{Keep Calm\\and\\Practice}

\end{document}


\documentclass[11pt]{article}
\usepackage{6001}
\usepackage{time,fullpage}
\usepackage{amsmath}
\usepackage{../epsfig}
%\input ../6001mac

\textheight 8in

\oddsidemargin 11pt
\evensidemargin \oddsidemargin
\marginparwidth 0.5in

\advance\textwidth by -2\oddsidemargin

\newdimen\tablewidth
\tablewidth=\textwidth
\advance \tablewidth by -11pt

\parindent 0.0in
\parskip \medskipamount

\let\to\rightarrow
\let\union\cup
\let\cross\times

\def\SI{\mbox{Scheme-Integer}}
\def\SNI{\mbox{Scheme-Nonneg-Integer}}
\def\SN{\mbox{Sch-\-Num}}
\def\SB{\mbox{Sch-Bool}}
\def\Empty{\mbox{Empty}}
\def\SI{\mbox{Sch-Int}}
\def\SNI{\mbox{Sch-Nonneg-Int}}

\makeatletter

\def\DefineBNFAbbrev#1#2{%
    \expandafter\newcommand\expandafter{\csname#1\endcsname}{\@bnfabbrev{#2}}%
}

\def\@bnfabbrev#1{%
    \@ifnextchar _{\@subabbrev{#1}}{\@plainabbrev{#1}}%
}

\def\@subabbrev#1_#2{\hbox{\normalfont$\langle\mbox{#1}_{#2}\rangle$}}

\def\@plainabbrev#1{\hbox{\normalfont$\langle\mbox{#1}\rangle$}}

% \def\exp{\hbox{$\bnf <expression>$}}

\DefineBNFAbbrev{expr}{expression}
\DefineBNFAbbrev{define}{define}
\DefineBNFAbbrev{defines}{defines}
\DefineBNFAbbrev{vrbl}{variable}
\DefineBNFAbbrev{bod}{body}
\DefineBNFAbbrev{init}{init}
\DefineBNFAbbrev{val}{value}
\DefineBNFAbbrev{pval}{primitive\ value}
\DefineBNFAbbrev{ival}{immediate\ value}
\DefineBNFAbbrev{test}{test}
\DefineBNFAbbrev{orsf}{or}
\DefineBNFAbbrev{andsf}{and}
%\DefineBNFAbbrev{beginsf}{begin}

\makeatletter

\def\fbox#1{%
  \vtop{\vbox{\hrule%
     \hbox{\vrule\kern3pt%
 \vtop{\vbox{\kern3pt#1}\kern3pt}%
 \kern3pt\vrule}}%
 \hrule}}

\begin{document}

\psetheader{Spring Semester, 1995}{Supplementary Notes}
\begin{center}\large
{\bf A Term Rewriting Model for Scheme}
\end{center}

\medskip

\begin{flushleft}
Issued:  Tuesday, 7 March, 1995\\
\end{flushleft}

\section{Substitution Models}

A useful way to think about computation in Scheme is as {\em algebraic
  simplification\/} aimed at computing the value of an expression by
successively simplifying its subexpressions.  The use of names for terms
is also a familiar part of arithmetic/algebraic manipulation, as in,
\begin{quote}
Let $p(x) = x^{2}-1$, then the polynomial $p$ factors into
$p_{1}\cdot p_{2}$ where $p_{1}(x) = x + 1$ and $p_{2}(x) = x - 1$.
\end{quote}
Naming rules are usually not spelled out in studying algebra, but in
Scheme, as in all programming languages, such rules play a key
role---arguably a more important one than the ordinary algebraic rules.  A
system of rules which explain Scheme computation in terms of symbolic
manipulation of Scheme expressions and definitions is called a {\em
Substitution Model} for Scheme.

For example, the {\em variable instantiation} rule is a basic naming rule:
\begin{quote}
replace an occurrence of a variable by the expression it names.
\end{quote}
Implicit in this rule is a simple recipe for figuring out what expression
a variable names: starting at the variable to be instantiated, search back
through the expression tree until you come to a definition of that
variable.

In the Substitution Model sketched in 6.001 lectures and text, there is
also a particular {\em substitution rule} for handling procedure
application.  In the case of a one argument procedure, the substitution
rule is:
\begin{quote}
rewrite ``\Code{((lambda ($x$) $B$) $V$)}'' as ``$B$ with $V$ substituted
for $x$''.
\end{quote}

In these notes we describe a slightly different rule for procedure
application.  The Substitution Model using this new rule dramatically
shortens the size of expressions to be manipulated in many examples.
It also will allow us to model Scheme's computational behavior much
more accurately\footnote{The Substitution Model in the text is
  sketchily described (on purpose, to avoid distracting beginners with
  details).  The most straightforward ways of spelling out the details
  lead to models which have to be abandoned altogether when we
  introduce side-effects.  Side-effects are explained in Chapter 3 of
  the text with a new {\em environment model}.  You won't have to
  unlearn the new Substitution Model described in these Supplementary
  Notes, because it extends to handle side-effects quite well.  In
  fact, the environment model can usefully be understood as a way to
  {\em implement} the new Substitution Model efficiently.}.

We'll simply call the new rule the {\em lambda application rule}.  In the
one argument case, it is:
\begin{quote}
rewrite ``\Code{((lambda ($x$) $B$) $V$)}'' as ``$B$''\\
while adding the definition ``\Code{(define $x$ $V$)}.''
\end{quote}
Of course to use this rule, we'll need to specify where and how to ``add''
definitions.

It's helpful to realize that the new lambda application rule could be used
to simulate the old rule: starting with \Code{((lambda ($x$) $B$) $V$)},
use the lambda application rule.  This gives $B$ along with the definition
\Code{(define $x$ $V$)}.  Then, by successively instantiating all the
$x$'s in $B$ by copies of $V$, we arrive at the same result as the
substitution rule.  Well almost---we still have the definition of $x$
hanging around.  But since we instantiated all the $x$'s, this definition
no longer refers to anything and is not needed.  So we will apply a new
rule which allows us to remove unreferenced definitions.

\subsection{Syntactic Values}

We said that the point of Substitution Model rewrite rules is to arrive at
the value of an expression.  More precisely, the aim is to arrive at some
standardized, syntactic representation called the {\em syntactic value} of
the expression.  Before examining the rules in detail, we should have a
clear picture of what syntactic values look like.

The most familiar syntactic values are the {\em primitive values}.  These
are objects like numbers or truth values which have standard
representations printable as output.

Scheme provides dozens of {\em primitive procedure variables} like
\Code{+}, \Code{<}, \Code{atan}, or \Code{not} which can be applied to
primitive values.  These primitive procedure variables will also be
syntactic values\footnote{We assume here that primitive procedure
variables won't be redefined!  In fact, according to the official
definition of \RFS, it is possible to redefine them.  In creating 6.001
Scheme from general MIT Scheme, the arithmetic operators do get redefined
slightly---so that rational arithmetic does not yield unexpectedly huge
quotients.}.

Scheme also provides a means to construct procedure values, namely, with
lambda expressions.  The
\begin{itemize}
\item primitive values,
\item primitive procedure variables, and
\item lambda expressions,
\end{itemize} are called {\em immediate values}.

The full meaning of lambda expression like \Code{(lambda (x) (+ x y))}
isn't determined until we know what number \Code{y} is defined to be, so
we also allow syntactic values like
\begin{lisp}
(define y 2)
(lambda (x) (+ x y))
\end{lisp}
which represents the ``add 2'' function.  In general, a {\em syntactic
value} is a sequence of zero or more {\em immediate definitions} followed
by an immediate value, where an immediate definition is of the form
\Code{(define \vrbl\ \ival)}.

\section{Term Rewriting}

We begin by describing rewrite rules for combinations and \Code{if}
expressions.  To manage definitions, we'll also have rewrite rules for
Scheme bodies, where a {\em body} is sequence of zero or more definitions
followed by an expression.  We'll use the notation
\[\bod_{1} \rulesto \bod_{2}\]
to indicate the rule that $\bod_{1}$ can be rewritten as, that is, replaced
by, $\bod_2$.

When an expression not only returns a value but also causes {\em
side-effects} like printing, then it is essential to be able to control
how rules are applied, and this is a crucial aspect of Scheme programming.
But as long as we focus on {\em values}, as we have to this point in
6.001, we needn't specify any special strategy for applying rules: a
sub-body matching the lefthand side of a rule can be rewritten as the
righthand side, anywhere, anytime.\footnote{For example, Scheme
unambiguously specifies that evaluation of the combination:
\[\Code{((lambda (x) ((lambda (y) 99) (display \#t))) (display \#f))}\]
will cause the operand to be evaluated before the {\em body} of the
operator, so \Code{\#f\#t} will be printed before the value \Code{99} is
returned.  On the other hand, if the inner \Code{display} combination
within the body was evaluated first, then \Code{\#t\#f} would be printed
before the value \Code{99} was returned.  But it's the same syntactic
value, \Code{99}, returned in either case!} A Substitution Model in which
rules can be used anywhere is called a {\em term rewriting model} (TRM).
That's what we will describe for Scheme.

\subsection{Primitive Application Rules}
We take for granted an (infinite) set of {\em primitive application rules\/}
for rewriting primitive operators on primitive values, for example,
\begin{eqnarray*}
\Code{(- 2 3)}  & \rulesto & \Code{-1}\\
\Code{(* 4 5 42)}  & \rulesto & \Code{840}\\
\vdots
\end{eqnarray*}
In general, a primitive application rule is of the form
\[\bnf\Code{($<primitive procedure variable>$ \pval_{1} \ldots)} \rulesto \pval.\]

By repeatedly {\em applying\/} such rules, namely replacing lefthand sides
of rules with their righthand sides, we can rewrite any nested primitive
combination to its primitive value.  For example,
\begin{eqnarray*}
\Code{(+ 0 1 (- 2 3) (* 4 5 (* -6 -7)))}  & \rulesto & \Code{(+ 0 1 (- 2 3) (* 4 5 42))}\\
{}&  \rulesto & \Code{(+ 0 1 -1 (* 4 5 42))}\\
{}&  \rulesto & \Code{(+ 0 1 -1 840)}\\
{}&  \rulesto & \Code{840}
\end{eqnarray*}

Another familiar set of primitive application rules result in the {\em
truth values\/} \Code{#t}, \Code{#f}:
\begin{eqnarray*}
\Code{(< 6 7)}  & \rulesto & \Code{#t}\\
\Code{(not #f)}  & \rulesto & \Code{#t}\\
\Code{(zero? -1.414)}  & \rulesto & \Code{#f}\\
\vdots
\end{eqnarray*}
For example, applying these rules and the numerical ones above allows us
to handle:
\begin{eqnarray*}
\Code{(not (< (+ 0 1 2) (/ 3 1)))}  & \rulesto & \Code{(not (< (+ 0 1 2) 3))}\\
{}&  \rulesto & \Code{(not (< 3 3))}\\
{}&  \rulesto & \Code{(not #f)}\\
{}&  \rulesto & \Code{#t}
\end{eqnarray*}

It is easy to see that {\em it does not matter in what order the primitive
rewriting rules are applied}---the primitive value at the end will always
be the same!\footnote{Well, there's a {\em proviso\/} here: the primitive
value is unique when it is {\em possible} somehow to rewrite the
expression into one.  Some ``ill-typed'' expressions like \Code{(/ \#t 3)}
do not have values.  (What would Scheme do when such an expression is
evaluated?)} For example, we might have chosen to rewrite the example
above in another order:
\begin{eqnarray*}
\Code{(not (< (+ 0 1 2) (/ 3 1)))}  & \rulesto & \Code{(not (< 3 (/ 3 1)))}\\
{}&  \rulesto & \Code{(not (< 3 3))}\\
{}&  \rulesto & \Code{(not #f)}\\
{}&  \rulesto & \Code{#t}
\end{eqnarray*}
The primitive value is unique because Scheme is {\em fully
parenthesized}---ambiguous mathematical expressions like $(3 + 2 - 4)$ are
disallowed---and because there are no primitive rules with the same
lefthand side but different righthand sides.

\subsection{Conditional Rules}
There are two rewrite rules for an \Code{if} expression:
\begin{bnf}
\begin{eqnarray*}
\Code{(if #f \expr_{1} \expr_{2} )} & \rulesto & \expr_{2}\\
\Code{(if $<non-"#f" immediate value>$ \expr_{1} \expr_{2})} & \rulesto & \expr_{1}
\end{eqnarray*}
\end{bnf}

Note that, in contrast to primitive applications, the \Code{if} rule can
be applied without the constraint that $\expr_{1}$ and $\expr_{2}$ be
immediate values.

Now we can do rewriting such as
\begin{align*}
\Code{(if (lambda (a b) c) }
    &\Code{(if (not (< (+ 0 1 2) (/ 3 1))) atan (lambda (x) x)) +)}\\
{}\rulesto{} & \Code{(if (not (< (+ 0 1 2) (/ 3 1))) atan (lambda (x) x))}\\
\vdots\\
\rulesto{} & \Code{(if \#t atan (lambda (x) x))}\\
\rulesto{} & \Code{atan}
\end{align*}

\subsection{Instantiation}
The {\em variable instantiation rule\/} is:
\begin{quote}
\[\vrbl \rulesto \ival\]
when \vrbl\ is defined to be \ival.
\end{quote}

For example,
\begin{eqnarray*}
\lefteqn{\Code{(define y 7) (define x (+ 1 2)) (* x y)}}\\
{} & \rulesto & \Code{(define y 7) (define x (+ 1 2)) (* x 7)}\\
{} & \rulesto & \Code{(define y 7) (define x 3) (* x 7)}\\
{} & \rulesto & \Code{(define y 7) (define x 3) (* 3 7)}\\
{} & \rulesto & \Code{(define y 7) (define x 3) 21}
\end{eqnarray*}

Actually, to be used as a term rewriting rule at an arbitrary place in a
body, the instantiation rule must also include a technical specification
about changing defined names into ``fresh'' names\footnote{The problem is
that after instantiation, there are two copies of \ival---the original one
in the definition of \vrbl, and another at the place where \vrbl\ was
instantiated.  It may happen that some variable {\em within} \ival\ winds
up underneath a different definition in the second copy than it did in the
original.  This has to be prevented in order to mantain the requirement
that Scheme be statically scoped.}.  Fortunately, this technicality can
safely be ignored as long as we obey
\begin{quote}
{\bf The Lambda Body Rewriting Restriction}: {\em Don't instantiate into
the body of a lambda expression.}
\end{quote}
Real Scheme evaluation obeys the lambda body restriction.

\subsection{Lambda Applications and Renaming}

Scheme grammar allows definitions only in a sequence at the beginning of a
body.  Bodies can only appear by themselves at ``top-level,'' or as the
bodies of lambda expressions\footnote{A formal grammar for TRM Scheme is
attached as an Appendix for your reference.}.

When the lambda application rule creates new immediate
definitions\footnote{To obtain ``call-by-name,'' or ``normal order,''
behavior, we must relax the condition that the operands of the combination
be \ival's, allowing them instead to be arbitrary expressions.}, we just
stick them anyplace that is grammatical.  Definitions at the beginning of
a lambda body may also have to be moved after the lambda disappears.
So the form of the lambda application rule is:
\[\Code{((lambda (\vrbl_{1}\ldots) \defines\ \expr) \ival_{1}\ldots)} \rulesto
\expr\]
\begin{quote}
with the sequence
\[\Code{(define \vrbl_1 \ival_{1})}\ldots\defines\]
placed in the body above \expr\ at any position at which a sub-body may
begin.
\end{quote}
But watch out!  This time there is a naming problem we cannot avoid.

The scope, or binding, rules of a language determine how names are
associated with things named.  Scheme is a {\em statically} scoped
language (also called {\em lexically} scoped).  The purpose of static
scoping is to nsure that names of formals or names defined within an
expression can be ``kept private'' so they behave independently of names
outside the expression.  In this way, a programmer can choose names within
a program without concern for whether or how the same names may have been
used elsewhere.

For example, in Scheme, evaluation of the following body returns
the value 8, as we would expect:
\begin{lisp}
(define make-incrementer (lambda (n) (lambda (m) (+ m n))))
(define add2 (make-incrementer 2))
(define add3 (lambda (n) (inc (add2 n))))
(add3 5)
\end{lisp}

As the names suggest, \Code{add2} has the behavior of adding two to its
operand; similarly, \Code{add3} adds three.  Let's examine in detail how
our Substitution Model realizes this intended behavior.

The only rule applicable at the start is instantiatiation for
\Code{make-incrementer} or \Code{add3}.  Scheme would work on the
definitions at the beginning first, so let's do likewise and first
instantiate \Code{make-incrementer}:
\begin{lisp}
(define make-incrementer (lambda (n) (lambda (m) (+ m n))))
(define add2 ((lambda (n) (lambda (m) (+ m n))) 2))
(define add3 (lambda (n) (inc (add2 n))))
(add3 5)
\end{lisp}
It will be easier to follow this example if we now simplify the body by
dropping the no longer referenced definition---in this case, the
definition of \Code{make-incrementer}:
\begin{lisp}
(define add2 ((lambda (n) (lambda (m) (+ m n))) 2))
(define add3 (lambda (n) (inc (add2 n))))
(add3 5)
\end{lisp}
Lambda application in the definition of \Code{add2} creates a definition
of \Code{n}:
\begin{lisp}
(define add2 (lambda (m) (+ m n)))
(define n 2)
(define add3 (lambda (n) (inc (add2 n))))
(add3 5)
\end{lisp}
Now we can instantiate \Code{add3} and then drop its definition:
\begin{lisp}
(define add2 (lambda (m) (+ m n)))
(define n 2)
((lambda (n) (inc (add2 n))) 5)
\end{lisp}
Lambda application comes next, yielding:
\begin{lisp}
(define add2 (lambda (m) (+ m n)))
(define n 2)
(define n 5)
(inc (add2 n))
\end{lisp}

Now there is an obvious problem, because we have two definitions of
\Code{n} at the beginning of the block, which is ambiguous and indeed
violates Scheme grammar.  We handle this by renaming the newly defined
\Code{n} and the occurrences it defines, to some ``fresh'' name, say
\Code{n#1}:
\begin{lisp}
(define add2 (lambda (m) (+ m n)))
(define n 2)
(define n#1 5)
(inc (add2 n#1))
\end{lisp}
This expression is grammatical again, and now it is safe to instantiate
and garbage-collect \Code{add2}:
\begin{lisp}
(define n 2)
(define n#1 5)
(inc ((lambda (m) (+ m n)) n#1))
\end{lisp}

Notice that if we had not renamed \Code{n} to \Code{n#1} in this way, we
would have rewritten to
\begin{lisp}
(define n 2)
(define n 5)
(inc ((lambda (m) (+ m n)) n))
\end{lisp}
and the ambiguity of which occurrence of \Code{n} is bound to which value
becomes unresolvable\footnote{Actually, until the mid-1970's, all LISP
dialects resolved the ambiguity by choosing the ``nearest'' value of
\Code{n}, so that this example would have rewritten to \Code{(inc ((lambda
(m) (+ m 5)) 5))} and resulted in the value 11 instead of 8.  This method
of name management is called ``dynamic scope.''}.

So a more accurate statement of the {\em lambda application rule} is:
\[\Code{((lambda (\vrbl_{1} \ldots) \defines \expr) \ival_{1} \ldots)} \rulesto
\expr\]
\begin{quote}
with the sequence
\[\Code{(define \vrbl_1 \ival_{1})}  \ldots \defines\]
placed above \expr\ in any position in the body at which a sub-body may
begin, {\bf with defined variables freshly renamed as necessary}.
\end{quote}

\subsection{Garbage Collection}

``Garbage collection'' refers to the process whereby LISP-like systems
identify and recapture previously used, but no longer accessible, storage
cells.  The corresponding process in our TRM is dropping
unreferenced definitions, so we call this the {\em garbage collection
rule}:
\begin{eqnarray*}
\bod_1 & \rulesto& \bod_2,\\
\mbox{where $\bod_2$ is the } & \mbox{result} & \mbox{ of erasing garbage in $\bod_1$}.
\end{eqnarray*}
A subset $G$ of immediate definitions among the definitions occurring at
the beginning of a body is said to be {\em garbage in the body}, if none
of the variables left in the body after $G$ is erased were defined by $G$.

For example, in
\begin{lisp}
(define a (lambda () b))
(define b 3)
(define c (lambda () (* b d)))
(define d 4)
(+ 1 (a))
\end{lisp}
The definitions of \Code{c} and \Code{d} are {\em garbage} because
\Code{c}'s and \Code{d}'s don't occur anywhere outside their own
definitions.  The body can be garbage collected to be:
\begin{lisp}
(define a (lambda () b))
(define b 3)
(+ 1 (a))
\end{lisp}

\section{Uniqueness}

The full set of term rewriting rules has same the unique value
property as the simple algebraic rules:
\begin{quote}
\noindent{\bf The Unique Value Theorem}.  {\em There is at most one
primitive value that can be reached by successively rewriting a body using
the Scheme Term Rewriting rules above.}
\end{quote}

That's the good news.  The bad news is that the order in which rules
are applied {\em does} matter to avoid wasted time and space---even
infinite waste if rules are applied forever in useless places such as
the alternative branch of an \Code{if} whose test evaluates to
\Code{#t}.

We also observed that real Scheme evaluation obeys the lambda body
restriction.  There is no problem about this because of the
\begin{quote}
\noindent{\bf Lambda Body Safety Theorem}.  {\em If a body can be
rewritten into a primitive value by successive use of the Scheme Term
Rewriting rules above, then it can be rewritten to a primitive value while
obeying the lambda body rewriting restriction.}
\end{quote}

Of course by the Uniqueness Theorem, rewriting while obeying the lambda
body restriction will reach the {\em same} primitive value, if any, as any
other way of applying the rules.

The Uniqueness and Safety Theorems are by no means obvious.  (Their proof
is sometimes covered in the graduate course 6.840 on Semantics of
Programming Languages.)  There is a whole subdiscipline of Theoretical
Computer Science called Term Rewriting Theory which studies such
properties.

\section{Derived Expressions}

We have described above a ``kernel'' of Scheme which omits many familiar,
convenient Scheme constructs.  For example, we want to handle \Code{cond}
and \Code{let}.

Instead of extending the rewrite rules to handle these special forms
directly, another approach is to think of these extensions as
abbreviations, or ``syntactic sugar,'' for kernel expressions.  For
example,
\[
\Code{(let (($\vrbl_1$ $\init_1$)$\ldots\,$) \bod)}
\]
can be understood as an abbreviation for
\[
\Code{((lambda ($\vrbl_1\cdots\,$) \bod) $\init_1 \ldots\,$).}
\]
and
\begin{eqnarray*}
\Code{(cond } & \Code{($\test_{1}$ $\expr_{1}$)} \\*
              & \Code{($\test_{2}$ $\expr_{2}$)} \\*
              & \vdots \\*
              & \Code{(else $\expr_{n}$))}
\end{eqnarray*}
can be understood as an abbreviation for
\[
    \setlength{\arraycolsep}{0pt}
    \begin{array}{lllllllllllll}
    \Code{(if } & \rlap{\test_{1}} \\
                & \rlap{\expr_{1}} \\
                & \Code{(if } & \test_{2} \\
                &             & \rlap{\expr_{2}} \\
                &             & \vdots \\
                &             & \qquad \Code{(if } & \test_{n-1} \\
                &             &                    & \expr_{n-1} \\
                &             &                    & \expr_{n}\Code{)\ldots))}.
    \end{array}
\]
So we can specify the computations of derived expressions by
translating, or ``desugaring,'' them into kernel \expr's\footnote{These
translations are generally linear-time, one-pass, and yield a
kernel-\expr\ of size proportional to the original extended-\expr.  Real
Scheme interpreters and compilers typically carry out such translations.}.
The \RFS\ Report describes the translations above and others for \andsf's,
\orsf's, and several further forms.

\section{Lists and Symbols}

Scheme output notation for lists and symbols makes them look just like
expressions.  Using this notation in the TRM presents a problem: how do we
tell the difference between lists and combinations\footnote{The fact that
lists print out looking like expressions is generally considered a very
valuable feature in Lisp.  On the other hand, at least one famous
contemporary Computer Scientist has protested publicly that because of
this he couldn't learn Lisp---he could never figure out when to stop
evaluating expressions.}?  For example, is ``\Code{(+ 3 4)}'' a
combination---which should be rewritten to the syntactic value
\Code{7}---or is it a list of three elements---the procedure variable
\Code{+} (or perhaps it is the symbol ``\Code{+}'') followed by \Code{3}
and \Code{4}?  So the TRM instead ``simplifies'' lists into syntactic
values which are nested \Code{cons}'s of list elements.  For example, the
expression \Code{(list + 3 4)}, which Scheme prints out as
``\Code{([compiled arithmetic procedure +] 3 4)},'' would be rewritten in
our TRM into the expression
\[\Code{(cons + (cons 3 (cons 4 ())))}.\]
Similarly, {\em symbols\/} which print out as \Code{a} or \Code{+}
would be described in the TRM by the expressions \Code{(quote a)} or
\Code{(quote +)} to avoid confusing them with variables.  So
\Code{(list '+ 3 4)}, which Scheme prints out as ``\Code{(+ 3 4)},''
would would be rewritten in our TRM into the expression
\[\Code{(cons (quote +) (cons 3 (cons 4 ())))}.\]

With these notational conventions, it is a straightforward to handle
list structures in the TRM\footnote{This way of handling list works
  usefully until we begin ``mutating'' lists, at which point some more
  refined description of list structure would be needed.}.  Namely, we
add the appropriate procedure variables such as \Code{cons},
\Code{car} and \Code{cdr}, and regard any expression of the form
\[\bnf\Code{(cons \ival\ \ival)}\]
as an immediate value.  We don't even have to add a rewrite rule for
applications of \Code{cons}!  We do add some obvious rules for \Code{car}
and \Code{cdr}:
\begin{eqnarray*}
\Code{(car (cons \ival_{1} \ival_{2}))}
& \rulesto & \ival_{1} \\
\Code{(cdr (cons \ival_{1} \ival_{2}))}
& \rulesto & \ival_{2} \\
\end{eqnarray*}
The rules for \Code{cons}, \Code{car} and \Code{cdr} resemble the
primitive procedure rules in that they require that all the operands be
\ival's before the rule can be implied.  These {\em rule-specified
procedure variables} are, like primitive procedure variables, also treated
as \ival's.

Here are the remaining important rewriting rules about lists:
\begin{gather*}
\Code{(apply $E_{0}$ (cons $E_{1} \ldots$ (cons $E_{n}$ ())\ldots ))}
\rulesto \Code{($E_{0}\ E_{1}\ldots E_{n}$)}
\\[\bigskipamount]
\begin{aligned}
\Code{(pair? (cons \ival_{1} \ival_{2})} &\rulesto \Code{\#t}\\
\Code{(pair? \ival_{3})} &\rulesto \Code{\#f}\\
\end{aligned}\\
\text{if $\ival_{3}$ is not of
the form \Code{(cons \ival_{1} \ival_{2})}}
\\[\bigskipamount]
\begin{align*}
\Code{(null? ())}   & \rulesto \Code{\#t}\\
\Code{(null? \ival)} & \rulesto \Code{\#f}\\
\mbox{if \ival}  & \mbox{ is } \mbox{not \Code{()}.}
\end{align*}\\[\bigskipamount]
\begin{align*}
\Code{(list)} & \rulesto  \Code{()}\\
\Code{(list \ival_{1} \ldots)}  & \rulesto  \Code{(cons \ival_{1}
(list \ldots))}
\end{align*}
\end{gather*}

\section{Running the Substitution Model}

There is an implementation of the Substitution Model which you are welcome
to use.  It may help you understand how Scheme processes behave, and it
can also serve as a simple debugging aid.  Of course it is about four
orders of magnitude slower than Scheme, so don't expect it to be useful on
compute-intensive examples.

In the 6.001 Edwin editor, use {\tt M-x load-problem-set: 4} to load the
code for the Substitution Model.  You can generate a list of the steps in
the rewriting of an expression (in reverse order) by applying the
procedure \Code{smstep-list} to the quoted expression.  The order in which
rewrite rules are applied reflects Scheme evaluation order fairly
accurately.  To generate the list and print it nicely, apply the procedure
\Code{smeval} to the quoted expression.

For example, evaluate
\begin{lisp}
(smeval '((lambda (n) (+ 2 n)) 3))
\end{lisp}
to see expressions at selected steps as this lambda application
successively rewrote to \Code{5}.

A body beginning with one or more definitions is represented as a list of
the definitions with an expression at the end.  So evaluating,
\begin{lisp}
(smeval
 '((define (rec-factorial n)
     (if (<= n 0)
         1
         (* n (rec-factorial (dec n)))))
   (rec-factorial 6)))
\end{lisp}
will allow you to watch how this body rewrote to \Code{720}.

An expression printed out by \Code{smeval} at any point is a well-formed
Scheme expression which can be evaluated in Scheme and will give the same
final result as \Code{smeval}---at least if the final result is a number
or truth value\footnote{To evaluate a {\em body} printed by \Code{smeval}
when the body begins with definitions, it has to be made into a Scheme
expression.  If the body printed out is
\[\bnf \Code{(}\define_{1} \ldots \expr \Code{)}, \]
then in Scheme evaluate
\[\bnf \Code{((lambda () } \define_{1} \ldots \expr\Code{))}.\]}.

\subsection{Controlling Printout}

There are several utilities to control the output printed by \Code{smeval}.

The value returned by a call to \Code{smeval} is the \val\ at
which it successfully stops, or else an error message.  To be able to see
the final value in more familiar format, you should evaluate
\begin{lisp}
(define reversed-steps (smstep-list body))

(define final-body (body-or-info-of-step (car reversed-steps)))

(pp (printable-version final-body))
\end{lisp}

The procedure \Code{save-this-step?} determines which steps get saved on
the list generated by \Code{smstep-list} for printing by \Code{smeval}.
The default is to print more sparsely as the step-number grows.  To save
every step, evaluate
\begin{lisp}
(define (save-this-step? step-number body) #t)
\end{lisp}

The procedure \Code{garbage-collect-this-step?} can be used to force more
frequent garbage collections.  Its default arbitrarily imposes a garbage
collection every fortieth step.  To avoid such extra garbage collection
(which can slow things down a bit), evaluate
\begin{lisp}
(define (garbage-collect-this-step? step-number body) #f)
\end{lisp}

The procedure \Code{interrupt-smeval?} limits the number of rewriting
steps in an evaluation.  Its default is to abort evaluation after 600
steps.  You may want to do shorter runs.  For example, to set
\Code{smeval} to stop after 100 rewriting steps, evaluate
\begin{lisp}
(define (interrupt-smeval? step-number body) (> step-number 100))
\end{lisp}

{\bf Warnings}:
The code for the TRM implementation is written to be readable by
(ambitious) beginning 6.001 students, with major sacrifices in speed and
resilience for the sake of clarity.  As a consequence, \Code{smeval}
typically runs forever or crashes gracelessly on ungrammatical inputs.  It
is a good idea to test expressions by evaluating them in Scheme before
\Code{smeval}'ing them.

Edwin itself wedges horribly if the \Code{*scheme*} buffer overflows
(which may happen when its size is within a small factor of 100K
characters).  You don't want this to happen!  So be careful about doing
\Code{smeval} for long computations; instead save the list
\Code{smstep-list} generates and view it selectively.

\subsection{Bugs}

We don't know of any yet, but there surely are some.  Gratitude and lots
of 6.001 brownie points for first bug reports---email them to
\Code{6001-lecturers@ai.mit.edu}.

\section{Appendix: Grammar for Functional Scheme}

\subsection{Kernel Syntax}

\begin{bnf}
\begin{eqnarray*}
<define> &:=& "(define"\: <variable> <expression> ")"\\
<body>  &::=& <define_{1}>\ldots <expression>\\
        && {} \qquad \hbox{(Note: all defined variables must be distinct)}\\
\\
<expression> &::=& <variable> | <self-evaluating> | <symbol> | "()"\\
        && {}   | <combination> | <lambda expression> | <if>\\
\\
<self-evaluating>       &::=& <numeral> | <boolean>\\
<numeral>   &::=&   "0" | "-1" | "3.14159" | \ldots\\
<boolean>   &::=&   "#t" | "#f" \\
\\
<symbol>        &::=& "(quote " <variable> ")" | \Code{(quote $<keyword>$)}\\
\\
<combination>   &::=&   "(" <operator> <operand_{1}> \ldots ")"\\
<operator>   &::=&   <expression>\\
<operand>   &::=&   <expression>\\
\\
<lambda expression> &::=&  "(lambda ("<formals>") " <body> ")" \\
<formals>   &::=&   <variable_{1}>\ldots\\
        && {} \qquad \hbox{(Note: all \vrbl's must be distinct)}\\
\\
<if> &:=& "(if"\: <test> <consequent> <alternative> ")" \\
<test>   &::=&   <expression>\\
<consequent>   &::=&   <expression>\\
<alternative>   &::=&   <expression>\\
\\
<primitive procedure variable> &::=& "+" | "-" | "*" | "/" | "=" | "<" | "atan" | \dots\\
<rule-specified procedure variable> &::=& "null?" | "pair?" | "car" |
"cdr" | "cons" | "list" | "equal?" | "apply"\\
<keyword>   &::=& "define" | "quote" | "lambda" | "if"\\
<variable> &::=& \hbox{identifiers which are not $\bnf
        <self-evaluating>$ or $\bnf <keyword>$'s}\\
\end{eqnarray*}
\end{bnf}

\subsection{Derived Syntax}

\begin{bnf}
\begin{eqnarray*}
\expr &::=& \ldots | <derived expression>\\
<derived expression> &::=& <cond> | <let> | \ldots\\
<cond> &::=& "(cond"\: <clause_{1}> \ldots ")"\\
<clause> &::=& "(" <test> <expression>")" | "(else " \expr ")"\\
<let> &::=& "(let ("<binding_{1}> \ldots") " <body> ")" \\
<binding> &::=& "(" <variable> <init> ")"\\
<init> &::=& <expression>\\
%<begin> &::=& "(begin"\: \expr_{1} \ldots ")"\\
<define> &::=& \ \ldots\, | "(define ("<variable> <formals>")" <body>")"\\
%<primitive procedure variable> &::=& \ \ldots\, | "display" | "newline"\\
<keyword>  &::=&  \ \ldots\, | "cond" | "let" | "else" | \ldots\\
%"begin" | \ldots
\end{eqnarray*}
\end{bnf}

\subsection{Values}

\begin{bnf}
\begin{eqnarray*}
\pval &::=&  <self-evaluating> | <symbol> | "()"\\
\ival &::=& \pval | <lambda expression>\\
        && {} | <primitive procedure variable>\\
        && {} | <rule-specified procedure variable>\\
        && {} | "(cons "<immediate value>\ <immediate value>")"\\
<immediate define> &::=& "(define"\: <variable> <immediate value>")" \ldots\\
<value> &::=& <immediate define_{1}> \ldots <immediate value>\\
        && {} \qquad \hbox{(Note: all defined \vrbl's must be distinct)}\\
\end{eqnarray*}
\end{bnf}

\end{document}


\documentclass[12pt]{article}
\usepackage{fullpage,graphicx,psfrag,amsmath,amsfonts,verbatim}
\usepackage[small,bf]{caption}

\input defs.tex

\bibliographystyle{alpha}

\title{\LaTeX\ Style Guide for EE 364B}
\author{Stephen Boyd \and Ernest K. Ryu \and Neal Parikh}

\begin{document}
\maketitle

\begin{abstract}
This document lays out rules and guidelines for mathematical writing and
typesetting that you must follow for your project proposals, reports,
and the final exam, all of which \emph{must} be typeset in \LaTeX. The guidelines
here cover both the \LaTeX\ source as well as the output, so this PDF is
intended to be read alongside its own source code.

There are many well-known references on mathematical writing, but the
goal here is to briefly survey this topic and to lay out some rules specific to
this course. Parts of this document were inspired by or lifted from Halmos
\cite{Halmos:1970} and Knuth \cite{Knuth:1989}.
\end{abstract}

\newpage
\tableofcontents
\newpage

While you are writing, it is often useful to include
the table of contents so you can see the structure of your document,
even if you don't include it in the final version.

\section{Style guidelines}

You will likely find that attempting to write things out will reveal that you
were not as clear about your topic as you thought you were. John von
Neumann once said, ``There's no sense in being precise when you don't even know
what you're talking about,'' and Niels Bohr wrote, ``Never express yourself more
clearly than you can think.'' Keep these in mind.

Many respectable books follow similar rules, like
\cite{BoV:04},
\cite[p.~23]{Cover:1991},
\cite[p.~26]{Hastie:2001},
\cite[p.~21]{Sipser:2001},
\cite[p.~25]{Cormen:2001},
\cite[p.~15]{Rudin:1976},
\cite[p.~18]{Evans:2010},
\cite[p.~3]{Goldstein:1980}, and
\cite{Knuth:1973}.

\paragraph{Write good English.}
Always write good English, ``even'' when the subject is mathematics. This
includes correct grammar, word choice, punctuation, spelling, phrasing,
and common sense.
A classic on this topic, only slightly dated,
is Strunk and White \cite{SW:59}.

\paragraph{Keep the reader in mind.} Perhaps the most important principle of
good writing is to keep the reader in mind: What do they know so far? What do
they expect next and why? Do they have sufficient motivation for stated
results? As part of this, make sure you know what level of reader you are
writing for and stay consistent with that level. If the reader is expected to
know convex analysis, do not keep defining standard concepts like subgradients.

\paragraph{Write to allow skipping over formulas.}
Many readers will first read through the paper ignoring or skipping all but the
simplest formulas. Your sentences and overall paper should flow smoothly, and
make sense, when all but the simplest formulas are replaced by ``blah'' or a
similar placeholder.  As a related point, do not simply display a list of
formulas or equations in a row; tie the concepts together with a running
commentary.

\paragraph{Be precise with your language.}
The sentence ``Let $x^\star$ be the solution to the optimization
problem'' implicitly asserts that the solution is unique. If the solution is
not unique or need not be unique, write, ``Let $x^\star$ be a solution to the
optimization problem.'' Similarly, do not refer to ``solving'' an expression,
as this is meaningless.  You can solve an equation or set of equations,
evaluate an expression or function, or check that an equation or inequality
holds.

\paragraph{Use the editorial we when appropriate.}
The word ``we'' is often useful to avoid passive voice, which can
sometimes be awkward, or the use of ``I'' or
``one'', which should be avoided. However, be careful not to overuse
``we'', as it can become a very bad habit.
\begin{quote}
Often bad: We can see that Theorem 1 implies Corollary 2.\\
Good: Theorem 1 implies Corollary 2.
\end{quote}
In general, use whatever phrasing makes the sentence cleaner and less clunky.
To quote Strunk and White, ``Omit needless words.''

\paragraph{Punctuation in equations.}
An equation is part of a sentence, and you may need to include a comma or a period
at the end of an equation as a result, whether or not you are using inline or
display math style. For example:
\begin{quote}
    We next discuss how to solve the problem
    \[
        \begin{array}{ll}
            \mbox{minimize} & (1/2)\|Ax - b\|_2^2,
        \end{array}
    \]
    where $x \in \reals^n$ is the optimization variable.
\end{quote}

\paragraph{Don't start a sentence with a symbol.}
This hurts readability:
\begin{quote}
Bad: $f$ is smooth.\\
Good: The function $f$ is smooth.

Bad: $x^n - a$ has $n$ distinct zeros. \\
Good: The polynomial $x^n - a$ has $n$ distinct zeros.
\end{quote}
Similarly, don't start a sentence with a reference.

\paragraph{Use words to separate symbols in different formulas.}
If it might confuse the reader visually or in the actual
meaning of the sentence, use words to break apart formulas:
\begin{quote}
Bad: The sequences $x_1, x_2, \dots$, $y_1, y_2, \dots$ are Cauchy. \\
OK: The sequences $x_1, x_2, \dots,$ and $y_1, y_2, \dots,$ are Cauchy. \\
Good: The sequences $(x_i)$ and $(y_i)$ are Cauchy.

OK: The image of $S$ under $f$, $f(S) = \{ x \mid x \in S \}$, is convex. \\
Good: The image of $S$ under $f$, given by $f(S) = \{ x \mid x \in S \}$, is convex.
\end{quote}
Do not insert superfluous words if the meaning is clear.
\begin{quote}
Good: Consider the function $f + g + h$, where $f : \reals^n \to
\reals$, $g : \reals^m \to \reals$, and $h : \reals^p \to \symm^n$ are closed
proper convex.
\end{quote}

\paragraph{References.}
For internal references, use the \texttt{label} and \texttt{ref} commands.
\emph{Never} number or refer to an entity using a specific number,
as in ``Table~3.''
Refer to ``Table~\ref{t-ex1}'', ``\eqref{e-opt-prob}'' (an equation), and so on.
Only number equations that are important and should be emphasized or that you
specifically refer to elsewhere. Do not simply number all equations, and do not
number them randomly. A numbered equation draws the reader's attention, so it
should be used relatively sparingly. Use \verb+\S+ for section references, as in
\S\ref{s-content}.

For external references, you must use Bib\TeX. Use references like nouns or
footnotes:
\begin{quote}
Good: One useful reference is \cite{BoV:04}. \\
Good: Interested readers may refer to Boyd and Vandenberghe \cite{BoV:04}.
\end{quote}

Your Bib\TeX\ source must be correct.  Unfortunately, many systems that export
Bib\TeX\ entries export very poor ones.  Bib\TeX\ ignores the \texttt{*.bib}
file's capitalization for articles (but not books). To force capitalization,
you must wrap the letter with curly braces.  The hyphen (-), en dash (--), and
em dash (---) are distinct punctuation marks that serve different purposes.
(And the minus sign is different from all three.) When specifying a page range
in references, use the en dash. For an example of escaping and using the en
dash, look at our Bib\TeX\ entry for \cite{Tref:2008}.

\paragraph{Do not italicize English in math mode.}
Mathematical symbols should be typeset in math mode:
write $Ax=b$, not Ax=b. This said, subscripts or
superscripts that derive from English (or any human language) should not be
italicized. For example, write $f_\mathrm{best}$, not $f_{best}$. The exception
is subscripts based on a single letter: refer
to a point that is the center of some set as $x_c$, not $x_{\mathrm{c}}$.
Similarly, use commands for special functions: use $\sin(x)$,
$\log(x)$, and $\exp(x)$, not $sin(x)$, $log(x)$, or $exp(x)$.

A really heinous example would be the following:
\begin{quote}
Consider the problem
\[
\begin{array}{ll}
minimize & f(Ax - b) \\
\end{array}
\]
where x is the optimization variable and A and b are problem data.
\end{quote}

\paragraph{Spacing.}
A blank line ends a paragraph. You shouldn't leave a blank line between an
equation and the following text unless you intend the equation to end the
paragraph. Write:
\begin{quote}
\begin{verbatim}
The image of $S$ under $f$,
\[
    f(S) = \{ f(x) \mid x \in S \},
\]
is convex.
\end{verbatim}
\end{quote}
Inserting extra blank lines before \verb+\[+ or after \verb+\]+ will result in
bad typesetting. However, the following is fine, since a new paragraph is called for:
\begin{quote}
\begin{verbatim}
The image of $S$ under $f$ is defined as
\[
    f(S) = \{ f(x) \mid x \in S \}.
\]

We now turn to a different topic.
\end{verbatim}
\end{quote}
Using a tab before \verb+f(S)+ inside the equation environment is
optional, but helps readability in the source.  Similar rules should be
followed for other environments like \texttt{quote}; see the source of this
document.

\paragraph{Use of notation and jargon.}
The correct and appropriate use of notation and jargon takes time to master.
The following should give you a sense of what to think about:

\begin{itemize}
\item Don't use the same notation for two different things. Conversely, be consistent
about notation for the same thing mentioned in two places: don't
say ``$A_j$ for $1 \leq j \leq n$'' in one place and ``$A_i$ for $i=1,\ldots,n$''
in another, or use two different indices in summations over the same ranges.
Formally, the $i$ and $j$ are dummy variables with only that phrase as scope,
so these are technically correct, but it will confuse the reader.

\item It can be useful to choose names for indices so, for example, $i$
always varies from 1 to $m$ and $j$ always varies from 1 to $n$ (when
referencing something like the rows and columns of an $m \times n$ matrix).

\item Define all symbols before or near to where you use them.  A good rule is that
when you first use something, say, $X$, you should either define it immediately, or
within the paragraph.   There are a few cases where it is acceptable to define it
later, but you must say this explicitly, as in ``$X$ is the matrix of activation
levels, which we define below.''

\item A symbol like $f$ refers to a function, while $f(x)$ refers to a
function evaluated at a given point. Avoid sloppy writing like ``The function
$f(x)$ is convex.''
So-called `anonymous' functions defined inline are an exception to this rule,
as in ``the function $x^2 \cos x$ is a counterexample,'' though this should
be used only for simple functions.

\item Use typographic naming conventions like capital letters for sets, Greek
letters for dual variables, \emph{etc}.

\item Try to use mnemonic notation, so $x_c$ for a center point,
$c$ for a cost vector, $S$ for a generic set, $C$ for a convex set, $B$
for a ball, and so on. Note that there are conventions about
the use of different letters in mathematics that you should not ignore:
$i$, $j$, and $k$ are usually used for indices, $x$ through $z$ for
variables, $a$ through $d$ for constants, \emph{etc}.

\item Don't use symbols like $\forall$, $\exists$, and $\Rightarrow$; use the
corresponding words. These symbols are usually appropriate only in
formal logic.

\item Don't overuse subscripts. If you do not need to assign a subscript
to something, don't. For example, if you begin by defining a set as
$X = \{x_1, \dots, x_n\}$, then it is going to get annoying to refer to subsets
of $X$, since you will need double subscripts. If possible, it would be better
to not name the elements of $X$ and only refer to them when necessary, just
as, say, $x$ and $y$.

Beware especially of any topic in graph theory when it comes to this rule;
there are often \emph{many} ways to refer to relevant objects, and finding
reasonable notation can often get one half the way to getting a handle on the
problem itself.

\item Don't assign symbols to concepts that you never refer to, or can easily
refer to without:
\begin{quote}
Bad: Let $X$ be a compact subset of a space $Y$. If $f$ is a continuous
real-valued function over $X$, it has a minimum over $X$. \\
Good: A continuous real-valued function has a minimum over a compact set.
\end{quote}
Similarly, do not say ``The solution $x^\star$ is unique'' if you never need
to refer to $x^\star$ again; simply say that the solution is unique.
When you say ``The solution $x^\star$ is unique'' you are both stating a fact
\emph{and} entering the symbol $x^\star$ into the paper's symbol table and
the reader's working memory.
\end{itemize}

\paragraph{Sections.}
Use structures like \texttt{section}, \texttt{subsection},
\texttt{subsubsection}, and \texttt{paragraph} to organize the exposition;
never insert manual line breaks or page breaks for this purpose. In particular,
do not use line breaks to separate different topics. Do not use symbols in
article titles and ideally not even in section headers.

\paragraph{Use capitalization consistently.}
For section headers, capitalize the first letter, proper nouns, and lowercase
everything else, as in this document.  For references, write Figure 1, Algorithm 3,
Theorem 4, and so on.

\paragraph{Use the right commands.}
There are certain special commands in \LaTeX\ for notation that you otherwise
might attempt to write in an ad-hoc manner. If you do the latter, the typesetting
will be inferior. A few common examples:
\begin{itemize}
\item Norms are written $\|x\|$, not $||x||$.

\item For set-builder notation, use
$\{ x \in \reals \mid x \geq 0 \}$, not $\{x \in \reals | x \geq 0 \}$.

\item Make sure to use \verb+\left+ and \verb+\right+ when wrapping
taller expressions with parentheses, curly braces, brackets, and so on.
\begin{quote}
Bad: Let
\[
    x = \argmin_u (f(u) + \frac{1}{2}\|u - z\|_2^2).
\]
Good: Let
\[
    x = \argmin_u \left(f(u) + \frac{1}{2}\|u - z\|_2^2\right).
\]
\end{quote}

\item Use \verb+\ldots+ (lower dots) when the dots are surrounded by commas and
\verb+\cdots+ (center dots) when surrounded by other objects that have full
height, as in $x_1, x_2, \ldots, x_n$ and $x_1 + x_2 + \cdots + x_n$.
\end{itemize}
Similarly, make sure to use our conventions for standard mathematical objects
for this class; for example, use $\reals$, not $\mathbb{R}$, to denote the set
of real numbers. Use the \verb+\argmin+ and \verb+\argmax+ commands (as shown
above); do not write `arg min', since `argmin' is a single mathematical
operator.  These and other definitions are provided in \verb+defs.tex+.

\paragraph{Writing optimization problems.}
In this class, optimization problems can be introduced in the sentence as
nouns. For example, write as follows:
\begin{quote}
Consider the problem
    \begin{equation}
    \begin{array}{ll}
    \mbox{minimize}   & (1/2)\|Ax-b\|_2^2 + \lambda \|x\|_1 \\
    \mbox{subject to} & 0 \preceq x \preceq \ones \\
    & \|x\|_2 \leq 1,
    \end{array}
    \label{e-opt-prob}
    \end{equation}
where $x \in \reals^n$ is the optimization variable, and $A \in \reals^{m
\times n}$, $b \in \reals^m$, and $\lambda > 0$ are problem data.
\end{quote}
It is important to state which symbols refer to variables and which to problem data.

Be sure to carefully distinguish an optimization problem,
an algorithm for solving it, and its optimal value.
You \emph{solve} a problem (possibly, using a particular algorithm);
an optimization problem \emph{has} an optimal value;
and an optimization problem \emph{is} convex, or infeasible.
It does not make sense to talk about whether or not a problem converges.

\paragraph{Sentence-ending periods.}
\LaTeX\ assumes all periods followed by a space are sentence-ending periods.
Tell it otherwise when that is not the case.
\begin{quote}
Bad: Let $x_1,x_2,\ldots ,x_n$ be  i.i.d. normal random variables.\\
Good: Let $x_1,x_2,\ldots ,x_n$ be  i.i.d.\ normal random variables.
\end{quote}

\paragraph{Commas.}
Know when commas should appear inside or outside math environments:
\begin{quote}
Bad: Note that $a,b,$ and $c$ are nonnegative.\\
Good: Note that $a$, $b$, and $c$ are nonnegative.

Bad: We conclude that $x_1$, $x_2$, \dots, $x_n$ are decreasing.\\
Good: We conclude that $x_1, x_2, \ldots, x_n$ is decreasing.\\
Good: We conclude that $x_1>x_2> \cdots >x_n$.
\end{quote}

\paragraph{Tables and figures.}
Generally, do not refer to figures or tables in a
way that depend on their placement on the page; give them a \texttt{label}
and then use \texttt{ref} to refer to it. All figures and tables should have
captions.
\begin{quote}
Bad: Properties of several functions are shown in the table below.\\
Good: Properties of several functions are shown in Table~\ref{t-ex1}.
\end{quote}

\begin{table}
\begin{minipage}{\textwidth}
\centering
\begin{tabular}{|c|c|c|}
\hline
$f(x)$      & convex? & differentiable? \\ \hline
$\|x\|_2^2$ & Y       & Y \\
$\|x\|_1$   & Y       & N \\
$\|x\|_2^3$ & N       & Y \\
\hline
\end{tabular}
\caption{Example table}
\label{t-ex1}
\end{minipage}
\end{table}

\paragraph{\LaTeX\ in figures.}
Generally, mathematical symbols embedded in figures should be rendered by
\LaTeX. In Python, matplotlib has native support for \LaTeX\ rendering.
Otherwise, you can export the image in eps format and use the \LaTeX\ package
psfrag. See Figure~\ref{f-nopsfrag} and Figure~\ref{f-psfrag}. To use psfrag,
compile using
\begin{quote}
\begin{verbatim}
$ latex template.tex
$ dvipdf template.dvi
\end{verbatim}
\end{quote}
The psfrag package does not work with pdflatex.

\begin{figure}
\begin{center}
\includegraphics[width=0.6\textwidth]{figures/pwl_error_fbest_realize}
\end{center}
\caption{Original image without psfrag.}
\label{f-nopsfrag}
\end{figure}

\begin{figure}
\begin{center}
\psfrag{k}[t][b]{$k$}
\psfrag{fbest - fmin}[b][t]{$f_\mathrm{best}^{(k)} - f^\star$}
\psfrag{noise-free realize}{noise-free case}
\psfrag{realize1}{realization 1}
\psfrag{realize2}{realization 2}
\includegraphics[width=0.6\textwidth]{figures/pwl_error_fbest_realize}
\end{center}
\caption{Text replaced with equations using psfrag.}
\label{f-psfrag}
\end{figure}

\paragraph{Dialects.}
Be aware when you are writing in a mathematical dialect, like statistics,
machine learning, signal processing, control, finance, vision, information
theory, and so on.  Unless your intended audience is only from this one field,
try to avoid using dialect; try to write in such a way that a general reader
with a good understanding of basic mathematics can understand what you are
saying.  If you use terms like CVAR, hinge loss, Bode plot, or IIR filter,
you're speaking dialect. It's very easy to define these things so a person with
knowledge of basic mathematics can understand. Similarly, use standard variable
notation unless otherwise needed: $x$ for variables, $A$ for matrices, and so
on. Don't write a whole paper about solving a linear system you call $\Xi \beta =
\chi$ unless you really need to.

\paragraph{No rule is absolute.}
Break any of these rules rather than write anything nasty.

\section{Source code}

In this example, we show how to include code in a document.
\verbatiminput{example.m}
Here, we could now include some discussion about the code, include plots it
generates, and so on. Use your judgment about whether to start a new page
before displaying code, as it is helpful to be able to display all the code on
a single page. For very short snippets of code (just a few lines), it can help
readability to wrap it in a \texttt{quote} environment.

\section{Content}
\label{s-content}

Your report should use the following structure:

\begin{enumerate}
\item Begin with a brief paragraph that provides background, perhaps in
somewhat field-specific language.  Describe the problem you hope to address
in general terms.  For example:  ``We consider the problem of
reconstructing an image, given a blurred noisy version of it.'' Ideally,
this opening should be snappy and interesting, otherwise you will lose the
intended audience.

\item Transition (quickly) into a mathematical problem statement that
anyone with general mathematical training can look at and understand,
without any domain knowledge.

\item Outline the general approach. As a general comment here, it is of the
\emph{utmost importance} not to mix together the problem statement and the
method you intend to use to solve instances of that problem. You should cover
these in separate paragraphs, if not separate sections or subsections. This is
a key conceptual point, not just about writing.

Note that the approach is not merely the optimization algorithm you will
eventually use. For example, your approach to solving a nonconvex problem may
be to produce a particular convex relaxation whose solution will give a
heuristic solution for the original problem. Here, the relaxation is as much a
part of the approach as the algorithm you use to solve the relaxation.

\item If relevant, discuss properties of your overall approach, such
as convergence, rate of convergence, implementation details, and so on.
This could be as simple as saying that you use CVX,
or something more involved for, say, a distributed ADMM implementation.
Make sure you explain what machine and software you used.

\item If relevant, present some numerical experiments. If the focus is on an
algorithm, it is important to
thoroughly describe the problem data and settings of any algorithm parameters
(step sizes, stopping criteria, and so on). You should include number of
iterations to convergence, wall-clock time to convergence, residuals at
convergence, and any other related metrics. If appropriate, compare your method
to some relevant baseline, like CVX.
If the focus is on solving a practical problem, describe the
problem instance (or instances) solved, where the data came from, and so on.
The general problem statement should have been stated before, so when you present
the numerical example, you should not need to define a new problem.
For example:
\begin{quote}
We now consider a specific instance of the index tracking problem~(13).  We
have $n=100$ assets, with daily return data from January 2005 to January 2012,
all obtained from Google Finance.  The transaction cost parameter $\kappa$ was
set to $0.002$, \emph{i.e.}, 20 basis points, which is consistent with typical
transaction costs in practice.
\end{quote}

Typically you would describe the actual \emph{results} in a different paragraph.

\item If your original problem is in a particular field, make sure to try to
pause at various points in the exposition to provide interpretations of the
mathematical properties, approach, or numerical results back in the original
domain.

\item Briefly conclude and summarize the high-level points.
\end{enumerate}

\section*{Acknowledgments}

This is an example of an unnumbered section.

\newpage
\bibliography{template}

\end{document}


\documentclass{article}
\usepackage{parskip}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{listings}

\setlength{\parindent}{0cm}

\begin{document}

\lstset{language=Haskell, frame = single}

\title{CPSC 449 - Haskell}
\author{Andrew Helwer}
\date{Winter 2011}
\maketitle

\section{Programming Paradigms}

\begin{itemize}
\item A programming paradigm determines how you will solve a given problem
\item Imperative programming:
\begin{itemize}
\item Has a global, mutable state
\item Commands mutate the global state in some way
\item A program is a sequence of commands
\item Repetition is achieved through iteration
\item Example languages: Pascal, Fortran, Algol, C, ADA, Python
\end{itemize}
\item Object-oriented programming:
\begin{itemize}
\item Imperative programming with data abstraction
\item Example languages: C++, Java, Smalltalk, C$\#$, Python
\end{itemize}
\item Functional programming:
\begin{itemize}
\item Uses evaluation of expressions instead of execution of commands
\item No global state
\item Repetition is achieved through recursion
\item Example langauges: Haskell, ML, Scheme, Lisp
\end{itemize}
\item Logic programming:
\begin{itemize}
\item Describes result in terms of attributes and constraints
\item Complete opposite of imperative programming
\item Example languages: Prolog, G\"{o}del
\end{itemize}
\end{itemize}

\section{Haskell Basics}

\begin{itemize}
\item Function names start with a lowercase letter, types with an uppercase:
\begin{lstlisting}
name :: Type
\end{lstlisting}
\item Multiple parameters may also be defined (Type3 is the returned type):
\begin{lstlisting}
name :: Type1->Type2->Type3
\end{lstlisting}
\item Functions are implemented as follows:
\begin{lstlisting}
name args = body
\end{lstlisting}
\item Pattern matching is one way of enabling conditional function behaviour:
\begin{lstlisting}
name valA = valB
name valC = valD
\end{lstlisting}
\item Pattern matching is checked sequentially and returns if a match is found
\item Underscore (\_) matches arguments not used in the return value expression
\item To specify function behaviour for a collection of values, guards are used:
\begin{lstlisting}
name arg1, arg2
	| (f arg1 arg2)	= arg1
	| otherwise		= arg2
\end{lstlisting}
\item The standard library in Haskell is known as Prelude
\item Modules may be defined by placing the following in a Haskell file:
\begin{lstlisting}
module ModuleName where
\end{lstlisting}
\item Modules may also be imported into other modules:
\begin{lstlisting}
import ModuleName
\end{lstlisting}
\item It is sometimes necessary to override a Prelude function with your own:
\begin{lstlisting}
import Prelude hiding (name)
\end{lstlisting}
\item Logical operators on Bools:
\begin{itemize}
\item And: $\&\&$
\item Or: $||$
\item Not: not
\end{itemize}
\item Ordering operators on Ints:
\begin{itemize}
\item Less than: $<$
\item Greater than: $>$
\item Equal to: $==$
\item Not equal to: $/=$
\item Less than or equal to: $<=$
\item Greater than or equal to: $>=$
\end{itemize}
\end{itemize}

\section{Evaluation of Expressions}

\begin{itemize}
\item Every subexpression of an expression is called a redex
\item Every evaluation step reduces a redex to a simpler but equivalent form
\item Haskell has lazy evaluation, so expressions are expanded before reduction:
\begin{align*}
&23 - (\text{double }(3+1)) \\
&\rightsquigarrow 23 - (2*(3+1))            & \text{double} \\
&\rightsquigarrow 23 - (2*4)                & \text{arithmetic} \\
&\rightsquigarrow 23 - 8                    & \text{arithmetic} \\
&\rightsquigarrow 15                        & \text{arithmetic}
\end{align*}
\item In the above, double was evaluated on (3+1) before (3+1) was evaluated
\item A slightly different process is followed to evaluate functions with
guards:
\begin{align*}
&\text{maxThree  6 (4+3) 5} \\
&\text{?? } 6 >= (4+3) \text{ \&\& } 6 >= 5 		&\text{check maxThree.1}\\
&??\rightsquigarrow 6 >= 7 \text{ \&\& } 6 >= 7 	&\text{logic} \\
&??\rightsquigarrow \text{False } \&\& \text{ True} &\text{logic} \\
&??\rightsquigarrow \text{False } 					&\text{logic} \\
&\text{?? } 7 >= 5 									&\text{check maxThree.2} \\
&??\rightsquigarrow \text{True } 					&\text{logic}	\\
&\rightsquigarrow 7									&\text{maxThree.2} \\
\end{align*}
\end{itemize}

\section{Tuples and Lists}

\begin{itemize}
\item Tuples are composed of $n$ values of certain (possibly different) types:
\begin{lstlisting}
type Tuple = (Type1,Type2,Type3)
\end{lstlisting}
\item Elements in a pair tuple may be accessed using fst and snd
\item Lists are composed of an arbitrary number of values of a single type
\item The list constructor [ ] is an element of every list type
\item The operator ++ is used to concatenate two lists together ([a]++[b])
\item The operator : is used to prepend some element to a list (a:[b])
\item The operator !! returns the nth element of the list (xs!!n)
\item Prelude list functions:
\begin{itemize}
\item concat: concatenates a list of lists into a single list
\item length: returns the number of elements in the list
\item head, last: returns the first or last element of the list
\item tail, init: returns all but first or last elements of the list
\item take, drop: returns or removes the first n elements of the list
\item splitAt: splits the list into a pair tuple of lists at the nth element
\item reverse: reverses the order of the elements in the list
\item zip, unzip: turns a pair of lists into a list of pairs or vice versa
\item and, or: returns the conjunction or disjunction of a list of booleans
\item sum, product: returns the sum or product of a list of numerics
\end{itemize}
\item List comprehension generates a list from some other list xs:
\begin{itemize}
\begin{lstlisting}
[(f n) | n<-xs, (g n)]
\end{lstlisting}
\item Generation: n $<$\textemdash xs generates all elements of xs
\item Test: (g n) tests every $n$ in xs for a certain condition
\item Transform: (f n) transforms every $n$ in xs such that (g n) is true
\end{itemize}
\end{itemize}

\section{Recursion in Haskell}

\begin{itemize}
\item Instead of iteration, repetition is achieved through recursion in Haskell
\item Primitive recursion:
\begin{itemize}
\item Composed of two cases - base case and recursive case
\item Recursive case calls function with smaller input
\item Termination occurs when base case is reached
\item Primitive recursion is only applicable when using greedy algorithms
\end{itemize}
\item There are three fundamental patterns of primitive recursion:
\begin{itemize}
\item Accumulation: combine elements of a list using some operation
\item Transformation: map every element of a list to a different value
\item Selection: generate a subset of a list according to some restriction
\end{itemize}
\item General recursion:
\begin{itemize}
\item May have more than one base case
\item May recurse on multiple arguments
\item More difficult to prove correctness and termination
\item Any algorithm may be implemented using general recursion
\item Every primitive recursive function is a general recursive function
\end{itemize}
\end{itemize}

\section{Defining Functions Over Lists}

\begin{itemize}
\item In actuality lists are defined $x_1:x_2:\ldots:x_n:[\:]$
\item This easily allows primitive recursion to be used on lists
\item Patterns are one of the following:
\begin{itemize}
\item Literal value: True, 0, etc.
\item Variable: x, xs, etc.
\item Wildcard: (\_)
\item Tuple pattern: $(p_1,\ldots,p_n)$ where $p_1,\ldots,p_n$ are patterns
\item Constructor applied to patterns: (x:xs)
\end{itemize}
\item Pattern matching is used to decide which operations to perform on a list:
\begin{lstlisting}
name :: [Type]->[Type]
name [] 		= []
name (x:xs)
	| (f x)		= x:(name xs)
	| otherwise 	= (name xs)
\end{lstlisting}
\item The list constructor [ ] is the base case, with : used in the recursive
case
\item The case construction may also be used:
\begin{lstlisting}
name :: [Type]->[Type]
name xs
    = case (f xs) of
	[] -> []
	(y:ys) -> y:(name ys)
\end{lstlisting}
\item Local definitions may be created inside a function to increase simplicity:
\begin{lstlisting}
name :: [Type]->[Type]
name xs	= (f ys zs)
	where
	ys = (g xs)
	zs = (h xs)
\end{lstlisting}
\end{itemize}

\section{Structural Induction}

\begin{itemize}
\item Proving total correctness requires proving the following:
\begin{itemize}
\item Partial correctness: assuming termination, output is correct
\item Termination: the function terminates on all valid input
\end{itemize}
\item Termination is guaranteed with primitive recursive functions
\item Structural induction thus proves total correctness
\item Structural induction - show $P(ys)$ holds for all finite lists $ys$:
\begin{itemize}
\item Show the base case $P([\:])$ holds
\item Show the inductive step $P(xs) \Rightarrow P(x:xs)$ holds
\end{itemize}
\item Strengthening the inductive hypothesis is a good strategy in some cases
\item Note that structural induction is distinct from mathematical induction
\end{itemize}

\section{Higher-Order Functions}

\begin{itemize}
\item A first-class object possesses the properties such that it:
\begin{itemize}
\item May be passed as an argument
\item May be returned as a function value
\item May be stored in a data structure
\end{itemize}
\item Functions are first-class objects in functional languages
\item A higher-order function of a functional language is a function that:
\begin{itemize}
\item Accepts function arguments
\item Returns function values
\end{itemize}
\end{itemize}

\section{Functions as Arguments}

\begin{itemize}
\item Functions in Haskell may be passed as arguments to other functions:
\begin{lstlisting}
f :: Type1->Type2
g :: (Type1->Type2)->Type3
\end{lstlisting}
\item In the above, f could be passed as an argument to g
\item There are several higher-order functions implementing recursion patterns
\item Fundamental pattern of recursion: Accumulation
\begin{itemize}
\begin{lstlisting}
foldr :: (a->b->b)->b->[a]->b
\end{lstlisting}
\item Accepts a function as input and folds folds it between list elements
\item foldr1 does not need an identity element but fails on empty lists
\end{itemize}
\item Fundamental pattern of recursion: Transformation
\begin{itemize}
\begin{lstlisting}
map :: (a->b)->[a]->[b]
\end{lstlisting}
\item Accepts a function as input and applies it to every element of the list
\end{itemize}
\item Fundamental pattern of recursion: Selection
\begin{itemize}
\begin{lstlisting}
filter :: (a->Bool)->[a]->[a]
\end{lstlisting}
\item Constructs a new list from elements satisfying the input function
\end{itemize}
\end{itemize}

\section{Functions as Values}

\begin{itemize}
\item Composition of functions in Haskell is defined by (.) :
\begin{lstlisting}
f = g . h
\end{lstlisting}
\item The above would first apply any input to f to h, then g
\item (.) is therefore defined as:
\begin{lstlisting}
(.) :: (b->c)->(a->b)->(a->c)
\end{lstlisting}
\item The type of the second function must match the argument type of the first
\item The function id is defined as follows:
\begin{lstlisting}
id :: a->a
id a = a
\end{lstlisting}
\item Since f . id == f, id can be a base case for some recursive functions
\item Consider the following, which returns a function applied $n$ times:
\begin{lstlisting}
iter :: Int->(a->a)->(a->a)
iter n f = foldr (.) id (replicate n f)
\end{lstlisting}
\item The above unifies the concept of a function being a first-class object
\item We can also use the where construction to return functions as values:
\begin{lstlisting}
f :: Int->(Int->Int)
f x	= g
	where
	g y = x+y
\end{lstlisting}
\item Lambda notation is a simpler way of defining a function to return:
\begin{lstlisting}
f :: Int->(Int->Int)
f x = (\y -> x+y)
\end{lstlisting}
\item Lambda-defined functions are known as anonymous functions
\item Any function accepting two or more arguments may be partially applied:
\begin{lstlisting}
multiply :: Int->Int->Int
multiply x y = x*y

doubleAll :: [Int]->[Int]
doubleAll = map (multiply 2)
\end{lstlisting}
\item In actuality, every function in Haskell takes exactly one argument
\item The partially applied function is then applied to the other arguments
\end{itemize}

\section{Overloading and Type Classes}

\begin{itemize}
\item Polymorphic functions have the same behaviour for all types
\item Overloaded functions act differently for each type
\item The set of types over which a function is defined is called a type class
\item Members of a type class are called instances of that type class
\item A polymorphic function may be constrained to the type class Eq as follows:
\begin{lstlisting}
f :: Eq a => a -> a -> Bool
f x y = (x==y)
\end{lstlisting}
\item Since f is defined only for instances of Eq, (==) is always defined in f
\item The part before the $=>$ is called the context of the function
\item Multiple constraints on different types may be levelled in the context
\item Custom classes may be declared as follows:
\begin{lstlisting}
class Name a where
	f :: a -> b
	g :: a -> c
\end{lstlisting}
\item The declaration defines the name of the class and then the signature
\item A type is an instance of the class if the signature functions are defined:
\begin{lstlisting}
instance Name Int where
	f x = x
	g x = (h x)
\end{lstlisting}
\item Signature functions may be defined in terms of each other by default
\item Classes may also derive from other classes; consider the Ord class:
\begin{lstlisting}
class Eq a => Ord a where
	(<), (<=), (>), (>=)	:: a -> a -> Bool
	max, min		:: a -> a -> a
	compare			:: a -> a -> Ordering
\end{lstlisting}
\item The Ord class inherits all the operations of the Eq class
\end{itemize}

\section{Built-in Haskell Classes}

\begin{itemize}
\item Equality (Eq):
\begin{lstlisting}
class Eq a where
 (==), (/=) :: a -> a -> Bool
\end{lstlisting}
\item Ordering (Ord):
\begin{lstlisting}
class (Eq a) => Ord a where
	(<), (<=), (>), (>=)	:: a -> a -> Bool
	max, min		:: a -> a -> a
	compare			:: a -> a -> Ordering
\end{lstlisting}
\item Enumeration (Enum):
\begin{lstlisting}
class (Ord a) => Enum a where
	toEnum		:: Int -> a
	fromEnum	:: a -> Int
	enumFrom	:: a -> [a]
	enumFromThen	:: a -> a -> [a]
	enumFromTo	:: a -> a -> [a]
	enumFromThenTo	:: a -> a -> a -> a -> [a]
\end{lstlisting}
\item Bounded types (Bounded):
\begin{lstlisting}
class Bounded a where
	minBound, maxBound :: a
\end{lstlisting}
\item From values to strings (Show):
\begin{lstlisting}
class Show a where
	showsPrec	:: Int -> a -> ShowS
	show		:: a -> String
	showList	:: [a] -> ShowS
\end{lstlisting}
\item From strings to values (Read):
\begin{lstlisting}
class Read a where
	read	:: String -> a
\end{lstlisting}
\end{itemize}

\section{Algebraic Types}

\begin{itemize}
\item Algebraic types are generalized language constructs
\item The most basic algebraic type is the enumerated type:
\begin{lstlisting}
data Bool = True | False
\end{lstlisting}
\item Enumerated types have values limited to their explicit definition
\item True and False are the constructors of type Bool
\item Product types amalgamate other types:
\begin{lstlisting}
data People = Person Name Age
\end{lstlisting}
\item Person is a constructor for People, and may be represented thus:
\begin{lstlisting}
Person :: Name -> Age -> People
\end{lstlisting}
\item A product type may have multiple constructors
\item An algebraic type can be defined to be an instance of any class
\item The system may be asked to supply instantiations of classes as follows:
\begin{lstlisting}
data Season = Spring | Summer | Autumn | Winter
		deriving (Eq, Ord, Show, Read)
\end{lstlisting}
\item Defining algebraic types recursively allows for much greater expression
\item Consider the recursive algebraic type of a list of integers:
\begin{lstlisting}
data IntList = EmptyList | ConsPair Int IntList
\end{lstlisting}
\item In the above, EmptyList is [ ] and ConsPair is equivalent to (:)
\item The list $[1,2,3]$ would be represented thus:
\begin{lstlisting}
(ConsPair 1 (ConsPair 2 (ConsPair 3 EmptyList)))
\end{lstlisting}
\item Constructors may also be used in infix form:
\begin{lstlisting}
(1 'ConsPair' (2 'ConsPair' (3 'ConsPair' EmptyList)))
\end{lstlisting}
\item Constructors may also be defined and then used in infix form sans quotes:
\begin{lstlisting}
data IntList = EmptyList | Int :ConsPair: IntList
\end{lstlisting}
\item Two mutually recursive algebraic types use each other in their definition
\item Polymorphism may also be used when defining algebraic types:
\begin{lstlisting}
data List a = EmptyList | ConsPair a IntList
\end{lstlisting}
\end{itemize}

\section{Induction on Algebraic Types}

\begin{itemize}
\item For structural induction over an algebraic type:
\begin{itemize}
\item Construct a base case for each nonrecursive constructor
\item Construct an inductive hypothesis for each recursive constructor
\end{itemize}
\item If a constructor recurses on multiple values, assume their conjunction
\end{itemize}

\section{Lazy Evaluation}

\begin{itemize}
\item Expressions in Haskell are not evaluated until they are needed
\item If expressions are not needed, they will not be evaluated at all
\item A duplicated expression is never evaluated more than once
\item Expressions are evaluated from outside in and left to right
\item A construct taking advantage of this is infinite lists
\item An infinite list is defined but only evaluated to $n$ when requested
\end{itemize}

\end{document}


\documentclass[11pt]{article}
\usepackage{uvatoc} % replace this line with the one below for your submission
%\usepackage[response]{uvatoc}

\begin{document}

\makeheader

\makemytitle{Problem Set 1: (Un)Natural Numbers}
\submitter{TODO: replace this with your name (and computing id)}
\due{4:19pm, Friday, 13 September}

\directions{
This assignment is designed to develop your skills with formal definitions and provide some practice with inductive reasoning.

\collaboration{You should do this assignment by yourself and submit your own answers. You may discuss the problems with anyone you want and it is also fine to get help from anyone on problems with LaTeX or Jupyter/Python. You are permitted to use any resources you find for this assignment. You should note in the {\em Collaborators and Resources} box below the people you collaborated with and any external resources you used (you may exclude resources you used exclusively for help with LaTeX or Jupyter/Python.}
}

\collaborators{TODO: replace this with your collaborators and resources (if you did not have any, replace this with {\em None})}

\directions{
This problem set has two parts, one of which should be completed by writing your answers in the `ps1.tex` LaTeX template, and the other in the PS1 Jupyter notebook. As with Problem Set 0, you will submit (in collab) both a PDF file with your answers to the questions in this template, and your Jupyter notebook.

To get started with this assignment, follow directions similar to those from ps0:

\begin{enumerate}
\item Download the Problem Set 1 template from: \url{https://uvatoc.github.io/ps/ps1.zip}
\item In Overleaf, click on \keyword{New Project} in Overleaf and select \keyword{Upload Project} from the menu.
\item Click \keyword{Select a .zip file} and then select the \keyword{ps1.zip} file you downloaded in step 1.
\end{enumerate}

In the left side of the browser, you should see a file directory containing \keyword{ps1.ipynb}, a Jupyter notebook that you'll use in the second part (but shouldn't edit or view in Overleaf), \keyword{ps1.tex}, the template you will modify for this problem set, and \keyword{uvatoc.sty}, a style file that defines useful macros for cs3102 (you are welcome to look at this file, but should not need to modify it). You can click on \keyword{ps1.tex} to see the LaTeX source for this file.

\shortsection{LaTeX Template} As with ps0, the first thing you should do in \keyword{ps1.tex} is set up your name as the author of the submission by replacing the line, \texttt{\textbackslash submitter\{TODO: your name\}}, with your name and UVA id, e.g., \texttt{\textbackslash submitter\{Grace Hopper (gmh1a)\}}.

Before submitting your \keyword{ps1.pdf} file, also remember to:
\begin{itemize}
\item List your collaborators and resources, replacing the TODO in {\texttt{\textbackslash collaborators\{TODO: replace ...\}}} with your collaborators and resources. (Remember to update this before submitting if you work with more people.)

\item Replace the second line in \keyword{ps1.tex}, \texttt{\textbackslash usepackage\{uvatoc\}} with \texttt{\textbackslash usepackage[response]\{uvatoc\}} so the directions do not appear in your final PDF.
\end{itemize}
}

\begin{problem}
Induction Practice
\end{problem}
Prove that for any natural number $n\geq 2$, $n! < n^{n}$.

\begin{directions}
Note: For this problem (and any other problems where we don't explicitly state that you should use a particular definition), you can use the intuitive informal definition of natural numbers, and assume all of the familiar operations are defined and behave as expected. \end{directions}

\begin{problem}
Higher Induction Practice
\end{problem}
Prove that any binary tree of height $h$ has at most $2^{h-1}$ leaves.

\begin{directions}
Note: We haven't defined a \emph{binary tree} (and the book doesn't). An adequate answer to this question will use the informal understanding of a binary tree which we expect you have entering this class, but an excellent answer will include a definition of a binary tree and connect your proof to that definition.
\end{directions}

\begin{problem}
Addition is Commutative
\end{problem}
\begin{directions}
For this problem, we will use the successor definition of Natural Numbers (from Class 2 and 3):

\begin{definition}[Natural Numbers]
\normalfont
We define the \emph{Natural Numbers} as:
\begin{enumerate}
\item {\bf 0} is a Natural Number.
\item If $n$ is a Natural Number, {\bf S}($n$) is a Natural Number.
\end{enumerate}
\end{definition}
We will use this definition of addition (from class 3):
\begin{definition}[Sum]
\normalfont
The \emph{sum} of two Natural Numbers $a$ and $b$ (denoted as $a + b$) is defined as:
\begin{enumerate}
\item If $a$ is $\textbf{0}$, then $a + b$ is $b$.
\item Otherwise, $a$ is $\textbf{S}(p)$ for some Natural Number $p$, and $a + b$ is $\textbf{S}(p + b)$.
\end{enumerate}
\end{definition}
\end{directions}

Prove that addition (as defined above) is \emph{commutative} (that is, for all Natural Numbers $a$ and $b$, $a + b$ is $b + a$).
\directions{
Note that what ``is'' means here is they are exactly the same representation (we are not using $=$, since we haven't defined it for our number representation). You can think of all the operations we have defined as just manipulating strings of symbols, and ``$x$ is $y$'' meaning that $x$ and $y$ are exactly the same sequences of symbols.
}

\begin{problem}Countable Programs\end{problem}
\directions{
Prove that the set of all Python programs that you can execute on your laptop is \emph{countable}.
}

\vbox{ % This is to avoid an awkward page split
\begin{problem}Countable Graphs\end{problem}
\directions{
The book defines an \emph{undirected graph} (Definition 1.3). We modify this by adding one word to define a \emph{undirected finite graph}:
\begin{definition}[Undirected finite graph]
\normalfont
An undirected finite graph $G = (V, E)$ consists of a \emph{finite} set $V$ of vertices and a set $E$ of edges. Every edge is a size two subset of $V$.
\end{definition}}

Prove that the set of all undirected finite graphs is \emph{countably infinite}.
} % close vbox

\begin{problem}Uncountable Sets\end{problem}

($\star$)\footnote{When a problem is marked with a $\star$, it means we think this problem is challenging enough that students who are not able to solve it well can still get ``full credit'' (i.e., \emph{gold star}) for the assignment without submitting a good answer to the problem. We still hope everyone will attempt these problems and learn from trying to solve them, but you shouldn't get overly frustrated if you are not able to solve a $\star$ problem.}
Prove that the set of all undirected graphs (using the book's Definition 1.3, without the constraint that $V$ is finite that was added for the previous problem) is not countable.  (Note: be careful in any argument that you make that the graphs you are counting as actually \emph{different}. The nodes on the graph have no labels, so the only way for two graphs to be different is if they have different structure.)

% Your answer for problem here

\directions{
\section{Jupyter Problems}

The \keyword{ps1.zip} file includes \keyword{ps1.ipynb}, a Jupyter notebook.

To run this notebook, execute:
\begin{quote}
\texttt{jupyter notebook ps1.ipynb}
\end{quote}

The notebook contains additional problems and starting code for this assignment. Follow the directions there. Like for Problem Set 0, you will edit the provided \keyword{ps1.ipynb} notebook, and submit your completed jupyter notebook as your assignment.
}

\end{document}


\section{The structure of the thesis}

There should be 5--8 numbered chapters in a thesis, including
Introduction and Conclusion.  If necessary, you can use sections
and subsections to give the thesis a more fine-grained structure.

The chapters that lie between Introduction and Conclusion are
collectively called the \textit{body} of the thesis.  It is
often said to start with a \textit{background}, which is then
followed either by a \textit{main theorem}, a \textit{constructive part}
or an \textit{empirical part}.

Instead of simply listing headings of different levels it is recommended to let every
heading be followed by at least a short passage of text.

Headings should reflect the content of the coming part (chapter, section).

\subsection{Background}
\label{background}

The goal of the background part of a thesis is to develop the
theoretical background required in the thesis.  The idea is that a
reader of the thesis should be able to understand all the special
concepts and methods used in the thesis.
A good thesis also gives well-argued reasons for why exactly these
concepts and methods are in use in the thesis (with the main
alternatives given in the literature mentioned).

The best way to present and use of the theoretical background depends on
what the thesis is about. The background part of a
fully mathematical work differs considerably from the background part of a quantitative or qualitative
empirical study.

Some suggestions:
\begin{itemize}
\item In a fully mathematical (theoretical) thesis this chapter usually introduces the
mathematical background, general theory that is the setting of your contribution.
\item In an empirical thesis it is usually chapter where you describe background of the problem, the
methodology or explain the method(s) you will use to address the main problem
of your thesis.
\end{itemize}

Reading other thesis of the same type will give you a good impression
of what is required of your own thesis.

\subsection{Main contribution}

The background part is followed by your contribution:
\begin{itemize}
\item In a fully mathematical (theoretical) thesis it is usually a sequence of
  definitions and lemmas of your own devising, which then culminate in
  the proof of your main theorem.
\item In an empirical thesis it is a set of empirical results obtained
  by applying a empirical research method.
\end{itemize}

\subsection{Experimental part}

In this part your results (theorems or new methods) are validated. This often means simulation, where your results are compared with other previous results.

You should present your contribution with precision, giving reasons
for the choices you have made.  You should follow the best practices
of the research tradition you are using.