\documentclass[]{article}

% ------
% Fonts and typesetting settings
\usepackage[sc]{mathpazo}
\usepackage[T1]{fontenc}
\linespread{1.05} % Palatino needs more space between lines
\usepackage{microtype}
\usepackage{amsmath}

% ------
% Page layout
\usepackage[hmarginratio=1:1,top=30mm,bottom=30mm,columnsep=20pt]{geometry}
\usepackage[font=it]{caption}
\usepackage{paralist}
%\usepackage{multicol}

\usepackage{graphicx}
\usepackage{color}
\usepackage{tabularx}

%\usepackage{wrapfig}

\usepackage{capt-of}

% \usepackage[ngerman]{babel}

% ------
% Lettrines
\usepackage{lettrine}

% ------
% Abstract
\usepackage{abstract}
	\renewcommand{\abstractnamefont}{\normalfont\bfseries}
	\renewcommand{\abstracttextfont}{\normalfont\small\itshape}

% ------
% Titling (section/subsection)
\usepackage{titlesec}
\renewcommand\thesection{\Roman{section}}
\titleformat{\section}[block]{\large\scshape\centering}{\thesection.}{1em}{}

% ------
% Header/footer
\usepackage{fancyhdr}
	\pagestyle{fancy}
	\fancyhead{}
	\fancyfoot{}
	\fancyhead[C]{Post-quantum cryptography $\bullet$ Winter 2018/19 $\bullet$ RheinMain University of Applied Sciences}
	\fancyfoot[RO,LE]{\thepage}

% ------
% Maketitle metadata
\title{\vspace{-7mm}%
	\fontsize{24pt}{10pt}\selectfont
	\textbf{Re-implementation of the Picnic signaturescheme in Python}
	}
\author{%
	\large
	\textsc{Thorsten Knoll} \\[2mm]
	\normalsize	info@thorstenknoll.de \\[2mm]
	\normalsize March, 2019
	%\vspace{-5mm}
	}
\date{}

\usepackage[utf8]{inputenc}

\usepackage{hyperref}

%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}

\maketitle
\thispagestyle{fancy}

%\begin{abstract}
%\noindent Abstract goes here
%\end{abstract}

\section{Introduction}
\subsection{Post-quantum cryptography, NIST and Picnic}
Quantum computers are experiencing fast development and seem to be available within a timeframe of the next few decades. One of their properties will be to break huge parts of modern cryptography. Especially the discrete logarithm and prime-factorisation loose their trapdoor funcionality in regards to the efficient quantum algorithms from Grover and Shor. Therefore the need for new cryptographic algorithms arises, beeing save in regards to the availability of quantum computers. This field of research goes with the name "Post-quantum cryptography" (PQC). The american National Institute of Standards and Technology (NIST) called out a challenge to find the next PQC standards. This challenge is in round two of three at the time of writing this document. 69 submissions from round one were reduced to 26 candidates in round two of the challenge. These 26 candidates got announced by NIST not long ago at the end of january 2019. One of the submissions surviving the first round is the Picnic signaturescheme.\\ \\
NIST PQC page: \url{https://csrc.nist.gov/Projects/Post-Quantum-Cryptography}
\subsection{Evaluation and reviews}
69 submissions is quite a huge amount in terms of reviewing and evaluating them. Additionaly PQC is a new field of research with a history not much longer than a decade. Cryptographers (and -analysts) are working intense on creating, evaluating, reviewing and breaking PQC algorithms. The state of PQC is that every litte step helps towards the goal of having secure PCQ algorithms. At RheinMain University of Applied Sciences (HSRM) the Master Students in Computer Science found together in a research course to participate in this process. This re-implementation is part of this efford.
\subsection{Goals: Learning Picnic (and LowMC)}
The sole purpose of this re-implementation is learning and understanding the Picnic algorithm and it's underlying zero-knowledge proof system. The goals are to provide an "easy to read and understand" codebase in a high-level language (Python) and make it a little easier to follow and learn the designprinciples of Picnic. The execution of Python-Picnic is awefull slow compared to the reference implementations in C. It is very unlikely that this will ever reach a usable state for production. Additionaly the code is not reviewed by anyone but the author and is surely not secure for productive use. But it may help to understand Picnic.\\ \\
On the way to understand Picnic, another algorithm must be understood too. That is the LowMC blockcipher. There are two main parts in Picnic, where LowMC plays a major role. Firstly the derivation of the public key is a LowMC encryption of the Picnic private key. Secondly each Picnic zero-knowledge round is a modified LowMC encryption, fitted into a Multi-Party-Computation (MPC) scheme. In the following description of the implementations we start with LowMC for that reason.
\subsection{Reference documents and implementations by the Picnic Team}
The original publications and reference implementations (in C) are available at: \\ \\
Microsoft Picnic projectpage: \url{https://www.microsoft.com/en-us/research/project/picnic/}\\
Microsoft Picnic Github: \url{https://github.com/Microsoft/Picnic}
\subsection{Re-implementations in Python}
These re-implementations in Python follow the original MIT Licenses and are public available at:\\ \\
LowMC in Python: \url{https://github.com/ThorKn/Python-LowMC}\\
Picnic in Python: \url{https://github.com/ThorKn/Python-Picnic}\\ \\
Installation and usage instructions are given inside the projects \texttt{README} files. This \texttt{PDF} can be found inside the \texttt{Python-Picnic} project in the \texttt{docs} folder.
\section{LowMC}
\subsection{Idea and overview}
Picnic makes intense use of the LowMC algorithm. Therefore we start with LowMC before hoping over to Picnic. A standalone LowMC Python-implementation got build as a starting point to understand Picnic. That is why there is a own Github project under the name \texttt{"Python-LowMC"}.\\ \\
LowMC is a blockcipher in a roundbased construction scheme like many other blockciphers. The name is an abbreviation for "Low multiplicative complexity". XOR in GF2 is a linear operation (ADD), while the multiplication (AND) in GF2 is a non-linear operation (Figure \ref{fig:gates}). LowMC tries to keep the count of AND operations as low as possible while still maintaining a given security level (L1, L3, L5). Additionaly LowMC is also designed to keep the AND-depth low. That means most AND operations could be done in parallel.\\
\begin{figure}[htbp]
\center
\includegraphics[width=0.35\textwidth]{pics/gates.pdf}
\caption{Linear and non-linear operations}
\label{fig:gates}
\end{figure}\\
Figure \ref{fig:lowmcscheme} shows the roundbased scheme of LowMC. Only the sbox part of the algorithm uses multiplications (ANDs). The other parts strictly contain only linear operations. From a mathematical point of view the XOR is a bijective function and the multiplications (ANDs) in GF2 are not bijective. Therefore the sboxes are the only not bijective part in LowMC. That is the reason for choosing LowMC in Picnic and it keeps the signature lengths smaller than with other blockciphers. We'll see how this is achieved with the Picnic implementation later on.
\begin{figure}[htbp]
\center
\includegraphics[width=0.5\textwidth]{pics/lowmc_scheme.pdf}
\caption{LowMC scheme}
\label{fig:lowmcscheme}
\end{figure}
\subsection{Pre-calculated constants}
The python program \texttt{generator.py} generates the files for all security levels with the following pre-calculated constants:
\begin{itemize}
\item{Linear layer matrices}
\item{Round constants}
\item{Roundkey matrices}
\end{itemize}
The generation of the constants-files is not mandatory for usage as the project contains them "ready to use".
\subsection{Private functions}
\subsubsection{\texttt{\_\_apply\_sbox()}}
Sboxes are the only parts in LowMC, that contain multiplications in GF2 (ANDs). A fixed number of sboxes is applied to the state. Each sbox substitutes 3 Bit of the original state through a fixed substitution scheme. Let $a$, $b$ and $c$ be three bits in the state. Then $a'$, $b'$ and $c'$ get computed by:
\newpage
\[a' = a \oplus b \cdot c\]
\[b' = a \oplus b \oplus a \cdot c\]
\[c' = a \oplus b \oplus c \oplus a \cdot b\]
Where $\oplus$ is XOR and $\cdot$ is AND. So each 3-Bit sbox contains exactly 3 multiplications (ANDs). The security level (L1, L3, L5) defines the number of 3-Bit sboxes ($n$) per LowMC-round as shown in figure \ref{fig:sboxes}. The surplus Bits in the state get no substitution, shown on the right of the figure. The total number of multiplications for a complete encryption in LowMC sums up to $3 * n * rounds$. In example for security level L1 this calculates to $3 * 10 * 20 = 600$ ANDs.\\
\begin{figure}[htbp]
\center
\includegraphics[width=0.5\textwidth]{pics/sboxes.pdf}
\caption{Sboxes per LowMC round}
\label{fig:sboxes}
\end{figure}\\
The function applies the sboxes to a state in memory and has no parameters and no returns. The actual state is stored in the private variable \texttt{self.\_\_state}. The sboxes are stored as a list (you can imagine it as a lookup-table) in the private variable \texttt{self.\_\_sbox}.
\subsubsection{\texttt{\_\_multiply\_with\_lin\_mat(round)}}
The state gets matrix multiplied with the constant and pre-calculated linear matrix. This contains only linear operations.
\subsubsection{\texttt{Add roundconstant}}
This needs no seperate function. It is a one-line operation with XOR on the state and therefore contains only linear operations.
\subsubsection{\texttt{\_\_key\_addition(round)}}
For XOR'ing the roundkey to the state the roundkey must be derived first. This is done by a matrix multiplication of the private key and the constant, pre-calculated roundkey-matrix. Again this only contains linear operations.
\subsubsection{\texttt{Decryption functions}}
The decryption works pretty much the whole encryption way backwards. For the matrix multiplications their inverse matrices are needed. They get calculated within the constructor of the LowMC class and stored in seperate, private variables. The neccessary functions are named like the ones for encryption but with a \texttt{\_inv} appended to their names. The same rule applies for the names of their private variables.
\subsection{Public functions (API)}
\subsubsection{\texttt{LowMC(Security level) - Constructor}}
Constrcuts an object of LowMC with the parameters regarding to the security level. The following security levels are available and shall be given to the constructor as strings: "picnic-L1", "picnic-L3" and "picnic-L5". The fitting file with the constants must be in the project directory and gets read (see Pre-calculated constants). The constants from the file get stored in the private variables \texttt{self.\_\_lin\_layer}, \texttt{self.\_\_round\_consts} and \texttt{self.\_\_round\_key\_mats}.
\subsubsection{\texttt{generate\_priv\_key()}}
Generates a private key of the length specified within the security level. The private key is stored in the private variable \texttt{self.\_\_priv\_key}. The CSPRNG from the python package \texttt{os} is used (\texttt{os.urandom(bytelength)}).
\subsubsection{\texttt{set\_priv\_key(priv\_key)}}
Instead of generating the private key, it can also be set by giving a bytearry to this function. The bytearray must match the specified keylength from the security level.
\subsubsection{\texttt{encrypt(plaintext)}}
Encrypts a plaintext and returns the ciphertext. The plaintext length must match the specified blocksize length (security level) and must be given as a bytearray to the function. The ciphertext is returned as a bytearray of the same length. Before using this function a private key must be set (or generated).
\subsubsection{\texttt{decrypt(ciphertext)}}
Decrypts a ciphtertext and returns the plaintext. The ciphertext length must match the specified blocksize length (security level) and must be given as a bytearray to the function. The plaintext is returned as a bytearray of the same length. Before using this function a private key must be set (or generated).
\subsection{Testvectors}
The repository contains the python file \texttt{test\_lowmc.py}. One can simply run this and nine different testvectors get executed on the implementation. Three vectors for each security level. This testfile is also a good starting point to see how the implementation can be used.
\subsection{Prerequisites}
The code is tested with Ubuntu 16.04 LTS and Python3.6. The package "BitVector" for python is required. It is recommended to use a virtual environment for Python, like \texttt{virtualenv}. In (very) short lines:\\
\texttt{virtualenv --p /usr/bin/python3.6 myvenv}\\
\texttt{source /path\_to\_myvenv/bin/activate}\\
\texttt{<myvenv>pip install BitVector}\\
\texttt{<myvenv>python test\_lowmc.py}\\
\section{Picnic}
\subsection{Components}
Picnic is a Post-quantum signature scheme that does not rely on hard number theoretical problems like discrete logarithm or prime-factorization. Instead Picnice embedds symmetric cryptographic primitves into a zero-knowledge proof system. The components of Picnic are:
\begin{itemize}
\item{A blockcipher (LowMC)}
\item{A Hashfunktion (SHA3-SHAKE)}
\item{A Zero-knowledge proof system (ZKB++)}
\end{itemize}
LowMC is discussed earlier in this document. It is a parametric blockcipher algorithm that simulates a gatebased (XOR, AND in GF2) electrical circuit from input to output with low AND-gate counts. The Python-LowMC implementation will be used for Picnic. SHA3-SHAKE will not be discussed in detail in this document. It is a NIST-standardized Hashalgorithm, based on the Spongeconstruction with an arbitrary output length. In Picnic SHA3-SHAKE is used as a Hashfunction as well as a Key-Derivation-Function (KDF). Python-Picnic uses the Python library \texttt{hashlib} whereever SHA3-SHAKE is needed\\ \\
That leaves the zero-knowledge proof system ZKB++ to explain. The following descriptions are on a very abstract level and will not explain every detail. Instead we'll focus on getting a broad overview of the functionality to learn the key points of the implementation. Most of the following examples are based on the documentations and presentations of the Picnic research team \footnote{\url{https://asiacrypt.iacr.org/2018/files/SLIDES/TUESDAY/Z411/post\%20quantum\%20signatures\%20-\%20asiacrypt18v2.pdf}}.
\subsection{Proof of knowledge: The $\Sigma$ - Protocol}
Zero-knowledge proofs are based on the $\Sigma$-protocol, but with the twist to transmitt no parts of the underlying secret anywhere in the communication. The basic $\Sigma$-Protocol is a communication scheme between two parties as in figure \ref{fig:sigma}. A prover wants to convince a verifier about the knowledge of a secret.
\begin{figure}[htbp]
\center
\includegraphics[width=0.5\textwidth]{pics/sigma.pdf}
\caption{$\Sigma$-Protocol scheme}
\label{fig:sigma}
\end{figure}\\
To prove this knowledge, a 3-way communication is held. A classic example for the $\Sigma$-Protocol is the Schnorr protocol. It is based on the discrete logarithm. The prover knows a secret $x$ so that $y=g^{x}$ with $g$ beeing a generator in a cyclic group $G_{p}$ with the order $p$. The messages in the Schnorr protocol are:
\begin{itemize}
\item{Commitment: Prover chooses a random $r$ and commits $t = g^{r}$ and $y$.}
\item{Challenge: Verifier chooses a random $c$ and sends it to the prover.}
\item{Response: Prover sends $s = r + cx$.}
\end{itemize}
The verifier accepts, if $ty^{c} = g^{s}$. Because:
\[ty^{c} = g^{r}y^{c} = g^{r}g^{cx} = g^{r + cx} = g^{s}\]
Inserted into the sequence diagramm above, this communication would look like figure \ref{fig:schnorr}.
\begin{figure}[htbp]
\center
\includegraphics[width=0.5\textwidth]{pics/schnorr.pdf}
\caption{Schnorr protocol}
\label{fig:schnorr}
\end{figure}
\subsection{LowMC in ZKB++}
In the next step towards ZKB++ we'll look into how LowMC works as the One-way-function inside a $\Sigma$-protocol.\\ \\
Imagine LowMC as a electronic circuit of XOR and AND gates as in the example in figure \ref{fig:circuit}. There are inputs ($x_{1..8}$) and outputs ($y_{1..6}$) from the circuit. The function of this LowMC circuit could be $f_{LowMC}(x) = y$. For given inputs the outputs can be calculated efficiently. For given outputs there is no efficient algorithm to determine the inputs. That is a hard to reverse function.\\
\begin{figure}[htbp]
\center
\includegraphics[width=0.69\textwidth]{pics/circuit.pdf}
\caption{A LowMC circuit as a One-way-function}
\label{fig:circuit}
\end{figure}\\
Thinking in terms of the $\Sigma$-protocol we can define the following sentence:
\begin{center}
\textit{A prover has knowledge of a secret key (inputs $x$) that computes with\\
the LowMC cicruit (One-way-function) to a public key (outputs $y$).}
\end{center}
\subsection{MPC and the zero-knowledge proof}
The zero-knowledge proof system ZKB++ is based on Multi-Party-Computation (MPC). MPC means that the prover from the $\Sigma$-protocol is splitted into different players. For ZKB++ the number of players is fixed to three. To get a grip of how MPC and the zero-knowledge property works, we'll look into an example from Melissa Chase from the Picnic research team (figure \ref{fig:mpc}). She presented this example at RealWorldCrypto 2018 and the talk is public available as a video\footnote{\url{https://www.youtube.com/watch?v=_J9ESIy8D2o}}.\\ \\
A prover knows the secrets $a$ and $b$. The function $f$ shall be the very simple circuit $c=a\oplus c$, where $\oplus$ is an XOR. Let $H$ be a cryptographic secure Hashfunction (i.e. SHA3-SHAKE). This example is designed for two players, instead of the three players in ZKB++.\\
\begin{figure}[htbp]
\center
\includegraphics[width=1.0\textwidth]{pics/mpc2player.pdf}
\caption{MPC with two players}
\label{fig:mpc}
\end{figure}\\
It is easy to recognize the $\Sigma$-protcol in this MPC by the message scheme of "commitment", "challenge" and "response". The differences are that now two players are involved on the prover side. Both have their input- and output shares and the challenge determines which players input shares get revealed. The verifier can then check if the revealed player had a valid input share of the secrets $a$ and $b$ and therefore is convinced about the provers knowledge of the secrets by a probability of 50\% (one of two players). This can be repeated $n$ times till the wanted probability (defined by the security level) is reached. The probability calculates to $p = (1/2)^{n}$. As the function $f$ is assumed to be "hard to reverse", nothing about the secrets $a$ and $b$ got learned. That is the zero-knowledge part of the proof.\\ \\
Some remarks about the differences between this example and the MPC in Picnic need to be noted:
\begin{itemize}
\item{This works because of $(a_1 \oplus a_2) \oplus (b_1 \oplus b_2) = (a_1 \oplus b_1) \oplus (a_2 \oplus b_2) = c_1 \oplus c_2 = c$}
\item{LowMC has AND gates. This makes dividing the shares more complicated.}
\item{ZKB++ has three players instead of two. The secrets have to be shared by three.}
\item{The cheating probability increases to $2/3$. Confidence probability is $p=(1/3)^n$.}
\item{Challenges request one of three players to be revealed with $e \in \{0,1,2\}$.}
\item{The lowest security level in Picnic has $n = 219$ MPC rounds.}
\end{itemize}
\subsection{MPC in the head and Random oracle models}
The zero-knowledge proof we've discussed so far is interactive between the prover and the verifier. The communication in the $\Sigma$-protocol defines the verifier as a secure source of randomness for the challenges. The prover must not be able to guess in advance what the challenge will be.\\ \\
For a signaturescheme it is wanted to calculate the proof without the need for an "external" source of randomness. The signatures shall be created and verified on a single machine without the counterpart of the verifier in the communication. This is called "MPC in the head", reduces the proof to a non-interactive version and is used in ZKB++. It wouldn't be a secure idea to let the prover choose the challenges on his own. The prover then could simply pick the challenge that favours him. A proveable secure solution to this is to use a "Random Oracle Model" (ROM) on the provers side to generate the challenges. In ZKB++ this is done with the cryptographic secure hashfunction SHA3-SHAKE. The output of SHA3-SAHKE is the source of randomness under the premise of the ROM and fulfills all the needed properties for secure random numbers.\\ \\
The concrete implementation looks like this:\\
The round-commitments contain randomness (input shares) and are calculated and commited before the start of the protocol. To get the challenges, the commitments from each MPC round gets hashed. In the example above (figure \ref{fig:mpc}) this would be the hash of $h_1, h_2, c_1, c_2$. The challenges then are extracted from this hash bitwise (figure \ref{fig:challenges}). Each two bits from the hash are transformed to a single challenge $e \in \{0,1,2\}$ for a three party MPC. And there we see the reason for using a hashfunction with arbitrary output lengths (SHA3-SHAKE). The needed length of this hash depends on the number of MPC rounds $n$ (security level L1: $n=219$) as every MPC round has it's own challenge.\\
\begin{figure}[htbp]
\center
\includegraphics[width=0.7\textwidth]{pics/challenges.pdf}
\caption{Hashes to challenges}
\label{fig:challenges}
\end{figure}\\ \\
Picnic has two different versions of MPC in the head defined. The first one is the Fiat-Shamir (FS) transformation, which is based on the described ROM but might not be quantum save. The second option is the Unruh (UR) transformation, which is based on a Quantum Random Oracle Model (QROM). The re-implementation Python-Picnic can only handle the FS transformation so far.
\subsection{Signing a message: The Picnic loops}
All the described parts taken together assemble to the Picnic signaturescheme. Picnic consists mainly of two big loops, shown in figure \ref{fig:mainloops} for creating a signature (signing a message).
\begin{figure}[htbp]
\center
\includegraphics[width=0.5\textwidth]{pics/mainloops.pdf}
\caption{Signing a message: Picnic loops}
\label{fig:mainloops}
\end{figure}\\
\subsection{Keys, Message and Signature}
Picnic works with keypairs for signing and verifying as every other public key cryptographic algorithm. In figure \ref{fig:mainloops} the parts are marked, where the keys and the message to sign is used. The generation of the keypair is done with the LowMC encryption. A random plaintext message is needed to do this. The lengths of the keys and the plaintext are defined through the security level. Therefore the \textbf{key generation} is:
\begin{itemize}
\item{Pick a random private key $sk$ (secret key).}
\item{Pick a random plaintext message $p$ (Not to confound with the message to sign).}
\item{Compute the encryption of $p$ with $sk$: $C = LowMC(sk, p)$.}
\item{The public key is the tuple $pk = (C,p) = (LowMC(sk,p), p)$.}
\end{itemize}
The \textbf{message $M$} to be signed must be an arbitrary bytearray of the length $1 \leq \vert M  \vert \leq 2^{55}$. The messsage takes account into the creation of the challenges. In the description of "MPC in the head" above, this was not explained to keep things as simple as possible. But in the Picnic signaturescheme the challenges depend on the commitments, the output shares \textbf{and} the message $M$.\\ \\
The Picnic signing function is defined as:
\[signature\text{ }\delta = picnic\_sign(sk, pk, M)\]
The resulting \textbf{signature $\delta$} can be understood as a transcript of the complete communication in the MPC protocol. The signature in Picnic includes:
\begin{itemize}
\item{The challenges for all MPC rounds.}
\item{The player revelations according to the challenges (transcripts, seeds and input shares). Remark: Only one player gets revealed per MPC round.}
\item{The commitments of the player according to the challenges. Remark: Only one players commitment gets revealed per MPC round.}
\end{itemize}
\textbf{LowMc and the signature sizes:}\\
At the beginning of the LowMC description it was said, that LowMC was chosen because it reduces the signature sizes in Picnic, compared to other blockcipher algorithms. The argumentation was, that the low count of AND gates does this. In figure \ref{fig:mainloops} can be seen that the transcripts of the LowMC rounds are done in the sbox-part of the algorithm. And only the calculations from the AND gates get recorded as a transcript. That is the point where Picnic takes advantage of LowMC to minimize the size of the signatures.
\subsection{Types and variables in the implementation}
With the given explanations about the Picnic algorithm it should be not that hard to understand the Python sourcecode. The functions mostly map directly to the explanations. Instead of describing all functions in detail, an affiliation of the code-variables to the examples above will be given. We'll start with the public variables in table \ref{tab:secparams} defined through the security level of Picnic. If Python-Picnic would support more security levels (only L1 at the moment), the constructor would set these variables according to them. Supporting more security levels is implemented in Python-LowMC and it can be seen there, as an example how to implement this feature.\newpage
\begin{table}[htbp]
\begin{center}
\begin{tabular}{|l|l|}
\hline
\textbf{Variable}  & \textbf{Description} \\ \hline
self.blocksize  &  Internal blocksize of LowMC in bits (also statesize)\\ \hline
self.blocksize\_bytes  &  Internal blocksize of LowMC in bytes\\ \hline
self.keysize  &  Lenght of private and public key in bits\\ \hline
self.rounds  &  Number of LowMC rounds\\ \hline
self.sboxes  &  Number of 3-Bit sboxes in LowMC\\ \hline
self.mpc\_rounds  &  Number of MPC rounds\\ \hline
self.hash\_length  &  Lenght of the SHAKE ouput as hashfunction in bits\\ \hline
self.lowmc  &  Name of the security level as string\\ \hline
\end{tabular}
\caption{Public variables}
\label{tab:secparams}
\end{center}
\end{table}
\noindent Before the private variables, we'll declare the implementation specific types (datastructures) and describe them in table \ref{tab:types}. They are defined in an own file, named \texttt{picnic\_types.py}. All the types are classes with only a constructor and some variables. Imagine them like C structs.\\
\begin{table}[htbp]
\begin{center}
\begin{tabular}{|l|l|l|}
\hline
\textbf{Class}  & \textbf{Variables} & \textbf{Description} \\ \hline
Publickey & self.public\_key & Public key as BitVector, length = self.keysize \\
		  & self.p			  & Plaintext message for public key generation as BitVector, \\
		  &					  & length =  self.keysize\\ \hline
View	  & self.i\_share     & Single input share as a BitVector, length = self.blocksize \\
		  & self.transcript  & Single transcript of a LowMC round as a BitVector,\\
		  &					  & length = AND gates in one LowMC round\\
		  & self.o\_share     & Single output share as BitVector, \\
		  &                   & length = self.blocksize \\ \hline
Commit-   & self.hash       & Hash of a single commitment as a bytearray,\\
ment      &                 & length = self.hash\_length \\
		  & self.n\_commitments & Not used by now \\ \hline
Proof     & self.seed\_1  & Seed of the first not revealed player in a round\\
		  & self.seed\_2  & Seed of the second not revealed player in a round\\
		  & self.i\_share & Input share of the revealed player in a round\\
		  & self.transcript & Transcript of the AND gates of the revealed player\\
		  & self.view\_3\_commit & A merged commit of the three players (to save space)\\ \hline
Signature & self.proofs & List of Proofs (class Proof), length = self.mpc\_rounds\\
		  & self.challenges & List of all challenges, length = self.mpc\_rounds\\
		  & self.salt & Salt as bytearray, length = self.blocksize\\ \hline
\end{tabular}
\caption{Picnic types (classes)}
\label{tab:types}
\end{center}
\end{table}\\
\noindent Now, with the knowledge about the types (classes) we can define the private variables. They mostly store the informations from the MPC rounds for every player (three of them). Therefore the views, commitments and seeds are two-dimensional arrays with the first dimension beeing the MPC rounds and the second dimension beeing the three players. Python does not have datatypes for arrays. They are nested lists, but can be accessed in the same way as arrays in other languages by bracket-notations ([dim 1][dim 2]). The private variables are described in table \ref{tab:privvars}.
\begin{table}[htbp]
\begin{center}
\begin{tabular}{|l|l|}
\hline
\textbf{Variable}  & \textbf{Description} \\ \hline
self.\_\_priv\_key    & Private key as BitVector, length = self.keysize\\ \hline
self.\_\_pub\_key     & Public key as type Publickey (class)\\ \hline
self.\_\_views        & Two-dimensional array of Views (class)\\
			          & dims: [self.mpc\_rounds][3 (players)]\\ \hline
self.\_\_commitments  & Two-dimensional array of Commitments (class)\\
					  & dims: [self.mpc\_rounds][3 (players)] \\ \hline
self.\_\_seeds 		  & Two-dimensional array of seeds as BitVectors.\\
			          & Each BitVector has length = self.blocksize\\
			          & dims: [self.mpc\_rounds][3 (players)] \\ \hline
self.\_\_salt  		  & Salt as a BitVector, length = self.blocksize\\ \hline
self.\_\_tapes\_pos  & Position counter on the tapes. Type = Integer\\ \hline
self.\_\_challenges  & List of the challenges $e \in \{0,1,2\}$,\\
					  & length = self.mpc\_rounds \\ \hline
self.\_\_prove       & List of Proofs (class), length = self.mpc\_rounds\\ \hline
self.\_\_signature   & Stores the complete Signature (class),\\
					  & including proofs, challenges and salt \\ \hline
self.\_\_signature\_ser & Stores a serialized signature as bytearray\\ \hline
\end{tabular}
\caption{Private variables}
\label{tab:privvars}
\end{center}
\end{table}
\subsection{Verify a Picnic signature}
To verify a given signature, nearly the same steps as to create a signature are executed. The challenges decided which one of the three players in each round got revealed. The transcripts, seeds and  shares of the one revealed player got stored into the signature. In the verification the other two players must be recalculated. After recalculating the "missing" players data, the challenges are re-computed. \\ \\
In figure \ref{fig:mainloops} can be seen, that the computation of the challenges is the secondlast step in the creation of the signature. The data from all three players are merged into a single hash and the challenges are derived from this hash. Only after the challenges are fixed, the proofs for the signature are assembled, based on the challenges. In other words the challenges depend on the calculated data of all three players.\\ \\
\textbf{The signature is accepted as valid,} if the re-calculation of the "missing" (not revealed) players and the data from the revealed player computes to the same challenges as in the signature.\\ \\
The main algorithmic differences between sign and verify are that each MPC round and each LowMC round only calculates two players in the verification. And which two players are calculated depends on the round challenge in the signature. Therefore all internal functions are re-written to accept the round challenge as an additional parameter and calculate only the two "missing" players. This seems a little redundant in the sourcecode but keeps good review and learning capabilities. The verify functions can be recognized by the postfix \texttt{\_verify} in their names.
\subsection{The API to Python-Picnic}
In comparison to \texttt{Python-LowMC} there are no private functions in \texttt{Python-Picnic}. All functions follow the Python scheme for public functions (no leading \texttt{\_\_}). That could be changed in future reworks. Therefore the functions to use \texttt{Python-Picnic} are described here. Additionaly there ist a testfile (\texttt{tests.py}) in which the usage can be seen by function-call examples.\\ \\
\texttt{Picnic-LowMC} got expanded from the standalone version (in the LowMC Github) to a version for the Picnic needs. For example the sbox-function in LowMC needs to store the outcomes of the AND-gates for the signature. That was not a part in the standalone LowMC. A new, expanded version of LowMC is included within \texttt{Python-Picnic} as the file \texttt{lowmc.py}.\\ \\
The Picnic specifications inculde a scheme for serializing signatures. The serialization and file-storage of a signature are implemented in \texttt{Python-Picnic}. That enables a way to compare signatures to the ones from the reference implementation. The file-storage writes textfiles with the serialized signature as a HEX-string. This is not the most compact way, but enables human readability and comparison.\\ \\
The serialization of the keys is also a part of the Picnic specification but is not implemented in \texttt{Python-Picnic} so far. This is a priority issue for future works. That means, that the keys are gone, if the Picnic-object is destroyed (the execution of the sourcecode ends). A function for setting the private key and the plaintext message is included. This function then derives the public key.
\subsubsection{\texttt{generate\_keys(p, priv\_key)}}
Sets or generates the plaintext message $p$ (for LowMC key generation) and the private key $pk$. If the parameters are given, they are setted. If left emtpy, they are generated with \texttt{os.urandom()}. The public key then gets derived via LowMC encrpytion. The parameters must be bytearrays with correct length according to the security parameter. So far only "Picnic-L1" is implemented. Therefore the sizes must be 16 bytes. The data is stored in the matching private variables from table \ref{tab:privvars}.
\subsubsection{\texttt{sign(message)}}
Signs a message $M$. The keys must be set or generated before. The message must be passed as a bytearray of arbitrary length in the bounds $1 \leq \vert M \vert \leq 2^{55}$. The signature gets stored into the private variable \texttt{self.\_\_signature} (see table \ref{tab:privvars}).
\subsubsection{\texttt{verify(message)}}
Verifies a signature regarding to the message. The keys must be set or generated before. The message must be passed as a bytearray of arbitrary length in the bounds $1 \leq \vert M \vert \leq 2^{55}$. The signature must be available in the private variable \texttt{self.\_\_signature} before calling \texttt{verify}. This can be done by signing a message or by reading one from a file before.
\subsubsection{\texttt{serialize\_signature()}}
Serializes a signature from the private variable \texttt{self.\_\_signature} and stores it into the private variable \texttt{self.\_\_signature\_ser}.
\subsubsection{\texttt{deserialize\_signature()}}
Deserializes a signature from the private variable \texttt{self.\_\_signature\_ser} and stores it into the private variable \texttt{self.\_\_signature}.
\subsubsection{\texttt{write\_ser\_sig\_to\_file(filename)}}
Writes a serialized signature from the private variable \texttt{self.\_\_signature\_ser} to a textfile. The filename must be provided as a string. The textfile then contains the serialized signature as a HEX-string.
\subsubsection{\texttt{read\_ser\_sig\_to\_file(filename)}}
Reads a textfile with the given filename (string). The textfile must contain a serialized signature as HEX-string. The serialized signature then gets stored into the private variable \\ \texttt{self.\_\_signature\_ser}.
\subsubsection{\texttt{print\_signature()}}
Does a printout into the console of the signature in the private variable \texttt{self.\_\_signature}. The variable must contain a signature.
\subsubsection{\texttt{print\_signature\_ser()}}
Does a printout into the console of the serialized signature in the private variable \\ \texttt{self.\_\_signature\_ser} as a HEX dump. The variable must contain a serialized signature.
\subsection{Prerequisites}
The code is tested with Ubuntu 16.04 LTS and Python3.6. The package "BitVector" for python is required. The package "hashlib" is used for the SHA3-SHAKE parts. SHAKE is available in "hashlib" since Python 3.6. Therefore \texttt{Python-Picnic} will not run with Python versions lower than 3.6. It is recommended to use a virtual environment for Python, like \texttt{virtualenv}. In (very) short lines:\\ \\
\texttt{virtualenv --p /usr/bin/python3.6 myvenv}\\
\texttt{source /path\_to\_myvenv/bin/activate}\\
\texttt{<myvenv>pip install BitVector}\\
\texttt{<myvenv>python tests.py}\\
%\bibliographystyle{unsrt}
%\bibliography{}

\end{document}


\documentclass[12pt]{article}
\usepackage[top=1in,bottom=1in,left=0.75in,right=0.75in,centering]{geometry}
\usepackage{fancyhdr}
\usepackage{epsfig}
\usepackage[pdfborder={0 0 0}]{hyperref}
\usepackage{palatino}
\usepackage{wrapfig}
\usepackage{lastpage}
\usepackage{color}
\usepackage{ifthen}
\usepackage[table]{xcolor}
\usepackage{graphicx,type1cm,eso-pic,color}
\usepackage{hyperref}
\usepackage{amsmath}
\usepackage{wasysym}
\usepackage{latexsym}
\usepackage{amssymb}

\def\course{CS 4102: Algorithms}
\def\homework{Module 2 - Graphs: Basic Written HW}
\def\semester{Spring 2021}

\newboolean{solution}
\setboolean{solution}{false}

% add watermark if it's a solution exam
% see http://jeanmartina.blogspot.com/2008/07/latex-goodie-how-to-watermark-things-in.html
\makeatletter
\AddToShipoutPicture{%
\setlength{\@tempdimb}{.5\paperwidth}%
\setlength{\@tempdimc}{.5\paperheight}%
\setlength{\unitlength}{1pt}%
\put(\strip@pt\@tempdimb,\strip@pt\@tempdimc){%
\ifthenelse{\boolean{solution}}{
\makebox(0,0){\rotatebox{45}{\textcolor[gray]{0.95}%
{\fontsize{5cm}{3cm}\selectfont{\textsf{Solution}}}}}%
}{}
}}
\makeatother

\pagestyle{fancy}

\fancyhf{}
\lhead{\course}
\chead{Page \thepage\ of \pageref{LastPage}}
\rhead{\semester}
%\cfoot{\Large (the bubble footer is automatically inserted into this space)}

\setlength{\headheight}{14.5pt}

\newenvironment{itemlist}{
\begin{itemize}
\setlength{\itemsep}{0pt}
\setlength{\parskip}{0pt}}
{\end{itemize}}

\newenvironment{numlist}{
\begin{enumerate}
\setlength{\itemsep}{0pt}
\setlength{\parskip}{0pt}}
{\end{enumerate}}

\newcounter{pagenum}
\setcounter{pagenum}{1}
\newcommand{\pageheader}[1]{
\clearpage\vspace*{-0.4in}\noindent{\large\bf{Page \arabic{pagenum}: {#1}}}
\addtocounter{pagenum}{1}
\cfoot{}
}

\newcounter{quesnum}
\setcounter{quesnum}{1}
\newcommand{\question}[2][??]{
\begin{list}{\labelitemi}{\leftmargin=2em}
\item [\arabic{quesnum}.] {#2}
\end{list}
\addtocounter{quesnum}{1}
}

\definecolor{red}{rgb}{1.0,0.0,0.0}
\newcommand{\answer}[2][??]{
\ifthenelse{\boolean{solution}}{
\color{red} #2 \color{black}}
{\vspace*{#1}}
}

\definecolor{blue}{rgb}{0.0,0.0,1.0}

\begin{document}

\section*{\homework}

%----------------------------------------------------------------------
\question[3]{
Describe an algorithm that, given a directed graph G represented as an \emph{adjacency matrix}, returns whether or not the graph contains vertex with in-degree $|V| - 1$ and out-degree $0$. In other words, does the graph have a node such that every other node points to it, but it does not point to any other node. Your algorithm must be $O(V)$. Note that there are $\Theta(V^2)$ cells in your adjacency matrix so you'll need to be clever here.
}

\answer[0.5in]{...}

\question[1]{
Let's say a graph $G$'s {\em circumference} is the number of edges in the shortest cycle in $G$. Describe an efficient algorithm to find the circumference of a graph in $\Theta(V \times E)$.  (Note: you must make use of algorithms studied in this module, and not  re-invent the wheel.)
}

\answer[0.5in]{...}

\question[3]{
Let $G$ be an undirected graph with $n$ nodes (let's assume $n$ is even). Prove or provide a counterexample for the following claim: If every node of $G$ has a degree of at least $\frac{n}{2}$, then $G$ must be connected.
}

\answer[0.5in]{...}

\question[1]{
 For a given undirected graph $G$, prove that the depth of a DFS tree cannot be smaller than the depth of the BFS tree.  (Clearly state your proof strategy or technique.)
}

% ------------------------------------------

% ------------------------------------------

% ------------------------------------------

\iffalse

\question[1]{
In the CLRS code for {\em DFS-Visit} at line 8,  we have completed recursively visiting all then un-visited vertices adjacent to vertex $u$, so we change $u$'s color to black.  For this problem, consider what happens if instead we change the color of $u$ to {\em white} at this line.

Explore what this causes to happen by tracing this altered algorithm on a small connected undirected graph.  After you have done that, submit answers to the following questions.

\begin{enumerate}
\renewcommand{\theenumi}{\Alph{enumi}}
\item In no more than a few sentences, clearly describe what the ``DFS'' tree from an initial node $s$ found by this algorithm represents.  (Note:  we put DFS in quotes here because with this change this algorithm is no longer DFS!)
\item Give a mathematical formula (not just an order class) for the number of leaves in this tree for a worst-case input graph.  Describe this worst-case input graph.  (Again, tracing this algorithm on small connected graphs may help you find the answer more quickly.)
\end{enumerate}

}

\question[1]{
The textbook describes two variables that can be associated with each node in a graph $G$ during the execution of \emph{Depth-First Search}: discovery time ($v.d$) and finish time ($v.f$). These are integer values that are unique. Every time a node is discovered (i.e., DFS sees the node for the first time) that node's $v.d$ is set to the next available integer. When DFS is finished exploring ALL of this node's children, $v.f$ is set to the next available integer.

For this question, consider a single edge in a graph $G$ after DFS finishes executing. You might need to reference the textbook or slides for definitions of tree edge, forward edge, back edge, and cross edge. Argue that each edge $e=(u,v)$ is:

\begin{enumerate}
\item A tree edge or forward edge if and only if $u.d < v.d < v.f < u.f$
\item A back edge if and only if $v.d \leq u.d < u.f \leq v.f$
\item A cross edge if and only if $v.d < v.f < u.d < u.f$
\end{enumerate}

You can describe your answers intuitively, but your answers must be clearly articulated.
}

\question[1]{
Given an undirected graph $G$, the {\em eccentricity} of a node $v$ is the largest of the shortest possible distances from $v$ to any other node in the graph. The minimum eccentricity in the graph is called the  {\em graph radius} for $G$. All the nodes in $G$ that have eccentricity equal to the graph radius form a set called the {\em graph center} of G.

Describe (using pseudo-code or a very clea rtext explanation) an efficient algorithm to find the graph center of a graph $G$ and describe its complexity.  (Note: you must make use of algorithms studied in this module, and not  re-invent the wheel.)
}
\fi

\end{document}


\documentclass[aps,prl,reprint]{revtex4-2}
\usepackage{gensymb}
\usepackage{graphicx}
\usepackage{amsmath}
\usepackage{hyperref}
\usepackage{dsfont}
\usepackage{relsize}
\usepackage{wrapfig}
\usepackage{graphicx}
\usepackage{hyperref}
\hypersetup{colorlinks=true, citecolor=blue, urlcolor=blue, linkcolor=blue}

\begin{document}

% Use the \preprint command to place your local institutional report
% number in the upper righthand corner of the title page in preprint mode.
% Multiple \preprint commands are allowed.
% Use the 'preprintnumbers' class option to override journal defaults
% to display numbers if necessary
%\preprint{}

%Title of paper
\title{AFT Lab}

% repeat the \author .. \affiliation  etc. as needed
% \email, \thanks, \homepage, \altaffiliation all apply to the current
% author. Explanatory text should go in the []'s, actual e-mail
% address or url should go in the {}'s for \email and \homepage.
% Please use the appropriate macro foreach each type of information

% \affiliation command applies to all authors since the last
% \affiliation command. The \affiliation command should follow the
% other information
% \affiliation can be followed by \email, \homepage, \thanks as well.
\author{Trevor Smith, Alex Storrer}
\email[]{smith.tr@northeastern.edu}
\homepage[]{https://github.com/trevorm4x/}
%\thanks{}
%\altaffiliation{}
\affiliation{Northeastern University}

\date{\today}

\begin{abstract}
	The relationship between both sample rate and number of cycles
	with FFT linewidth was established, and it was found that
	the number of cycles observed cycles was much more relevant
	in precisely calculating the frequency of a signal.
	It was observed that sampling a signal at a sample rate
	lower than twice that of the signal does not produce
	an accurate reconstruction of the signal in the time
	domain or the frequency domain. Several acoustic sounds
	were produced in the lab and analyzed. It was found that tuning forks
	tuned to the same note will produce an observable acoustic
	``beat" due to their slight differences in frequency.
	It was found that a human whistle produces only a single,
	pure tone, and the sound produced by two humans whistling
	the same note is indistinguishable. Several human vowel
	sounds were analyzed, and it was found that each vowel
	sound has a unique frequency signature, and that these
	vowel sounds can be differentiated from each other clearly.
	Finally, two string-based instruments were analyzed for the
	quality of their timbre, or the harmonics present in their
	music. A guitar was found to have much fewer harmonics, and
	lower overall harmonics than a single-string guitar, which
	has much higher harmonics and a great many harmonics.
\end{abstract}

\maketitle

% body of paper here - Use proper section commands
% References should be done using the \cite, \ref, and \label commands
\section{Introduction}
% The Introduction should contain 1 or 2 paragraphs.
% Briefly state the physics underlying the experiment
% (what is being tested and why).
Fourier analysis is the practice of viewing a time-domain signal in the
frequency domain. Named after the mathemetician Joseph Fourier for his
breakthrough discovery that most functions, even discontinuous functions
like the step function, can be represented as an infinite sum of sine
waves, the advancement was originally made in pursuit of more easily
solving complex differential equations describing heat transfer. Some
scientists and engineers, however, do Fourier wrong by simply
referring to the technique by the anagram of its modern discrete
implementation, by saying, for example, ``plot the FFT". \\

The FFT, short for Fast-Fourier Transform, is as stated a method for
calculating the discrete Fourier transform of a finite time-domain signal.
One can forgive those who refer to Fourier analysis generally as ``FFT",
considering how this ingenious algorithm has paved the way for
the discrete Fourier transform's widespread usage in signal processing
across a wide range of fields and disciplines. \\

Utilizing a divide-and-conquer technique, the FFT could be compared to
a sailboat that, rather than following the wind directly to its destination,
turns sharply to the side and tacks back and forth across the wind,
taking a significantly longer and more complicated path that arrives in
a fraction of the time. To understand just how well this analogy works,
consider that the first step the FFT performs on a signal of length 2049
is to add another 2047 zeros onto the end so that the signal length is
an exact power of 2. \\

In this lab we will be conducting Fourier analysis, with the help of the
FFT algorithm, of various acoustic signals. This analysis is particularly
interesting in the context of speech and musical instruments, as noised that
to our ears may sound like ``one" note or vowel sound are in fact more
often than not rich with multiple harmonics throughout the frequency spectrum.\\

We will first conduct a simplified test implemented entirely in software,
examining the effect of longer observations on the linewidth, or uncertainty
in the frequency domain, numerically. We will then conduct a simple test
using an function generator with an oscilloscope to collect data for a
sine wave and square wave, in order to compare their frequency responses. \\

In the next phase of the lab, acoustic signals will be examined.
First, we will explore the interaction of two tuning forks as they
constructively and destructively interfere due to slight differences
in their frequency, producing what is known as a ``beat". We will then
explore characteristics of musical notes produced by a whistling sound,
the human voice producing vowel sounds, and musical instruments. \\

Finally, we will conduct a numerical exploration of the breakdown of accurate
signal reconstruction in the time-domain as a function of the nyquist
frequency and the fundamental frequency of the signal.

\section{Apparatus}
% List equipment components (manufacturer, model
% numbers and brief specifications).

The apparatus consisted of the following.
\begin{itemize}
\end{itemize}

\section{Basic FFT}
% Briefly describe the experimental procedures (in your own words, but don’t overdo it)
% Discuss calibrations, etc., if required
% Include necessary equations and put them on their own line (number them, e.g. “Eq. (3)”)
% Include plots showing relevant results (label each figure, e.g. “Fig. 3”, with caption).
% Describe what you found (describe what the plot illustrates)

\subsection{Procedure and Results}

In this section, a time-vector from 0 to 0.1 using 2048 equally spaced points
was produced, and used to build a sine wave of equation $y=sin(2\pi 100 x)$,
shown in \ref{shortsine_TD}.
The signal was then transformed into the frequency domain, using the
FFT algorithm. With this signal, as with all signals for the duration of the
lab, the signal was multiplied by a hamming window before performing the
discrete Fourier transform to mitigate spectral leakage. \\

\begin{figure}[h]
\includegraphics[width=0.34\textwidth]{../Images/l5_A_1a.png}
\caption{\label{shortsine_TD} Sine wave of frequency 100 Hz, observed for 0.1 seconds.}
\end{figure}

The Fourier analysis produced the expected frequency of 100 Hz, verifying that
the technique was applied correctly, as seen in \ref{shortsine_FD}.

\begin{figure}[h]
\includegraphics[width=0.34\textwidth]{../Images/l5_A_1b.png}
\caption{\label{shortsine_FD} Sine wave of frequency 100 Hz, observed for 0.1 seconds, in the frequency domain.}
\end{figure}

A second sine signal, calculated with the same sine function and N samples
but longer observation window of 1 second, was produced, as seen in
\ref{longsine_TD}.

\begin{figure}[h]
\includegraphics[width=0.34\textwidth]{../Images/l5_A_2a.png}
\caption{\label{shortsine_TD} Sine wave of frequency 100 Hz, observed for 1.0 seconds.}
\end{figure}

This longer sine wave was analyzed in the frequency domain as well, producing
a 100 Hz peak, as seen in \ref{longsine_FD} with the same x-axis range as
\ref{shortsine_FD}.

\begin{figure}[h]
\includegraphics[width=0.34\textwidth]{../Images/l5_A_2b.png}
\caption{\label{shortsine_TD} Sine wave of frequency 100 Hz, observed for 1.0 seconds, in the frequency domain.}
\end{figure}

The characteristics of these two alike signals can be easily compared in
\ref{comparisine_FD}, however quantitative characteristics are also given in
\ref{comparisine_TB}.

\begin{figure}[h]
\includegraphics[width=0.34\textwidth]{../Images/l5_A_2b.png}
\caption{\label{comparisine_FD} Comparison of the short (0.1 second) and long
(1.0 second) sine waves, given by the same equation, using Fourier analysis.}
\end{figure}

A brief exploration into the effect of the sample rate on the appearance of
a signal, and its corresponding Nyquist frequency, was conducted numerically.
The same sine wave corresponding to the equation $y=sin(2\pi 100 x)$ was
sampled for 0.1 seconds, using 10 and 100 points. Using an understanding
of the Nyquist frequency, which states that the sample rate must be at least
twice that of the sine wave in order to truthfully reconstruct it, the
lowest number of samples per 0.1 seconds that can truthfully reconstruct the
sine wave was plotted as well, along with one less than that number. These four
waves can be seen in \ref{waves}.

\begin{figure}[h]
\includegraphics[width=0.44\textwidth]{../Images/l5_optional.png}
\caption{\label{waves} The same equation, sampled with four different numbers
of samples per one tenth of a second.}
\end{figure}

While it is barely visible behind the other curves, it is still clear that
the blue wave is the baseline, a sample rate high enough to reconstruct
the sine wave very well. Because the frequency of the sine wave is 100 Hz,
the lowest Nyquist frequency acceptable would be 200 Hz, or 20 samples over
0.1 seconds. From this it is clear why the red wave, sampled at a rate
such that the Nyquist frequency of that wave is half of what is needed,
does not match the true sine wave whatsoever and looks like a completely
different signal. Observing that this red signal appears to make exactly one
cycle in 0.1 seconds, we can see that it looks like a 10 Hz signal instead of
a 100 Hz signal. It is also easy to make out that the green wave, sampled
at 20 samples per second, contains almost exactly two samples per period or
one sample per positive and negative peak - the Nyquist frequency corresponding
to that sample rate is exactly the lowest possible value. Finally,
comparing the purple wave, which is sampled with a Nyquist just below the
requisite for this sine wave, to the green and blue waves, it can be seen that
in the middle of the signal it skips a peak, resulting in what looks like a
similar frequency (but slightly lower in frequency) sine wave that is
dampened in the middle.

\subsection{Conclusion}

Uncertainty in the frequency of a signal, which manifests as the linewidth
of a peak in the frequency domain, is reduced as a function of observation time.
This is the result of a flavor of the Heisenberg Uncertainty Principle, where
longer observations (greater N cycles) of a signal trade better certainty of
the location of the signal in the frequency domain for worse certainty of the
location of the signal in the time domain. \\

This simple experiment confirms that linewidth $\Gamma$ is reduced with
longer observations or more cycles. A higher precision FFT was produced
in this experiment by collecting 100 cycles than by collecting 10 cycles.
It also shows that if a longer observation time is used while the number
N of samples is kept constant, sample rate decreases, which is seen in the
frequency range as well. It is important to note that although the
resolution of the frequency spectrum was reduced by a factor of ten (larger frequency
bins), the uncertainty or linewidth was still reduced.

\begin{widetext}
\begin{center}
\begin{table}[t]
\renewcommand{\arraystretch}{1}
\setlength{\tabcolsep}{10pt}
\caption{\label{comparisine_TB} Frequency response and parameters given by a
short and long observation of the same sine equation.}
\begin{tabular}{|c|c|c|c|c|c|}
%\hline
\toprule
Time (s) & Cycles M & Samples N & FFT Range $\Delta f$ & Resolving Power $\frac{f_0}{\delta f}$ (Hz) & Linewidth $\Gamma$ (Hz) \\
\colrule
0.1  &  10   &  2048  &  10225   & 10.00 &  17.4 \\ \colrule
1.0  &  100  &  2048  &  1022.5  & 1.000 &  1.74 \\ \hline
\botrule
\end{tabular}
\end{table}
\end{center}
\end{widetext}

\section{Tuning Forks}

\subsection{Procedure and Results}

In this section, the beat frequency of two tuning forks tuned to the same note
was analyzed. An acoustic ``beat" is caused by a slight difference in the
frequency of two sounds. Because sounds are waves and can constructively or
destructively interfere with each other, two waves of constant frequency can
interact with each other at a fixed point in space with a repeating pattern.
Specifically, a ``beat" usually occurs when the two constant frequencies are
just slightly different. So, while two tuning forks are more or less exactly
the same to most human ears, the frequency difference between them when they
are played simultaneously may produce an audible ``beat".\\

Two tuning forks were selected, and held at equal distances from a microphone
connected through an amplifier to an oscilloscope. The resulting wave was
recorded and is shown in \ref{forks}.

\begin{figure}[h]
\includegraphics[width=0.44\textwidth]{../Images/l5_C_a.png}
\caption{\label{comparisine_FD} Two tuning forks of nearly equal pitch interacting
in a constructive/destructive pattern, or ``beat", with an estimation of this
beat frequency. }
\end{figure}

The frequency of the tuning forks can be seen as the waves of shorter wavelength,
and the interaction of the two slightly different notes producing a ``beat" can
be seen as the oscillating amplitude of these peaks. It should be noted that
the frequency of the tuning forks themselves may not be accurately represented
at this sample rate, as the nyquist frequency is 120 Hz but the frequency of
the tuning forks is in the thousands. The low sample rate was necessary to observe
the beat pattern, as this was the priority of this experiment. The frequency of these
beats was estimated using trial-and-error at about 0.6 Hz. This fit is not
perfect, perhaps due to holding the forks at inconsitent distances from the
microphone.

\section{Whistle}

\subsection{Procedure}

In the next phase of the lab, a human whistle was produced by two different
subjects and analyzed in the frequency domain. As in the last section and
in all following sections, the acoustic sounds were recorded with a microphone,
and sampled with an oscilloscope before being saved and analyzed with Fourier
analysis. Each human subject attempted to produce a constant whistling note
during recording.

\subsection{Results}

In the first part of the test only one person whistled a higher-register note.
The frequency signature of this whistle is shown in \ref{high}.

\begin{figure}[h]
\includegraphics[width=0.44\textwidth]{../Images/l5_D_1.png}
\includegraphics[width=0.44\textwidth]{../Images/l5_D_1_zoomed.png}
\caption{\label{high} The frequency response of a higher-register note
produced by a human whistling, at full scale and zoomed in to the relevant area.}
\end{figure}

Only a single frequency is observed in a human whistle, similar to what may
be expected from a tuning fork. While it is true that the zoomed in version
of the FFT in \ref{high} reveals a non-zero linewidth and seems to include a few
frequency components, this is likely due to the subject's whistling skill
being inhibited by wearing a face-mask, causing the note to waver in pitch
slightly. \\

\newpage

In the next part of this test, two subjects, Adrian and Trevor,
whistled the same note, recording
them separately. A lower note was used that was within both subjects' registers.
This is shown in \ref{low}.

\begin{figure}[h]
\includegraphics[width=0.44\textwidth]{../Images/l5_D_2.png}
\includegraphics[width=0.44\textwidth]{../Images/l5_D_2_zoomed.png}
\caption{\label{low} The normalized frequency response of
two subjects recording the same whistling note separately.}
\end{figure}

Again, as before, a single frequency was observed for both subjects'
whistles. While a zoomed in view does seem to show that Adrian's whistle
involves slightly more variation lower than the main note, this is likely
simply a matter of Adrian not holding the exact same note during testing,
while Trevor's note was more consistent. For both whistlers, there are
no harmonics present in the Fourier analysis.

\subsection{Conclusion}

It appears for all intents and purposes that the whistle of one identical,
constant note by two people are indistinguishable. This is indicative
of the physiology of whistling. \\

In order to produce a whistle, there is at the core an interaction between
high-speed air and still air that forms a ``vortex ring". This occurs
in the space between the tongue, pushed up against the roof of the mouth,
and the lips, inside the mouth. As these rings of circulating air hit the
lips, a pressure wave is sent back into the mouth. A whistler is able
to shape their mouth such that this pressure wave resonates with the
formation of new vortex rings. \\

It is this mechanism that amplifies the overall sound and produces a single,
pure tone. This is because there is only one path that the sound travels,
and nodes only at the back of the tongue and the lips. \\

It is true, though, that just because the same note held by two people is
indistinguishable, doesn't mean that all whistling is the same. Because
whistling is a musical instrument, artistic talent is required to produce
music, and this artistic talent may be observable from one person to the next.

\section{Human Voice}

\subsection{Procedure and Results}

In this phase of the lab, several vowel sounds were produced, recorded with
a microphone and oscilloscope, and analyzed in the frequency domain. These
vowel sounds were `a', `e', `o', and `u', pronounced like in `car' with
a bostonian accent, `cheese', `coo coo ca choo', and `choose'. These
sounds were produced by a human male with a relatively low voice. The frequency
response of these 5 vowel sounds are shown in \ref{vowels}.

\begin{figure}[h]
\includegraphics[width=0.44\textwidth]{../Images/l5_E_a.png}
\includegraphics[width=0.44\textwidth]{../Images/l5_E_e.png}
\includegraphics[width=0.44\textwidth]{../Images/l5_E_o.png}
\includegraphics[width=0.44\textwidth]{../Images/l5_E_u.png}
\caption{\label{vowles} The frequency signatures of various vowel sounds.}
\end{figure}

\subsection{Conclusion}

These frequency responses help describe the sounds we are used to hearing
and making in a few ways. \\

First, beginning at the earliest peak, the `0' frequence or offset.
There is a significant peak observed for `e'
and `u', and a small one for `o', but not for `a'. The reason for this is
that for `e' and `u', the sounds are produced by building up pressure at
the very back of the throat and then releasing, while the `a' sound is
simply released without any effort. This pressure wave is recorded as an
average amplitude greater than zero. Trying to make an `e' sound without
building up pressure feels very awkward. \\

Next, we can look at the number of peaks present. `a', has the most activity
in the frequency domain when judged by number of peaks. This relates to
the way this sound is produced with an open mouth, with very many different
paths and harmonics available for the sound to be shaped by. `e' has very
vew peaks, which relates to the more closed position of the mouth and the
flat shape of the tongue. `o' and `u' have almost the exact same number of
peaks and frequencies of said peaks, which relates to them being essentially
the same sound but with a slight shift at the front of the mouth. This shift
serves to shift the relative amplitude of the higher harmonics closer to
the lower ones. \\

Next, we can look at the locations of the peaks. Perhaps the most interesting
vowel in this regard is `e'. `e' has both the lowest peak frequency and the
largest higher frequency in the 2 kHz range. This relates to the dropped jaw
leaving more room for the vocal cord to oscillate at a lower frequency, and
also to the higher pitch resonance created in the nasal cavities. `a' has
a peak frequency that is higher pitched, but has lower and higher amplitude
harmonics, but has very little resonance in the nasal cavities producing
higher frequency harmonics. This can be observed by saying `e' and `a' with
one's nose plugged - the `e' sounds much different but the `a' sounds the
same. Finally, for `o' and `u', the fundamental frequency is much more
noticable as they are lower-sounding notes, but very many higher sounds
are present, kind of the same sound that is the main one you hear when
humming.

\section{Musical Harmonics}

\subsection{Procedure and Results}

Finally, the same recording setup as before was used to record two musical
instruments playing the same note. The two selections were a classical
guitar and a single-string. The frequency response of both of these
instruments playing a C# can be seen in \ref{instruments_ffts}.

\begin{figure}[h]
\includegraphics[width=0.44\textwidth]{../Images/l5_f_extra.png}
\caption{\label{instruments_ffts} The frequency response of the two
selected instruments. The locations of peaks used in further analysis
are marked with dots. }
\end{figure}

It is clear that these instruments are indeed quite different from their
frequency response. Most prominent is the comparison between the most
prominent peaks. The guitar's strongest harmonic is very low, the second
harmonic. This makes sense given the construction of the instrument -
there is a very large, hollow body situated just under the location
where one strums, which serves to amplify lower frequencies and increase
the richness of the sound. The single-string's strongest harmonic is much
higher, the fifth harmonic. This makes sense given its construction is just
a single string drilled into a 1/2x3 plank of wood. There is nothing to
amplify the lower frequencies, and the result is a much tinnier sound. \\

The further point of comparison between the two instruments is the
amount of harmonics. The guitar has a strong second harmonic (and the
fundamental frequency is also observable), as well four or five more,
much quieter higher harmonics. The single-string has a second, very
significant harmonic at 1500 kHz, and another one at 2000 kHz. This
is much higher than any of the harmonics with a significant amplitude
for the guitar had. In addition, there are just a slew of harmonics,
there's something present at essentially every single harmonic all
the way up to 3000 kHz. \\

To clarify, all musical notes have a single fundamental frequency, the
lowest frequency, and a series of harmonics which are integer multiples
of the fundamental. It is doubtful that any musical instrument
intentionally has more than one fundamental, as it would sound like
playing two discordant notes at the same time. \\

A summary of the above FFT plot can be seen in \ref{harmonics}, where
each frequency was divided by the fundamental in order to find the
integer factor, or the harmonic number. Each harmonic was also
converted to a musical note.

\begin{figure}[h]
\includegraphics[width=0.44\textwidth]{../Images/l5_f.png}
\caption{\label{harmonics} Normalized plot of the harmonics
of both instruments and their relative amplitudes. }
\end{figure}

This plot clarifies the difference between the two instruments. The
beauty of the guitar as a musical instrument is really striking,
with the C#, the fundamental frequency, harmonizing with a C#
one octave up, a G# which is the fifth half-step below the C#,
and again with another G# and C# in even higher registers.
For the single-string, by contrast,
while the tuner appropriately picked up the lowest
note, the C# to tune to, the most predominant notes are the
B and G, where the B is a very awkward two half-steps below
the C#, and the G is a very awkward 6 half-steps below the C#.
This explains why no matter how tuned it was, the single-string
always sounded out of tune and discordant. \\

For the purpose of demonstration, a long cardboard tube was
used to create a flute-like instrument by cutting a hole near
one end and rounding it with tape. A note was successfully
produced with great effort, which was recorded using a laptop
microphone and saved as an mp3. The A(N) is shown in \ref{flute?}.

\begin{figure}[h]
\includegraphics[width=0.44\textwidth]{../Images/l5_optional_flute_harmonics.png}
\caption{\label{flute?} Normalized plot of the harmonics
of a makeshift flute and their relative amplitudes. }
\end{figure}

\begin{figure}[h]
\includegraphics[width=0.44\textwidth]{../Images/l5_optional_flute.jpg}
\caption{\label{flute} Picture of the makeshift flute. }
\end{figure}

It is not clear from seeing the normalized scale, but only one of
these notes was audible, the fifth harmonic. The sound of air
rushing past did seem to produce measurable frequencies which
did correspond to harmonics of a fundamental (corresponding
to the length of the tube), but in reality these other harmonics
just sounded like air blowing through a cardboard tube. It is
unexpected that the main note is the fifth harmonic because
the hole was located about one seventh of the way down the tube,
not one fifth. From this it seems like the point of the tube
where the note was produced was inside the tube. This perhaps
could help design improvements, as the length could be cut down
to match this length of five times the distance from the hole
to the first end. An image is shown in \ref{flute}.

\section{Summary}

The characteristics of several acoustic signals,
and the inherent constraints of Fourier analysis as it pertains
to sample rate, Nyquist frequency, and spectral leakage, were
explored. It was observed that a signal sampled at too
low a sample rate will alias into the lower frequency ranges,
making the signal look like a lower frequency signal.
It was also observed that, as long as the Nyquist frequency
corresponding to the sample rate is still high enough
to observe the signal, more sine wave cycles is more
important than more samples per second in determining
frequency with very high certainty, or low linewidth. \\

Several acoustic noises were analyzed, and their frequency-
domain characteristics were linked to the character of the
sound that can be observed through listening.
Two tuning forks were struck simultaneously, in order to
observe the slight difference in their exact tuning through
the pattern of constructive and destructive interference
that it causes, known as acoustic ``beat". This beat was
observed with a period of about 0.6 seconds. \\

A human whistle was analyzed, and it was found to be very
similar in the frequency domain to a single sine wave.
Two subjects produced a whistle at the same note, and
these whistles were sound to be more or less identical.
This was linked to the physiological way that whistles
are produced by humans, which inherently produces only
a single oscillating pressure wave with no harmonics. \\

Several vowel sounds were found to be distinguishable through
a series of frequency-domain features, including a plosive
sound formed by releasing pressure to create the sound,
nasal harmonics, numbers of peaks, and the frequency
of the highest peak. \\

Several musical instruments were analyzed, two of which
both create sound using strings and were playing the same
note at time of recording, and their timbre was revealed
through Fourier analysis, explaining the rich and deep sound
of the guitar and the tinny and discordant sound of the
single-string. \\

Fourier analysis is truly an insightful tool in the
realm of acoustic physics, and it was all enabled
by Fourier, and the incredible algorithm known as
the Fast-Fourier-Transform.

\begin{thebibliography}{9}
\bibitem{fft}
Wikipedia, Fast Fourier Transform: \\
\href{https://en.wikipedia.org/wiki/Fast_Fourier_transform#History}{https://en.wikipedia.org/wiki/FastFouriertransform}

\bibitem{whistling}
Wall Street Journal, The Secret of Whistling \\
\href{https://www.wsj.com/?mod=wsjheader_logo}{https://www.wsj.com/?mod=wsjheader_logo}

\bibitem{speech}
Royal Society Publishing, Bioacoustics of Human Speech \\
\href{https://royalsocietypublishing.org/doi/10.1098/rspb.2019.1116}{https://royalsocietypublishing.org/doi/10.1098/rspb.2019.1116}
\end{thebibliography}

\end{document}
%
% ****** End of file apstemplate.tex ******


\documentclass{article}
\usepackage{fullpage,graphicx}
\usepackage{amsmath,amsfonts,amsthm,amssymb,multirow}
\usepackage{algorithmic,url}
\usepackage{tikz}
\usetikzlibrary{decorations.pathreplacing, shapes,positioning}
\usepackage[ruled,vlined,commentsnumbered,titlenotnumbered]{algorithm2e}
\newcommand{\expecting}[1]{\noindent{[\textbf{We are expecting:} \em #1\em]}}
\newcommand{\hint}[1]{\noindent{[\textbf{HINT:} \em #1\em]}}
\newcommand{\pts}[1]{\textbf{(#1 pt.)}}

\begin{document}
\noindent
CS 161 \hfill \textbf{Problem Set 6} \newline
{Winter 2019} \hfill \textbf{Due:} Friday, March 8, 2019, at 3pm on Gradescope

\noindent
\rule{\linewidth}{0.4pt}
\noindent
\section*{Exercise}
Please do the exercises on your own.

\noindent
\rule{\linewidth}{0.4pt}
\begin{enumerate}

\item\pts{8} Let $A$ be an array of length $n$ containing real numbers.  A \em longest increasing subsequence \em (LIS) of $A$ is a sequence $0 \leq i_0 < i_1 < \ldots i_\ell < n$ so that $A[i_0] < A[i_1] < \cdots < A[i_\ell]$, so that $\ell$ is as large as possible.  For example, if
$A = [6,3,2,5,6,4,8]$, then a LIS is $i_0 = 1, i_1 = 3, i_2 = 4, i_3 = 6$ corresponding to the subsequence $3,5,6,8$.  (Notice that a longest increasing subsequence doesn't need to be unique).

In the following parts, we'll walk through the recipe that we saw in class for coming up with DP algorithms to develop an $O(n^2)$-time algorithm for finding an LIS.
\begin{enumerate}
\item\pts{2} \textbf{(Identify optimal sub-structure and a recursive relationship).}  We'll come up with the sub-problems and recursive relationship for you, although you will have to justify it.  Let $D[i]$ be the length of the longest increasing subsequence of $[A[0], \ldots, A[i]]$ that ends on $A[i]$.
Explain why
\[ D[i] = \max\left(\{ D[k] + 1\,:\, 0 \leq k < i, A[k] < A[i] \} \cup \{1\} \right). \]

\expecting{A short informal explanation (a paragraph or so).  It might be good practice to write a formal proof, but this is not required for credit.}

\item\pts{3} \textbf{(Develop a DP algorithm to find the value of the optimal solution)} Use the relationship about to design a dynamic programming algorithm returns the \em length \em of the longest increasing subsequence.  Your algorithm should run in time $O(n^2)$ and should fill in the array $D$ defined above.

\expecting{Pseudocode.  No justification is required.}

\item \pts{3} \textbf{(Adapt your DP algorithm to return the optimal solution)} Adapt your algorithm above to return an actual LIS instead of its length.  Your algorithm should run in time $O(n^2)$.

\expecting{Pseudocode \textbf{AND} a short English explanation of what your algorithm is doing.  You do not need to justify that it is correct.}

\end{enumerate}

\textbf{Note:} Actually, there is an $O(n\log(n))$-time algorithm to find an LIS, which is faster than the DP solution in this exercise!

\end{enumerate}
\newpage
\noindent
\rule{\linewidth}{0.4pt}
\section*{Problems}

You may talk with your fellow CS161-ers about the problems.  However:
\begin{itemize}
	\item Try the problems on your own \em before \em collaborating.
	\item Write up your answers yourself, in your own words.   You should never share your typed-up solutions with your collaborators.
	\item If you collaborated, list the names of the students you collaborated with at the beginning of each problem.
\end{itemize}

\noindent
\rule{\linewidth}{0.4pt}

\begin{enumerate}
\setcounter{enumi}{1}

\item \pts{7} \textbf{[MinElementSum.]}
Consider the following problem, \textsc{MinElementSum}.
\begin{quote}
\textsc{MinElementSum}$(n,S)$:
Let $S$ be a set of positive integers, and let $n$ be a non-negative integer.  Find the minimal number of elements of $S$ needed to write $n$ as a sum of elements of $S$ (possibly with repetitions).  If there is no way to write $n$ as a sum of elements of $S$, return \texttt{None}.
\end{quote}

For example, if $S = \{1,4,7\}$ and $n = 10$, then we can write $n = 1 + 1 + 1 + 7$ and that uses four elements of $S$.  The solution to the problem would be ``4."   On the other hand if $S = \{4,7\}$ and $n=10$, then the solution to the problem would be ``\texttt{None},'' because there is no way to make $10$ out of $4$ and $7$.

Your friend has devised a divide-and-conquer algorithm to solve \textsc{MinElementSum}.  Their pseudocode is below.
\begin{verbatim}
def minElementSum(n, S):
     if n == 0:
         return 0
     if n < min(S):
         return None
     candidates = []
     for s in S:
         cand = minElementSum( n-s, S )
         if cand is not None:
              candidates.append( cand + 1 )
     if len(candidates) == 0:
         return None
     return min(candidates)
\end{verbatim}

Your friend's algorithm correctly solves \textsc{MinElementSum}.  Before you start doing the problems on the next page, it would be a good idea to walk through the algorithm and to understand what this algorithm is doing and why it works.

\vfill \hfill [Questions on next page]
\newpage

\begin{enumerate}
\item \pts{1} Argue that for $S = \{1,2\}$, your friend's algorithm has exponential running time.  (That is, running time of the form $2^{\Omega(n)}$).
You may use any statement that we have seen in class.

\hint{Consider the example of the Fibonacci numbers that we saw in class.}

\expecting{
\begin{itemize}
\item A recurrence relation that the running time of your friend's algorithm satisfies when $S = \{1,2\}$.
\item A convincing argument that the closed form for this expression is $2^{\Omega(n)}$.  You do not need to write a formal proof.  \end{itemize}}

\item \pts{3} Turn your friend's algorithm into a top-down dynamic programming algorithm.
Your algorithm should take time $O(n|S|)$.

\hint{Add an array to the pseudocode above to prevent it from solving the same sub-problem repeatedly.}

\expecting{\begin{itemize}
\item Pseudocode \textbf{AND} a short English description of the idea of your algorithm.
\item An informal justification of the running time.\end{itemize}}

\item \pts{3} Turn your friend's algorithm into a bottom-up dynamic programming algorithm.
Your algorithm should take time $O(n|S|)$.

\hint{Fill in the array you used in part (b) iteratively, from the bottom up.}

\expecting{\begin{itemize}
\item Pseudocode \textbf{AND} a short English description of the idea of your algorithm.
\item An informal justification of the running time.\end{itemize}}
\end{enumerate}

\newpage
\item \pts{6} \textbf{[Rotten Tomatoes.]}
You are planting tomato plants in a garden, and the garden has $n$ spots arranged in a line.  Different spots in the garden will result in different quality tomatoes: suppose that the location $i$ will result in tomatoes of deliciousness $T[i]$, where $T[i]$ is a positive integer.  Further, you cannot plant two plants directly next to each other, because they will compete for resources and wilt.
Your goal is to create the most deliciousness possible (summed up over all of the tomato plants).

\textbf{For example,} if the input was
$ T = [21,4,6,20,2,5],$
then you should plant tomatoes in the pattern
\begin{center}
    \begin{tikzpicture}
\foreach \i in {1,2,3,4,5,6}
{
\draw (\i -1, 0) rectangle (\i, 1);
}
\foreach \i in {1,4,6}
{
\node at (\i -.5, .5) {\includegraphics[width=.8cm]{th.jpeg}};
}
\end{tikzpicture}
\end{center}
and you would obtain deliciousness $21 +20+5 = 46$.  You would \textbf{not} be allowed to plant tomatoes in the pattern
\begin{center}
\begin{tikzpicture}
\foreach \i in {1,2,3,4,5,6}
{
\draw (\i -1, 0) rectangle (\i, 1);
}
\foreach \i in {1,2,4,6}
{
\node at (\i -.5, .5) {\includegraphics[width=.8cm]{th.jpeg}};
}
\end{tikzpicture}
\end{center}
because there are two tomato plants next to each other.

In this question, you will
design a dynamic programming algorithm which runs in time $O(n)$ which takes as input the array $T$ and returns the maximum deliciousness possible given $T$.  Do this by answering the two parts below.

\begin{enumerate}
	\item \pts{3} What sub-problems will you use in your dynamic programming algorithm?  What is the recursive relationship which is satisfied between the sub-problems? What is the base case for this recursive relationship?

\expecting{\begin{itemize}
\item A clear description of your sub-problems.
\item A recursive relationship that they satisfy, along with a base case.
\item An informal justification that the recursive relationship is correct.
\end{itemize}}

	\item \pts{3} Write pseudocode for your algorithm.  Your algorithm should take as input the array $T$, and return a single number which is the maximum amount of deliciousness possible.  Your algorithm does not need to output the optimal way to plant the tomatoes.

\expecting{Pseudocode \textbf{AND} a clear English description.  You do not need to justify that your algorithm is correct, but correctness should follow from your reasoning in part (a).}
\end{enumerate}

\newpage
\item \pts{6} \textbf{[Fish fish eat eat fish.] }
Plucky the Pedantic Penguin enjoys fish, and he has discovered that on some days the fish supply is better in Lake A and some days the fish supply is better in Lake B.
He has access to two tables $A$ and $B$, where $A[i]$ is the number of fish he can catch in Lake A on day $i$, and $B[i]$ is the number of fish he can catch in Lake B on day $i$, for $i=0,\ldots,n-1$.

If Plucky is at Lake $A$ on day $i$ and wants to be at Lake $B$ on day $i+1$, he may pay $L$ fish to a polar bear who can take him from Lake $A$ to Lake $B$ overnight; the same is true if he wants to go from Lake $B$ back to Lake $A$.
The polar bear does not accept credit, so \textbf{Plucky  must pay \em before \em he travels}. (And if he cannot pay, he cannot travel).

Assume that when day $0$ begins, Plucky is at Lake $A$, and he has zero fish.  Also assume that $A[i]$ and $B[i]$ are positive integers for $i =0,\ldots,n-1$ and that $L$ is also a positive integer.

\fbox{
\begin{minipage}{0.9\textwidth}
For example, suppose that $n=3$, $L=3$, and that $A$ and $B$ are given by
$A = [5,2,3]$ and  $B = [2,7,4].$
Then Plucky might do:
\begin{center}
\begin{tikzpicture}
\node at (1, .6) {Lake $A$};
\node at (7, .6) {Lake $B$};
\begin{scope}[yscale=.8]
\draw [decorate,decoration={brace,amplitude=10pt},xshift=-4pt,yshift=0pt]
(0,-2.4) -- (0,.4)node [black,midway,xshift=-30pt] {Day 0};
\node(p0) at (1,0) {\includegraphics[width=.5cm]{plucky}};
\node(p1) at (1,-2) {\includegraphics[width=.5cm]{plucky}};
\node at (1.7, 0) {$0$ fish};
\node at (1.7, -1.7) {$5$ fish};
\draw[dashed] (p0) to node[right,pos=0.5] {$+5$} (p1);
\end{scope}
\begin{scope}[yscale=.8,yshift=-3cm]
\draw [decorate,decoration={brace,amplitude=10pt},xshift=-4pt,yshift=0pt]
(0,-2.4) -- (0,.4)node [black,midway,xshift=-30pt] {Day 1};
\node(p2) at (7,0) {\includegraphics[width=.5cm]{plucky}};
\node(p3) at (7,-2) {\includegraphics[width=.5cm]{plucky}};
\node at (7.7, 0) {$2$ fish};
\node at (7.7, -2) {$9$ fish};
\draw[dashed] (p2) to node[right,pos=0.5] {$+7$} (p3);
\end{scope}
\begin{scope}[yscale=0.8, yshift=-6cm]
\draw [decorate,decoration={brace,amplitude=10pt},xshift=-4pt,yshift=0pt]
(0,-2.4) -- (0,.4)node [black,midway,xshift=-30pt] {Day 2};
\node(p4) at (7,0) {\includegraphics[width=.5cm]{plucky}};
\node(p5) at (7,-2) {\includegraphics[width=.5cm]{plucky}};
\node at (7.7, 0) {$9$ fish};
\node at (7.7, -2) {$13$ fish};
\draw[dashed] (p4) to node[right,pos=0.5] {$+4$} (p5);
\end{scope}
\draw[dashed] (p1) to node[above,pos=0.5] {$-3$} (p2);
\end{tikzpicture}
\end{center}

So Plucky's total fish at the end of day $n-1=2$ is $13$.
\end{minipage}
}

In this question, you will design an $O(n)$-time dynamic programming algorithm that finds the maximum number of fish that Plucky can have at the end of day $n-1$.   Do this by answering the two parts below.

\begin{enumerate}
	\item \pts{3} What sub-problems will you use in your dynamic programming algorithm?  What is the recursive relationship which is satisfied between the sub-problems?  What is the base case for this recursive relationship?

\expecting{\begin{itemize}
\item A clear description of your sub-problems.
\item A recursive relationship that they satisfy, along with a base case.
\item An informal justification that the recursive relationship is correct.
\end{itemize}}

	\item \pts{3} Design a dynamic programming algorithm that takes as input $A,B,L$ and $n$, and in time $O(n)$ returns the maximum number of fish that Plucky can have at the end of day $n-1$.

\expecting{Pseudocode \textbf{AND} a short English description of what it does and why it works, and a justification of why it runs in time $O(n)$.}
\end{enumerate}

\newpage
\textbf{This problem set is long enough}, but more practice with dynamic programming is always good.  If you'd like another practice problem (or just miss Socrates the Scientific Squirrel), you can do the problem below for one bonus point.  To get the bonus point, you should complete the whole problem.
\item \pts{NOT REQUIRED, WORTH 1 BONUS} \textbf{[Nuts! (part 2)]}

\begin{minipage}{.5\textwidth}
Socrates the Scientific Squirrel (from HW1) is back!
Recall that Socrates lives in a very tall tree with $n$ branches, and she wants to find out what is the lowest branch $i \in \{1, \ldots, n\}$ so that an acorn will break open when dropped from branch $i$.  If an acorn breaks open when dropped from branch $i$, then an acorn will also break open when dropped from branch $j$ for any $j \geq i$.
(If no branch will break an acorn, Socrates should return $n+1$).
\newline \newline
The catch is that, once an acorn is broken open, Socrates will eat it immediately and it can't be dropped again.
\newline\newline
In HW1, you designed a strategy for Socrates to use very few drops, given that she had $k$ acorns.  She was pretty pleased with that algorithm, but now she wants to compute \em exactly \em the number of drops she needs, in the worst case.
\end{minipage}
\hspace{.5cm}
\begin{minipage}{.4\textwidth}
\hfill
\begin{tikzpicture}
\node{
\includegraphics[width=6cm]{squirrel}};
\node(bn) at (-2.5,1.8) {Branch $n$};
\node(b0) at (-2.2,-1.25) {Branch $1$};
\node(b1) at (-2.2,-.55) {Branch $2$};
\draw(b0) -- (-.3, -1.25);
\draw(b1) -- (-.7, -.55);
\end{tikzpicture}
\end{minipage}

\vspace{.5cm}
For $n \geq 0$ and $k \geq 1$, let $D[n,k]$ be the \em optimal worst-case number of drops \em that Socrates needs to determine the correct branch out of $n$ branches using $k$ acorns.    That is, $D[n,k]$ is the number of drops that the best algorithm would use in the worst-case.
\begin{enumerate}
\item For any $1 \leq j \leq k$, what is $D[0,j]$? What is $D[1,j]$?  For any $1 \leq m \leq n$, what is $D[m,1]$?
(Note that if $n=0$, then Socrates needs zero drops to identify the correct branch, since there are no branches).

\expecting{Your answer.  No justification required.}

\item Suppose the best algorithm drops the first acorn from branch $x \in \{1, \ldots, n\}$. Write a formula for the optimal worst-case number of drops remaining in terms of $D[x-1,k-1]$ and $D[n-x,k]$.

\expecting{Your formula and an informal explanation of why this formula is correct.}

\item  Write a formula for $D[n,k]$ in terms of values $D[m,j]$ for $j \leq k$ and $m < n$.

\hint{Use part (b).}

\expecting{Your formula and an informal explanation of why this formula is correct.}

\item Design a dynamic programming algorithm which will compute $D[n,k]$ in time $O(n^2k)$.

\hint{Use parts (a) and (c).}

\expecting{Pseudocode \text{AND} an English description of how it works, as well as an informal justification of the running time.  You do not need to justify that it is correct.}
\end{enumerate}

\end{enumerate}
\end{document}