\chapter{Generation of Band Structures}
\section{Program BZ}
\subsection{Description} \index{BZ!description of}
Unlike molecules, whose eigenvalue spectrum consists of infinitely sharp lines
(Kronecker-$\delta$ type), the eigenvalues of solids form bands.  These bands
are conventionally represented by Brillouin Zones (BZ).  For a polymer, the BZ
consists of a line, for a layer structure, a surface, and for a solid, a
three-dimensional shape.  The dimensions of the BZ are inverse distance: if two
polymers have unit cells of 10 and 8 \AA, then the ratio of their unit cell
translation vectors is 1.25:1, and the ratio of their BZ's is 1:1.25.

Although MOPAC can generate all the information necessary  to generate
band-structures, for ease of use this job is given to a special program called
BZ. \  MOPAC is designed to run in batch mode, but drawing band-structures is
an interactive operation.

Before BZ can be run, a MOPAC calculation must first be run in order to
generate the data needed by BZ. \  Most of this data is invisible to the user,
but the user must supply to MOPAC one or two data which BZ will use.  These
data are:

\begin{description}
\item[\comp{MERS=($n_1$,$n_2$,$n_3$)}]~\\
(See Chapter~\ref{makpol:mers}  and Section~\ref{mopac:mers})  BZ needs to know how
the Fock matrix is organized, and  \comp{MERS} gives the number of unit cells
in each direction.  MOPAC uses the keyword \comp{MERS} as the prompt to write
out a file for use by BZ.  Within MOPAC, \comp{MERS} has no other use.
\index{MERS}
\item[\comp{BCC} \normalfont{(optional)}]~\\
Like \comp{MERS}, \comp{BCC} is not used by MOPAC. \comp{BCC} (see
Chapter~\ref{makpol:bcc})  indicates that the system is Body-Centered-Cubic; in
other words, that every odd unit cell is missing.  If the keyword \comp{BCC} is
present, MOPAC informs BZ that the system is Body-Centered-Cubic.
\end{description}

BZ is an interactive utility program.  It can perform three types of
calculation:
\begin{itemize}
\item  Points in $k$-space are to be studied.
\item  Lines in $k$-space are to be drawn.
\item  Surfaces in $k$-space are to be drawn.
\end{itemize}

\subsection{Data input for BZ}\index{Data! for BZ}
Once the MOPAC calculation has been completed, the band structure can be
generated. The instruction to generate band structures is:

\comp{bz $<$filename$>$}

where \comp{$<$filename$>$} is the name of the file. This must be the same as
that used for the MOPAC calculation.

When BZ starts, it invites the user to specify the type
of calculation to be performed. The allowed types are:
\begin{description}
\item[0] Points in $k$-space are to be studied.
\item[1] Lines in $k$-space are to be drawn.
\item[2] Surfaces in $k$-space are to be drawn.
\end{description}

Instead of supplying data at the prompt, a data set can be supplied, using the
 command:

\comp{bz $<$filename$>$ $<$filename2$>$}

A second file, called \comp{$<$filename2$>$.bz}, must exist.  This file will
contain the data that would otherwise be supplied by the prompt.

\index{Help! with BZ}
In addition, the user is invited to enter the number `3' to request help. Help
describes diagnostic key-words which allow an interested user to follow the
calculation.

Some of the operations in BZ are very sensitive to perturbations in the Fock
matrix, specifically any perturbations which lower the symmetry.  The first
thing BZ does, therefore, is to restore symmetry.  To do this, BZ reads in a
list of symmetry operations and symmetrizes the Fock matrix.

At the present time, the user must supply all operations of the group.
Eventually this will be done automatically by the program, but for now the job
of defining symmetry is given to the user.

\subsubsection{Structure of $<$filename$>$.ops}
\index{Space group!operations}
This file holds the definitions of the symmetry operations for the space-group.
The format is `free format' - one or more spaces are treated as one space. The
first line should contain one of the following two words: ``Cartesian'' or
``Crystallographic''.  If ``Cartesian'' is selected, then the rotation axis is
relative to the Cartesian coordinates of the atoms; if ``Crystallographic'' is
selected, then the rotation axis is relative to the crystal coordinates of the
atoms.  (In practice, ``Cartesian'' is {\em much} easier to use.)

Each operation is defined by one line and is composed of 12 data.
In order, these data are:
\begin{enumerate}
\item A `1' or `0'.  `1' if the operation is composed of the inversion operation times
a rotation, `0' if the operation is a pure rotation.
\item The non-primitive translations.  These are given as their reciprocals, thus
a (0.5,0.5,0.0) translation would be entered as `2~2~0'. The absence of
a non-primitive translation is indicated by a zero. (three numbers)
\item The rotation expressed as a fraction of a circle.
\item The axis about which the operation is performed. Units are
Cartesian coordinates, or, if ``Crystallographic'' is selected, the crystal
coordinates. (three numbers)
\item The center about which the operation is performed. Units are
Cartesian coordinates, in Angstroms. (three numbers)
\item A text string describing the operation.
\end{enumerate}

The operations list is terminated by an operation which has a `2' for the
inversion option.

Examples of these operations are illustrated in Table~\ref{sgo}
by the 10 classes of operation for the O$_h$ group in O$_h^7$.

The Fock matrix will be symmetrized if, and only if, every operation of
the group is represented once.  For O$_h$, this would involve a total of 49
lines, 48 for the operations of O$_h$, and one line to terminate the operations
file.

% 24 lines, including this one
\begin{table}
\caption{\label{sgo}
 Space-Group Operations of O$_h^7$}
\index{oh7@{$O_h^7$}|ff}
\begin{center}
\begin{tabular}{lllllllrrrll}\\ \hline
i& \multicolumn{3}{c}{N.P.T}  & Rotation & \multicolumn{3}{c}{Axis of Rotation} &
 \multicolumn{3}{c}{Center of Operation}& Name\\ \hline
0& 0& 0& 0& 0.0     &  0.0&0.0 &1.0 &  0.0& 0.0& 0.0 &  Identity  \\
0& 0& 0& 0& 0.3333  &  1.0&1.0 &1.0 &  0.0& 0.0& 0.0 &  C$_3$  \\
0& 0& 0& 0& 0.5     &  1.0&0.0 &0.0 &  0.0& 0.0& 0.0 &  C$_2$=C$_4^2$  \\
0& 2& 2& 2& 0.5     &  1.0&0.0 &-1.0 & 0.0& 0.0& 0.0 &  C$_2$  \\
0& 2& 2& 2& 0.25    &  0.0&0.0 &1.0 &  0.0& 0.0& 0.0 &  C$_4$  \\
1& 2& 2& 2& 0.0     &  0.0&0.0 &1.0 &  0.0& 0.0& 0.0 &  Inversion  \\
1& 0& 0& 0& 0.25    &  0.0&0.0 &1.0 &  0.0& 0.0& 0.0 &  S$_4$  \\
1& 0& 0& 0& 0.5     &  1.0&1.0 &0.0 &  0.0& 0.0& 0.0 &  $\sigma_d$  \\
1& 2& 2& 2& 0.333333&  1.0&1.0 &1.0 &  0.0& 0.0& 0.0 &  S$_6$  \\
1& 2& 2& 2& 0.5     &  0.0&0.0 &1.0 &  0.0& 0.0& 0.0 &  $\sigma_h$  \\
2& 0& 0& 0& 0.0     &  0.0&0.0 &1.0 &  0.0& 0.0& 0.0 &  End  \\ \hline
\end{tabular}

N.P.T.: Non-Primitive Translation \end{center}
\end{table}

\subsection{Calculating Points in $k$-space}
\index{ksp@{$k$-space}!calculating points in}

A point in $k$-space is specified by one number for a polymer, two
numbers for a layer system, and three numbers for a solid.   All symmetry
points and lines for diamond are shown in Table~\ref{sod} and Figure~\ref{oh7}.
% 21 lines, including this one
\begin{figure}
\begin{makeimage}
\end{makeimage}
% \setlength{\unitlength}{0.1cm}
\begin{center}
% \begin{picture}(100,100)
% \put(62,47){$\Gamma$}
% \put(106,42){X}
% \put(108,68){W}
% \put(107.5,58){$\longleftarrow$Z}
% \put(96.5,54){S$\longrightarrow$}
% \put(84,44){$\Delta$}
% \put(100.2,59.5){U}
% \put(76,71){L}
% \put(92,71){Q}
% \put(56,80){K}
% \put(61,63){$\Sigma$}
% \put(69,59){$\Lambda$}
% %\put(14,38){\psfig{figure=oh7.ps}}
% \put(14,38){\includegraphics{oh7}}
% \end{picture}
\includegraphics{oh7}
\end{center}
\caption{\label{oh7}Brillouin zone for Diamond}
\end{figure}
A ``random'' point is indicated by the number 0.123.  (Note: 0.377 = 0.500 -
0.123)

These high-symmetry points have associated subgroup symmetries, thus $\Gamma $
has the symmetry O$_h$, $\Lambda $ has the symmetry C$_{3v}$, and X has the
symmetry D$_{4h}$.

\subsubsection{Little Groups}\index{Little groups|(}
The symmetry operations supplied in \comp{ $<$filename$>$.ops} are used to
generate a little group of the space group.  A ``little group'' is the
sub-group of the space-group at a specific point in $k$-space.  There are too
many little groups to allow all the irreducible representations to be labeled.
In addition, there is no generally-accepted convention for describing them.
Because of this, the little group is given as a group-table.  Thus the little
group for $\Gamma$ would have the form shown in Table~\ref{lgd}.

% 22 lines, including this line
\begin{table}
\begin{center}
\caption{\label{sod} Symmetry Points in $k$-space for Diamond}
\begin{tabular}{lllcc} \\ \hline
\multicolumn{3}{c}{Point} & Little Group* & Symbol\\ \hline
  0.000& 0.000& 0.000  & O$_h$ &  $\Gamma$\\
  0.500& 0.000& 0.000  & (D$_{4h}$)&X\\
  0.500& 0.250& 0.000  & (C$_{2v}$)&W\\
  0.500& 0.125& 0.125  & (C$_{2v}$)&U\\
  0.375& 0.375& 0.000  & (C$_{2v}$)&K\\
  0.250& 0.250& 0.250  & D$_{3d}$ &L\\
  0.123& 0.000& 0.000  & C$_{4v}$ &$\Delta $\\
  0.500& 0.123& 0.000  & (C$_{2v}$) &Z\\
  0.500& 0.045& 0.045  & (C$_{2v}$)&S\\
  0.123& 0.123& 0.000  & C$_{2v}$ &$\Sigma $\\
  0.123& 0.250& 0.377  &  C$_{2}$ &Q\\
  0.123& 0.123& 0.123  & C$_{3v}$ &$\Lambda $\\ \hline
\end{tabular}

* Point groups in parentheses only approximate little groups.\end{center}\end{table}
\begin{table}
\begin{center}
\caption{\label{lgd} Little Group for $\Gamma$ for Diamond}
\begin{tabular}{lrrrrrrrrrrrr}\\ \hline
Level & Energy & $\Gamma$ & E & C$_3$ & C$_2$=C$_4^2$ & C$_2$ & C$_4$
 & I & S$_4$ & $\sigma_d$ & S$_6$
&$\sigma_h$ \\ \hline
  1& -58.0408& 1& 1& 1& 1& 1 &1&1&1&1&1&1 \\
  2&  -9.4687& 2& 3& 0&-1& 1&-1&3&-1&1&0&-1 \\
  3&   0.9807& 3& 3& 0&-1&-1&1&-3&-1&1&0&1 \\
  4&   4.1933& 4& 1& 1& 1&-1&-1&-1&1&1&-1&-1\\ \hline
\end{tabular}\end{center} \end{table}

From this we see that there are four different irreducible representations: 1,
2, 3, and 4. These representations can be equated with those of the O$_h$
point-group, so 1 and 4, being non-degenerate, become $a$, while 2 and 3, being
3-fold degenerate, become $t$. So far we have ($a$, $t$, $t$, $a$).  The effect
of inversion on the eigenfunctions allows us to assign {\em gerade} and  {\em
ungerade}, thus ($a_g$, $t_g$, $t_u$, $a_u$), while C$_4$ resolves the
``1''-``2'' nature of the representations: ($a_{1g}$, $t_{2g}$, $t_{1u}$,
$a_{2u}$).

Inspection of the eigenvectors reveals, as expected, that the two
$a$ representations can be identified with the $s$ atomic orbitals, and the two
$t$ representations, with the six $p$ atomic orbitals.

For points other than $\Gamma$, the little groups become complex. Consider a
point on $\Delta$, the line connecting $\Gamma$ and X, or (0,0,0) and
(1/2,0,0). The little group for (0.123,0,0) has the form shown in
Table~\ref{dig}.
\begin{table}
\begin{center}
\caption{\label{dig} Little Group for $\Delta$ for Diamond}
 \index{Diamond!little group|(}
\begin{tabular}{lrlrrrrr} \\ \hline
Level&Energy&$\Gamma$&E &C$_2$=C$_4^2$ &C$_4$&$\sigma_d$
&$\sigma_h$  \\  \hline
  1& -54.2893 &1 & 1& 1& $\theta$    &   1& $\theta$   \\
  2& -10.2758 &2 & 2&-2& 0           &   0& 0              \\
  3& -10.1336 &3 & 1& 1&-$\theta$    &   1& -$\theta$   \\
  4&   0.9087 &1 & 1& 1& $\theta$    &   1& $\theta$   \\
  5&   1.5003 &2 & 2&-2& 0           &   0& 0  \\
  6&   3.7878 &3 & 1& 1&-$\theta$    &   1& -$\theta$  \\ \hline
\end{tabular}\end{center}\end{table}
Here $\theta$ = $e^{-ik/2\pi}$.

As is seen, complications arise for those operations which involve
\index{Characters!complex}\index{Complex characters} non-primitive
translations,\index{Translations!non-primitive} \index{Non-primitive
translations} e.g.\  C$_{4}$ and $\sigma_h$, when points other than $\Gamma$ are
studied. The complex phase-factor can cause interpretation of the group
characters to be difficult.  One option is to correct for the phase-factor by
multiplying the character by $e^{ik/2\pi}$. This would make the little group
for $\Delta$ easier to read (Table~\ref{mdig}).

\begin{table}
\begin{center}
\caption{\label{mdig} Modified Little Group for $\Delta$ for Diamond}
\begin{tabular}{lrlrrrrr} \\ \hline
Level&Energy&$\Gamma$&E &C$_2$=C$_4^2$ &C$_4$&$\sigma_d$
&$\sigma_h$  \\ \hline
  1& -54.2893 &1 & 1& 1& 1     &   1& 1    \\
  2& -10.2758 &2 & 2&-2& 0     &   0& 0              \\
  3& -10.1336 &3 & 1& 1&-1     &   1& -1    \\
  4&   0.9087 &1 & 1& 1& 1     &   1& 1    \\
  5&   1.5003 &2 & 2&-2& 0     &   0& 0  \\
  6&   3.7878 &3 & 1& 1&-1     &   1& -1   \\ \hline
\end{tabular}\end{center}\end{table}

However, for some little groups, this procedure may cause complications. Thus,
at $L$, the inversion operation becomes sensitive to the point chosen, e.g.
(0.25,0.25,0.25) will give a different character for the $I$ operation than
(0.25,0.25,-0.25).

A third option is to assume that the lowest-lying level represents the totally
symmetric representation.  (Note: this is different from transforming as the
totally symmetric representation.  Only one point, the $\Gamma$-point, can ever
contain a totally symmetric representation.) By making that assumption, all
characters can be related to those of the  lowest-lying level.

Users are given key-words which select these alternatives to the basic
character tables when the $k$-point is specified.  The key-words are:

\begin{description}
\index{One! use in BZ}\index{BZ!use of ``one''}
\item[\comp{one}] Assume the lowest energy level is totally symmetric.  All operations
involving non-primitive translations are then multiplied by a (complex) factor
which will make the lowest energy level totally symmetric. Example: \comp{0.123 0 0 one}.

\index{Byk! use in BZ}\index{BZ!use of ``byk''}
\item[\comp{byk}] Multiply all operations which involve non-primitive translations by
a phase factor (``byk''---``multiply by k'')  which depends on the current value
of $k$. Example: \comp{0.123 0 0 byk}.
\end{description}

Using the points option, assignment of the symmetry of lines and points in
$k$-space becomes very easy.

\subsection{Lines in $k$-space}

A line  in $k$-space is specified by two numbers for a polymer, four numbers
for a layer system, and six numbers for a solid.  The number of points
calculated for each line is proportional to the length of the line in
$k$-space. For a line of length 1.0, for example $\Gamma$ to $\Gamma$, 300
points would be calculated. \index{Walks in
$k$-space}\index{ksp@{$k$-space}!walks} The data needed to specify a
band-structure `walk' from $\Gamma $ to X to  W to L to $\Gamma $ is given in
Table~\ref{walk}, and for diamond, the band-structure for this `walk' is given
in Figure~\ref{walk-pic}.

\begin{table}
\begin{center}
\caption{\label{walk}A ``Walk'' in $k$-Space ($\Gamma $ to X to W to L to $\Gamma $)}
\begin{tabular}{ccccccccc} \\ \hline
Start && Stop&\multicolumn{3}{c}{Start} & \multicolumn{3}{c}{Stop} \\ \hline
$\Gamma$&-&X & 0.000& 0.000& 0.000& 0.500& 0.000& 0.000  \\
X       &-&W        & 0.500& 0.000& 0.000& 0.500& 0.250& 0.000  \\
W       &-&L        & 0.500& 0.250& 0.000& 0.250& 0.250& 0.250  \\
L       &-&$\Gamma$ & 0.250& 0.250& 0.250& 0.000& 0.000& 0.000  \\ \hline
\end{tabular}
\end{center}
\end{table}
\begin{figure}
\begin{makeimage}
\end{makeimage}
\begin{center}
\includegraphics{diamondbs}
\end{center}
\caption{\label{walk-pic}Band structure for Diamond}
\label{pbt}
\end{figure}
\index{Little groups|)}
\index{Diamond!little group|)}

\subsection{Surfaces in $k$-space}
\index{ksp@{$k$-space}!surfaces in}\index{Surfaces in $k$-space} A surface is
defined by seven data.  Three numbers are used to specify the center of the
surface, three are used to define a perpendicular, and one number is used to
define the length of an edge.

For example, to generate the hexagonal face of the Brillouin Zone for diamond,
the specification would be (0.25 0.25 0.25 1 1 1 0.7071), the center of the
plot being (0.25 0.25 0.25), and (1 1 1) defining the direction.

Two dimensional surfaces use 80 points in each direction, and an interpolation
procedure is used to double this number to 160 points in each direction.  The
length of a side in a two-dimensional plot is defined by the user at
run-time.

The cost of generating the surface is quite large.  Because of this, the data
are stored on disk, once they are generated.

The user is prompted for input.

\subsection{Files used by BZ}
\index{Files used by BZ}\index{BZ!files used by}
BZ uses the following files:
\begin{description}
\item[\comp{ $<$filename$>$.ops}] a symmetry file.
\item[\comp{ $<$filename$>$.brz}] a Fock matrix file made by MOPAC.
\end{description}

The file \comp{$<$filename$>$.brz} {\em must} exist.  The file
\comp{$<$filename$>$.ops}
{\em should}, but does not have to, exist.    If \comp{$<$filename$>$.ops} is
written,  the first two lines should look like this:
\begin{verbatim}
0 0 0 0 0.0       0.0       0.0       1.0  0.0 0.0 0.0  'Identity'
2 0 0 0 0.0       0.0       0.0       0.0  0.0 0.0 0.0  'Terminus'
\end{verbatim}
More lines can be added, as needed,  to define the other symmetry operations.


% !TEX encoding = UTF-8
% !TEX program = pdflatex
% !TEX spellcheck = en_US
% !TEX root = roma-demo.tex

\section{Introduction}

\subsection{Original problem}

\begin{frame}[t]{Code Example}
	\begin{lstlisting}[language=C++, caption=Multiplication example]
		byte mult(byte in_1, byte in_2){
			byte mask, result, piv;
			mask = 0x01;
			result = 0x00;
			piv = in_1;
			for(int i=0; i<8; i++){
				if(in_2 & mask) result^=piv;
				mask = mask << 1;
				piv = xtime(piv);
			}
			return result;
		}
	\end{lstlisting}
\end{frame}

\begin{frame}[t]{Assumptions}

	Let us consider the usual linear regression model defined as: \[y = \beta_*^t \mathbf{x} + \epsilon \text{ with }\]

	\begin{enumerate}[i.]
		\item $\mathbf{x} \in \mathbb{R}^p$ a vector of random variables normally called the input vector.
		\item $\epsilon \in \mathbb{R}$ the random noise defined as a Gaussian random variable with expectation zero and variance $\sigma^2$, this is, $\epsilon \sim \mathcal{N}(\mu=0,\,\sigma^{2})$
		\item $y \in \mathbb{R}$ a random variable that depends linearly on $\mathbf{x}$.
		\item $\beta_* \in \mathbb{R}^p$ is the optimal model.
	\end{enumerate}

\end{frame}

\begin{frame}[t]{Problem Formulation}

	The problems we need to solve to estimate $\beta_*$ are written as follow:

	\begin{mini!}|s|[2]<b>
		{\beta, e}{ f(e)+ \lambda g(\beta)}{}{P(s, \lambda) \quad}
		\addConstraint{e}{= \mathbf{y} - X \beta \quad \label{const:c1ex1}}{e \in \mathbb{R}^m, \beta \in \mathbb{R}^p }
		\addConstraint{h(\beta)}{\leq s}{ s \in \mathbb{R}, s \geq 0}
		\addConstraint{\mathbf{L}\leq }{A\beta \leq \mathbf{U}}{\mathbf{L,U} \in \mathbb{R}^m, A \in \mathbb{R}^{q x p}}
	\end{mini!}

\end{frame}

\begin{frame}[t]{Examples}
	\begin{itemize}

	\item $f$ is the error function. Examples: $f(\mathbf{e}) = {\| \mathbf{e} \|}_1$ y $f(\mathbf{e}) =\frac{1}{2} {\| \mathbf{e} \|}^2_2$, among others.

	\item $h$ and $g$ are the complexity functions of the model. Examples: $g(\mathbf{\beta}) = {\| \mathbf{\beta} \|}_1$ y $g(\mathbf{\beta}) = {\| \mathbf{\beta} \|}^2_2$, $h(\mathbf{\beta}) = {\| \mathbf{\beta} \|}_1$ y $h(\beta) = {\| \beta \|}_0 = \vert \lbrace j: \beta_j \neq 0,\;\;j \in [n] \rbrace \vert$, among  others.

	\item  $A$,$\mathbf{L}$ and $\mathbf{U}$ allow the modelling of linear constraints over the regressors.

	\end{itemize}
\end{frame}

\subsection{The Holistic Regression Problem}

\begin{frame}[t]{The Holistic Regression problem}
\[(R(\lambda,s))\;\;\underset{\beta,\mathbf{e},\mathbf{z}}{min}\;\;f(\mathbf{e}) + \lambda g(\beta)\;\;s.t.\]
\[\mathbf{y} - X \beta = \mathbf{e}\]
\[h(\beta) \leq s\]
\[\mathbf{L} \leq A\beta \leq \mathbf{U}\]
\[(\beta,\mathbf{z}) \in H\]
\[\beta \in \mathbb{R}^n,\;\;\mathbf{e} \in \mathbb{R}^m,\;\;\mathbf{z} \in {\lbrace 0,1 \rbrace}^n\]

	\begin{itemize}
		\item The structure of $R(\lambda,s)$ is too general, so the algorithms designed for $P(s, \lambda)$ cannot be used (Specially because $H$).
		\item For the usual optins of $f$,$g$,$h$ and for $H$ defined as affine equations and inequations in $(\beta,\mathbf{z})$ $R(\lambda,s)$ is as (0-1-MICQP).

\end{itemize}
\end{frame}

\begin{frame}[t]{Huber Function $\rho_\gamma(s)$}
	\begin{center}
		$\rho_\gamma(s) =
		\begin{cases}
		\frac{1}{2} s^2  & 0 \leq  s  \leq \gamma\\
		\gamma  s - \frac{1}{2} \gamma^2  &  s \geq \gamma
		\end{cases}
		$

		\vspace{0.3cm}

		\resizebox{0.58\textwidth}{!}{
			\begin{tikzpicture}
			\begin{axis}[
			xlabel=$s$,
			ylabel={$\rho_\gamma(s)$},
			legend pos=north west
			]
			% p_2(x)
			\addplot[green, ultra thick, domain=0:3]{0.5*x^2};
			\addlegendentry{$\gamma=3$}
			\addplot[blue, ultra thick, domain=0:2]{0.5*x^2};
			\addlegendentry{$\gamma=2$}
			\addplot[red, ultra thick, domain=0:0.5]{0.5*x^2};
			\addlegendentry{$\gamma=0.5$}

			\addplot[green, ultra thick, domain=3:6]{3*abs(x)-0.5*(3)^2};

			\addplot[blue, ultra thick, domain=2:6]{2*abs(x)-0.5*(2)^2};

			\addplot[red, ultra thick, domain=0.5:6]{0.5*abs(x)-0.5*(0.5)^2};

			\end{axis}
			\end{tikzpicture}
		}
	\end{center}
\end{frame}

\begin{frame}[t]{The $\epsilon$-insensitive Huber Function $g_\gamma^\epsilon(t)$}
	\begin{center}

		$f^{\epsilon}_\gamma(\mathbf{e}) = \underset{i \in [m]}{\sum} g^{\epsilon}_\gamma(\bar{\mathbf{e}}_i)$ with: \\

		$g^{\epsilon}_\gamma(t) = \left\{\begin{array}{lcc} 0 & si & \vert t \vert \leq \epsilon\\\rho_\gamma(\vert t \vert - \epsilon)   & si & \vert t \vert \geq \epsilon\\
		\end{array}
		\right.$
	\end{center}

\end{frame}

\section{The study case}

\begin{frame}[t]{Study case}

	\[(R(\lambda,k))\;\;\underset{\beta,\mathbf{e},\mathbf{z}}{min}\;\;f^\epsilon_\gamma (\mathbf{e}) + \lambda {\parallel \beta \parallel}_1\;\;s.t.\;\;(1)\]
	\[\mathbf{y} - X \beta = \mathbf{e}\;\;(2)\]
	\[\mbox{If}\;\;\mathbf{z}_j = 1\;\;\mbox{then}\;\;\beta_j = 0\;\;\forall j \in [n]\;\;(3)\]
	\[Co(\mathbf{z})\leq k\;\;(4)\]
	\[\underset{j \in J1_i}{\sum} \mathbf{z}_j \leq 1\;\;\forall i \in [n_1]\;\;(5)\]
	\[\underset{j \in J2_i}{\sum} \mathbf{z}_j = 1\;\;\forall i \in [n_2]\;\;(6)\]
	\[\mathbf{z}_{j_1} = \mathbf{z}_{j_2}\;\;\forall j_1,j_2 \in B_i\;\;\forall i \in [n_B]\;\;(7)\]
	\[\beta_j \geq 0\;\;\forall j \in J^+,\;\;\beta_j \leq 0\;\;\forall j \in J^-\;\;(8)\]

\end{frame}

\begin{frame}[t]{Study case (II)}

	\[(R(\lambda,k))\;\;\underset{\beta,\mathbf{e},\mathbf{z}}{min}\;\;f^\epsilon_\gamma (\mathbf{e}) + \lambda {\parallel \beta \parallel}_1\;\;s.t.\;\;(1)\]
	\[ \cdots \]
	\[\mathbf{z}_{j_1} + \mathbf{z}_{j_2} \leq 1\;\;\forall (j_1,j_2) \in Jc\;\;(9)\]
\[\beta \in \mathbb{R}^n,\;\;\mathbf{e} \in \mathbb{R}^m,\;\;\mathbf{z} \in {\lbrace 0,1 \rbrace}^n\;\;(10)\]

\end{frame}

\section{Roadmap}

\begin{frame}[t]{Road}
\textbf{Objective:} Find a set of solutions with values close to the optimal, this is {\it a path of Approximate Solutions}

\begin{enumerate}
	\item Formulation of $ R(\lambda, k)$.
	\item Obtaining valid values for BigM values.
		BigMs too big $\implies$ numerical problems, inefficiency of algorithms.
		BigMs too small $ ~ implies $ good solutions removed.
		\item {\it Local Holistic Searches}: Distances, Neighborhoods and Complexity function are presented on $\mathbf{z}$, which we will call Holistic, that adapt naturally to the case study, to obtain solutions locally optimal.
		\item Algorithms for the construction of the Approximate Solutions 	Path combining (2.) and (3.)
\end{enumerate}
\end{frame}


\section{UTxO}
\label{sec:utxo}

\begin{figure*}[htb]
  \emph{Functions}
  %
  \begin{align*}
    & \fun{isNonNativeScriptAddress} \in \Tx \to \Addr \to \Bool \\
    & \fun{isNonNativeScriptAddress}~tx~a = \\
      &\quad\begin{cases}
        s \in \ScriptNonNative & a \in \AddrScr \land \fun{validatorHash}~a \mapsto s \in \fun{txscripts} (\fun{txwits}~tx) \\
        \False & \text{otherwise}
      \end{cases}
                 \nextdef
    & \fun{totExunits} \in \Tx \to \ExUnits \\
    & \fun{totExunits}~\var{tx} = \sum_{\wcard \mapsto (\wcard, eu) \in \fun{txrdmrs}~(\fun{txwits}~tx)} eu
    \nextdef
    & \fun{feesOK} \in \PParams \to \Tx \to \UTxO \to \Bool  \\
    & \fun{feesOK}~\var{pp}~tx~utxo~= \\
    &~~      \minfee{pp}~{tx} \leq \txfee{txb} \wedge (\fun{totExunits}~tx \neq (0, 0) \Rightarrow \\
    &~~~~~~((\forall (a, \wcard, \_) \in \fun{range}~(\fun{txinputs_{fee}}~{txb} \restrictdom \var{utxo}), \neg \fun{isNonNativeScriptAddress}~tx~a) \\
    &~~~~~~\wedge~ \fun{adaOnly}~\var{balance} \\
    &~~~~~~      \wedge~ \var{balance} \geq \txfee{txb})) \\
    &~~      \where \\
    & ~~~~~~~ \var{txb}~=~\txbody{tx} \\
    & ~~~~~~~ \var{balance}~=~\fun{ubalance}~(\fun{txinputs_{fee}}~{txb} \restrictdom \var{utxo})
    \nextdef
    & \fun{txins} \in \TxBody \to \powerset{\TxId \times \Ix} \\
    & \fun{txins} ~\var{txb} = \fun{txinputs}~txb \cup \fun{txinputs_{fee}}~txb
    \nextdef
    & \fun{txscriptfee} \in \Prices \to \ExUnits \to \Coin \\
    & \fun{txscriptfee}~(pr_{mem}, pr_{steps})~ (\var{mem, steps})
    = \var{pr_{mem}}*\var{mem} + \var{pr_{steps}}*\var{steps}
    \nextdef
    &\fun{minfee} \in \PParams \to \Tx \to \Coin \\
    &\fun{minfee}~\var{pp}~\var{tx} = \\
    &~~(\fun{a}~\var{pp}) \cdot \fun{txSize}~\var{tx} + (\fun{b}~\var{pp}) +
    \hldiff{\fun{txscriptfee}~(\fun{prices}~{pp})~(\fun{totExunits}~(\fun{txbody}~{tx}))}
  \end{align*}
  \caption{Functions related to fees}
  \label{fig:functions:utxo}
\end{figure*}

We have added or changed several functions that deal with fees as shown in Figure \ref{fig:functions:utxo}.

\begin{itemize}
  \item $\fun{isNonNativeScriptAddress}$ is a predicate that checks
  whether an address is used as a script address with a non-native
  script.
  \item $\fun{totExunits}$ calculates the total $\ExUnits$ in a transaction by summing
  the per-script units stored in the indexed redeemer structure
  \item The predicate $\fun{feesOK}$ checks whether the transaction is
  paying the necessary fees, and that it does it correctly. That is, it checks that:
  \begin{enumerate}[label=({\roman*})]
    \item the fee amount that the transaction states it is paying suffices to cover
    the minimum fee that the transaction is obligated to pay; and if the transaction uses non-native scripts, that
    \item the fee-marked inputs do not belong to non-native script addresses;
    \item all the fee-marked inputs contain strictly Ada and no other kinds of token; and
    \item the fee-marked inputs are sufficient to cover the fee amount that is stated
    in the transaction.
  \end{enumerate}
  \item The function $\fun{txins}$ returns the UTxO keys of transaction inputs.
  \item $\fun{txscriptfee}$ calculates the fee that a transaction must pay for script
  execution based on the amount of $\ExUnits$ it has budgeted, and the prices in the current protocol parameters
  for each component of $\ExUnits$.
  \item The minimum fee calculation, $\fun{minfee}$, includes the script
  fees that the transaction is obligated to pay in order to run its scripts.
\end{itemize}

Note that when creating a transaction, the wallet is responsible for
determining the fees. Thus, it also has to execute the non-native scripts
and include the fees for their execution.

\subsection{Combining Scripts with Their Inputs}
\label{sec:scripts-inputs}

Figure~\ref{fig:functions:script1} shows the functions that are needed to
retrieve all the data that is relevant to Plutus script validation.
These include:

\begin{itemize}
\item $\Time$ is the system time
\item
  $\ScriptPurpose$ is a sum type of all parts of a transaction that may
  require a script witness to validate. Note that this contains the data
  (eg. a certificate $c \in \fun{txcerts}~{txb}$,
  or a transaction input $tin \in \fun{txcerts}~{txb}$) of the item being validated,
  not just a tag indicating the type.
\item
  $\fun{indexof}$ is a helper function that finds the index of a given certificate, value, input, or
  withdrawal in a list, finite map, or set of such objects.
  It assumes there is some ordering on each of these structures.
\item
  $\fun{indexedRdmrs}$ indexes the pair of a redeemer and an $\ExUnits$ value
  for a given script by its script purpose (eg. the input, or certificate, etc.)
\end{itemize}

\begin{figure}[htb]
  \emph{Abstract types}
  %
  \begin{equation*}
    \begin{array}{r@{~\in~}l@{}lr}
      \var{tm}
      & \Time
      & \text{System time}
    \end{array}
  \end{equation*}
  %
  \emph{Derived types}
  %
  \begin{equation*}
    \begin{array}{r@{~\in~}l@{\qquad=\qquad}lr}
      \var{sp}
      & \ScriptPurpose
      & \PolicyID \uniondistinct \UTxOIn \uniondistinct \AddrRWD \uniondistinct \DCert
%      & \text{item the script is validated for}
    \end{array}
  \end{equation*}
  %
  \emph{Abstract functions}
  \begin{align*}
    &\fun{indexof} \in \DCert \to \seqof{\DCert} \to \Ix\\
    &\fun{indexof} \in \AddrRWD \to \Wdrl \to \Ix\\
    &\fun{indexof} \in \UTxOIn \to \powerset{\TxIn} \to \Ix\\
    &\fun{indexof} \in \PolicyID \to \Value \to \Ix
  \end{align*}
  %
  \emph{Indexing functions}
  \begin{align*}
    &\fun{indexedRdmrs} \in \Tx \to \ScriptPurpose \to (\seqof{\Data}~\times~\ExUnits)\\
    &\fun{indexedRdmrs}~tx~sp =
      \begin{cases}
        ([], \var{eu}) & rdptr \mapsto (\Nothing, \var{eu}) \in \fun{txrdmrs}~(\fun{txwits}~{tx}) \} \\
        ([d], \var{eu}) & rdptr \mapsto (\var{d}, \var{eu}) \in \fun{txrdmrs}~(\fun{txwits}~{tx}) \} \\
        \Nothing & \text{otherwise}
      \end{cases} \\
    & ~~\where \\
    & ~~\quad \var{txb} = \txbody{tx} \\
    & ~~\quad \var{rdptr} = \begin{cases}
        (\mathsf{certTag},\fun{indexof}~\var{sp}~(\fun{txcerts}~{txb}))   & \var{sp}~\in~\DCert \\
        (\mathsf{wdrlTag},\fun{indexof}~\var{sp}~(\fun{txwdrls}~{txb}))   & \var{sp}~\in~\AddrRWD \\
        (\mathsf{mintTag},\fun{indexof}~\var{sp}~(\fun{mint}~{txb}))    & \var{sp}~\in~\PolicyID \\
        (\mathsf{inputTag},\fun{indexof}~\var{sp}~(\fun{txinputs}~{txb})) & \var{sp}~\in~\UTxOIn
      \end{cases}
  \end{align*}
  \caption{Indexing script and data objects}
  \label{fig:functions:script1}
\end{figure}

\subsection{Plutus Script Validation}
Figure~\ref{fig:defs:functions-valid} shows the abstract functions that are used for script validation.

\begin{itemize}
\item $\fun{slotToTime}$ translates a slot number to system time if possible.
If it is not possible to do this translation, $\Nothing$ is returned.
The reason it may not be possible to translate is that the slot number
is too far in the future for the system to accurately
predict the exact time to which it refers.

\item $\fun{txInfo}$ summarizes all the necessary transaction and chain state info
  that needs to be passed to the script interpreter. The $\Language$ argument
  is required because different languages have different expectations of the
  format and contents of the summary $\Data$ term.
  It has a $\UTxO$ as its argument to recover the full information of the inputs of the transaction,
  but only the inputs of the transaction are provided to scripts. For details, see~\ref{sec:txinfo}

\item
  $\fun{valContext}$ constructs the \emph{validation context}. A validation context is
  a $\Data$ term which encodes both the summary of the transaction and ledger information
  (this is supplied by the $\fun{txInfo}$ summarization function), and the script purpose.

\item
  $\fun{runPLCScript}$ validates Plutus scripts. It takes the following
  arguments:
  \begin{itemize}
  \item A cost model, that is used to calculate the $\ExUnits$ that are needed for script execution;
  \item A script to execute;
  \item A list of terms of type $\Data$ that will be passed to the script; and
  \item the execution unit budget.
  \end{itemize}
  It outputs the validation result.
  Note that script execution stops if the full budget has been spent before validation is complete.
  It is left abstract because it is implemented as part of the native script interpreter, not the ledger.
  The interpreter called depends on the language of the script.
\end{itemize}

\textbf{Slot to time translation.}
One of the inputs to scripts is the transaction validity interval (recall here that
they do not actually see the current slot number). The length of a
slot may change in a future era. In this case, for a script written in a previous
era, if we were to pass the transaction validity interval expressed as slot numbers,
we get that

\begin{itemize}
  \item the script logic is expressed in terms of slot numbers
  which likely assume the slot length of the era in which it was created
  \item the slot numbers in the validity interval of the transaction are used
  assuming slot length of the current era
\end{itemize}

Therefore, the slot numbers inside the contract and the slot numbers in the transaction
map differently onto points in time. The ledger does not have access to data (or conversion functions)
that is needed to convert transaction validity interval slots numbers to slots numbers
that correspond to the contracts world view. To address this, we decided to pass
non-native contracts (in all languages and all eras) the system time instead of slot numbers.
The conversion function is implemented by consensus (see~\cite{shelley_consensus}),
which has the information to do this correctly for

\begin{itemize}
  \item all slots prior to the current slot
  \item a number of slots after the current slot (this number is determined by
  the consensus's forecast window)
\end{itemize}

\textbf{Validation context construction.}
  As additional non-native scripting languages become supported in the future, scripts of different
  languages may expect different (or differently structured) transaction and ledger data summary.
  The $\fun{txInfo}$ function will be implemented differently
  for each new language. So, the construction is
  dependent on both the language of the script being validated and the ledger/transaction structure
  of the current era.

  In order to ensure that running scripts of all script languages is supported indefinitely across
  future eras, the $\fun{txInfo}$ function must be total.
  Recall here that while \emph{running} all scripts must be supported across
  all future ledger changes,
  it is not a requirement that every script must \emph{validate} within the context of some transaction.

  The $\fun{txInfo}$ output is computed once for the whole transaction. The output of the function
  $\fun{valContext}$ is computed separately for each script purpose.
  The script purpose is passed to it
  to allow the script to reference itself via its hash, and to be aware of what it is validating.

\textbf{Know your contract arguments.}
  A Plutus validator script may receive either a list of three terms of type $\Data$, in case it validates the spending of script outputs
  or two terms (redeemer and context, with no datum), for all other uses.
  Script authors must keep this in mind when writing scripts, since the ledger call to the interpreter is oblivious to what
  arguments are required.

\begin{figure*}[htb]
  \emph{Abstract Script Validation Functions}
  %
  \begin{align*}
     &\fun{slotToTime} \in \Slot \to \Time^? \\
     &\text{Translate slot number to system time or fail} \\~\\
     &\fun{txInfo} \in \Language \to \UTxO \to \Tx \to \Data \\
     &\text{Summarizes transaction data} \\~\\
     &\fun{valContext} \in \Data \to \ScriptPurpose \to \Data \\
     &\text{Pairs transaction data with a script purpose} \\~\\
     &\fun{runPLCScript} \in \CostMod \to\ScriptPlutus \to
    \seqof{\Data} \to \ExUnits \to \IsValidating \\
     &\text{Validate a Plutus script, taking resource limits into account}
  \end{align*}
  %
  \emph{Notation}
  %
  \begin{align*}
    \llbracket \var{script_v} \rrbracket_{\var{cm},\var{exunits}}~\var{d}
    &=& \fun{runPLCScript} ~{cm}~\var{script_v}~\var{d}~\var{exunits}
  \end{align*}
  \caption{Script Validation, cont.}
  \label{fig:defs:functions-valid}
\end{figure*}

Figure \ref{fig:functions:script2} contains the functions used to
match scripts with their corresponding inputs and pass them to the
evaluator.

\begin{itemize}
  \item $\fun{getData}$ looks for a datum associated with a given script purpose. Note that
  only an $\TxIn$-type script purpose can result in finding an associated datum hash.
  In no datum is found, an empty list is returned. A list containing the found datum
  is returned otherwise.

  \item $\fun{collectNNScriptInputs}$ builds a list of scripts, paired with their
  inputs. Specifically, each tuple in the list contains :

  \begin{itemize}
  \item the script;

  \item the validation context, built by the $\fun{valContext}$ function using
  the transaction summary built by $\fun{txInfo}$, together with the current item being validated;

  \item the hash of the required datum, if any (returned by the $\fun{getData}$ function,
  wrapped in a list type instead of a $\Data^?$ type).

  \item a pair, returned by the $\fun{indexedRdmrs}$ function, of
  \begin{itemize}
    \item a list of $\Data$, containing exactly one or zero elements (this
    is not checked here, however, see~\ref{fig:functions:script1}). This list
    contains the optional redeemer if there is one.
    \item an $\ExUnits$ value, which is mandatory for all scripts
  \end{itemize}

  \item $\fun{evalScripts}$ evaluates a whole list of scripts paired with all their
  inputs by calling the native script validator function, $\fun{runPLCScript}$

  \item $\fun{runNativeScript}$ replaces the $\fun{validateScript}$ function,
  to diffentiate running native and non-native scripts. The definition is the
  same as in the ShelleyMA specification.
\end{itemize}

Note that no ``checks'' are performed within these functions.
Missing validators, missing inputs, incorrect hashes, the wrong type of script etc,
are caught during the application of the UTXOW rule (before these functions are ever applied).
%

\end{itemize}

\begin{figure}[htb]
  \begin{align*}
    & \fun{getData} \in \Tx \to \UTxO \to \ScriptPurpose \to \seqof{\Data} \\
    & \fun{getData}~{tx}~{utxo}~{sp}~=~
      \begin{cases}
        [\var{d}] & \var{sp} \mapsto (\_, \_, h_d) \in \var{utxo}, \var{h_d}\mapsto \var{d} \in \fun{txdats}~(\fun{txwits}~tx) \\
        \epsilon  & \text{otherwise}
      \end{cases}
    \nextdef
    & \fun{collectNNScriptInputs} \in \PParams \to \Tx \to \UTxO \to \seqof{(\ScriptNonNative \times \seqof{\Data} \times \ExUnits \times \CostMod)} \\
    & \fun{collectNNScriptInputs} ~\var{pp}~\var{tx}~ \var{utxo} ~=~ \\
    & ~~\fun{toList} \{ (\var{script}, (\fun{valContext}~\var{txinfo}~\var{sp}~++~ \fun{getData}~tx~utxo~sp~++~\var{d}), \var{eu}, \var{cm}) \mid \\
    & ~~~~(\var{sp}, \var{scriptHash}) \in \fun{scriptsNeeded}~{utxo}~{tx}, \\
    & ~~~~\var{scriptHash}\mapsto \var{script}\in \fun{txscripts}~(\fun{txwits}~tx), \\
    & ~~~~(\var{d}, \var{eu}) := \fun{indexedRdmrs}~tx~sp, \\
    & ~~~~\fun{language}~{script} \mapsto \var{cm} \in \fun{costmdls}~{pp} \} \\
    & \where \\
    & ~~~~~~~ \var{txinfo}~=~\fun{txInfo}~(\fun{language}~{script})~\var{utxo}~\var{tx} \\
    \nextdef
    & \fun{evalScripts} \in \seqof{(\ScriptNonNative \times \seqof{\Data} \times \ExUnits \times \CostMod)} \to \IsValidating \\
    & \fun{evalScripts}~\epsilon = \True \\
    & \fun{evalScripts}~((\var{sc}, \var{d}, \var{eu}, \var{cm});\Gamma) =
      \llbracket sc \rrbracket_{cm,\var{eu}} d \land \fun{evalScripts}~\Gamma
    \nextdef
    &\fun{runNativeScript} \in\ScriptNative \to \Tx \to \IsValidating
  \end{align*}
  \caption{Scripts and their arguments}
  \label{fig:functions:script2}
\end{figure}

\subsection{Two-Phase Transaction Validation for Non-Native Scripts}
\label{sec:two-phase}

Transactions are validated in two phases:
the first phase consists of every aspect of transaction validation apart from executing the non-native scripts; and
the second phase involves actually executing those scripts.
This ensures that users pay for the computational resources that are needed to validate non-native scripts, even
if script validation fails. %
In order to handle script execution, an additional transition system is used, called UTXOS.
It performs the appropriate UTxO state changes, based on the
value of the $\IsValidating$ tag, which it checks using the $\fun{evalScripts}$ function.

In general, there is no way to check \emph{a-priori} that the budget that has been supplied is sufficient for the transaction.
This can only be done by actually running the scripts. From the perspective of the ledger, there is no difference
between a script that exhausts the $\ExUnits$ budget during validation, and one that fails to validate.
If a transaction contains a failing script, the only change to the ledger that is made
is to collect all inputs that have been marked for fees.

It is always in the interest of the slot leader to have the new block validate,
and for it to contain only valid transactions. This motivates the
slot leader to:

\begin{enumerate}
  \item Correctly apply the $\IsValidating$ tag;
  \item Include all transactions that validate within the block,
  \textit{even when there is a 2nd step script validation failure};
  \item Exclude any transactions that are invalid in some way \textit{other than 2nd step script validation failure}.
\end{enumerate}

One important reason for adding the validation tag
to a transaction is that re-applying blocks will not require repeat
execution of scripts in the transactions inside a block, which would increase execution costs.
In fact, when replaying
blocks, all the witnessing information can be thrown away.

\subsection{The UTXOS transition system}
\label{sec:utxo-state-trans}

We have defined a separate transition system, UTXOS, to represent the two distinct
UTxO state changes: i) when all the scripts in a transaction validating; and
ii) when at least one fails to validate. Its transition types
are identical to the UTXO transition (Figure
\ref{fig:ts-types:utxo-scripts}).

\begin{figure}[htb]
  \emph{State transitions}
  \begin{equation*}
    \_ \vdash
    \var{\_} \trans{utxos}{\_} \var{\_}
    \subseteq \powerset (\UTxOEnv \times \UTxOState \times \Tx \times \UTxOState)
  \end{equation*}
  %
  \caption{UTxO script state update types}
  \label{fig:ts-types:utxo-scripts}
\end{figure}

There are two rules, corresponding to the two possible state changes of the
UTxO state in the UTXOS transition system (Figure~\ref{fig:rules:utxo-state-upd}).
%
In both cases, the $\fun{evalScripts}$ function is called upon to verify that the $\IsValidating$
tag has been applied correctly. The function $\fun{collectNNScriptInputs}$ is used to build
the inputs $\var{sLst}$ for the $\fun{evalScripts}$ function.
%
The first rule
applies when the validation tag is $\True$.
In this case, the states of the UTxO, fee
  and deposit pots, and updates are updated exactly as in the current Shelley
  ledger spec.
%
  The second rule
  applies when the validation tag is $\False$.
  In this case, the UTxO state changes as follows:

  \begin{enumerate}
    \item All the
    UTxO entries corresponding to the transaction inputs selected for covering
    fees are removed;

    \item The sum total of the value of the marked UTxO entries
    is added to the fee pot.
  \end{enumerate}

\begin{figure}[htb]
  \begin{equation}
    \inference[Scripts-Yes]
    {
    \var{txb}\leteq\txbody{tx} &
    \var{sLst} := \fun{collectNNScriptInputs}~\var{pp}~\var{tx}~\var{utxo}
    \\
    ~
    \\
    \fun{txvaltag}~\var{tx} = \fun{evalScripts}~\var{sLst} = \True
    \\~\\
    {
      \begin{array}{r}
        \var{slot} \\
        \var{pp} \\
        \var{genDelegs} \\
      \end{array}
    }
    \vdash \var{pup} \trans{\hyperref[fig:rules:update]{ppup}}{\fun{txup}~\var{tx}} \var{pup'}
    \\~\\
    \var{refunded} \leteq \keyRefunds{pp}{txb}
    \\
    \var{depositChange} \leteq
      (\deposits{pp}~{poolParams}~{(\txcerts{txb})}) - \var{refunded}
    }
    {
    \begin{array}{l}
      \var{slot}\\
      \var{pp}\\
      \var{poolParams}\\
      \var{genDelegs}\\
    \end{array}
      \vdash
      \left(
      \begin{array}{r}
        \var{utxo} \\
        \var{deposits} \\
        \var{fees} \\
        \var{pup} \\
      \end{array}
      \right)
      \trans{utxos}{tx}
      \left(
      \begin{array}{r}
        \varUpdate{\var{(\txins{txb} \subtractdom \var{utxo}) \cup \outs{slot}~{txb}}}  \\
        \varUpdate{\var{deposits} + \var{depositChange}} \\
        \varUpdate{\var{fees} + \txfee{txb}} \\
        \varUpdate{\var{pup'}} \\
      \end{array}
      \right) \\
    }
  \end{equation}
  \begin{equation}
    \inference[Scripts-No]
    {
    \var{txb}\leteq\txbody{tx} &
    \var{sLst} := \fun{collectNNScriptInputs}~\var{pp}~\var{tx}~\var{utxo}
    \\
    ~
    \\
    \fun{txvaltag}~\var{tx} = \fun{evalScripts}~\var{sLst} = \False
    }
    {
    \begin{array}{l}
      \var{slot}\\
      \var{pp}\\
      \var{poolParams}\\
      \var{genDelegs}\\
    \end{array}
      \vdash
      \left(
      \begin{array}{r}
        \var{utxo} \\
        \var{deposits} \\
        \var{fees} \\
        \var{pup} \\
      \end{array}
      \right)
      \trans{utxos}{tx}
      \left(
      \begin{array}{r}
        \varUpdate{\var{\fun{txinputs_{fee}}~{txb} \subtractdom \var{utxo}}}  \\
        \var{deposits} \\
        \varUpdate{\var{fees} + \fun{ubalance}~(\fun{txinputs_{fee}}~{txb}\restrictdom \var{utxo})} \\
        \var{pup} \\
      \end{array}
      \right)
    }
  \end{equation}
  \caption{State update rules}
  \label{fig:rules:utxo-state-upd}
\end{figure}

Figure \ref{fig:rules:utxo-shelley} shows the $\type{UTxO-inductive}$
transition rule for the UTXO transition type.
This rule has the following changes:

\begin{enumerate}
  \item The transaction pays fees correctly, as defined above;

  \item The end of the transaction validity interval is translatable into
  system time (ie. within the consensus's forecast window). This is checked
  by $\fun{slotToTime}$, which returns $\Nothing$ if the end slot is outside.
  Note that we do not need to check that the start slot can be converted to
  time, because all pasts slots can be converted into time correctly.

  \item $\fun{adaPerUTxOWord}$ is now a protocol parameter explicitly, the
  $\fun{utxoEntrySize}$ calculation is defined differently than for ShelleyMA
  (see Section~\ref{sec:value-size})

  \item $\fun{maxValSize}$ is now also a protocol parameter (not a constant).
  It represents a size (in bytes) of the total transaction
  size that the size of a $\Value$ in an output can be. Otherwise, this check is
  the same as in ShelleyMA.

 \item The execution unit budget for a transaction is within the maximum
  permitted number of units for a transaction;

  \item The UTXOS state transition is valid (this is the transition that runs the
  non-native scripts)
\end{enumerate}

The resulting state transition is defined entirely by the application of the
UTXOS rule.

\begin{figure}[htb]
  \begin{equation}\label{eq:utxo-inductive-shelley}
    \inference[UTxO-inductive]
    {
      \var{txb}\leteq\txbody{tx} &
      \fun{ininterval}~\var{slot}~(\fun{txvldt}~{tx}) \\
      \hldiff{\var{(\wcard, i_f)}\leteq\fun{txvldt}~{tx}} & \hldiff{\fun{slotToTime}~i_f \neq \Nothing} \\
      \txins{txb} \neq \emptyset
      & \hldiff{\fun{feesOK}~pp~tx~utxo}
      & \txins{txb} \subseteq \dom \var{utxo}
      \\
      \consumed{pp}{utxo}{txb} = ~\produced{pp}{poolParams}~{txb}
      \\~\\
      \mathsf{adaID}\notin \supp {\fun{mint}~tx} \\~\\
      \forall txout \in \txouts{txb}, \\
      \fun{getValue}~txout \geq \fun{inject}~(\hldiff{\fun{utxoEntrySize}~{txout} * \fun{adaPerUTxOWord}~pp)} \\~
      \\
      \forall txout \in \txouts{txb},\\
      \hldiff{\fun{serSize}~(\fun{getValue}~txout) ~\leq ~ (\fun{maxTxSize}~pp) * (\fun{maxValSize}~pp)} \\~
      \\
      \forall (\wcard\mapsto (a,~\wcard)) \in \txouts{txb}, \fun{netId}~a = \NetworkId
      \\
      \forall (a\mapsto\wcard) \in \txwdrls{txb}, \fun{netId}~a = \NetworkId
      \\
      \fun{txsize}~{tx}\leq\fun{maxTxSize}~\var{pp} \\
      \hldiff{\fun{totExunits}~{tx} \leq \fun{maxTxExUnits}~{pp}}
      \\
      ~
      \\
      \hldiff{{
        \begin{array}{c}
          \var{slot}\\
          \var{pp}\\
          \var{poolParams}\\
          \var{genDelegs}\\
        \end{array}
      }
      \vdash
      {
        \left(
          \begin{array}{r}
            \var{utxo} \\
            \var{deposits} \\
            \var{fees} \\
            \var{pup}\\
          \end{array}
        \right)
      }
      \trans{utxos}{\var{tx}}
      {
        \left(
          \begin{array}{r}
            \var{utxo'} \\
            \var{deposits'} \\
            \var{fees'} \\
            \var{pup'}\\
          \end{array}
        \right)
      }
    }}
    {
      \begin{array}{l}
        \var{slot}\\
        \var{pp}\\
        \var{poolParams}\\
        \var{genDelegs}\\
      \end{array}
      \vdash
      \left(
      \begin{array}{r}
        \var{utxo} \\
        \var{deposits} \\
        \var{fees} \\
        \var{pup}\\
      \end{array}
      \right)
      \trans{utxo}{tx}
      \left(
      \begin{array}{r}
        \varUpdate{\var{utxo'}}  \\
        \varUpdate{\var{deposits'}} \\
        \varUpdate{\var{fees'}} \\
        \varUpdate{\var{pup'}}\\
      \end{array}
      \right)
    }
  \end{equation}
  \caption{UTxO inference rules}
  \label{fig:rules:utxo-shelley}
\end{figure}

\subsection{Witnessing}
\label{sec:wits}

Because of two-phase transaction validation, non-native script validation is not part of phase one of transaction witnessing
(it is done in phase 2, once the rest of the transaction is validated).
However, native script validation does remain part of transaction witnessing.
When witnessing a transaction in phase one, we therefore need to validate only the native scripts.

We construct the following helper functions :

\begin{itemize}
  \item $\fun{scriptsNeeded}$ assembles the all the $\ScriptPurpose$ terms
  for validation of every transaction action that requires script validation,
  paired with the hashes of corresponding the witnessing scripts.
  This function collects hashes of both native and non-native scripts.

  \item $\fun{checkRedeemers}$ returns $\True$ if, for the given script purpose,
  whenever the script it points to is non-native, the transaction contains an associated entry
  in the indexed redeemers structure.
  Recall that redeemers are optional to include, so there may be a $\Nothing$ in place of
  a redeemer. Execution units are mandatory for all scripts, so each script purpose
  should have an associated entry specifying the $\ExUnits$ value.

  \item $\fun{languages}$ returns the set of (non-native) script languages
  of all the scripts included in the transaction
\end{itemize}

\begin{figure}[htb]
  \begin{align*}
    & \hspace{-1cm}\fun{scriptsNeeded} \in \UTxO \to \Tx \to \powerset (\ScriptPurpose \times \ScriptHash) \\
    & \hspace{-1cm}\fun{scriptsNeeded}~\var{utxo}~\var{tx} = \\
    & ~~\{ (\var{i}, \fun{validatorHash}~a) \mid i \mapsto (a, \wcard, \wcard) \in \var{utxo},
      i\in\fun{txinsScript}~{(\fun{txins~\var{txb}})}~{utxo}\} \\
    \cup & ~~\{ (\var{a}, \fun{stakeCred_{r}}~\var{a}) \mid a \in \dom (\AddrRWDScr
           \restrictdom \fun{txwdrls}~\var{txb}) \} \\
    \cup & ~~\{ (\var{cert}, \var{c}) \mid \var{cert} \in (\DCertDeleg \cup \DCertDeRegKey)\cap\fun{txcerts}~(\txbody{tx}), \\
    & ~~~~~~\var{c} \in \cwitness{cert} \cap \AddrScr\} \\
      \cup & ~~\{ (\var{pid}, \var{pid}) \mid \var{pid} \in \supp~(\fun{mint}~\var{txb}) \} \\
    & \where \\
    & ~~~~~~~ \var{txb}~=~\txbody{tx}
    \nextdef
    & \hspace{-1cm}\fun{checkRedeemers} \in \Tx \to \UTxO \to (\ScriptPurpose \times \ScriptHash) \to \Bool \\
    & \hspace{-1cm}\fun{checkRedeemers}~\var{tx}~\var{utxo}~(\var{sp},\var{h})~=~ \forall s, (h\mapsto s) \in \fun{txscripts}~(\fun{txwits}~tx),\\
    & (s \in \ScriptNonNative~\Rightarrow \fun{indexedRdmrs}~tx~sp \neq \Nothing) \\
    \nextdef
    & \hspace{-1cm}\fun{languages} \in \TxWitness \to \powerset{\Language} \\
    & \hspace{-1cm}\fun{languages}~\var{txw}~=~
      \{\fun{language}~s \mid s \in \range (\fun{txscripts}~{txw}) \cap \ScriptNonNative\}
  \end{align*}
  \caption{UTXOW helper functions}
  \label{fig:functions-witnesses}
\end{figure}

We have made the following changes and additions to the UTXOW preconditions:

\begin{itemize}

\item All the native scripts in the transaction validate;

\item The transaction contains exactly those scripts that are required for witnessing and no
additional ones;

    \item The datums included in the witnesses are exactly those that are required for validating;

    \item For every item that needs to be validated by a non-native script, the transaction contains
      an entry in the indexed redeemer structure (ie. the execution units for it are specified);

    \item The signatures of the keys whose hashes are specified in the
    $\fun{reqSignerHashes}$ field in a transaction
    have all indeed signed it;

    \item
    The hash of the subset of protocol parameter values that have been included in the transaction body is the same as
    the hash of the same subset of protocol parameters that are currently contained in the ledger;

    \item A check that ensures that the list of scripts paired with their input data (context, datum and redeemer)
    has the same number of elements as the set of scripts needed for each script purpose. Note that the same
    script may appear more than once in both the list and the set, as it can be used for different purposes, and therefore
    run separately for each, with different input data. Note also that by construction, the output of
    the $\fun{collectNNScriptInputs}$ function should have exactly the same collection of scripts as
    the $\fun{scriptsNeeded}$ function output - this check is in place to catch discrepancies in this construction.
    \begin{note}
      Note that $\fun{collectNNScriptInputs}$ is called twice, here and in UTXO. We need to avoid this.
      ALSO we need to audit the $\fun{wppHash}$ function
    \end{note}
\end{itemize}

If these conditions are all satisfied, then the resulting UTxO state change is fully determined
by the UTXO transition (the application of which is also part of the conditions).

\begin{figure}[htb]
  \emph{State transitions}
  \begin{equation*}
    \_ \vdash
    \var{\_} \trans{utxow}{\_} \var{\_}
    \subseteq \powerset (\UTxOEnv \times \UTxOState \times \Tx \times \UTxOState)
  \end{equation*}
  %
  \caption{UTxO with witnesses state update types}
  \label{fig:ts-types:utxo-witness}
\end{figure}

\begin{figure}
  \begin{equation}
    \label{eq:utxo-witness-inductive-alonzo}
    \inference[UTxO-witG]
    {
      \var{txb}\leteq\txbody{tx} &
      \var{txw}\leteq\fun{txwits}~{tx} \\
      (utxo, \wcard, \wcard, \wcard) \leteq \var{utxoSt} \\
      \var{witsKeyHashes} \leteq \{\fun{hashKey}~\var{vk} \vert \var{vk} \in
      \dom (\txwitsVKey{txw}) \}\\~\\
      \hldiff{\forall \var{s} \in \range (\fun{txscripts}~{txw}) \cap \ScriptNative,
      \fun{runNativeScript}~\var{s}~\var{tx}}\\~\\
      \hldiff{\{ s \mid (\_, s) \in \fun{scriptsNeeded}~\var{utxo}~\var{tx}\} = \dom (\fun{txscripts}~{txw})} \\
      \hldiff{\{ h \mid (\_ \mapsto (a, \_, h)) \in \txins{txb} \restrictdom \var{utxo}, \fun{isNonNativeScriptAddress}~{tx}~{a}\} =} \\
      \hldiff{\dom (\fun{txdats}~{txw})} \\
      \hldiff{\forall sph \in \fun{scriptsNeeded}~\var{utxo}~\var{tx},~ \fun{checkRedeemers}~tx~utxo~sph}
      \\~\\
      \forall \var{vk} \mapsto \sigma \in \txwitsVKey{txw},
      \mathcal{V}_{\var{vk}}{\serialised{txbodyHash}}_{\sigma} \\
      \hldiff{\fun{witsVKeyNeeded}~{utxo}~{tx}~{genDelegs} \cup \fun{reqSignerHashes}~txb \subseteq \var{witsKeyHashes}}
      \\~\\
      genSig \leteq
      \left\{
        \fun{hashKey}~gkey \vert gkey \in\dom{genDelegs}
      \right\}
      \cap
      \var{witsKeyHashes}
      \\
      \left\{
        c\in\txcerts{txb}~\cap\DCertMir
      \right\} \neq\emptyset \implies \vert genSig\vert \geq \Quorum \wedge
      \fun{d}~\var{pp} > 0
      \\~\\
      \var{adh}\leteq\fun{txADhash}~\var{txb}
      &
      \var{ad}\leteq\fun{txAD}~\var{tx}
      \\
      (\var{adh}=\Nothing \land \var{ad}=\Nothing)
      \lor
      (\var{adh}=\fun{hashAD}~\var{ad})
      \\~\\
      \hldiff{\fun{wppHash}~{txb}~=~\fun{hashWitnessPPData}~\var{pp}~(\fun{languages}~{txw})~(\fun{txrdmrs}~{txw})}
      \\~\\
      \hldiff{\|~\fun{scriptsNeeded}~\var{utxo}~\var{tx}~\|~=~\|~\fun{collectNNScriptInputs} ~\var{pp}~\var{tx}~ \var{utxo}~\|}
      \\~\\
      {
        \begin{array}{r}
          \var{slot}\\
          \var{pp}\\
          \var{poolParams}\\
          \var{genDelegs}\\
        \end{array}
      }
      \vdash \var{utxoSt} \trans{\hyperref[fig:rules:utxo-shelley]{utxo}}{tx}
      \var{utxoSt'}\\
    }
    {
      \begin{array}{r}
        \var{slot}\\
        \var{pp}\\
        \var{poolParams}\\
        \var{genDelegs}\\
      \end{array}
      \vdash \var{utxoSt} \trans{utxow}{tx} \varUpdate{\var{utxoSt'}}
    }
  \end{equation}
  \caption{UTxO with witnesses inference rules for Tx}
  \label{fig:rules:utxow-alonzo}
\end{figure}


\documentclass{scrartcl}
\usepackage{amsmath}
\usepackage{tikz}
\usepackage{hyperref}
\usepackage[font={small,it}]{caption}
\usepackage{pdflscape}
\usepackage{rotating}
\usepackage{multido}
\usetikzlibrary{dsp,chains}
\usepackage{expl3}
\ExplSyntaxOn
\cs_new_eq:NN \Repeat \prg_replicate:nn
\ExplSyntaxOff
\newcommand{\skipnodes}[1]{
    \Repeat{#1}{{};\&}
}

\title{Modified Gardner Reverb}
\subtitle{Sound Processing Mini Project}
\author{Pelle Juul Christensen, SMC7, Aalborg Universitet}

\begin{document}
\maketitle

This document serves to describe the algorithms used in my \textit{sound processing mini project} to implement an artificial reverberator. First I will describe the implementation of an algorithm for modelling early reverberation. Afterwards an algorithm for modelling late reverberation. Lastly I comment on how these algorithms a implemented in practice.

\section{Early Reflections}
When a sound propagates through a room it will first arrive at the listener from the \textit{direct path} -- the shortest path, usually a straight line, between the source and the listener. Afterwards the first reflections off the walls of the room will arrive, these are the \textit{second order reflections}. After that we have third and fourth order reflections and so on. These are referred to as the \textit{early reflections}, and are especially important for the spatial impression of the sound \cite[p. 100]{gardner2002}.

The early reflection algorithm I implemented is shown in figure 1, which is based on the algorithm presented in \cite[p. 104]{gardner2002}. This is implmented via two tapped delay lines for the left and right channels respectively. The delay times and coefficients were calculated using Amcoustics Amray tool\footnote{\url{https://amcoustics.com/tools/amray}}. In case of stereo input the left and right channels are mix together to yield a single sound source. The crossover filter and delay acts as a simple head-related filter model for increased spatial impression.

\section{Late Reverberation}
After the early reflections comes the late reverberation -- a dense collection of echos indistinguishable from one another. This results in a diffuse prolonging of the sound as the energy is absorbed by the room.

To emulate the sound of natural reverberation I implemented a version of Gardner's \textit{Medium Room Reverberator} found in \cite[p. 56]{gardner1982}. This was modified with ideas taken from Dattorro's plate reverberator algorithm shown in \cite[p. 117]{gardner2002}. For a greater stereo image an instance of the algorithm was used for both the left and right channels with slightly different delay parameters. These then feed back into one another, rather than to themselves. Furthermore a time variant component was included to generate a slight movement to the sound, and also to prevent some coloration, since the resonant frequency of the reverberator is being modulated. A diagram of the algorithm is shown in figure 2.

\section{Implementation Notes}
The algorithms were implemented as a VST/AudioUnit plug-in. The early reflection algorithm feeds directly into the late reverberation algorithm. A graphical user interface allows the user to control the $g$ (decay) parameter of the late reverberation algorithm, as well the mix of dry to reverberated signal.

\begin{landscape}
\input{early}
\end{landscape}

\begin{landscape}
\input{late}
\end{landscape}

% http://www.texample.net/tikz/examples/fir-filter/

\bibliographystyle{plain}
\bibliography{bibliography}

\end{document}


\documentclass[11pt]{article}
%============Macros==================%
% you don't need to change anything. start editing from main body.
\usepackage{amsmath,amsfonts,amssymb,amsthm, cancel, float, enumitem}
\usepackage{qcircuit}
\usepackage[margin=1in]{geometry}
%--------------Cosmetic----------------%
\usepackage{mathtools}
\usepackage{hyperref}
\usepackage{fullpage}
\usepackage{microtype}
\usepackage{xspace}
\usepackage[svgnames]{xcolor}
\usepackage[sc]{mathpazo}
\usepackage{enumitem}
\setlist[enumerate]{itemsep=1pt,topsep=2pt}
\setlist[itemize]{itemsep=1pt,topsep=2pt}
%--------------Header------------------%
\def\course{CS 410/510 Introduction to Quantum Computing}
\def\term{Portland State U, Spring 2017}
\def\prof{Lecturer: Fang Song}
\newcommand{\handout}[5]{
   \renewcommand{\thepage}{\arabic{page}}
   \begin{center}
   \framebox{
      \vbox{
    \hbox to 5.78in { \hfill \large{\course} \hfill }
       \vspace{2mm}
       \hbox to 6in { {\Large \hfill #5  \hfill} }
       \vspace{2mm}
       \hbox to 6in { \term \hfill \emph{#2}}
       \hbox to 6in { {#3 \hfill \emph{#4}}}
      }
   }
   \end{center}
   \vspace*{4mm}
}
\newcommand{\lecture}[4]{\handout{#1}{#2}{#3}{#4}{{Lecture #1}}}

\def\complex{\mathbb{C}}
\def\real{\mathbb{R}}
\def\natural{\mathbb{N}}
\def\integer{\mathbb{Z}}

\newcommand{\norm}[1]{\left\lVert#1\right\rVert}
\newcommand{\snorm}[1]{\lVert#1\rVert}
\newcommand{\abs}[1]{\left\lvert #1 \right\rvert}
\newcommand{\ceil}[1]{\left\lceil #1 \right\rceil}
\newcommand{\floor}[1]{\left\lfloor #1 \right\rfloor}
\newcommand{\set}[1]{\left\{ #1 \right\}}
\newcommand{\vecb}[1]{\boldsymbol{\vec{#1}}}
\newcommand{\conj}[1]{\overline{#1}}
\newcommand{\op}[2]{#1#2#1^\dag}

\newcommand{\tr}{\operatorname{Tr}}
\newcommand{\se}{\operatorname{H}}
\newcommand{\vne}{\operatorname{S}}
\newcommand{\e}{\operatorname{E}}
\newcommand{\rank}{\operatorname{rank}}
\renewcommand{\det}{\operatorname{Det}}

\newcommand{\bra}[1]{\langle #1 \rvert}
\newcommand{\ket}[1]{\lvert #1 \rangle}
\newcommand{\bret}[2]{\langle{#1}|{#2}\rangle}
\newcommand{\kret}[2]{\ket{#1}\bra{#2}}
\newcommand{\kera}[1]{\kret{#1}{#1}}
\newcommand{\Example}[1]{{\bf Example #1}:}

\def\X{\mathcal{X}}
\def\Y{\mathcal{Y}}
\def\Z{\mathcal{Z}}
\def\W{\mathcal{W}}
\def\A{\mathcal{A}}
\def\B{\mathcal{B}}
\def\V{\mathcal{V}}
\def\U{\mathcal{U}}
\def\C{\mathcal{C}}
\def\D{\mathcal{D}}
\def\E{\mathcal{E}}
\def\F{\mathcal{F}}
\def\M{\mathcal{M}}
\def\R{\mathcal{R}}
\def\P{\mathcal{P}}
\def\Q{\mathcal{Q}}
\def\S{\mathcal{S}}
\def\T{\mathcal{T}}
\def\K{\mathcal{K}}
\def\L{\mathcal{L}}

\def\fill{   \hfill}

%=============Main Doc=================%
\begin{document}
%-----Specs: change accordingly--------%
\def\lecdate{May 16, 2017} % put lecture date here
\def\scribe{Scribe: Enis K. Inan} % put your name here
\def\lecnum{13} % change the lecture number

\lecture{\lecnum}{\lecdate}{\prof}{\scribe}%

\begin{center}
{\textsc{Version: \today}}
\end{center}

\noindent Last lecture we introduced the density operator, which made it easier for us to describe general quantum states. We will briefly review it before proceeding any further. In the old notation, we only had pure states of the form $\ket{\psi} = \alpha \ket{0} + \beta \ket{1}$ where $\alpha, \beta \in \complex$ and $\abs{\alpha}^2 + \abs{\beta}^2 = 1$. With our new framework, a pure state is expressed as $\kera{\psi}$ where for our example,
\begin{equation*}
\kera{\psi} = \left(\begin{array}{cc}
\alpha\conj{\alpha} & \alpha\conj{\beta} \\
\conj{\alpha}\beta & \beta\conj{\beta}
\end{array}
\right) = \left(\begin{array}{cc}
\abs{\alpha}^2 & \alpha\conj{\beta} \\
\conj{\alpha}\beta & \abs{\beta}^2
\end{array}
\right)
\end{equation*}
The expressive power of this notation is apparent when we have general quantum states. Specifically, imagine we have a register $X$ that could be in one of the quantum states $\ket{\psi_1}, \dots, \ket{\psi_k}$ with a probability distribution $p_1, \dots, p_k$ where $p_i$ is the probability that $X$ is in state $\ket{\psi_i}$. With our new notation, we expressed our ``knowledge'' of $X$ as a density matrix $\rho$ where
\begin{equation*}
\rho = \sum_{i} p_i \kera{\psi_i}
\end{equation*}
Intuitively, $\rho$ corresponds to a weighted average of each state. There were also several important properties associated with density matrices:
\begin{enumerate}
	\item $\tr{(\rho)} = 1$

	\item $\rho$ is positive semidefinite.
\end{enumerate}
Property 2 will be important later in this lecture, so keep it in the back of your head for now.

\fill

\noindent In our old notation, the physically allowable operations on $\ket{\psi}$ were unitary operations $U$ -- the state $\ket{\psi'} = U\ket{\psi}$ is the resulting state after applying the unitary $U$ on $\ket{\psi}$. In our new notation, $\rho' = U\rho U^\dag$ corresponds to applying the unitary $U$ on the general quantum state described by $\rho$ -- the result is $\rho'$.

%==============================%
\section{General (Physically Admissible) Quantum Operations}
%==============================%
The density matrix formalism does not limit us to just unitary operations. Specifically, any \emph{physically admissible operation} $\Phi$ is a series of matrices $A_1, A_2, \dots, A_k$ where $A_{i_{jk}} \in \complex$ and
\begin{equation} \label{eq:phya:completeness}
\sum_{i} A^\dag_iA_i = I
\end{equation}
\begin{equation} \label{eq:phya:app}
\Phi(\rho) = \sum_{i} \op{A_i}{\rho}
\end{equation}
Note that each $A_i$ in $\Phi$ does \emph{not} have to be a square matrix, and that unitary matrices $U$ are a special case of $\Phi$ with $k = 1$.

\noindent Applying $\Phi$ to $\rho$ yields another density matrix, just like how applying unitary $U$ to $\ket{\psi}$ resulted in another valid quantum state. In fact, $\Phi$ is also known as a completely positive trace preserving (CPTP) operator, which is just jargon for an operation that preserves a matrix's trace and semi-positive definitiveness. Another way to think of $\Phi$ is as follows. Let $\X$ and $\Y$ denote spaces describing $m$ and $n$ qubits, respectively, and let $\L(\X, \Y)$ be the set of all linear mappings from $\X$ to $\Y$. Let $\D(\X)$ be the set of all density matrices in $\X$; define $\D(\Y)$ in a similar manner. Then $\Phi : \D(\X) \rightarrow \D(\Y)$ or, informally, $\Phi$ is the set of all density matrix mappings from $\X$ to $\Y$.

\fill

\noindent \Example{1} Here we investigate decoherence as a physically admissible operation, which is when a quantum system interacts with some environmental noise and loses its quantumness (i.e. gets measured). Note that the operation used in this example is equivalent to measurement in the standard basis $\set{\ket{0}, \ket{1}}$. Here we have $A_0 = \kera{0}$ and $A_1 = \kera{1}$ so that
\begin{equation*}
\Phi(\rho) = \op{A_0}{\rho} + \op{A_1}{\rho}
\end{equation*}
Firs we check if $A_0$ and $A_1$ are valid, i.e. that they satisfy Eqn. \ref{eq:phya:completeness}:
\begin{align*}
\sum_{i} A^\dag_iA_i
&= A^\dag_0A_0 + A^\dag_1A_1 \\
&= \ket{0}\bret{0}{0}\bra{0} + \ket{1}\bret{1}{1}\bra{1} \\
&= \kera{0} + \kera{1} \\
&= I
\end{align*}
which they do. Now assume that $\rho=\kera{\psi}$ where $\ket{\psi} = \alpha\ket{0} + \beta\ket{1}$, i.e. that $\rho$ corresponds to a pure state. We have,
\begin{align*}
\Phi(\kera{\psi})
&= \op{A_0}{\kera{\psi}} + \op{A_1}{\kera{\psi}} \\
&= \kera{0}\kera{\psi}\kera{0} + \kera{1}\kera{\psi}\kera{1} \\
&= \left(\begin{array}{cc}
1 & 0 \\
0 & 0
\end{array}\right)
\left(\begin{array}{cc}
\abs{\alpha}^2 & \alpha\conj{\beta} \\
\conj{\alpha}\beta & \abs{\beta}^2
\end{array}
\right)
\left(\begin{array}{cc}
1 & 0 \\
0 & 0
\end{array}\right) + \left(\begin{array}{cc}
0 & 0 \\
0 & 1
\end{array}\right)
\left(\begin{array}{cc}
\abs{\alpha}^2 & \alpha\conj{\beta} \\
\conj{\alpha}\beta & \abs{\beta}^2
\end{array}
\right)
\left(\begin{array}{cc}
0 & 0 \\
0 & 1
\end{array}\right) \\
&= \left(\begin{array}{cc}
\abs{\alpha}^2 & 0 \\
0 & \abs{\beta}^2
\end{array}
\right) \\
&= \abs{\alpha}^2\kera{0} + \abs{\beta}^2\kera{1}
\end{align*}
which is exactly what we get by doing a measurement on the standard basis! To see why, the last line shows that we can think of $\Phi(\kera{\psi})$ as representing the general quantum state where we have an $\abs{\alpha}^2$ chance of being in $\ket{0}$ and a $\abs{\beta}^2$ chance of being in $\ket{1}$. This is the definition of measurement in the standard basis.

\fill

\noindent Another important operation is the partial trace. Imagine that we have an $m + n$ qubit-state, e.g. $\ket{\psi} = \sum_{x \in \set{0, 1}^m}\sum_{y \in \set{0, 1}^n} \alpha_{xy}\ket{x}\ket{y}$. We want to examine the resulting state after we discard either $x$ or $y$. For our old notation, this is easy -- for $\ket{\psi}$, we can just remove $\ket{x}$ or $\ket{y}$. But in our new notation of density matrices, it is not as obvious. Let $\X$ and $\Y$ be the spaces describing $\ket{x}$ and $\ket{y}$, respectively, and assume without any loss of generality that we want to remove $\ket{y}$. Then what we want is an operation $\Phi: \D(\X \otimes \Y) \rightarrow \D(\X)$ -- this is the partial trace, denoted as $\tr_y$ for our specific case to explicitly indicate that we want to discard $\ket{y}$.

\fill

\noindent Let's examine what $\tr_y$ would look like when $\X$ and $\Y$ both describe 1-qubit each -- i.e., when we have a two-qubit state and we want to discard the second qubit. We have $\Phi$ be the matrices:
\begin{equation*}
\begin{split}
A_0 &= I_x \otimes \bra{0}_y = \left(\begin{array}{cccc}
1 & 0 & 0 & 0 \\
0 & 0 & 1 & 0
\end{array}\right) \\
A_1 &= I_x \otimes \bra{1}_y = \left(\begin{array}{cccc}
0 & 1 & 0 & 0 \\
0 & 0 & 0 & 1
\end{array}\right)
\end{split}
\end{equation*}
Note that $A_0$ and $A_1$ are $2 \times 4$ matrices -- $I_x$ is the $2 \times 2$ identity matrix. We first check that $A_0$ and $A_1$ satisfy Eqn. \ref{eq:phya:completeness}:
\begin{align*}
\sum_{i} A^\dag_iA_i
&= A^\dag_0A_0 + A^\dag_1A_1 \\
&= (I_x \otimes \ket{0}_y)(I_x \otimes \bra{0}_y)
+  (I_x \otimes \ket{1}_y)(I_x \otimes \bra{1}_y) \\
&= (I_x \otimes \kera{0}_y) + (I_x \otimes \kera{1}_y) \\
&= I_x \otimes (\kera{0}_y + \kera{1}_y) \\
&= I_x \otimes I_y = I_{xy}
\end{align*}
Now let's do an example calculation using $\Phi$.

\fill

\noindent \Example{2} Let $\rho = \kera{0} \otimes \kera{1}$. Intuitively, we should get $\kera{0}$ back after applying $\Phi$. Let's see if this is indeed the case.
\begin{align*}
\Phi(\rho)
&= \op{A_0}{\rho} + \op{A_1}{\rho} \\
&= (I_x \otimes \bra{0}_y)(\kera{0} \otimes \kera{1})(I_x \otimes \ket{0}_y)
+  (I_x \otimes \bra{1}_y)(\kera{0} \otimes \kera{1})(I_x \otimes \ket{1}_y) \\
&= \cancelto{0}{(\kera{0} \otimes \bret{0}{1}\bra{1})}(I_x \otimes \ket{0}_y)
+  (\kera{0} \otimes \bret{1}{1}\bra{1})(I_x \otimes \ket{1}_y) \\
&= (\kera{0} \otimes \bra{1})(I_x \otimes \ket{1}_y) \\
&= \kera{0}
\end{align*}
which is exactly what we expected. In the general case, e.g. when we have $\rho' = \rho \otimes \ket{0}$, then $\Phi(\rho') = \rho$ which is consistent with the physical meaning of $\tr_y$ -- take away $y$ and only look at $x$. We can think of it as ``tracing out $y$'', which is where the name ``partial trace'' comes from.

\fill

\noindent Now what if the qubits $x$ and $y$ are entangled? What do we get after we apply $\tr_y$? We will use $\ket{\phi^+} = \frac{1}{\sqrt{2}}(\ket{00} + \ket{11})_{xy}$ as our example.

\fill

\noindent \Example{3} $\tr_y(\kera{\phi^+}) = \frac{1}{2}\kera{0} + \frac{1}{2}\kera{1} = \frac{1}{2}I$ which can be verified by brute-force computation using $\Phi$, like we did in Example 2. So we see that we get a \emph{maximally mixed state}, i.e. a density matrix where the pure states form an orthonormal basis and each state has a probability $1/n$ of occurring, where $n$ is the dimension of the matrix. Here, $n = 2$. In fact, it can be shown that $\tr_y$ for \emph{any} Bell state is $\frac{1}{2}I$. Here's why this makes sense. In a Bell state, when we measure the second register, we \emph{collapse} the resulting state to either just $\ket{0}$ with probability $1/2$, or just $\ket{1}$ with probability $1/2$ -- exactly our maximally mixed state. For example in $\ket{\phi^+}$, if we measure a $1$ in the second register, then the state collapses to $\ket{1}_x$; otherwise, it collapses to $\ket{0}_x$.

\fill

\noindent The next operation we will consider is an extension of Example 1. Instead of constraining the measurement to a specific basis, e.g. the standard basis, let's generalize it. Imagine that $\Gamma$ represents the set of all possible outcomes resulting from our measurement and, for an $a \in \Gamma$, $M_a$ is the matrix ``capturing'' an outcome $a$. For example in Example 1, $\Gamma = \set{0, 1}$, and $M_0 = \kera{0}$, $M_1 = \kera{1}$. Then if
\begin{equation*}
\sum_{a \in \Gamma} M^\dag_aM_a = I
\end{equation*}
then the set of matrices $M = \set{M_a \: | \: a \in \Gamma}$ form a physically admissible operation $\Phi$, i.e. $\Phi$ is a valid measurement. Let's take an outcome $a$ and its measurement matrix $M_a$ where $M_a$ is a projecter ($M^2_a = M_a$). Then $\tr(M_a\rho M^\dag_a)$ is the probability that we will observe outcome $a$ when we measure the quantum system described by $\rho$. In Example 1, $\tr(M_0\rho M^\dag_0) = \abs{\alpha}^2$, which is exactly the probability of measuring a $0$. Now assume that we did measure $a$. Then our state would collapse to
\begin{equation*}
\frac{M_a\rho M^\dag_a}{\tr(M_a\rho M^\dag_a)}
\end{equation*}
which makes sense. If $M_a$ is the measurement matrix ``capturing'' an outcome $a$ then when we see $a$, we should only have $M_a\rho M^\dag_a$ left in our summation for $\Phi(\rho)$. However $M_a\rho M^\dag_a$ may not be a valid density matrix, so we need to normalize its trace back down to $1$ -- this is what the $\tr(M_a\rho M^\dag_a)$ in the denominator does. This corresponds to what we do in the pure state case, which is to keep only parts of the state that contain the measured outcome in its qubits ($M_a\rho M^\dag_a$ here), then normalize that part (divide by $\tr(M_a\rho M^\dag_a)$).

\fill

\noindent The above is known as a Von-Neumann measurement. Another way to think about measurement is through positive operator valued measurements (POVMs) which are the most general class of quantum measurements. In a POVM, we do not care about the resulting state after the measurement; only the probability of a specific outcome $a$. Above, we determined this to be $\tr(M_a\rho M^\dag_a)$. Using a nice property of the trace, $\tr(AB) = \tr(BA)$, we see that $\tr(M_a\rho M^\dag_a) = \tr(M^\dag_aM_a \rho ) = \tr(E_a \rho)$ where $E_a = M^\dag_aM_a$. Given that $\tr(E_a \rho)$ is the probability that we will see outcome $a$, we can think of $E_a$ as a ``probability'' matrix for outcome $a$ that we multiply with $\rho$ to obtain the probability that we measure $a$. Then note that the completeness condition, i.e. Eqn. \ref{eq:phya:completeness}, can be restated as $\sum_{a} E_a = 1$ -- intuitively, this is like $\sum_{i} p_i = 1$ for a probability distribution. So POVM is a generalization of measurement, but in a different flavor.

\fill

\noindent It would appear on the surface that a physically admissible operator $\Phi$ is more powerful than a unitary $U$ because $U$ is just $\Phi$ with $k = 1$, i.e. $\Phi$ has more matrices that we're applying on $\rho$. Surprisingly according to Stinespring's Dilation Theorem, this is not the case - unitaries and physically admissible operators are \emph{equally} powerful. Proving this result is beyond the scope of this class, but the basic idea is that we can simulate any circuit implementing $\Phi$ with a corresponding unitary circuit using some ancilla bits as input to the latter. At a high-level, the diagram looks like the following:
\includegraphics[scale = 0.7]{phisim}
%NOTE: Don't know how to draw the above as a circuit, spent too much time trying to figure it out.

\noindent \Example{4} As an example, let's simulate $\Phi$ as described in Example 1. The following circuit will do the trick:

\centerline{
\Qcircuit @C=1em @R=0.75em {
	\lstick{\ket{0}}   & \targ & \qw & \qw \\
	\lstick{\alpha\ket{0}+\beta\ket{1}} & \ctrl{-1} & \qw & \rstick{\rho' = \Phi(\rho)}
}
}

\fill

\noindent so we see that we've introduced an extra ancillary bit and applied the CNOT gate to do the measurement, discarding the ancilla at the end.

%==============================%
\section{Quantum Information Theory}
%==============================%
So far we talked about the no-cloning theorem (1), distinguishing between two quantum states (2), entanglement (3), and the density matrix formalistm (4). An example of (2) was given in HW. 1 Problem 4. Here Alice and Bob are physically separated, each given one of the qubits of some 2-qubit state; the 2-qubit state is either State I or State II. The problem asked us to devise a strategy they could use to distinguish whether they're sharing State I or State II given that they are allowed to make only local measurements and communicate across a classical channel. An example of (3) was quantum teleportation where we showed that through entanglement, Alice can transmit a 1-qubit state to Bob.

\fill

\noindent In both classical and quantum information theory, we have three important issues that we would like to consider. These are:
\begin{enumerate}[start=0]
\item What is the information comprised of? What is its source? How do we measure the \emph{amount} of information that's being transmitted?
	\begin{itemize}
		\item In the classical world, the source is a random variable $X$. We measure the amount of information using the Shannon entropy, $\se(X)$.

		\item In the quantum world, the source is a mixed state $\rho$. We measure the amount of information using the Von Neumann entropy, $\vne(\rho)$.
	\end{itemize}

\item How do we transmit information over a noiseless channel? To put another way, if we store the information on a physical device, then what is the optimal compression that's possible for storing this information source?
	\begin{itemize}
		\item Given an $m$-bit source, if we want to represent it using only $\alpha\bullet m$ bits where $\alpha < 1$, then Shannon's noiseless source coding theorem says that we can only do so iff $\alpha \geq H(X)$

		\item Given a density matrix $\rho$ on $m$-qubits, if we want to represent it using only $\alpha\bullet m$ qubits where $\alpha < 1$, then Schumacher's noiseless quantum source coding theorem says that we can only do so iff $\alpha \geq S(\rho)$.
	\end{itemize}

\item How do we transmit information over a noisy channel?
	\begin{itemize}
		\item We can do so using error correction codes, ECC.

		\item We can do so using quantum error correction codes, QECC.
	\end{itemize}
\end{enumerate}

\fill

\noindent Imagine that we have a classical source churning out $m$-bit binary strings that are being transmitted on a quantum channel. The information transfer can be summarized by the following steps for a given $n$-bit binary string $x$:
\begin{enumerate}
\item The classical source churns out $x$

\item Some kind of process encodes $x$ as a $\alpha\bullet n$ qubit quantum source $\rho_x$, where $\alpha \leq 1$.

\item $\rho_x$ is transmitted across the quantum channel.

\item $\rho_x$ is decoded at the end to get back $x$.
\end{enumerate}
The question here is whether we can use a shorter quantum message to transmit our classical message, i.e. if we can find an $\alpha < 1$. Unfortunately, we're stuck with $\alpha = 1$ due to Holevo's theorem, which states that it is impossible to communicate more than $n$ bits of classical information when transmitting $n$ qubits.

%==============================%
\section{Entropy}
%==============================%

\subsection{Shannon Entropy}
We think of information as some kind of a message but, as counter-intuitive as it might be, a message may not necessarily contain any ``information''. For example, if all participating parties know the exact contents of the message that's being transmitted, then anybody who opens to read the message does not gain any new ``information'' -- they already know what to expect! So really, it is better to think of ``information'' as the \emph{amount of uncertainty} that's present in a message. The more uncertainty we have in our message, the more ``information'' it contains. For example, an e-mailed job offer would tell you a lot of information because, in general, there are a lot of factors that determine whether you will get the job or not and hence, a lot of uncertainty on whether you will get said job.

\fill

\noindent In physics, entropy is a quantity used to capture the amount of uncertainty in a given system. Similarly, the \emph{Shannon Entropy} quantifies the amount of uncertainty in a given piece of information -- that is why we use the term entropy. Mathematically it is defined as follows. Say we have a source that outputs a random variable $X \in \set{0, 1}^m$ with probability $p_x$. Then we define the Shannon Entropy $\se(x)$ as:
\begin{equation} \label{eq:def-se}
\se(X) = -\sum_{x} p_x \lg{p_x}
\end{equation}
where we define $0\lg{0} = 1$.

\fill

\noindent \Example{5} Let $X \in \set{0, 1}$ where $p_0 = 0$ and $p_1 = 1$. Note that there is no uncertainty involved in $X$ -- we know that our source will always transmit a $1$. Thus we expect that $\se(X) = 0$. Doing the calculation:
\begin{align*}
\se(X)
&= -\sum_{x} p_x \lg{p_x} \\
&= -1\lg{1} \\
&= 0
\end{align*}

\fill

\noindent \Example{6} Let $X \in \set{0, 1}$ where $p_0 = p_1 = 1/2$, i.e. $X$ corresponds to a fair coin. Then we see that:
\begin{align*}
\se(X)
&= -\sum_{x} p_x \lg{p_x} \\
&= -\left(
\frac{1}{2}\lg{\frac{1}{2}} + \frac{1}{2}\lg{\frac{1}{2}}
\right) \\
&= -(-\frac{1}{2} + -\frac{1}{2}) \\
&= 1
\end{align*}
which is exactly 1-bit of information. This is the mathematical definition of a bit.

\fill

\noindent Generalizing Example 6, if we have $X \in \set{0, 1}^m$ and $H(X) = m$, then this corresponds to $m$ fair coins each with 1-bit of information for a total of $m$-bits of information. Note that the Shannon Entropy is non-negative, bounded by the size of %NOTE: I didn't quite hear this part in lecture, so couldn't record it.
It also works well in a syntactic sense in that we can take many independent and identically distributed random variables %NOTE: Didn't hear this part in lecture too, I think it was glazed over.

\subsection{Von Neumann Entropy}
Imagine that we have an $m$-qubit space $\X$, and a source that outputs $k$ pure states with probability $p_k$ for each. Then our source is summarized by the density matrix $\rho_x = \sum_{i} p_i \kera{\psi_i}$. First, note that the quantum source subsumes the classical source as any classical source with $X \in \{0, 1\}^m$ and associated probability $p_x$ is just the densitry matrix $\rho' = \sum_{x \in \set{0, 1}^m} p_x \kera{x}$. %NOTE: In class, we had a density matrix with density matrices p1, p2, ..., pm along its diagonals as being the one that summarizes a classical source. I don't understand why this is the case. The previous sentence makes more sense to me so I included that instead. If it is incorrect, then I apologize.
Let us try to come up with a way to describe the amount of information contained in the density matrix, i.e. its entropy. At a glance, it might seem like we could use $\se$ defined above. Letting $\e(\rho_x)$ denote the entropy quantity of $\rho_x$, we get:
\begin{equation*}
\e(\rho_x) = -\sum_{i} p_i \lg{p_i}
\end{equation*}
However this definition does not work because two different quantum sources can have the same entropy -- entropy is meant to be unique. For example, the quantum source $S_1$ that outputs $\ket{0}$ with probability $1/2$ and $\ket{1}$ with probability $1/2$ is certainly different than the quantum source $S_2$ that outputs $\ket{0}$ with probability $1/2$ and $\ket{+}$ with probability $1/2$ -- the density matrices are not the same! However the probabilities of all the possible pure states in each source are the same, so $\e(S_1) = \e(S_2)$. The intuition is that in the quantum world, we have different bases that we can output our information in such as the standard and Hadamard bases. Further, there is no requirement that the pure states outputted by our source be orthogonal or even form an orthonormal basis -- $S_2$ is an example of one such source. In the classical world, however, everything is in binary -- all our possible sources will output information that's the same representation, so it is enough to just examine the probabilities. But the Shannon Entropy is too limited in the quantum world because we have sources that output different kinds of pure states together.

\fill

\noindent Fortunately, there is a way we can resolve our problem and that is by using the spectral decomposition. Because $\rho$ is positive semi-definite, it has a unique decomposition under the eigenbasis which is:
\begin{equation*}
\rho = \sum_{i = 0}^{d-1} \lambda_i \kera{\psi_i}
\end{equation*}
where $d$ is the dimension of $\rho$'s space, $\lambda_i$ is an eigenvalue, and $\ket{\psi_i}$ is an eigenvector such that $\rho\ket{\psi_i} = \lambda_i \ket{\psi_i}$ and $\bret{\psi_i}{\psi_j} = \delta_{ij}$. Note that $\lambda_i \geq 0$. Because $\tr(\rho) = 1$, we see that $\sum_{i} \lambda_i = 1$ so the eigenvalues form a valid probability distribution. Then we define the Von-Neumann entropy $\vne$ as:
\begin{equation} \label{eq:def-vne}
\vne(\rho) = -\sum_{i = 0}^{d-1} \lambda_i \lg{\lambda_i}
\end{equation}

\fill

\noindent \Example{7} Consider the source summarized by $\rho = \kera{0}$, i.e. a source that always outputs the pure state $\ket{0}$. We would expect that $\vne(\rho) = 0$ since there is no uncertainty in what state we get. This is indeed the case, as $\vne(\rho) = -1\lg{1} = 0$, i.e. $\lambda = 1$ is the only eigenvalue of $\rho$.

\fill

\noindent \Example{8} Consider a fair coin, i.e. the source where $\rho = \frac{1}{2}\kera{0} + \frac{1}{2}\kera{1}$. Here, $\vne(\rho) = 1$ which matches the corresponding classical case. In fact, if we have a mixed state on $n$-qubits where $\rho = \frac{1}{2^n}I$, then $\vne(\rho) = n$.

\end{document}


\section{Analysis of variance (ANOVA)}