\documentclass[main.tex]{subfiles}
\begin{document}

\marginpar{Wednesday\\ 2020-11-11, \\ compiled \\ \today}

Last time we discussed the Coleman-Weinberg potential:
%
\begin{align}
V(\varphi ) = \frac{B \sigma^{4}}{2} - B \varphi^{4}
\qty[\log \qty(\frac{\varphi^2}{\sigma^2}) - \frac{1}{2}]
\,,
\end{align}
%
where typically \(B \sim \num{e-3}\).
It can be approximated for \(\varphi \ll \sigma \) as
%
\begin{align}
V(\varphi ) \approx \frac{B \sigma^{4}}{2} - \frac{\lambda}{4} \varphi^{4}
\,,
\end{align}
%
where \(\lambda \sim (10 \divisionsymbol 100 )B \sim \num{.1}\), and we have seen that if the initial value of \(\varphi \) is of the order of \num{e8} to \SI{e9}{GeV}, corresponding to roughly \(H/10\) then we can get a total number of \(e\)-folds of more than 1000.

Let us now move to \textbf{problems} with this model.
We must guarantee that the variance of the fluctuations of the scalar field must be smaller than the classical trajectory:
%
\begin{align}
\expval{ \delta \varphi^2} \ll \varphi_0^2 (t)
\,,
\end{align}
%
otherwise we cannot meaningfully treat the problem in a perturbative way.
This is violated, since \(\delta \varphi \sim H / 2\pi \) is comparable to \(\varphi _i \sim H / 10\).
This might destroy inflation.

We have
%
\begin{align}
\frac{ \delta \rho }{\rho } \approx \frac{H^2}{\dot{\varphi}} \approx \frac{3 H^3}{V'(\varphi )} \approx \frac{3}{\lambda } \qty(\frac{H}{\varphi })^3
\marginnote{See equation \eqref{eq:density-perturbation-power-spectrum}.}
\,,
\end{align}
%
since \(\dot{\varphi} = - V'(\varphi ) / 3H\). When \(\varphi \ll \sigma \), \(V' (\varphi ) \approx - \lambda \varphi^3\).

This will be of order unity at least!

Let try to make it so the number of \(e\)-folds \(N_\lambda (\varphi \to \varphi _f)\) is at least 50 or 60: this is given by
%
\begin{align}
N_\lambda (\varphi \to \varphi _f) &= \frac{3}{2} \frac{H^2}{\lambda } \qty( \frac{1}{\varphi^2} - \underbrace{\frac{1}{\varphi _f^2}}_{\text{negligible}})  \\
\frac{H}{\varphi } &\approx  \lambda^{1/2} \qty( \frac{2}{3})^{1/2} N_\lambda^{1/2}
\,,
\end{align}
%
so the density perturbation will be
%
\begin{align}
\frac{ \delta \rho }{\rho } \approx \lambda^{1/2} N_\lambda^{3/2} (8/3)^{1/2}
\,,
\end{align}
%
so if \(\lambda \approx \num{.1}\) and indeed \(N_\lambda \sim 50 \divisionsymbol 60 = N _{\text{CMB}}\) we get
%
\begin{align}
\frac{ \delta \rho }{\rho } \sim 100
\,.
\end{align}

This is in stark contrast to the CMB observation: \(\delta \rho /\rho \sim \num{e-5}\).

So, we get a contradiction: if \(\lambda \) is relatively large the density perturbations are huge, and in order to have the observed density perturbations we would need to have it tiny (\(\lambda \sim \num{e-10}\)), which would prohibit thermal equilibrium, which we assumed.

\textbf{Chaotic} models of inflation attempted to solve these problems: they used
%
\begin{align}
V(\varphi ) = \frac{\lambda}{4} \varphi^{4}
\,,
\end{align}
%
and they are \emph{large-field} models.
These models do not require coupling between the inflaton and other fields; however here we also find a relation
%
\begin{align}
\frac{ \delta \rho }{\rho } \sim \lambda^{1/2} N_\lambda^{3/2}
\,.
\end{align}

% Something about the Helmholtz free energy in the finite-temperature corrections to the potential \(V(\varphi ; T)\).

Hybrid models of inflation: we take a potential in the shape
%
\begin{align}
V(\varphi ) = V_0 \qty[1 + \qty(\frac{\varphi }{\mu })^{p}]
\,,
\end{align}
%
so that the potential is rolling down a potential towards a nonzero vacuum energy.

These were the first models for which the potential depends on two fields, so that the aforementioned potential for \(\varphi \) is an effective one: the full potential is
%
\begin{align}
V(\varphi , \psi ) = \frac{1}{2} m^2\varphi^2+ \frac{\lambda}{4} \qty(\psi^2-M^2)^2 + \frac{\lambda'}{2} \varphi^2 \psi^2
\,.
\end{align}

If we evaluate it at \(\psi = 0\) we find
%
\begin{align}
V(\varphi , \psi = 0) = \frac{1}{2} m^2\varphi^2 + \frac{\lambda}{4} M^{4}
\,,
\end{align}
%
in the same form as the aforementioned potential, with \(V_0 = \lambda M^{4} /4\).

The effective mass of \(\psi \), only considering the quadratic coupling, is
%
\begin{align}
\pdv[2]{V}{\psi } = m^2_\psi = \lambda ' \varphi^2 = m^2_\psi (\varphi )
\,,
\end{align}
%
so the square mass of \(\psi \) reads
%
\begin{align}
\eval{m^2_\psi}_{\psi = 0} = - \lambda  M^2 + \lambda ' \varphi^2
\,,
\end{align}
%
and it can be positive or negative! The critical value of \(\varphi \) for which it has zero mass is given by
%
\begin{align}
\varphi _c = \qty( \frac{\lambda }{\lambda'})^{1/2} M
\,,
\end{align}
%
for \(\varphi > \varphi _c\) we have \(\eval{m^2_\psi }_{\psi = 0} > 0\).

When \(\varphi \) becomes such that \(\varphi < \varphi _c\) then the point \(\psi = 0\) becomes unstable, so \(\psi \) moves from zero to either \(+\) or \(-M\).

We get a \emph{second-order} phase transition for \(\psi \).
\todo[inline]{Add graph for \(V (\psi , \phi )\).}

\subsection{Some remarks on inflation model building}

What are the loop contributions to the tree-level potential?
The tree-level potential can look like
%
\begin{align}
V(\varphi ) = V_0 \pm \frac{1}{2} m^2 \varphi^2 + \frac{\lambda}{4} \varphi^{4} + \frac{\lambda '}{\Lambda^2} \varphi^{6} + \dots
\,,
\end{align}
%
but the UV completion (the sixth-power term and beyond) must be suppressed with a large cutoff scale \(\Lambda \).

Loop corrections can change the parameters, but it can also add whole new terms (like the log in the Coleman-Weinberg potential).
These can be useful but also dangerous, for example spoiling the flatness needed for slow-roll inflation.

Typically, we will have something like
%
\begin{align}
\Delta V^{\text{one-loop}}(\varphi )
= \sum _{i} \frac{\pm g_i}{64 \pi^2}
M_i^{4} (\varphi ) \log \qty(\frac{M_i^2 (\varphi )}{\mu^2})
\,,
\end{align}
%
where \(M_i^2(\varphi )\) is the effective mass of the \(i\)-th particle species which interacts with \(\varphi \).
This logarithm generates the one in the Coleman-Weinberg potential.

The vacuum energy is given by
%
\begin{align}
E^{\psi } _{\text{vacuum}} = \frac{1}{2} \int  \frac{ \dd[3]{p}}{(2 \pi )^3}
\sqrt{p^2 + M^2_\psi (\varphi )}
\,.
\end{align}

Let us make some examples: if we have two scalar fields 1 and 2 with which \(\varphi \) interacts we might get terms in the form
%
\begin{align}
\Delta V(\varphi ) \sim m_1^2 m_2^2 \log \qty( \frac{\varphi}{\mu })
\,,
\end{align}
%
so starting from a tree-level flat potential \(V(\varphi ) = V_0 \) we might get
%
\begin{align}
V(\varphi ) = V_0 \qty(1 + \alpha  \log (\frac{\varphi }{\mu }))
\,,
\end{align}
%
where
%
\begin{align}
\alpha = \frac{m_1^2 m_2^2}{V_0 }
\,.
\end{align}
%

Another example which is similar to Coleman-Weinberg is
%
\begin{align}
\Delta V(\varphi ) \sim \frac{c}{2} \qty(m_1^2+ m_2^2) \varphi^2 \log \frac{\varphi }{\mu }
\,,
\end{align}
%
so
%
\begin{align}
V(\varphi ) &= V_0 + \frac{\varphi^2}{2} \qty[m^2 + c \widetilde{m}^2 \log \frac{\varphi }{\mu }]
\,,
\end{align}
%
which can arise from a tree-level potential like \(V_0 + m^2 \varphi^2 / 2\), where we defined \(\widetilde{m}^2 = m_1^2 + m_2^2\).

This might be observationally detected through a \textbf{running of the spectral index}: \(n_s = n_s (k)\).

\paragraph{The \(\eta \) problem}

Suppose we have a potential \(V\) depending on \(n\) complex scalar fields:
%
\begin{align}
V = V(\varphi _n, \overline{\varphi} _n) = e^{k(\varphi _n, \overline{\varphi}_n) / M _{\text{pl}}^2} \widetilde{V} (\varphi _n, \overline{\varphi}_n)
\,,
\end{align}
%
which is commonly called the Kähler potential --- it arises in the context of supergravity theories.
It arises from a Lagrangian in the form
%
\begin{align}
\mathscr{L} = \partial_{\mu } \overline{\varphi}_{m} K_{\overline{m} n} \partial^{\mu } \varphi_n
\,,
\end{align}
%
where
%
\begin{align}
K_{\overline{m}} = \pdv{K}{\overline{\varphi}_m} &&
K_{n} = \pdv{K}{\varphi_n}
\,.
\end{align}

If \(K = \sum _{m} \abs{\varphi _m}^2\) we find simply \(K_{\overline{m} n} = \delta_{nm}\); then
%
\begin{align}
\eta _V = \frac{1}{3} \frac{m^2}{H^2} = \frac{1}{3} \frac{V''(\varphi )}{H^2}
\,.
\end{align}

Let us identify \(\varphi \), the inflaton, with the real part of one of the fields: \(\varphi = \Re \varphi _n\).

Then,
%
\begin{align}
V = e^{K / M_P^2} \widetilde{V}
\,,
\end{align}
%
so that
%
\begin{align}
\pdv{V}{\varphi } = e^{K / M_p^2} \frac{2 \varphi }{M_P^2} \widetilde{V} + e^{k / M_P^2} \widetilde{V}'
\,,
\end{align}
%
therefore the square mass of the field reads
%
\begin{align}
m_\varphi^2
= \eval{\pdv[2]{V}{\varphi }}_{\varphi = 0}
= \frac{2V}{M_P^2} + e^{K / M_P^2} \widetilde{V}''
\,.
\end{align}

Then, using \(H^2 \approx \frac{8 \pi G}{3} V(\varphi )\) we get
%
\begin{align}
\eta _V = \frac{1}{3} \frac{m^2}{H^2} \sim \frac{m^2 M_P^2}{V}
\,.
\end{align}

This yields
%
\begin{align}
\eta _V = 1 + M_P^2 \frac{\widetilde{V}''}{\widetilde{V}}
\,,
\end{align}
%
which is a problem if we want slow-roll inflation.
\todo[inline]{Possibly not a 1 here.}

If we have a potential \(V _{\text{sr}}\) for the slow-roll, we might add a term
%
\begin{align}
V = V _{\text{sr}} + \frac{\varphi^2}{\Lambda^2} V _{\text{sr}}
\,,
\end{align}
%
so if \(\Lambda \leq M_P\), we might get \(\eta _V = V'' M_P^2 / V \approx 1\).
The main point is that inflation is very sensitive to high-energy physics.

The inflationary potential can in general be an effective one, which works for energies \(E \leq \Lambda \) for some cutoff \(\Lambda \).
We can use some additional symmetries imposed on the UV completion.

%
\begin{align}
\mathscr{L} _{\text{eff}} = \frac{1}{2} \partial_{\mu } \varphi \partial^{\mu } \varphi + \frac{1}{2} m^2 \varphi^2 - \frac{\lambda}{4} \varphi^{4}
+ \sum _{p=1}^{\infty } \qty[\lambda _p \varphi^{4} + \nu _p \partial_{\mu } \varphi \partial^{\mu }\varphi ] \qty( \frac{g}{\Lambda } \varphi )^{2p}
\,,
\end{align}
%
which contains nonrenormalizable terms, but this is fine since it is an effective theory.
We have employed the reflection symmetry \(\varphi \to - \varphi \).

We can impose that \(\varphi \ll \Lambda \), so that the tower of terms does not spoil the flatness. This means that we have a small-field model of inflation.
Alternatively, we may employ some symmetry like a shift symmetry \(\varphi \to \varphi + c\).
In that case, the tower of terms cannot spoil the flatness, therefore we may see large-field models of inflation, which predict a relatively high tensor-to-scalar ratio.

\end{document}


The initial step of our work is the study of the existing MC TBR model and its
behaviour. Following the examination of its features (simulation parameters), we
present efficient means of evaluating this model on large sets of points in
high-performance computing (HPC) environment, preprocessing techniques designed
to adapt collected datasets for surrogate modelling, and our attempts at feature
space reduction to achieve the lowest possible number of dimensions.

\subsection{Expensive Model Description}
\label{sec:expensive-model-description}

The expensive MC TBR model is fundamentally a Monte Carlo simulation based on the
OpenMC framework~\cite{ROMANO201590}. As input the software expects 18~parameters, discrete and
continuous, that are fully listed in~\cref{tbl:params}. During evaluation, which
usually takes units of seconds, a fixed number of neutron events is generated, and the
results are given in terms of the mean and the standard deviation of the~TBR aggregated
over the simulated run. The former of these two we accept to be the output TBR
value that is subject to approximation.

\begin{table}[h]
	\centering
	{\footnotesize
		\begin{tabular}{l|llll}
		\toprule
		{} & Parameter Name & Acronym & Type & Domain\\
		\midrule
		\parbox[t]{2mm}{\multirow{12}{*}{\rotatebox[origin=c]{90}{Blanket}}}
		   & Breeder fraction\textsuperscript{\textdagger} & BBF & Continuous & $[0,1]$\\
		   & Breeder \isotope[6]{Li} enrichment fraction & BBLEF & Continuous & $[0,1]$\\
		   & Breeder material & BBM & Discrete & $\{\ce{Li2TiO3}, \ce{Li4SiO4}\}$\\
		   & Breeder packing fraction & BBPF & Continuous & $[0,1]$\\
		   & Coolant fraction\textsuperscript{\textdagger} & BCF & Continuous & $[0,1]$\\
		   & Coolant material & BCM & Discrete & $\{\ce{D2O}, \ce{H2O}, \ce{He}\}$\\
		   & Multiplier fraction\textsuperscript{\textdagger} & BMF & Continuous & $[0,1]$\\
		   & Multiplier material & BMM & Discrete & $\{\ce{Be}, \ce{Be12Ti}\}$\\
		   & Multiplier packing fraction & BMPF & Continuous & $[0,1]$\\
		   & Structural fraction\textsuperscript{\textdagger} & BSF & Continuous & $[0,1]$\\
		   & Structural material & BSM & Discrete & $\{\ce{SiC}, \text{eurofer}\}$\\
		   & Thickness & BT & Continuous & $[0,500]$\\
		\midrule
		\parbox[t]{2mm}{\multirow{7}{*}{\rotatebox[origin=c]{90}{First wall}}}
		   & Armour fraction\textsuperscript{\textdaggerdbl} & FAF & Continuous & $[0,1]$\\
		   & Coolant fraction\textsuperscript{\textdaggerdbl} & FCF & Continuous & $[0,1]$\\
		   & Coolant material & FCM & Discrete & $\{\ce{D2O}, \ce{H2O}, \ce{He}\}$\\
		   & Structural fraction\textsuperscript{\textdaggerdbl} & FSF & Continuous & $[0,1]$\\
		   & Structural material & FSM & Discrete & $\{\ce{SiC}, \text{eurofer}\}$\\
		   & Thickness & FT & Continuous & $[0,20]$\\
		\bottomrule
		\end{tabular}
	}
	\caption{Input parameters supplied to the MC TBR simulation in alphabetical
		order. Groups of fractions marked\textsuperscript{\textdagger
		\textdaggerdbl} are independently required to sum to one.}
	\label{tbl:params}
\end{table}

In the following sections, we often reference TBR points or samples. These are simply vectors
in the feature space generated by Cartesian product of domains of all
features---parameters from~\cref{tbl:params}.

Since most surrogate models
that we employ assume overall continuous numerical inputs, we take steps to unify our
feature interface in order to attain this property. In particular, we transform
discrete features by embedding each such feature using standard one-hot
encoding. This option is available to
us since discrete domains that generate our feature space are finite in
cardinality and relatively small in size. And while it helps us towards
unification, this step comes at the expense of increasing the dimensionality of the
feature space. This is further discussed in~\cref{sec:dimred}.

\subsection{Dataset Generation}
\label{sec:dataset-generation}

In our work, we deliberately make no assumptions about the internal properties of the
MC TBR simulation, effectively treating it as a black box model. This limits our
means of studying its behaviour to inspection of its outputs at various
points in the feature space. We therefore require
sufficiently large and representative quantities of samples to ensure that
surrogates can be trained to approximate the MC TBR model accurately.

With a grid search in such a high-dimensional domain clearly intractable, we
selected uniform pseudo-random sampling\footnote{Continuous and discrete
parameters are drawn from a corresponding uniform distribution over their
domain, as defined in~\cref{tbl:params}. For repeatability, each run uses a seed equal to its number.} to generate large amounts of feature
configurations that we consider to be independent and unbiased. For evaluation
of the expensive MC TBR model, we utilise parallelisation offered by
the HPC infrastructure available at UCL computing facilities. To this end, we
designed and implemented the Approximate TBR Evaluator---a Python software package capable of
sequential evaluation of the multi-threaded OpenMC simulation on batches of
previously generated points in the feature space.
Having deployed ATE at the UCL Hypatia cluster\footnote{The Hypatia RCIF
	partition is comprised of 4~homogeneous nodes. Each node is installed with
	376~GB RAM and 40~Intel\textsuperscript{\textregistered}
	Xeon\textsuperscript{\textregistered} Gold 6148 CPUs of clock frequency
	2.40~GHz.}, we completed three data
generation runs that are summarised in~\cref{tbl:sampling-runs}.

\begin{table}[h]
	\sisetup{round-mode=places,round-precision=2}
	\centering
	{\footnotesize
		\begin{tabular}{rlllll}
		\toprule
		\#	& Samples & Batch division & $t_{\text{run}} $
			& $\overline{t}_{\text{eval.}}$ [\si{\second}] & Description \\
		\midrule
		0 & \num{100000} & $\num{100}\times\num{1000}$ & 2~days, 23~h
		  & $\num{7.877122043981347} \pm \num{2.749485948560108}$ &
		Testing run using old MC TBR version.\\
		1 & \num{500000} & $\num{500}\times\num{1000}$ & 13~days, 20~h
		  & $\num{7.777049573054314} \pm \num{2.8103592103930337}$ &
		Fully uniform sampling in the entire domain.\\
		2 & \num{400000} & $\num{400}\times\num{1000}$ & 10~days
		  & $\num{7.944379778103232} \pm \num{2.601428571503671}$ &
		Mixed sampling, discrete features fixed.\\
		\bottomrule
		\end{tabular}
	}
	\caption{Parameters of sampling runs. Here, $t_{\text{run}}$ denotes the total run
		time (including waiting in the processing queue), and
		$\overline{t}_{\text{eval.}}$ is the mean evaluation time of the MC TBR
		model (per single sampled point).}
	\label{tbl:sampling-runs}
\end{table}

Skipping run zero, which was performed using an older, fundamentally different
version of the MC TBR software, and was thus treated as a technical
proof-of-concept, we generated a total of~\num{900000} samples in two runs.
While the first run featured fully uniform sampling of the unrestricted feature
space, the second run used a more elaborate strategy. Interested in further study
of relationships between discrete and continuous features, we selected four
assignments of discrete features (listed in~\cref{tbl:slices}) and fixed them
for all points, effectively slicing the feature space into four corresponding
subspaces. In order to achieve comparability, all such \textit{slices} use the
same samples for the values of continuous features.

\begin{table}[h]
	\centering
	{\footnotesize
		\begin{tabular}{rllllll}
		\toprule
		{} & \multicolumn{6}{c}{Discrete feature assignment}\\
		\cmidrule(lr){2-7}
		Batches & BBM & BCM & BMM & BSM & FCM & FSM \\
		\midrule
		0-99 & \ce{Li4SiO4} & \ce{H2O} & \ce{Be12Ti} & eurofer & \ce{H2O} & eurofer\\
		100-199 & \ce{Li4SiO4} & \ce{He} & \ce{Be12Ti} & eurofer & \ce{H2O} & eurofer\\
		200-299 & \ce{Li4SiO4} & \ce{H2O} & \ce{Be12Ti} & eurofer & \ce{He} & eurofer\\
		300-399 & \ce{Li4SiO4} & \ce{He} & \ce{Be12Ti} & eurofer & \ce{He} & eurofer\\
		\bottomrule
		\end{tabular}
	}
	\caption{Selected discrete feature assignments corresponding to slices in run~2.}
	\label{tbl:slices}
\end{table}

Since some surrogate modelling methods applied in this work are not scale-invariant or
perform suboptimally with arbitrarily scaled inputs, all obtained TBR~samples
(features and TBR~values) were standardised prior to further use. In this
commonly used statistical procedure, features and regression outputs are
independently scaled and offset to attain zero mean and unit variance.

\subsection{Dimensionality Reduction}
\label{sec:dimred}

% TODO: here maybe mention desirable effects of dim. red. (e.g. speedup,
% simplification of the problem, better convergence...)

Model training over high-dimensional parameter spaces (illustrated
in~\cref{fig:tbr-vs-features}) may be improved in many
aspects by carefully reducing the number of variables used to describe the
space. For many applications, feature selection strategies succeed in
identifying a sufficiently representative subset of the original input
variables. However, all given variables were assumed to be physically relevant
to the MC TBR model. On the other hand, feature extraction methods aim to
identify a transformation of the parameter space which decreases dimensionality; even if no individual parameter is separable from the space, some linear combinations of parameters or nonlinear functions of parameters may be.

\begin{figure}[h]
	\centering
	\includegraphics[width=\linewidth]{run1_500k_tbr_vs_feat}
	\caption{Marginalised dependence of TBR on the choice of continuous
	features in \num{500000}~points generated in run~1. Points are coloured by density.}
  \label{fig:tbr-vs-features}
\end{figure}

\subsubsection{Principal Component Analysis}

To pursue linear feature extraction, principal component analysis (PCA)
\cite{Jolliffe2016} was performed via SciKit Learn~\cite{scikit-learn} on a set
of \num{300000} uniform samples of the MC TBR model. % TODO:which run? batch range?

\Cref{fig:pca} shows the resultant cumulative variance of the 11 principal components. The similar share of variance among all features
reveals irreducibility of the TBR model by linear methods.

\begin{figure}[h]
	\centering
	\includegraphics[width=0.6\linewidth]{fig2_pca.jpg}
	\caption{Cumulative variance for optimal features identified by PCA}
	\label{fig:pca}
\end{figure}

\begin{wrapfigure}[30]{r}{0.5\textwidth}
	\centering
	\hspace*{-.3\columnsep}\includegraphics[width=0.58\textwidth]{fig3_allvar.jpg}
	\caption{Semivariograms for MC TBR data with coolant materials: (a) \ce{He},
	(b) \ce{H2O}, (c) \ce{D2O}}
	\label{fig:var}
\end{wrapfigure}

\subsubsection{Variogram Computations}

Kriging is a geostatistical surrogate modelling technique which relies on
correlation functions over distance (lag) in the feature space~\cite{Bouhlel2018}. Although kriging performed poorly for our use case due to high dimensionality, these correlation measures gave insight into similarities between discrete-parameter slices of the data.

\Cref{fig:var} shows the Matheron semivariance~\cite{Matheron1963} for three discrete slices with coolant material varied, but all other discrete parameters fixed. Fits~\cite{KrigingFig} to the Matérn covariance model confirmed numerically that the coolant material is the discrete parameter with the greatest distinguishability in the MC TBR model.

\subsubsection{Autoencoders}

Autoencoders~\cite{SCHMIDHUBER201585} are a family of approaches to
dimensionality reduction driven by artificial neural
networks (ANNs). Faced with a broad selection of alternatives, we opted for a
conventional autoencoder architecture with a single hidden layer. While it
follows that the input and output layers of such
network are sized to accommodate the analysed dataset, the
hidden layer, also called \textit{the bottleneck}, allows for variable number of
neurons that represent a smaller subspace. By scanning
over a range of bottleneck widths and investigating relative changes in the
validation loss, we assess the potential for dimensional reduction.

\begin{wrapfigure}[15]{l}{0.25\textwidth}
	\centering
	{\footnotesize \incfigscale{0.8}{autoencoder}}
	\caption{Autoencoder with input width~$W_0$ and bottleneck width~$W_1$.
	Here, $\text{Dense}(N)$ denotes a fully-connected layer of $N$~neurons.}
	\label{fig:autoencoder}
\end{wrapfigure}

In particular, we consider two equally-sized sets\footnote{Each set contained
\num{100000}~samples from batches 0-99 of the corresponding runs.} of samples:
(a)~a~subset of data obtained
from run~1 and (b)~a~subset of a single slice obtained from run~2. Our
expectation was that while the former case would provide meaningful insights into
correlations within the feature space, the latter would validate our
autoencoder implementation by analysing a set of points that are trivially
reducible in dimensionality due to a number of fixed discrete features.

\begin{wrapfigure}[22]{r}{0.4\textwidth}
	\centering
	\vspace{-4ex}

	\begin{subfigure}[b]{\linewidth}
		\includegraphics[width=\linewidth,trim={0 48px 0 0},clip]{ae_mixed}
	\end{subfigure}

	\vspace{-0.2ex}

	\begin{subfigure}[b]{\linewidth}
		\includegraphics[width=\linewidth]{ae_single_slice}
	\end{subfigure}

	\caption{Autoencoder loss scan on the full feature space (top) and a single slice
		(bottom). Dimensional reduction is indicated by a green arrow.}
	\label{fig:autoencoder-loss}
\end{wrapfigure}

The results of both experiments are shown in~\cref{fig:autoencoder-loss}.
Consistent with our motivation, in each plot we can clearly identify a constant
plateau of low error in the region of large dimensionality followed by a point,
from which a steep increase is observed.
We consider this \textit{critical point} to mark the largest viable
dimensional reduction without significant information loss.
With this approach we find that the autoencoder was able to reduce the
datasets into a subspace of 18~dimensions in the first case and 10~dimensions in
the second case.

Confirming our expectation that in the latter, trivial case the
autoencoder should achieve greater dimensional reduction, we are inclined to
believe that our implementation is indeed operating as intended. However, we
must also conclude that in both examined cases this method failed to produce a
reduction that would prove superior to a naïve approach.\footnote{In both tested cases we
	can trivially eliminate 6~dimensions due to overdetermination of one-hot-encoded
	categorical features, and 2~dimensions corresponding to sum-to-one constraints. Furthermore, in the
	single slice case we may omit 6~additional dimensions due to fixed feature
	assignment.} This is consistent with the previous results obtained by PCA and kriging.

% TODO: Question: is it accurate to say this represents nonlinear feature extraction? re my intro paragraph


\section{Design}
\label{sec:design}

As described in our motivation, there are two major aspects to STEAK's design.  The first is the subsystem for securely and automatically managing keys.  We refer to this subsystem as AutoKey.  The second is the protocol for sending and receiving emails, called Secure Message Request Protocol (SMRP).  SMRP relies on AutoKey to ensure the sender and receiver have the appropriate keys in place before communicating.

\subsection{Architecture}
Our design assumes Alice and Bob both have sets of trusted endpoints that run loosely-synchronized clocks, For hosting hard state across sessions, we leverage Alice and Bob's personal cloud storage accounts.  Additionally, we assume Alice and Bob's endpoints can run code in execution and resource contexts outside of the web browser (such as in a VM).

There are four components to STEAK, beyond cloud storage and endpoint devices (Figure~\ref{fig:overview}). The first is the STEAK endpoint code, which runs separately from the browser.  It performs key management, session management, caching, cloud storage access, cryptographic operations, and UI proxying. The second is the webmail UI, which differs from a conventional webmail UI only in that it issues its RPCs to the locally-hosted endpoint code instead of a remote webmail server.  These two components are intentionally separated for practical reasons, because at the time of this writing there is no way to perform cryptography inside a remotely-served webpage without exposing the user to a multitude of Javascript-based attacks, such as code injection and inter-tab information leakage.

The third is the STEAK server, which helps the endpoints discover when the user has new mail, assists with backwards compatibility.  It also serves copies of users' public keys, certificates, and storage signatures, which are mirrored by one or more metadata repositories (the fourth component).  Metadata repositories are not required for correct execution since they host redundant information, but using one or more of these increases the number of servers Mal must compromise to trick Alice and Bob.

The Alice's endpoint, STEAK server, and metadata repositories work together to implement AutoKey for her.  Alice and Bob's STEAK servers, cloud storage, and endpoints work together to implement SMRP.  Figure~\ref{fig:overview} shows how this manifests in inter-component communications.

\begin{figure}[h!]
\centering
\includegraphics[width=0.5\textwidth]{figures/overview}
\caption{\it Overview of the STEAK architecture, and various data flows that must take place before Alice sends a message to Bob.  Solid-head arrows are part of the AutoKey process.  Unfilled-head arrows are part of the SMRP process.}
\label{fig:overview}
\end{figure}

In AutoKey, each user is given an account public/private key pair, a storage public/private key pair, and one or more signing public/private key pairs.  The private keys are stored encrypted with the user's password, and only decrypted when the device is running a session.  The storage and signing public keys are made available in the form of certificates signed by the account private key.  The use for each key pair is listed in Table~\ref{tab:keypairs}.

\begin{table*}[ht!]
\begin{tabular}{ | l | p{14cm} |}
\hline
\textbf{Key Pair Name} & \textbf{Usage} \\
\hline
Account key pair & Certifying and revoking other public keys. \\
Storage key pair & Sealing/unsealing and signing cloud-hosted data.  Used for message confidentiality and state CIA. \\
Signing key pair & Signing email messages and attachments.  Used for message integrity and authenticity. \\
\hline
\end{tabular}
\caption{\it Names and usages for a user`s key pairs used in STEAK`s AutoKey subsystem.}
\label{tab:keypairs}
\end{table*}

\subsubsection{Storage}
STEAK protects the contents of cloud storage from tampering by replicating cryptographic signatures.  Each file uploaded to cloud storage is sealed with the user's storage private key for confidentiality.  STEAK organizes the files into a Merkel tree, such that each directory contains the signed hash of all of its children's signed hashes.  Each hash is sealed by the storage private key, making external tampering from Mal evident.

Writing data is similar to two-phase commit.  A writer endpoint prepares to write by generating the new root signature, and replicating it to its STEAK server and all metadata repositories.  If they all authenticate and accept it, the writer uploads the data to cloud storage, and then broadcasts a signed success message.  The write completes when the STEAK server and metadata repositories acknowledge upon successful authentication.

Because reads and writes are serialized by the fact that the user does not use two endpoints simultaneously, the metadata repository only needs to store the last root signature it received.  To avoid timing out partway through writing, the endpoint splits large writes into smaller ones and commits them separately.

On read, the endpoint verifies the integrity of cloud storage by fetching the root signatures from these servers and comparing them to the one in cloud storage.  Because Mal cannot compromise all servers, and cannot compromise all channels, the reader will learn if Mal has tampered with a server if the signatures do not match.  These read and write protocols are executed by AutoKey to store trusted public keys in a tamper-evident way.

Given the threat Mal poses to the system, STEAK employs a fail-fast approach to handling storage faults.  This is because unavailability or inconsistencies discovered in publicly-hosted data (such as incorrect signatures) are assumed to be due to external interference from Mal.  This is a reasonable trade-off, because it alerts users and cloud storage operators to Mal's presence.  In practice, STEAK servers are deployed in highly-available infrastructure to reduce the risk of transient faults leading to unavailability.

Because only the user's endpoints may write to the user's cloud storage, STEAK is fundamentally a pull-based architecture.  Instead of sending data from Alice's endpoint to Bob's email server, Alice will write messages into her cloud storage, and Bob will download them later using SMRP.  This is a departure from SMTP, which we exploit to offer an ``un-send mail'' feature and to economically disincentivize spam mail by requiring the sender to pay for storage.

\subsubsection{Usability}
A user interacts with STEAK through the web browser, using the local endpoint as a web proxy.  The UI is stored as files in cloud storage and are signed by the storage private key.  This lets the endpoint verify their authenticity and integrity before serving them over the local trusted RPC channel, effectively preventing code injection attacks from Mal.

Before Alice or Bob can use STEAK, they must set up the endpoint code.  However, this can be made easy in practice (see section~\ref{sec:implementation}).  We assume in the following sections that the endpoints all run instances of the endpoint code in local VMs.

\subsection{Bootstrapping Trust}
Before Alice can use STEAK, she needs an account.  In creating one, she bootstraps AutoKey by establishing her public key and registration date with each component, populating her cloud storage with initial application state, and granting her endpoint permission to access it.  She also establishes security questions and answers to be used to recover her private key, should she forget her password.

\begin{figure}[h!]
\centering
\includegraphics[width=0.5\textwidth]{figures/register}
\caption{\it The STEAK key registration protocol.}
\label{fig:register}
\end{figure}

To do so, her endpoint replicates her account public key and backs up her revocation certificate to more servers than Mal can compromise.  We assume that Mal cannot alter the behavior of the servers during the registration process; if the servers do not behave correctly, the registration fails (Figure~\ref{fig:register}).

From a usability standpoint, creating an account on the STEAK server is similar to doing so on a webmail server.  Alice begins by submitting a desired username and password to the STEAK server through the endpoint, as well as any number of hard-to-guess security questions and answers, and the identifier for an uncompromisable out-of-band channel to confirm the registration (e.g. a phone number or existing email address).  The STEAK-specific extra requirements are the authentication tokens needed to access her cloud storage, and her additional metadata repositories.

Once the information is entered, the endpoint uploads the username and password to the STEAK server, which replies with a one-time-use registration URL via the out-of-band channel (we assume that Eve cannot determine the password in this step).  Alice navigates to the URL to complete her registration.  Once Alice confirms, the STEAK server remembers iterated salted hash of the password and out-of-band channel identifier, so Eve and Mal cannot easily learn either and so Alice can use the channel identifier later to reset her password.

Once Alice's account is created on the STEAK server, the endpoint sets up her keys and certificates.  It generates her public/private key pairs, and signs the storage and signing public keys with the account private key.  It then generates revocation certificates for the account and storage keys, as well as two public certificates---one for the signing key, and one for the storage key---that contain Alice's username, the public key, the timestamp, and a nonce for uniqueness (``pubkey certs'' in Figure~\ref{fig:register}).  It signs these certificate with the account private key.

It then proceeds to replicate the account public key and certificates to each server, using the STEAK server to vouch for her.  To upload them to the STEAK server, It generates an HMAC over them using the password as the shared secret.  Once the STEAK server validates and accepts them (remembering the nonce to prevent re-register attacks), the endpoint uploads them to each metadata repository.  The endpoint authenticates to each using OpenID protocol and Alice's password, where the STEAK server acts as the OpenID provider.  The metadata repositories do not consider a revocation certificate to be in force until Alice activates it later.

The endpoint finishes by populating Alice's cloud storage with STEAK account state, using the authentication tokens she supplied at the beginning of the process.  It uploads her public key certificates as a world-readable files in cloud storage (for Bob to download later) as well as her revocation certificates and account public key (which are NOT encrypted).  It encrypts the private keys and cloud storage credentials using an authenticated symmetric key scheme, deriving symmetric keys from her salted password.  It also seals a copy of the storage private key with the answers to her security questions, so Alice can change her password without losing her data.  The endpoint uploads the security questions and sealed keys to cloud storage, seals the MACs and salts from the encryption with the password, and erases them from RAM, completing the registration and AutoKey bootstrap process.

\subsection{Session Management}
Once AutoKey is bootstrapped, Alice can use multiple endpoints to access her account transparently.  To do so, Alice simply enters her username and password, and the endpoint (via AutoKey) fetches her sealed storage private key, endpoint-specific sealed signing private key, and sealed cloud storage credentials.  If the device has never been used before, the endpoint generates a new signing key certificate and revocation certificate for it, seals the private key with the password, and distributes the certificates to the STEAK server and metadata repositories (which authenticate them with the account public key they obtained on registration).  The servers do not publish the revocation certificates until Alice signals them to do so.

Alice has the option to designate that the endpoint will be used for only one session (akin to a ``This device is public'' checkbox in webmail).  If so, the signing key will have an expiration date in the very near future, e.g. 30 minutes.

When Alice logs out or her session times out, the endpoint has AutoKey erase any secrets from RAM.  As a precaution, it also erases any data it cached data, and will erase cached data automatically if it restarts. Cached data is always sealed with one of Alice's public keys before being written to local storage, preventing Eve from breaking confidentiality via offline analysis.

\subsection{Key Distribution}
In AutoKey, Bob's endpoint must learn Alice's account, storage, and signing public keys before he can communicate with her.  Once it has them, AutoKey puts them into his cloud storage, executing the two-phase write protocol so his other endpoints can securely and automatically fetch them later.  The challenges are in obtaining them for the first time in such a way that Eve and Mal cannot trick him into learning the wrong ones, and in revoking trust in them without also being tricked.

Bob's endpoint will trust one of Alice's public keys only if AutoKey can get unanimous agreement on the key's value from each server that hosts them, and only if the key is not expired.  Similarly, AutoKey will check for an activated revocation certificate if all servers agree on the same key, and the key is different from the currently trusted key.  This strategy works under our threat model because without Alice's password, Mal is not powerful enough to send the wrong key on every channel, or change it to every server.  Bob waits for unanimous disagreement before checking for a revocation certificate to avoid Mal tricking him by activating it on one server.

While Bob trusts the keys, AutoKey periodically checks to see if it Alice's servers have changed them.  Because the account public key and storage public key do not change as often as the signing key (see the next section), it will check the account key at most once per session.  However, it will check the storage and signing public keys every time Bob sends a message to Alice.

To advertise her keys, Alice's STEAK address is a well-formed email address that indicates her username, her cloud storage provider, her STEAK server, and any metadata repositories that host her keys.  We use the character `\^{}' to separate them---for example, Alice's STEAK address might be alice\^{}cloudstorage.com\^{}keybackup.org@mail.net, indicating that her data is hosted at cloudstorage.com, her keys are replicated to keybackup.org, and her STEAK server is mail.net.  Each service makes both the keys and certificates available via canonical URLs derived from the username and the service name.  Bob's endpoint has AutoKey use TLS-secured channels with authenticated cipher suites (i.e. AES-GCM) to fetch copies from each service, in order to hedge against external tampering from Mal (but not eavesdropping from Eve).

In the event that some of Alice's services are unreachable, AutoKey continues to trust Bob's copies of Alice's public keys even if there is disagreement among the online servers.  This is to prevent Mal from weakening the system with denial-of-service attacks.  In practice, Alice's services run on highly-available infrastructure, so unreachability problems are expected to be rare and transient.

\subsection{Key Revocation}

\begin{figure}[h!]
\centering
\includegraphics[width=0.5\textwidth]{figures/revoke}
\caption{\it The STEAK key revocation protocol.}
\label{fig:revoke}
\end{figure}

Inevitably, AutoKey will need to revoke Alice's keys for her.  When Alice removes access permission from a trusted endpoint device, AutoKey revokes its signing key.  When she changes or resets her password, AutoKey revokes and regenerates her keys by default because the reason for doing so may be due to a password compromise.

Revoking a signing key is a matter of activating its stored revocation certificate (Figure~\ref{fig:revoke}).  To do so, AutoKey first obtains it by downloading it from each the servers, using a request signed by the account private key.  It also gets a copy from cloud storage.  At least one of the servers will reply with the correct revocation certificate, since Mal cannot compromise all of them under our threat model.

AutoKey then re-uploads it in a signed request to the servers, indicating that the should publish it.  The servers erase the old public key certificate on successful verification, and AutoKey removes it from cloud storage.  Then, when Bob contacts Alice next, his endpoint will detect the key discrepancy, discover the revocation certificate, and stop trusting the old signing key.

If Eve compromises Alice's password, she will be able to read her incoming messages, and messages sent to others.  If Mal compromises Alice's password, she can do anything with the account.  To regain control, Alice resets her password, effectively re-registering her account and re-bootstrapping AutoKey using registration protocol described earlier (but with two small differences described below).  As before, we assume that Mal cannot alter the behavior of the servers during re-registration.

Unlike with first-time registration, the STEAK server requires Alice to submit the same out-of-band communication channel as she did before.  Also, AutoKey sets a flag while uploading new public key information to ask for a reply containing the old revocation certificate.  It also obtains the copy uploaded earlier from cloud storage, and then executes a variant of the signing key revocation protocol to publish the revocation certificates for her account and storage keys.  The only differences are that the revocation certificates will be signed by the new account key, and that the servers will additionally verify the request with OpenID to ensure that it came from Alice (the only person who knows the new password).

When Alice logs in next, her endpoint ``imports'' her old account data by unsealing it with the old storage key and re-sealing it with the new storage key.  If Alice remembers her old password, her endpoint decrypts the old storage key automatically.  If she does not, her endpoint obtains the copy of the storage key sealed with the answers to her security questions, and prompts her for them to decrypt it.

Deleting an account is similar to revoking the keys.  The only difference in the process is that no new keys are generated.

\subsection{Sending, Receiving, and Un-Sending}
Once Alice and Bob have exchanged public keys with AutoKey, they communicate with SMRP, described in this section.  In SMRP, Alice sends Bob a message by sealing it with his storage public key, uploading it to her cloud storage, and making it world-readable. Bob's endpoint downloads and decrypts it, sanitizes it, and serves it to Bob's browser for him to read. The same principle applies to attachments, which in STEAK are sent as separate files to be downloaded.  Alice makes a copy for herself in her ``sent'' folder, if desired.

If Bob expects email from Alice, he can search Alice's cloud storage for new messages and fetch them.  The UI allows him to query individual contacts for new messages.

The challenge for Bob is to discover when Alice sent him an unsolicited message.  To address this in SMRP, Bob's STEAK server acts as a notification service for new email.  Alice sends Bob's STEAK server a message metadata record, sealed with his storage public key and signed with her signing private key, that identifies herself as the sender and Bob as the recipient.  It serves as a hint to Bob that he has unsolicited mail, and tells him the message recipients, the subject, the human-readable names of the attachments, and the attachment signatures.  This information is hidden from the STEAK server to provide end-to-end message CIA, and its small size makes it easy for it to store many of them.

When Bob accesses his email, his endpoint downloads and decrypts the unread message metadata records from the server.  Each of them appear in Bob's UI as unread messages. The UI tells Bob the subject, recipients, and attachment names.  Once Bob's endpoint reads and stores the metadata records, the STEAK server is free to erase them.

When Bob opens an unread message from Alice, his endpoint downloads, decrypts, and verifies the authenticity and integrity of Alice's message body, using the public keys obtained by AutoKey. Once verified, Bob reads it via the UI. To download an attachment, the endpoint streams it from Alice's cloud storage, verifies it, decrypts it, and delivers it to the UI as a file download.  As a performance optimization (and to assist automatic spam filtering), the endpoint prefetches message bodies as they are discovered.

Mailing lists in SMRP are treated like user accounts.  The only difference is that every participant on the list has a sealed copy of the account storage key and a personal signing key.

In SMRP, Alice can ``un-send'' a message by erasing the body and attachments from cloud storage.  This allows her to withdraw messages sent in haste, or sent accidentally to unintended people.  Bob will discover that she deleted it (i.e. he will receive a metadata record for a message that does not exist), but this may be preferable to having Bob read the entire message.  As such, once Bob obtains a message's body and attachments, his endpoint replicates them to his cloud storage by default to keep them available even if Alice deletes it later.

\subsection{Searching, Tagging, and Filtering}
Beyond sending and receiving email, webmail users expect automatic spam filtering, the ability to organize messages and conversations, and the ability to search them.  In traditional webmail systems, this functionality resides on the server.  The challenge in providing it in STEAK is in moving it to the endpoint to preserve confidentiality, but without compromising features.

Tagging messages is a matter of associating a given message with a bag of tags that Bob defines.  Bob's endpoint incrementally builds an index that pairs each tag to a list of message identifiers.  To search messages by tag, the endpoint fetches a page of the tag's index, looks up the messages, and serves them to the UI.

To search messages, the endpoint incrementally builds a search index as Bob reads them, using an off-the-shelf indexer.  The indices are updated and synchronized with cloud storage in the background as he opens and reads messages.  As a performance optimization, the endpoint lazily downloads the index by chunk they are needed by the indexer.  It caches them for the session, and asynchronously replicates modifications.

To filter messages, the endpoint uses a combination of a locally-trained classifier and sender blacklists.  Bob has the option of marking messages as spam and marking senders as spammers, in which case the endpoint feeds the message body into its local spam classifier and replicates the classifier's new model parameters to cloud storage.  This allows the classifier to be used across endpoints without revealing its parameters.  If Bob marks a contact as a spammer, AutoKey revokes trust in its public key, and the endpoint will ignore future messages from it.

Using only a local spam filter is desirable for confidentiality.  The spam classifier model parameters can leak information about the contents of the messages they have classified, so it is important that Bob's endpoint not share this information directly.  This is in contrast to webmail providers today, which learn to classify spam by monitoring many user accounts.  However, empirical tests~\cite{local-spam-filter-eval} suggest that existing local spam filters can achieve upwards of 98\% effectiveness in practice, suggesting that our strategy should not significantly impact usability if the endpoint code ships with a pre-trained classifier.

\subsection{Backwards Compatibility}
Because email is already a widely-used service, STEAK must remain backwards compatible with it to allow Alice and Bob to communicate with Charles, a user who relies on conventional email.  To do so, the STEAK server provides an SMTP/SMRP gateway that translates one protocol into the other.  The STEAK server has its own cloud storage to hold messages from Charles to serve to Alice via SMRP.  Alice's messages to Charles are automatically routed through SMTP because Charles does not have a well-formed STEAK email address.

The gateway alone does not provide CIA guarantees.  If Charles wants a limited degree of CIA, STEAK offers one of two options that require a minimal change in his workflow.  First, if Charles uses PGP already, he will send his public key and encrypted messages via SMTP.  AutoKey obtains Charles' public key automatically.  While this is less trustworthy than STEAK's approach, it is better than nothing, because Mal has only one very short window of time to alter the public key.

If Charles does not use PGP, he must first agree with Alice on a shared secret out-of-band, and assume that Mal does not compromise the STEAK server or the TLS CA server that vouches for its TLS public key.  To send her a message securely, he navigates to her STEAK server, enters the secret, and is given a webmail form for composing her a message.  When he submits his message, STEAK it available to Alice via SMRP.

When Alice replies via SMRP, the STEAK server sends Charles a URL instead of the message body.  When opened, the STEAK server gives him a specially-crafted HTML page that contains Alice's ciphertext, a decryption algorithm in Javascript, and a secret submission form.  When Charles enters the secret, the page decrypts the message for him.


\documentclass[12pt]{article}
\usepackage[dutch]{babel}

\title{Prolog Logical Expressions}
\author{%
    Maico Timmerman\\%
    10542590%
}

\date{\today}

\begin{document}
\maketitle

\section{Exercises}

\textbf{Give logical expressions for the following sentences:}\\
Mary knows all important artists:\\
$M = all(X, artists(X), important(X) => knows(mary, X))$.\\
\\
Every teacher who teaches French and studies music understands Chopin\\
\emph{M = all(X, teacher(X)and teaches(X, french) and studies(X, music) =$>$ understands(X, chopin).}\\
\\
A charming lady from Florida runs a beauty shop in Sydney:\\
\emph{M = exists(X, lady(X) and charming(X) and lives(X, florida) and Y, shop(Y) and beautiful(Y) and from(Y, florida) and runs(X, Y)).}
\end{document}


\section{Models of Associative Memory}

Three models for associative memory are explored in this section, two traditional machine learning models and one emerging technology. While the traditional models (Hopfield networks and Boltzmann machines) may be considered abstract models defined independent of underlying hardware, they are in practise often employed on commodity hardware with a von-Neumann architecture. The emerging technology (memristors) however, enables a radically different computer architectures on top of which new models for associative memory (and other machine learning tasks) may be developed, and for which existing models may be ported to.

% === [ Subsections ] ==========================================================

\input{sections/2_models_of_associative_memory/1_hopfield_network}
\input{sections/2_models_of_associative_memory/2_boltzmann_machine}
\input{sections/2_models_of_associative_memory/3_memory_resistor}


\chapter*{Abstract}
\addcontentsline{toc}{chapter}{Abstract}
Detecting outliers in datasets has been important in many domains. There are various Machine Learning methods which have been developed to detect outliers. Two of them are Local Outlier Factor and One Class Support Vector Machine.

The purpose of this research is to compare Local Outlier Factor and One Class Support Vector Machines models in order to find the better performing algorithm in a highly unbalanced dataset. The dataset was taken from the Kaggle data science repository. Specifically, a fraudulent credit card dataset was used to evaluate the models.

Evaluation of these models is based on True Positive Rate and False Positive Rate. Comparing results of the algorithms shows that One Class Support Vector Machine performs better than Local Outlier Factor in the given dataset.

% % % % % % % % % % % one reference % % % %

\begin{comment}
@ARTICLE{Larry,
		  AUTHOR = {Larry M. Manevitz and Malik Yousef},
		  TITLE = {One-Class {SVM}s for Document Classification},
		  JOURNAL = {Journal of Machine Learning Research 2 (2001) 139-154},
		  YEAR = {2001}
}
\end{comment}


\par
\section{Data Structure}
\label{section:Drand:dataStructure}
\par
The {\tt Drand} object has nine fields.
\begin{itemize}
\item
{\tt double seed1} : first seed
\item
{\tt double seed2} : second seed
\item
{\tt double base1} : first base
\item
{\tt double base2} : second base
\item
{\tt double lower} : lower bound for a uniform distribution
\item
{\tt double upper} : upper bound for a uniform distribution
\item
{\tt double mean} : mean for a normal distribution
\item
{\tt double sigma} : variation for a normal distribution
\item
{\tt int mode}:
mode of the object, uniform is {\tt 1}, normal is {\tt 2}
\end{itemize}