\documentclass{article}
\usepackage{simplewick}
\usepackage{amsmath,mathtools,amssymb}
\usepackage{graphicx}
\usepackage{gensymb}
\usepackage{verbatim}
\usepackage{cancel}
\usepackage{mathrsfs}
\usepackage{bbm}
\usepackage{braket}
\usepackage{xcolor}
\definecolor{orange}{RGB}{255,127,0}
\definecolor{green}{RGB}{34,139,34}
\definecolor{purple}{RGB}{153,50,204}
\definecolor{blue}{RGB}{70,130,180}
\usepackage{verbatim}
\usepackage[margin=1.0in]{geometry}
\newcommand{\ol}{\overline}
\newcommand{\ctr}{\bcontraction}
\newcommand{\fctr}{\contraction}
\newcommand{\ve}{\varepsilon}
\newcommand{\kphi}{\ensuremath{\ket{\Phi}} }
\newcommand{\ap}{\ensuremath{a_p} }
\newcommand{\dg}{\ensuremath{^\dagger} }
\newcommand{\cd}{\ensuremath{\cdots} }
\newcommand{\apd}{\ensuremath{a_p^\dagger} }
\def\*#1{\mathbf{#1}}
\def\cb#1{{\color{blue}#1}}
\def\co#1{{\color{orange}#1}}
\def\cre#1{{\color{red}#1}}
\def\cg#1{{\color{green}#1}}
\def\cp#1{{\color{purple}#1}}
\DeclarePairedDelimiter\floor{\lfloor}{\rfloor}

\title{Lecture 3.6:  $a_p$ and $a_p\dg$ in the Particle-Hole Formalism}
\date{February 26$^{\text{th}}$, 2020}
\begin{document}
\maketitle
\noindent
Previously, we saw that to work in the Fermi vacuum, we could first translate
particle operators $a_p$ and $a_p\dg$ into quasiparticle operators $b_p$ and $b_p\dg$.
This was not efficient because for each $p$ there are two cases to consider: occupied and unoccupied.
For a string of 4 operators, $a_p\dg a_q\dg a_s a_r$, this would mean we have 16 terms in the particle-hole formalism to deal with.
Instead, we want to work directly with $a_p$ and $a_p\dg$ in the particle-hole formalism.
Our next task is to see how to do that.
\section{ Working with $a_p$ and $a_p\dg$ in the particle-hole formalism }
\subsection{Anticommuntation relations}
The anticommuntation relations for $a_p$ and $a_p\dg$ stays the same.
Strictly speaking, we see that the definitions depend on what the index $p$ is,
for example:
\[{a_i, a_a} = {b_i\dg, b_a} = \delta_{ia}\]
However, this quantity ends up being 0 because $\delta_{ia}$ is always 0.
We can make this sort of argument for all mixed cases of occupied and unoccupied indices to see that
the anticommuntation relations remains:
\begin{enumerate}
\item  $\{a_p, a_q\} = 0$
\item $\{a_p^\dagger, a_q^\dagger \} = 0$
\item $\{a_p, a_q\dg \} = \delta_{pq}$
\end{enumerate}
\subsection{$\Phi$-Normal products using $a_p$ and $a_p\dg$}
How do we evaluate $N[a_p\dg a_q a_r\dg]$?
We need to translate back to quasiparticle operators.
In order to do that, we have to specify occupation for the indices.  \\ \\
In the case where $p=i$, $q=j$, and $r=a$,
\begin{align*}
N[a_i\dg a_j a_a\dg] &= N[b_i b_j\dg b_a\dg] \\
&= b_j\dg b_a\dg b_i \\
&= a_j a_a\dg a_i\dg \\
&\neq n[a_i\dg a_j a_a\dg]
\end{align*}
Thus, we see that $N[x_1\cd x_m] \neq n[x_1 \cd x_m]$, and the relationship between the two depends on the indices. \\  \\
A formal definition for the normal product is:
\[N[x_1 \cd x_m]  = (-1)^R b_{R_1}\dg \cd b_{R_\alpha}\dg b_{R_{\alpha+1}} \cd b_{R_m} \]
Thus, a $\Phi$-normal product using $a_p$ and $a_p\dg$ still means that all the quasiparticle operators $b_p\dg$ are to the left and $b_p$ are to the right.
In order to explicitly write a form for $N[x_1 \cd x_m]$, we would need to know the occupation of the indices.
\subsection{Contractions in the Fermi vacuum using $a_p$ and $a_p\dg$}
To figure out what contractions between $a_p$ and $a_p\dg$ look like with respect to the Fermi vacuum, we first introduce the step functions $\chi$ and
$\pi$:
\[
\chi (p) =
    \begin{cases}
      1  & p \in occupied \\
      0 & p \in unoccupied
    \end{cases}
\]

\[
  \pi(p) =
    \begin{cases}
      0  & p \in occupied \\
      1  & p \in unoccupied
    \end{cases}
\]
For example,
\[\chi(i) = 1 \quad  \quad \chi(a) = 0 \quad  \quad \pi(i) = 0 \quad   \quad \pi(a) = 1\]
\\ \\
The step functions have the following properties:
 \[\chi(p) + \pi(p) = 1 \]
 \[\chi(p)\pi(p) = 0 \]
\[\chi^2(p) = \chi(p) \]
\[\pi^2(p) = \pi(p) \]
We can use the step functions to inform how to map between particle operators and quasiparticle operators.
For example, $\chi(p)a_p = b_p\dg$.\\ \\
Let's see how we can figure out how to compute a contraction in the Fermi vacuum for $a_p$ and $a_q$:
\begin{align*}
 \fctr{}{a}{{}_p}{a}
 a_p a_q  &=(1)(1) \fctr{}{a}{{}_p}{a} a_p a_q \\
  &= [\chi(p) + \pi(p)][\chi(q) + \pi(q)] \fctr{}{a}{{}_p}{a} a_p a_q \\
 &= \chi(p)\chi(q)\fctr{}{a}{{}_p}{a} a_p a_q + \chi(p) \pi(q) \fctr{}{a}{{}_p}{a} a_p a_q  +  \pi(p)\chi(q) \fctr{}{a}{{}_p}{a} a_p a_q  +
 \pi(p) \pi(q) \fctr{}{a}{{}_p}{a} a_p a_q
\end{align*}
Now, the step functions will inform what b operator to translate to:
\begin{align*}
 \fctr{}{a}{{}_p}{a}a_p a_q
 &= \chi(p)\chi(q)\fctr{}{a}{{}_p}{a} a_p a_q + \chi(p) \pi(q) \fctr{}{a}{{}_p}{a} a_p a_q  +  \pi(p)\chi(q) \fctr{}{a}{{}_p}{a} a_p a_q  +
 \pi(p) \pi(q) \fctr{}{a}{{}_p}{a} a_p a_q  \\
&= \chi(p)\chi(q)\fctr{}{b}{{}_p\dg}{b} b_p\dg b_q\dg + \chi(p) \pi(q) \fctr{}{b}{{}_p\dg}{b} b_p\dg b_q  +  \pi(p)\chi(q) \fctr{}{b}{{}_p}{b} b_p b_q\dg  +
 \pi(p) \pi(q) \fctr{}{b}{{}_p}{b} b_p b_q \\ \\
&  \text{we can get rid of all contractions that go to zero} \\
&= \cre{\cancelto{0}{\chi(p)\chi(q)\fctr{}{b}{{}_p\dg}{b} b_p\dg b_q\dg}} + \cre{\cancelto{0}{\chi(p) \pi(q) \fctr{}{b}{{}_p\dg}{b} b_p\dg b_q}}  +  \pi(p)\chi(q) \fctr{}{b}{{}_p}{b} b_p b_q\dg  +
\cre{\cancelto{0}{ \pi(p) \pi(q) \fctr{}{b}{{}_p}{b} b_p b_q }}\\
&=  \pi(p)\chi(q) \delta_{pq} \\
&=  \pi(p)\chi(p) \\
&= 0
\end{align*}
We can take the same steps to find $\fctr{}{a}{{}_p\dg}{a} a_p\dg a_q $:
\begin{align*}
 \fctr{}{a}{{}_p\dg}{a}
 a_p\dg a_q  &= [\chi(p) + \pi(p)][\chi(q) + \pi(q)] \fctr{}{a}{{}_p\dg}{a} a_p\dg a_q \\
 &= \chi(p)\chi(q)\fctr{}{a}{{}_p\dg}{a} a_p\dg a_q + \chi(p) \pi(q) \fctr{}{a}{{}_p\dg}{a} a_p\dg a_q  +  \pi(p)\chi(q) \fctr{}{a}{{}_p\dg}{a} a_p\dg a_q  +
 \pi(p) \pi(q) \fctr{}{a}{{}_p\dg}{a} a_p\dg a_q \\
 &= \chi(p)\chi(q)\fctr{}{b}{{}_p}{b} b_p b_q\dg + \chi(p) \pi(q) \fctr{}{b}{{}_p}{b} b_p b_q  +  \pi(p)\chi(q) \fctr{}{b}{{}_p\dg}{b} b_p\dg b_q\dg  +
 \pi(p) \pi(q) \fctr{}{b}{{}_p\dg}{b} b_p\dg b_q \\
 &= \chi(p)\chi(q)\fctr{}{b}{{}_p}{b} b_p b_q\dg + \cre{\cancelto{0}{\chi(p) \pi(q) \fctr{}{b}{{}_p}{b} b_p b_q }} +  \cre{\cancelto{0}{ \pi(p)\chi(q) \fctr{}{b}{{}_p\dg}{b} b_p\dg b_q\dg}}  +
 \cre{\cancelto{0}{\pi(p) \pi(q) \fctr{}{b}{{}_p\dg}{b} b_p\dg b_q }}\\
 &= \chi(p)\chi(q) \delta_{pq} \\
 &= \chi(p)\chi(p) \delta_{pq} \\
 &= \chi^2(p)\delta_{pq} \\
 &= \chi(p)\delta_{pq} \\
  &= \gamma_{pq}\\
\end{align*}
We can do the same type of derivation for $ \fctr{}{a}{{}_p}{a}a_p a_q\dg$ and  $\fctr{}{a}{{}_p}{a} a_p\dg a_q\dg$.
You will practice this in your homework.
The end result is:
 $$
 \fctr{}{a}{{}_p}{a}
 a_p a_q  = 0
 $$

 $$
 \fctr{}{a}{{}_p}{a}
 a_p a_q\dg = \pi(p)\delta_{pq} = \eta_{pq}
 $$

 $$
 \fctr{}{a}{{}_p}{a}
 a_p\dg a_q =   \chi(p)\delta_{pq} = \gamma_{pq}
 $$

 $$
 \fctr{}{a}{{}_p}{a}
 a_p\dg a_q\dg = 0
 $$
where we have defined $ \eta_{pq} = \pi(p)\delta_{pq}$ and $ \gamma_{pq} =  \chi(p)\delta_{pq} $.

\subsection{$\Phi$-Normal products using $a_p$ and $a_p\dg$}
From what we know so far, we see that a $\Phi$-normal product with contractions inside for particle operators
\[
\fctr{N[x_1 \cd }{x}{{}_{i_1} \cd x_{i_\lambda} \cd }{x}
\fctr[2ex]{N[x_1 \cd x_{i_1} \cd}{ x}{{}_{i_\lambda} \cd x_{j_1} \cd }{x}
N[x_1 \cd x_{i_1} \cd x_{i_\lambda} \cd x_{j_1} \cd x_{j_\lambda} \cd x_m]
\]
can be rewritten as:
\[
\fctr{N[x_1 \cd }{x}{{}_{i_1} \cd x_{i_\lambda} \cd }{x}
\fctr[2ex]{N[x_1 \cd x_{i_1} \cd}{ x}{{}_{i_\lambda} \cd x_{j_1} \cd }{x}
N[x_1 \cd x_{i_1} \cd x_{i_\lambda} \cd x_{j_1} \cd x_{j_\lambda} \cd x_m]
=
\fctr{(-1)^R}{x}{{}_{i_1} }{x}
\fctr{(-1)^R x_{i_1}x_{j_1} \cd}{x}{{}_{i_\lambda} }{x}
(-1)^R x_{i_1}x_{j_1} \cd x_{i_\lambda} x_{j_\lambda} N[x_{k_1} \cd x_{k_\mu}]
\]
where
\[
R =
\begin{pmatrix}
1 & 2 & \cd & 2\lambda -1 & 2\lambda & 2\lambda + 1&\cd & m  \\
i_1 & j_1 & \cd& i_\lambda & j_\lambda  &k_1 & \cd & k_\mu \\
\end{pmatrix}
\] \\
and the indices $2\lambda + \mu = m$.
\\ \\
For example:
\begin{align*}
N[ \fctr[2ex]{}{a}{{}_p\dg a_q a_r\dg}{a}
\fctr{ a_p\dg}{a}{{}_q }{a}
 a_p\dg a_q a_r\dg a_s \fctr{}{a}{{}_t}{a}a_t a_u\dg ]
 &= \fctr{}{a}{{}_p\dg}{a} a_p\dg a_s \fctr{}{a}{{}_q}{a}a_q a_r\dg\fctr{}{a}{{}_t}{a}a_t a_u\dg \\
 &= [\chi(p)\delta_{ps}] [\pi(p)\delta_{qr}] [\pi(t) \delta_{tu}]  \\
 &= \gamma_{ps} \eta_{qr} \eta_{tu}
\end{align*}

\subsection{Wick's Theorem}
Now that we have addressed what $\Phi$-normal ordering and $\Phi$-normal ordering with contractions mean for operators $a_p$ and $a_p\dg$, we are ready to state Wick's theorem for
$a_p$ and $a_p\dg$ in the particle-hole formalism:
\[x_1 \cd x_m = N[x_1\cd x_m] + \sum_{a.c.} N\ol{[x_1 \cd x_m]} \]
\\ \\
The generalized Wick's Theorem states:
\[x_1 \cd N[ x_\nu \cd x_\mu] \cd  x_m = N[x_1\cd x_m] + \sum_{a.c.}{}' N\ol{[x_1 \cd x_m]} \]
Where $ \sum_{a.c.}{}'$ stands for all possible contractions except the ones between the operators within the $\Phi$-normal order.
\subsection{Rules for expectation values}
We can now see what the rules imply for $a_p$ and $a_p\dg$ in the Fermi vacuum.
\begin{itemize}
\item Rule 1: $N[x_1 \cd x_m]\kphi = 0$ unless $x_1 \cd x_m$ only contains $a_p$ where $p \in occ$ and $a_q\dg$ where $q \in unocc$.
\item Rule 2: $\braket{\Phi | N[x_1 \cd x_m] | \Phi} = 0$ for  $m \geq 1$ \\
\item Rule 3. $\fctr{N[x_1 \cd }{x}{{}_{\nu_1} \cd x_{\nu_\lambda} \cd }{x}
\fctr[2ex]{N[x_1 \cd x_{\nu_1} \cd}{ x}{{}_{\nu_\lambda} \cd x_{\mu_1} \cd }{x}
N[x_1 \cd x_{\nu_1} \cd x_{\nu_\lambda} \cd x_{\mu_1} \cd x_{\mu_\lambda} \cd x_m] \kphi= 0$ if there is at least 1 uncontracted
operator $a_p\dg$ where $p \in occ$ or $a_q$ where $q \in unocc$  \\
\item Rule 4. $\bra{\Phi}\fctr{N[x_1 \cd }{x}{{}_{\nu_1} \cd x_{\nu_\lambda} \cd }{x}
\fctr[2ex]{N[x_1 \cd x_{\nu_1} \cd}{ x}{{}_{\nu_\lambda} \cd x_{\mu_1} \cd }{x}
N[x_1 \cd x_{\nu_1} \cd x_{\nu_\lambda} \cd x_{\mu_1} \cd x_{\mu_\lambda} \cd x_m] \kphi= 0$ unless all operators are contracted.
A vacuum expectation value of any normal product with contractions will be zero if there are a odd number of operators. \\

\item Rule 5 $\braket{\Phi | x_1 \cd x_{2m + 1} | \Phi} = 0 $ \\

\item Rule 6 $\braket{\Phi | x_1 \cd x_{2m } | \Phi} = \sum\limits_{f.c.} \braket{\Phi | N\ol{\ol{ [x_1 \cd x_{2m }]}}| \Phi} = \sum_{f.c.} (-1)^R
\fctr{}{x}{{}_{\nu_1}}{x} x_{\nu_1} x_{\mu_1} \cd \fctr{}{x}{{}_{\nu_m}}{x} x_{\nu_m} x_{\mu_m}$\\

\begin{equation*}
R =
\begin{pmatrix}
1 & 2 &\cd  & 2m - 1 & 2m  \\
\nu_1 & \mu_1 & \cd  & \nu_m & \mu_m \\
\end{pmatrix}
\end{equation*}

\item Rule 7  $x_1 \cd x_m \kphi = \sum\limits_{b_p f.c.} N\ol{[ x_1 \cd x_m]}\kphi$
where $ \sum\limits_{b_p f.c.}$ denotes that any $a_p\dg$ where $p \in occ$ or $a_q$ where $q \in unocc$ is fully contracted.
\end{itemize}
\subsection{Example: Deriving Slater's first rule}

We can use what we have learned so far to quickly derive Slater's first rule.

\[\braket{\Phi | H | \Phi} = \braket{\Phi | \sum_{pq} h_{pq} a_p\dg a_q + \frac{1}{2} \sum_{pqrs} \braket{pq | rs} a_p\dg a_q\dg a_s a_r | \Phi} \]
One-electron term:
\begin{align*}
 \sum_{pq} h_{pq} \braket{\Phi | a_p\dg a_q | \Phi} &=   \sum_{pq} h_{pq} \braket{\Phi | N[\fctr{}{a}{{}_p\dg}{a} a_p\dg a_q] | \Phi}) \\
 &=   \sum_{pq} h_{pq} \chi(p)\delta_{pq} \braket{\Phi | \Phi}  \\
 &=  \sum_{pq} h_{pq} \gamma_{pq} \\
 &=  \sum_{ij} h_{ij}\delta_{ij} \\
 &= \sum_i h_{ii}
\end{align*}
Two-electron term:
\begin{align*}
\frac{1}{2} \sum_{pqrs} \braket{pq | rs} \braket{\Phi| a_p\dg a_q\dg a_s a_r | \Phi} &= \frac{1}{2} \sum_{pqrs} \braket{pq | rs}  \sum_{f.c.}\braket{\Phi| N\ol{\ol{[a_p\dg a_q\dg a_s a_r]}} | \Phi} \\
&=  \frac{1}{2} \sum_{pqrs} \braket{pq | rs} ( \braket{\Phi| N[\fctr[2ex]{}{a}{{}_p\dg a_q\dg a_s}{a} \fctr{a_p\dg }{a}{{}_q\dg}{a} a_p\dg a_q\dg a_s a_r] | \Phi}
+ \braket{\Phi| N[ \fctr{}{a}{{}_p\dg a_q\dg}{a}  \fctr[2ex]{a_p\dg }{a}{{}_q\dg a_s}{a} a_p\dg a_q\dg a_s a_r] | \Phi} )\\
&= \frac{1}{2} \sum_{pqrs} \braket{pq | rs}  (\gamma_{pr}\gamma_{qs} - \gamma_{ps}\gamma_{qr}) \\
&\text{make assignments } p\rightarrow i \quad  q \rightarrow j \quad  r\rightarrow k \quad  s\rightarrow l \\
&= \frac{1}{2} \sum_{ijkl} \braket{ij | kl}  (\delta_{ik}\delta_{jl} - \delta_{il}\delta_{jk}) \\
&= \frac{1}{2} \sum_{ij}  \braket{ij | ij} -   \braket{ij | ji} \\
&= \frac{1}{2} \sum_{ij} \braket{ij || ij}
\end{align*}
What if we wanted to solve for matrix elements of terms like $ \braket{\Phi_{kl}^{cd} | H |\Phi_{ij}^{ab}}$?
This means we are working with 12 operators:
\[\braket{\Phi | \cg{a_l\dg a_d a_k\dg a_c }\cb{  a_p\dg a_q\dg a_s a_r } \co{a_a\dg a_i a_b\dg a_j } | \Phi} \]
Previously, in the particle formalism, we took advantage of the Generalized Wick's theorem to reduce the number of contractions we have to consider.
We only considered contractions between operators that were not from the same normal-ordered group.
We see that if we could put different groups in the above term in $\Phi$-normal ordering, we can reduce the number of terms we have to consider.

\section{Excitation operators from \kphi are already in $\Phi$-normal order}
We see that the operators associated with excitations from the reference determinant are already in $\Phi$-normal order. \\ \\
For example,
\[a_a\dg a_i a_b\dg a_j = b_a\dg b_i\dg b_b\dg b_j\dg = N[b_a\dg b_i\dg b_b\dg b_j\dg] = N[ a_a\dg a_i a_b\dg a_j ]\]
\\
We see that using anticommuntation relations, we can also equivalently write:
 \[N[b_a\dg b_i\dg b_b\dg b_j\dg] = N[b_a\dg b_b\dg b_j\dg b_i\dg  ] = N[ a_a\dg a_b\dg  a_j a_i  ]\]
 Both forms can be used to express excitations from the reference determinant.

\section{The $\Phi$-normal ordered Hamiltonian}
We can use Wick's theorem to help put the Hamiltonian in $\Phi$-normal order.
\\ \\
One-electron operator:
\begin{align*}
\hat{h} &= \sum_{pq} h_{pq} a_p\dg a_q \\
 &= \sum_{pq}h_{pq} (N[a_p\dg a_q] + N[\fctr{}{a}{{}_p\dg}{a} a_p\dg a_q]) \\
&= \sum_{pq}h_{pq} N[a_p\dg a_q] + \sum_{pq}h_{pq} \gamma_{pq} \\
&= \sum_{pq}h_{pq} N[a_p\dg a_q] + \sum_{i}h_{ii} \\
\end{align*}
Two-electron operator:
\begin{align*}
\hat{g} &=  \frac{1}{2} \sum_{pqrs} \braket{pq | rs} a_p\dg a_q\dg a_s a_r \\
&= \cg{\frac{1}{2} \sum_{pqrs} \braket{pq | rs} N[a_p\dg a_q\dg a_s a_r] } \\ \\
&+ \cb{\frac{1}{2} \sum_{pqrs} \braket{pq | rs} \left(N[\fctr{}{a}{{}_p\dg a_q\dg}{a}  a_p\dg a_q\dg a_s a_r] +
N[\fctr{}{a}{{}_p\dg a_q\dg a_s}{a}  a_p\dg a_q\dg a_s a_r] +
N[\fctr{a_p\dg}{a}{{}_q\dg }{a}  a_p\dg a_q\dg a_s a_r] +
N[\fctr{a_p\dg}{a}{{}_q\dg a_s }{a}  a_p\dg a_q\dg a_s a_r] \right)} \\
&+ \co{ \frac{1}{2} \sum_{pqrs} \braket{pq | rs} \left(
N[\fctr[2ex]{}{a}{{}_p\dg a_q\dg a_s }{a} \fctr{a_p\dg}{a}{{}_q\dg}{a}  a_p\dg a_q\dg a_s a_r] +
N[\fctr{}{a}{{}_p\dg a_q\dg }{a}  \fctr[2ex]{a_p\dg}{a}{{}q\dg a_s}{a} a_p\dg a_q\dg a_s a_r]
  \right) } \\  \\
&= \cg{\frac{1}{2} \sum_{pqrs} \braket{pq | rs} N[a_p\dg a_q\dg a_s a_r] } \\
&+ \cb{\frac{1}{2} \sum_{pqrs} \braket{pq | rs} \left(-\gamma_{ps} N[ a_q\dg a_r] +
\gamma_{pr} N[ a_q\dg a_s ] +
\gamma_{qs} N[ a_p\dg a_r] -
\gamma_{qr} N[ a_p\dg a_s] \right)} \\
&+ \co{ \frac{1}{2} \sum_{pqrs} \braket{pq | rs} ( \gamma_{pr}\gamma_{qs} -\gamma_{ps}\gamma_{qr}) }\\ \\
&= \cg{\frac{1}{2} \sum_{pqrs} \braket{pq | rs} N[a_p\dg a_q\dg a_s a_r] } \\
& \cb{- \frac{1}{2} \sum_{qr} \sum_i \braket{iq | ri} N[ a_q\dg a_r] +
\frac{1}{2} \sum_{qs} \sum_i \braket{iq | is} N[ a_q\dg a_s ] +
\frac{1}{2} \sum_{pr} \sum_i \braket{pi | ri} N[ a_p\dg a_r] -
\frac{1}{2} \sum_{ps} \sum_i \braket{pi | is} N[ a_p\dg a_s] } \\
&+ \co{ \frac{1}{2} \sum_{ij} \braket{ij || ij} }
\end{align*}
We can perform a change of variables and permute within the integrals:
\begin{align*}
\hat{g}&= \cg{\frac{1}{2} \sum_{pqrs} \braket{pq | rs} N[a_p\dg a_q\dg a_s a_r] } \\
& \cb{- \frac{1}{2} \sum_{pq} \sum_i \braket{ip | qi} N[ a_p\dg a_q] +
\frac{1}{2} \sum_{pq} \sum_i \braket{ip | iq} N[ a_p\dg a_q ] +
\frac{1}{2} \sum_{pq} \sum_i \braket{pi | qi} N[ a_p\dg a_q] -
\frac{1}{2} \sum_{pq} \sum_i \braket{pi | iq} N[ a_p\dg a_q] } \\
&+ \co{ \frac{1}{2} \sum_{ij} \braket{ij || ij} } \\ \\
&= \cg{\frac{1}{2} \sum_{pqrs} \braket{pq | rs} N[a_p\dg a_q\dg a_s a_r] } \\
& \cb{ \frac{1}{2} \sum_{pq} \sum_i \braket{pi | qi} N[ a_p\dg a_q] -
\frac{1}{2} \sum_{pq} \sum_i \braket{pi | iq} N[ a_p\dg a_q ] +
\frac{1}{2} \sum_{pq} \sum_i \braket{pi | qi} N[ a_p\dg a_q] -
\frac{1}{2} \sum_{pq} \sum_i \braket{pi | iq} N[ a_p\dg a_q] } \\
&+ \co{ \frac{1}{2} \sum_{ij} \braket{ij || ij} }
\end{align*}
We can reorder the order of terms:
\begin{align*}
&= \cg{\frac{1}{2} \sum_{pqrs} \braket{pq | rs} N[a_p\dg a_q\dg a_s a_r] } \\
& \cb{+ \frac{1}{2} \sum_{pq} \sum_i \braket{pi | qi} N[ a_p\dg a_q] +
\frac{1}{2} \sum_{pq} \sum_i \braket{pi | qi} N[ a_p\dg a_q ] -
\frac{1}{2} \sum_{pq} \sum_i \braket{pi | iq} N[ a_p\dg a_q] -
\frac{1}{2} \sum_{pq} \sum_i \braket{pi | iq} N[ a_p\dg a_q] } \\
&+ \co{ \frac{1}{2} \sum_{ij} \braket{ij || ij} }\\ \\
&= \cg{\frac{1}{2} \sum_{pqrs} \braket{pq | rs} N[a_p\dg a_q\dg a_s a_r] } \\
& \cb{+ \sum_{pq} \sum_i ( \braket{pi | qi} - \braket{pi | iq})  N[ a_p\dg a_q]} \\
&+ \co{ \frac{1}{2} \sum_{ij} \braket{ij || ij} } \\ \\
&=  \cg{\frac{1}{2} \sum_{pqrs} \braket{pq | rs} N[a_p\dg a_q\dg a_s a_r] } +  \cb{ \sum_{pq} \sum_i \braket{pi || qi}   N[ a_p\dg a_q]} + \co{ \frac{1}{2} \sum_{ij} \braket{ij || ij} }
\end{align*}
All together, we get:
\[H = \sum_{pq}h_{pq} N[a_p\dg a_q] + \sum_{i}h_{ii} + \frac{1}{2} \sum_{pqrs} \braket{pq | rs} N[a_p\dg a_q\dg a_s a_r]  +   \sum_{pq} \sum_i \braket{pi || qi}   N[ a_p\dg a_q] +  \frac{1}{2} \sum_{ij} \braket{ij || ij}  \]
We see that the second and fifth terms have no operators, and
the first and fourth terms both have 2 operators.
We can group these terms together:
\[H = \co{ \sum_{i}h_{ii} + \frac{1}{2} \sum_{ij} \braket{ij || ij}}  + \cb{\sum_{pq}h_{pq} N[a_p\dg a_q]  +   \sum_{pq} \sum_i \braket{pi || qi}   N[ a_p\dg a_q]}
  + \cg{\frac{1}{2} \sum_{pqrs} \braket{pq | rs} N[a_p\dg a_q\dg a_s a_r]}  \]
  The first two terms we see are simply $\braket{\Phi |H|\Phi}$:
 \[H = \co{ \braket{\Phi |H|\Phi}} + \cb{\sum_{pq}h_{pq} N[a_p\dg a_q]  +   \sum_{pq} \sum_i \braket{pi || qi}   N[ a_p\dg a_q]}
  + \cg{\frac{1}{2} \sum_{pqrs} \braket{pq | rs} N[a_p\dg a_q\dg a_s a_r]}  \]
  The remaining terms now form our $\Phi$-normal ordered Hamiltonian, $\hat{H}_N$:
   \[H = \co{ \braket{\Phi |H|\Phi}} + H_N\]
   \[H_N = \cb{\sum_{pq}h_{pq} N[a_p\dg a_q]  +   \sum_{pq} \sum_i \braket{pi || qi}   N[ a_p\dg a_q]}
  + \cg{\frac{1}{2} \sum_{pqrs} \braket{pq | rs} N[a_p\dg a_q\dg a_s a_r]} \]
  The $\Phi$-normal ordered Hamiltonian can be further divided into 2 terms:
     \[H_N = \cb{F_N} + \cg{G_N} \]
     \[  \cb{F_N = \sum_{pq}h_{pq} N[a_p\dg a_q]  +   \sum_{pq} \sum_i \braket{pi || qi}   N[ a_p\dg a_q]} \]
     \[ \cg{G_N = \frac{1}{2} \sum_{pqrs} \braket{pq | rs} N[a_p\dg a_q\dg a_s a_r]}\]
  $F_N$, called the Fock operator, is an effective one-electron operator.
  The first term tells us about state q leaving and arriving at state p.
  The second term tells about state q leaving and arriving at state p \textit{in the presence of occupied orbitals i}.
  It describes an effective one-body interaction that comes from a two-body operator.
  In other words, it contains information about two-body interactions in a mean-field manner.
$G_N$ is the usual two-electron operator.
\\ \\
We can re-express $F_N$ as:
 \[  \cb{F_N = \sum_{pq} (h_{pq} + \sum_i \braket{pi || qi}  ) N[a_p\dg a_q] }  \]
  \[  \cb{F_N = \sum_{pq} f_{pq} N[a_p\dg a_q] } \]
  And re-express $H_N$ as:
       \[H_N =  \cb{\sum_{pq} f_{pq} N[a_p\dg a_q] }  + \cg{ \frac{1}{2} \sum_{pqrs} \braket{pq | rs} N[a_p\dg a_q\dg a_s a_r] }\]
 \section{Implications of the $\Phi$-normal ordered Hamiltonian}
 We have thus arrived at a $\Phi$-normal ordered Hamiltonian:
 \[ H_N =  H-  \braket{\Phi |H|\Phi}\]
What have we done qualitatively?
We see that the $\Phi$-normal ordered Hamiltonian is obtained by shifting the original Hamiltonian by the expectation value in the reference determinant.
In other words, it is removing the energy contribution of the reference determinant.
This makes sense.
In our original mapping to the particle-hole formalism, we make the reference determinant a vacuum state.
Thus, the $\Phi$-normal ordered Hamiltonian, which is in the particle-hole formalism does not have any interaction with reference determinant.
In the same way that in our original formalism,
\[\braket{0| H | 0} = 0\]
In the particle-hole formalism,
\[\braket{\Phi| H_N | \Phi} = 0\]
 Mathematically, the choice of the reference determinant is arbitrary. It does not matter which determinant you use in the wavefunction expansion.
 Practically, it is more efficient to choose a determinant that dominates the wavefunction expansion (large coefficient).
 If we choose our reference determinant \kphi to be the Hartree-Fock result, then shifting the Hamiltonian by the Hartree-Fock
 energy $E_{HF} = \braket{\Phi |H|\Phi}$ means we are really just defining a Hamiltonian that takes care of correlation effects.
\[H = E_{HF} + H_{correlation} \]
 The $\Phi$-normal ordered Hamiltonian is thus equal to a correlation Hamiltonian $H_c$:
 \[H_N = H_c \]
\end{document}


%LuaLaTeX
\documentclass[a4paper]{article}
\usepackage{luatexja}
\usepackage{musikui}
\usepackage{listings}
\usepackage[pdfencoding=auto]{hyperref}
\usepackage{longtable}
\usepackage{shortvrb}
\MakeShortVerb{\|}
\newcommand{\Meta}[1]{$\langle$\mbox{}\nobr#1\nobr\mbox{}$\rangle$}
\newcommand{\Note}{\par\noindent ※}
\newcommand{\Means}{：\ }
\newcommand{\nobr}{\nolinebreak[4]}
\newcommand*{\PKN}[1]{\textsf{#1}}

\title{The \PKN{musikui} package v1}
\author{Naoki Kaneko}
\date{2018/04/25}
\begin{document}
\maketitle

This package is for easy expression of arithmetical restorations with \LaTeX.

\begin{center}
\begin{musikui}
\wari{\eaten&\eaten&\eaten&\eaten&\eaten&\eaten&\eaten&\eaten}
{\eaten&\eaten&\eaten}
{\eaten&7&\eaten&\eaten&\eaten}
\musi{\eaten&\eaten&\eaten&\eaten}{4}
\sen
\musi{\eaten&\eaten&\eaten}{3}
\musi{\eaten&\eaten&\eaten}{3}
\sen
\musi{\eaten&\eaten&\eaten&\eaten}{2}
\musi{\eaten&\eaten&\eaten}{2}
\sen
\musi{\eaten&\eaten&\eaten&\eaten}{0}
\musi{\eaten&\eaten&\eaten&\eaten}{0}
\sen
\musi{0}{0}
\end{musikui}
\end{center}

The package is maintained on GitHub:
\begin{itemize}
\item \url{https://github.com/puripuri2100/musikui.sty}
\end{itemize}
\section{Package read}
Read using |\usepackage| command. There is no option.

\begin{quote}
|\usepackage{musikui}|
\end{quote}
\section{Dependent package}
\PKN{graphics} package

\section{License}
The MIT License

\section{Provide command}
\subsection{Commands related to composition}
\begin{quote}
|\kake{|\Meta{multiplicand}|}{|\Meta{multiplier}|}{|\Meta{product}|}|\\
|\wari{|\Meta{dividend}|}{|\Meta{divide}|}{|\Meta{quotient}|}|\\
|\musi{|\Meta{holes}|}{|\Meta{distance from the right end}|}|\\
|\sen|\\
|\bubunsen{|\Meta{length}|}{|\Meta{distance from the right end}|}|
\end{quote}

\subsection{Commands related to holes}
\begin{quote}
|\eaten{|\Meta{numbers etc.}|}|\\
|\noneaten{|\Meta{numbers etc.}|}|\\
|\halfeaten{|\Meta{numbers etc.}|}|\\
|\halfnoneaten{|\Meta{numbers etc.}|}|\\
|\hhalfeaten{|\Meta{numbers etc.}|}|\\
|\hhalfnoneaten{|\Meta{numbers etc.}|}|
\end{quote}

\section{The role of each command}
The role of each command is shown in Table \ref{yakuwari}.
\begin{longtable}[h]{rp{23em}}
\caption{\label{yakuwari}}\\
|\kake|&Outputs \Meta{multiplicand},\Meta{multiplier} and \Meta{product} of multiplication arithmetical restorations calculation.\\
|\wari|&Outputs \Meta{dividend},\Meta{divide} and \Meta{quotient} of division arithmetical restorations calculation.\\
|\musi| &Outputs \Meta{holes},\Meta{distance from the right end}.\\
|\sen|&line\\
|\bubunsen|&Line of the specified length\\
|\eaten|&normal hole\\
|\noneaten| &hole without a line \\
|\halfeaten| &Half the width hole of \verb|\eaten|.\\
|\halfnoneaten| &Hole without a line with half width of  \verb|\eaten|.\\
|\hhalfeaten| &Two holes with |\harleaten| side by side.\\
|\hhalfnoneaten| &|\hhalfeaten| line without a hole
\end{longtable}

\section{Notation}
Use one musikui environment per an arithmetical restorations.
For the representation part of the hole, a hole and a hole (or a number) are connected by  ``|&|".
After using |\kake| or |\wari|, you just line |\musi| and |\sen| like the hole counting you want to express.
An example of division and multiplication is given below.

\begin{longtable}[h]{lr}
\begin{minipage}{0.7\hsize}
\begin{verbatim}
\begin{musikui}
\kake{8&\eaten&6&\eaten}
{\eaten&\eaten}
{\eaten&\eaten&\eaten&\eaten&\eaten}
\musi{\eaten&6&\eaten&\eaten&\eaten}{0}
\musi{\eaten&\eaten&\eaten&6}{1}
\sen
\end{musikui}

\end{verbatim}
\end{minipage}
&
\begin{minipage}{0.4\hsize}
\begin{musikui}
\kake{8&\eaten&6&\eaten}
{\eaten&\eaten}
{\eaten&\eaten&\eaten&\eaten&\eaten}
\musi{\eaten&6&\eaten&\eaten&\eaten}{0}
\musi{\eaten&\eaten&\eaten&6}{1}
\sen
\end{musikui}
\end{minipage}
\\\hline
\begin{minipage}{0.7\hsize}
\begin{verbatim}

\begin{musikui}
\wari{\eaten&\eaten&\eaten&\eaten}
{\eaten&\eaten}
{\eaten&\eaten}
\musi{\eaten&\eaten}{1}
\sen
\musi{1&\eaten}{0}
\musi{\eaten&\eaten}{0}
\sen
\musi{1}{0}
\end{musikui}

\end{verbatim}
\end{minipage}
&
\begin{minipage}{0.4\hsize}
\begin{musikui}
\wari{\eaten&\eaten&\eaten&\eaten}
{\eaten&\eaten}
{\eaten&\eaten}
\musi{\eaten&\eaten}{1}
\sen
\musi{1&\eaten}{0}
\musi{\eaten&\eaten}{0}
\sen
\musi{1}{0}
\end{musikui}
\end{minipage}
\\\hline
\begin{minipage}{0.7\hsize}
\begin{verbatim}

\begin{musikui}
\wari{\eaten{1}&\eaten{0}&\eaten{0}&\eaten{2}}
{\eaten{1}&\eaten{1}}
{\eaten{9}&\eaten{1}}
\musi{\eaten{9}&\eaten{9}}{1}
\bubunsen{4}{0}
\musi{1&\eaten{2}}{0}
\musi{\eaten{1}&\eaten{1}}{0}
\bubunsen{2}{0}
\musi{1}{0}
\end{musikui}

\end{verbatim}
\end{minipage}
&
\begin{minipage}{0.4\hsize}
\begin{musikui}
\wari{\eaten{1}&\eaten{0}&\eaten{0}&\eaten{2}}
{\eaten{1}&\eaten{1}}
{\eaten{9}&\eaten{1}}
\musi{\eaten{9}&\eaten{9}}{1}
\bubunsen{4}{0}
\musi{1&\eaten{2}}{0}
\musi{\eaten{1}&\eaten{1}}{0}
\bubunsen{2}{0}
\musi{1}{0}
\end{musikui}
\end{minipage}
\end{longtable}

\section{Customize}
You can change the value of arithmetical restorations using \verb|\renewcommand*|.

|\renewcommand*{|\Meta{command name}|}{|\Meta{value}|}|

The values whose roles and default values can be changed are shown in Table \ref{kiteiti}.

\begin{longtable}[h]{lll}
\caption{\label{kiteiti}}\\
Command name&Role&Default value \\ \hline
|\musiwidth|&hole width&1.2em\\
|\musiheight|&hole height&0.96em\\
|\musidepth|&hole depth&0.24em\\
|\musihgap|&distance between hole and hole&0.4em\\
|\musivgap|&distance between hole and line&0.4em\\
|\musirule|&line width&0.4pt\\
|\musiopsymbol|&multiplication sign&\verb|$\times$|\\
|\musiwarikakko|&divide symbol&\verb|\Big)|
\end{longtable}

\end{document}


% LaTeX2e Template by Stephen Iota (https://stepheniota.github.io/)
% last updated: Oct. 2018

% for papers
%\documentclass[aps,onecolumn,superscriptaddress]{revtex4-1}
% https://www-d0.fnal.gov/Run2Physics/WWW/templates/revtex4.pdf
% https://cdn.journals.aps.org/files/revtex/auguide4-1.pdf
% for revTeX4-1 class options

% for other
\documentclass[12pt]{article}
\usepackage[margin=2cm]{geometry}

%%%%%%%%%%%%%%%%
%%% Packages %%%
%%%%%%%%%%%%%%%%

\usepackage[utf8]{inputenc}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{amsfonts} % to remove math font when typesetting equations
\usepackage{graphicx}
\usepackage[shortlabels]{enumitem} % to change labels in enum/item
\usepackage[dvipsnames]{xcolor} % for colored links

% always put this at the end
\usepackage[
	colorlinks=true,
	citecolor=green!50!black,
	linkcolor=NavyBlue!75!black,
	urlcolor=green!50!black,
	hypertexnames=false]{hyperref}

 %%%%%%%%%%%%%%%%%%
 %% New Commands %%
 %%%%%%%%%%%%%%%%%%

\newcommand{\email}[1]{\texttt{\href{mailto:#1}{#1}}}

\newcommand{\hint}[1]{\color{Blue}{#1}}

%----------------------------------------------------
%%%%%%%%%%%%%%%%%%
%% Front Matter %%
%%%%%%%%%%%%%%%%%%

%\pagenumbering{gobble} % no page numbers
\graphicspath{{figures/}} % set directory for figures
\usepackage{wrapfig}
\setcounter{section}{-1} % start with section 0

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

\begin{center}

\Large{\textsc{Worksheet 4}: \textbf{Connecting $V$ and $\vec{E}$}}

\end{center}

\vspace{.5mm}

%%%%%%%%%%
%% INFO %%
%%%%%%%%%%

\begin{tabular}{rl}
\textsc{SI Leader}:
&
Stephen Iota (\email{siota001@ucr.edu})
\\
\textsc{Course}:
&
Physics 40C (Fall 2018), Dr.~Laura Sales
\\
\textsc{Date}:
&
25 October 2018
\end{tabular}

%%%%%%%%%%%%%%
%% PROBLEMS %%
%%%%%%%%%%%%%%

\section{Comments}
Slightly fewer problems this week.
The goal is to focus more on problem solving skills, trying to understand each step at a deep level when going through a solution.

\section{Kirchhoff's Loop Law}
Kirchhoff's Loop Law states the sum of all potential differences encountered while moving around a closed loop is zero.
$$ \Delta V_\mathrm{loop} = \sum_i (\Delta V)_i = 0 $$
Prove that this is just a statement of conservation of energy.\footnote{In other words, this law doesn't tell us anything we didn't know from 40A.}

\vspace{32mm}
\section{Parallel-Plate Capacitor}
Earlier in the quarter, we learned that the electric field inside a parallel-plate capacitor is:
$$ \vec{E} = \Bigg(\frac{Q}{\epsilon_0 A},+\rightarrow-\Bigg) $$
Let $ V = 0 $ at the negative plate.
Find the \textbf{electric potential} inside the capacitor.

\newpage

\section{Capacitance}

The figure below shows two electrodes charged to $\pm Q$. Although net charge is equal to zero, there is a potential difference $\Delta V$ between the electrodes. We define \textbf{capacitance} $C$ to be the proportionality constant that relates charge\footnote{Here, $Q$ refers to the magnitude of the charge on \emph{one} of the electrodes. The electrodes of a capacitor always have \emph{equal but opposite} charges.  } to potential.
$$ Q = C \Delta V_C  \ \ \ \ \ \  (\text{charge on a capacitor}) $$
% there's gotta be a better way to put text into an equation, but i'm in a pinch!

\noindent
Prove that capacitance \textbf{depends only on the geometry of the electrodes}.
\begin{center}
	\includegraphics[width=.3\linewidth]{W4_f1}
\end{center}

\end{document}


%-------------------------------------------------------
%    DOCUMENT CONFIGURATIONS
%-------------------------------------------------------

%-------------------------------------------------------
%    START OF CRYPTOGRAPHY ANALYSE
%-------------------------------------------------------
\subsection{Cryptography}
\paragraph{Privacy} Being an integral part of Overclouds, research has been made to find the best type of client-side cryptography (right from the browser as the highest priority). We were looking for a fair middle ground between performance and security.

\subsubsection{From Scratch VS Libraries}
\paragraph{1st Question} Is it possible and does it exists right from the browser?

We started looking at what is done in JavaScript and we found an interesting list of \textit{premium} libraries (maintained by prestigious organizations) such as Stanford Javascript Crypto Library\cite{Stark2009SymmetricJavascript}, MDN\cite{MDN2015MDNCrypto}, W3C\cite{Sleevi2014WebAPI}, Google Closure\cite{Google2015ClosureLibrary}, or msrCrypto\cite{Microsoft2015MSRLibrary}.

Then we looked at other crypto libraries such as forge\cite{DigitalBazaar2016Forge} (a native implementation of TLS in Javascript and tools designed for crypto-based and network-heavy web apps), jsHashes\cite{Johnston2015JsHashes}, crypto-browserify\cite{Tarr2013Crypto-Browserify}, etc...

\paragraph{2nd Question} The natural question that followed was: is it worth make it ourselves?

The answer came pretty quick while navigating across numerous forums. It is a pretty bad idea if we do not have a team dedicated to it and a pretty strong community to test it out. Even large enterprises such as Microsoft or Google are struggling a bit on the last part.

However, for the fun of it, we looked at solutions to start a homemade cryptography library. We found two interesting potential starting points to make it work with the browser, a Symmetric Encryption sample \cite{InfoTech2014SymmetricSample}, or a procedure for Digital Signatures\cite{InfoTech2014DigitalBrowser}.

\paragraph{Decision} Shortly after the second question, it was pretty clear that it will not be possible to create our cryptography library in the time given. So we decided to find the \textit{best} library out there for our project.

\subsubsection{Comparison of some JavaScript Cryptography Libraries}
\begin{table}[htpb]
\centering
\caption{Key Derivation (pbkdf2) based on figures ~\ref{fig:pbkdf2-sha1}, ~\ref{fig:pbkdf2-ops-sha1}, ~\ref{fig:pbkdf2-sha256}, ~\ref{fig:pbkdf2-ops-sha256}}
\label{tab:key-derivation-pbkdf2}
\begin{adjustbox}{center, width=\columnwidth-20pt}
\begin{tabular}{|l|l|l|l|l|}
\hline
Libraries & Sha1 (time) & Sha1 (size) & Sha256 (time) & Sha256 (size)    \\ \hline
sjcl                & \textbf{Amazing}    & \textbf{Amazing}    & \textbf{Amazing}     & \textbf{Amazing}        \\ \hline
crypto-js            & Awful    & Awful    & Awful    & Awful        \\ \hline
forge                & \textbf{Amazing}    & Nice        & \textbf{Amazing}    & Okay                \\ \hline
crypto-browserify    & \textbf{Amazing}    & Nice        & Good        & Ugly            \\ \hline
\end{tabular}
\end{adjustbox}
\end{table}

Based on the table ~\ref{tab:key-derivation-pbkdf2} below and the following referenced tables we can notice that \textbf{sjcl}\cite{Stark2009SymmetricJavascript}, \textbf{crypto browserify}\cite{Tarr2013Crypto-Browserify}, and \textbf{forge}\cite{DigitalBazaar2016Forge} algorithms have been optimized for defined objectives.

Also see Tables ~\ref{tab:hashing-0-10mb-files} and ~\ref{tab:hashing-small-files}
and their related Figures ~\ref{fig:hash-sha1}, ~\ref{fig:hash-ops-sha1}, ~\ref{fig:hash-sha256}, ~\ref{fig:hash-ops-sha256}, ~\ref{fig:small-hash-sha1}, ~\ref{fig:small-hash-sha256}

Read the table as going from Amazing to Awful.

\subsubsection{A killer}

After taking time doing research about the above algorithms, we came across a pretty amazing algorithm based on Sha3: \textbf{BLAKE2}\cite{Guo2014AnalysisBLAKE2,SaarinenM-J.2015TheMAC}.

BLAKE2 outperforms MD5, SHA-1, SHA-2, and SHA-3 on recent Intel CPUs and it has \textbf{no known} security issues. Plus SHA-1, MD5, and SHA-512 are susceptible to length-extension.

It is a \textit{new} algorithm designed specifically for \textbf{performance} and is multifaceted \textbf{BLAKE2s} (optimized for 8to32-bit) and \textbf{BLAKE2b} (optimized for 64-bit)

\subsubsection{Now what}
\begin{figure}[htpb]
\centering
\caption{\small \sl y-axis size/time, higher is better
\label{fig:hash-ops-best}}
\includegraphics[scale=0.6]{annexes/graphs/hash-ops-best.png}
\end{figure}

\begin{figure}[htpb]
\centering
\caption{\small \sl lower is better
\label{fig:blake2-sandy}}
\includegraphics[scale=0.3]{annexes/graphs/blake2-sandy.png}
\end{figure}

If we look at the figure ~\ref{fig:hash-ops-best}, BLAKE2 is dominating the two best above. \textbf{rusha} is close behind it, and forge's \textit{sha256}. Plus we can note that the curves display a nearly completely linear performance.

Also on at the table ~\ref{tab:fastest-hashes} with the figure ~\ref{fig:blake2-sandy}, we notice that BLAKE2 is in its own category.

\subsubsection{What about OverClouds}

\begin{table}[htpb]
\centering
\caption{Fastest Hashes /milliseconds based on figures ~\ref{fig:hash-ops-best}, ~\ref{fig:blake2-sandy}}
\label{tab:fastest-hashes}
\begin{adjustbox}{center, width=\columnwidth-20pt}
\begin{tabular}{|l|l|l|l|l|}
\hline
Libraries & Sha1 (size) & Sha256 (size) & Sha3 (size) \\ \hline
rusha    & \textbf{Amazing}    & Neutral    & Neutral        \\ \hline
forge    & Neutral    & \textbf{Amazing}    & Neutral        \\ \hline
blake2s    & Neutral    & Neutral    & \textbf{Amazing}    \\ \hline
\end{tabular}
\end{adjustbox}
\end{table}
We can note that we are not really interested in SHA1, because of potential security flaws. SHA256 is much better for us. However, BLACK2 is pretty amazing. We will try to make it work in the following implementation.

Now, if it does not work for whatever reason, we will certainly go with forge, crypto-browserify, or sjcl. The problem with forge and crypto-browserify is that we must trust a company or an individual. With sjcl however, we are confident into a scholar institution.

\subsubsection{Special Mention} We researched also PGP\cite{PGP2005PGPDirectory} and GPG\cite{Koch2008UsingGuard} technology. We conclude that it is still a good encryption protocol, but too heavy for Overclouds.

%-------------------------------------------------------
%    END OF COMMUNICATION ANALYSE
%-------------------------------------------------------


\chapter{Related Work}\label{chapter:related}

\toolname combines ideas from four main lines of research areas.
%
It is a
refinement type checker (\S~\ref{related:refinementtypes})
that enjoys SMT-based (\S~\ref{related:smtbased}) automated type checking.
Via Refinement Reflection we touch the expressiveness
of fully dependently typed systems (\S~\ref{related:dependenttypes}),
getting an automated and expressive verifier for Haskell programs (\S~\ref{related:haskell}).
%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%% Classic refinement types %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Refinement Types}\label{related:refinementtypes}

\mypara{Standard Refinement Types}
Refinement Types were introduced by Freeman and
Pfenning~\cite{FreemanPfenning91}, with refinements limited to
restrictions on the structure of algebraic datatypes.
%
Freeman and Pfenning carefully designed the refinement logic
to ensure \textit{decidable type inference}
via the notion of predicate subtyping (PVS~\cite{Rushby98}).
%
The goal of refinement types is
to refine the type system of an existing, general purpose,
target language so that it
\textit{rejects more programs} as ill typed,
unlike dependent type systems,
that aim to increase the expressiveness
and alter the semantics of the language.

\mypara{Applications of Refinement Types}
Xi and Pfenning implemented DML~\cite{pfenningxi98}
a refinement type checker for ML
where arrays are indexed by terms
from Presburger arithmetic to statically eliminate array bound checking.
%
Since then, refinement types have been implemented for various general purpose languages,
including
ML~\cite{GordonTOPLAS2011,LiquidPLDI08},
C~\cite{deputy,LiquidPOPL10},
Racket~\cite{RefinedRacket}
and Scala~\cite{refinedscala}
to prove various correctness properties ranging from safe memory accessing
to correctness of security protocols.
%
All the above systems operate under CBV semantics
that implicitly assume that all free variables are bound to values.
%
This assumption, that breaks under Haskell's lazy semantics,
turned out to be crucial for the soundness
of refinement type checking.
To restore soundness in \toolname we
use a refinement type based termination checker
to distinguish between provably terminating and potential diverging free variables.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%% Extensions of refinement types %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\mypara{Reconciliation between Expressiveness and Decidability}
Reluctant to give up decidable type checking,
many systems have pushed the expressiveness of refinement types
within decidable logics.
%
Kawaguchi \etal~\cite{LiquidPLDI09}
introduce \emph{recursive} and \emph{polymorphic} refinements for data
structure properties increasing the expressiveness but also the complexity
of the underlying refinement system.
%
\catalyst~\citep{catalyst} permits a form of
higher order specifications where refinements
are relations which may themselves be parameterized
by other relations.
%
However, to ensure decidable checking, \catalyst
is limited to relations that can be specified as
catamorphisms over inductive types, precluding
for example, theories like arithmetic.
%
In the same direction, Abstract and Bounded refinement types
encode modular, higher order specifications
using the decidable theory of uninterpreted functions.
%
All the above systems
only allow for ``shallow'' specifications,
where the underlying solver can only reason about
(decidable) abstractions of user defined functions
and not the exact description of the function  implementations of the functions.
%
Refinement Reflection, on the other hand,
reflects user defined function definitions
into the logic, allowing for ``deep'' program specifications
but requiring the user to manually provide cumbersome proof terms.

\section{SMT-Based Verification}\label{related:smtbased}

Even though refinement type systems use SMT solvers to
achieve decidable program verification by highly constraining the
expressiveness of specifications,
%
SMT-based verification has been extensively used for program verification
without the decidability constraint.
%
In such verifiers the SMT solvers are used to decide validity of
arbitrary (\ie non strictly decidable) logics leading to expressive specifications
but undecidable and unpredictable verification.
Unpredictable verification, as described in~\cite{Leino16}, suffers from
\textit{the butterfly effect} as ``a minor modification in one
part of the program source causes changes in the outcome of the verification in other,
unchanged and unrelated parts of the program''.
%
Here we present three SMT-based verifiers that have highly influenced
the design decisions in \toolname
and discuss the ways each one of them uses to control the unpredictability of verification.

\mypara{Sage}~\cite{Knowles10} is a hybrid type checker.
The specifications are expressed in the form of refinement types
that allow predicates to
be arbitrary terms of the language being typechecked.
It uses the SMT solver Simplify~\cite{simplifyj} to statically discharge
as many proof obligations as possible and defers the rest to runtime casts.
%
\toolname is a subset of Sage that provably requires no runtime casts
since predicates are carefully constrained to decidable logics.
%
We used Knowles and Flanagan's formalism on denotational typing
and correctness of Sage to formalize soundness and semantics of \toolname.

\mypara{\fstar}~\cite{fstar} is a refinement type checker
that allows predicates to be arbitrary terms
and aims to discharge all proof obligations via the SMT solver,
leading to unpredictable verification.
%
\fstar allows the user to control the SMT decision procedures
by exposing to the user SMT tactics that can be used to direct
verification in case of failure.
%
Moreover, \fstar allows effectful computations
(\eg state, exceptions, divergence and IO)
and combines refinement types with a sophisticated effect type system
to reason about totality of programs.
%
In (Liquid) Haskell all programs are pure, thus reasoning about effectful
computations has already been taken care of by Haskell's basic (\ie unrefined)
type system that requires effectful computations to be wrapped inside monads.
%
The only effects allowed in Haskell are exceptions and divergence
that can be optionally tracked by \toolname's totality and termination checker respectively.

\mypara{Dafny}~\cite{dafny} is a prototype SMT-based verifier
for imperative programs that allows arbitrarily expressive specifications
in the form of pre- and post-conditions.
%
Acknowledging the disadvantages of unpredictable verification,
Dafny aims to give to the user control over the underlying SMT
decision procedures
via sophisticated trigger and fuel techniques.
%
Dafny
that verifies effectful, imperative code via pre- and post-conditions
is quite different from \toolname
that verifies the pure and functional Haskell via refinement types.
%
Yet, the work of Leino and the rest of Dafny developers
has been a great inspiration for existing and future work
on challenges shared by both verifiers,
including termination checking,
coinduction~\cite{LeinoM14},
local calculations~\cite{LeinoPolikarpova16},
and error reporting~\cite{GouesLM11}.

\section{Dependent Type Systems}\label{related:dependenttypes}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%% Fully dependent typing %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Dependent Types Systems like Coq~\cite{coq-book},
Agda~\cite{agda}, Idris~\cite{Brady13} and Isabelle/HOL~\cite{isabelle}
express sophisticated theorems as types since they
allow arbitrary terms to appear in the types.
%
Constructive proofs of such theorems are just programs
that are either manually written by the users or automatically generated via
proof tactics and heuristics.
However programs are not just proofs,
thus, unlike \toolname, these verification oriented, dependent type systems
fail to provide an environment for mainstream code development.

\mypara{Expressiveness: Deep vs. Shallow Specifications}
Dependently typed languages permit
\textit{deep} specification and verification.
%
To express and prove theorems, these systems
represent and manipulate the exact
descriptions of user-defined functions.
%
For example, we can represent
the specification that the list @append@ function is associative and
we can manipulate (unfold) its definition
to write a small program that by reduction
constructs a proof of the specification.
%
On the other hand,
standard refinement types, including \toolname without refinement reflection,
restrict refinements to so-called  \textit{shallow}
specifications that correspond to abstract interpretations of
the behavior of functions within decidable logical domains.
%
For example, refinements make it easy
to specify that the list returned by the @append@ function has size
equal to the sum of those of its inputs
but in the logic the exact definition of @append@ is not known.
%
Refinement Reflection reflects user defined functions into the logic
allowing deep specifications.
Verification still occurs using the abstract interpretations of the functions,
but with refinement reflection, the abstraction of the function is
exactly equal to its definition.

\mypara{Proof Strategy: Type Level Computations vs. Abstract Interpretation}
Dependent type systems use type level computations to construct proofs by evaluation.
%
On the other hand, in refinement type systems,
safety proofs rely on validity of subtyping constraints
that is checked externally by an SMT solver.
%
That is, the type system is unable to perform any proof by evaluation,
as the only information it has for each function is the abstraction that is
described by its type.
%
With refinement reflection, we fake type level computations:
the Haskell, value level, proof terms provide all the required reduction steps
that are then retrofitted as equality assertions to the SMT solver.

\mypara{Automation: Tactics vs. SMT solvers}
Dependent type checking requires explicit proof terms to be provided by the users.
%
To help automate proof term generation, both built-in and user-provided
tactics and heuristics are used to attempt to discharge proof obligations; however,
the user is ultimately responsible for manually proving any
obligations which the tactics are unable to discharge.
%
On the other hand, refinement type checking
does not require explicit proof terms.
%
Verification proceeds by checking validity of subtyping constraints
which reduces to implication checking that is in turn
decided using the power of SMT solvers.
%
Many times the SMT solver fails to prove
validity of a subtyping constraint because the environment is too weak.
%
In such cases the user can strengthen the environment by instantiating
axioms via function calls.
%
For example, the proof that @() :: {v:() | fib 1 = 1}@
is valid under an environment that invokes @fib@ on @1@.
%
That is, to prove deep specifications we fake type level computations
via value level proof terms, but ultimately,
we check validity using the power of SMTs
which drastically simplifies proofs over key theories
like linear arithmetic and equality.
%
In the future, we plan to investigate how to simplify such proof terms
by adapting the tactics and heuristics of dependently typed systems
into \toolname.

\mypara{System Features: Theorem Prover vs. Legacy Programming Languages}
Dependent type systems are proof oriented systems, lacking
features required for a general purpose language, like
diverging and effectful programs.
%
Various systems extend theorem provers to support effectful programs,
for example
Zombie~\cite{Zombie,Sjoberg2015} and \fstar~\cite{fstar} allow dependent types to
coexist with divergent and effectful programs.
%
Still, these systems are verification oriented and lack the
optimized libraries that come from the mainstream developers of
a general purpose programming language.
%
On the other hand, \toolname
retrofits verification in Haskell,
a legacy programming language with
a long-standing developer community.
%
With \toolname,
Haskell programmers can as use their favorite
language for general purpose programming,
and also prove specifications without the need to use an external,
verification specific, theorem prover.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%% alternative verification in Haskell %%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Haskell Verifiers}\label{related:haskell}

\toolname belongs into the ongoing research of Haskell code verification
that is exploring techniques to verify properties about Haskell programs
that the current type system cannot specify.
%
There are two main directions in this line of research.
%
Some groups are building external verifiers that analyze
well typed Haskell programs, while others are enriching
the expressiveness of the Haskell's type system.

\mypara{Domain Specific Haskell Verifiers}
Various external Haskell analyzers have been proposed
to check correctness properties of Haskell code that
is not expressible by Haskell's type system.
%
Catch~\cite{catch} is
a fully automated tool that tracks incomplete patterns,
like our totality analyzer.
AProVE~\cite{Giesl11} implements a powerful, fully-automatic
termination analysis for Haskell based on term-rewriting,
like our termination analyzer.
HERMIT~\citep{Farmer15} proves equalities by rewriting
the GHC core language, guided by user specified scripts,
like our equality reasoning performed via Refinement Reflection.
%
All the above verifiers allow for a domain specific analysis,
precluding \toolname's generalized functional
correctness specifications, encoded via refinement typing.
%

\mypara{Static Contract Checking}
A generalized correctness analysis in Haskell is feasible
via Haskell's static contract checking~\cite{XuPOPL09}
that encodes arbitrary contracts in the form of refinement types and
checks them using symbolic execution to unroll procedures
upto some fixed depth.
%
Similarly, Zeno~\cite{ZENO} is an automatic Haskell
prover that combines unrolling with heuristics for rewriting
and proof-search.
%
Finally, the Halo~\cite{halo} contract checker encodes
Haskell programs into first-order logic by directly
modeling the code's denotational semantics,
again, requiring heuristics for instantiating axioms
describing functions' behavior.
%
All the above general purpose verifiers
allow specification of arbitrarily expressive contracts
rendering verification undecidable and thus impractical.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%% dependent types in Haskell %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\mypara{Dependent Types in Haskell}
Haskell itself is a dependently-typed language~\cite{Eisenberg16},
as type level computation is allowed via
Type Families~\cite{McBride02},
Singleton Types\cite{Weirich12},
Generalized Algebraic  Datatypes (GADTs)~\cite{JonesVWW06, SchrijversJSV09},
type-level functions~\cite{ChakravartyKJ05},
and explicit type applications~\cite{EisenbergWA16}.
%
In this line of work~\citep{EisenbergS14}
Eisenberg \etal aim to allow fully dependent
programming within Haskell, by making
``type-level programming ... at least as
  expressive as term-level programming''.
%
Our approach differs in two significant ways.
%
First, while enriching expressiveness of the types
allows Haskell's type system to accept more programs,
we aim not to alter semantics of Haskell programs,
but by refining the checks performed by the type system
to reject more programs as ill typed.
%
As a consequence, refinements are completely erased at run-time.
%
As an advantage (resp. disadvantage), refinements
cannot degrade (resp. optimize)
the performance of programs.
%
Second, dependent Haskell follows the classic dependent type
verification by type level evaluation approach
that turns out to be quite painful~\cite{LindleyM13}.
On the other hand, \toolname
enjoys SMT-aided verification,
which drastically simplifies proofs over key theories
like linear arithmetic and equality.
%
Despite these differences, these two approaches target
the same problem of lifting value level terms into Haskell's type system.
%
In the future, we hope to unify these two techniques and
allow a uniform interface for lifting values inside the type specifications
to create a dependent Haskell
that enjoys
both SMT-based automation of verification and
type driven runtime optimizations.

\begin{comment}

Much of this simplicity can be recovered in
Haskell using the @singleton@ library~\citep{Weirich12}.
%
Our goal is to show that bounded refinements
are expressive enough to permit the construction
of rich abstractions like a relational algebra
and generic combinators for safe database access
while using SMT solvers to provide decidable
checking and inference. Further, unlike the
HList based approaches, refinements they can
be used to \emph{retroactively} or \emph{gradually}
verify safety; if we erase the types we still
get a valid Haskell program operating over
homogeneous lists.
We do not extende Haskell's expressivity

\spara{Tracking Divergent Computations}
The notion of type stratification to track potentially
diverging computations dates to at least~\citep{ConstableS87}
which uses $\bar{\typ}$ to encode diverging terms, and types
$\efix{}$ as $(\bar{\typ}\rightarrow\bar{\typ}) \rightarrow \bar{\typ}$).
%
More recently, \cite{Capretta05} tracks diverging
computations within a \emph{partiality monad}.
%
Unlike the above, we use refinements to
obtain terminating fixpoints (\etfix{}), which let us prove
the vast majority (of sub-expressions) in real world libraries
as non-diverging, avoiding the restructuring that would
be required by the partiality monad.

\spara{Termination Analyses}
Various authors have proposed techniques to verify termination
of recursive functions, either using the ``size-change principle''
\cite{JonesB04,Sereni05}, or by annotating types with size indices
and verifying that the arguments of recursive calls have smaller
indices~\cite{HughesParetoSabry96,BartheTermination}.
%
Our use of refinements to encode terminating fixpoints is most
closely related to~\cite{XiTerminationLICS01}, but this work
also crucially assumes CBV semantics for soundness.

AProVE~\cite{Giesl11} implements a powerful, fully-automatic
termination analysis for Haskell based on term-rewriting.
%
While we could use an external analysis like AProVE,
we have found that encoding the termination proof via
refinements provided advantages that are crucial in
large, real-world code bases. Specifically, refinements
let us
%
(1) prove termination over a subset
    (not all) of inputs; many functions (\eg @fac@)
    terminate only on @Nat@ inputs and not all @Int@s,
%
(2) encode pre-conditions,
    post-conditions, and auxiliary invariants that
    are essential for proving termination, (\eg @gcd@),
%
(3) easily specify non-standard
    decreasing metrics and prove termination, (\eg @range@).
%
In each case, the code could be (significantly)
\emph{rewritten} to be amenable to AProVE but this defeats
the purpose of an automatic checker.
%
Finally, none of the above analyses have been empirically
evaluated on large and complex real-world libraries.

\spara{Static Contract Checkers}
like ESCJava~\cite{ESCJava} are a classical way of verifying
correctness through assertions and pre- and post-conditions.
%
Side-effects like modifications of global variables are a
well known issue for static checkers for imperative languages;
the standard approach is to use an effect analysis to determine
the ``modifies clause'' \ie the set of globals modified by a procedure.
%
Similarly, one can view our approach as implicitly computing
the non-termination effects.
%
%
\cite{XuPOPL09} describes a static contract checker for
Haskell that uses symbolic execution to unroll procedures
upto some fixed depth, yielding weaker ``bounded'' soundness
guarantees.
%

%
Similarly, Zeno~\cite{ZENO} is an automatic Haskell
prover that combines unrolling with heuristics for rewriting
and proof-search.
Based on rewriting, it is sound but
``Zeno might loop forever'' when faced with
non-termination.
%
Finally, the Halo~\cite{halo} contract checker encodes
Haskell programs into first-order logic by directly
modeling the code's denotational semantics,
again, requiring heuristics for instantiating axioms
describing functions' behavior. Halo's translation of Haskell
programs directly encodes constructors as uninterpreted functions,
axiomatized to be injective (as the denotational semantics requires).
This heavyweight encoding is more precise than predicate abstraction
but leads to model-theoretic problems (outlined in the Halo paper) and
affects the efficiency of the encoding when scaling to larger programs
(see also \ref{sec:refinedhaskell:conclusion}, paragraph B) in the lack of specialized
decisions procedures.
%
Unlike any of the above, our type-based approach does
not rely on heuristics for unrolling recursive procedures,
or instantiating axioms.
%
Instead we are based on decidable SMT validity
checking and abstract interpretation~\cite{LiquidPLDI08}
which makes the tool predictable and the overall workflow
scale to the verification of large, real-world
code bases.

\paragraph{Parallel Code Verification}
Dependent type theorem provers have been used before to
verify parallel code.
%
BSP-Why~\cite{bspwhy} is an extension to Why2 that is using both Coq and SMTs
to discharge user specified verification conditions.
%
Daum~\cite{daum07} used Isabelle to formalize the semantics
of a type-safe subset of C,
by extending Schirmer's~\cite{schirmer06}
formalization of sequential imperative languages.
%
Finally, Swierstra~\cite{wouter10} formalized mutable arrays in Agda
and used them to reason about distributed maps and sums.

\mypara{Deterministic Parallelism}
%
Deterministic parallelism has plenty of theory but relatively few practical
implementations.  Early discoveries were based on limited producer-consumer
communication, such as single-assignment variables \cite{Tesler-1968,IStructures}, Kahn
process networks~\cite{kahn-1974}, and synchronous dataflow~\cite{lee-sdf}.
Other models use synchronous updates to shared state, as in
Esterel~\cite{synchronous-overview} or PRAM.  Finally, work on type systems for
permissions management \cite{permission-types,habanero-java-permissions},
supports the development of {\em non-interfering} parallel programs that access
disjoint subsets of the heap in parallel.  Parallel functional programming is
also non-interfering~\cite{manticore,multicore-ghc}.
%
Irrespective of which theory is used to support deterministic parallel
programming, practical implementations such as Cilk~\cite{cilk} or Intel
CnC~\cite{cnc} are limited by host languages with type systems insufficient to
limit side effects, much less prove associativity.  Conversely, dependently
typed languages like Agda and Idris do not have parallel programming APIs and
runtime systems.

% synchronous languages such as Esterel
\mypara{Our Approach for Verifying Stateful Computations} using monads
indexed by pre- and post-conditions is inspired by the method of
Filli\^atre~\citep{Filliatre98}, which was later enriched with
separation logic in Ynot~\citep{ynot}. In future work it would
be interesting to use separation logic based refinements to specify
and verify the complex sharing and aliasing patterns allowed by Ynot.
%
\fstar encodes stateful computations in a special Dijkstra
Monad~\citep{dijkstramonad} that replaces the two assertions with
a single (weakest-precondition) predicate transformer which
can be composed across sub-computations to yield a transformer
for the entire computation.
%
Our \RIO approach uses the idea of indexed monads but
has two concrete advantages.
%
First, we show how bounded refinements alone suffice to
let us fashion the \RIO abstraction from scratch.
%
Consequently, second, we automate inference of pre- and
post-conditions and loop invariants as refinement instantiation
via Liquid Typing~\citep{LiquidPLDI08}.

Systems~\citep{sousa16} and \citep{KobayashiRelational15}
extend classical safety verification algorithms,
respectively based on Floyd-Hoare logic and Refinement Types,
to the setting of relational or $k$-safety properties
that are assertions over $k$-traces of a program.
%
Thus, these methods can automatically prove that
certain functions are associative, commutative \etc.
but are restricted to first-order properties and
are not programmer-extensible.
%
Zeno~\citep{ZENO} generates proofs by term
rewriting and Halo~\citep{halo} uses an axiomatic
encoding to verify contracts.
%
Both the above are automatic, but unpredictable and not
programmer-extensible, hence, have been limited to
far simpler properties than the ones checked here.

\paragraph{Parallel Code Verification}

One work  closely related to ours is
SyDPaCC~\cite{SyDPaCC}, a Coq library that
automatically parallelizes list homomorphisms
by extracting parallel Ocaml versions of user provided Coq functions.
%
Unlike SyDPaCC, we are not automatically generating the parallel
function version, because of engineering limitations
(\S~\ref{sec:evaluation}).  Once these are addressed, code extraction
can be naturally implemented by turning
Theorem~\ref{theorem:two-level} into a Haskell type class with a
default parallelization method.
%
SyDPaCC used maximum prefix sum as a case study,
whose morphism verification is
much simpler than our string matching case study.
%
Finally, our implementation consists of
2K lines of Liquid Haskell, which we consider verbose and aim to
use tactics to simplify.
On the contrary, the SyDPaCC implementation
requires three different languages:
2K lines of Coq with tactics, 600 lines of Ocaml and 120 lines of C,
and is considered ``very concise''.

\mypara{Dependent Types for Non-Terminating Programs}
%
Zombie~\citep{Zombie, Sjoberg2015} integrates
dependent types in non terminating programs
and supports automatic reasoning for equality.
%
Vazou \etal have previously~\citep{Vazou14} shown
how Liquid Types can be used to check
non-terminating programs.
%
Reflection makes \toolname at least as
expressive as Zombie, \emph{without}
having to axiomatize the theory of
equality within the type system.
%
Consequently, in contrast to Zombie,
SMT based reflection lets \toolname
verify higher-order specifications
like @foldr_fusion@.

\end{comment}


\chapter{Designing User-Centric ML Systems}
\label{chapter2}

\graphicspath{{Chapter2/figs/}}

This chapter focuses on describing some advances in the context of Interactive ML and Interpretable ML. In first instance, both sub-fields are tackled independently but, in Section \ref{section2.3}, a discussion is stated in terms of how they can be combined for designing better and more user-centric ML systems. Finally, some related proposals in the context of DR and Clustering are presented in Section \ref{section2.4}.

\section{Interactive ML}
\label{section2.1}

The Human-Computer Interaction (HCI) field cares about human perception, cognition, intelligence, decision-making and interactive techniques of visualization. By the other hand, in Knowledge Discovery in Databases (KDD) automatic computational methods for finding previously unknown relationships in data are developed \cite{Holzinger2013}. By merging these fields, many research opportunities emerge including the paradigm where algorithms can interact with humans and optimize their learning behavior through these interactions \cite{Holzinger2016}.

As described in \cite{Fails2003}, classic ML generally has some assumptions which can be addressed through the use of Interactive ML, such as:

\begin{itemize}
\item The introduction of many attributes in the model can become noise and therefore affect its performance. An Interactive ML system should provide to user the ability to perform attribute selection through a friendly interface.
\item When there is not enough training data, user also should be able to perform labeling under consideration or by a systematic way.
\item The system must quickly adapt after any user interaction affecting the data or model behavior. A delayed adaptation implies losing the user's attention.
\end{itemize}

More formally, Interactive ML is a co-adaptive process, driven by the user, but inherently dynamic in nature as the model and user evolve together during training \cite{Dudley2018}. These kind of systems should include interaction elements: \textbf{sample review}, \textbf{feedback assignment}, \textbf{model inspection} and \textbf{task overview}. By the other hand, an interface for Interactive ML should meet the following requirements: train very quickly, accommodate hundreds to thousands of features, perform feature selection and support tens to hundreds of thousands of training examples \cite{Fails2003}. A synthesis of a Interactive ML system is shown in Figure \ref{fig:InteractiveML} describing the direction of the interaction for each element.

\begin{figure}[ht]
 \centering
 \includegraphics[width=0.7\textwidth]{InteractiveML.png}
 \caption{Block diagram representing an Interactive ML system.}
 \label{fig:InteractiveML}
\end{figure}

Known strategies for implementing the first two elements are briefly described in Subsections \ref{subsection2.1.1} and \ref{subsection2.1.2}. Although the \textbf{model inspection} element apparently does not have the same level of development, some relevant works are presented in Subsection \ref{subsection2.1.3}. For \textbf{task overview}, no one relevant work was found in the context of Interactive ML because this interface element is closely related to the specific knowledge domain. Model accuracy and related metrics are not enough to evaluate the task fulfillment, so this interface element should provide visibility of global objectives but also contextualize about other information such as availability of training data \cite{Dudley2018}.

Next subsections describe some related concepts to tackle the Interactive ML design process including some implementation scenarios.

\subsection{Dimensionality Reduction (DR)}
\label{subsection2.1.1}

In general terms, DR deals with the problem of finding meaningful low-dimensional structures (compact representation) from high-dimensional data \cite{Tenenbaum2000},\cite{Roweis2000}. For \textbf{sample review}, this is a valuable technique for representing high-dimensional data in principally two dimensions to validate the data distribution. Some algorithms for DR are Principal Component Analysis (PCA) \cite{PCA}, Self-Organized Maps (SOM) \cite{Kohonen1982Self-organizedMaps}, Isometric Mapping (ISOMAP) \cite{Tenenbaum2000}, t-Stochastic Neighborhood Embedding (t-SNE) \cite{VanDerMaaten2008}, and Uniform Manifold Approximation and Projection (UMAP) \cite{McInnes2018}. In general terms, many of the algorithms require a distance function (e.g. Euclidean distance) as method for calculating the similarity between pairs of instances \cite{Wenskovitch2018}, have their own training mechanism, may be sensible to random initialization at different levels and the selection of the hyper-parameters could satisfy diverse user intentions according to the domain of the problem.

PCA is a linear transformation algorithm that produce new uncorrelated dimensions (principal components) looking to maximize the variability represented in the dataset. SOM comes from the family of neural networks and use competitive learning to build a discrete representation of the data. ISOMAP is one of the first algorithms based on manifold learning and produces a low-dimensional embedding maintaining the geodesic distance between all instances causing preservation of global structures. Unlike ISOMAP, t-SNE retains particularly local structure but also some of global structure of the data. In many scenarios, t-SNE enables more the visual identification of clusters in comparison with ISOMAP but have the disadvantage of being expensive in  memory and processing and producing different embeddings with random initializations. UMAP is the newest technique and can compete with t-SNE for visualization but with superior run time performance.

DR can be used to achieve cluster-oriented task sequences such as verify clusters, name clusters and match cluster and classes \cite{Brehmer2014VisualizingSequences}. In this sense, DR and Clustering algorithms have been successfully combined for assist analysts in performing this kind of user tasks \cite{Wenskovitch2018}. Nevertheless, many challenges and opportunities need to be addressed. In addition, it is important to note that DR and Clustering algorithms are not only relevant for providing \textbf{sample review} as stated in \cite{Wenskovitch2017}, where a \textbf{feedback assignment} mechanism based on observation-level interaction is enabled for improving the cluster computation in an iterative way.

\subsection{Active Learning and Visual Interactive Labeling}
\label{subsection2.1.2}

One way for achieving \textbf{feedback assignment} is by providing users the ability of labeling data. Active Learning (AL) consists of a series of analytical methods to select unlabeled data and present it to users in the form of queries for label assignment \cite{Holzinger2016}. Independently of the querying method used, the success of incorporating AL into an Interactive ML system lies on keeping the user labeling effort to a minimum. This can be achieved by only asking for feedback when the hope for a performance improvement given a specific query is high \cite{Olsson2009},\cite{Tong2001}.

Visual Interactive Labeling (VIL), in contrast to AL, delivers to user the selection of data candidates to be labeled. Nevertheless, user cognitive load can be reduced by incorporating visual techniques such as 2D colormaps, class coloring, convex hulls and butterfly plots \cite{Bernard2018b}. AL and VIL are used in scenarios where there is small amount of labeled data, and where the domain knowledge from users can be useful to improve unreliable predictions.

In \cite{Bernard2018b}, authors present a comparison among multiple VIL and AL strategies. The decision regarding to use either of the two methods depends highly on the user task complexity, the \textbf{sample review} technique and the class separability. In general terms, both techniques can compete to produce better and faster classification models.

\subsection{Parameter Tuning and Error Discovery}
\label{subsection2.1.3}

Two useful strategies for \textbf{feedback assignment} and \textbf{model inspection} to be included into an Interactive ML system are parameter tuning and error discovery.

% Parameter tuning
For the first strategy, the adjustment of model parameters does not imply necessarily, for instance, to provide the ability to modify the number of hidden layers or link weights, as in the context of neural networks. The goal is to design interaction mechanisms usable for users even when these are not experts in ML. In other words, putting model parameters in terms of the task domain, being this a non-trivial design decision. An example is shown in \cite{Kapoor2010}, where users are able to refine the parameters of the confusion matrix according to their preferences and thus re-train the model in an iterative way. For clustering, user actions affecting implicitly the model parameters include dragging points to form one or more new clusters, dragging an outlier into existing cluster, maximize one dimension weight and drag multiple sliders to equally large weights \cite{Self2016}.

% error discovery
An example of Interactive ML system for error discovery is presented in \cite{Chen2018b}. From a website classification problem, domain knowledge about the target class is introduced facilitating error discovery through semantic data exploration. While elements such as \textbf{sample review} and \textbf{model inspection} are introduced, an eventual desire of Interactive ML systems is missing: the ability to perform labeling correction and re-train the model to evaluate if performance improves.

% Learning by user knowledge
It is also important to highlight some works focused on implement systems that learn explicitly from user knowledge and not refining an specific algorithm proposed in literature. In \cite{Brown2012}, users are able to build the distance function for two dimensions data projection according to their own sense of distance. In SIRIUS \cite{Dowling2018SIRIUS:Reductions}, coordinated dragging of instances and attributes in 2D panels offer a visual intuition about similarity-based relationships between them. In addition, a tool for clustering steered by user, having significantly higher quality than those from a pure algorithmic process, in proposed in \cite{Chang2016}.

\section{Interpretable ML}
\label{section2.2}

Interpretability is defined as the ability to explain or to present in understandable terms to a human \cite{Doshi-Velez2017c}. This definition by itself leaves more questions open than it solves and the decision behind delivering ML interpretability to users must be careful studied. Figure \ref{fig:interpretableML}, presents a condensed synthesis regarding to design aspects for delivering interpretability which are highly related to context, users, data and models \cite{Hohman2018},\cite{Doshi-Velez2017c},\cite{Lipton2017}. These aspects are grouped in six questions to be asked during the design process:

\begin{itemize}
    \item Why do you need to produce interpretability? Should the system be in the ability to generate trust about predictions? Does it protect sensitive information in the data?
    \item Who is the user of the system? Is the user a ML or a domain-expert?
    \item What are the most important elements of the data or the model to visualize?
    \item How do you plan to represent those most important elements? Is it important for user to interact with those elements?
    \item When generate interpretations? Is the model under continuous refinement  or was the model previously trained and validated?
    \item Where will the system be deployed? Is the system intended to support a real-world problem in a company? Does the system contribute to produce scientific advances in a specific ML sub-field or any other knowledge domain?
\end{itemize}

\begin{figure}[ht]
 \centering
 \includegraphics[width=0.9\textwidth]{InterpretableML.png}
 \caption{Aspects to consider when designing Interpretable ML systems.}
 \label{fig:interpretableML}
\end{figure}

Delivering interpretability implies opening the black-box and sometimes it could not be necessary and appropriate to do it, principally when there are no significant consequences for unacceptable results or the problem is sufficiently well-studied and validated in real applications that user trust the system’s decision, even if this is not perfect \cite{Doshi-Velez2017c}.

An example of interpretability in the DR context is DimReader \cite{Faust2019DimReader:Projections}. Building new axes representing infinitesimal perturbations in the embedding, this technique can be used to determine the regions where instances with similar range of values for a particular attribute are concentrated and the direction of the change.

\subsection{Frameworks for Interpretability}

Some relatively basic techniques for interpret ML models are \cite{Becker2018MachineExplainability}: Permutation importance, for determining which attribute produces the highest performance decrease, and Partial dependence plots, for visualizing influence direction and shape when varying an attribute value.

A more sophisticated technique is LIME \cite{Ribeiro2016}, Local Interpretable Model-Agnostic Explanations, where a specific prediction is explained by learning an interpretable model locally. The result of LIME is a probability for each attribute value of belonging to the prediction class. In addition, the authors show the potential of the framework in applications based on tabular, image and text data. LIME is extended by SHAP \cite{Lundberg2017APredictions}, including an additional component based on the identification of a new class of additive attribute importance measures. LIME is also extended in \cite{Teso2018} and \cite{Phillips2018InterpretableLearning} to explain the query produced in an AL scenario. Local explanations are the base of works focused on produce global interpretation as proposed in \cite{Yang2018}. From contribution matrix representing the attribute importance for every data item, a binary tree is learned to explicitly represent the most important decision rules that are implicitly contained in the black-box model.

Black-box Deep Learning models have the disadvantage of being the least interpretable because their large number of parameters as measure of complexity. Contributions in this field have been achieved by producing interpretation of the features learned at each layer of a Neural Network \cite{Yosinski2015a},\cite{Olah2018}. A more extensive literature review about interpretability in Deep Learning can be found in \cite{Zhang2018}.

\section{The Link Between Both Worlds}
\label{section2.3}

Interactive ML and Interpretable ML in the most of cases previously described has been tackled as isolated concepts. In some scenarios, mechanisms for \textbf{sample review} and \textbf{feedback assignment} (e.g. labeling or parameter tuning) may not be enough to successfully fulfill the user task. \textbf{Model inspection} implies opening the black-box and presenting it to user in an interpretable way and model interpretation indicates the ability to provide explanations about their inner working which could help users to better understand their results \cite{Doshi-Velez2017c}. This extension could support the \textbf{task overview} interface element because, as stated in \cite{Doshi-Velez2017c}, \cite{Lipton2017}, model interpretation is used to achieve other important requirements in user-centric ML systems such as trust, unbiasedness, privacy, reliability, robustness, causality, transferability, informativeness and usability.

In other words, \textbf{an Interactive ML system is not necessarily interpretable in terms of what model is learning and, in the opposite case, an Interpretable ML system could not involve all enough elements of interaction to perform the task in an usable and efficient way}. Designers must not forget the system is constrained by an user task and users are the ones who have the power to determine if the task is effectively fulfilled. User evaluation for interactivity and interpretability, as in any HCI study, must be considered.

%After establishing the bases for designing user-centric ML systems, some DR and Clustering algorithms are presented from a practical perspective. This chapter is not focused in determining the best algorithm for reducing or clustering data but discussing about how these behave for some real-world datasets. The third section of this chapter concentrates in summarize some tools that use this kind of algorithms while user can interact and interpret them.

%Figure \ref{fig:dr-matrix} shows some experiments performed for 4 datasets with different level of complexities using 4 of the DR algorithms previously described: the Iris dataset, the Breast Cancer dataset, the FIFA dataset and the SALURBAL dataset. A class attribute is used for color encoding: species, diagnosis, position and sub-city type, respectively. Hyper-parameter tuning is not considered, the most important aspect to evaluate is the ability of the algorithms to build embeddings with visually identifiable clusters. For the first dataset, all algorithms seem to work similar separating one of the three classes and reflecting no linear separability of the remaining classes.

%\begin{figure}[ht]
% \centering
% \includegraphics[width=1.0\textwidth]{DRmatrix.png}
% \caption{DR embeddings for 4 datasets: the Iris dataset, the Breast Cancer dataset, the FIFA dataset and the SALURBAL dataset.}
% \label{fig:dr-matrix}
%\end{figure}

%As appreciate, PCA and ISOMAP tend to overlap the classes making difficult for user to

%\section{Clustering Data}
%\label{section2.5}

%K-Means
%Spectral
%Agglomerative
%DBSCAN

\section{EDA Tools for Interacting and Interpreting DR and Clustering}
\label{section2.4}

Many researchers have proposed to integrate ML in systems or tools for analyzing data. In \cite{Endert2017b}, a wide range of works are presented and some challenges and opportunities are presented including: (1) incorporation of user feedback, (2) balance human and machine efforts, responsibility and tasks, (3) control of system complexity, (4) visualization of intermediate results, and (5) interpretability. In the context of DR and Clustering, \cite{Wenskovitch2018} and \cite{Sacha2017g} derive from literature review the user tasks and interaction mechanisms incorporated in this kind of systems:

\begin{itemize}
\item DR: See distribution of instances, identify clusters, rotate the embedding, reposition instances, measure distances between instances, change distance metric, select different attributes, modify the weight of an attribute, obtain attribute values and select the algorithm and modify its hyper-parameters.
\item Clustering: Determine cluster structure, label / annotate clusters, merge or split clusters, reposition instances, select different attributes, modify the weight of an attribute, obtain attribute values and select the algorithm and modify its hyper-parameters.
\end{itemize}

To the best of our knowledge, a first effort of interactive tool for DR and Clustering is Divvy \cite{Lewis2013Divvy:Analysis}. In Divvy, user is able to load a dataset and evidence its shape, train some DR and Clustering models changing the hyper-parameters and visualize the results in multiple embeddings. In this standalone tool, no other interaction mechanism is considered. Embedding Projector \cite{Smilkov2016EmbeddingEmbeddings} is a web tool from the Tensorflow \cite{Abadi2016TensorFlow:Learning} ecosystem and it enables additional interactions for embeddings including zooming, rotation, panning, query for getting attribute values and nearest-neighbors. Three DR algorithms are implemented in Embedding Projector (PCA, t-SNE and a linear projection of any two custom vectors) but experimentation is limited to 5 pre-loaded datasets. A-tSNE \cite{Pezzotti2016ApproximatedAnalytics} is a complementary tool mainly focused on fast execution of the t-SNE algorithm for progressive analytics. In a first stage, the tool builds an approximated embedding to subsequently refine the approximation in areas of interest for the user. Figure \ref{fig:interactiveDR} shows screenshoots of the works previously mentioned. Other improvement of t-SNE is proposed in \cite{Pezzotti2018LinearWeb}. In this case, Tensorflow.js \cite{Smilkov2019TensorFlow.js:Beyond} is extended with this DR algorithm for execution in the browser taking advantage of the tensor data structures and WebGL textures for fast execution.

\begin{figure}[ht]
 \centering
 \includegraphics[width=0.9\textwidth]{InteractiveDR.png}
 \caption{Divvy \cite{Lewis2013Divvy:Analysis} (top left), Embedding Projector \cite{Smilkov2016EmbeddingEmbeddings} (top right) and A-tSNE \cite{Pezzotti2016ApproximatedAnalytics} (bottom) for interactive DR and Clustering.}
 \label{fig:interactiveDR}
\end{figure}

These proposals inspire the development of the tool explained in Chapter \ref{chapter3}. The main improvement with respect to these tools is the ability for domain-expert users to train DR and Clustering models for supporting clustering-oriented EDA tasks without losing the overall context of the data in the same interactive tool. This context of the data is also used as an initial mechanism for providing interpretability for the available models.


\documentclass{article}
\usepackage{amsmath}
\usepackage{amssymb} % for "\mathbb" macro
\usepackage[round]{natbib}
\usepackage{url}
\usepackage{hyperref}

\title{Valuation of Commodity Storage}
\author{Jake C. Fowler}
\date{January 2020}

\begin{document}
\newcommand{\+}[1]{\ensuremath{\mathbf{#1}}}

\maketitle

WARNING: THIS DOCUMENT IS CURRENTLY WORK IN PROGRESS

\section{Introduction}
Define $v_i$ as the decision volume of commodity injected or withdrawn from storage at time
$t_i$. To clarify, positive value of $v_i$ denotes injection into storage, increasing the
inventory, where as a negative value denotes the volume withdrawn. The admissible values
of $v_i$ are restricted by the minimum and maximum inject/withdraw rate functions
$v_{min}$ and $v_{max}$.

\begin{equation}
    v_i \in [v_{min}(t_i, V_i), v_{max}(t_i, V_i)]
\end{equation}

Note that $v_{min}$ and $v_{max}$ are both functions of time and $V_i$, which represents the
inventory in storage at time $t_i$. Inventory-varying injection and withdrawal rates are commonly
seen in natural gas storage, where higher storage cavern pressue results from higher inventory,
which results in a higher maximum withdrawal rate, and lower maximum withdrawal rate.

\bigskip

The inventory $V_i$ can be defined recursively as:

\begin{equation}
    V_i = V_{i-1} + v_{i-1} - L(t_{i-1}, V_{i-1})
\end{equation}

Where $L(t_{i-1}, V_{i-1})$ is the inventory loss, as a function of time and inventory,
evaluated for the previous time period. An alternative representation of inventory is
as a summation:

\begin{equation}
    V_i = V_{start} + \sum\limits^{i-1}_{j=0} {(v_{j} - L(t_j, V_j))}
\end{equation}

$V_{start}$ is the inventory at the inception. This is necessary in the case where storage
capacity is purchased or leased with some amount of commodity inventory in place.

\bigskip

$V_i$ is itself constrained to be within $V_{min}$ and $V_{max}$, the minimum and maximum
inventory functions.

\begin{equation}
    V_i \in [V_{min}(t_i), V_{max}(t_i)]
\end{equation}

Commonly $V_{min}$ will evaluate to zero for all time periods, but examples
where non-zero minimum inventory is needed include when regulations require a minimum
level of inventory is held, as is seen for natural gas storage in some European countries.
Two possible reasons why $V_{max}$ need to be functions of time are:
\begin{itemize}
    \item Storage could be leased for consecutive time periods, but for different notional
    volumes.
    \item The terms of leased storage commonly stipulate that the storage must be empty
    at the time that the leased capacity ends.
\end{itemize}

Mathematical constraints.

- Set of decision times.

- Decision volume (inject/withdraw) for each time.

- Set of admissible decision volumes which adhere to constraints.

\section{Cash Flows}
Define $p(v_i, t_i)$ as the net present (discounted) cash flows resulting from decision
volume $v_i$ at time $t_i$.

\begin{equation}
    p(v_i, t_i, V_i) = (\mu(t_i, V_i, v_i) + v_i) s_i d(c(t_i)) - \pi(t_i, V_i, v_i)
\end{equation}

Where:
\begin{itemize}
    \item $s_i$ is the spot commodity price at time $t_i$.
    \item $c(t_i)$ is the commodity settlement time function which maps from the
    time that commodity was delivered to the time that payment is made. In European
    energy markets this is usually a formulaic date in the next month.
    \item $d$ is the discount factor function. Encorporating current market risk-free
    interest rates, this function maps from a time of a cash flow to the present value
    of one unit of money. Any cash flow at future time $t$ can be multiplied by $d(t)$
    in order calculate the present value of this cash flow.
    \item $\mu(t_i, V_i, v_i)$ is the volume of commodity consumed (not added to inventory)
    by the storage facility, as a function of time, inventory and decision volume. In practice
    this term is relevant for energy storage where some quantity of the energy commodity
    is consumed in order to power the motors used to get the commodity into or out of storage.
    \item $\pi(t_i, V_i, v_i)$ is the NPV of any other costs which are generated. An example of
    this in practice is the cost of running motors which facilitate injection or withdrawal.
\end{itemize}

The optimal value of the storage at time $t_i$ with inventory $V_i$ can be written as:

\begin{equation}
    \Omega(t_i, V_i) =  \sup_{\+v \in \Phi} \mathbb{E}^Q \biggl[\sum^n_{j=i}p(v_j, t_j, V_j) \biggr]
\end{equation}

Where $\mathbb{E}^Q$ is the expectation operator under the risk-neutral measure, $\+v$ is
an adapted decision strategy consisting of $\mathcal{F}_{t_i}$ adapted $v_i$ at each time step,
and $\Phi$ is the set of all feasible decision volume vectors, given the storage
constraints presented above.

\bigskip
From above %TODO reference the equation
we can see that the storage pricing problem effectively comes down to finding the optimal
decision strategy. This can be solved using Dynamic Programming. First writing the recursive
Bellman equation.

\begin{equation}
    \label{eq:bellman}
    \Omega(t_i, V_i) = \max_{v_i \in [v_{min}, v_{max}]} \biggl\{ p(v_i, t_i) + \mathbb{E}^Q \biggl[
        \Omega(t_{i+1}, V_i + v_i - L(t_i, V_i)) \biggr] \biggr\}
\end{equation}
% TODO make expectation conditional? Conditional on a vector of Markov variables?
Where the time and inventory dependence of $v_{min}$ and $v_{max}$ has been omitted to lighten notation.
The intuition behind this formula is that at every time step the optimal decision volume $v_i$
is the one which maximises the sum of current and discounted future expected cash flows
conditional upon the decision.
Hence, calculating the value involves recursively solving \ref{eq:bellman}, start at
the end date of the storage facility and using backward induction to move back in time,
at each time step calculating the optimal decision as a function of the previously
calculated values at the next time step.

\subsection{Valuation In Practice}
In order to implement the valuation calculation using \ref{eq:bellman} approximations need
to be made.

\subsubsection{Bang-Bang Exercise Strategy}
One problematic assumption in \ref{eq:bellman} is that the set of all permissible values of
$v_{min}$ is $[v_{min}(t_i, V_i), v_{max}(t_i, V_i)]$. The practical implemenation involves
evaluating the part of \ref{eq:bellman} inside the curly brackets for all permissible values,
picking the value of $v_i$ for which this evaluates to the highest value. However, assuming
$v_{min}(t_i, V_i) < v_{max}(t_i, V_i)$, there are an infinite number of permissible values for
$v_i$ making this impractical to implement. The approximating solution is to assume a
"Bang-Bang" exercise strategy, this being that the decision is either to inject to storage
at the maximum rate, withdraw at the maximum rate, or do nothing. Expressing this mathematically:

\begin{equation}
    \label{eq:bb-dcsn-set}
    v_i \in \{v_{min}(t_i, V_i), 0, v_{max}(t_i, V_i)\}
\end{equation}

If either $v_{min}(t_i, V_i) > 0$ or $v_{max}(t_i, V_i) < 0$ then the 0 element is removed
from \ref{eq:bb-dcsn-set} as it is no longer in the real set of permisible values.

\bigskip

Using a "Bang-Bang" exercise strategy is an approximation, hence the decision stategy that
this results in could be suboptimal, giving a lower value for the storage than it's true
value. However, several studies have shown that this assumption is a realistic one, and that
even if the set of permissible values for $v_i$ includes a larger number of elements, the
optimal strategy will be very close to the "Bang-Bang" strategy, and hence the calculated
storage value will be not far from the true optimal value.
%To do: provide references on bang-bang.

\subsubsection{Inventory Space Grid}
During backward induction \ref{eq:bellman} will need to be solved for specific
values of the inventory $V_i$. Clearly this cannot be done for all valid values of
$V_i$ as there are infinite number of such values.
In practice, at each time step $t_i$ a discrete grid of values within
$[V_{min}(t_i), V_{max}(t_i)]$ is chosen, and \ref{eq:bb-dcsn-set} is solved at each
of these.

\bigskip
The decision of the precise elements of the inventory space grid at which \ref{eq:bellman}
is evaluated is somewhat arbitrary. In practice, the following points need to be kept
in mind.
\begin{itemize}
    \item It should span the entire set of admissible inventories, i.e. the minimum
    value at $t_i$ should be $V_{min}(t_i)$, and the maximum value $V_{max}(t_i)$.
    \item A higher number of elements, should lead to a more accurate (less suboptimal)
    valuation, but will take longer to run. In practice some experimentation is required
    to choose a grid spacing sufficiently fine to give an accurate result, but without
    taking too long to calculate. This will be somewhat complicated by the fact that
    different storage configurations will behave differently.
\end{itemize}

\bigskip
In the Cmdty.Storage library C\# core API the calculation of this grid is abstracted
away to the IDoubleStateSpaceGridCalc interface allowing an extension point where the
client code to provide it's own implemenation. An implementation of this is provided
which calculates the grid with a fixed spacing between elements.

\bigskip
The calculation of an inventory grid with superior qualities is potentially an interesting
area of future study. The aim is find a good trade-off between a low number of points
on this grid, in order to have low computation time, whilst maintaining a good level
of accuracy such that the NPV calculated is not too suboptimal.
% To do, look into Warin work and Semi-Lagrangian

\subsubsection{Continuation Value Interpolation}
Solving \ref{eq:bellman} involves the calculating of $\mathbb{E}^Q \biggl[
\Omega(t_{i+1}, V_i + v_i - L(t_i, V_i)) \biggr]$
the expected value of the storage at the next time step, give the specific decision volume
$v_i$ chosen. In literature this value is often referred to as the "continuation value".
During the backward induction, the continuation will always have
been previously calculated. However, as described in the previous section, these values
will only have been calculated at specific values of $V_i$ on the inventory space grid.
It is unlikely however, that the continuation value for the inventory equal to exactly
$V_i + v_i - L(t_i, V_i)$ will have been calculated. This necessitates some sort of
approximation.

- Continuation value interpolation.
- Inventory space reduction.
\bigskip
\bigskip

- Problem then boils down to calculating the expectation.

- Intrinsic Valuation

\end{document}


    \filetitle{iscompatible}{True if two models can occur together on the LHS and RHS in an assignment}{model/iscompatible}

	\paragraph{Syntax}\label{syntax}

\begin{verbatim}
Flag = iscompatible(M1,M2)
\end{verbatim}

\paragraph{Input arguments}\label{input-arguments}

\begin{itemize}
\itemsep1pt\parskip0pt\parsep0pt
\item
  \texttt{M1}, \texttt{M2} {[} model {]} - Two model objects that will
  be tested for compatibility.
\end{itemize}

\paragraph{Output arguments}\label{output-arguments}

\begin{itemize}
\itemsep1pt\parskip0pt\parsep0pt
\item
  \texttt{Flag} {[} \texttt{true} \textbar{} \texttt{false} {]} - True
  if \texttt{M1} and \texttt{M1} can occur in an assignment,
  \texttt{M1(...) = M2(...)} or horziontal concatenation,
  \texttt{{[}M1,M2{]}}.
\end{itemize}

\paragraph{Description}\label{description}

The function compares the names of all variables, shocks, and
parameters, and the composition of the state-space vectors.

\paragraph{Example}\label{example}


\section{Observable stochastic games}