\documentclass[11pt, oneside]{article}
\usepackage{indentfirst, hyperref, geometry, amsmath, amssymb, algorithm}
\usepackage[noend]{algpseudocode}
\usepackage[cache=false]{minted}
\geometry{a4paper}

\hypersetup{
    colorlinks=true,
    urlcolor=cyan
}

\title{Various Computational Cube Theory Conjectures}
\author{Stephen Huan}

\begin{document}
\maketitle

\section{Basics}
\subsection{What This Is}

This lecture will not directly make you faster. Nor is it really about Rubik's cubes.
Instead, it is about general computer algorithms that currently exist and I postulate will exist.
If you appreciate listening to someone talk about cubes, I encourage you to write your own lectures
and make Rubik's Cube Club great again. In the words of Jayden McNeill, ``Don't be a cubing intellectual''.

\subsection{Representation}

At first, I imagined doing a sticker-wise face respentation. That is, an array of shape 6x3x3.
The first dimention represents the face (there are 6 faces on a cube). Note that I specify a face by color in
WCA orientation (white top green front) and colors by their first letter (they are distinct); the ordering is WGRBOY: a counterclockwise-esque rotation pattern. Then, for each face, there are 9 stickers. I then subdivided these 9 stickers
into 3 rows of 3. The problem is that simulating a turn becomes too unweildy. A single move will shift 12 stickers along its axis, which are hard to keep track of, and shifts 9 stickers which are easier to cycle. In total 21 stickers move, and it's hard to generalize for the 6 possible moves.

An obvious alternative I realized when reading \href{https://github.com/hkociemba/RubiksCube-TwophaseSolver}{Kociemba's GitHub} is a cubie-level representation, which simplifies moving.
In my implentation a cubie contains 3 ordered colors.
Cubie(W, B, O) means the white is either up/down (U/D), the blue is front/back (F/B), and the orange is left/right (L/R).
In general, I also refer to moves by the equivalent face they are done to.
The ordering is a representation of the concept of ``orientation''.
The logic is the same for edge pieces. For example, Cubie(W, B, None) is a valid edge.
The white center would be Cubie(W, None, None) and the even core of the cube would be Cubie(None, None, None).

As you can see the same class can represent each piece type. Now let's simulate a move. First, track a corner; in this case the WBO corner.
When you turn the U layer the W remain facing U/D, but the O faces F/B and the B faces L/R. Now track the WGR corner as I do a R move.
R remains facing L/R, but W now faces F/B and G faces U/D. Suppose U/D is 0, F/B is 1, and L/R is 2. A move will not affect its corresponding color, and will swap the two remaining colors.

\begin{minted}{python}
def rotate(self, dir):
    i, j = {0, 1, 2} - {dir}
    self.colors[i], self.colors[j] = self.colors[j], self.colors[i]
\end{minted}

Now that I know how moves affect cubies, I just need to move the cubie objects themselves. First of all, I will make an array to hold cubie objects,
this time in layers. I started with the top layer, going from left to right, top to bottom.
This array has shape 6x9, as I felt it was no longer necessary to subdivide further into rows.
To do a move, get the layer it corresponds to. Then, cycle the corners and cycle the edges.
Finally, apply the rotation algorithm shown above on each piece in the layer.
Note that when I ``get'' a layer I return indices, not the objects themselves. I need to modify the array, and since Python doesn't have pointers
only indicies will do. Getting these indices is remarkably easy.

Here is my cycle algorithm. Note that it is extremely general, as I might change the dimentionality in the future.
\begin{minted}{python}
def cycle(l, indexes):
    start = access(l, indexes[-1])
    for i in range(len(indexes) - 1, 0, -1):
        modify(l, indexes[i], access(l, indexes[i - 1]))
    modify(l, indexes[0], start)
\end{minted}

Finally, here is how I perfrom a move. Note that CWC and CWE are lists of indices specifying the order.
\begin{minted}{python}
def move(self, dir):
      layer = self.get_layer(dir)

      cycle(self.cube, get(layer, CWC))
      cycle(self.cube, get(layer, CWE))

      for cubie in layer: access(self.cube, cubie).rotate(ORIENT[dir])
\end{minted}

Some details: I specify color using numeric codes, because:
\begin{enumerate}
  \item The color ordering is now WYGBRO.
  \item The opposite color to a given color \( c \) is \( 5 - c \), like dice.
  \item The orientation of a move is \( j//2 \), where \( j \) is the index of the move in the ordering.
\end{enumerate}

Of course, you could use strings or whatever to your liking. It doesn't really matter.

\subsection{Commentary}

Evidently, a cubie level approach is superior to a sticker level approach.
I have some intuition as to why.
\begin{itemize}
  \item Traditional speedsolving methods emphasize blockbuilding and a piece level approach.
  We like to make fun of beginners for saying ``I can only solve a face'', as it shows a fundamental
  näivety with the geometry of the puzzle.
  \item In general, the more abstract something is, the easier it is to manipulate.
\end{itemize}

If you look at the structure of my code, avaiable \href{https://github.com/stephen-huan/Cube-Solver}{here}
you'll realize I like named constants, small, modular, functions, and headers.
I call this ``AI style''. I do not write production code. As such, I think this format is good enough
for a beginner playing around at programming. As a side note, you, the reader, should take AI.
It is by far the greatest class TJ has offered me in these two long and stressful years and has provided
a foundation that will last me the rest of my career. This lecrure would not be possible otherwise.

\section{High Level Algorithmic Overview}

\subsection{Problem Structure}
Given a cube state, the problem is to find the shortest move sequence such that the cube is solved after the sequence.
That is, I want to solve a cube in the fewest moves possible.
This problem is a graph problem. The vertices are states of the cubes, and the edges are possible moves.
Obviously this graph has cycles, but we can prune those out. Now, this is a single-source-shortest path problem,
on an undirected graph.

\subsection{Uninformed Searches}

\subsubsection{BFS}
Imagine copying the cube 18 times and then applying U to one of the copies,
R to another, etc. until I have 18 distinct cubes. Then for each of those cubes, I do the same thing.
If I enumerate every single possibility, I will of course find the shortest solution.
This algorithm is called breadth-first-search or ``BFS'' and it has the computational complexity of \( O(|V| + |E|)\)
as in the worse case I visit each vertex and each edge exactly once.
In this case, since, the graph is a tree, \( |E| = |V| - 1\). Therefore the complexity is \( O(|V| + |V| - 1)\) = \( O(|V|) \).

That seems pretty good, as it's linear in \( |V| \).
Unfortunately, the number of vertices grows at an exponential rate. It's more accurate to say the complexity is \( O(b^d) \),
where \( b \) is the branching factor, the number of moves at each depth, and \( d \) is the depth.

If I'm in half turn metric (HTM) then there are 15 (6*3, but minus 3 since it doesn't make sense to do a move and then a move on the same face)
possible moves at each step. God's number is 20, so in the worst case I'd have to search \( 15^{20} \) states (approximately \(3.3 \cdot 10^{25} \) states)
which is way too large. Clearly, I need a faster algorithm.

\subsubsection{Bi-BFS}
A simple, but enormously effective optimization. Do a BFS, but from start to goal and goal to start simultaneously and symmetrically.
When the two searchs meet in the middle, just combine the two paths. Intuitively, two small trees will halt
the exponential growth in half. When I solve mazes, I'll jump from end to end and try to combine the two.
The new complexity is \( O(b^{d/2}) = O(\sqrt{b^d}) \), doubling my effective search depth.

Some subtleties in implementation: adding children to seen is much faster, but don't goal test on children.
My implementation is extremely slow though: it takes 30 seconds to find the optimal 9 HTM U-perm.

\subsubsection{IDDFS}
Essentially the same thing as BFS but uses less memory. Since DFS goes straight down, only the path from start to current node needs to be stored.
Therefore, the memory consumption is \( O(d) \). The trade off is time, as iterative deepening means running DFS to depth 0, then 1, then 2, etc.
until depth \( d \). The complexity is \( O(1 + b^1 + b^2 + b^3 + ... + b^d) \).
Using geometric series this sums to \( \frac{b^{d + 1} - 1}{b - 1} = \lim_{b \to \infty} b^d\), because of the definition of big-O (asymptotic).

An addded benefit is it avoids the copying cost, which is a nontrival factor (\#1 in total time when profiled).
Instead of copying a cube object to generate children, just stick with one cube object and perform a single move when going down,
and doing a single inverse move when going back up. With a BFS, I would need to apply multiple inverse moves,
making it slightly slower than just copying.

A comparision of all the algorithms discussed so far:

\begin{tabular} {| c | c | c | c | c |}
  \multicolumn{5}{c}{Algorithms} \\ \cline{2-5}
  \multicolumn{1}{c |}{} & BFS & Bi-BFS & IDDFS & Bi-IDDFS \\ \hline
  Time & \( O(b^d) \) & \( O(b^{d/2}) \) & \( O(b^d) \) & \( O(b^{d/2}) \) \\ \hline
  Space & \(O(b^d) \) & \(O(b^{d/2}) \) & \( O(d) \) & \( O(d) \) \\ \hline
\end{tabular}

\subsection{Informed Searches}
We can do better. If I take advantage of a prediction of how far away a given state is to the goal, then the search is faster.
The general algorithm for this is called A*, and even though it uses a heuristic, the search will return an optimal path if
the heuristic is admissible. Optimality proof TBD.

\section{What Exists}
The undisputed best algorithm for solving 3x3 is, of course, \href{http://kociemba.org/cube.htm}{Kociemba's algorithm}.
It works by some horrendously complicated two-phase group reduction math stuff. A ``group'', as I understand it,
is a subset of cube states able to be solved by a subset of moves. \\

Drawbacks:
\begin{itemize}
  \item Not generalizable: 4x4+ group reduction would be intractable (necessary to do slice moves)
  \item Fundamentally a search algorithm: Stockfish was made a decade ago.
  \item Takes \textasciitilde 12 seconds to solve a cube optimally.
\end{itemize}

\section{The Future}
Now, there exists machine learning.
ML traditionally deals with vectors, so I propose one-hot encoding colors and then flattening into a linear order,
sticker by sticker face by face. The resulting dimentionality would be 6*9*6 = 324x1. The reason I don't use numberical color codes
is because that causes numerically similar colors to be literally closer to each other, which is something I don't want. Therefore,
I make the colors orthongonal to each other.

\subsection{Pure Prediction}

The most direct approach would be to have a neural network (NN) or convolutional neural network (CNN) directly predict the next move
given a cube state. The problem would be probable difficulty in extracting a viable feature space and I have no idea how good this would actually be.
Also, there'd be no way to verify optimality on a input that hadn't been solved before.

\subsection{Boosting A*}

I mentioned earlier that A* required an admissible heuristic. The deterimination of such a function is nontrivial and NNs could simulate a heuristic.
The problem would be the lack of guarentee of admissibility, which is solved by the following approach.
First off, add a regularization factor in loss to penalize overestimation more than underestimating.
This by itself does not guarentee admissibility, thought it encourages it. Suppose the heuristic is \( y' \) and the actual distance is \( y \).
I want a function \( f \) such that \( \forall y' f(y') \leq y' \) and \( f(y') < y \). That is, if a function satisfies both conditions, then it must be admissible.
A ``trivial'' function that accomplishes this is  \( f(y') = y' - e \), where \( e \) is \( \max_{\forall y'} y' - y \).
However, this linear ``force'' layer may be too aggressive, as I want the heuristic as large as possible.
Stack NNs on top of each other sucessively to soften the blow, then add the force layer to force admissbility.

\subsection{Reinforcement Learning}

In my opinion, this has the greatest viability. AlphaGO is good example of RL's power.
The combination of a small discrete action space coupled with a massive state space is very comparable to Chess, Othello, Go, etc.

The added benefit is the Rubik's cube is arguably much easier than Chess or Go, which have probably 5x the action space and depths in the hundreds to thousands.
Such a system would be extremely general as applying it to 4x4 is as easy as generating more training data.

\end{document}


\chapter{White noise, and weak- and wide-sense stationarity}


\subsubsection{\stid{3.11} ALExa}

\paragraph{Overview}

The ALExa project ({\sl Accelerated Libraries for
Exascale})
focuses on preparing the DTK and Tasmanian libraries for
exascale platforms and integrating these libraries into ECP
applications.  These libraries deliver capabilities
identified as needs of ECP applications: (1) the ability to
transfer computed solutions between grids with differing
layouts on parallel accelerated architectures,
enabling simulation projects such as ExaAM and ExaSMR to
seamlessly combine results from different computational
grids to perform their required simulations (DTK); and (2) the
ability to construct surrogate models with low memory
footprint, low cost and optimal computational throughput, to
enable the use of methods for optimization and uncertainty
quantification for large scale engineering problems, as well
efficient multi-physics simulations in projects such as
ExaStar (Tasmanian).

These capabilities
are being developed through ongoing interactions with our
ECP application project collaborators to ensure they will
satisfy requirements of these customers.  The libraries in
turn take advantage of other ECP/SW capabilities currently in
development, including Trilinos, Kokkos and SLATE.  The
final outcome of the ECP project will be a set of
libraries deployed to facilities
and also made broadly available as part of the xSDK4ECP
project.

{\bf DTK} (Data Transfer Kit)
{\it Purpose:}
Transfers computed solutions between grids with differing
layouts on parallel accelerated architectures.
{\it Significance:} Coupled applications frequently have
different grids with different parallel distributions; DTK
is able to transfer solution values between these grids
efficiently and accurately.
{\it Mesh-free interpolation capabililities:}
multivariate data interpolation between point clouds;
compactly supported radial basis functions;
nearest-neighbor and moving least square implementations;
common applications include conjugate heat transfer,
fluid structure interaction, and mesh deformation.
{\it Performace portable search capabilities:}
threaded and GPU implementations of spatial tree
construction;
threaded and GPU implementations of various spatial tree
queries;
MPI front-end for coordinating distributed spatial searches
between sets of geometric objects with different
decompositions;
communication plan generation based on spatial search
results.
{\it URL:}
https://github.com/ORNL-CEES/DataTransferKit

{\bf Tasmanian} (Toolkit for Adaptive Stochastic Modeling
and Non-Intrusive Approximation)
{\it Purpose:} Constructs surrogate models for high
dimensional problems to help solve large scale engineering
and multiphysics problems
{\it Significance:}
Applications may require reduced representations of higher
dimensional data, for example, to optimize storage of high
dimensional tabular data or optimally perform UQ
calculations.  In addition, Tasmanian offers capabilities in
inverse problems, e.g., calibration and inference.
{\it Sparse grids capabilities:}
surrogate modeling and design of experiments (adaptive
multi-dimensional interpolation);
reduced (lossy) representation of tabulated scientific data;
high dimensional numerical quadrature;
data mining and manifold learning.
{\it DiffeRential Evolution Adaptive Metropolis (DREAM)
capabilities:}
Bayesian inference;
parameter estimation/calibration;
model validation.
global optimization and optimization under uncertainty.
{\it URL:}
http://tasmanian.ornl.gov

\paragraph{Key Challenges}

\indent

{\bf DTK:}
The general case of transferring data between grids of
unrelated applications requires an all-to-all
communication.
This is increasingly challenging as communication
to computation ratios are decreasing on successive HPC
systems.
Furthermore, the gridcell search procedures to locate
interpolation points require tree search methods
difficult to optimize on modern accelerated
architectures due to vector lane or thread divergence.
Also, maintaining high accuracy for the transfer requires
careful attention to the mathematical properties of the
interpolation methods and is highly application-specific.
Unlike other, ``black box'' libraries,
grid transfer methods may require close collaboration
with application partners to understand customer
requirements
(accuracy and conservation law requirements,
distribution of grids, location and layout of grid data in
memory hierarchy, etc.)

{\bf Tasmanian:}
Sparse grid methods require dense linear algebra operations
with matrix sizes that may be large.
These operations must be well-optimized for the target
architectures, including accelerated nodes.
Uncertainty quantification methods can require many runs of
an application as input to forming a surrogate model,
and the runs may have very different runtimes,
creating a scheduling problem that must be solved in order
to maximize performance.

\paragraph{Solution Strategy}

\nobreak

\indent

{\bf DTK:}
State of the art mathematically rigorous methods are used in
DTK to preserve accuracy of interpolated solutions.
Algorithms are implemented in a C++ code base with extensive
unit testing on multiple platforms.
Trilinos packages are used to support interpolation methods.
Kokkos is used to achieve performance portability
across accelerated platforms.

{\bf Tasmanian:}
To support performance portability across platforms for
dense linear algebra operations, a collaboration with the
SLATE ECP project is underway to take advantage of the new
library software being developed.
A DAG scheduler will be implemented under the project to
enable optimal execution of multiple application instances
for UQ problems.

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

\paragraph{Recent Progress}

\indent

{\bf DTK:}
Ongoing work with a growing list of ECP application partners
is continuing.
Extensive work has been done to define the Fortran, C and
C++ DTK interfaces to support partner projects.
A set of benchmark problems has been developed
to guide DTK method and code development.
Recent progress has been made to optimize the search methods
for modern-generation GPUs.

\begin{figure}[htb]
        \centering
        \includegraphics[width=4in]{projects/2.3.3-MathLibs/2.3.3.11-ALExa/dtk-gpu}
        \caption{\label{fig:dtk-gpu}DTK tree search, OpenMP and Summitdev GPU speedups}
\end{figure}

{\bf Tasmanian:}
The infrastructure of Tasmanian has been upgraded to support
the broader ECP focus of the work.
GPU acceleration of sparse grid surrogates has been
implemented.
Tasmanian recently enabled the ExaStar project
to reduce the size of a large-memory table of neutrino
opacities by 100X while still preserving accuracy.

\begin{figure}[htb]
        \centering
        \includegraphics[width=2in]{projects/2.3.3-MathLibs/2.3.3.11-ALExa/tasmanian-gpu}
        \caption{\label{fig:tasmanian-gpu}Tasmanian speedup on Titan node using cuBLAS}
\end{figure}

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

\paragraph{Next Steps}

\indent

{\bf DTK:}
A major focus for the near future is to optimize performance
for the targeted architectures using the developed benchmark
cases.
This will be followed by work on a showcase problem to
demonstrate performance.

{\bf Tasmanian:}
Work will continue to integrate the SLATE dense linear
algebra capabilities into Tasmanian to enable high
performance and performance portability.
Asynchronous sampling using DAG methods will be implemented
for the sparse grid methods.

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


\section{Smart Contracts}
\label{sec:smartContracts}
\secttoc

In this section we give further details of all the Solidity contracts, libraries and interfaces in the Nightfall repository.
Some of these contracts are pre-existing and some are new.
The important new contracts are:
\begin{itemize}
  \item Shield contract - stores `token commitments' which represent ownership of underlying ERC-20 or ERC-721 tokens, and facilitates the minting, transferring and burning of these token commitments.
  \item Verifier Contract - uses elliptic curve pairing functions to verify a zk-SNARK.
  \item Verifier Registry Contract - a registry of Verifier Contracts, Verification Keys, and Proof submissions. For simplicity, we ignore this layer from our explanations in this paper; although it is utilised in the Nightfall repository.
\end{itemize}

Here, we give further details of all Solidity contracts, libraries and interfaces in the Nightfall repository:\\
\\
\subsection{Pre-Existing Contracts}

\subsubsection{\texttt{ERC-721}}
The structuring of the ERC-721 contracts is aligned with the \url{https://0xcert.org} implementation.
These are designed for the transfer of non-fungible assets and include the following files:
\begin{center}
	\begin{tabular}{ll}
		\texttt{ERC721Interface.sol} & \\
		\texttt{ERC721TokenReceiver.sol} & \\
		\texttt{ERC721Metadata.sol} & \\
		\texttt{NFTokenMetadata.sol} & An example metadata implementation, to accompany \texttt{NFToken.sol} \\
		\texttt{NFToken.sol} & An example ERC-721 implementation.
	\end{tabular}
\end{center}
An overview of the ERC-721 contracts is given in Figure~\ref{pic:nftSmartContract}

\begin{figure}[H]
	\begin{center}
		\begin{mdframed}[backgroundcolor=black,userdefinedwidth=\textwidth,align=center]
			\includegraphics[width=\textwidth]{images/nft-contracts.png}
		\end{mdframed}
	\end{center}
	\caption{ERC-721 contract structure.}
	\label{pic:nftSmartContract}
\end{figure}

\subsubsection{\texttt{ERC-20}}
The structuring of the ERC-20 contracts is aligned with the \url{https://openzeppelin.org} implementation.
These are designed for the transfer of fungible assets and include the following files:
\begin{center}
	\begin{tabular}{ll}
		\texttt{ERC20Interface.sol} & \\
		\texttt{FToken.sol} & An example ERC-20 implementation. \\
	\end{tabular}
\end{center}
An overview of the ERC-20 contracts is given in Figure~\ref{pic:ftSmartContract}

\begin{figure}[H]
	\begin{center}
		\begin{mdframed}[backgroundcolor=black,userdefinedwidth=\textwidth,align=center]
		\includegraphics[width=\textwidth]{images/ft-contracts.png}
		\end{mdframed}
	\end{center}
	\caption{ERC-20 contract structure.}
	\label{pic:ftSmartContract}
\end{figure}

\subsubsection{\texttt{ERC-165}}
The structuring of the ERC-165 contracts is aligned with the \url{https://0xcert.org} implementation.
\begin{center}
	\begin{tabular}{ll}
		\texttt{ERC165Interface.sol} & \\
		\texttt{SupportsInterface.sol} &  \\
	\end{tabular}
\end{center}

\subsubsection{\texttt{Utility contracts}}
\begin{center}
	\begin{tabular}{ll}
		\texttt{AddressUtils.sol} & See \url{https://ethereum.stackexchange.com/a/14016/36603} for more details about how this works. \\
		\texttt{SafeMath.sol} & For safe mathematical operations.  \\
	\end{tabular}
\end{center}

\subsection{Shield contracts}
\subsubsection{\texttt{NFTokenShield.sol}}
Facilitates private transfers of Non-Fungible Tokens.

Constructor: At deployment, specify one Verifier contract (see below) and one ERC-721 contract. NFTokenShield will then be able to hold tokens of the ERC-721 contract in escrow, whilst the private counterparts of these tokens are transferred. Future contributions to Nightfall will produce an NFTokenShield contract which can handle multiple ERC-721 contracts at once.

Stores token commitments, which represent ownership of a token of the specified ERC-721 contract.

Calls upon the Verifier contract to verify zk-SNARKs for it.

A high-level diagram of the `shielding' process is shown in Figure~\ref{pic:nftShield}.

\begin{figure}[H]
	\begin{center}
		\includegraphics[width=\textwidth]{images/erc721Shielding.png}
	\end{center}
	\caption{High-level diagram of `shielding' an ERC-721 token.}
	\label{pic:nftShield}
\end{figure}

\subsubsection{\texttt{FTokenShield.sol}}
Facilitates private transfers of Fungible Tokens.

Constructor: At deployment, specify one Verifier contract (see below) and one ERC-20 contract. FTokenShield will then be able to hold tokens of the ERC-20 contract in escrow, whilst the private counterparts of these tokens are transferred. Future contributions to Nightfall will produce an FTokenShield contract which can handle multiple ERC-20 contracts at once.

Stores token commitments, which represent ownership of a particular amount of currency, as denominated in the specified ERC-20 contract.

Calls upon the Verifier contract to verify zk-SNARKs for it.

A high-level diagram of the `shielding' process is shown in Figure~\ref{pic:ftShield}.

\begin{figure}[H]
	\begin{center}
		\includegraphics[width=\textwidth]{images/erc20Shielding.png}
	\end{center}
	\caption{High-level diagram of `shielding' an ERC-20 token.}
	\label{pic:ftShield}
\end{figure}

\subsection{Verifier contracts}
The sole purpose of a verifier contract is to verify zk-SNARKs which are passed to it. It returns \texttt{true} if the (proof, public inputs) pair verifies. Otherwise, it returns \texttt{false}.

\subsubsection{\texttt{GM17.sol}}
An implementation of the draft EIP-1922 zk-SNARK Verifier Standard.

\subsubsection{\texttt{Points.sol}}
Library. Defines how Elliptic Curve coordinates $(x, y)$ are structured.

\subsubsection{\texttt{GM17Library.sol}}
Library. Defines the structures of both a Verification Key and a Proof under the GM17 protocol (using the elliptic curve points of \texttt{Points.sol}).

\subsubsection{\texttt{Pairing.sol}}
Library. Performs elliptic curve operations and elliptic curve pairing operations. Utilises the precompiled contracts of EIP-196 and EIP-197.

\subsection{Verifier Registry contracts}
The Verifier Registry is intended to be a single contract to register all zk-SNARK traffic on the Ethereum mainnet. It facilitates:
\begin{itemize}
  \item[--] Registration of Verifier contracts
  \item[--] Storage of all Verification Keys
  \item[--] Proof submissions
  \item[--] Other zk-SNARK use-cases beyond Nightfall
\end{itemize}

Note: although the intention is for there to be just one Verifier Registry on the Ethereum mainnet, the default migration script in the Nightfall repository deploys an implementation of the Verifier Registry along with all other contracts -- for the sake of example.

\subsubsection{\texttt{Verifier\_Registry\_Interface.sol}}
The draft EIP-1923 interface for a Verifier Registry.

\subsubsection{\texttt{Verifier\_Registry.sol}}
An implementation of the Verifier\_Registry\_Interface.

\subsubsection{\texttt{Verifier\_Register\_Interface.sol}}
Library. Defines the structures of the register, which store entries to the Verifier\_Registry.

\subsection{Deployment of Contracts}
\label{sec:deploymentOfContracts}
See \hyperref[fig:trustedSetup]{Trusted Setup} for an explanation of deployment steps, and how contract deployment is intertwined with the zk-SNARK trusted setup.

\begin{center}
	\begin{mdframed}[backgroundcolor=verylightblue]
		Where to look?\\
		\\
		\begin{tabular}{lp{14cm}}
			\texttt{./zkp/contracts/} & Contracts in Nightfall\\
			\texttt{./zkp/migrations/} & Default deployment ordering of contracts in Nightfall\\
			\url{https://eips.ethereum.org/EIPS/eip-165} & EIP-165\\
			\url{https://eips.ethereum.org/EIPS/eip-20} & EIP-20\\
			\url{https://eips.ethereum.org/EIPS/eip-721} & EIP-721\\
			\url{https://eips.ethereum.org/EIPS/eip-196} & EIP-196\\
			\url{https://eips.ethereum.org/EIPS/eip-197} & EIP-197\\
			\url{https://eips.ethereum.org/EIPS/eip-1922} & EIP-1922\\
			\url{https://eips.ethereum.org/EIPS/eip-1923} & EIP-1923
		\end{tabular}
	\end{mdframed}
\end{center}

%Don't include figure until we get more. It looks out of place.
% \begin{figure}[H]
%   \centering
%   \includegraphics[scale=0.65]{smart-contracts}
%   \caption{The on-chain relationship between a `public' ERC-721 token and the `private' token commitments which represent it within the Shield Contract.}
%   \label{pic:Shield1}
% \end{figure}


\subsection{Hydrogen production methods}
\begin{frame}
\frametitle{Electrolysis}
\begin{columns}
    \column[t]{5cm}
	\begin{figure}[htbp!]
		\begin{center}
			\includegraphics[height=4.0cm]{images/ele-curve.png}
		\end{center}
		\caption{Energy consumption of an ideal electrolysis process. Image reproduced from \cite{hi2h2_highly_2007}.}
	\end{figure}

	\column[t]{5cm}
	$\Delta H = \Delta G + T \Delta S$
	\begin{itemize}
		\item $\Delta$G: Electrical energy.
		\item T$\Delta$S: Thermal energy.
	\end{itemize}
    \vspace{0.7cm}

	\begin{itemize}
    	\item In low temperature electrolysis (LTE), electricity provides the thermal energy.
    	\item In high temperature electrolysis (HTE), a heat source provides the thermal energy.
    	\item HTE has the advantage of decreasing the electricity requirement.
    \end{itemize}
\end{columns}
\end{frame}

\begin{frame}
\frametitle{Sulfur-Iodine}
\begin{columns}
    \column[t]{5cm}
   	\begin{figure}[htbp!]
		\begin{center}
			\includegraphics[height=4.0cm]{images/si-energy.png}
		\end{center}
		\caption{Sulfur-Iodine thermochemical cycle. Image reproduced from \cite{nomura_mikihiro_efficient_2004}.}
 	\end{figure}

 	\column[t]{5cm}
 	\begin{itemize}
 		\item 3 different reactions: sulfuric acid decomposition, Bunsen reaction, and hydrogen iodide decomposition.
 		\item Input: H$_2$O.
 		\item Output: H$_2$ $\&$ O$_2$.
 		\item Does not require electricity.
 		\item Needs a high temperature source.
 	\end{itemize}
\end{columns}
\end{frame}

\subsection{Nuclear energy-based hydrogen}
\begin{frame}
\frametitle{Co-generation}
\begin{columns}
    \column[t]{6.8cm}
   	\begin{figure}[htbp!]
		\begin{center}
			\includegraphics[height=3.6cm]{images/hte-figure0.png}
		\end{center}
		\caption{Diagram of a reactor coupled to hydrogen plant.}
 	\end{figure}

 	\column[t]{4.5cm}
 	$\beta$: power fraction that is converted into electricity.
 	\\
    $\beta$ = 1: no hydrogen produced.
    \\
 	$\beta$ = 0: no electricity produced. \vspace{0.5cm}

 	Low temperature electrolysis (LTE):
 	\begin{itemize}
 		\item $\gamma$=1. P$_{TH2}$ = 0.
 	\end{itemize}

 	High temperature electrolysis (HTE):
 	\begin{itemize}
 		\item 0 $< \gamma <$ 1.
 	\end{itemize}

    Sulfur-Iodine (SI):
 	\begin{itemize}
 		\item $\gamma$=0. P$_{EH2}$ = 0.
 	\end{itemize}
\end{columns}
\end{frame}


\documentclass[11pt,a4paper]{article}
\usepackage[top=3cm, bottom=3cm, left=3cm, right=3cm]{geometry}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{lmodern}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{color}
\usepackage{xspace}
\usepackage{graphicx}
\usepackage[leftcaption]{sidecap}
\usepackage{enumerate}
\usepackage[page,titletoc]{appendix}
\usepackage{braket}
\usepackage{subfigure}
\usepackage{wasysym}
\usepackage{bbm}

\newcommand\req[1]{Eq.\;\ref{#1}}
\newcommand\rfig[1]{Fig.\;\ref{#1}}
\newcommand\rapp[1]{Ann.\;\ref{#1}}

\newcommand\eq[1]{\begin{align} #1 \end{align}}
\newcommand\eqnl[1]{\begin{align*} #1 \end{align*}}

\newcommand\eqc[1]{\begin{equation} #1 \end{equation}}
\newcommand\eqcnl[1]{\begin{equation*} #1 \end{equation*}}
\newcommand\evat[1]{\bigg|_{#1}}
\newcommand\sameas{\Longleftrightarrow}
\newcommand\Lsameas{\;\;\;\;\;\Longleftrightarrow\;\;\;\;\;}
\newcommand\Limplies{\;\;\;\;\;\Longrightarrow\;\;\;\;\;}
\newcommand\mst{<\!\!<}
\newcommand\mgt{>\!\!>}
\newcommand\prl{\;/\!/\;}
\newcommand\ang{\text{\AA}}
\newcommand\mean[1]{\left< #1 \right>}
\newcommand{\norm}[1]{\left| #1 \right|}
\newcommand{\snorm}[1]{| #1 |}
\newcommand{\abs}[1]{\left| #1 \right|}
\newcommand{\sabs}[1]{| #1 |}
\newcommand{\lvec}[1]{\overrightarrow{#1}}
\newcommand{\half}{\frac{1}{2}}
\newcommand{\id}{\mathbf{1}}
\newcommand{\tr}{\text{Tr}}
\newcommand{\erf}{{\rm erf}}
\newcommand{\erfc}{{\rm erfc}}

\newcommand{\via}{{\it via}\xspace}

\newcommand{\herschel}{{\it Herschel}\xspace}
\newcommand{\spitzer}{{\it Spitzer}\xspace}
\newcommand{\hubble}{{\it Hubble}\xspace}

\newcommand{\mad}{{\rm MAD}}
\newcommand{\median}{{\rm median}}
\newcommand{\logd}{\log_{10}}
\newcommand{\sfr}{{\rm SFR}}
\newcommand{\sfruv}{{\rm SFR}_{\rm UV}}
\newcommand{\sfrir}{{\rm SFR}_{\rm IR}}
\newcommand{\sfrms}{{\rm SFR}_{\rm MS}}
\newcommand{\ssfr}{{\rm sSFR}}
\newcommand{\lir}{L_{\rm IR}}
\newcommand{\luv}{L_{\rm UV}}
\newcommand{\lsun}{L_\odot}
\newcommand{\msun}{M_\odot}
\newcommand{\yr}{{\rm yr}}
\newcommand{\mstar}{M_\star}
\newcommand{\snr}{{\rm SNR}}
\newcommand{\uvj}{\text{\it UVJ}\xspace}
\newcommand{\snu}{S_{\!\nu}}
\newcommand{\tdust}{T_{\rm dust}}

\newcommand{\halpha}{${\rm H}_\alpha$\xspace}
\newcommand{\Ks}{${\rm K}_s$\xspace}
\newcommand{\celib}{CE01\xspace}

\newcommand{\msum}[1]{\displaystyle\sum\limits_{#1}}
\newcommand{\mprod}[1]{\displaystyle\prod\limits_{#1}}
\newcommand{\infint}{\int_{-\infty}^{+\infty}}
\newcommand{\dd}{\mathrm{d}}
\newcommand{\DD}{\mathrm{D}}
\newcommand{\ddD}[1]{\mathrm{d}^{#1}}

\newcommand{\der}[2]{\frac{\mathrm{d}#1}{\mathrm{d}#2}}
\newcommand{\derb}[2]{\frac{\mathrm{d}^2 #1}{{\mathrm{d}#2}^2}}

\newcommand{\pder}[2]{\frac{\partial#1}{\partial#2}}
\newcommand{\pderb}[2]{\frac{\partial^2 #1}{{\partial#2}^2}}

\newcommand{\fder}[2]{\frac{\delta#1}{\delta#2}}
\newcommand{\fderb}[2]{\frac{\delta^2#1}{\delta^2#2}}
\newcommand{\fderbb}[3]{\frac{\delta^2#1}{\delta#2\;\delta#3}}

\newcommand{\com}[2]{\left[#1, #2\right]}
\newcommand{\acom}[2]{\left\{#1, #2\right\}}

\newcommand{\ind}{\indent\indent}

\newcommand{\emptyline}{\vspace{5 mm}}
\newcommand{\rmvline}{\vspace{-5 mm}}

\newcommand{\vecd}[2]{\hspace{-#1 em}\vec{\hspace{#1 em}#2}}

\newenvironment{dlist}{
\begin{itemize}
  \renewcommand{\labelitemi}{$\bullet$}
  \setlength{\itemsep}{1pt}
  \setlength{\parskip}{0pt}
  \setlength{\parsep}{0pt}
}{\end{itemize}}
\newenvironment{slist}{
\begin{itemize}
  \renewcommand{\labelitemi}{$\ast$}
  \setlength{\itemsep}{1pt}
  \setlength{\parskip}{0pt}
  \setlength{\parsep}{0pt}
}{\end{itemize}}
\newenvironment{elist}{
\begin{itemize}
  \renewcommand{\labelitemi}{}
  \setlength{\itemsep}{1pt}
  \setlength{\parskip}{0pt}
  \setlength{\parsep}{0pt}
}{\end{itemize}}
\newenvironment{nlist}{
\begin{enumerate}
  \setlength{\itemsep}{1pt}
  \setlength{\parskip}{0pt}
  \setlength{\parsep}{0pt}
}{\end{enumerate}}
\newenvironment{alist}{
\begin{enumerate}[a)]
  \setlength{\itemsep}{1pt}
  \setlength{\parskip}{0pt}
  \setlength{\parsep}{0pt}
}{\end{enumerate}}

\newcommand{\emptypage}{\newpage\null\thispagestyle{empty}\newpage}

\renewcommand\floatpagefraction{.9}
\renewcommand\topfraction{.9}
\renewcommand\bottomfraction{.9}
\renewcommand\textfraction{.1}
\setcounter{totalnumber}{50}
\setcounter{topnumber}{50}
\setcounter{bottomnumber}{50}

\renewcommand\sidecaptionsep{10 mm}
\numberwithin{equation}{section}

\newcommand{\sectionR}[1]{\section{{\color{red}#1}}}
\newcommand{\subsectionR}[1]{\subsection{{\color{red}#1}}}
\newcommand{\subsubsectionR}[1]{\subsubsection{{\color{red}#1}}}

\renewcommand{\id}{\mathbbm{1}}
\newcommand{\ie}{i.e.\xspace}

\begin{document}

{\centering
{\Huge EGG recipes for creating mock surveys}

\centering by Corentin Schreiber\par
}

\section{Determining the SED of the bulge and disk for a given galaxy}

We consider that each galaxy observed in a survey can be represented as a two-component system composed of a disk and a bulge. The mass ratio of each component is set by the bulge-to-total ratio, $f_B \equiv M_{\rm bulge}/M_{\rm disk+bulge}$. We attribute to each of these components a different SED, base on the recipes introduced in EGG (Schreiber et al.~2017b). These recipes are summarized here, and re-written in terms of probabilities to enable analytical calculations (instead of producing mock catalogs).

Alongside the bulge-to-total ratio, we attribute two main physical parameters to each galaxy: its redshift ($z$) and its total stellar mass ($\mstar$). We also attribute each galaxy a type ($t$), which can be either ``star-forming'' (SF) or ``quiescent'' (QU). The end goal of the EGG recipes is to describe, for both the bulge and disk, the probability of occurrence of a SED ($s$) based on these four parameters: $z$, $\mstar$, $t$, and $f_B$. In other words, we aim to define the two probability densities:
\begin{align}
p_{\rm disk}(s | z, \mstar, t, f_B) \quad\quad\text{and}\quad\quad p_{\rm bulge}(s | z, \mstar, t, f_B)\,,
\end{align}
where $s$ is an integer index symbolizing one SED among a chosen finite set.

The main idea behind EGG is that most of the diversity in galaxy SEDs can be captured by only two broadband colors, the rest-frame $(U-V)$ and $(V-J)$ colors (or \uvj diagram, see Williams et al.~2009), and that these colors are largely driven by the four parameters introduced above. Therefore, if we can build realistic probability distributions for the colors ($c_{UV}$ and $c_{V\!J}$, for short), and associate an SED to each color combination, then we can then generate a realistic distribution of SEDs.

To this end, in Schreiber et al.~(2017b) we divided the $(U-V)$ vs $(V-J)$ color space into bins, and attributed an SED to each bin by averaging the best-fit Bruzual \& Charlot (2003) model of all the galaxies observed in the deep CANDELS fields that fell in said color bin. This resulted in a library of 252 unique SEDs. Given that each SED corresponds to the average SED in a bin of \uvj colors, we can write:
\begin{align}
p_{\rm disk}(s | z, \mstar, t, f_B) = \frac{\int_{c_{UV,l}(s)}^{c_{UV,u}(s)} \dd c_{UV} \int_{c_{V\!J,l}(s)}^{c_{V\!J,u}(s)} \dd c_{V\!J}\,p_{\rm disk}(c_{UV}, c_{V\!J} | z, \mstar, t, f_B)}{\sum_{s'} p_{\rm disk}(s' | z, \mstar, t, f_B)}
\end{align}
where $c_{UV,l}(s)$ and $c_{UV,u}(s)$ represent respectively the lower and upper bounds of the $(U-V)$ bin in which the SED $s$ was constructed (and likewise for $c_{V\!J,l}(s)$ and $c_{V\!J,u}(s)$).

We then studied the observed location of galaxies on the \uvj diagram to construct the color distributions. Current data do not allow us to perform reliable color studies of disks and bulges separately, so we are limited to studying integrated colors of galaxies, and then make assumptions regarding how these integrated colors can be translated into bulge and disk colors.

In particular, we made the following simplifying assumptions: the disk colors are independent of the galaxy's type $t$ and the bulge-to-total ratio $f_B$:
\begin{align}
p_{\rm disk}(c_{UV}, c_{V\!J} | z, \mstar, t, f_B) = p_{\rm disk}(c_{UV}, c_{V\!J} | z, \mstar)\,.
\end{align}
and the bulge colors are independent on the galaxy's type:
\begin{align}
p_{\rm bulge}(c_{UV}, c_{V\!J} | z, \mstar, t, f_B) = p_{\rm bulge}(c_{UV}, c_{V\!J} | z, \mstar, f_B)\,.
\end{align}
The final SED of the galaxy will eventually depend on the type $t$ through the dependence of $f_B$ and $\mstar$ on $t$; here we simply assume that at fixed $\mstar$ and $f_B$ the type can be ignored.

We then assume that the colors can be split into two main classes: ``SF'' and ``QU'' (unrelated to the type $t$ of the galaxy), driven by the corresponding probability densities $p_{\rm SF}(c_{UV}, c_{V\!J} | z, \mstar)$ and $p_{\rm QU}(c_{UV}, c_{V\!J} | z, \mstar)$, which we assume only depend on mass and redshift. We then assume that disks only have ``SF'' colors, while bulges can be either ``SF'' or ``QU'' depending on $f_B$, such that:
\begin{align}
p_{\rm disk}(c_{UV}, c_{V\!J} | z, \mstar) &= p_{\rm SF}(c_{UV}, c_{V\!J} | z, \mstar)\,, \\
p_{\rm bulge}(c_{UV}, c_{V\!J} | z, \mstar, f_B) &= \left\{\begin{array}{lll}
p_{\rm QU}(c_{UV}, c_{V\!J} | z, \mstar) & \text{for} & f_B \ge 0.6 \\
\frac{p_{\rm QU}(c_{UV}, c_{V\!J} | z, \mstar) + p_{\rm SF}(c_{UV}, c_{V\!J} | z, \mstar)}{2} & \text{for} & f_B < 0.6
\end{array}\right.\,.
\end{align}
The rationale behind this choice is to allow classical bulges (which are quiescent) and pseudo bulges (which are still star-forming), and the adopted prescription was roughly tuned to match the observed relation between $f_B$ and integrated colors. Quiescent disks do exist but are quite rare, and they were therefore ignored.

We then looked at the integrated colors of real galaxies, quiescent and star-forming, and in bins of mass and redshift, to build $p_{\rm SF}$ and $p_{\rm QU}$. We found the following (admittedly convoluted!) prescriptions provide an accurate description of the data.

For ``SF'' colors. We noticed that galaxies cluster along a ``sequence'' (with some scatter), and move on this sequence depending on their mass and redshift. We therefore introduce a new intermediate quantity $A$, which is the ``intrinsic'' position of the galaxy on the sequence, such that:
\begin{align}
p_{\rm SF}(c_{UV}, c_{V\!J} | z, \mstar) = \int \dd A\,p(A | z, \mstar)\,p(c_{UV} | A,z)\,p(c_{V\!J} | A,z)\,,
\end{align}

Using the normal distribution
\begin{align}
G(x; \mu, \sigma) &= \frac{1}{\sigma\,\sqrt{2\pi}}\,\exp\left(-\frac{(x-\mu)^2}{2\,\sigma^2}\right)\,,
\end{align}
we set:
\begin{align}
p(A | z, \mstar) &= G(A; \bar{A}, \sigma_A)\,, \\
\bar{A} &= \left\{\begin{array}{lll}
\bar{A}^* & \text{for} & \bar{A}^* < 2\,, \\
2 & \text{else,}
\end{array}\right.\\
\bar{A}^* &= \bar{A}_0 + \bar{A}_1\times\left\{\begin{array}{lll}
z & \text{for} & z < 3.3\,, \\
3.3 & \text{else,} \\
\end{array}\right.\\
\bar{A}_0 &= 1.39 + 0.58\,{\rm erf}\big[\log_{10}(\mstar/10^{10})\big]\,, \\
\bar{A}_1 &= -0.34 + 0.30\times\left\{\begin{array}{lll}
\log_{10}(\mstar) - 10.35 & \text{if} & > 0\,, \\
0 & \text{else,} \\
\end{array}\right. \\
\sigma_A &= 0.1 + 0.3\times\left\{\begin{array}{lll}
z-1 & \text{if} & 1 \le z < 2\, \\
0 & \text{if} & z < 1\, \\
1 & \text{if} & z \ge 2\, \\
\end{array}\right\}\\
&\times\left[0.17 + \left\{\begin{array}{lll}
\log_{10}(\mstar) - 9.3 & \text{if} & 9.3 \le \log_{10}(\mstar) < 10.3 \\
11.3 - \log_{10}(\mstar) & \text{if} & 10.3 \le \log_{10}(\mstar) < 11.3 \\
0 & \text{else}
\end{array}\right.\right]\,, \\
p(c_{UV} | A, z) &= G(c_{UV}; 2\,c_z(z)+0.45+0.545\,A, 0.12)\,, \\
p(c_{V\!J} | A, z) &= G(c_{V\!J}; c_z(z)+0.838\,A, 0.12)\,, \\
c_z(z) &= \left\{\begin{array}{lll}
(0.5 - z)/0.5 & \text{if} & z < 0.5\,, \\
0 & \text{else.} \\
\end{array}\right.
\end{align}
The latter, $c_z(z)$, is a color correction term for low redshift galaxies ($z<0.5$), which was found necessary when comparing our prescriptions (originally calibrated only at $0.5<z<3.0$) against observations of low redshift galaxies (GAMA).

For ``QU'' galaxies the prescription is a little simpler, but follows the same philosophy. Galaxies also cluster along a sequence (which can be identified as the ``red sequence''), which we parametrize with the intermediate variable $B$:
\begin{align}
p_{\rm QU}(c_{UV}, c_{V\!J} | z, \mstar) = \int \dd B\,p(B | z, \mstar)\,p(c_{UV} | B,z)\,p(c_{V\!J} | B,z)\,.
\end{align}
Using the step function
\begin{align}
U(x) = \left\{\begin{array}{lll}
1 & \text{for} & x \ge 0\, \\
0 & \text{for} & x < 0\, \\
\end{array}\right.\,,
\end{align}
and Dirac ``delta'' function
\begin{align}
\delta(x) = \lim_{\sigma \to 0}\,G(x; 0, \sigma)\,,
\end{align}
we set:
\begin{align}
p(B | z, \mstar) &= G(B; \bar{B}, 0.1)\,U(-0.1-B)\,U(B-0.2) + \beta_l\,\delta(B+0.1) + \beta_u\,\delta(B-0.2) \\
\beta_l &= \int_{-\infty}^{-0.1}\dd B\,G(B; \bar{B}, 0.1) = \frac{1}{2} + \frac{1}{2}\,{\rm erf}\left[\frac{-0.1-\bar{B}}{0.1\,\sqrt{2}}\right]\\
\beta_u &= \int_{0.2}^{+\infty}\dd B\,G(B; \bar{B}, 0.1) = \frac{1}{2} - \frac{1}{2}\,{\rm erf}\left[\frac{0.2-\bar{B}}{0.1\,\sqrt{2}}\right]\\
\bar{B} &= 0.1\,\log_{10}(\mstar/10^{11}) \\
p(c_{UV} | B,z) &= G(c_{UV}; 2\,c_z(z)+1.85+0.88\,B, 0.10) \\
p(c_{V\!J} | B,z) &= G(c_{V\!J}; c_z(z)+1.25+B, 0.10)
\end{align}

\section{Determining the fundamental properties of galaxies}

With these color (or SED) distributions in place, all we are left to do is plug in distributions for the base parameters, namely: $z$, $\mstar$, $t$, and $f_B$.

We start by $f_B$. Lang et al.~(2014) presented distributions of $f_B$ for galaxies at $z=1$ and $z=2$, and found these distributions to be independent on redshift, but strongly dependent on mass and galaxy type (SF or QU), with a residual random scatter. The following is based on their observations. Using the log-normal distribution
\begin{align}
LN(x; \mu, \sigma) &= \frac{1}{x\,\sigma\,\sqrt{2\pi}}\,\exp\left(-\frac{\log(x/\mu)^2}{2\,\sigma^2}\right)\,,
\end{align}
we set:
\begin{align}
p(f_B | \mstar, t) &= LN(f_B; \bar{f}_B, 0.2)\,U(1 - f_B) + \alpha_1\,\delta(f_B - 1)  \\
\alpha_1 &= \int_1^{+\infty}\dd f_B\, LN(f_B; \bar{f}_B, 0.2)
= \frac{1}{2} + \frac{1}{2}\,{\rm erf}\left[\frac{\log(\bar{f}_B)}{0.2\,\sqrt{2}}\right]\,, \\
\bar{f}_B &= \left\{\begin{array}{lll}
0.2\,(\mstar/10^{10})^{0.27} & \text{for} & t={\rm SF}\,, \\
0.5\,(\mstar/10^{10})^{0.10} & \text{for} & t={\rm QU}\,.
\end{array}\right.
\end{align}

We then proceed with $z$, $t$ and $\mstar$. For these, we use the observed stellar mass functions of star-forming and quiescent galaxies, separetely, where the SF/QU separation was done in the \uvj diagram. The observed stellar mass distributions in bins of redshift were fit with double Schechter functions; See Schreiber et al.~(2017b) for the fit parameters. The mass functions are extended to $z=0$ using Baldry et al.~(2012) and to $z>4$ using Grazian et al.~(2016). Here we note these as:
\begin{align}
\frac{\dd N(z, \mstar, t)}{\dd \mstar\,\dd V}\,.
\end{align}
since this is the number of galaxies per bin of stellar mass and per unit comoving volume.

In a survey, we observe galaxies in bins of redshift which get projected within a fixed area on the sky, and this corresponds to a different comoving volume depending on the chosen redshift slice. To get the number of observed galaxy in our survey, we therefore need to compute and integrate
\begin{align}
\frac{\dd N(z, \mstar, t)}{\dd \mstar\,\dd z} = \frac{\mathcal{A}}{4\,\pi}\,\frac{\dd V(z)}{\dd z}\,\frac{\dd N(z, \mstar, t)}{\dd \mstar\,\dd V}\,,
\end{align}
where $\mathcal{A}$ is the sky area covered by our survey in steradians (this value is actually irrelevant for our predictions, so we picked $1\,{\rm deg}^2$), and $V(z)$ is the comoving volume of the Universe contained within a radius of $D_C(z)$ (the comoving distance).

\section{The PSF of a galaxy}

Using the Euclid PSF toolkit, we generated PSFs for each of the 252 SEDs in the EGG library, redshifted on a fine grid with step $\Delta z = 0.001$. For reach of these PSFs, we computed the moments: $Q_{11}$, $Q_{12}$, and $Q_{22}$, which are given by:
\begin{align}
F_w &= \sum_{x, y} {\rm PSF}(x,y)\,W(x,y,\bar{x},\bar{y})\,, \\
Q_{11} &= \frac{\sum_{x, y} {\rm PSF}(x,y)\,W(x,y,\bar{x},\bar{y})\,(x - \bar{x})^2}{F_w}\,, \\
Q_{12} &= \frac{\sum_{x, y} {\rm PSF}(x,y)\,W(x,y,\bar{x},\bar{y})\,(x - \bar{x})\,(y - \bar{y})}{F_w}\,, \\
Q_{22} &= \frac{\sum_{x, y} {\rm PSF}(x,y)\,W(x,y,\bar{x},\bar{y})\,(y - \bar{y})^2}{F_w}\,, \\
\end{align}
with
\begin{align}
\bar{x} &= \frac{\sum_{x, y} {\rm PSF}(x,y)\,W(x,y,\bar{x},\bar{y})\,x}{F_w}\,, \\
\bar{y} &= \frac{\sum_{x, y} {\rm PSF}(x,y)\,W(x,y,\bar{x},\bar{y})\,y}{F_w}\,.
\end{align}

The weighting function $W$ is a constant 2D Gaussian function of $\sigma=0.75"$ centered on $(\bar{x}, \bar{y})$, which attenuates the pixels further away from the center and stabilizes the moments. Because this weighting function depends on $\bar{x}$ and $\bar{y}$, which themselves also depend on the weighting function, the process should be iterated until convergence of $\bar{x}$ and $\bar{y}$. However, in order to be able to use the simple formula below, we actually forced the centroids to be exactly the same for all PSFs. Note that the PSFs produced by the toolkit are such that $\sum_{x,y}{\rm PSF}(x,y) = 1$, but because the weighting function removes flux from the PSF, in general we have $F_w < 1$, and the wider the PSF the more $F_w$ deviates from unity (in practice we find $0.9<F_w<0.96$). When producing a summed PSF, this effectively downweights the PSFs in the red in favor of PSFs in the blue. This is an artificial weighting which only affects the moments as computed above, not the actual PSF, but it has to be taken into account when comparing moments from different PSFs.

From these equations, it follows that when summing two PSFs, and assuming the centroids $(\bar{x},\bar{y})$ are identical, the moments of the summed PSF are the weighted averages of the moments of each PSF. The weights are the relative fluxes of each PSF (accounting, in particular, for the effect of the weighting function, which affects the total flux of the PSFs in a non-trivial way). This means that, for an SED $s$, we can actually write the moments of the corresponding PSF as an integral over wavelengths:
\begin{align}
Q_s = \frac{\int \dd\lambda\,f_s(\lambda)\,R(\lambda)\,F_w(\lambda)\,Q(\lambda)}{\int \dd\lambda f_s(\lambda)\,R(\lambda)\,F_w(\lambda)}\,,
\end{align}
where $f_s$ is the flux density (per unit wavelength) of the SED, $R(\lambda)$ is the energy response of the instrument (a factor $\lambda$ times the quantum efficiency), $Q(\lambda)$ is the moment of the monochromatic PSF at the wavelength $\lambda$, and $F_w(\lambda)$ is the total flux of the PSF after applying the weighting function (as defined as above).

For a galaxy composed of a disk and a bulge of SEDs $d$ and $b$ (respectively), the total flux density can be written:
\begin{align}
f_{\rm tot}(\lambda, f_B, d, b) = f_B\,f_b(\lambda) + (1-f_B)\,f_d(\lambda)\,.
\end{align}
Plugging this in the above integral, we can then express the moment corresponding to this SED as:
\begin{align}
Q_{\rm tot}(f_B, d, b) = \hat{f}_B(d,b)\,Q_b + (1 - \hat{f}_B(d,b))\,Q_d,
\end{align}
where $\hat{f}_B(d,b)$ is some sort of \emph{flux-weighted} bulge-to-total ratio:
\begin{align}
\hat{f}_B(d,b) = \frac{\int \dd\lambda f_B\,f_b(\lambda)\,R(\lambda)\,F_w(\lambda)}{\int \dd\lambda f_{tot}(\lambda, f_B, d, b)\,R(\lambda)\,F_w(\lambda)}
\end{align}

Omitting the $F_w$ term in the above equations can induce a bias approaching $10\%$ of the Euclid requirements.

\section{The observed flux of a galaxy}

In EGG, the flux density per unit stellar mass of an SED $s$ is:
\begin{align}
\bar{f}_s(\lambda, z) = 10^{-C_{\rm M/L}(z)}\,\bar{f}_{s,{\rm base}}(\lambda)\,,
\end{align}
where $C_{\rm M/L}(z)$ is a simple piece-wise linear function, which corrects for varying mass-to-light ratio at fixed \uvj colors. Since this correction term is wavelength-independent, it can be ignored when computing the effective PSF, but it will impact the total flux of the galaxy, and therefore whether the galaxy is above the survey detection limit or not.

The total flux density of the galaxy is thus:
\begin{align}
f_{\rm tot}(\lambda, \mstar, z, f_B, d, b) = \mstar\left[f_B\,\bar{f}_b(\lambda, z) + (1-f_B)\,\bar{f}_d(\lambda, z)\right]\,,
\end{align}
where $d$ is the disk SED and $b$ is the bulge SED. We can finally integrate this within the passband of the selection band (i.e., VIS for Euclid?):
\begin{align}
F_{\rm tot}(\mstar, z, f_B, d, b) = \frac{\int \dd\lambda\,f_{\rm tot}(\lambda, \mstar, z, f_B, d, b)\,R(\lambda)}{\int \dd\lambda\,R(\lambda)}\,,
\end{align}

\section{The average PSF in a redshift slice}

Using all the above, we can finally write down the average moments of the PSF in a given redshift slice $z_a < z < z_b$, and for a given flux detection limit $F > F_{\rm lim}$:
\begin{align}
\mean{Q}(F &> F_{\rm lim}, z_a < z < z_b) \nonumber \\
&\propto \int_{z_a}^{z_b}\dd z\sum_{t=\{{\rm SF,QU}\}}\int_0^{+\infty} \dd \mstar\,\frac{\dd N(z, \mstar, t)}{\dd \mstar\, \dd z} \int_0^1\dd f_B\,p(f_B | \mstar,t) \nonumber \\
&\quad\quad \sum_{d=1}^{N_{\rm SED}} p_{\rm disk}(d | z,\mstar) \sum_{b=1}^{N_{\rm SED}}p_{\rm bulge}(b | z,\mstar,f_B) \nonumber \\
&\quad\quad\quad\quad U[F_{\rm tot}(\mstar, z, f_B, d, b) - F_{\rm lim}]\,Q_{\rm tot}(f_B, d, b)\,.
\end{align}
where the term $U[...]$ enforces the survey detection limit.

In practice, we run the integral over $\mstar$ from $M_{\rm lim}(F_{\rm lim},z)$ to $10^{13}\,\msun$. The former is the minimum stellar mass we can expect given the flux detection limit, our SED library, and the redshift $z$:
\begin{align}
M_{\rm lim}(F_{\rm lim},z) = \min_{s} \frac{F_{\rm lim}}{\bar{F}_s(z)}\,,
\end{align}
where $\bar{F}_s(z)$ is the broadband flux per unit mass of the SED $s$ at redshift $z$.

\end{document}


\section{Algorithm description}
\label{sec:alg_desc}

Here we give a high-level description of how the program works, with some pseudocode where useful. Such pseudocode is meant to provide an abstract and concise representation of the algorithm, leaving out many implementation details and optimizations.

\paragraph{Individual}
An individual is described by the following attributes:
\begin{itemize}
    \item $id$ : unique identifier in the world (assigned incrementally)
    \item $pos = (x,y)$ : absolute position in the world
    \item $\Delta pos = (\Delta x,\Delta y)$ : displacement vector, representing the movement at each step
    \item $status =$ \NotExposed | \Exposed | \Infected | \Immune : current status of the individual. Both \NotExposed and \Exposed individuals are considered susceptible; the distinction is introduced for computational needs, for ease of visualization and debugging
    \item $t_{status}$ : time passed since the individual entered its current state. It is used to determine when to change state.
\end{itemize}

\paragraph{Initialization}
The program starts by reading the simulation parameters from command line and validating them according to the rules we mentioned in section~\ref{sec:intro}; if an error is found, it is logged back to the user and the program exits with \MPIAbort.
The configuration is then broadcast to all the processes with \MPIBcast, using the purposefully created \texttt{mpi\_global\_config} datatype.
Each country proceeds to autonomously calculate its $x,y$ limits and the indices of its neighbors.

Now the root proceeds to (uniformly) distribute the population among the countries, sending the local number of individuals $N_c$ and infected $I_c$ via \MPIScatter. Each country will then create the requested number of individuals on its own, giving them a random position inside its borders and a random travelling direction.
We also use \MPIExscan to compute the id of the first individual of each country, by summing the numbers of individuals of the previous ones.

Note that we used blocking and asynchronous communication primitives for two main reasons:
\begin{enumerate*}[label=(\roman*)]
    \item the amount of data to be sent is small, so it is unlikely to fill the send-buffers, and
    \item the data flows only from the root to the other processes, so there is no need for synchronization
\end{enumerate*}.
Pseudocode of the initialization procedure can be found in algorithm~\ref{alg:initialization}.

\paragraph{Main loop}
Each iteration of the main loop takes a consistent situation at time $t$ and computes a consistent situation at $t + t_{step}$. There is no interpolation: each individual is treated as if it were in the same initial position and status for the whole step. At the beginning of each iteration we assume that each susceptible individual has $status_i = \NotExposed$.
The procedure, summarized in algorithm~\ref{alg:mainloop}, can be broken down in various phases:
\begin{description}
    \item[update exposure] Check each susceptible individual $i$ against infected individuals: as soon as $i$ is found within spreading distance $d$ from an infected $j$, it is flagged with $status_i = \Exposed$.

    \item[update status] Based on $status$ and $t_{status}$, the status of each individual is updated (for example, an infected individual with $t_{status} >= t_{infection}$ will become immune). In case the individual changed status or was not exposed, $t_{status}$ is reset to zero, otherwise it is incremented by $t_{step}$. \Exposed individuals are set back to \NotExposed. In this way $t_{status}$ will accumulate the time an individual has been continuously exposed.

    \item[update position] $pos_i$ is updated by summing the displacement $\Delta pos_i$. In case the resulting position is out of the country boundary, there are two possibilities:
    \begin{enumerate*}[label=(\roman*)]
        \item it is also out of the world boundary, so it will bounce, or
        \item it is in a neighbor country $c'$; in such case it is removed from the local individuals and inserted into an outbound list $migrated \mhyphen to_{c'}$ for the specific country.
    \end{enumerate*}.

    \item[exchange migrated] Country $c$ exchanges the list of individuals that moved to each of its neighbors $c'$. The source country performs an \MPIIsend and the destination will perform a matching \MPIRecv , both with the specific tag \MigratedTag.
    We then integrate the received individuals into the local lists and finally wait for the sends to complete.
    We chose a \emph{non-blocking} send so that the process immediately starts receiving from its neighbors, without having to wait for all the outbound data to be copied into the buffers, which may fill since a lot of data is potentially sent. For receives we chose a \emph{blocking} approach, with the disadvantage that a process might be stuck waiting for a slower neighbor, while a faster neighbor has already sent its data. However, the only approaches that overcome this limitation are \emph{event-driven} and \emph{polling}, none of which is available out-of-the-box in MPI, so we chose not to overcomplicate the code for a small gain in performance.
    In order to send the struct representing an individual, we created a custom MPI type called \texttt{mpi\_individual}.

    \item[write summary] If at least one day has passed since the last summary, each country counts how many susceptible, infected and immune individuals are currently in it. This data is packed into a \texttt{mpi\_summary} triple and gathered by the root using \MPIGather; the root will write an entry for each country in a \texttt{csv} file. An alternative to this approach would be collectively writing to an \MPIFile , but this also involves ensuring that each write operation is atomic. In our opinion the chosen approach is simpler, clearer and equivalent in terms of performance.

    \item[check termination] Each country counts the local number of infected individuals, then it calls \MPIAllreduce so that the total number of infected in the world is computed and received by each country. If there are no more infected in the whole world, the loop stops.
\end{description}

\begin{algorithm}[p]

    \If{root}{
        \Cfg$\leftarrow \langle N, I, W, L, w, l, v, d, t_{infection}, t_{recovery}, t_{immunity}, t_{step}, t_{target}\rangle$\;
        \ValidateConfig{\Cfg}\;
    }
    \MPIBcast{\Cfg}\;
    \If{root}{
        $\left\{ N_c \right\} \leftarrow$ \DistributePopulation{$N$}\;
        $\left\{ I_c \right\} \leftarrow$ \DistributePopulation{$I$}\;
    }
    \MPIScatter{$N_c$}\;
    \MPIScatter{$I_c$}\;
    \ForEach{individual $i$}{
        $pos_i \leftarrow$ random position\;
        $\Delta pos_i \leftarrow t_{step} \cdot v \cdot
            \begin{bmatrix} \cos \theta_i & \sin \theta_i \end{bmatrix}$,
        where $\theta_i$ is a random direction\;
        $status_i \leftarrow$ \NotExposed | \Infected, based on distribution\;
        $t_{status} \leftarrow 0$\;
    }
    \caption{Initialization}
    \label{alg:initialization}
\end{algorithm}
\begin{algorithm}[p]

    \For{$t \leftarrow 0$ \KwTo $t_{target}$ \Step $t_{step}$}{
        \ForEach{susceptible individual $i$, infected individual $j$}{
            \UpdateExposure{$i,j$}\;
        }
        \ForEach{individual $i$}{
            \UpdateStatus{i}\;
            \UpdatePosition{i}\;
        }
        $\left\{ migrated \mhyphen to_{c'} \right\} \leftarrow$ list of individuals to be moved from $c$ to each neighbor $c'$\;
        \ForEach{neighbor country $c'$}{
            \MPIIsend{$migrated \mhyphen to_{c'}$, $c'$}\;
        }
        \ForEach{neighbor country $c'$} {
            \MPIRecv{$migrated \mhyphen from_{c'}$, $c'$} and integrate it with local individuals\;
        }
        wait until all the \MPIIsend have completed\;
        \If{end of day}{
            $\langle susceptible_c, infected_c, immune_c \rangle \leftarrow$ \CountByStatus{$\left\{ status_{i} \right\}$}\;
            $summary \leftarrow$ \MPIGather{$\left\{\langle susceptible_c, infected_c, immune_c \rangle\right\}$}\;
            \If{root}{
                \WriteToCSV{$summary$}\;
            }
        }
        $infected_c \leftarrow$ \Count{infected individuals}\;
        $total \mhyphen infected \leftarrow$ \MPIAllreduce{$infected_c$}\;
        \If{$total \mhyphen infected = 0$}{
            \Break\;
        }
    }
    \caption{Main Loop}
    \label{alg:mainloop}
\end{algorithm}


\begin{landscape}
\chapter{Taxonomy of Online Algorithms}\label{appendix:taxonomy}

Here, we give an overview of the algorithms that were discussed in this chapter. The first table includes online algorithms for the one dimensional setting. The latter table includes online algorithms for the general setting.

\begin{table}[!ht]
    \centering
    \begin{tabularx}{\textheight}{l|l|X|l}
        name & problem & performance & time complexity \\\hline
        \hyperref[alg:ud:lcp]{LCP} & \hyperref[problem:simplified_smoothed_convex_optimization]{SSCO} & 3-competitive & $\mathcal{O}((\tau + w) C O_{\epsilon}^{\tau + w})$ \\
        \hyperref[alg:ud:lcp]{Int-LCP} & \hyperref[problem:simplified_smoothed_convex_optimization]{Int-SSCO} & 3-competitive & $\mathcal{O}((\tau + w)^2 C \log_2 m)$ \\
        \hyperref[alg:ud:memoryless]{Memoryless} & \hyperref[problem:simplified_smoothed_convex_optimization]{SSCO} & 3-competitive & $\mathcal{O}(C O_{\epsilon}^1)$ \\
        \hyperref[alg:ud:probabilistic]{Probabilistic} & \hyperref[problem:simplified_smoothed_convex_optimization]{SSCO} & 2-competitive & $\mathcal{O}(\tau^2 C I_{\epsilon} |B_{f_0}| R_{\epsilon} O_{\epsilon}^1)$ \\
        \hyperref[alg:ud:rbg]{RBG} & \hyperref[problem:smoothed_convex_optimization]{SCO} & $\alpha$-unfair competitive ratio $(1+\theta) / \min \{\theta, \alpha\}$ and regret $\mathcal{O}(\max \{T / \theta, \theta\})$; 2-competitive for $\theta = 1$ & $\mathcal{O}(C (O_{\epsilon}^1)^{\tau+1})$ \\
        \hyperref[alg:ud:randomized]{Rand-Probabilistic} & \hyperref[problem:simplified_smoothed_convex_optimization]{Int-SSCO} & 2-competitive & $\mathcal{O}(\tau^2 m C I_{\epsilon} R_{\epsilon} O_{\epsilon}^1)$ \\
        \hyperref[alg:ud:randomized]{Rand-RBG} & \hyperref[problem:smoothed_convex_optimization]{Int-SCO} & 2-competitive & $\mathcal{O}(C (O_{\epsilon}^1)^{\tau+1})$ \\
    \caption{Taxonomy of uni-dimensional online algorithms.}
    \end{tabularx}
\end{table}

\begin{table}[!ht]
    \centering
    \begin{tabularx}{\textheight}{l|l|X|l}
        name & problem & performance & time complexity \\\hline
        \hyperref[alg:md:lazy_budgeting:det_slo]{LB} & \hyperref[problem:slo]{SLO} & $2d$-competitive & $\mathcal{O}(m d^2 + C d \prod_{k=1}^d m_k)$ \\
        \hyperref[alg:md:lazy_budgeting:det_slo]{Randomized LB} & \hyperref[problem:slo]{SLO} & $\frac{e}{e-1}d$-competitive & $\mathcal{O}(m d^2 + C d \prod_{k=1}^d m_k)$ \\
        \hyperref[alg:md:lazy_budgeting:sblo_c]{LB} & \hyperref[problem:sblo]{SBLO} & $(2d + 1 + \epsilon)$-competitive & $\mathcal{O}(\widetilde{n}_{\tau} \widetilde{\tau}^2 |\mathcal{M}| C d)$ \\
        \hyperref[alg:md:ogd]{OGD} & \hyperref[problem:smoothed_convex_optimization]{SCO} & $\mathcal{O}(\sqrt{T})$-regret & $\mathcal{O}(d C O_{\epsilon}^d)$ \\
        \hyperref[alg:md:obd]{OBD} & \hyperref[problem:smoothed_convex_optimization]{SCO} & - & $\mathcal{O}(O_{\epsilon}^d)$ \\
        \hyperref[alg:md:pobd]{P-OBD} & \hyperref[problem:smoothed_convex_optimization]{SCO} & $3 + \mathcal{O}(1 / \alpha)$-competitive & $\mathcal{O}(C O_{\epsilon}^d + O_{\epsilon}^d R_{\epsilon})$ \\
        \hyperref[alg:md:dobd]{D-OBD} & \hyperref[problem:smoothed_convex_optimization]{SCO} & $\mathcal{O}(\sqrt{T})$-regret & $\mathcal{O}(C O_{\epsilon}^d + (O_{\epsilon}^d)^2 R_{\epsilon})$ \\
        \hyperref[alg:predictions:rhc]{RHC} & \hyperref[problem:smoothed_convex_optimization]{SCO} & $(1 + \mathcal{O}(1/w))$-competitive in one dimension; otherwise $(1 + \max_{k \in [d]} \beta_k / e_k(0))$-competitive & $\mathcal{O}(C O_{\epsilon}^{dw})$ \\
        \hyperref[alg:predictions:afhc]{AFHC} & \hyperref[problem:smoothed_convex_optimization]{SCO} & $(1 + \max_{k \in [d]} \frac{\beta_k}{(w+1) e_k(0)})$-competitive, i.e., $(1 + \mathcal{O}(1/w))$-competitive & $\mathcal{O}(w C O_{\epsilon}^{dw})$ \\
    \caption{Taxonomy of multi-dimensional online algorithms.}
    \end{tabularx}
\end{table}
\end{landscape}


\documentclass{beamer}

\usetheme{JuanLesPins}
%\usetheme{Darmstadt}

\usepackage{beamerthemesplit}
\usepackage{pxfonts}
\usepackage{proof}
%\usepackage{fleqn}

\title{Agda II -- Take One}
\author{Ulf Norell}
\date{\today}

\newcommand\PI[2]{(#1:#2)\to{}}
\newcommand\hPI[2]{\{#1:#2\}\to{}}
\newcommand\Fun[2]{#1\to#2}
\newcommand\lam[1]{\lambda #1\to{}}
\newcommand\Cons{\mathrel{::}}

\newcommand\To{\Rightarrow}
\newcommand\GoFig{\_}

\newcommand\Data[3]{\ensuremath{
    \mathbf{data}~#1 : #2~\mathbf{where} \\
    \quad\begin{array}{lcl}
	#3
    \end{array}
}}
\newcommand\Module[2]{\ensuremath{
    \mathbf{module}~#1~\mathbf{where} \\
    \quad\begin{array}{l}
	#2
    \end{array}
}}

\newenvironment{code}{
\begin{block}{}\(\begin{array}{l}
}{
\end{array}\)\end{block}
}

\renewcommand\Bar{~~|~~}

\begin{document}

\frame{\titlepage}

\section{Introduction}
\frame{\tableofcontents}

\subsection{Motivation}
\frame{
    \frametitle{What's the point?}

    \begin{itemize}
	\item of Agda II
	\begin{itemize}
	    \item Solid theoretical foundation (lacking in Agda)
	    \begin{itemize}
	    \item Small well-defined core language with nice metatheory.
	    \item Transparent translation from the full language to the core language.
	    \end{itemize}
	\end{itemize}
	\item of this talk
	\begin{itemize}
	    \item Present the (full) language from a user's perspective.
	\end{itemize}
    \end{itemize}
}

\subsection{The Basics}
\frame{
    \frametitle{The Logical Framework}

    {\small \begin{block}{The Basic Language}\(\begin{array}{llcl}
	\mbox{(Terms)} & s, t & \Coloneqq & x \Bar c \Bar f \Bar s\,t \Bar \lam xt \Bar \lam{(x:A)}t \\
	\mbox{(Types)} & A, B & \Coloneqq & \PI xAB \Bar A\to B \Bar t \Bar \alpha \\
	\mbox{(Sorts)} & \alpha, \beta & \Coloneqq & Set_i \Bar Set \Bar Prop \\
	\end{array}\)
    \end{block}}

    \begin{itemize}
	\item Note: $Set \neq Prop$.
    \end{itemize}

    {\small\begin{block}{Example: polymorphic identity}\(\begin{array}{l}
	id : \PI A{Set} A\to A \\
	id = \lam{(A:{Set})(x:A)}x
    \end{array}\)\end{block} }
}

\subsection{Features and Not}

\frame{
    \frametitle{What's there and what's not}

    \begin{itemize}
	\item Features
	\begin{itemize}
	    \item Inductive datatypes
	    \item Functions by pattern matching
	    \item Implicit arguments
	    \item Module system
	\end{itemize}
    ~
	\item Not Yet Features
	\begin{itemize}
	    \item $\Pi$ in Set
	    \item Signatures and structures
	    \item Inductive families
	\end{itemize}
    \end{itemize}
}

\section{Not Yet Features}

\subsection{Pi in Set}

\frame{
    \frametitle{$\Pi$ in Set}

    \begin{itemize}
	\item What does it mean?
	\begin{block}{We don't have}\[
	    \infer{\Gamma\vdash\PI xAB:{Set}}
		{ \Gamma\vdash A:{Set}
		& \Gamma,x:A\vdash B:{Set}
		}
	\]\end{block}

	\item Consequences:
	    {\small \begin{block}{We can't do}\(\begin{array}{l}
		    Rel~A = A\to A\to{Prop} \\
		    apply : List~(Nat\to Nat)\to List~Nat\to List~Nat \\
	    \end{array}\)\end{block} }
    \end{itemize}
}

\frame{
    \frametitle{$\Pi$ in Set}
    \begin{itemize}
	\item Why don't we have it?
	    \begin{itemize}
		\item Ask Thierry... (The metatheory gets tricky when you combine
		      $\eta$-equality and $\Pi$ in ${Set}$.)
	    \end{itemize}
	~
	\item What to do about it:
	\begin{itemize}
	    \item Get the metatheory straightened out (e.g. $\eta$-equality for datatypes).
	    \item Abandon $\eta$-equality.
	    \item Abandon $\Pi$ in ${Set}$.
	\end{itemize}
    \end{itemize}
}

\subsection{Signatures and Structures}

\frame{
    \frametitle{Signatures and Structures}

    \begin{itemize}
	\item What does it mean?
	\begin{itemize}
	    \item In Agda you can say (something like)
		{\small \begin{code}
		    Pair~A~B = \mathbf{sig}\begin{array}[t]{lcl}
			    fst & : & A \\
			    snd & : & B \\
			\end{array} \\
		    p : Pair~Nat~Nat \\
		    p = \mathbf{struct}\begin{array}[t]{lcl}
			    fst & = & 3 \\
			    snd & = & 7 \\
			\end{array} \\
		    three = p.fst
		\end{code} }
	\end{itemize}
	\item Why don't we have it?
	\begin{itemize}
	    \item We want to start simple.
	    \item Signatures and structures will appear in Agda II -- Take Two
	    (but probably not in the same form as in Agda).
	\end{itemize}
    \end{itemize}
}

\subsection{Inductive Families}

\frame{
    \frametitle{Inductive Families}

    \begin{itemize}
	\item What does it mean?
	\begin{itemize}
	    \item For instance:
	    \begin{code}
		\Data{Vec~(A:{Set})}{Nat\to{Set}}{
		    vnil  & : & Vec~A~zero \\
		    vcons & : & \PI n{Nat}A\to Vec~A~n\to Vec~A~(suc~n) \\
		}
	    \end{code}
	\end{itemize}
	\item Why don't we have it?
	\begin{itemize}
	    \item The inductive families in Agda are very limited in terms of
		  what you can do with them.
	    \item We want something better, which will require some thinking.
	\end{itemize}
    \end{itemize}
}

\section{Features}

\subsection{Datatypes}

\frame{
    \frametitle{Datatypes}

    \begin{itemize}
	\item Standard, garden-variety, strictly positive datatypes:
	{\small \begin{code}
	    \Data{Nat}{Set}{
		zero & : & Nat \\
		suc & : & Nat\to Nat \\
	    } \\{}\\
	    \Data{Exist~(A:{Set})~(P:A\to{Prop})}{Prop}{
		witness & : & \PI xA P~x\to Exist~A~P
	    } \\{}\\
	    \Data{Acc~(A:{Set})~((<):A\to A\to{Prop})~(x:A)}{Prop}{
		acc & : & (\PI yA y<x\to Acc~A~(<)~y)\to Acc~A~(<)~x
	    }
	\end{code} }
	\item Note that $\mathbf{data}\ldots$ is a declaration (not a term or type).
    \end{itemize}
}

\subsection{Definitions by Pattern Matching}

\frame{
    \frametitle{Definitions by Pattern Matching}

    \begin{itemize}
	\item Functions are defined by pattern matching
	\begin{itemize}
	    \item Arbitrarily nested, exhaustive, possibly overlapping patterns.
	    \item No case expressions!
	    {\small \begin{code}
		\begin{array}{lclcl}
		\multicolumn5l{(+) : Nat\to Nat\to Nat} \\
		zero &+& m &=& m \\
		suc~n &+& m &=& suc~(n + m) \\
		\end{array}\\
		{}\\
		\begin{array}{lllcl}
		eqNat : &Nat\to&Nat\to&&Bool \\
		eqNat&zero&zero &=& true \\
		eqNat&(suc~n)&(suc~m) &=& eqNat~n~m \\
		eqNat&\_&\_ &=& false \\
		\end{array}
	    \end{code} }
	\end{itemize}
    \end{itemize}
}

\frame{
    \frametitle{Mutual induction-recursion}

    \begin{itemize}
	\item You can have mutually inductive-recursive definitions:
	{\small \begin{code}
	    \mathbf{mutual} \\
	    \quad\begin{array}{llcl}
		even : &Nat\to&&Bool \\
		even&zero &=& true \\
		even&(suc~n) &=& odd~n \\
		\\
		odd : &Nat\to&&Bool \\
		odd&zero &=& false \\
		odd&(suc~n) &=& even~n \\
	    \end{array}
	\end{code} }
	\item I'd show the standard universe construction example of
	      induction-recursion, but you need $\Pi$ in ${Set}$ for that.
    \end{itemize}

}

\frame{
    \frametitle{Local functions}

    \begin{itemize}
	\item Functions (and datatypes) can be local to a definition:
	{\small \begin{code}
	    reverse : (A:{Set})\to List~A\to List~A \\
	    reverse~A~xs = rev~xs~nil \\
	    \quad\mathbf{where} \\
	    \qquad\begin{array}[t]{lllcl}
		    rev : &List~A\to&List~A\to&&List~A \\
		    rev&nil&ys & = & ys \\
		    rev&(x\Cons xs)&ys & = & rev~xs~(x\Cons ys) \\
		\end{array}
	\end{code} }
    \end{itemize}
}

\frame{
    \frametitle{Termination}

    \begin{itemize}
	\item We allow general recursion.
	\item Termination checking is done separately (as in Agda).
	\item Example:
	{\small \begin{code}\begin{array}{llcl}
	    qsort : &List~Nat\to&&List~Nat \\
	    qsort &nil &=& nil \\
	    qsort &(x\Cons xs) &=& filter~(\lam yy<x)~xs\mathrel{++} \\
	    &&& x\Cons filter~(\lam yy\geq x)~xs
	\end{array}\end{code} }
    \end{itemize}
}

\subsection{Implicit Arguments}

\frame{
    \frametitle{Meta Variables}

    \begin{itemize}
	\item There are two kinds of meta variables (only one in Agda):
	\begin{itemize}
	    \item Interaction points: $?$ and $\{!~\ldots~!\}$
	    \item Go figure\footnote{Conorism}: $\GoFig$
	\end{itemize}
	\item The type checker should be able to figure out the value of a go
	      figure without user intervention...
	\item ...whereas the value of an interaction point is supplied by the user.
	\item We use go figures to implement implicit arguments.
    \end{itemize}

}

\frame{
    \frametitle{Implicit Arguments}
    \begin{itemize}
	\item Curly braces $\{~\}$ are used to indicate implicitness:
	{\small \begin{block}{Syntax}\(\begin{array}{lcl}
	    s,t & \Coloneqq & \ldots \Bar s~\{t\} \Bar \lam{\{x\}}t \Bar \lam{\{x:A\}}t \Bar \GoFig \\
	    A,B & \Coloneqq & \ldots \Bar \hPI xAB \Bar \{A\}\to B \\
	\end{array}\)\end{block} }
	{\small \begin{code}
	    id~:~\hPI A{Set} A\to A \\
	    id~\{A\}~x = x \\
	    zero' = id~\{Nat\}~zero \\
	\end{code} }
	\item Implicit arguments can be omitted: $id~x$ means $id~\{\GoFig\}~x$.
	\item Both in left-hand-sides and right-hand-sides:
	{\small \begin{code}
	    id~:~\hPI A{Set} A\to A \\
	    id~x = x \\
	\end{code} }
    \end{itemize}
}

\frame{
    \frametitle{Example}

    \begin{code}
	\begin{array}{l}
	    \Data{List~(A:{Set})}{Set}{
		nil & : & List~A \\
		(\Cons) & : & A\to List~A\to List~A \\
	    }
	\end{array} \\{}\\
	\begin{array}{lclcl}
	\multicolumn5l{(++) : \hPI A{Set} List~A\to List~A\to List~A} \\
	nil & ++ & ys &=& ys \\
	(x::xs) & ++ & ys &=& x::(xs \mathrel{++} ys) \\
	\end{array}
    \end{code}
    \begin{itemize}
	\item Note that constructors are polymorphic:
	\begin{itemize}
	    \item $\vdash nil : List~A$, for any $A$
	    \item $\not\vdash nil : \hPI A{Set}List~A$.
	\end{itemize}
    \end{itemize}
}

\subsection{Module System}

\frame{
    \frametitle{Module System}

    \begin{itemize}
	\item Purpose:
	\begin{itemize}
	    \item Control the scope of names.
	    \item (Not to model algebraic structures.)
	\end{itemize}
	\item Guiding principle:
	\begin{itemize}
	    \item Scope checking should not require type
	      checking or computation.
	\end{itemize}
	\item Consequence:
	\begin{itemize}
	    \item Modules are not first class.
	\end{itemize}
    \end{itemize}
}

\frame{
    \frametitle{Submodules}

    \begin{itemize}
	\item Each source file contains a single module, which in turn can
	contain any number of submodules:
	{\small \begin{code}
	    \Module{Prelude}{
		\Module{Nat}{\ldots} \\
		\Module{List}{
		    \ldots \\
		    \Module{Fold}{\ldots} \\
		    \ldots \\
		} \\
	    }
	\end{code} }
    \end{itemize}
}

\frame{
    \frametitle{Accessing the Module Contents}

    \begin{itemize}
	\item To use a module from a file the module has to be {\em imported}\\
	\begin{code}
	    \mathbf{import}~Prelude
	\end{code}
	\item We can then use the names in the module fully qualified
	\begin{code}
	    one = Prelude.Nat.suc~Prelude.Nat.zero
	\end{code}
	\item Or we can {\em open} a module
	\begin{code}
	    \mathbf{open}~Prelude.Nat \\
	    one = suc~zero
	\end{code}
    \end{itemize}
}

\frame{
    \frametitle{Controlling what is imported}
    \begin{itemize}
	\item We can exercise finer control over what is imported or opened.
	\begin{code}
	    \mathbf{import}~Prelude~as~P \\
	    \mathbf{open}~P.Nat,~hiding~(+),~renaming~(zero~to~z) \\
	    \mathbf{open}~P.List,~using~(replicate) \\
	    zz : P.List.List~Nat \\
	    zz = replicate~(suc~(suc~z))~z
	\end{code}
    \end{itemize}
}

\frame{
    \frametitle{Controlling what is exported}
    \begin{itemize}
	\item Private things are not exported.
	{\small \begin{code}
	    \Module{BigProof}{
		\mathbf{private}~minorLemma = \ldots \\
		mainTheorem : P == NP \\
		mainTheorem = \ldots minorLemma \ldots
	    }
	\end{code} }
	\item Abstract things export only their type.
	{\small \begin{code}
	    \Module{Stack}{
		\mathbf{abstract} \\
		\quad\begin{array}{l}
		    Stack : Set\to Set \\
		    Stack = List \\
		\end{array} \\
	    }
	\end{code} }
	\item Private things still reduce, abstract things don't.
    \end{itemize}
}

\frame{
    \frametitle{Parameterised Modules}

    \begin{itemize}
	\item Modules can be parameterised.
	{\small \begin{code}
	    \mathbf{module}~Monad\begin{array}[t]{l}
		    (M:Set\to Set) \\
		    (return:\hPI{A}{Set}A\to M~A) \\
		    ((>>=):\hPI{A,B}{Set}M~A\to(A\to M~B)\to M~B)
		\end{array} \\
		~~~\mathbf{where} \\
		\quad\begin{array}{l}
		    liftM : \hPI{A,B}{Set}(A\to B)\to M~A\to M~B \\
		    liftM~f~m = m \mathrel{>>=} \lam x return~(f~x)
		\end{array}
	\end{code}}
	\item And instantiated
	{\small \begin{code}
	    \mathbf{module}~MonadList = Monad~List~singleton~(flip~concatMap) \\
	    lemma : \begin{array}[t]{l}
		    \hPI{A,B}{Set}\PI{f}{A\to B}\PI{xs}{List~A} \\
		    map~f~xs == MonadList.liftM~f~xs \\
		\end{array}
	\end{code} }
	\item You need to instantiate a parameterised module to use it.
    \end{itemize}
}

\section{Conclusions}

\frame{
    \frametitle{That's it folks}

    \begin{itemize}
	\item Agda II is very much work in progress.
	\item At this point very little is set in stone, so if you think things
	      should be a different way now is the time to speak up.
	\item Most of what you've seen will be available for use during the 4th
	      Agda Implementors Meeting starting next week in Japan.
    \end{itemize}
}
% \section{Examples}
%
% \frame{
% }

\end{document}