\documentclass[american,ignorenonframetext,notheorems,aspectratio=1610]{beamer}
\usetheme[compress]{Madrid}
\usecolortheme{albatross}
\usepackage{tikz,tikzscale}
\usetikzlibrary{snakes}
\input{mixed/fig/tikzsettings}
\def\restrict{r}
\def\prolongate{p}

\usepackage{../mathsim}
\usepackage{times}
\usepackage{xr}
\externaldocument{main}
\usepackage{mfirstuc}
\usepackage{mathtools}
\mathtoolsset{showonlyrefs}

\def\footnote#1{}
\def\putindex#1{#1}
\title{Finite Elements}
\author{Guido Kanschat}
\date{\today}
\begin{document}
\frame{\maketitle}
\frame{\frametitle{Overview}\tableofcontents[hideallsubsections]}
\section{Elliptic PDE and Their Weak Formulation}
\frame{\sectoc}
\subsection{Elliptic boundary value problems}

\frame {\input{blocks/Notation-coordinates.tex}}
\frame {\input{blocks/Notation-partial-derivative.tex}}
\frame {\input{blocks/Notation-elim-coord.tex}
  \input{blocks/Definition-lin-pde-2order.tex}}
\frame {\input{blocks/Definition-poisson-eqn.tex}}
\frame {\input{blocks/Definition-domain.tex}}
\frame {\input{blocks/Definition-boundary-conditions.tex}}
\frame {\input{blocks/Definition-dirichlet-problem-differential.tex}}
\frame {\input{blocks/Theorem-Dirichlet-principle.tex}}
\frame {\input{blocks/Theorem-Dirichlet-variational-principle.tex}
  \input{blocks/Corollary-Dirichlet-uniqueness.tex}}
\frame {\input{blocks/Lemma-reduction-to-zero-bc.tex}}
\frame {\input{blocks/Notation-l2.tex}}
\frame {\input{blocks/Lemma-Friedrichs-continuous.tex}
  \input{blocks/Problem-Friedrichs.tex}}
\frame {\input{blocks/Lemma-h1-norm.tex}}
\frame {\input{blocks/Lemma-Dirichlet-energy-boundedness.tex}
  \input{blocks/Lemma-minimizing-sequence.tex}}
\frame {\input{blocks/Definition-h10.tex}
  \input{blocks/Lemma-Friedrichs-h1.tex}}
\frame {\input{blocks/Definition-weak-formulation.tex}
  \input{blocks/Theorem-weak-unique-solution-1.tex}}

\frame {\input{blocks/Lemma-neumann-weak.tex}}
\frame {\input{blocks/Definition-natural-bc.tex}}
\frame {\input{blocks/Lemma-mixed-bc-weak.tex}}

\subsection{Hilbert Spaces and Bilinear Forms}
\frame{\tableofcontents[currentsection,subsectionstyle=show/shaded/hide]}

\frame {\input{blocks/Definition-inner-product.tex}}
\frame {\input{blocks/Theorem-bcs-inequality.tex}
  \input{blocks/Lemma-inner-product-norm.tex}}
\frame {\input{blocks/Definition-complete.tex}}
\frame {\input{blocks/Definition-Banach-hilbert.tex}}
\frame {\input{blocks/Definition-orthogonal.tex}}
\frame {\input{blocks/Definition-orthogonal-complement.tex}}
\frame {\input{blocks/Lemma-orthogonal-closed.tex}}
\frame {\input{blocks/Theorem-orthogonal-complement.tex}}
% \frame {\input{blocks/Corollary-ortho-density.tex}}
\frame {\input{blocks/Definition-ortho-projection.tex}}
\frame {\input{blocks/Definition-dual-space.tex}}
\frame {\input{blocks/Theorem-Riesz-representation.tex}}
\frame {\input{blocks/Definition-bilinear-form.tex}}
\frame {\input{blocks/Lemma-pde-bilinear.tex}}
\frame {\input{blocks/Lemma-lax-milgram.tex}}
\frame {\input{blocks/Lemma-weak-well-posed.tex}
  \input{blocks/Definition-elliptic.tex}}

\subsection{Fast facts on Sobolev spaces}
\frame{\tableofcontents[currentsection,subsectionstyle=show/shaded/hide]}

\frame {\input{blocks/Notation-multi-index.tex}}
\frame {\input{blocks/Definition-distributional-derivative.tex}}
\frame {\input{blocks/Definition-Wkp.tex}
  \input{blocks/Corollary-wkp-embedding.tex}}
\frame {\input{blocks/Definition-hkp.tex}
  \input{blocks/Theorem-meyers-serrin.tex}}

\frame {\input{blocks/Definition-boundary-smoothness.tex}}
\frame {\input{blocks/Definition-continuous-embedding.tex}}
\frame {\input{blocks/Theorem-sobolev-embedding.tex}}
\frame {\input{blocks/Lemma-trace-continuous.tex}
  \input{blocks/Theorem-trace.tex}}
\frame {\input{blocks/Definition-hoelder-spaces.tex}}
\frame {\input{blocks/Theorem-hoelder-embedding.tex}
  \input{blocks/Corollary-sobolev-continuous.tex}}

\subsection{Properties of solutions}
\frame{\tableofcontents[currentsection,subsectionstyle=show/shaded/hide]}

\frame {\input{blocks/Definition-wkp-loc.tex}
  \input{blocks/Theorem-gt-8-8.tex}
  \input{blocks/Theorem-gt-8-10.tex}
  \input{blocks/Corollary-gt-8-10.tex}}
\frame {\input{blocks/Theorem-gt-8-13.tex}
  \input{blocks/Corollary-h2-solution-bvp.tex}
  \input{blocks/Remark-classical-smooth.tex}
  \input{blocks/Remark-classical-convex.tex}}
\frame {\input{blocks/Theorem-kondratev.tex}}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Conforming Finite Element Methods}
\frame{\sectoc}
\subsection{Meshes, shape functions, and degrees of freedom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame {\input{blocks/Definition-facets.tex}
  \input{blocks/Definition-mesh.tex}}
\frame {\input{blocks/Definition-finite-element.tex}
\input{blocks/Notation-dofs.tex}}
\frame {\input{blocks/Definition-node-topology.tex}
  \input{blocks/Definition-fe-space.tex}}
\frame {\input{blocks/Notation-global-local.tex}}
\frame {\input{blocks/Definition-local-global.tex}}
\frame {\input{blocks/Lemma-fe-support.tex}}
\frame {\input{blocks/Lemma-mesh-continuity.tex}
  \input{blocks/Lemma-nodal-continuity.tex}}

\frame {\input{blocks/Definition-barycentric-coordinates.tex}}
\frame {\input{blocks/Lemma-barycentric-affine.tex}
  \input{blocks/Corollary-barycentric-interpolation.tex}}

\begin{frame}
  \frametitle{The $P_1$ element in barycentric coordinates}
  \begin{columns}
    \begin{column}{.5\textwidth}
      \begin{center}
        \includegraphics[width=.6\textwidth]{mixed/fig/p1-p.tikz}
      \end{center}
    \end{column}
    \begin{column}{.5\textwidth}
      \begin{gather*}
        \phi_i = \lambda_i,
        \quad i=0,1,2
      \end{gather*}
    \end{column}
  \end{columns}
\end{frame}

\begin{frame}
  \frametitle{The $P_2$ element in barycentric coordinates}
  \begin{columns}
    \begin{column}{.5\textwidth}
      \begin{center}
        \includegraphics[width=.6\textwidth]{mixed/fig/p2-p.tikz}
      \end{center}
    \end{column}
    \begin{column}{.5\textwidth}
      \begin{xalignat*}2
        \phi_{ii} &= 2\lambda_i^2 - \lambda_i,
        &i&=0,1,2\\
        \phi_{ij} &= 4\lambda_i\lambda_j
        &j&\neq i
      \end{xalignat*}
    \end{column}
  \end{columns}
\end{frame}

\begin{frame}
  \frametitle{The $P_3$ element in barycentric coordinates}
  \begin{columns}
    \begin{column}{.5\textwidth}
      \begin{center}
        \includegraphics[width=.6\textwidth]{mixed/fig/p3-p.tikz}
      \end{center}
    \end{column}
    \begin{column}{.5\textwidth}
      \begin{xalignat*}2
        \phi_{iii} &= \tfrac12 \lambda_i(3\lambda_i-1)(3\lambda_i-2)
        &i&=0,1,2\\
        \phi_{ij} &= \tfrac92\lambda_i\lambda_j(3\lambda_j-1)
        &j&\neq i\\
        \phi_0 &= 27\lambda_0\lambda_1\lambda_2
      \end{xalignat*}
    \end{column}
  \end{columns}
\end{frame}

\frame {\input{blocks/Definition-galerkin-approximation.tex}}
\frame {\input{blocks/Corollary-galerkin-equations.tex}}
\frame {\input{blocks/Lemma-discrete-lax-milgram.tex}
  \input{blocks/Lemma-cea.tex}}
\frame {\input{blocks/Lemma-fe-matrix.tex}}
\frame {\input{blocks/Algorithm-matrix-assembling.tex}}

\frame {\input{blocks/Definition-tensor-product-polynomials.tex}}
\frame {\input{blocks/Lemma-tensor-product-node-functionals.tex}}

\begin{frame}
  \frametitle{Example: $Q_2$ shape functions}
  \begin{center}
    \includegraphics[height=.27\textheight]{graph/shape0}
    \includegraphics[height=.27\textheight]{graph/shape1}
    \includegraphics[height=.27\textheight]{graph/shape2}

    \includegraphics[height=.27\textheight]{graph/shape3}
    \includegraphics[height=.27\textheight]{graph/shape4}
    \includegraphics[height=.27\textheight]{graph/shape5}

    \includegraphics[height=.27\textheight]{graph/shape6}
    \includegraphics[height=.27\textheight]{graph/shape7}
    \includegraphics[height=.27\textheight]{graph/shape8}
  \end{center}
\end{frame}

\frame {\input{blocks/Lemma-tensor-product-trace.tex}}

\begin{frame}
  \frametitle{Example: $Q_2$ continuous basis (selection)}
  \begin{center}
    \includegraphics[height=.27\textheight]{graph/cgbasis1-02}
    \includegraphics[height=.27\textheight]{graph/cgbasis1-03}
    \includegraphics[height=.27\textheight]{graph/cgbasis1-15}
    \includegraphics[height=.27\textheight]{graph/cgbasis1-16}

    \includegraphics[height=.27\textheight]{graph/cgbasis1-07}
    \includegraphics[height=.27\textheight]{graph/cgbasis1-13}
    \includegraphics[height=.27\textheight]{graph/cgbasis1-18}
    \includegraphics[height=.27\textheight]{graph/cgbasis1-22}

    \includegraphics[height=.27\textheight]{graph/cgbasis1-17}
    \includegraphics[height=.27\textheight]{graph/cgbasis1-23}
    \includegraphics[height=.27\textheight]{graph/cgbasis1-20}
    \includegraphics[height=.27\textheight]{graph/cgbasis1-24}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{Example: $Q_2$ discontinuous basis (selection)}
  \begin{center}
    \includegraphics[height=.27\textheight]{graph/dgbasis1-08}
    \includegraphics[height=.27\textheight]{graph/dgbasis1-15}
    \includegraphics[height=.27\textheight]{graph/dgbasis1-20}
    \includegraphics[height=.27\textheight]{graph/dgbasis1-27}

    \includegraphics[height=.27\textheight]{graph/dgbasis1-07}
    \includegraphics[height=.27\textheight]{graph/dgbasis1-19}
    \includegraphics[height=.27\textheight]{graph/dgbasis1-23}
    \includegraphics[height=.27\textheight]{graph/dgbasis1-30}

    \includegraphics[height=.27\textheight]{graph/dgbasis1-26}
    \includegraphics[height=.27\textheight]{graph/dgbasis1-33}
    \includegraphics[height=.27\textheight]{graph/dgbasis1-24}
    \includegraphics[height=.27\textheight]{graph/dgbasis1-22}
  \end{center}
\end{frame}

\subsubsection{Mapped finite elements}

\frame {\input{blocks/Definition-mapped-mesh.tex}}
\frame {\input{blocks/Example-mapping-linear.tex}}
\frame {\input{blocks/Example-mapping-bilinear.tex}}
\frame {\input{blocks/Definition-mapped-fe.tex}}
\frame {\input{blocks/Lemma-mapped-norms-affine.tex}}
\frame {\input{blocks/Lemma-shape-regular-transformation.tex}}
\frame {\input{blocks/Assumption-mapping-decomposition.tex}}
\frame {\input{blocks/Lemma-scaling-1.tex}}

\subsection{A priori error analysis}
\frame{\subtoc}

\frame {\input{blocks/Lemma-poincare.tex}}
\frame {\input{blocks/Lemma-bramble-hilbert.tex}}
%\frame {\input{blocks/Lemma-b-h-projector.tex}}
\frame {\input{blocks/Definition-mesh-family.tex}}
\frame {\input{blocks/Definition-nodal-interpolation.tex}
  \input{blocks/Lemma-nodal-interpolation.tex}}
\frame {\input{blocks/Definition-broken-sobolev-norm.tex}}
\frame {\input{blocks/Theorem-fe-interpolation.tex}
  \input{blocks/Corollary-fe-approximation.tex}}
\frame {\input{blocks/Theorem-fe-convergence.tex}}

\subsubsection{Estimates of stronger norms}

\frame {\input{blocks/Definition-stronger-norm.tex}}
\frame {\input{blocks/Lemma-inverse-estimate.tex}}
\frame {\input{blocks/Theorem-h2-error.tex}}

\subsubsection{Estimates of weaker norms}

\frame {\input{blocks/Definition-dual-problem.tex}}
\frame {\input{blocks/Lemma-poisson-dual.tex}}
\frame {\input{blocks/Assumption-elliptic-regularity.tex}}
\frame {\input{blocks/Theorem-fe-l2.tex}
  \input {blocks/Corollary-fe-functional.tex}}

\subsubsection{Green's function and maximum norm estimates}

\frame {\input {blocks/Definition-greens-function.tex}
  \input {blocks/Theorem-greens-function-rd.tex}}
\frame {\input {blocks/Lemma-greens-function-domain.tex}}
\frame {\input {blocks/Theorem-greens-function-representation.tex}}
\frame {\input {blocks/Theorem-linfty-error.tex}}

\subsection{A posteriori error analysis}
\frame{\subtoc}

\frame {\input {blocks/Definition-a-posteriori.tex}}
\frame {\input {blocks/Definition-locally-quasi-uniform.tex}}
\frame {\input {blocks/Definition-fem-neighborhood.tex}}
\frame {\input {blocks/Theorem-clement.tex}}
\frame {\input {blocks/Theorem-scott-zhang.tex}}
\frame {\input {blocks/Theorem-schoeberl-interpolation.tex}}
\frame {\input {blocks/Definition-residual.tex}}
\frame {\input {blocks/Lemma-residual-hm1.tex}}
\frame {\input {blocks/Definition-mvl-jmp.tex}}
\frame {\input {blocks/Definition-residual-strong.tex}}
\frame {\input {blocks/Lemma-residual-upper-bound.tex}}
\frame {\input {blocks/Definition-osc.tex}}
\frame {\input {blocks/Definition-residual-estimator.tex}}
\frame {\input {blocks/Theorem-residual-estimate.tex}}

\section{Variational Crimes}
\frame{\sectoc}
\subsection{Numerical quadrature}
\frame {\input {blocks/Lemma-strang-1.tex}}
\frame {\input {blocks/Definition-tensor-product-quadrature.tex}
  \input {blocks/Lemma-tensor-product-gauss.tex}}
\frame {\input {blocks/Assumption-bilinear-form-quadrature.tex}}
\frame {\input {blocks/Definition-bilinear-quadrature.tex}}
\frame {\input {blocks/Lemma-quadrature-stability.tex}}
\frame {\input {blocks/Theorem-quadrature-error-bilinear.tex}}
\frame {\input {blocks/Lemma-product-sobolev-norm.tex}}
\frame {\input {blocks/Theorem-quadrature-error-rhs.tex}}

\section{Solving the Discrete Problem}
\frame{\sectoc}
\subsection{Richardson's method}
\frame {\input {blocks/Definition-spd-condition-number.tex}}
\frame {\input {blocks/Definition-matrix-condition-number.tex}}
\frame {\input {blocks/Lemma-richardson-error-step.tex}}
\frame {\input {blocks/Theorem-richardson-convergence1.tex}}
\frame {\input {blocks/Definition-richardson-method.tex}}
\frame {\input {blocks/Theorem-richardson-convergence2.tex}}
\frame {\input {blocks/Definition-riesz-isomorphism.tex}}
\frame {\input {blocks/Definition-p-richardson-method.tex}}
\subsection{The conjugate gradient method}
\frame{\subtoc}
\frame {\input {blocks/Definition-steepest-descent.tex}}
\frame {\input {blocks/Lemma-steepest-descent.tex}}
\frame {\input {blocks/Definition-cg-method.tex}}
\frame {\input {blocks/Definition-pcg-method.tex}}
\frame {\input {blocks/Definition-krylov-space.tex}}
\frame {\input {blocks/Lemma-cg-orthogonality.tex}}
\frame {\input {blocks/Lemma-cg-minimization.tex}}
\frame {\input {blocks/Theorem-cg-convergence.tex}}

\subsection{Condition numbers of finite element matrices}
\frame{\subtoc}
\frame {\input {blocks/Notation-up-to-a-constant.tex}}
\frame {\input {blocks/Definition-mass-stiffness.tex}}
\frame {\input {blocks/Lemma-condition-number-mass-matrix.tex}}
\frame {\input {blocks/Corollary-refined-condition-number.tex}}
\frame {\input {blocks/Theorem-condition-number-stiffness-matrix.tex}}

\subsection{Multigrid methods}
\frame {\input {blocks/Algorithm-mgm.tex}}

\section{Bibliography}
\frame{\bibliographystyle{alpha}
\bibliography{all}}
\end{document}

%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End:


\section{Language}~\label{sec:language}

Copilot is embedded into the functional programming language Haskell
\cite{PeytonJones02}, and a working knowledge of Haskell is necessary to use
Copilot effectively. Copilot is a pure declarative language; i.e., expressions
are free of side-effects and are referentially transparent.  A program written
in Copilot, which from now on will be referred to as a \emph{specification}, has
a cyclic behavior, where each cycle consists of a fixed series of steps:

\begin{itemize}
\item Sample external variables and arrays.
\item Update internal variables.
\item Fire external triggers. (In case the specification is violated.)
\item Update observers (for debugging purpose).
\end{itemize}

\noindent We refer to a single cycle as an \emph{iteration} or a \emph{step}.

All transformation of data in Copilot is propagated through streams.
A stream is an infinite, ordered sequence of values which must conform to the same type.
E.g., we have the stream of Fibonacci numbers:

\begin{center}
$s_{fib} = \{0, 1, 1, 2, 3, 5, 8, 13, 21, \dots \}$
\end{center}

\noindent We denote the $n$th value of the stream $s$ as $s(n)$, and the first
value in a sequence $s$ as $s(0)$. For example, for $s_{fib}$ we have that $s_{fib}(0) = 0$,
$s_{fib}(1) = 1$, $s_{fib}(2) = 1$, and so forth.

Constants as well as arithmetic, boolean, and relational operators are
lifted to work pointwise on streams:

\noindent
%\begin{minipage}{0.3\textwidth}
\begin{lstlisting}[language = Copilot, frame = single]
x :: Stream Int32
x = 5 + 5

y :: Stream Int32
y = x * x

z :: Stream Bool
z = x == 10 && y < 200
\end{lstlisting}
%\end{minipage}

\noindent Here the streams {\tt x}, {\tt y}, and {\tt z} are simply
\emph{constant streams}:

\begin{center}
$\mathtt{x} \leadsto \{10, 10, 10, \dots \}$,
$\mathtt{y} \leadsto \{100, 100, 100,  \dots \}$,
$\mathtt{z} \leadsto \{\mbox{T},\; \mbox{T},\; \mbox{T},\; \dots \}$
\end{center}

Two types of \emph{temporal} operators are provided, one for delaying streams and one for
looking into the future of streams:
%
\begin{lstlisting}[language = Copilot, frame = single]
(++) :: [a] -> Stream a -> Stream a
drop :: Int -> Stream a -> Stream a
\end{lstlisting}
%
Here {\tt xs ++ s} prepends the list {\tt xs} at the front of the stream {\tt s}.
For example the stream {\tt w} defined as follows, given our previous definition
of {\tt x}:
%
\begin{lstlisting}[language = Copilot, frame = single]
w = [5,6,7] ++ x
\end{lstlisting}
%
evaluates to the sequence
$\mathtt{w} \leadsto \{5, 6, 7, 10, 10, 10, \dots\}$.
The expression {\tt drop k s} skips the first {\tt k} values of the stream {\tt
  s}, returning the remainder of the stream.
For example we can skip the first two values of {\tt w}:
%
\begin{lstlisting}[language = Copilot, frame = single]
u = drop 2 w
\end{lstlisting}
%
which yields the sequence
$\mathtt{u} \leadsto \{7, 10, 10, 10, \dots\}$.

\subsection{Streams as Lazy-Lists} \label{sec:stream}

A key design choice in Copilot is that streams should mimic \emph{lazy lists}.
In Haskell, the lazy-list of natural numbers can be programmed like this:
%
\begin{lstlisting}[language = Copilot, frame = single]
nats_ll :: [Int32]
nats_ll = [0] ++ zipWith (+) (repeat 1) nats_ll
\end{lstlisting}
%
As both constants and arithmetic operators are lifted to work pointwise on
streams in Copilot, there is no need for {\tt zipWith} and {\tt repeat} when
specifying the stream of natural numbers:
%
\begin{lstlisting}[language = Copilot, frame = single]
nats :: Stream Int32
nats = [0] ++ (1 + nats)
\end{lstlisting}
%
In the same manner, the lazy-list of Fibonacci numbers can be specified  in Haskell as follows:
%
\begin{lstlisting}[language = Copilot, frame = single]
fib_ll :: [Int32]
fib_ll = [1, 1] ++ zipWith (+) fib_ll (drop 1 fib_ll)
\end{lstlisting}
%
In Copilot we simply throw away {\tt zipWith}:
\begin{lstlisting}[language = Copilot, frame = single]
fib :: Stream Int32
fib = [1, 1] ++ (fib + drop 1 fib)
\end{lstlisting}

Copilot specifications must be \emph{causal}, informally meaning that
stream values cannot depend on future values.  For example, the following stream
definition is allowed:
%
\begin{lstlisting}[language = Copilot, frame = single]
f :: Stream Word64
f = [0,1,2] ++ f

g :: Stream Word64
g = drop 2 f
\end{lstlisting}
%

But if instead {\tt g} is defined as {\tt g = drop 4 f}, then the definition is
disallowed.  While an analogous stream is definable in a lazy language, we bar
it in Copilot, since it requires future values of {\tt f} to be
generated before producing values for {\tt g}.  This is not possible since
Copilot programs may take inputs in real-time from the environment (see
Section~\ref{subsec:interacting}).

\subsection{Structs}
Structs require some special attentation in Copilot, as we cannot magically
import the definition of the struct in Copilot. In this section we discuss the
steps that need to be taken by following the code of \texttt{Struct.hs} in the
\texttt{Examples} directory of the Copilot distribution, or the repository
\footnote{\url{https://github.com/Copilot-Language/Copilot/blob/master/Examples/Struct.hs}}.

Let's assume that we have defined a 2d-vector type in our C code:
\begin{lstlisting}
struct vec {
	float x;
	float y;
};
\end{lstlisting}
For us to be able to use this vector inside Copilot, we need to follow a number
of steps:
\begin{enumerate}
  \item Enable \texttt{DataKinds} compiler extension.
  \item Define a datatype to mimic the C definition.
  \item Write an instance of the \texttt{Struct} class, containing a definition
  for the struct name and function to translate the fields to a heterogeneous
    list.
  \item Write an instance of the \texttt{Typed} class.
\end{enumerate}

\subsubsection*{Enabling compiler extensions}
First and foremost, we need to enable the \texttt{DataKinds} extension to GHC,
by putting:
\begin{lstlisting}[language=Copilot]
{-# LANGUAGE DataKinds #-}
\end{lstlisting}
at the top of our specification file. This allows us to define \emph{kinds},
which are the types of types. Our datatype needs to carry the names of the
fields in C as well. Using the \texttt{DataKinds} extension we are able to
write the names of the fields as part of our types.

\subsubsection*{Defining the datatype}
A suitable representation of structs in Haskell is provided by the
\emph{record-syntax}, this allows us to use named fields as part of the
datatype. For Copilot this is not enough though: we still need to define the
names of the fields in our C code. Therefore we introduce new \texttt{Field}
datatype, which takes two arguments: the name of field, and it's type. Now we
can mimic our vector struct in Copilot as follows:
\begin{lstlisting}[language=Copilot]
data Vec = Vec
  { x :: Field "x" Float
  , y :: Field "y" Float
  }
\end{lstlisting}
Here we created two fields, $x$ and $y$, each with their corresponding C names
and types. Note that the name inside Haskell and the C names do not necessarily
need to match, nor is it always possible to have them match. For type-safety,
inside Copilot we will typically only use the Haskell level names (i.e. the
unquoted ones). The C names are only used by Copilot internally.

\subsubsection*{Instance of \texttt{Struct}}
Our next task is to inform Copilot about our new type, therefore we need to
write and instance of the \texttt{Struct}-class. This class has the purpose of
defining the datatype as a struct, it provides the code generator of Copilot the
name of struct in C, and provides a function to translate the struct to a list
of values:
\begin{lstlisting}[language=Copilot]
instance Struct Vec where
  -- typename :: Vec -> String
  typename _ = "vec"  -- Name of the type in C

  -- Function to translate Vec to list of Value's, order should match struct.
  -- tovalues :: Vec -> [Value Vec]
  toValues v = [ Value Float (x v)
               , Value Float (y v)
               ]
\end{lstlisting}
Both definitions should be pretty self-explanatory. Note however that
\texttt{Value a} is a wrapper around the \texttt{Field} datatype to hide the
actual type of \texttt{Field}. It takes the type of the field, and the field
itself as its arguments. The elements in the list should be in the same order
as the fields in the struct.

Both \texttt{typename} and \texttt{toValues} have to be defined by the user,
but neither should ever be used by the user. Both functions are only used by
the code generator of Copilot.

\subsubsection*{Instance of \texttt{Typed}}
In Copilot, streams can only of types that are instances of the \texttt{Typed}
class. To be able to create streams of vectors, \texttt{Vec} needs to be an
instance of \texttt{Typed} as well. The class only provides a \texttt{typeOf}
function, returning the type:
\begin{lstlisting}[language=Copilot]
instance Typed Vec where
  typeOf = Struct (Vec (Field 0) (Field 0))
\end{lstlisting}
For \texttt{Vec} this means we need to return something of the \texttt{Vec}
type wrapped in the \texttt{Struct} constructor. In this case it does not
matter what the values of the fields are, we just need to return something of
the correct type.

\subsubsection*{Simple operations}
Building streams of structs works like building any other stream, but we need
to wrap the values of a struct using the \texttt{Field} constructor. The reason
for this is quite straightforward: the fields of our struct are defined in
terms of \texttt{Field}:
\begin{lstlisting}[language=Copilot]
v :: Stream Vec
v = [ Vec (Field 0) (Field 1) ] ++ v
\end{lstlisting}

We can also turn a field of a struct into its own stream using the
\texttt{(\#)}-operator:
\begin{lstlisting}[language=Copilot]
vx :: Stream Float
vx = v # x
\end{lstlisting}
Note the we use the Haskell level accessor \texttt{x} to retrieve the field
from the stream of vectors.

\subsubsection*{Example code}
\begin{example}
\label{exm:struct}
Now that we defined all there is, we can make streams of structs. The following
code has been taken from the \texttt{Struct.hs} example, and shows the basic
usage of structs.

\begin{lstlisting}[language=Copilot]
{-# LANGUAGE DataKinds #-}

module Struct where

import Language.Copilot
import Copilot.Compile.C99

import Prelude hiding ((>), (<), div, (++))

data Vec = Vec
  { x :: Field "x" Float
  , y :: Field "y" Float
  }

instance Struct Vec where
  typename _ = "vec"  -- Name of the type in C

  -- Function to translate Vec to list of Value's, order should match struct.
  toValues v = [ Value Float (x v)
               , Value Float (y v)
               ]

-- We need to provide an instance to Typed with a bogus Vec
instance Typed Vec where
  typeOf = Struct (Vec (Field 0) (Field 0))

vecs :: Stream Vec
vecs = [ Vec (Field 1) (Field 2)
       , Vec (Field 12) (Field 8)
       ] ++ vecs

spec = do
  -- Trigger that always executes, splits the vec into seperate args.
  trigger "split" true [arg $ vecs # x, arg $ vecs # y]
\end{lstlisting}
\end{example}

\subsection{Functions on Streams} \label{sec:FnOnStreams}

Given that constants and operators work pointwise on streams, we can use Haskell
as a macro-language for defining functions on streams.  The idea of using
Haskell as a macro language is powerful since Haskell is a
general-purpose higher-order functional language.

\begin{example}
We define the function {\tt even}, which given a stream of
integers returns a boolean stream which is true whenever the input stream
contains an even number, as follows:
%
\begin{lstlisting}[language = Copilot, frame = single]
even :: Stream Int32 -> Stream Bool
even x = x `mod` 2 == 0
\end{lstlisting}
%
Applying {\tt even} on {\tt nats} (defined above) yields the sequence
$\{T, F, T, F, T, F, \dots\}$.
\end{example}

If a function is required to return multiple results, we simply use plain
Haskell tuples:

\begin{example}
We define complex multiplication as follows:
%
\begin{lstlisting}[language = Copilot, frame = single]
mul_comp
  :: (Stream Double, Stream Double)
  -> (Stream Double, Stream Double)
  -> (Stream Double, Stream Double)
(a, b) `mul_comp` (c, d) = (a * c - b * d, a * d + b * c)
\end{lstlisting}
%
Here {\tt a} and {\tt b} represent the real and imaginary part of the left
operand, and {\tt c} and {\tt d} represent the real and imaginary part
of the right operand.
\end{example}

\subsection{Stateful Functions} \label{sec:stateful}

In addition to pure functions, such as {\tt even} and {\tt mul\_comp},
Copilot also facilitates \emph{stateful} functions. A \emph{stateful} function
is a function which has an internal state, e.g. as a latch (as in electronic
circuits) or a low/high-pass filter (as in a DSP).

\begin{figure*}
\begin{minipage}{0.25\linewidth}
\begin{tabular}{c|c||c}
$\mathtt{x}_i$: & $\mathtt{y}_{i-1}$: & $\mathtt{y}_i$:\\
\hline
$F$ & $F$ & $F$ \\
\hline
$F$ & $T$ & $T$ \\
\hline
$T$ & $F$ & $T$ \\
\hline
$T$ & $T$ & $F$
\end{tabular}
\end{minipage}
\begin{minipage}{0.35\linewidth}
\begin{lstlisting}[frame=none]
latch :: Stream Bool -> Stream Bool
latch x = y
  where
  y = if x then not z else z
  z = [False] ++ y
\end{lstlisting}
\end{minipage}
\hspace{1cm}
\begin{minipage}{0.3\linewidth}
\begin{tabular}{c|c|c|c|c|c}
   & 0 & 1 & 2 & 3 & 4\\
\hline
x & $F$ & $T$ & $T$ & $F$ & $F$ \\
\hline
y & $F$ & $T$ & $F$ & $F$ & $F$ \\
\end{tabular}
\end{minipage}
\caption{A latch [Example 3]. The specification function is provided at the left and the
implementation in copilot is provided in the middle. The right shows an example of
the latch, where x is $\{F, T, T, F, F, \dots \}$ and the initial value of y (used with $x_0$ to find
$y_0$ since there is no $y_{-1}$) is False.}
\label{fig:jk_latch}
\end{figure*}

\begin{example}
We consider a simple latch, as described in \cite{Farhat2004}, with a single
input and a boolean state. A latch is a way of simulating memory in circuits by feeding
back output gates as inputs.  Whenever the input is true the internal state is reversed.
The operational behavior and the implementation of the latch is shown in Figure
\ref{fig:jk_latch}.\footnote
{In order
to use conditionals (i.e., if-then-else) in Copilot specifications,
as in Figures~\ref{fig:jk_latch} and~\ref{fig:counter}, the GHC
language extension {\tt RebindableSyntax} must be set on.}
\end{example}

\begin{figure*}
\begin{minipage}{0.4\linewidth}
\begin{tabular}{c|c||c}
$\mathtt{inc}_i$: & $\mathtt{reset}_i$: & $\mathtt{cnt}_i$: \\
\hline
$F$ & $F$ & $\mathtt{cnt}_{i-1}$ \\
\hline
* & $T$ & $0$ \\
\hline
$T$ & $F$ & $\mathtt{cnt}_{i-1} + 1$ \\
\hline
\end{tabular}
\end{minipage}
\hspace{1cm}
\begin{minipage}{0.6\linewidth}
\begin{lstlisting}[language = Copilot, frame = none]
counter :: Stream Bool -> Stream Bool
        -> Stream Int32
counter inc reset = cnt
  where
  cnt = if reset then 0
          else if inc then z + 1
                 else z
  z = [0] ++ cnt
\end{lstlisting}
\end{minipage}
\caption{A resettable counter. The specification is provided at the left and the
implementation is provided at the right.
}
\label{fig:counter}
\end{figure*}

\begin{example}
We consider a resettable counter with two inputs, {\tt inc} and {\tt reset}.
The input {\tt inc} increments the counter and the input {\tt reset} resets the
counter. The internal state of the counter, {\tt cnt}, represents the value of the
counter and is initially set to zero. At each cycle, $i$, the value of
$\mathtt{cnt}_i$ is determined as shown in the left table in Figure
\ref{fig:counter}.
\end{example}

%\begin{figure}
%\begin{code}
%fir2pole :: Double -> Double -> Double -> Double
%  -> Double -> Sig Double -> Sig Double
%fir2pole a1 a2 b0 b1 b2 x0 = y0
%  where
%    y0 = - (constant a1)*y1 - (constant a2)*y2
%         + (constant b0)*x0 + (constant b1)*x1 + (constant b2)*x2
%    x2 = [0, 0] ++ x0 ; x1 = drop 1 x2
%    y2 = [0, 0] ++ y0 ; y1 = drop 1 y2
%\end{code}
%\caption{A $2$-pole IIR filter.}
%\label{fig:2_pole_iir_filter}
%\end{figure}

\subsection{Types} \label{sec:types}

Copilot is a typed language, where types are enforced by the Haskell type system
to ensure generated C programs are well-typed.  Copilot is \emph{strongly typed}
(i.e., type-incorrect function application is not possible) and \emph{statically
  typed} (i.e., type-checking is done at compile-time).  The base types are
Booleans, unsigned and signed words of width 8, 16, 32, and 64, floats, and
doubles.  All elements of a stream must belong to the same base
type.  These types have instances for the class {\tt Typed a}, used to constrain
Copilot programs.

We provide a {\tt cast} operator
%
\begin{lstlisting}[language = Copilot, frame = single]
cast :: (Typed a, Typed b) => Stream a -> Stream b
\end{lstlisting}
%
that casts from one type to another.  The cast operator is only defined for
casts that do not lose information, so an unsigned word type {\tt a} can only be
cast to another unsigned  type at least as large as {\tt a} or to a signed word
type strictly larger than {\tt a}.  Signed types cannot be cast to unsigned
types but can be cast to signed types at least as large.

There also exists an {\tt unsafeCast} operator which allows casting from any
type to any other (except from floating point numbers to integer types):

\begin{lstlisting}[language = Copilot, frame = single]
unsafeCast :: (Typed a, Typed b) => Stream a -> Stream b
\end{lstlisting}

\subsection{Interacting With the Target Program}
\label{subsec:interacting}

All interaction with the outside world is done by sampling \emph{external
  symbols} and by evoking \emph{triggers}.  External symbols are symbols that
are defined outside Copilot and which reflect the visible state of the target
program that we are monitoring.  They include variables and arrays.
Analogously, triggers are functions that are defined outside Copilot and which
are evoked when Copilot needs to report that the target program has violated a
specification constraint.

\paragraph{External Variables.}

As discussed in Section~\ref{sampling}, \emph{sampling} is an approach
for monitoring the state of an executing system based on sampling
state-variables, while assuming synchrony between the monitor and the
observed software. Copilot targets hard real-time embedded C programs
so the state variables that are observed by the monitors are variables
of C programs. Copilot monitors run either in the same thread or a
separate thread as the system under observation and the only variables
that can be observed are those that are made available through shared
memory. This means local variables cannot be observed. Currently,
Copilot supports basic C datatypes, arrays and structs. Combinations of each of
those work as well: nested arrays, arrays of structs, structs containg arrays
etc. All of these variables containing actual data; pointers to data are not
supported by design.

Copilot has both an interpreter and a compiler.The compiler must be
used to monitor an executing program. The Copilot reification process
generates a C monitor from a Copilot specification. The variables that
are observed in the C code must be declared as \emph{external}
variables in the monitor. The external variables have the same name as
the variables being monitored in the C code are treated as shared
memory. The interpreter is intended for exploring ideas and algorithms
and is not intended to monitor executing  C
programs. It may seem external variables would have no meaning if the
monitor was run in the interpreter, but Copilot gives the user the
ability to specify default stream values for an external variable that
get used when the monitor interpreted.

 A Copilot specification is \emph{open} if defined with external symbols in the
sense that values must be provided externally at runtime.  To simplify writing
Copilot specifications that can be interpreted and tested, constructs for
external symbols take an optional environment for interpretation.

External variables are similar to global variables in other languages. They
are defined by using the {\tt extern} construct:
%
\begin{lstlisting}[language = Copilot, frame = single]
extern :: Typed a => String -> Maybe [a] -> Stream a
\end{lstlisting}
%
\noindent
It takes the name of an external variable, a possible Haskell list to serve as
the environment for the interpreter, and generates a stream by sampling the
variable at each clock cycle.  For example,
%
\begin{lstlisting}[language = Copilot, frame = single]
sumExterns :: Stream Word64
sumExterns = let ex1 = extern "e1" (Just [0..])
                 ex2 = extern "e2" Nothing
             in  ex1 + ex2
\end{lstlisting}
%
is a stream that takes two external variables {\tt e1} and {\tt e2} and adds
them.  The first external variable contains the infinite list {\tt [0,1,2,...]}
of values for use when interpreting a Copilot specification containing the
stream.  The other variable contains no environment ({\tt sumExterns} must have
an environment for both of its variables to be interpreted).

Sometimes, type inference cannot infer the type of an external variable.  For
example, in the stream definition
%
\begin{lstlisting}[language = Copilot, frame = single]
extEven :: Stream Bool
extEven = e0 `mod` 2 == 0
  where e0 = externW8 "x" Nothing
\end{lstlisting}
%
\noindent
the type of {\tt extern "x"} is ambiguous, since it cannot be inferred from a
Boolean stream and we have not given an explicit type signature.  For
convenience, typed {\tt extern} functions are provided, e.g., {\tt externW8} or
{\tt externI64} denoting an external unsigned 8-bit word or signed 64-bit word,
respectively.
% Please see the grammar in Appendix~\ref{sec:BNF} for the list of
% all sampling functions.

In general it is best practice to define external symbols with
top-level definitions, e.g.,
%
\begin{lstlisting}[language = Copilot, frame = single]
e0 :: Stream Word8
e0 = extern  "e0" (Just [2,4..])
\end{lstlisting}

\noindent
so that the symbol name and its environment can be shared between streams.

Just like regular variables, arrays can be sampled as well. Copilot threats
arrays in the same way as it does for scalars.
\begin{example}
\label{exmp:pitot}
Lets take the example where we
have the readouts of four pitot tubes, giving us the measured airspeed:
\begin{code}[frame=single]
/* Array containing readouts of 4 pitot tubes. */
double airspeeds[4] = ... ;
\end{code}
In our Copilot specification, we need to provide the type of our array, because
Copilot need to know the length of the array we refer to. Apart from that,
referring to an external array is like referring to any other variable:
\begin{lstlisting}[language=Copilot, frame=single]
airspeeds :: Stream (Array 4 Double)
airspeeds = extern "airspeeds" Nothing
\end{lstlisting}
\end{example}

\paragraph{Triggers.}
Triggers, the only mechanism for Copilot streams to effect the outside world,
are defined by using the {\tt trigger construct}:
%
\begin{lstlisting}[language = Copilot, frame = single]
trigger :: String -> Stream Bool -> [TriggerArg] -> Spec
\end{lstlisting}
%
The first parameter is the name of the external function, the second parameter is the
guard which determines when the trigger should be evoked, and the third parameter
is a list of arguments which is passed to the trigger when evoked.
Triggers can be combined into a specification by using the \emph{do}-notation:
%
\begin{lstlisting}[language = Copilot, frame = single]
spec :: Spec
spec = do
  trigger "f" (even nats) [arg fib, arg (nats * nats)]
  trigger "g" (fib > 10) []
  let x = externW64 "x" (Just [1..])
  trigger "h" (x < 10) [arg x]
\end{lstlisting}
%
The order in which the triggers are defined is irrelevant. To interpret this spec we run:
%
\begin{lstlisting}[language = Copilot, frame = single]
interpret 10 spec
\end{lstlisting}
%
which will yield the following output:
%
\begin{code}
f:        g:	 h:
(1,0)     ()        (1)
--        ()        (2)
(2,4)     ()        (3)
--        ()        (4)
(5,16)    ()        (5)
--        ()        (6)
(13,36)   --	(7)
--        --        (8)
(34,64)   --	(9)
--        --         --
\end{code}
%

\begin{example}
\label{exm:engine}
We consider an engine controller with the following property: If the temperature
rises more than 2.3 degrees within 0.2 seconds, then the fuel injector should
not be running.  Assuming that the global sample rate is 0.1 seconds, we can
define a monitor that surveys the above property:
%
\begin{lstlisting}[language = Copilot, frame = single]
propTempRiseShutOff :: Spec
propTempRiseShutOff =
  trigger "over_temp_rise"
    (overTempRise && running) []

  where
  max = 500 -- maximum engine temperature

  temps :: Stream Float
  temps = [max, max, max] ++ temp

  temp = extern "temp" Nothing

  overTempRise :: Stream Bool
  overTempRise = drop 2 temps > (2.3 + temps)

  running :: Stream Bool
  running = extern "running" Nothing
\end{lstlisting}
%

Here, we assume that the external variable {\tt temp} denotes the temperature of
the engine and the external variable {\tt running} indicates whether the fuel
injector is running.  The external function {\tt over\_temp\_rise} is called
without any arguments if the temperature rises more than 2.3 degrees within 0.2
seconds and the engine is not shut off.  Notice there is a latency of one tick between when the property is violated and when the guard becomes true.
\end{example}


\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{lmodern,textcomp}
\usepackage[frenchb]{babel}
\usepackage{amsmath,amsfonts}
\usepackage{graphicx}
\title{Machine Learning - Lesson nÂ°11}
\author{ChloÃ©-Agathe Azencott}
\date{December 2016}
\DeclareMathOperator*{\argmax}{arg\,max}
\begin{document}

\maketitle

Scribes : RÃ©mi Lalanne, Adam Hotait and Devang Thakkar

\section{Introduction}
In Machine Learning, it appears necessary to reduce the dimensionality of data set. There are various reasons to do so :

\begin{itemize}
    \item Computational complexity : the goal is to reduce the computational cost in time and space and therefore to avoid data overfitting.

    \item Interpretability, so that models are easier to interpret by human users.

    \item To simplify the models and make them more robust since there is less variance.

    \item Data visualization : the goal is to make this visualization easier for a human, for instance doctors who want to visualize plenty of data of their patients.

    \item To curb the cost of data acquisition, that can be very high in some cases.

    \item To keep only relevant and non-redundant attributes, since irrelevant and redundant attributes can prevent the algorithm from being efficient.

\end{itemize}

\bigskip

\textbf{Feature selection and feature extraction} are two ways of accomplishing dimensionality reduction.

On the one hand, the idea of feature selection is to select $m<p$ features among the $p$ existing features, and to ignore the remaining $(p-m)$ features. There are three ways to proceed :
\begin{enumerate}
    \item \textbf{Filtering approaches} that calculate a feature relevance score thanks to a statistical measure. Low-scoring features are then removed. These methods have a low computational cost and are independent of the classification algorithm but each feature is considered separately, so they ignore features dependencies.

    \item \textbf{Wrapper approaches} that aim at finding the best set of features for a given predictive model but that can be computationally very expensive.

    \item \textbf{Embedded approaches} that simultaneously fit a model and learn which features should be included. They are specific to a model.
\end{enumerate}

All these approaches are supervised.

\bigskip
On the other hand, the idea of feature extraction is to project the $p$ features on $m<p$ new dimensions. There are several approaches, such as linear approaches (Principal Components Analysis, Factor Analysis, MultiDimensional Scaling), supervised approaches (Linear Discriminant Analysis), non linear approaches (Isometric feature mapping, Locally Linear Embedding, Autoencoders).

\section{Feature selection : subset selection}
In a feature subset selection problem, the issue is to select a subset of features, so that all the attention concerns this subset and that the rest can be ignored.

\subsection{Wrappers approaches}

The goal is to find the subset of features that leads to the best-performing algorithm, knowing that there are $2^p$ subsets of p features. Indeed, if we consider p features, each feature can be present or  absent in the remaining features, so there are two choices for each future, hence $2^p$ such sets at the end.
Therefore, it is almost impossible to search the whole space exhaustively, except in the cases where $n$ is very small, since complexity is $O(2^p)$.
\bigskip

To solve this problem, we can use a greedy approach ("algorithme glouton" in French) : the forward search.
We proceed  by adding the "best" feature at each step. Let $E(F)$ be the error on held-out validation set of a predictor trained only using the features in $F$.
\begin{itemize}

    \item Initially, $F = \emptyset $

    \item Then, we find a new best feature : $j*= arg \ min_{j \in \{1,...,p\}} E(F\cup \{j\})$

    \item If $E(F)<E(F \cup \{j\})$ : the algorithm stops.

    \item Else : $F \leftarrow F \cup \{j\}$.

\end{itemize}

The error is therefore minimal and the complexity is $O(p^2)$, which is way better than $O(2^p)$.

\subsection{Embedded approaches}
We have seen algorithms which simultaneously optimize a cost/loss function and the features that should be uses.
Among them, the $L1$ regularization, with an approach called the Lasso. For a parameter $\lambda \geq 0 $, this approach finds $\widehat{\beta}_{lasso} = arg \ min_{\beta} \| y-X\beta \|_{2}^{2} + \lambda \| \beta \|_2 $.

\section{Feature extraction : Principal Components Analysis}

Another way of reducing the dimensionality of the data is use to Principal Component Analysis. The primary objective that we need to achieve is the minimization of information loss after the data has been projected onto a lower dimensional space using a linear mapping. In other words, we need to find a lower dimensional space, where the variance of the projection is maximised.

\bigskip

A few things to be noted here are:
\begin{itemize}
    \item PCA is an unsupervised method, in the sense that when project our values, we only consider the data points without paying any heed to the labels that pertain to those points.
    \item In PCA, one of our early assumptions is that the data that we have is centred; that is to say, the mean of our data is 0.
    \item PCA is a variance maximising exercise, hence it requires the data to be normalized before we can apply it correctly.
\end{itemize}

\bigskip

\subsection{Finding the Principal Components}
The goal is to find a space which maximizes the variance of the data that is projected on it. Before we begin, we define a certain terms that would enable us to understand better the derivation process. Let $w$ be a unit vector on which we wish to project our matrix of data points $X$.
This would imply that the projection of $X$ in the direction $w$ is given by $z = w^T X$. The variance of $z$, as calculated in the slides, comes out to be $w^T(\Sigma)w$ where $\Sigma$ is the covariance of X under the assumptions of a centred dataset.

\subsubsection{Finding the first component}
We need to begin by finding a vector that maximizes the variance of the projection $z$ and has unit magnitude. A problem of this type takes the form of a Lagrangian optimisation that can be solved easily by introducing a Lagrangian multiplier. Putting it mathematically, the problem is transformed from $(1)$ to $(2)$:

\begin{gather}
    w_1 = \argmax_ { w \in R_p} Var(w^T x) \\
    w_1 = \argmax_ { w \in R_p} (w^T \Sigma w - \alpha (w^Tw \ - \ 1))
\end{gather}

As with any ordinary Lagrangian problem, we derive the resulting equation and set it to 0. Doing this leads us to a couple of astonishing results. We find out that:

\begin{itemize}
    \item The system has been reduced to an eigen value problem
    \item The multiplier $\alpha$ is an eigen value of the matrix $\Sigma$
    \item The direction vector $w_1$ is an eigen vector of the matrix $\Sigma$
\end{itemize}

Using this results, we find out that the desired direction vector is the eigen vector with the largest eigen value.

\subsubsection{Finding the remaining components}
Once we have the first principal component, we proceed to find the remaining components. The process is really similar to the previous case, except for the fact that we have one more condition on our vector $w_i$, that is, the new vector $w_i$ must be orthogonal to all the previously found components. This algorithm leads to the discovery that the $i^{th}$ component is the eigen vector with the $i^{th}$ largest eigen value.

\bigskip

Once we have all the principal components of the data, we can choose to keep the top $m$ components and discard the rest. An important variable to decide here is $m$, i.e., how many principal components do we retain. One way to decide is to plot a scree graph of the variance explained by the components and select as many variables as required as long as the addition of one more components seems useful to the total variance explained.

\section{Feature extraction : Autoencoders}

A third way to do dimensionality reduction is to use neural networks, with the use of Autoencoders. Autoencoders try to reconstruct its input. However, and that is where it uses neural networks, the interest of autoencoders is the hidden layer(s) it constructs. Autoencoders are a non linear, unsupervised approach to dimensionality reduction.

\subsection{General presentation}

The goal is to select fewer features than there are in the train set to then reconstruct the train set. This is done on several points of data to find the weights that minimize the reconstruction error.

\begin{figure}[!h]
    \center
    \includegraphics[scale=0.5]{./figures/autoencoder_general.png}
    \caption{Diagram of a generic autoencoder}
\end{figure}

\subsection{Restricted Boltzmann Machines}

RBM are stochastic neural networks, where the activation of a unit is probabilistic, with : \[P(o_i = 1) = \frac{1}{1+e^{-a_i+\sum_j o_j w_{ij}}}\]

\begin{figure}[!h]
    \center
    \includegraphics[scale=0.5]{./figures/autoencoder_stochastic.png}
    \caption{Diagram of a stochastic neural network}
\end{figure}

A RBM has two layers, with bidirectional connections. The term "restricted" comes from the fact that there are no connection between the hidden units.

The main property of a RBM is the energy of the RBM, defined by : \[E(\textbf{x},\textbf{z}) = - \sum\limits_{j=1}^p a_jx_j - \sum\limits_{h=1}^H b_hz_h - \sum\limits_{j=1}^p\sum\limits_{h=1}^H x_jw_{jh}z_h\]

where $a_j$ is the offset for the visible unit j and $b_h$ is the offset for the hidden unit h.

\begin{figure}[!h]
    \center
    \includegraphics[scale=0.5]{./figures/autoencoder_rbm.png}
    \caption{Diagram of a RBM}
\end{figure}

The goal is to model the probability distribution $P(\textbf{x})$, with : \[P(\textbf{x}) = \frac{\exp(-\mathcal{F}(\textbf{x}))}{Z}\]

where $\mathcal{F}$ and $Z$ are respectively the free energy and the partition function (which is a normalizing factor), with :
\[
\left\{
  \begin{array}{rcc}
    \mathcal{F} & = & - \log\sum\limits_{\textbf{z}}\exp(-E(\textbf{x},\textbf{z})) = - \sum\limits_{j=1}^p a_jx_j - \sum\limits_{h=1}^H\log\sum\limits_{z_h}e^{z_h(b_h+\sum_{j=1}^pw_{jh}x_j)}\\
    Z & = & \sum\limits_{\textbf{x}\in\omega}\exp(\mathcal{F}(\textbf{x}))\\
  \end{array}
\right.
\]

\subsection{Deep architectures}
It should be noted that by stacking RBM (outputs of RBM become inputs for other subsequent RBM), we get Deep belief networks.

\begin{figure}[!h]
    \center
    \includegraphics[scale=0.5]{./figures/autoencoder_deepbelief.png}
    \caption{Diagram of a deep belief network}
\end{figure}

\end{document}


\par
\section{Prototypes and descriptions of {\tt SymbFac} methods}
\label{subsection:SymbFac:proto}
\par
This section contains brief descriptions including prototypes
of all methods that belong to the {\tt SymbFac} object.
\par
\subsection{Symbolic factorization methods}
\label{subsection:SymbFac:proto:symbfac}
\par
\begin{enumerate}
%-----------------------------------------------------------------------
\item
\begin{verbatim}
IVL * SymbFac_initFromGraph ( ETree *etree, Graph *graph ) ;
\end{verbatim}
\index{SymbFac_initFromGraph@{\tt SymbFac\_initFromGraph()}}
This symbolic factorization method takes a {\tt Graph} object
as input.
This method constructs an {\tt IVL} object that contains one list
per front.
List {\tt ilist} contains the internal and external vertices
for front {\tt ilist}.
If the input {\tt graph} is a compressed graph, then the lists of
compressed vertices make little sense; they must be converted to
original vertices.
To do this, see the {\tt IVL\_expand()} method.
The {\tt nodwghtsIV} and {\tt bndwghtsIV} objects for the {\tt
ETree} object are updated using information from the symbolic
factorization.
\par \noindent {\it Error checking:}
If {\tt etree} or {\tt graph} is {\tt NULL},
or if ${\tt nfront} < 1$,
or if ${\tt nvtx} < 1$,
or if $\mbox{\tt graph->nvtx} \ne {\tt nvtx}$,
an error message is printed and the program exits.
%-----------------------------------------------------------------------
\item
\begin{verbatim}
IVL * SymbFac_initFromInpMtx ( ETree *etree, InpMtx *inpmtx ) ;
\end{verbatim}
\index{SymbFac_initFromInpMtx@{\tt SymbFac\_initFromInpMtx()}}
This symbolic factorization method takes a {\tt InpMtx} object
as input.
This method constructs an {\tt IVL} object that contains one list
per front.
List {\tt ilist} contains the internal and external vertices
for front {\tt ilist}.
We assume that both the {\tt ETree} and {\tt InpMtx} objects have
had been permuted into their final ordering.
The {\tt nodwghtsIV} and {\tt bndwghtsIV} objects for the {\tt
ETree} object are updated using information from the symbolic
factorization.
\par \noindent {\it Error checking:}
If {\tt etree} or {\tt inpmtx} is {\tt NULL},
or if the coordinate type of {\tt inpmtx} is not {\tt
INPMTX\_BY\_CHEVRONS},
or if the storage mode of {\tt inpmtx} is not {\tt
INPMTX\_BY\_VECTORS},
or if ${\tt nfront} < 1$,
or if ${\tt nvtx} < 1$,
an error message is printed and the program exits.
%-----------------------------------------------------------------------
\item
\begin{verbatim}
IVL * SymbFac_initFromPencil ( ETree *etree, Pencil *pencil ) ;
\end{verbatim}
\index{Symbfac_initFromPencil@{\tt Symbfac\_initFromPencil()}}
This first symbolic factorization method takes a {\tt Pencil} object
as input and is used to compute the symbolic factorization for
a matrix pencil $A - \sigma B$.
This method constructs an {\tt IVL} object that contains one list
per front.
List {\tt ilist} contains the internal and external vertices
for front {\tt ilist}.
We assume that both the {\tt ETree} and {\tt InpMtx} objects have
had been permuted into their final ordering.
The {\tt nodwghtsIV} and {\tt bndwghtsIV} objects for the
{\tt ETree} object are updated using information from the symbolic
factorization.
\par \noindent {\it Error checking:}
If {\tt etree} or {\tt inpmtxA} is {\tt NULL},
or if the coordinate type of either internal {\tt InpMtx} objects
is not {\tt INPMTX\_BY\_CHEVRONS},
or if the storage mode of either internal {\tt InpMtx} objects
is not {\tt INPMTX\_BY\_VECTORS},
or if ${\tt nfront} < 1$,
or if ${\tt nvtx} < 1$,
an error message is printed and the program exits.
%-----------------------------------------------------------------------
\end{enumerate}


\subsection{Identification of Informative Variants for the Chip Array}

For identification of informative variants on the chip array, we will utilise a hybrid algorithm with cycles of LD based pairwise tagging, and imputation, as has been previously described.\cite{Hoffmann2011422} Only populations with at least 50 samples will be included in the chip design process, as pairwise LD evaluation would be difficult in smaller samples. Because different sample sizes affects LD calculations,\cite{Jorde2000}\cite{Peer2006} we randomly downsample populations to a maximum size of 100 samples. Here, the term ‘population’ should be considered distinct from an ethno-linguistic group/project, and constitutes a group of individuals/samples that appear genetically homogeneous, without any significant substructure or clustering. In order to account for different sample sizes and LD differentiation among populations, we will carry out multi-population pairwise tagging, as described below. We seek only to tag common SNPs (MAF\textgreater5\%) for generation of this array.

We have developed a multi-population tagging algorithm based on the algorithm TAGster for WGS data.\cite{Xu2007} The methods we used for tagging were identical to those used by TAGster; however, by using seeking and indexing approaches we were able to optimise the computational efficiency of the algorithm by an order of magnitude (unpublished data, Carstensen et al.). We briefly outline the tagging algorithm as follows (Figure 2):

\begin{enumerate}
\item Calculate LD (\textit{r}\textsuperscript{2}) between each SNP and all other SNPs in the flanking 250 KB region for each population separately. MAF thresholds are imposed at this stage, and only pairs of SNPs where both exceed the MAF threshold are included.
\item For each SNP not already in the tagging set, a count of SNPs in the target set that are in LD exceeding a given threshold \textit{r}\textsuperscript{2} with it is generated across the genome and summed across all populations.
\item The most informative SNP (the SNP with most target SNPs in LD with it summed across population) is chosen as the tagging SNP and added to the set of tagging SNPs. If two SNPs have the same ranking, then a SNP is chosen by one or all of the following parameters in order of preference: 1) presence on existing SNP arrays (count), 2) presence in 1000G and/or dbSNP (binary), 3) location within a gene region (binary), 4) binned genotyping score provided by the vendor, 5) rate of heterozygosity across all populations (continuous).
%We do not take the vicinity to existing tag SNPs into account, despite  SNPs in close proximity being able to interfere with each other when assayed.\cite{21535878} We expect the algorithm to avoid this problem, because SNPs in proximity of each other are also likely to be in LD with each other.
\item This tagging SNP and SNPs in LD with it are now removed from the set of target SNPs. This process is carried out separately for each population, so that a separate set of target SNPs is maintained for each population set. However, SNPs in LD with the tagging SNP can still be picked up as tagging SNPs themselves if they independently tag the maximum no. of SNPs in any iteration.
Steps 2-3 are repeated until either a specified number of SNPs or all target SNPs (chosen as SNPs above a specific MAF threshold per-population) are tagged across all population sets, or until a specific number of SNPs is reached, as specified.
\end{enumerate}

Although this method works well across populations, it only carries out pairwise single-marker tagging. Haplotype based, or multi-marker tagging would potentially be more efficient, and select fewer tagging sites. In order to incorporate haplotype based tagging into our model, we use a hybrid method, with cycles of tagging and imputation, as has been described before.\cite{Hoffmann2011422}

\begin{figure}[!htbp]
\centering
\includegraphics[width=0.8\textwidth]{tagSNPselection}
\caption{Hybrid tagging and imputation algorithm for chip design.}
\end{figure}

We implement this method by selecting a maximum number of pre-defined tagging SNPs in the first cycle. With these tagging SNPs we simulate a chip for each population, and imputation is carried out using a reference panel, to identify additional sites in each population that are tagged at an $r^{2}$ threshold above 0.80 by the tagging sites. These sites are removed from the target set for each population, and do not contribute to the next cycle, thereby making the process more efficient. To maximise imputation accuracy we use all samples in table \ref{tab:samples} for the reference panel and merge this reference panel with haplotypes from all of the 1000G samples from Europe, Asia and the Americas not already present in the reference panel. However, for imputation into each population, all samples from the given population are removed from the reference panel. This ‘leave one population out’ approach would produce relatively conservative results for tagging, with more variants being tagged than if a subsample of the population was included in the reference panel. This is a more realistic scenario, as it is not necessary that any given population genotyped on the chip in future would be represented in the reference panel.

Additionally, pre-selected known biologically relevant variants, valuable to the studies planned for consortia can be included on the array, to replace certain tag SNPs. We have previously shown that a 1M tagging variants chosen using the described algorithm can produce \textgreater80\% coverage across diverse populations in Africa. Based on this, we plan to carry out approximately 10 cycles to capture 1.2M tagging variants, in order to prioritise variants to include in the design of a 1M chip array. Following this, we will further validate our tagging algorithm among populations with smaller sample sizes that were not included in the development in the chip array, by selecting tagging variants among these and imputing with the reference panel, excluding these populations. We estimate coverage of each population by such a chip array using imputation. Coverage is defined as the proportion of common variation captured at a correlation greater than 0.80 across the genome in a given population with the combined reference panel (excluding the population being evaluated). $r^{2}$, here, is calculated as the correlation between the sequence data and imputed data on a hypothetical 1M chip array for common variation.

%Instead of random choice do 1) chip overlap, 2) quality score (VQSLOD and MVNcall posterior), 3) white/black list


%!TEX root = ../main.tex
%TODO: Redo the flowchart with updated and more specific steps

The input to our problem is a fiducial marker $F$ that provides the object position in the real world, and a 3D mesh $M$ that will be rendered in Augmented Reality. The method will calculate the properties of a set of light sources $L_i$, specifically position, rotation, intensity and color. In order to analyze the luminance ($L()$), a $360^{\circ}$ panoramic image is required, generated as a pre-processing step as explained in chapter \ref{theory}. The complete process is depicted in the flowchart in Figure \ref{flowch}, and each step is consequently described in more detail according to the mentioned sections.
\begin{figure}[H]
  \centering
  \setlength{\unitlength}{\textwidth}
    \begin{picture}(1,0.5)
       \put(-0.1,0){\includegraphics[width=1.3\unitlength]{Figures/Flowchart.png}}

    \end{picture}
    \caption{Our method in a nutshell.}
    \label{flowch}
\end{figure}

\section{Capture $360^{\circ}$ panoramic image}
We use panoramic images as a pre-process. As such it's not within the scope of the method to define a new way of capturing $360^{\circ}$ images. The application we used to procure a spherical panoramic image within the device itself is Google Street View. This application guides the user through the process of generating the $360^{\circ}$ panorama. In total 44 photos are necessary and the application shows an orange dot on the screen on the point where the user has to point the camera next. This functionality was originally conceived to capture outdoors scenes, but if the user stands roughly in the middle of a room it works to capture indoors scenes as well.\newline
We ask the user to provide the origin of the virtual world by rotating the virtual reflective sphere so that the view of the room aligns with that of the section of the real room that the camera is facing. This also simplifies calculations of light orientations later on.

\section{Light source filtering}\label{lsf}
We factor out the luminance from the RGB representation of the panorama. This is achieved by the following equation:
\begin{equation}
  \forall \  P_{ij}; L(P_{ij}) = 0,2126 \cdot R_{ij} + 0,7152 \cdot G_{ij} + 0,0722 \cdot B_{ij} ,
\end{equation}
where $L$ is the luminance obtained at D65 white point and $P$ is the pixel in the $i,j$ position of the image and $R,G,B$ are the red, green and blue components of the pixel, respectively. \newline
The contrast ratio has to be adjusted, so that the regions with high luminance are more clearly separated.

\begin{equation}
     g(i,j) = \alpha \cdot L(P_{ij}) + \beta
\end{equation}

Where $g(i,j)$ is the adjusted image, $L(i,j)$ is the original grayscale image and $\alpha$ and $\beta$ are the brightness and contrast constants respectively, determined by parameter tuning. We carried out the parameter tuning in a trial-and-error basis, by using initial extreme values and run the program, and varying the values in order to achieve the best result. The values that worked in the implementation were $\alpha = 220$ and $\beta = 255$.
In order to prevent outlier pixels and noise from causing false positives, we normalize $g(i,j)$ as follows:
\begin{equation}
    N(g_{ij}) = \frac{ 2 \cdot g_{ij} }{min(L) + max(L)},
\end{equation}
Where $min(L)$ and $max(L)$ are the overall minimum and maximum luminance values in the image.
\newline
The result of these steps is a black and white image with the rough shape of the light source. We call these shapes \emph{regions of high luminance}. If there are no regions of high luminance in the image at all it means that no relevant light sources were found. A region of high luminance in the image is formally defined as follows:
\begin{equation}
    R(H) = \{p_{00}, p_{01}, ... , p_{mn}\},
\end{equation}
 where $p_{ij}$ is the pixel in the i,j position of the image, so that
\[
    L(p_{ij}) \leq 0.9 \cdot max(L(p_{ij}))
\]
The region must also be connected side-by-side, so the pixels must be adjacent.\newline
Regions of high luminance are for the most part characterized by much noise and artifacts. These are caused by clear objects, reflections of light sources on polished surfaces, and even light sources that are far away, but don't contribute an important amount of light to the area of interest. Therefore, it's necessary to also add further filtering to the pipeline. \newline
The amount of light that a lighting source contributes to a given scene is directly proportional to the emission area of that source. When analyzing a photograph this area translates to the pixel size of the light source in the image. So we consider this to be a good measure for filtering. Figuring what constitutes an acceptable region size to determine if we have to filter a the light source is a challenging problem for which we couldn't find an existing solution. The approach we took is to define a percentage of the width and height of the overall image as a threshold in search for the best solution. The size filter is then:
\begin{equation}
    width(R(H)) \cdot height(R(H)) \geq k \cdot W \cdot H
\end{equation}
Where $k$ is the threshold, in the implementation the value that yielded the best results was $k = 0.004$; $W$ and $H$ are the total image width and height.\newline
Each identified region of high luminance that passes all the filters is a light source used at runtime. We capped the maximum amount of light to 8 in practice. We decided to use a maximum of 8 for a few reasons. With more than 8 light sources it becomes challenging to keep the scene from being too lit, even normalizing the intensities. Since we're calculating shadows for each light source, we found that doing it for more than 8 light sources made this process a bottleneck that caused the whole application performance to drop. \newline

\section{Calculate light properties}
We need to calculate position, orientation, intensity, and color for each light, remembering that we have the original full color image available.  \newline
\begin{enumerate}
\item  \textbf{Orientation}: This process is carried out with an array $P_i$ of points containing the pixel coordinates $(x,y)$ of the regions of high luminance; the normalized luminance analysis image $N(g_{ij})$ mapped on a sphere $S$ and a camera $C$ facing the sphere from four different points of view (in order to cover a full revolution). The orientation of the pth light source $O(L_p)$ is calculated as follows:
\begin{algorithm}[H]
\caption{Light source orientation calculation}\label{alg:orientAl}
\begin{algorithmic}[1]
\For{\texttt{i $\in[1,4]$}}
    \For{\texttt{each pixel in camera view}}
        \State \texttt{Cast ray to $S$}
        \If {Color at hit point $H$ is white AND $H=P_p$}
            \State \texttt{Calculate $O(L_p)$:}
            \begin{equation}
            O(L_p) = -2 \cdot (N_h \cdot C_r) N_h + C_r,
            \end{equation}
            \NoNumber{ $N_h$: normal of $S$ at $H$.}
            \NoNumber{$C_r$: camera ray direction.}

            \State \texttt{Normalize $O(L_p)$:}
            \begin{equation}
            O(L_p)_N = (\frac{O(L_P)_x}{|O(L_P)|}, \frac{O(L_P)_y}{|O(L_P)|}, \frac{O(L_P)_z}{|O(L_P)|})
            \end{equation}
        \EndIf
    \EndFor
    \State \texttt{Obtain the next camera view by rotating $C$ $90^{\circ}$ clockwise around the $y$ axis of $S$}
\EndFor
\end{algorithmic}
\end{algorithm}
This process is depicted in Figure \ref{camMov} for further clarification. The figure shows the vectors $N_h$ and $C_r$, the $C$ orbiting $S$ and the four distinct points of view with which $C$ reconstructs the entire $360^{\circ}$ environment.
\begin{figure}[H]
  \centering
  \setlength{\unitlength}{\textwidth}
    \begin{picture}(0.75,0.5)
       \put(-0.1,0){\includegraphics[width=1.0\unitlength]{Figures/camMov.png}}

    \end{picture}
    \caption{Illustration of the computation of the light orientations based on the virtual reflective sphere.}
    \label{camMov}
\end{figure}
\item \textbf{Position}: With the orientation calculated in the previous step we know the angles of the light source with respect to the marker $F$. What we don't know is how far away along that vector the light actually is. In order to approximate the distance from a camera to an object in a photograph we can use triangle similarity, the device's known camera parameters and a known object size. The ratio of the size of the object on the camera sensor and the size of the object in real life is the same as the ratio between the focal length of the lens and distance to the object.
We use the average of a light source's height to approximate the desired distance:
\begin{equation}
   D = \frac{f \cdot h(O_r) \cdot h(L)}{h(O_p) \cdot h(s)},
\end{equation}
where $f$ is the camera aperture size, $h(O_r)$ and $h(O_p)$ are the real object height in millimeters (the value we used is 200 mm) and the image object height in pixels, respectively; $h(L)$ is the height of the full image and $h(s)$ is the camera sensor height.

\item \textbf{Color}: Storing both versions of the panorama, one in full color and another one after processing, allows us to have both the color and the luminance information. Once a light source is detected, the equivalent area in the color image is averaged to determine the color of the light source. We obtain the linear average of each individual color channel and use the combined results.
\item \textbf{Intensity}: There are two factors that influence the intensity of a light as perceived by a camera, the light size and the color temperature. The light's color temperature in Kelvin is calculated using the approximation proposed by \citep{mccamy1992}, as follows:
\begin{equation}
    T(C_p) = -949.86315 + 6253.80338 ^ {\frac{-n}{0.92159} } + 28.70599 ^{\frac{-n}{0.20039} } + 0.00004 ^ {\frac{-n}{0.07125} }
\end{equation}
\begin{equation}
n = {\frac{0.23881\cdot R + 0.25449\cdot G - 0.58291\cdot B}{0.11109\cdot R - 0.85406\cdot G + 0.52289\cdot B} }
\end{equation}

Where $R, G, B$ are the red, green and blue components of the light color.\newline
The other significant factor to determine the light intensity is the size. In our method the size is given by the integral of the region of high luminance with respect to the full image.\newline
The light intensity is finally expressed by:
\begin{equation}
I(L_p) = T(C_p) \cdot \int_{R(L_p)} N(g_{ij}) \,d\mu
\end{equation}
Where $N(g_{ij})$ is the output image of the luminance analysis and $R(L_p)$ is the $p^{th}$ region of high luminance. $I(L_p)$ is the scalar value that denotes the intensity of the light source at runtime.\newline

\end{enumerate}

\section{Calculate ambient light}
Since a panoramic image of the environment is already available, we can use it to implement environment mapping. However, asking the user to capture the environment more than once in order to carry out the Tone Mapping would have a bad impact on user friendliness. It is also highly unlikely that the produced image would have the exact same framing every time. Alternatively, we produce the different exposure values for the Tone Mapping by altering the brightness and contrast values of the base image using equation 4.2 once again. Afterwards, we produce the HDR image using the \citet{Debevec} weighting algorithm.\newline

\section{Real-time Phase}
We use the original spherical panoramic image to create a cubemap of the real environment for ambient lighting, to calculate the ambient contribution of the diffuse shaders and to use as reflections for the specular shaders.
\begin{enumerate}

\item \textbf{Cubemap:} We take the polar coordinates of a unit sphere $(1,\theta,\phi)$. The image coordinates are divided into four regions by latitude $-\pi/4 < \theta < \pi/4 , \pi/4 < \theta < 3\pi/4, 3\pi/4 < \theta < 5\pi/4, 5\pi/4 < \theta < 7\pi/4$. These represent either one of the four faces of the cube, top or bottom. The projected coordinates are given by:
\begin{equation}
P_c = (1, tan(\phi), \frac{cot(\theta)}{cos(\phi)}),
\end{equation}
 The process is further explained in Figure \ref{cubeMap}.
 \begin{figure}
  \centering
  \setlength{\unitlength}{\textwidth}
    \begin{picture}(0.75,0.5)
       \put(-0.1,0){\includegraphics[width=1.0\unitlength]{Figures/cubemapping.png}}

    \end{picture}
    \caption{The cubemap creation process.}
    \label{cubeMap}
\end{figure}

 The projected points for each face of the cube are composed into an image and each image stitched together to create a cross cube map.

 \item \textbf{Ambient contribution:} The environment lighting contribution is done with a shader. The ambient contribution is reduced to a single value in the range of $0$ and $1$ and applied to the diffuse color component. The result is a dimmer color when the ambient light is low.
 The ambient contribution value $A_c$ for each region of high luminance $R(L(P_{ij}))$ in the luminance analisys image $N(g_{ij})$ is given by:
 \begin{equation}
 \forall R(L(P_{ij}));A_c = \frac {\sum_{i=1,j=i} R(L(P_{ij}))}{width(R(L(P_{ij}))) \cdot height(R(L(P_{ij})))}
 \end{equation}

 \item \textbf{Reflections:} The cubemap from step 1 is also used to for reflections. A vector is cast from every vertex of the object along its normal and intersected with the cubemap generated from the panoramic image. The texture color is mixed with the diffuse color according to the specularity defined for the material to simulate reflection, this information is calculated in advance and used at runtime.

 \item \textbf{Shadows:} During early experiments it became clear that one of the bigger differences between real and virtual object were a product of the shadows as well as the light. A problem when it comes to casting shadows for virtual objects in AR is the fact that there has to be an object underneath $M$ to cast the shadow on. But this object has to be as unobtrusive as possible. We worked around this issue by using a transparent material on a plane that receives shadows. $M$ is projected on the plane from each light source and rendered flat in black color.

\end{enumerate}


\section{Introduction}
\label{sec:Introduction}

Industry equipment reliability (ER) and asset management (AM) programs are essential elements that
help ensure the safe and economical operation of nuclear power plants (NPPs).
The effectiveness of
these programs is addressed in several industry-developed and regulatory programs.
However, these programs have proven labor-intensive and expensive.
There is an opportunity to significantly
enhance the collection, analysis, and use of this information in order to provide more cost-effective plant
operation.
LOGOS provides computational capabilities to optimize plant resources such as
maintenance optimization (ER application) and optimal component replacement schedule (AM application)
by using state-of-the-art discrete optimization methods.

LOGOS is a software package and RAVEN~\cite{RAVEN,RAVENtheoryMan} plugin that
contains a set of discrete optimization models designed to solve capital budgeting optimization
problems by integrating economic and reliability data into the analysis framework.
More specifically, given system, structure and component
(SSC) health (e.g., failure rate or probability), O\&M costs, replacement costs, and cost
associated with component failure and budget constraints, LOGOS provides the optimal set of projects
(e.g., SSC replacement) to maximize profit and satisfy the provided reliability requirements.
The aforementioned input data can be either deterministic or stochastic in nature (i.e., they can be point values or probability distribution functions).
In the latter case, several scenarios are generated by
sampling the provided distributions.

The developed models are based on different versions of the knapsack optimization problem.
Two main classes of optimization models were initially developed: deterministic and stochastic.
Stochastic optimization models evolve deterministic models by explicitly considering data
uncertainties associated with constraints or item cost and reward. In FY-20, we moved forward
by implementing two schedule optimization methods. The first one reformulates the
capital budgeting problem in a distributionally robust form which allows the user to rely on
data directly rather than proposing a distribution from the data itself. The second one
reformulates the capital budgeting explicitly using risk measures as variable to be maximized or
minimized.

These models can be employed as stand-alone models or interfaced with the INL-developed RAVEN code
to propagate data uncertainties and analyze the generated data (i.e., sensitivity analysis).

\subsection{Acquiring and Installing LOGOS}
LOGOS is supported on three separate computing platforms: Linux, OSX (Apple Macintosh), and Microsoft
Windows.
 Currently, LOGOS can be downloaded from the LOGOS GitLab repository:
\url{https://hpcgitlab.hpc.inl.gov/RAVEN_PLUGINS/LOGOS.git}.
New users should contact LOGOS developers to get started with LOGOS.
This typically involves the following steps:

\begin{itemize}
  \item \textit{Download LOGOS}
    \\ You can download the source code for LOGOS from \url{https://hpcgitlab.hpc.inl.gov/RAVEN_PLUGINS/LOGOS.git}.
  \item \textit{Install LOGOS dependencies}
	\begin{lstlisting}[language=bash]
	path/to/LOGOS/build.sh --install
	\end{lstlisting}
  \item \textit{Activate LOGOS Libraries}
  \begin{lstlisting}[language=bash]
  source activate LOGOS_libraries
  \end{lstlisting}
  \item \textit{Test LOGOS}
	\begin{lstlisting}[language=bash]
	python run_tests.py
	\end{lstlisting}
  	Alternatively, the \texttt{logos} script
    contained in the folder ``\texttt{LOGOS}'' can be directly used:
\begin{lstlisting}[language=bash]
path/to/LOGOS/logos -i <inputFile.xml> -o <outputFile.csv>
\end{lstlisting}
	\item \textit{For use as a RAVEN Plugin}, RAVEN must first be downloaded from
  \url{https://github.com/idaholab/raven.git}.
		\\ Detailed instructions are available from \url{https://github.com/idaholab/raven/wiki}.
    To register a plugin with RAVEN and make its components accessible, run the script:
    \begin{lstlisting}[language=bash]
raven/scripts/install_plugins.py -s /abs/path/to/LOGOS
  	\end{lstlisting}
    After the plugin registration, then following the installation instruction at
    \url{https://github.com/idaholab/raven/wiki/installationMain} to install the
    required dependencies.
\end{itemize}

\subsection{User Manual Formats}
In this manual, we employ the following formats to highlight specific elements with
particular meanings (i.e., input structure, examples, and terminal commands):

\begin{itemize}
\item \textbf{\textit{Python Coding:}}
\begin{lstlisting}[language=python]
class AClass():
  def aMethodImplementation(self):
    pass
\end{lstlisting}
\item \textbf{\textit{LOGOS XML input example:}}
\begin{lstlisting}[style=XML,morekeywords={anAttribute}]
<MainXMLBlock>
  ...
  <aXMLnode anAttribute='aValue'>
     <aSubNode>body</aSubNode>
  </aXMLnode>
  <!-- This is  commented block -->
  ...
</MainXMLBlock>
\end{lstlisting}
\item \textbf{\textit{Bash Commands:}}
\begin{lstlisting}[language=bash]
cd path/to/LOGOS/
./build.sh --install
cd ../../
\end{lstlisting}
\end{itemize}

\subsection{Components of LOGOS}
In LOGOS, eXtensible Markup Language (XML) format is used to create the input file.
For more information about XML, please click on the link:
\href{https://www.w3schools.com/xml/default.asp}{\textbf{XML tutorial}}.
%
\\The main input blocks are as follows:
\begin{itemize}
  \item \xmlNode{Logos}: The root node containing the
  entire input; all of
  the subsequent blocks fit inside the \emph{LOGOS} block.
  %
  \item \xmlNode{Settings}: Specifies the calculation settings (i.e. options for
	optimization solvers, options for constraints, and working directory.)
  %
  \item \xmlNode{Sets}: Specifies a collection of data, possibly including
	numeric data (e.g. real or integer values) as well as symbolic data (e.g. strings)
	typically used to specify valid indices for indexed components.
	\nb numeric data provided in the \xmlNode{Sets} would be treated as strings.
  %
	\item \xmlNode{Parameters}: Specifies a collection of parameters, which are
  numerical values used to formulate constraints and objectives in a
	optimization model. A parameter can denote a single value, an array of values, or a multi-dimensional
	array of values.
	%
	\item \xmlNode{Uncertainties}: Specifies a collection of scenarios, which are
	numerical values used to simulate variations within parameters. A scenarios should follow
	the same format as the parameter.
	%
	%
	\item \xmlNode{ExternalConstraints}: Specifies a collection of external constraints, which are
  Python functions used to add additional constraints to the
	current optimization problem.
	%
\end{itemize}

Each of these components is explained in dedicated sections of the user manual.

\subsection{Capabilities of LOGOS}
This document provides a detailed description of LOGOS.
The features included in LOGOS are:
\begin{itemize}
    \item Overview of modeling components (see Section~\ref{sec:ModelingComponents})
	\item Deterministic capital budgeting (see Section~\ref{sec:DeterministicCapitalBudgeting})
	\item Prioritizing project selection to hedge against uncertainty (see Section~\ref{sec:StochasticCapitalBudgeting})
    \item Distributionally robust optimization (see Section~\ref{sec:DROCapitalBudgeting})
    \item Risk-based stochastic capital budgeting using conditional Value-at-Risk (See Section~\ref{sec:CVaR})
    \item Plugin for the RAVEN code (see Section~\ref{sec:RavenPlugin})
	\item SSC cashflow and NPV models (see Section~\ref{sec:SSCNPV})
\end{itemize}


\documentclass[12pt,a4paper,titlepage,final]{article}

\usepackage[czech,english]{babel}
\usepackage[utf8]{inputenc}
\usepackage{dirtytalk}
\usepackage[bookmarksopen,colorlinks,plainpages=false,urlcolor=blue,unicode]{hyperref}
\usepackage{url}
\usepackage{amsthm}
\usepackage[dvipdf]{graphicx}
\usepackage[top=3.5cm, left=2.5cm, text={17cm, 24cm}, ignorefoot]{geometry}
\everymath{\displaystyle}

\begin{document}

\def\author{Attila Večerek}
\def\email{xvecer17@stud.fit.vutbr.cz}
\def\projname{Demonstartion of Basic Fuzzy Set Operations }

\input{title.tex}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% obsah
\pagestyle{plain}
\pagenumbering{Roman}
\setcounter{page}{1}
\tableofcontents

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% textova zprava
\newpage
\pagestyle{plain}
\pagenumbering{arabic}
\setcounter{page}{1}

%=============================================================================

\section{Introduction} \label{introduction}
This report discusses and presents the design and implementation of a desktop application capable of demonstrating the 3 basic erations over fuzzy sets:

\begin{itemize}
\item union,
\item intersection,
\item and complement.
\end{itemize}

The assignment has stated to demonstrated these operations over \textit{discrete} fuzzy sets. However, this report discusses the solution of operations over \textbf{continuous} fuzzy sets.

%=============================================================================

\section{Theory} \label{theory}
In this section, we will briefly cover the theoretical knowledge needed for this project.

\subsection{Fuzzy set}
A \textbf{fuzzy set} is a generalization of an ordinary set by allowing a \textbf{degree} (or \textbf{grade}) \textbf{of membership} for each element. A membership degree is a real number on [0, 1] \cite{fuzzy}.

\subsection{Membership function}
The \textbf{membership function} of a set maps each element to its degree. Having the elements of the set being associated with a degree of membership is the foundation of fuzzy sets as well as fuzzy systems \cite{fuzzy}.

\subsection{Universe}
The \textbf{universe} represents a regular set of elements that have an associated degree of membership in a given fuzzy set.

%=============================================================================
\section{Design} \label{design}
The application has been designed to satisfy the following requirements from the perspective of a user:

\begin{enumerate}
\item it should be possible to define a common universe to the fuzzy sets,
\item it should be possible to define upto 2 fuzzy sets by their respective names (optionally) and membership functions,
\item it should be possible to define the membership function as a mathematical expression,
\item and it should be possible to run the operations only in cases, when all the necessary input has been given.
\end{enumerate}

\subsection{Logic} \label{logic}
The logic of the application is responsible for all the computation required for parsing the user input as well as processing the fuzzy operations. The fuzzy model consists of 3 main classes: \texttt{FuzzySet}, \texttt{FuzzyMember} and \texttt{MembershipFunction}. The MembershipFunction class is dependant on the \texttt{Math} subpackage which is responsible for parsing the membership function input by the user. In order to parse and evaluate math expressions, the \textbf{com.scireum.Parsii} open-source module has been chosen as a project dependency \cite{parsii}.

\noindent
\begin{figure}[h]
\centering
\includegraphics[width=1.0\textwidth]{img/model-UML}
\caption{The logic of the application}
\label{fig:model}
\end{figure}

Parsii has been chosen because of its ease of use and integration as well as it is one of the fastest expression evaluators implemented in Java based on an article published by \url{http://www.javacodegeeks.com/} \cite{performanceTest}.

To define a discrete universe to the fuzzy sets, the user needs to specify a range or several ranges of decimal numbers, i.e. the range \texttt{1..10} stands for a left-closed and right-open interval between 1 and 10, whereas \texttt{1...10} marks a closed interval. Notice the difference in the number of dots in the respective examples. The universe can also be defined by a list of ranges separated by a sequence of characters described by the regular expression \verb|,\\s^{+}|.

\subsection{Front-end} \label{ui}
The application follows the design pattern called MVC which stands for Model-View-Controller. The Figure \ref{fig:guiUML} represents the dependencies between the packages and the communication flow between the instances of the respective classes. The \texttt{MainController} consists of an instance of \texttt{FuzzyLineChart} to be able to operate with it (\verb|initialize| and \verb|update| operations). It also communicates with the \texttt{ApplicationHelper} class which is responsible for creating the user-defined universe. Both the \texttt{MainController} and \texttt{ApplicationController} utilize the \texttt{Model} package described in the above section to be able to create the necessary fuzzy sets and run the user-selected operations above them. The \texttt{FuzzyLineChart} class wraps a \textbf{JavaFX LineChart} and populates it with the required datapoints obtained by the \texttt{MainController}, thus rendering the expected chart output.

\noindent
\begin{figure}[h]
\centering
\includegraphics[width=0.7\textwidth]{img/gui-UML}
\caption{Frontend design}
\label{fig:guiUML}
\end{figure}

\subsubsection{User Experience}
A good user experience is never bad. With that and the best practices in mind, the user interface has been divided into two integral parts as it is seen in Figure \ref{fig:gui}. The bigger part of the screen is assigned to the description of the fuzzy operation and its result. On the right side of the screen, there is the pane that serves the purpose of inputting all the information in relation to the fuzzy sets and the operations to be done over them.

\noindent
\begin{figure}[h]
\centering
\includegraphics[width=1.0\textwidth]{img/gui}
\caption{The graphical user interface}
\label{fig:gui}
\end{figure}

\paragraph{Error messages}
There are 4 possible error messages in relation to invalid input:
\begin{enumerate}
\item the definition of the universe is not parsable,
\item the membership function is not parsable,
\item the membership function cannot be evaluated,
\item the same name has been given to the fuzzy sets.
\end{enumerate}

A valid universe definition can be either a range, list of several ranges or an enumeration of decimal numbers. In all other cases it invokes an error message which is a hyperlink leading to the Git repository of the project and its \texttt{README} file as seen in Figure \ref{fig:universeDefinitionError}.

The membership function is parsable and evaluable if it is an expression parsable by the \texttt{com.scireum.Parsii} module and it contains exactly one variable, i.e. the \verb|x| in expression \verb|abd(sin(x))|. Otherwise the respective errors would rise up as seen in Figure \ref{fig:membershipParseError} and \ref{fig:membershipEvalError}.

\begin{figure}[!htb]
\minipage{0.32\textwidth}
  \includegraphics[width=\linewidth]{img/universe-definition-error}
  \caption{Parse error U}\label{fig:universeDefinitionError}
\endminipage\hfill
\minipage{0.32\textwidth}
  \includegraphics[width=\linewidth]{img/membership-parse-error}
  \caption{Parse error memb()}\label{fig:membershipParseError}
\endminipage\hfill
\minipage{0.32\textwidth}
  \includegraphics[width=\linewidth]{img/membership-evaluation-error}
  \caption{Eval error memb()}\label{fig:membershipEvalError}
\endminipage
\end{figure}

The fourth error message occurs when both fuzzy sets have been assigned with the same name as it is shown in Figure \ref{fig:setNameError}.

\begin{figure}[!htb]
\minipage{0.45\textwidth}
  \includegraphics[width=\linewidth]{img/set-name-error}
  \caption{Identical set name error} \label{fig:setNameError}
\endminipage\hfill
\minipage{0.45\textwidth}
  \includegraphics[width=\linewidth]{img/buttons-disabled}
  \caption{Eval error memb()}\label{fig:disabledButtons}
\endminipage
\end{figure}

\paragraph{Action Buttons}
In order to prevent any further errors, the respective action buttons are enabled only in case that all the required fields have been filled out and the input information is valid. The Figure \ref{fig:disabledButtons} shows that the binary operations are disabled when only the first fuzzy set has been set up.

\noindent
\begin{figure}[!h]
\centering
\includegraphics[width=0.7\textwidth]{img/line-chart}
\caption{The line chart}
\label{fig:lineChart}
\end{figure}

\paragraph{Line Chart}
The line chart is the most important element of the UI. It presents the result of the basic operations over the specified fuzzy sets. The following information are always shown to the user, so he is always aware of the currently presented fuzzy operation and its details: \textit{title of the operation}, the \textit{line chart} and the \textit{legend}. An example can be seen in Figures \ref{fig:gui} and \ref{fig:lineChart}.
%=============================================================================
\section{Implementation} \label{implementation}
The desktop application has been implemented in Java 8. It uses the \texttt{com.scireum.Parsii} module to parse and evaluate mathematical expressions. The GUI is implemented using the \texttt{JavaFX 8} library. The tests are written in \texttt{Groovy} using the \texttt{Spock} framework.

As it has already been mentioned, the application is capable of operating with fuzzy sets defined by a \textit{continuous} universe. In this section we will describe and discuss the implementation of exactly this issue.

\subsection{Discrete vs. continuous}
A digital computer is not able to work with continuous data in their raw form. It uses sampling with an approriate sampling rate to create a set of discrete data it can finally process and operate with. However, the sampling frequency can be set very high, so the produced discrete data may seem for the human eye as continuous. That is exactly the same procedure our desktop application has adopted.

 When a user specifies the universe with a range, e.g. \texttt{0...1}, the application has to decide about the appropriate sampling rate. Too high sampling could be very memory inefficient. On the other hand, too low sampling rate would cause a non-linear member function to loose its \say{curviness}. To find an optimum, the application examines the width of the linechart in pixels. That number is considered as the maximal number of datapoints presented on the chart. Assume the formerly defined universe with the range of \texttt{0...1} and a line chart of a 100 pixels width. It means that the specified interval needs to be discretized into 100 evenly distributed data points across that interval.

 The next step is to compute the \textit{precision}. In the above example of a closed range the computation would look as following. Let us assume an unrealistic case of a 5 pixels wide linechart to make the example trivial. The step would be then equal to $\frac{1 - 0}{5 - 1} = 0.25$. If it were a left-closed and right-open range, the computation would be as follows: $\frac{1 - 0}{5} = 0.2$.

 \subsection{The algorithm}
 The application operates with only as many datapoints as needed in order to be memory and computation efficient. The following steps describe the workflow that takes place since the start until the end which in our case means that the line chart is populated with data and presented to the user.

 \begin{enumerate}
 \item The user enters a \texttt{String} as an input in the universe definition text field.
 	\begin{enumerate}
 	\item The \verb|ApplicationHelper| class checks, whether the input matches an acceptable format.
 	\item If the given input has been evaluated as invalid, the \verb|MainController| sets the error message visible. Otherwise, it does not do anything.
 	\end{enumerate}
\item The user fills out the member function text field.
	\begin{enumerate}
	\item The \verb|MainController| invokes a method chain leading to the \texttt{Parsii} module which parses the member function.
	\item If the given input is not parsable or contains more than 1 variable, an appropriate error message will be set visible.
	\end{enumerate}
\item The user clicks the Complement operation action button.
	\begin{enumerate}
	\item The \verb|MainController| obtains the width of the line chart and sets the \texttt{precision} accordingly.
	\item Then, it creates the universe which is  a \verb|Set| of \verb|FuzzyMember|s generated by the \verb|Range| class.
	\item After the universe is created, the user-specified \verb|FuzzySet| is instantiated.
	\item In the following step, the complement of the instantiated \verb|FuzzySet| is created.
	\item Lastly, the \verb|MainController| populates the line chart with the created fuzzy sets in the exact same order as they have been created. It assures that the data points of the complement fuzzy set will overwrite the data points of the user-specified fuzzy set in the chart.
	\end{enumerate}
 \end{enumerate}

 \noindent
\begin{figure}[!h]
\centering
\includegraphics[width=1.0\textwidth]{img/discontinuous-ranges}
\caption{Line chart lacking discontinuity}
\label{fig:discontinuousRanges}
\end{figure}

\subsection{Known issues}
The application is able to present fuzzy sets defined by continuous universes. However, it cannot handle disconinuity. Assume a case when multiple ranges have been specified as the universe by the user, e.g. \verb|1...10, 20...30|. The LineChart of the JavaFX library does not offer any tool to handle such situations. It connects the specified datapoints with a straight line. Having said that, such definitions of the universe may lead to results as seen in Figure \ref{fig:discontinuousRanges}. A possible solution would be to inject another datapoint before the start and after the end of each range with a membership degree of \verb|Double.NaN|. This way the last point of a range and the first point of the following would be connected somewhere outside - in the undefined part of the line chart.

%=============================================================================
\section{Conclusion} \label{conclusion}
This report introduced a desktop application capable of operating with fuzzy sets defined by a continuous univers and a member function as a mathematical expression and demonstrate the 3 basic fuzzy operations over them. We presented the design of the application along with the implementation details and had a more in-depth discussion about challanges met during the development of the project regarding the representation of continuous data sets on a discrete system.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% seznam citovana literatury: kaada poloaka je definovana paakazem
% \bibitem{xyz}, kde xyz je identifikator citace (v textu pouaij: \cite{xyz})
\newpage
\begin{thebibliography}{1}
\bibitem{fuzzy}
T. Munakata. Fundamentals of the New Artificial Intelligence. Springer Science, 2008
\bibitem{parsii}
Andreas Haufler. scireum/parsii. \url{https://github.com/scireum/parsii}
\bibitem{performanceTest}
Andreas Haufler. How to write one of the fastest expression evaluators in Java? \url{https://www.javacodegeeks.com/2014/01/how-to-write-one-of-the-fastest-expression-evaluators-in-java.html}
\end{thebibliography}

\end{document}