%!TEX root = ../main.tex
\section{Related Work}
\label{sec:related_work}
This section gives a survey of relevant literature, mostly covering approaches to ensuring termination or productivity of programs defined over both inductive and coinductive data.

\subsection{Size-change Termination}
Due to the fact that Idris already has a working totality checker using size-change termination\,\citep{BradyIdrisImpl13}, it would be interesting if the size-change principle could be used for determining the productivity of corecursive functions as well. The size-change principle for termination was first proposed for a strict first-order functional language (without loop constructs) by Lee, Jones, and Ben-Amram\,\citep{LeeJones01SizeChange}. The principle essentially states that if infinitely many recursive calls to a function would lead to infinite decrease in some parameter value, then the function must be terminating, since any value of an inductive type must have finite size. This last condition is of particular importance, as the size-change principle cannot in general recognize functions as being terminating if they have parameters that do not exhibit a well-founded order. Lee, Jones, and Ben-Amram present two realizations of the principle, one using automata and one using a call graph. In the graph formulation, termination is determined by identifying any recursive calls (both direct and indirect) through cycles in the call graph, and then constructing a ``size-change graph'' for each of these. The size-change graphs are then used to find out whether infinite descent in some parameter value is present. One of the limitations of this approach is that parameter values must decrease monotonically: Values cannot at any point become structurally larger, even though the total change in size in a call chain would ultimately lead a to a decreasing value. Two examples of size-change terminating functions are shown in Figure~\ref{fig:sizechange_plus_map}. In both examples, the recursive call happens on structurally smaller input.

\begin{figure}
\begin{alltt}
plus : Nat -> Nat -> Nat           map : (a -> b) -> Vect n a -> Vect n b
plus Z      m = m                  map f []        = []
plus (S n') m = plus n' m          map f (x :: xs) = f x :: map f xs
\end{alltt}
\caption{Two size-change terminating functions.}
\label{fig:sizechange_plus_map}
\end{figure}

Since its first-order formulation, the principle has been proven to work for more expressive cases. Jones and Bohr\,\citep{Jones04Untyped} showed that size-change termination can be applied to the untyped lambda calculus using abstract interpretation. Interesting results of this work include size-change termination of programs employing the Y-combinator.

Following the work on the untyped lambda calculus, Sereni and Jones generalized the size-change principle to handle a higher-order functional language with user-defined data types and general recursion\,\citep{Sereni05terminationanalysis,Sereni06Phd}. Here, a termination criterion is presented which works for arbitrary control-flow graphs, and in turn is able to give an approximation of termination for both strict and lazy functional programs. A key point in this work is how different approaches to control-flow and call graph construction may influence the preciseness of the termination analysis.

Most implementations of the size-change principle only work on data for which some well-founded order exists. Nevertheless, Avery\,\citep{Avery06} presented a formulation in which it is possible to detect size-change termination for non-well-founded data types --- in particular, this formulation is shown to work for a language with an integer type. Instead of identifying infinite descent using a well-founded partial order on parameters, the analysis is based on a decrease in invariants which are found to hold for each program point. These invariants are inferred automatically from the structure of the program. The idea is that if the value of some invariant (which can involve arbitrarily many values) can be shown to decrease on every passage of a program point, then the program terminates. A simple example of a size-change terminating program in Avery's implementation is given in Figure~\ref{fig:avery_example}. The invariant for the inner loop is \texttt{n - j + i}, while the one for the outer loop is \texttt{n - i}. These cannot decrease forever, and therefore the program is size-change terminating.

\begin{figure}
\begin{alltt}
for (i = 0; i <= n; i++) \{
  for (j = 0; j-i <= n; j++);
\}
return;
\end{alltt}
\caption{A size-change terminating program with integers, written in a subset of C.}
\label{fig:avery_example}
\end{figure}

Avery's formulation is insufficient or impractical for productivity checking definitions with copatterns in several aspects. First, it is still assumed that totality is determined solely on the basis of an infinitely decreasing property that is bounded from below. However, many corecursive functions exhibit no such property; Indeed, one of the virtues of such functions is exactly the ability to define infinite structures. Secondly, the formulation works on a graph of program points. Since it is valid for a corecursive function to be defined in terms of itself, non-termination for copatterns only becomes apparent when observations are defined in terms of themselves. Constructing a graph of all observations in the system would be necessary for this approach to work, and such an undertaking might not be ideal, since it would require all observations to be unfolded (see Section \ref{sec:productivity}).

In more recent work, Hyvernat\,\citep{Hyvernat13} has proposed a formulation of the size-change principle for functional languages which to a certain degree solves the problem of non-monotonic decrease in parameter values. The motivation behind this work is to incorporate size-change termination into the PML language\,\cite{PMLLanguage}. Non-monotonic decrease is detected by tracking the size of a parameter throughout the entire control-flow graph, instead of merely recording whether each call in isolation leads to a decrease in some value. As an extension, Hyvernat proposes that infinite data can be covered by the principle by counting the number of (lambda) abstractions and compare these to the number of function applications in a program. His idea is that if we do not reduce under abstractions, then if a function has more abstractions than applications, then it will be productive. In this form, however, this proposal seems inadequate for a usable productivity checker for copatterns.

The termination criterion that comes closest to the size-change principle, and which actually predates the original size-change article (\citep{LeeJones01SizeChange}), is the one developed for the \texttt{foetus} termination checker by Abel\,\citep{Abel98foetus}. This criterion forms the basis of the totality checker used by Agda\,\citep{Norell:thesis}. In a similar manner, Abel identifies recursive calls in a call graph and determines termination by tracking changes in parameter sizes. This work does not make any mention of productivity for coinductive data, however.

It seems that there exists no current formulation of the size-change principle which describes how productivity for coinductive data can be ensured in a way that is suitable for a system with copatterns. In the following, we will explore several different approaches to productivity, unrelated to the size-change principle.

\subsection{Guarded Corecursion}
Because of the duality between inductive and coinductive types, it may be compelling to think that if size-change termination for inductive types works by identifying structurally smaller values, then a dual notion of ``size-change productivity'' would exist that worked by identifying structurally larger values. The idea of \emph{guarded corecursion} uses exactly this idea to determine productivity: Where values become structurally smaller as the result of pattern matching, they become structurally larger by constructor application. Therefore, the \emph{guardedness principle} states that a coinductive definition is guarded if all corecursive calls appear directly under a coinductive constructor. This has the implication that the productivity of corecursive functions can be detected by a purely syntactic check.

The guardedness principle was first proposed by Coquand\,\citep{Coquand94} as an important part of a ``guarded proof induction principle'' for a proof system containing coinductive definitions, inspired by a similar approach in the area of process calculi by Milner\,\citep{Milner82}. In continuation of Coquand's efforts, Gim\'{e}nez applied the method to the Calculus of Constructions in order to avoid the introduction of non-normalizable terms\,\citep{Gimenez95}.

The guardedness property described by Coquand and Gim\'{e}nez was intended to be used within a proof system (e.g. Coq\,\citep{Coq:manual}) in order to have proofs involving coinductive types, not necessarily taking a more practical programming setting into account. In a programming setting, Telford and Turner argue that this approach is too conservative\,\citep{Telford98ensuringthe}. Because \emph{all} corecursive calls to a function must appear directly under a constructor, many intuitive defintions of standard functions (e.g. \texttt{nats} in Figure \ref{fig:nats}) are not considered productive.

In their \emph{Elementary Strong Functional Programming} (ESFP) system\,\citep{Telford97ensuringstreams,Telford98ensuringthe}, Telford and Turner extend the principle to accept a wider range of corecursive functions as being productive, showing it to be usable in a realistic programming setting. They achieve this by considering guardedness more abstractly over a domain of guardedness levels, such that productive corecursion is bounded by a given ``depth''. As an advanced example, they show that the Hamming function is considered productive within their system.

Another approach to coping with the conservative nature of the original guardedness principle is to consider alternative programming styles, making productive definitions easier to write. Following the incorporation of the guardedness condition into the Agda totality checker\,\citep{AltenkirchNAD10}, Danielsson\,\citep{Danielsson10beatingthe} described a method for working around the guardedness condition whenever it rejects a productive program. For each situation, he designs an embedded domain specific language, implements the rejected program in said language, and then provides an interpreter which is accepted by the guardedness condition. None of these steps happen automatically, but must be done manually. Although useful, Danielsson argues that efficiency is a concern, and that the best solution might be to entirely move away from using guardedness for productivity. Sized types have since been implemented in Agda.

\subsection{Sized Types}
\label{sec:sized_types}
The idea of sized types is that instead of detecting totality using a syntactic check, such as it is the case for guarded corecursion, size information is added to the type system. Because the type system can then provide guarantees about the sizes of both the input and output of a function, this enables the user to write stronger type specifications. The term ``size'' is used quite broadly here, without implying any specific structure of the data. Unlike the size-change principle or guarded corecursion, approaches using sized types for totality checking of both inductive and coinductive data within the same system have been presented\,\citep{Abel13Wellfounded}. An Agda example of a coinductive stream type with sized types is shown in Figure~\ref{fig:agda_stream_sized_types}. Here, the \texttt{tail} observation has an implicit size parameter \texttt{j}, the type of which (\texttt{Size< i}) indicates that the result of a \texttt{tail} observation is a smaller \texttt{Stream} than the observed \texttt{Stream}, which has size \texttt{i}. This definition of streams can be used to define the natural numbers using sized types, as shown in Figure~\ref{fig:agda_nats_sized_types}. The productivity of the \texttt{nats} and \texttt{map} functions can be established by enforcing that the outcome of an observation has a smaller size than the observed stream. This is apparent from the size arguments applied to \texttt{map} in both functions, since \texttt{j} is less than \texttt{i} by definition. Note that all of these size annotations must be provided by the user.

\begin{figure}
\begin{alltt}
record Stream \{i : Size\} (A : Set) : Set where
  coinductive
  field
    head : A
    tail : \{j : Size< i\} ->  Stream \{j\} A
open Stream
\end{alltt}
\caption{A \texttt{Stream} defined with sized types in Agda.}
\label{fig:agda_stream_sized_types}
\end{figure}

\begin{figure}
\begin{alltt}
map : \{i A B\} (f : A -> B) -> (s : Stream \{i\} A) -> Stream \{i\} B
head (map \{i\} f s)     = f (head s)
tail (map \{i\} f s) \{j\} = map \{j\} f (tail s \{j\})

nats : \{i\} -> Stream \{i\} Nat
head (nats \{i\})     = Z
tail (nats \{i\}) \{j\} = map \{j\} S (nats \{j\})
\end{alltt}
\caption{The corecursive \texttt{nats} function in Agda.}
\label{fig:agda_nats_sized_types}
\end{figure}

Sized types for totality checking were first proposed by Hughes, Pareto, and Sabry\,\citep{Hughes96} for reactive systems, where each data type introduced into a program is associated with a family of sized types indicating the bounds of a value of that type. A similar idea was developed by Amadio and Coupet-Grimal\,\citep{Amadio98}, where guard conditions are introduced into the type system to ensure the productivity of coinductive data, following the work of Coquand\,\citep{Coquand94} and Gim\'{e}nez\,\citep{Gimenez95}.

Eduarde Gim\'{e}nez also presented a system for typing recursive definitions in an extension of the Calculus of Constructions using sized types\,\citep{Gimenez98structuralrecursive}. A notable result of this work is that any well-typed term in the proposed extension is normalizing with respect to lazy evaluation, widening the domain of functions to which type-based termination is applicable substantially. In the wake of this extension, Abel\,\citep{Abel99terminationchecking} wrote a quite accessible paper on using sized types for termination checking of both inductive types, showing that bidirectional type checking\,\citep{Pierce00} is suitable for a system with sized types. In addition, it is described how infinite streams defined by coinductive types can be encoded in a language as functions on natural numbers, and that the productivity of a stream can be understood in terms of its \emph{definedness}, meaning the number of times it can safely be unfolded.

The notion of definedness is also an important part of Abel and Pientka's work on applying sized types to a system with copatterns\,\citep{Abel13Wellfounded}, although here it is defined more precisely as the \emph{depth} of a value of coinductive type. By directly using the notion of depth in the type system, they show that totality of both coinductive definitions with copatterns and inductive definitions (as well as mixed inductive-coinductive) can be determined by well-founded induction on sizes within the type system. The method is shown to work for System F\textsubscript{$\omega$}, and has later been implemented in Agda along with copatterns. Thus, sized types are a candidate for detecting productivity of corecursive functions with copatterns in Idris. However, due to various concerns discussed in Section \ref{sec:productivity}, sized types may not be a desirable solution.

In relation to other methods for totality checking, Thibodeau\,\citep{Thibodeau11} presented an interesting comparison between sized types and termination checking by structural size change (such as the methods used for the size-change principle and the \texttt{foetus} termination checker). Here, Thibodeau concludes that sized types in general should be preferred over approaches examining structure, since they generally are more flexible. The main concern regarding sized types is that size annotations make the code harder to read, and seem unnecessary from the point of view of the user of the language. Thibodeau expects, however, that it would be possible to reconstruct most size annotations automatically in a mature system. To our knowledge, it has yet to be investigated whether all size annotations could potentially be reconstructed, essentially making the user oblivious to the use of sized types.

\subsection{Methods Based On Time}
Atkey and McBride\,\citep{AtkeyMcBride13} have developed an experimental calculus with coinductive types in which productive programs can be typed by introducing ``clock variables'' to the type system. Much like the \texttt{Inf} operator described in Section~\ref{sec:stateinidris}, they use a \emph{guardedness type constructor} to indicate values that will only be available ``tomorrow''. These guarded types are then parameterized by clock variables, which has the effect that the output on a given ``day'' must be produced on that day, i.e. from the data that is available that day. Since Atkey and McBride quantify over clock variables in each definition, these provide only local constraints, expressing the relationship between input and output. This should be contrasted with the nature of sized types, where constraints can be expressed in terms of globally available types. In its current form, the system by Atkey and McBride is not an ideal solution for productivity checking definitions with copatterns, since it seems to require a certain style of programming in order to be usable. Furthermore, it still requires the user to specify ``time annotations'' for all definitions, which is not very different from sized types, although they only have local scope. A system based on local time constraints is quite interesting, however, and will be explored in greater detail as part of our proposal for a productivity algorithm in Section~\ref{sec:productivity}.

%Atkey and McBride\,\citep{AtkeyMcBride13} have developed an experimental calculus with coinductive types in which productive programs can be typed by introducing ``clock variables'' to the type system. The idea is to move the guardedness check from the syntactic level to the type level, by using \emph{guardedness type constructors} to represent values which can only be used in a guarded manner. These type constructors are then annotated by clock variables, such that it is possible for them to model guarded values which may only be available ``tomorrow''. The input and output of a function can then be typed such that they run on the same or related clocks, expressing certain guarantees about how many observations one can make on a given value. This idea of time will be revisited in Section \ref{sec:productivity}\todo{Remember this reference to Section \ref{sec:productivity}}. The difference between the approach taken by Atkey and McBride and full-blown sized types, is that they require fewer size annotation from the user, which is achieved by utilizing the described notion of time. The downside is that it does at this point require a certain style of programming which seems quite inflexible, making the approach less ideal for programming with copatterns.

Krishnaswami\,\citep{Krishnaswami13} devised a language for functional reactive programming based on time. In his system, it is impossible to write a program which gives rise to either ``space leaks'' (non-permanent memory leaks from capturing too much history) or ``time leaks'' (dependence on past values for arbitrary intervals of time). This is achieved by keeping track of a global clock, and then defining two operational semantics for evaluation of programs. One of these define evaluation of an expression at the current time, while the other has a ``tick relation'' which advances the global clock. Whenever the global clock is advanced, all values which can no longer be referenced due to time constraints are discarded from the environment, thus eliminating space leaks. Furthermore, at each clock tick, the values which have become available at that tick are unfolded, in effect making time leaks impossible. The type system is extended with rules that make sure that no references to unavailable data can be made. This work is quite interesting in relation to the solution we propose in Section~\ref{sec:productivity}, since Krishnaswami's approach only allows definitions in terms of future values. To type programs dependent on time, he uses \emph{temporal recursive types}, in which the recursive occurrence is not available before the next clock tick. This is similar to how time measures are used in our proposal, where the next observation on a coinductive instance occurs at the next moment in time. Therefore, temporal recursive types could most likely be used for productivity checking.


\section{Results}

% TODO Supervisor: Can you put a table listing the experiments? Columns: experiment, market setting, simulation runs, purpose etc. DONE!
% if these can be put clearly, the text can tell (cannot read)
The model was tested in several experiments. First, the generic dynamics of
the model is inspected. The convergence to equilibrium price is studied with two
simulations and then the model is validated using stylized facts.
The purpose of the first set of experiments is to validate the model and provide additional evidence
on the observations from previous literature regarding to efficiency of zero-intelligent traders and
reproduction of stylized facts.

The second set of experiments consists of examining price dynamics by injecting shocks to the order book via placement
preferences of the traders. This is more experimental in nature and the purpose is to gain a better understanding of
how the market price moves due to the structure of the order book in the model. The summary of the experiments is
shown in the table ~\ref{tbl:experiment_summary}.

\input{tables/summary_of_experiments.tex}

In all the experiments all the traders are allowed
to make one trading decision per session, meaning that the speak ratio
is one. There are no dividend nor interest paid for any assets in these experiments.
The summary of the parameters that are set as the same in all of the experiments
is shown in the table ~\ref{tbl:parameter_summary}.
% TODO:
%   Why equilibrium testing? Literature has inspected it and this is to closer this model to it
%   Why stylized fact validation? Literature uses these to validate
%   Why shock injection? Because of something new.

\input{tables/summary_of_parameters.tex}

\subsection{Generic dynamics of the model}
% Price dynamics, stylized facts, order book evolution
The single asset simulation was run three times: for the first run
the starting market price was set to 500, for the second run it
was set to 1 500 and for the third was set to 1 000 which is near the equilibrium price.
The rationale for this equilibrium price is discussed later.
The first and second simulations were
used to study how the convergence to the equilibrium price occurs
and the third to examine the stylized facts of the price
dynamics after the equilibrium is reached. The simulations were
run with 10 000 zero-intelligent traders which is the
same amount of traders as what \citet{Raberto05} used in their experiments
with somewhat similar settings. As only the convergence to equilibrium is
the point of interest in the first and second simulations, the number of sessions
were chosen to be relatively small, 200 sessions, but to get reliable results for
the third simulation the number of sessions was chosen to be 4 000 in order to
make sure the statistical significance of the tests performed to validate the
stylized facts will not be hampered by the number of observations.

The amount of currency and the amount of stock
a trader owns at the beginning of all the simulations were set to
10 000 000 units and 10 000 units respectively. Therefore
the ratio of stock to currency is 1 000 which
is the expected equilibrium price as there are
no payouts in either asset. The amount of currency
per trader may seem much but as the tick size is one,
it may be more convenient to think the currency as amounts
of cents or pennies. The standard deviation of
the normal distribution that the traders use to pick the order prices
is set to 20. % TODO Supervisor: See if you can put some quantities to the table (see upper). DON'T remove explanations. DONE!

%\begin{table}
%    \input{tables/simulation_summary.tex}% table.tex > \mytable
%\end{table}

\subsubsection{Converge to Equilibrium}
% Descriptive analysis:
%   how converge occurs
The evolution of trade prices, quantities and trade values throughout
the trading sessions for the lower and higher starting price simulations
are shown in the figure ~\ref{fig:basic_trades}. As can be observed,
the near-equilibrium market price is achieved before 30 trading
sessions for both experiments. The simulation with lower starting price converges
to the equilibrium in almost instantly whereas for the higher starting
price it takes more sessions. Furthermore, the traded quantities are
initially lower for the simulation with higher staring price than
for the simulation with lower price. As the traded volumes are lower,
the converge occurs slower due to that there are fewer situations in
which the market price can adapt. In addition to these findings,
the equilibrium price is slightly lower than the expected which is
about 940.
%The reason why the price stays slightly
%under the equilibrium price and why the price converges quicker with
%lower starting price than with the higher may be caused by the implementation of
%determining the order price and order quantity. If a trader decides
%to allocate less currency on an order than the order price it chose
%the order gets obviously invalidated but there is no such
%limitation for placing asks. Therefore, there might be a slightly less
%bids than asks in general.

\begin{figure}[H]
    \includegraphics[width=\linewidth]{plots/basic_trades.png}
    \caption{Evolution of price and quantity} % TODO Supervisor: "in the simulation one using... showing" Explaing hypotheses and the plot more. Same with plots 6.2-6.4. DONE!
    \label{fig:basic_trades}
\end{figure}

% How the market converged to equilibrium
The market depths, as shown in figure ~\ref{fig:market_depths}, suggest that the
converge to equilibrium is caused by balancing the sides of the market.
In this figure, the order book is visualized for the first 15 trading sessions
for both of the simulations: with a starting market price of 500 and 1 500.
The surface describes the evolution of the cumulative bids and cumulative asks
throughout time and the bottom of the valley formed in the surface is the bid-ask spread.
The left side from the valley is the cumulative bid book and right is the cumulative ask book.
The ask side of the market is almost completely missing initially in the run that
starts with lower market price while the opposite is true for the run with higher
initial market price. The ask side of the order book emerges almost instantly
in the simulation of the lower starting price whereas the converge happens more
gradually with a higher starting price.

\begin{figure}[H]
    \centering
    \begin{subfigure}{.5\textwidth}
      \centering
      \includegraphics[width=\linewidth]{plots/basic_market_depth_converge_lower.png}
      \caption{Starting price 500}
      \label{fig:market_depth_lower}
    \end{subfigure}%
    \begin{subfigure}{.5\textwidth}
      \centering
      \includegraphics[width=\linewidth]{plots/basic_market_depth_converge_higher.png}
      \caption{Starting price 1 500}
      \label{fig:market_depth_higher}
    \end{subfigure}
    \caption{Converge of the order book to equilibrium}
    \label{fig:market_depths}
\end{figure}
% TODO Supervisor: remove extra enters. DONE!
Figure ~\ref{fig:basic_orderbook_evo} provides more top-down view of the orderbook.
This figure shows mostly the same aspects as figure ~\ref{fig:market_depths} but the sides of the
order book are not extrapolated to the edges of the plot: the white colour represents the absence of orders,
the green colour the cumulative bids and the red colour the cumulative asks.
The figure suggests that the asking traders in the experiment with the lower initial market price
adopt the equilibrium price quicker than the bidding traders in the experiment with the higher initial market
price. One possible explanation for this phenomenon might be the bid-ask asymmetricity
discussed earlier. It is also noteworthy that the downward spikes found in the figure when the equilibrium
is reached are caused by that some traders had consumed most of their currency balances and still decided
to do a bid order. Because of the budget constrain, these traders had to submit bid orders with prices
they could afford and these prices were substantially lower than the market price and may seem like outliers.

% TODO: Mention that the reason for high price - low price differing convergence to equilibrium is inspected in shocks

\begin{figure}[H]
    \includegraphics[width=\linewidth]{plots/basic_order_book_evo.png}
    \caption{Order book evolution}
    \label{fig:basic_orderbook_evo}
\end{figure}

When the equilibrium is reached, the order book is rather steep as is illustrated in the figure
~\ref{fig:basic_orderbook_evo}. This figure consists of the last 50 sessions of the extended simulation.
The spread also is also relatively stable most likely due to the number of traders.

\begin{figure}[H]
    \includegraphics[width=\linewidth]{plots/basic_market_depth_in_equilibrium.png}
    \caption{Order book depth in equilibrium}
    \label{fig:basic_orderbook_evo}
\end{figure}

% TODO: additional finding about explaining the next price

\subsubsection{Model Validation with Stylized Facts}
% stylized facts
% Something about filtering fist 100 out and now inspecting stylized facts
As stated before, the representativeness of the model's price behaviour compared to real markets
is studied using stylized facts. In order to have representative stationary data set to
test the stylized facts, the sessions before reaching the price equilibrium are filtered out.
Removing the first 100 sessions was considered suitable for this purpose leaving total of 3900
sessions to study the stylized facts.
As already discussed, the longer simulation that starts near-equilibrium
price is used to study the presence of stylized facts in the model.

% Autocorrelation
% TODO: REWRITE
The autocorrelation of the at equilibrium experiment is inspected using autocorrelation function (ACF) and partial
autocorrelation function (PACF). ACF and PACF functions for the intrasession absolute prices and absolute returns
are plotted in the figure ~\ref{fig:basic_autocorr}. Intrasession in this context is defined as the period
between each trade. It should be noted that this interval is non-fixed and may have the effects of non-trading.
The x-axes of the plots represent the lags and y-axes of the plots represent the
autocorrelation coefficients. The coefficient for lag zero is always one as a value is always completely autocorrelated with itself.
The absolute returns in this context are the actual price movements of
the asset and absolute values are simply the actual prices of the asset. As the prices are already in equilibrium, and therefore should be
stationary, taking the third difference from the absolute value, calculating the rate of returns, should not be necessary. There is some negative
autoregressive (AR) process in the absolute returns as the ACF plot shows negative and slowly decaying lags. There are numerous
significant lags in the AR process as can be observed from the PACF plot. In addition, the prices themselves are
positively autocorrelated with an AR process as the ACF shows slowly decaying lags. These findings are in line with the experiments conducted by \citet{Raberto05}:
they also observed some negative autocorrelation in intraday returns and long-lasting autocorrelation in the absolute
values with their simulation. However, it should be noted that this figure shows very short term
autocorrelations and the time between the lags may not be fixed: one lag is simply derived from one
trade.
% https://www.youtube.com/watch?v=R-oWTWdS1Jg

\begin{figure}[H]
    \includegraphics[width=\linewidth]{plots/basic_autocorrelation_intra.png}
    \caption{Autocorrelation of the simulation}
    \label{fig:basic_autocorr}
\end{figure}

Figure ~\ref{fig:basic_autocorr_per_session} suggests that the autocorrelation is carried over one
session for the absolute returns and four sessions in terms of prices. The x-axis and y-axis of the figure are the same as
in figure ~\ref{fig:basic_autocorr}: x-axis is the lag number and y-axis is the autocorrelation coefficient.
The prices used in this figure are the last trade prices of each session. As can be interpreted from the figure, there is an AR(1) process in
the absolute returns per session and AR(4) for prices on a session basis.

\begin{figure}[H]
    \includegraphics[width=\linewidth]{plots/basic_autocorrelation.png}
    \caption{Autocorrelation of the simulation grouped by session}
    \label{fig:basic_autocorr_per_session}
\end{figure}

% Fat-tailed returns
The distribution of the returns are plotted in ~\ref{fig:basic_return_distr}. As observed in the plot, the fat-tailed returns
clearly exist in the intrasession period but not necessarily per session basis. For intrasession returns, there is a clear spike in the mean of the
distribution and the tails spread out but these are not visible in the returns between session. In addition, the per-session distribution
is not smooth even though the sample consists of 22 million trades. The cause for this may be that the prices are not
continuous because of the tick size: the minimum possible amount for the price to go up or down is one. Furthermore, prices are
stationary thus the returns are produced by a specific set of prices. Therefore, the returns are also inherently discrete. One option
to mitigate this would be to increase the amount of currency to increase the price and increase the absolute
variation of the prices. Jarque-Bera goodness of fit test suggests that both time periods are not normally distributed, %TODO Supervisor: Onko tama esitelty teoriassa? Kerro mika se on. "Jarque-Bera goodness of fit test suggests"
as the p-values are practically zero in both cases thus the null hypothesis is rejected. The null hypothesis of the Jarque-Bera test
is a joint hypothesis that the distribution has no skewness and no excess kurtosis. However, as discussed, the distributions are not
convincingly continuous thus it is unclear how robust these results are. The kurtosis of the distribution for intrasession is 5.0
and -0.5 for session basis and therefore this indicates that the intrasession returns are leptokurtic while the returns between
sessions are slightly lighter in tails than a normal distribution. To summarize, the model does have fatter tails than a normal distribution
for intrasession returns but not between sessions.

% \citet{Raberto05} found fat tails in intra day

\begin{figure}[H]
    \centering
    \begin{subfigure}{.5\textwidth}
        \centering
        \includegraphics[width=\linewidth]{plots/basic_fat_tails_per_session.png}
        \caption{Between last prices of sessions}
        \label{fig:basic_return_distr_per_session}
    \end{subfigure}%
    \begin{subfigure}{.5\textwidth}
        \centering
        \includegraphics[width=\linewidth]{plots/basic_fat_tails_intrasession.png}
        \caption{Between trades}
        \label{fig:basic_return_distr_intrasession}
    \end{subfigure}
    \caption{Distributions of rate of returns}
    \label{fig:basic_return_distr}
\end{figure}

The spike in the distribution of the intrasession returns may be caused by the structure of the order book. If the order book
sides are steep, as they are and illustrated in ~\ref{fig:basic_orderbook_evo}, it requires substantially sized
order to push the opposing side back and have a significant effect on the price. Therefore, the price changes between trades
are generally rather small until there comes an order that can buy or sell a significant chunk of the opposing side and have
instant impact on the price. In such a case the opposing side may be weakened so much that the price change can be radical.
Therefore, the reason for the spike in the returns may be that small and medium-sized orders may have a similar impact on the
price but big orders may push the side relatively much further as the density of the order quantity in terms of price drops
when moving further away from the last market price.

% Volatility clusters
The autocorrelation of the volatilities in figure ~\ref{fig:basic_volaclusters}
indicate there are some volatility clusters in short term. The figure was conducted by
dividing the trade prices to fixed length windows in which the volatilities were calculated per-window
basis. As ACF plot is slowly decaying, the autocorrelation follows AR process. The market
microstructure is able to produce volatility clusters without additional volatility feedback mechanics.
Furthermore, the order book evolution may play a role in creating the volatility clusters.

\begin{figure}[H]
    \includegraphics[width=\linewidth]{plots/basic_volaclusters_intra.png}
    \caption{Volatility Clusters}
    \label{fig:basic_volaclusters}
\end{figure}

These findings are somewhat in line with previous literature. \citet{Genoa01}, \citet{Raberto05} and \citet{LIU20082535}
discussed that the microstructure is the cause for the fat-tailed returns. This is probably also the cause for the
fat-tails of intrasession returns observed in this thesis. However, the autocorrelation is different than what \citet{LIU20082535}
observed with high call market-clearing frequencies. Regardless, the autocorrelations of returns observed in this thesis and their model
are both short term. Even though a call market has different mechanics than a continuous market, a call market with
very high clearing frequency behaves similarly as a continuous market does. \citet{Genoa01} and \citet{Raberto05} only discussed
forming volatility clusters in the context of their model which had volatility feedback mechanism thus it is unclear
whether the volatility clusters observed in the model created in this thesis are to be expected.
% TODO: how does the autocorrelation differ from LIU20082535?

\subsection{Shock injection}

To gain a better understanding of the order book dynamics of the model the next set of experiments are about injecting shocks
to the order book. This is done by changing the weights the trading agents use to pick the type of an order they will submit.
The experiment is started in equilibrium and then the probability of picking ask order is increased from 33\% to 43\%
whereas the probability for bid order is reduced from 33\% to 23\%. The probability for inaction is kept at 33\%.
After reaching a new equilibrium the weights are set back to 33\% for each option. Then the same experiment is repeated
but instead of a negative shock, a positive shock is introduced using weights 43\%, 23\% and 33\% for bid order, ask order
and inaction respectively.

As this experiment is more exploratory in nature than the previous experiment the experiment may not need to be computationally
as heavy as the other experiments. Therefore, only 200 sessions are used to let the simulation reach equilibrium before and during
the shocks. The number of trading agents is kept at 10 000 to reduce noise in interpreting the results. In addition, both experiments,
introduction of negative and positive shocks, are conducted in the same simulation run.

The evolution of the order books in both shocks are presented in ~\ref{fig:shocks_orderbook}. Such shocks introduce a new equilibrium
price which is expectedly smaller in negative shock and higher in positive shock. When excess amount of bid orders flow to the market
there is a pressure for the price to increase and vice versa, which is observed here.
% TODO: Explain when the shocks start and end in the graphs

As observed in the previous experiment, the converge to equilibrium occurs rapidly. Interestingly, the gradual convergence of price
to equilibrium is more prevalent in positive shock than in negative shock. In addition, the order book volumes on both sides of the
market are higher in negative shock than in positive shock, as observed in ~\ref{fig:market_depths_shocks}. Furthermore, the order
book volumes are higher in negative shock than in the actual equilibrium. The reason for this is most likely that the smaller price
allows the buyers to bid for higher quantities due to that they can afford more and vice versa.

\begin{figure}[H]
    \includegraphics[width=\linewidth]{plots/shocks_order_book_evo.png}
    \caption{Order book evolution in shocks}
    \label{fig:shocks_orderbook}
\end{figure}

The comparable sizes of the order books can be better observed in ~\ref{fig:market_depths_shocks}. Initially, in negative shock,
there is a sudden surge of ask orders with sudden decline of bid orders. The existing bid orders are consumed by the ask orders
until the price reaches to levels that the ask orders cannot push further due to the balance between the currency and the asset:
the buyers submit bids with higher quantities than previously as with the new price they can afford more. The positive shock has a similar
effect: there is a sudden surge of bid orders and the ask side disappears for a moment and then gradually the equilibrium
price is reached as the ask side re-emerges. As demonstrated, the global balance between assets is not the only factor driving the
market price and the imbalance of the sides of the submitted orders can drive the price also in zero-intelligent markets.

% TODO: There is surge of orders

\begin{figure}[H]
    \centering
    \begin{subfigure}{.5\textwidth}
      \centering
      \includegraphics[width=\linewidth]{plots/shocks_neg_market_depth_in_equilibrium.png}
      \caption{Market depth of negative shock}
      \label{fig:market_depth_neg_shock}
    \end{subfigure}%
    \begin{subfigure}{.5\textwidth}
      \centering
      \includegraphics[width=\linewidth]{plots/shocks_pos_market_depth_in_equilibrium.png}
      \caption{Market depth of positive shock}
      \label{fig:market_depth_pos_shock}
    \end{subfigure}
    \caption{Market depths of the shocks}
    \label{fig:market_depths_shocks}
\end{figure}

%   Lisaa tahan jonkinlainen "summary of results" kappale, jossa kerrot tarkeimmat loydokset kootusti
%   --> ota materiaali conclusionista
\subsection{Summary of Results}

% Equilibrium converge

The model converges rapidly to equilibrium price which was slightly lower
than expected from the ratio of the assets. Interestingly, the convergence
occurs more rapidly with lower starting price than higher. The model manages
to somewhat capture the stylized facts observed in actual markets: the intrasession
returns are fat-tailed and some short-term volatility clusters were observed.
However, there was some negative moderately short-term autocorrelation in the
absolute returns and the fat-tails of returns are not carried over to the returns between sessions.
This is also somewhat in line with the literature with comparable models.
% TODO: Specify which studies

% Shocks
The model was also tested with negative and positive shocks by changing the
traders' probabilities to submit bid and ask orders. It was found out that
the global balance between assets is not necessarily the only driving factor for the
equilibrium price in a market populated with zero-intelligent traders
and the price can be manipulated by changing these values. Furthermore, this finding suggests that
solely the balance, or imbalance, of the sides in an order book may have an important role in
driving the price. For example, if the bid side is thinner than the ask side it may be more probable
that there will come an ask order that consumes a larger proportion of the bid side than the other way
around. As the ask order consumes a large chunk of the bid side, the price will decrease rapidly
or end up in free fall if the side is completely consumed. In addition, the negative shock
also increased the total quantities on both sides of the order book while
the positive shock had the opposite effect. Lower price is attributed to
more liquid market even though the global balance of assets is unaffected.
This is due to that the amount of assets the buyers can bid is limited by the
price while the amount of asset the sellers can sell are not.


\documentclass[]{article}
\usepackage{parskip}
\usepackage{amsmath}
\usepackage{enumitem}

\newcommand*\average[1]{\bar{#1}}

\begin{document}

%title
\begingroup
	\raggedright
	\Large Foundations of Analog and Digital Electronic Circuits\\
	\Large Exercise and Problems Solutions\\
	\vspace{3mm} %3 mm vertical space
	\normalsize Henrik Samuelsson\\
	\normalsize henrik.samuelsson@gmail.com
\endgroup

\section*{About}
	This is my personal solutions to exercises and problems from the book Foundations of Analog and Digital Electronic Circuits. A copy of the book is needed to fully understand the solutions since I will not include the full exercise instructions here. Exact version of the book is from 2005 and it has the ISBN number 978-1-55860-735-4.

	Very much appreciated if you contact me when you find errors in the solutions. My e-mail address can be found above this section.

\section*{Chapter 1}

\subsection*{Exercise 1.1}

	Then the power dissipated in a purely resistive load fed from an AC supply is given as

	\begin{equation*}
		P = \dfrac{ V^{2}_{rms} }{ R }
	\end{equation*}

	Rearrangement and insertion of known values gives the answer

	\begin{equation*}
		R = \dfrac{ V^{2}_{rms} }{ P } = \dfrac{ 120^{2} }{ 1200 } = 12 \Omega
	\end{equation*}

\subsection*{Exercise 1.2}

\begin{enumerate}[label=(\alph*)]
	\item The energy stored in a fully charged 50 A-hour 12-V battery is

	\begin{equation*}
		12 \cdot 50 \cdot 3600 = 2.16 MJ
	\end{equation*}

	\item The energy of water in a dam can be calculated by the following formula

	\begin{equation*}
		E =  m \cdot g \cdot h
	\end{equation*}

	We want to calculate the mass m, rearranging of the above formula gives

	\begin{equation*}
		m = \dfrac{E}{g \cdot h} = \dfrac{2.16 \cdot 10^6}{9.82 \cdot 30} = 7331 kg
	\end{equation*}

	This means that it takes 7 331 litres of water from a 30 meters high dam to charge the battery.
\end{enumerate}

\subsection*{Exercise 1.3}

The power dissipated in the resistor is given by

\begin{equation*}
	p =  \dfrac{ V _{DC} ^{2} }{ R }
\end{equation*}

\subsection*{Exercise 1.4}

\begin{enumerate}[label=(\alph*)]
	\item The average power dissipated in R is

	\begin{equation*}
		\average{p} =  { V _{rms} ^{2} }\dfrac{ 1 }{ R } = \left( \dfrac{ V _{AC} }{ \sqrt{2} }\right) ^2 \cdot \dfrac{ 1 }{ R }
	\end{equation*}

	\item
	\begin{equation*}
		V _{DC} = \dfrac{ V _{AC} }{ \sqrt{2} }
	\end{equation*}

\end{enumerate}

\end{document}


\subsection{Transfer}
\label{sec:20Transfer}

We continue with the notation and indices from the `\hyperref[sec:Mint]{Mint}' section.\\
\\
In the `Mint' section, we saw how Alice can create an `ERC-20 commitment' $Z_c$ within the Shield contract which:
\begin{itemize}
  \item hides an underlying value $c$, denominated in the currency of a particular ERC-20 contract; and
  \item hides and binds Alice as the owner of $Z_c$ (and hence of value $c$) through an ownership keypair $(sk_A^Z, pk_A^Z)$.
\end{itemize}
\ \\
Recall our privacy intentions:\\
Alice wishes to be able to transfer ownership of an ERC-20 tokens under zero-knowledge, so that the following become private:
	\begin{center}
		\begin{framed}
      \begin{enumerate}
        \item All details of the value being transacted.
        \item The identity of the sender of the value (`Alice').
        \item The identity of the receiver of the value.
      \end{enumerate}
    \end{framed}
  \end{center}

\noindent
Recall that minting a token commitment does not yet afford Alice any privacy (see the warning in Figure~\ref{fig:fMintWarning}). Only with subsequent transfers will the whereabouts of value $c$ and the amount Alice owns be hidden.\\
\\

Suppose Alice wishes to transfer a value $e$ to Bob under zero knowledge.\\
\\
First, Alice must ensure she has `minted' enough private token commitments which represent a value of at least $e$.
For convenience, suppose Alice has minted two private token commitments, representing ownership of values $c$ and $d$, where $c+d \geq e$. That is,
\begin{align*}
  Z_c := h(\;c\;|\;pk^Z_A\;|\;\sigma_c\;)\\
  Z_d := h(\;d\;|\;pk^Z_A\;|\;\sigma_d\;)\\
\end{align*}
Let $f$ be the balancing amount, so that $c+d = e+f$. In this example, we can think of $f$ as Alice's `change' when she pays Bob $e$.\\
\\
Note that a fungible commitment transfer in Nightfall always requires \textbf{two} `input' commitments and \textbf{two} `output' commitments. There are several reasons for this:
\begin{itemize}
  \item We're using zk-SNARKs to attest to proof of a `transfer' computation. Due to the way a computation (a set of constraints) is abstracted into a (proving key, verification key) pair, the computations cannot be dynamically sized. That is, the number of variables (public and private inputs) being passed into the computation must be of a fixed size. Further, only fixed-sized for-loops are possible within the computation.

  Therefore, if we wanted to allow different permutations of `number of inputs' and `number of outputs', we would need to perform a trusted setup for each permutation; store the verification key for each on-chain; and distribute each proving key.

  To avoid such complexity at this stage, we have chosen ``two inputs, two outputs'' for now.

  \item Having just one output would mean the sender would have to own a set of commitments which sum to exactly the amount required by the receiver (no more, no less). This is impractical for most use cases.
  \item Having just one input increases the likelihood of an observer inferring information from analysis of transactions.
\end{itemize}
\ \\

For Alice to transfer a value of $e$ (and receive $f$ as change) within the Shield contract, under zero knowledge, she follows the steps in Figure~\ref{fig:fTransferAlgorithm}:

\begin{figure}[htp]
  \ContinuedFloat*
	\begin{center}
		\begin{framed}
			\resizebox{0.85\textwidth}{!}{
      \begin{tabular}{p{16cm}}
        \textbf{Fungible transfer algorithm}
        \\
        \midrule
        \textbf{Bob's steps:}
        \begin{enumerate}
          \item Before Alice can send him anything, Bob must register his public keys $pk_B^Z$ and $pk_B^W$ against both his public Ethereum address $pk_B^E$ and his unique name `Bob' within the \hyperref[sec:pkd]{PKD}.
          \setcounter{ongoingEnumCounter}{\value{enumi}}
        \end{enumerate}
        \\ \midrule
        \textbf{Alice's steps:}
        \begin{enumerate}
          \setcounter{enumi}{\value{ongoingEnumCounter}}
          \item Generate new random salts $\sigma_e$ and $\sigma_f$.
          \item Lookup Bob's `zkp' public key $pk_B^Z$ from the PKD.
          \item Compute $Z_e := h(\;e\;|\;pk^Z_B\;|\;\sigma_e\;)$, a token commitment which represents value $e$, to be owned by Bob.
          \item Compute $Z_f := h(\;f\;|\;pk^Z_A\;|\;\sigma_f\;)$, a token commitment which represents value $f$, to be owned by Alice (as change).
          \item Compute $N_c := h(\;\sigma_c\;|\;sk^Z_A\;)$, the nullifier of Alice's commitment $Z_c$.
          \item Compute $N_d := h(\;\sigma_d\;|\;sk^Z_A\;)$, the nullifier of Alice's commitment $Z_d$.
          \item Get $\psi_{Z_c}$ -- the sister-path of $Z_c$ -- from the Shield contract (see Details below).
          \item Get $\psi_{Z_d}$ -- the sister-path of $Z_d$ -- from the Shield contract.
          \item Get the latest Merkle root from the Shield contract: $\roott_{n+m+k-1}$ (see Details below).
          \item Set public inputs $x = (\;N_c,\;N_d,\;Z_e,\;Z_f,\;\roott_{n+m+k-1})$
          \item Set private inputs $\omega = (\;c,\;d,\;e,\;f,\;\psi_{Z_c},\;\psi_{Z_d},\;sk_A,\;\sigma_c,\;\sigma_d,\;pk_B,\;\sigma_e,\;\sigma_f)$
          \item Select $C_{ft-transfer}(\;\omega,\;x\;)$ -- the set of constraints which are satisfied if and only if:
          \begin{enumerate}
            \item $pk_A$ equals $h(\;sk_A\;)$; (Proof of knowledge of the secret key to $pk_A$) (see Details for why $pk_A$ isn't an input to $C$)
            \item $Z_c$ equals $h(\;c\;|\;pk_A\;|\;\sigma_c\;)$ (Proof of the constituent values of $Z_c$)
            \item $Z_d$ equals $h(\;d\;|\;pk_A\;|\;\sigma_d\;)$ (Proof of the constituent values of $Z_d$)

            (See Details for why $Z_c$ and $Z_d$ aren't inputs to $C$)
            \item $\roott_{n+m+k-1}$ equals $h\br*{\psi_{Z_c}(1)\;|...|\;h\br*{\psi_{Z_c}(d-2)\;|\;h\br*{\psi_{Z_c}(d-1)\;|\;Z_c}\;}...}$ (Proof that $Z_c$ belongs to the on-chain Merkle Tree)
            \item $\roott_{n+m+k-1}$ equals $h\br*{\psi_{Z_d}(1)\;|...|\;h\br*{\psi_{Z_d}(d-2)\;|\;h\br*{\psi_{Z_d}(d-1)\;|\;Z_d}\;}...}$ (Proof that $Z_d$ belongs to the on-chain Merkle Tree)
            \item $N_c$ equals $h(\;\sigma_c\;|\;sk^Z_A\;)$ (Proof that $N_c$ is indeed the nullifier of $Z_c$)
            \item $N_d$ equals $h(\;\sigma_d\;|\;sk^Z_A\;)$ (Proof that $N_d$ is indeed the nullifier of $Z_d$)
            \item $Z_e$ equals $h(\;e\;|\;pk^Z_B\;|\;\sigma_e\;)$ (Proof that $Z_e$ hides value $e$)
            \item $Z_f$ equals $h(\;f\;|\;pk^Z_A\;|\;\sigma_e\;)$ (Proof that $Z_f$ hides value $f$)
            \item $c + d$ equals $e + f$.
            \item The two most significant bits of each of $c, d, e, f$ are both zero. This prevents the output values $e$ and $f$ from exceeding the maximum bit-lengths accepted by $C$ (and hence prevents us from creating two unspendable commitments).
          \end{enumerate}
          \item Generate $\pi := P(\;p_C\;,\;x,\;\omega\;)$; a proof of knowledge of satisfying arguments $(\omega, x)\;s.t.\;C(\omega, x) = 1$. Recall: $p_C$ -- the proving key for $C$ -- will be stored on Alice's computer.

          The pair $(\pi, x)$ is the zk-SNARK which attests to knowledge of private inputs $\omega$ without revealing them.
          \item Send $(\pi, x)$ to the Shield contract for verification.

          Using web3: \texttt{nfTokenShield.transfer(proof, inputs, vkId)}
          %remember where the count (enumi) is up to and store it in ongoingEnumCounter:
          \setcounter{ongoingEnumCounter}{\value{enumi}}
        \end{enumerate}
        \ \\
        \midrule
        ...
			\end{tabular}
		}
		\end{framed}
	\end{center}
\caption{Fungible Transfer Algorithm}
\label{fig:fTransferAlgorithm}
\end{figure}

%continue on next page
\begin{figure}[htp]
  \ContinuedFloat %to continue
	\begin{center}
		\begin{framed}
      \begin{tabular}{p{16cm}}
        \textbf{Shield contract's steps:}\\
        \begin{enumerate}
          %resume counter
          \setcounter{enumi}{\value{ongoingEnumCounter}}
          \item Verify the proof as correct: call a Verifier contract to verify the \texttt{(proof, inputs)} pair against the verification key represented by \texttt{vkId}.
          \setcounter{ongoingEnumCounter}{\value{enumi}}
        \end{enumerate}
        \ \\
        \midrule
        \textbf{Verifier contract's steps:}\\
        \begin{enumerate}
          \setcounter{enumi}{\value{ongoingEnumCounter}}
          \item Compute \texttt{result = verify(proof, inputs, vkId)}.

          I.e. Verify the \texttt{(proof, inputs)} pair against the verification key.
          \item Return \texttt{result}$\in$\texttt{\{false, true\}} to the Shield contract.
          \setcounter{ongoingEnumCounter}{\value{enumi}}
        \end{enumerate}
        \ \\
        \midrule
        \textbf{Shield contract's steps:}\\
        \begin{enumerate}
          \setcounter{enumi}{\value{ongoingEnumCounter}}
          \item If \texttt{result = false}, revert.
          \item Else:
          \begin{enumerate}
            \item Check $\roott_{n+m+k-1}$ is in $\rootsList$. (Revert if not).
            \item Check $N_c$ is not already in its list of `spent' nullifiers. (Revert if not).
            \item Check $N_d$ is not already in its list of `spent' nullifiers. (Revert if not).
            \item Add $Z_e$ to the next empty leaf of the Merkle Tree.
            \item Recalculate the path to the root of the Merkle Tree from $Z_e$ for future users.
            \item Add $Z_f$ to the next empty leaf of the Merkle Tree.
            \item Recalculate the path to the root of the Merkle Tree from $Z_f$ for future users.
            \item Append the newly calculated root $\roott_{n+m+k}$ to the ever-increasing array $\rootsList$
            \item Similarly append the nullifiers $N_c$ and $N_d$ to the ever-increasing array $\bm N$.
          \end{enumerate}
          \setcounter{ongoingEnumCounter}{\value{enumi}}
        \end{enumerate}
        \ \\
        \midrule
        \textbf{Alice's steps:}\\
        \begin{enumerate}
          \setcounter{enumi}{\value{ongoingEnumCounter}}
          \item Store relevant data in her local database, including the leaf-indices of $Z_e$ and $Z_f$.
          \item Send Bob important data privately via Whisper (using his public key $pk^W_B$):
          \begin{enumerate}
            \item The salt $\sigma_e$ of $Z_e$.
            \item The public key of Bob, $pk^Z_B$, used by Alice in the preimage of $Z_e$ (for completeness, so Bob can check the correctness of $Z_e$ himself).
            \item The value $e$.
            \item $Z_e$.
            \item The leaf-index of $Z_e$ within the on-chain Merkle Tree $M$ (so Bob can locate it).
          \end{enumerate}
          \setcounter{ongoingEnumCounter}{\value{enumi}}
        \end{enumerate}
        \ \\
        \midrule
        \textbf{Bob's steps:}\\
        \begin{enumerate}
          \setcounter{enumi}{\value{ongoingEnumCounter}}
          \item Check the correctness of the information provided by Alice:
          \begin{enumerate}
            \item Check $Z_e$ equals $h(\;e\;|\;pk^Z_B\;|\;\sigma_e\;)$
            \item Check that $Z_e$ is stored at the leafIndex of $M$ which Alice claimed.
          \end{enumerate}
          \item Store relevant data in his local database, including whether or not his `correctness checks' passed.
          \setcounter{ongoingEnumCounter}{0} %reset for next figure
        \end{enumerate}
			\end{tabular}
		\end{framed}
	\end{center}
\caption{Fungible Transfer Algorithm} %same caption as the first part of this figure
%\label{fig:fTransferAlgorithm} - no label in this second part of the figure
\end{figure}

\newpage
\subsubsection{Details}
\label{sec:721TransferDetails}

We refer to the numbered steps of Figure~\ref{fig:nfTransferAlgorithm}.

\textbf{Step $1$}
\ \\
This is handled at the time Bob creates an account through the \hyperref[sec:ui]{UI}.\\
\\

\textbf{Step $2$}
\ \\
This is handled within the \hyperref[sec:ui]{UI} microservice (or within the api-gateway).\\
\\

\textbf{Step $3$}
\ \\
This is handled within the api-gateway when a call is made by Alice to transfer to Bob.\\
\\

\textbf{Steps $4 - 7$}
\ \\
These steps are handled within \hyperref[sec:nf-token-controller]{\texttt{nf-token-controller.js}}.\\
\\

\textbf{Steps $8 - 10$}
\ \\
These calls to the Shield contract are handled within \hyperref[sec:nf-token-zkp]{\texttt{nf-token-zkp.js}}.\\
\\
It is important at this stage to note that there are an unknown number of other parties utilising the Shield contract.
Hence, the dynamic array of tokens $\bm{Z}$ might have grown since Alice appended her $Z_c$ as the $n^{th}$ leaf of $M$ (during the \hyperref[sec:20Mint]{Mint} explanation).\\
\\
Suppose $Z_c$ is located at the leaf-index $n$ of the merkle tree $M$ (and hence can also be denoted $Z_n$) and $Z_d$ is located at the leaf-index $n+m$ of the merkle tree $M$.\\
\\
Suppose there have been $k-1$ additional tokens added to $M$ since Alice added $Z_d$.
That is,\\
\begin{align*}
  \bm{Z}_{n+m+k-1} = (Z_0, Z_1,...,Z_{n-1}, Z_c, ..., Z_{n+m-1}, Z_d,..., Z_{n+m+k-1})
\end{align*}
We denote the corresponding Merkle Tree which holds tokens $\bm{Z}_{n+m+k-1}$ by $M_{n+m+k-1}$.
We denote its root by $\roott_{n+m+k-1}$; an element of $\rootsList = (\roott_0, \roott_1,...,\roott_{n+m+k-1})$.\\
\\

\begin{align*}
  \scalebox{0.9}{
    \begin{forest}
      [{$\roott_{n+m+k-1}:= h\br*{
                          h\br*{
                            h\br*{
                              h\br*{
                                Z_0,Z_1
                              },
                              ...
                            },
                            h\br*{
                              h\br*{
                                Z_{n-1},Z_c
                              },
                              h\br*{
                                ...,Z_{n+m-1}
                              }
                            }
                          },
                          h\br*{
                            h\br*{
                              h\br*{
                                Z_d, ...
                              },
                              h\br*{
                                Z_{n+m+k-1}, 0
                              }
                            },
                            0
                          }
                        }
                      $}
        [{$ h\br*{
              h\br*{
                h\br*{
                  Z_0,Z_1
                },
                ...
              },
              h\br*{
                h\br*{
                  Z_{n-1},Z_c
                },
                h\br*{
                  ...,Z_{n+m-1}
                }
              }
            }
          $}
          [{$ h\br*{
                h\br*{
                  Z_0,Z_1
                },
                ...
              }
            $}
            [{$ h\br*{
                  Z_0,Z_1
                }
              $}
              [{$Z_0$}][{$Z_1$}]
            ]
            [...
              [...][...]
            ]
          ]
          [{$ h\br*{
                h\br*{
                  Z_{n-1},Z_c
                },
                h\br*{
                  ...,Z_{n+m-1}
                }
              }
            $}
            [{$ h\br*{
                  Z_{n-1},Z_c
                }
              $}
              [{$Z_{n-1}$}][{$Z_c$}]
            ]
            [{$ h\br*{
                  ...,Z_{n+m-1}
                }
              $}
              [...][{$Z_{n+m-1}$}]
            ]
          ]
        ]
        [{$ h\br*{
              h\br*{
                h\br*{
                  Z_d, ...
                },
                h\br*{
                  Z_{n+m+k-1}, 0
                }
              },
              0
            }
          $}
          [{$ h\br*{
                h\br*{
                  Z_d, ...
                },
                h\br*{
                  Z_{n+m+k-1}, 0
                }
              }
            $}
            [{$ h\br*{
                  Z_d, ...
                }
              $}
              [{$Z_d$}][...]
            ]
            [{$ h\br*{
                  Z_{n+m+k-1}, 0
                }
              $}
              [{$Z_{n+m+k-1}$}][0]
            ]
          ]
          [0
            [0
              [0][0]
            ]
            [0
              [0][0]
            ]
          ]
        ]
      ]
    \end{forest}
  }
\end{align*}

Alice retrieves the value of the current Merkle root, $\roott_{n+m+k-1}$, from the Shield contract.\\
\\
Since she knows the index of $Z_c$ is $n$ within the leaves of $M_{n+m+k-1}$, Alice can also retrieve from $M_{n+m+k-1}$ the nodes of the path from the leaf $Z_n$ to the root $\roott_{n+m+k-1}$.
We denote this path:
\begin{align*}
  \phi_{Z_c} = [\phi_{Z_c}(d-1), \phi_{Z_c}(d-2),..., \phi_{Z_c}(1), \phi_{Z_c}(0)]
\end{align*}
Note that $\phi_{Z_c}(0) = \roott_{n+m+k-1}$.\\
\\
Alice also retrieve's the `sister-path' of this path:
\begin{align*}
  \psi_{Z_c} = [\psi_{Z_c}(d-1), \psi_{Z_c}(d-2),..., \psi_{Z_c}(1), \psi_{Z_c}(0)]
\end{align*}
where $\psi_{Z_c}(0) = \phi_{Z_c}(0) = \roott_{n+m+k-1}$.\\
\\
Similarly, Alice retrieves the path and sister-path $\phi_{Z_d}$ and $\psi_{Z_d}$.\\
\\
For ease of reading, let's focus only on the nodes of $M_{n+m-1}$ which Alice cares about for the purposes of transferring to Bob:

\begin{align*}
  \scalebox{0.9}{
    \begin{forest}
      [{$\roott_{n+m+k-1}:= \phi_{Z_c}(0) = \psi_{Z_c}(0) = \phi_{Z_d}(0) = \psi_{Z_d}(0)$}
        [{$\phi_{Z_c}(1) = \psi_{Z_d}(1)$}
          [{$\psi_{Z_c}(2)$}
            [...
              [...][...]
            ]
            [...
              [...][...]
            ]
          ]
          [{$\phi_{Z_c}(2)$}
            [{$\phi_{Z_c}(3)$}
              [{$\psi_{Z_c}(4)$}][{$Z_c$}]
            ]
            [{$\psi_{Z_c}(3)$}
              [...][...]
            ]
          ]
        ]
        [{$\phi_{Z_d}(1) = \psi_{Z_c}(1)$}
          [{$\phi_{Z_d}(2)$}
            [{$\phi_{Z_d}(3)$}
              [{$Z_d$}][{$\psi_{Z_d}(4)$}]
            ]
            [{$\psi_{Z_d}(3)$}
              [...][0]
            ]
          ]
          [{$\psi_{Z_d}(2)$}
            [0
              [0][0]
            ]
            [0
              [0][0]
            ]
          ]
        ]
      ]
    \end{forest}
  }
\end{align*}

\noindent
Equipped with $\psi_{Z_c}$ and $\psi_{Z_d}$, Alice can prove knowledge of leaves $Z_c$ and $Z_d$ in $M_{n+m+k-1}$ without revealing $Z_c$, $Z_d$, nor the paths $\phi_{Z_c}$, $\psi_{Z_c}$, $\phi_{Z_d}$, $\psi_{Z_d}$; all she needs to reveal is the root $\roott_{n+m+k-1}$ along with her proof.\\

\textbf{Steps $11 - 12$}
\ \\
These steps are handled within \hyperref[sec:f-token-controller]{\texttt{f-token-controller.js}}.\\
\\
As a reminder, we let:
\begin{center}
  \begin{tabular}{l l}
    $x = (N_c,\
          N_d,\
          Z_e,\
          Z_f,\
          \roott_{n+m+k-1})$ & Public Inputs used to generate the Proof\\
    $\bm\omega = (c, d, e, f,
              \psi_{Z_c},\
              \psi_{Z_d},\
              sk_A,\
              \sigma_c,\
              \sigma_d,\
              pk_B,\
              \sigma_e,\
              \sigma_f)$ & Private Inputs used to generate the Proof\\
  \end{tabular}
\end{center}
\ \\

\textbf{Steps $13 - 14$}
\ \\
These steps are handled within a \hyperref[sec:zokrates]{ZoKrates} container.\\
\\
Alice uses the $C_{ft-transfer}$ (or $C$) -- the set of constraints for a fungible transfer, located in \texttt{zkp/code/gm17/ft-transfer} (see \hyperref[sec:trustedSetup]{Trusted Setup}). $C_{ft-transfer}(\;\omega,\;x\;)$ returns a value of $true$ if Alice provides a set of valid `satisfying' arguments $(\omega, x)$ to $C$.\\
\\
Let's elaborate on each of the checks and calculations constraining the inputs to $C$ (we highlight public inputs in \textbf{bold} below):
\begin{enumerate}
  \item Calculate $h(sk_A) =: pk_A'$.\\
    Note that this newly calculated $pk_A'$ should equal $pk_A$ (Alice's public key), but we don't need to pass $pk_A$ as a private input and explicitly check that $pk_A'=pk_A$; a check on the correctness of $sk_A$ (and hence $pk_A'$) is implicitly achieved in the next four steps:
  \item Calculate $h(c\;|\;pk_A'\;|\;\sigma_c) =: Z_c'$.\\
  \item Calculate $h(d\;|\;pk_A'\;|\;\sigma_d) =: Z_d'$.\\
    Note again that these newly calculated $Z_c'$ and $Z_d'$ values should equal $Z_c$ and $Z_d$ respectively (Alice's token commitments). But we don't need to pass $Z_c$ and $Z_d$ as private inputs and explicitly check that $Z_c'=Z_c$ and $Z_d'=Z_d$; a check on the correctness of $Z_c'$ and $Z_d'$ is implicitly achieved in the next step:
  \item Check inputs $\psi_{Z_c}=[\psi_{Z_c}(d-1), \psi_{Z_c}(d-2),..., \psi_{Z_c}(1), \bm{\psi_{Z_c}(0)=\roott_{n+m+k-1}}]$ and the newly calculated $Z_c'$ satisfy:\\
    $h\br*{\psi_{Z_c}(1)\;|...|\;h\br*{\psi_{Z_c}(d-2)\;|\;h\br*{\psi_{Z_c}(d-1)\;|\;Z_c'}\;}...} = \roott_{n+m+k-1} ( =: \bm{\psi_{Z_c}(0)})$\\
    Given the one-way nature of our hashing function $h$, the only feasible way we could have arrived at the correct value of $\roott_{n+m+k-1}$ is if the sister-path $\psi_{Z_c}$ is correct, and if $Z_c'$ is correct, which (working backwards) must mean that $sk_A$ is correct.
  \item Check inputs $\psi_{Z_d}=[\psi_{Z_d}(d-1), \psi_{Z_d}(d-2),..., \psi_{Z_d}(1), \bm{\psi_{Z_d}(0)=\roott_{n+m+k-1}}]$ and the newly calculated $Z_d'$ satisfy:\\
    $h\br*{\psi_{Z_d}(1)\;|...|\;h\br*{\psi_{Z_d}(d-2)\;|\;h\br*{\psi_{Z_d}(d-1)\;|\;Z_d'}\;}...} = \roott_{n+m+k-1} ( =: \bm{\psi_{Z_d}(0)})$\\
    Given the one-way nature of our hashing function $h$, the only feasible way we could have arrived at the correct value of $\roott_{n+m+k-1}$ is if the sister-path $\psi_{Z_d}$ is correct, and if $Z_d'$ is correct, which (working backwards) must mean that $sk_A$ is correct.

    How does the circuit know the value of $\roott_{n+m+k-1}$ is correct? It doesn't; but it is a `public input', and we can rely upon the Shield smart contract to check the correctness of all public inputs.\\
  \\
  We've therefore shown in the steps so far, that:
  \begin{itemize}
    \item[--] Alice is the owner of two token commitments (because she knows their secret key)
    \item[--] Said token commitments are indeed leaves of the on-chain Merkle Tree $M_{n+m+k-1}$.
  \end{itemize}

  Alice commits to spending her tokens $Z_c$ and $Z_d$ in the next two steps:
  \item Check inputs $\sigma_c, sk_A, \bm{N_c}$ satisfy:
    $h(\sigma_c\;|\;sk_A) = \bm{N_c}$\\
    $N_c$ is referred to as a `nullifier' because it is understood by all participants to be an indisputable commitment to spend (`nullify') a token commitment. Remember that the token commitment being spent isn't revealed; the earlier steps have allowed Alice to demonstrate hidden knowledge of the secret key $sk_A$ of a token commitment which does indeed exist. By including $sk_A$ in the nullifier's preimage, Alice is binding herself as the executor of this transfer. By including $\sigma_c$, Alice is specifying a serial number which is unique to the token $Z_c$ (thereby distinguishing this nullifier from those which would nullify any other token commitments she may own).\\
  \item Check inputs $\sigma_d, sk_A, \bm{N_d}$ satisfy:
    $h(\sigma_d\;|\;sk_A) = \bm{N_d}$\\
  \item Check inputs $e, pk_B, \sigma_e, \bm{Z_e}$ satisfy:
    $h(e\;|\;pk_B\;|\;\sigma_e) = \bm{Z_B}$\\
    This step constrains a value of $e$ to be included in $Z_e$.
  \item Check inputs $f, \sigma_f, \bm{Z_f}$ and the calculated $pk_A'$ satisfy:
    $h(f\;|\;pk_A'\;|\;\sigma_f) = \bm{Z_f}$\\
    This step constrains a value of $f$ to be included in $Z_f$. Note that the default constraints for a fungible transfer in Nightfall force the second output token commitment to be returned to the sender as `change', as we're forcing $pk_A'$ to be a constituent of $Z_f$. It would be straightforward to make edits to allow this second token commitment to be transferred to anyone.
  \item Check that $c + d \bm{=} e + f$. We must constrain that no value is created or lost.
  \item Check that the most significant bit of each of $c, d, e, f$ is \textbf{zero}. This prevents either (or both) of $e$ and $f$ from exceeding the maximum bit-length of input values to $C$. If these bit-lengths were exceeded, then when if we were to attempt to transfer $Z_e$ and $Z_f$ in future, they would be rejected by $C$.

\end{enumerate}
Notice how each stage is linked to the last, and that at each of the `Check' stages, private inputs are being reconciled against at least one public input (highlighted in \textbf{bold} to help you notice). By structuring the circuit $C$ in this way, we are able to share only the public inputs with the Shield contract (along with a `proof' $\pi_{C,x,\omega}$). We'll see shortly that the Shield contract checks the correctness of each of the public inputs against its current states.\\
\\

\noindent
If all of the above constraints are satisfied by the public and private inputs, ZoKrates will generate the proof $\pi_{C,x,\omega}$; a proof of knowledge of satisfying arguments $(\omega, x) \ s.t. \ C(\omega, x) = 1$.\\
\\

\textbf{Step $15$}
\ \\
This transaction is handled within \hyperref[sec:f-token-zkp]{\texttt{f-token-zkp.js}}.\\
\\
Having generated $\pi_{C,x,\omega}$, Alice then sends the following to the Shield contract from her anonymous Ethereum address $\Xi_{A,1}$:
\begin{align*}
  &\pi_{C,x,\omega}\\
  &x = (\;N_c,\;N_d,\;Z_e,\;Z_f,\;\roott_{n+m+k-1})
\end{align*}
\\
Recall that everyone knows the checks and calculations which have been performed in the circuit $C_{ft-transfer}$, because it is a public file in the Nightfall repository. Further, everyone knows the verification key $vk_C$ which uniquely represents this circuit, because it has been publicly stored in the Verifier Registry contract. Therefore, when this anonymous caller (Alice) shares the pair $(x, \pi_{C,x,\omega})$, and the `unique id' of the relevant verification key $vk_C$; everyone will interpret this information as the caller's intention to transfer, and everyone will be convinced that the caller knows the secret key which permits them to transfer ownership of a token commitment.\\
\\

\textbf{Steps $16 - 18$}
\ \\
The Verifier Registry contract already has stored within it the verification key $vk_C$.
It runs a verification function $V(vk_C, \pi_{C,x,\omega}, x)$.
\begin{align*}
  V: (vk_C, \pi_{C,x,\omega}, x) \to \{0,1\}
\end{align*}
where:
\[
    V=
\begin{cases}
    1,& \text{if } \pi_{C,x,\omega} \text{ and } x \text{ satisfy } vk_C\\
    0,& \text{otherwise}
\end{cases}
\]
\ \\

\textbf{Steps $19 - 20$}
\ \\
If the Verifier contract returns $1$ ($true$) (verified) to the Shield contract, then the Shield contract will be satisfied that Alice's proof and public inputs represent her commitment to relinquish ownership of two token commitments (which only Alice knows to be $Z_c$ and $Z_d$), and to transfer ownership of value to someone via the newly proposed token commitment $Z_e$ (whilst receiving `change' in the form of $Z_f$). If the Verifier contract returns $0$, then the transaction will revert.\\
\\
Let's suppose Alice's $(x, \pi_{C,x,\omega})$ pair is verified.\\
\\
Following verification of the proof, the Shield contract will do the following:
\begin{enumerate}
  \item Check $\roott_{n+m+k-1}$ is in $\rootsList$.\\
    (If not, the transfer will fail)
  \item Check $N_c$ is not already in the list of nullifiers, which we denote $\bm{N}$.\\
    (If $N_c$ is already in $\bm{N}$, the transfer will fail)
  \item Check $N_d$ is not already in the list of nullifiers, which we denote $\bm{N}$.\\
  (If $N_d$ is already in $\bm{N}$, the transfer will fail)
  \item Append the commitment $Z_e$ to the ever-increasing array of tokens, $\bm{Z}_{n+m+k}$, so that $\bm{Z}_{n+m+k}=(Z_0, Z_1, ... Z_{n-1}, Z_c, ..., Z_d,... Z_{n+m+k-1}, Z_e)$\\
  \item Recalculate a Merkle Root $\roott_{n+m+k}$ of $M_{n+m+k}$\\
    \\
  \item Append the commitment $Z_f$ to the ever-increasing array of tokens, $\bm{Z}_{n+m+k+1}$, so that $\bm{Z}_{n+m+k}=(Z_0, Z_1, ... Z_{n-1}, Z_c, ..., Z_d,... Z_{n+m+k-1}, Z_e, Z_f)$\\
  \item Recalculate a Merkle Root $\roott_{n+m+k+1}$ of $M_{n+m+k+1}$

    Note: The `recalculation' of the Merkle Root within the Shield contract only recalculates the hashes on the path from the newly added leaf to the root. We do not recalculate the entire Merkle Tree as that would require exponentially more computations. Hence, we need to perform this `recalculation' each time a new commitment is added as a leaf.

    \begin{align*}
      \scalebox{0.9}{
        \begin{forest}
          [{$\roott_{n+m+k+1}:= h\br*{
                                h\br*{
                                  h\br*{
                                    h\br*{
                                      Z_0,Z_1
                                    },
                                    ...
                                  },
                                  h\br*{
                                    h\br*{
                                      Z_{n-1},Z_c
                                    },
                                    h\br*{
                                      ...,Z_{n+m-1}
                                    }
                                  }
                                },
                                h\br*{
                                  h\br*{
                                    h\br*{
                                      Z_d, ...
                                    },
                                    h\br*{
                                      Z_{n+m+k-1}, Z_e
                                    }
                                  },
                                  h\br*{
                                    h\br*{
                                      Z_f, 0
                                    },
                                    0
                                  }
                                }
                              }
                            $}
            [{$ h\br*{
                  h\br*{
                    h\br*{
                      Z_0,Z_1
                    },
                    ...
                  },
                  h\br*{
                    h\br*{
                      Z_{n-1},Z_c
                    },
                    h\br*{
                      ...,Z_{n+m-1}
                    }
                  }
                }
              $}
              [{$ h\br*{
                    h\br*{
                      Z_0,Z_1
                    },
                    ...
                  }
                $}
                [{$ h\br*{
                      Z_0,Z_1
                    }
                  $}
                  [{$Z_0$}][{$Z_1$}]
                ]
                [...
                  [...][...]
                ]
              ]
              [{$ h\br*{
                    h\br*{
                      Z_{n-1},Z_c
                    },
                    h\br*{
                      ...,Z_{n+m-1}
                    }
                  }
                $}
                [{$ h\br*{
                      Z_{n-1},Z_c
                    }
                  $}
                  [{$Z_{n-1}$}][{$Z_c$}]
                ]
                [{$ h\br*{
                      ...,Z_{n+m-1}
                    }
                  $}
                  [...][{$Z_{n+m-1}$}]
                ]
              ]
            ]
            [{$ h\br*{
                  h\br*{
                    h\br*{
                      Z_d, ...
                    },
                    h\br*{
                      Z_{n+m+k-1}, Z_e
                    }
                  },
                  h\br*{
                    h\br*{
                      Z_f, 0
                    },
                    0
                  }
                }
              $}
              [{$ h\br*{
                    h\br*{
                      Z_d, ...
                    },
                    h\br*{
                      Z_{n+m+k-1}, Z_e
                    }
                  }
                $}
                [{$ h\br*{
                      Z_d, ...
                    }
                  $}
                  [{$Z_d$}][...]
                ]
                [{$ h\br*{
                      Z_{n+m+k-1}, Z_e
                    }
                  $}
                  [{$Z_{n+m+k-1}$}][{$Z_e$}]
                ]
              ]
              [{$ h\br*{
                    h\br*{
                      Z_f, 0
                    },
                    0
                  }
                $}
                [{$ h\br*{
                      Z_f, 0
                    }
                  $}
                  [{$Z_f$}][0]
                ]
                [0
                  [0][0]
                ]
              ]
            ]
          ]
        \end{forest}
      }
    \end{align*}

  \item Append $\roott_{n+m+k+1}$ to the ever-increasing array $\rootsList$
  \item Similarly append the nullifiers $N_c$ and $N_d$ to the ever-increasing array $\bm N$.
\end{enumerate}

\textbf{Steps $21 - 22$}
\ \\
Nightfall uses web3.shh to use Whisper. Bob's logged-in application will listen for all Whisper messages, and will try to decrypt all messages with his private whisper key $sk^W_B$. If decryption is successful, the data will be stored in the relevant database on Bob's local machine.\\
\\
\hyperref[sec:f-token-zkp]{\texttt{ft-token-zkp.js}} includes functions to cross-reference the data Bob has received from Alice against the data stored in the Shield contract.\\
\ \\
Bob will store all important information in his private database.


\documentclass[12pt]{article}
\usepackage[utf8]{inputenc}	% Para caracteres en español
\usepackage{amsmath,amsthm,amsfonts,amssymb,amscd}
\usepackage{multirow,booktabs}
\usepackage[table]{xcolor}
\usepackage{fullpage}
\usepackage{lastpage}
\usepackage{enumitem}
\usepackage{fancyhdr}
\usepackage{mathrsfs}
\usepackage{wrapfig}
\usepackage{graphicx}
\usepackage{caption}
\usepackage{subcaption}
\usepackage{setspace}
\usepackage{calc}
\usepackage{multicol}
\usepackage{cancel}
\usepackage[T1]{fontenc}
%\usepackage[retainorgcmds]{IEEEtrantools}
\usepackage[margin=3cm]{geometry}
\usepackage{amsmath}
\newlength{\tabcont}
\setlength{\parindent}{0.0in}
\setlength{\parskip}{0.05in}
\usepackage{empheq}
\usepackage{framed}
\usepackage[most]{tcolorbox}
\usepackage{xcolor}
\colorlet{shadecolor}{orange!15}
\parindent 0in
\parskip 12pt
\usepackage[T1]{fontenc}

 \renewcommand{\familydefault}{\sfdefault}
\geometry{margin=1in, headsep=0.25in}
\theoremstyle{definition}

\usepackage{graphicx}
\usepackage{hyperref}
\hypersetup{
	colorlinks=true,
	linkcolor=blue,
	filecolor=magenta,
	urlcolor=cyan,
}

\begin{document}
\title{
	Assignment 1}

\author{Ethan Holleman}
\maketitle

\section{Part 1}

\subsection{Definitions}

\begin{itemize}
	\item $i$: Index over nucleotide (input) sequences.
	\item $P$: Length of motif to consider in the model.
	\item $j$: Indexes over start positions of all possible motifs in a given sequence $i$ of length $L$ assuming all sequences have length $L$. $0 \leq j \leq L - P+1$
	\item $m$: Indexes of each nucleotide of motif $j$ of sequence $i$. $0 \leq m \leq P$.
	\item $l$: Indexes over models where 1 indicates model corresponding to transcription factor binding motif (foreground) and 0 indicates non-binding region (background).
	\item $k$: Indexes over nucleotides (A, T, G, C).
	\item $X_{i,j,m,k}$: Indicator variable in which $X_{i,j,m,k}=1$ if base $m$ of the motif beginning at position $j$ of sequence $i$ is equal to nucleotide $k$ and is 0 otherwise.
	\item $C_{i}$: Vector of motif start positions for each sequence $i$. If $C_{i} = j$ then then motif $j$ is the transcription factor binding site.
	\subitem We use the indicator variable $C_{i,j}=1$ to represent when $C_{i} = j$.
	\item $P(C_{i,j} = l) = \lambda_{j}$ and $0 \leq \lambda_{j} \leq 1$.
	\item $P(X_{i,j,m,k}=l | C_{i,j}=l) = \psi_{k, m}^{(l)}$ where $\sum_{k}\psi^{(l)}_{k ,m}=1$
	\item $\boldsymbol{X}$: The set of all $X_{i,j,m,k}$.
	\item $\boldsymbol{C}$: The set of all $C_{i}$.
	\item The set of all model parameters is denoted as $\boldsymbol{\theta} = \{\lambda_{j}, \psi^{(l)}_{k ,m}\}$
\end{itemize}

\subsection{Complete log likelihood}

\begin{equation}
	Q(\theta | \boldsymbol{X}, \boldsymbol{C}) = \textrm{log}(P(\boldsymbol{X}, \boldsymbol{C} | \theta))
\end{equation}

\begin{equation}
	= \textrm{log} \prod_{i}\prod_{j}P(X_{i,j}, C_{i,j} | \theta)
\end{equation}

\begin{equation}
	= \textrm{log}\prod_{i}\prod_{j} (\prod_{m}\prod_{k}\prod_{l}[P(X_{i,j,m,k}=1 | C_{i, j}=l, \theta)P(C_{i, j} = l | \theta)]^{X_{i,j,m,k} C_{i, j}})
\end{equation}

\begin{equation}
= \textrm{log} \prod_{i} \prod_{j} (\prod_{m} \prod_{k}\prod_{l}[\lambda_{j} \psi_{k, m}^{(l)}])^{X_{i,j,m,k} C_{i, j}}
\end{equation}

\begin{equation}
	=\sum_{i} \sum_{j} \sum_{m} \sum_{k} \sum_{l} X_{i,j,m,k} C_{i,j} \textrm{log}[\psi_{k, m}^{(l)}]
\end{equation}

\begin{equation}
=\sum_{i} \sum_{j} \sum_{m} \sum_{k} \sum_{l} X_{i,j,m,k} C_{i,j} \textrm{log}[\psi_{k, m}^{(l)}]
\end{equation}

\begin{equation}
=\sum_{i} \sum_{j} \sum_{m} \sum_{k} \sum_{l} X_{i,j,m,k} C_{i,j} \textrm{log} \lambda_{j} + \sum_{i} \sum_{j} \sum_{m} \sum_{k} \sum_{l} X_{i,j,m,k} C_{i,j} \textrm{log} \psi_{k, m}^{(l)}
\end{equation}

\end{document}


In this section, we develop a technique for probabilistic transient power and
temperature analysis of electronic systems using the uncertainty-unaware
approach presented in \sref{transient-solution} combined with the machinery
described in \sref{chaos-uncertainty-analysis}. Our goal is to obtain a
technique that preserves the gradual solution process that is at the heart of
transient analysis; see \sref{transient-analysis}. In this way, the designer
retains fine control over transient calculations.

\subsection{\problemtitle}

As stated in \sref{chaos-uncertainty-analysis}, the designer is supposed to
decide on the system model that produces the quantity of interest. Assuming the
general system and temperature models given in \sref{system-model} and
\sref{temperature-model}, respectively, the only component that is left to
define is the power model, since it is what introduces the actual workload into
the system. Denote the power model by
\begin{equation} \elab{chaos-power-model}
  \vp = \f(i, \vq, \vu)
\end{equation}
where $\f: \natural[+] \times \real^\np \times \real^\nu \to \real^\np$ is a
function that evaluates the power consumption $\vp \in \real^\np$ of the
processing elements at time step~$i$ given their heat dissipation $\vq \in
\real^\np$ and an assignment of the uncertain parameters $\vu \in \real^\nu$.

\begin{remark}
It should be understood that \vp, \vq, and \vu are random vectors in general,
and that \f consumes $\vq(\omega)$ and $\vu(\omega)$ and yields $\vp(\omega)$
for some particular outcome $\omega \in \Omega$. The function \f \perse is
purely deterministic.
\end{remark}

The designer can choose any \f. For instance, it can be a closed-form formula or
a piece of code. The only assumption we make is that \f is smooth in \vz and,
when viewed as a random variable, belongs to $\L{2}{\Omega, \F, \probability}$
(see \xref{probability-theory}), which is generally applicable to most physical
systems \cite{xiu2010}. The definition of \f is flexible enough to account for
such phenomena as the interdependence between power and temperature discussed in
\sref{power-model}.

Our solution to transient analysis under process variation is based on the one
presented in \sref{transient-solution}. The major difference is that
\eref{temperature-model} implicitly operates on stochastic quantities in the
context of this chapter. Consequently, the recurrent solution in
\eref{transient-recurrence}, that is,
\begin{equation} \elab{chaos-recurrence-original}
  \vs_i = \m{E} \vs_{i - 1} + \m{F} \vp_i
\end{equation}
for $i = \range{1}{\ns}$, is stochastic as well. In the deterministic case, it
can be readily employed in order to perform transient power and temperature
analysis. In the probabilistic case, however, the situation is substantially
different, since $\vp_i$ and hence $\vs_i$ and $\vq_i$ are stochastic
quantities. Moreover, at each step, $\vp_i$ is an arbitrary transformation of
the uncertain parameters \vu and stochastic temperature $\vq_i$, which results
in a random vector with a generally unknown probability distribution.
Furthermore, $\vp_i$, $\vq_i$, $\vs_i$, and \vu are dependent random vectors,
since the first three are functions of the last one. Therefore, the operations
in \eref{chaos-recurrence-original} are to be performed on dependent random
vectors with arbitrary distributions, which, in general, have no closed-form
solutions.

Let us now summarize Stage~1 in \fref{chaos-overview}. In this section, the
quantity of interest \g is the transient power and temperature
profiles---denoted by \mp and \mq, respectively---that correspond to the
workload specified by \f as shown in \eref{chaos-power-model}. Regarding the
uncertain parameters \vu, they are left unspecified, since the construction
below is general with respect to \vu; however, a concrete scenario will be
considered in the next section, \sref{chaos-transient-application}. We now
proceed directly to Stage~3, as Stage~2 requires no additional attention in this
case.

\subsection{Surrogate Construction}

The goal now is to transform the recurrence in \eref{chaos-recurrence-original}
in such a way that the distributions of power and temperature can be efficiently
estimated. Based on the methodology presented in
\sref{chaos-uncertainty-analysis}, we construct a \ac{PC} expansion of \f so
that it can then be propagated through the recurrence in
\eref{chaos-recurrence-original} in order to obtain a \ac{PC} expansion of power
and a \ac{PC} expansion of temperature.

The expansion of $\vp_i$, which is required in \eref{chaos-recurrence-original}
and computed via \f shown in \eref{chaos-power-model}, is as follows:
\[
  \chaos{\nz}{\lc}{\vp_i} = \sum_{\vj \in \sparseindex{\nz}{\lc}} \hat{\vp}_{i \vj} \psi_{\vj}
\]
where $\set{\psi_{\vj}}{\real^\nz \to \real}$ are the basis polynomials,
$\set{\hat{\vp}_{i \vj}} \subset \real^\np$ are the corresponding coefficients,
and the index set $\sparseindex{\nz}{\lc}$ is the one given in
\eref{index-total-order-anisotropic}. In addition,
\rref{chaos-multidimensional-output} is worth recalling. It can be seen in
\eref{chaos-recurrence-original} that, due to the linearity of the operations
involved in the recurrence, $\vs_i$ attains such a \ac{PC} expansion that has
the same structure as the expansion of $\vp_i$. The recurrence in
\eref{chaos-recurrence-original} can then be rewritten as follows:
\[
  \chaos{\nz}{\lc}{\vs_i} = \m{E} \, \chaos{\nz}{\lc}{\vs_{i - 1}} + \m{F} \, \chaos{\nz}{\lc}{\vp_i}
\]
for $i = \range{1}{\ns}$. Consequently, there are two interwoven \ac{PC}
expansions: one is for power, and the other for temperature. The two expansions
have the same polynomial basis but different coefficients. In order to
understand the structure of the above formula better, let us spell it out as
\[
  \sum_{\vj \in \sparseindex{\nz}{\lc}} \hat{\vs}_{i \vj} \psi_{\vj} =
  \sum_{\vj \in \sparseindex{\nz}{\lc}} \left(\m{E} \hat{\vs}_{i - 1, \vj} + \m{F} \hat{\vp}_{i \vj}\right) \psi_{\vj}.
\]
Making use of the orthogonality property, which can be seen in
\eref{chaos-orthogonality}, we obtain the following recurrence:
\begin{equation} \elab{chaos-recurrence}
  \hat{\vs}_{i \vj} = \m{E} \hat{\vs}_{i - 1, \vj} + \m{F} \hat{\vp}_{i \vj}
\end{equation}
for $i = \range{1}{\ns}$ and $\vj \in \sparseindex{\nz}{\lc}$. The coefficients
$\set{\hat{\vp}_{i \vj}}$ needed in this recurrence are found using a suitable
quadrature $\quadrature{\nz}{\lq}$ (see \xref{numerical-integration}) as
follows:
\[
  \hat{\vp}_{i \vj} = \quadrature{\nz}{\lq}{\vp_i \psi_{\vj}}
\]
for $i = \range{1}{\ns}$ and $\vj \in \sparseindex{\nz}{\lc}$ where the
operation is elementwise, and it can be efficiently performed by virtue of the
projection matrix in \eref{chaos-projection-matrix}.

The final step of the construction process is to combine \eref{chaos-recurrence}
with \eref{temperature-algebraic} in order to obtain the coefficients of the
\ac{PC} expansion of the temperature vector $\vq_i$. Note that, since power
depends on temperature, which is discussed in \sref{power-model}, at each step
of the recurrence in \eref{chaos-recurrence}, the computation of $\hat{\vp}_{i
\vj}$ via \f should be done with respect to the expansion of $\vq_{i - 1}$.

The construction process of the stochastic power and temperature profiles is
estimated to have the following time complexity per time step:
\[
  \bigo{n_n^2 \nc + \nn \np \nq \nc + \nq \f(\np)}
\]
where \nn, \np, \nc, and \nq are the number of thermal nodes, processing
elements, polynomial terms, and quadrature points, respectively; and $\f(\np)$
denotes the contribution of the power model shown in \eref{chaos-power-model}.
The expression can be detailed further by expanding \nc and \nq. Assuming the
isotropic total-order index set in \eref{index-total-order-isotropic}, \nc can
be calculated as shown in \eref{index-total-order-isotropic-length}. This
formula behaves as $\nz^\lc / \lc!$ in the limit with respect to \nz. Regarding
\nq, for quadratures based on the full tensor product given in
\eref{quadrature-tensor}, $\log(\nq) \propto \nz$, which means that the
dependency of \nq on \nz is exponential.

It can be seen that the theory of \ac{PC} expansions suffers from the curse of
dimensionality \cite{eldred2008, xiu2010}: when \nz increases, the number of
polynomial terms as well as the complexity of the corresponding coefficients
exhibit growth, which is exponential without special treatments. The problem
does not have a general solution and is one of the central topics of many
ongoing studies.

We mitigate the curse of dimensionality by \one~keeping the number of stochastic
dimensions low via model order reduction, which is a part of $\transform$ shown
in \eref{chaos-transformation} and is based on the \ac{KL} decomposition
described in \xref{probability-transformation}, and \two~utilizing efficient
construction techniques, which is discussed in \sref{chaos-construction} and
\xref{numerical-integration}. For instance, in the case of isotropic integration
grids based on the Smolyak algorithm and Gaussian quadratures, $\log(\nq)
\propto \log(\nz)$, which means that the dependency of \nq on \nz is only
polynomial \cite{heiss2008}. Anisotropic constructions allow for further
reduction.

Let us summarize Stage~3 in \fref{chaos-overview}. Recall the stochastic
recurrence in \eref{chaos-recurrence-original} where, in the presence of
dependencies, an arbitrary function $\vp_i$ (since it is based on \f as shown
\eref{chaos-power-model}) of the stochastic temperature $\vq_i$ and the
uncertain parameters \vu needs to be evaluated and combined with the random
vector $\vs_i$. This recurrence has been replaced with a purely deterministic
one in \eref{chaos-recurrence}. More generally, the whole system, including the
temperature model in \eref{temperature-model-original}, has been substituted
with a lightweight surrogate defined by a set of polynomials $\set{\psi_{\vj}}$,
a set of coefficients $\set{\hat{\vp}_{i \vj}}$ for power, and a set of
coefficient $\set{\hat{\vq}_{i \vj}}$ for temperature. These quantities
constitute the desired stochastic power and temperature profiles, and these
profiles are ready to be analyzed at each step of the process as described in
\sref{chaos-processing}.

Before we proceed, let us draw attention to the ease and generality of taking
process variation into consideration using the proposed approach. The
description given above is delivered from any explicit formula of any particular
process parameter. In contrast, the solutions from the literature related to
process variation are typically based on ad~hoc expressions and should be
individually tailored by the designer to each new parameter; see, for instance,
\cite{ghanta2006, bhardwaj2008, huang2009a}. The proposed framework provides
great flexibility in this regard.