\documentclass{article}

\usepackage{amsmath,amssymb}
\usepackage[dvipdfmx]{hyperref,graphicx}
\usepackage{listings}

\lstset{%
  language={lisp},
  basicstyle={\small\ttfamily},%
  identifierstyle={\small},%
  commentstyle={\small\itshape},%
  keywordstyle={\small\bfseries},%
  ndkeywordstyle={\small},%
  stringstyle={\small\ttfamily},
  frame={tb},
  keepspaces=true,
  breaklines=true,
  columns=[l]{fullflexible},%
  numbers=left,%
  xrightmargin=0zw,%
  xleftmargin=3zw,%
  numberstyle={\scriptsize},%
  stepnumber=1,
  numbersep=1zw,%
  lineskip=-0.5ex%
}

\title{Typing Rule of Baremetalisp}
\author{Yuuki Takano\\ ytakano@wide.ad.jp}

\begin{document}

\maketitle

\section{Introduction}

In this paper, I will formally describe the typing rule of Baremetalisp,
which is a well typed Lisp for trusted execution environment.

\begin{table}[tb]
    \centering
    \caption{Notation}
    \label{tab:notation}
    \begin{tabular}{rl}
        $A \Rightarrow B$ & logical implication (if A then B)\\
        $e$ & expression \\
        $z$ & integer literal such as 10, -34, 112 \\
        $x$ & variable \\
        $t$ & type variable \\
        $D$ & type name of user defined data \\
        $L$ & label of user defined data \\
        $E$ & effect \\
        $E_\mathcal{T}: T \rightarrow E$ & effect of type \\
        $\mathcal{T}$ & type \\
        $C$ & type constraint \\
        $io(C): C \rightarrow \mathtt{Bool}$ & does $C$ contain $\mathtt{IO}$ functions? \\
        $\Gamma$ & context \\
        $\mathcal{P}$ & pattern \\
        $\mathcal{P}_{let}$ & pattern of let expression \\
        $\mathcal{T}_1 \equiv_\alpha \mathcal{T}_2$ & $\mathcal{T}_1$ and $\mathcal{T}_2$ are $\alpha$-equivalent \\
        $\mathcal{S} : t \rightarrow \mathcal{T}$ & substitution from type variable to type\\
        $\mathcal{T} \cdot \mathcal{S}$ & apply $\mathcal{S}$ to $\mathcal{T}$ \\
        $\mathcal{X}$ & set of $t$ \\
        $FV_\mathcal{T} : \mathcal{T} \rightarrow \mathcal{X}$ & function from $\mathcal{T}$ to its free variables\\
        $FV_\Gamma : \Gamma \rightarrow \mathcal{X}$ & function from $\Gamma$ to its free variables\\
        $Size : L \rightarrow \mathtt{Int}$ & the number of labels $L$'s type has \\
        $\Gamma \vdash e : \mathcal{T}\ |_\mathcal{X}\ C$ & $e$'s type is deduced as $\mathcal{T}$ from $\Gamma$ \\
        & under constraint $C$ and type variables $\mathcal{X}$
    \end{tabular}
\end{table}

\begin{figure}[tb]
    \centering
    \begin{tabular}{rrll}
    $\mathcal{C}$ & := & $\mathcal{T} = \mathcal{T}, \mathcal{C}$ & \bf{type constraint} \\
        & $|$ & $\varnothing$ \\ \\

    $\Gamma$ & := & & \bf{context} \\
        &     & $x: \mathcal{T}, \Gamma$ & type of variable \\
        & $|$ & $L: \mathcal{T}, \Gamma$ & type of label \\
        & $|$ & $L_{nth}: \mathcal{T}, \Gamma$ & n-th type of label's element \\
        & $|$ & $\varnothing$ \\ \\

    $E$ & := & $\mathtt{Pure}\ |\ \mathtt{IO}$ & \bf{effect} \\ \\

    $\mathcal{T}$ & := & & \bf{type} \\
        &     & $\mathtt{Int}$ \\
        & $|$ & $\mathtt{Bool}$ \\
        & $|$ & $'(\mathcal{T})$ & list type \\
        & $|$ & $[\mathcal{T}+]$ & tuple type \\
        & $|$ & $D$    & user defined type \\
        & $|$ & $(D\ \mathcal{T}+)$ & user defined type with type arguments \\
        & $|$ & $(E\ (\rightarrow\ (\mathcal{T}*)\ \mathcal{T}))$ & function type \\
        & $|$ & $t$ & type variable \\ \\

    $\mathcal{P}$ & := & & \bf{pattern} \\
        &     & $x$ & variable \\
        & $|$ & $L$ & label \\
        & $|$ & $(L\ \mathcal{P}+)$ & label with patterns \\
        & $|$ & $'()$ & empty list \\
        & $|$ & $[\mathcal{P}+]$ & tuple \\ \\

    $\mathcal{P}_{let}$ & := & & \bf{patten for let} \\
        &     & $x$ & variable \\
        & $|$ & $(L\ \mathcal{P}_{let}+)$ & label with patterns \\
        & $|$ & $[\mathcal{P}_{let}+]$ & tuple \\
    \end{tabular}
    \caption{Syntax}
    \label{fig:syntax}
\end{figure}

\section{Notation and Syntax}

Table~\ref{tab:notation} and Fig.~\ref{fig:syntax} shows notation used in this paper
and syntax for the typing rule, respectively.

\begin{lstlisting}[caption=Example of variable and type,label=src:vars]
(defun add (a b) (Pure (-> (Int Int) Int))
    (+ a b))
\end{lstlisting}

$x$ is a variable.
For example, $x \in \{a, b\}$ in Listing~\ref{src:vars}.
$\mathcal{T}$ is a type.
For example, $\mathcal{T} \in \{\mathtt{Int}, (\rightarrow\ (\mathtt{Int}\ \mathtt{Int})\ \mathtt{Int})\}$
in Listing~\ref{src:vars}.
$(\rightarrow\ (\mathtt{Int}\ \mathtt{Int})\ \mathtt{Int})$ is a function type which takes 2 integer values
and return 1 integer value.
$\mathtt{Pure}$ in Listing~\ref{src:vars} denotes the effect of the function but I just ignore it now.
Function effects will be described in Sec.~\ref{sec:effect}.
$\mathcal{T}$ can be other forms as described in Fig.~\ref{fig:syntax} such as
$\mathtt{Bool}$, $'(\mathtt{Int})$, $[\mathtt{Bool}\ \mathtt{Int}]$, $(\mathrm{List}\ a)$, $(\mathrm{List}\ \mathtt{Int})$.
$C$ is a type constraint, which is a set of pairs of types.
For example, $C = \{(\rightarrow\ (t_1\ t_2)\ t) = (\rightarrow\ (\mathtt{Int}\ \mathtt{Int})\ \mathtt{Int})\}$ deduced from
Listing~\ref{src:vars} means $(\rightarrow\ (t_1\ t_2)\ t)$ and $(\rightarrow\ (\mathtt{Int}\ \mathtt{Int})\ \mathtt{Int})$ are
semantically equal and every type variable in $C$, $t_1, t_2, t$, is thus $\mathtt{Int}$.
$\Gamma$ is a map from variable and label to type.
For example, $\Gamma = \{a : t_1, b : t_2, + : (\rightarrow\ (\mathtt{Int}\ \mathtt{Int})\ \mathtt{Int})\}$
in Listing~\ref{src:vars}.
$\Gamma$ is called context generally, thus I call $\Gamma$ context in this paper.

\begin{lstlisting}[caption=Example of user defined data type,label=src:cons]
(data (List a)
    (Cons a (List a))
    Nil)
\end{lstlisting}

$t$ is a type variable.
For example, $t \in \{a\}$ in Listing~\ref{src:cons}.
$L$ is a label for user defined type.
For example, $L \in \{\mathrm{Cons}, \mathrm{Nil}\}$ in Listing~\ref{src:cons}.
$D$ is user defined data.
For example, $D \in \{\mathrm{List}\}$ in Listing~\ref{src:cons}.
$\Gamma$ will hold mapping from labels in addition to variables.
For example,
$\Gamma = \{\mathrm{Cons} : (\mathrm{List}\ a), \mathrm{Nil} : (\mathrm{List}\ a), \mathrm{Cons}_{1st} : a, \mathrm{Cons}_{2nd} : (\mathrm{List}\ a)\}$
in Listing~\ref{src:cons}.

$FV_\mathcal{T}$ and $FV_\Gamma$ are functions, which take $\mathcal{T}$ and $\Gamma$ and return free variables.
For example, $FV_\mathcal{T}((\rightarrow\ (t_1\ t_2)\ t)) = \{t_1, t_2, t\}$ and
\begin{equation*}
    \begin{aligned}
        &FV_\Gamma(\{a : t_1, b : t_1, + : (\rightarrow\ (\mathtt{Int}\ \mathtt{Int})\ \mathtt{Int})\}) \\
        &=\{FV_\mathcal{T}(t_1), FV_\mathcal{T}(t_1), FV_\mathcal{T}((\rightarrow\ (\mathtt{Int}\ \mathtt{Int})\ \mathtt{Int}))\} \\
        &=\{t_1, t_2\}.
    \end{aligned}
\end{equation*}
$\mathcal{T}_1 \equiv_\alpha \mathcal{T}_2$ denotes that $\mathcal{T}_1$ and $\mathcal{T}_2$ are $\alpha$-equivalent,
which means $\mathcal{T}_1$ and $\mathcal{T}_2$ are semantically equal.
For example, $(\rightarrow\ (t_1\ t_2)\ t) \equiv_\alpha (\rightarrow\ (t_{10}\ t_{11})\ t_{12})$.
$\mathcal{S}$ is a substitution, which is a map from type variable to type,
and it can be applied to $\mathcal{T}$ as $\mathcal{T} \cdot \mathcal{S}$.
For example, if $\mathcal{S}(t_1) = [\mathtt{Bool}\ \mathtt{Int}], \mathcal{S}(t_2) = (\mathrm{List}\ t_3)$ then
$(\rightarrow\ (t_1\ t_2)\ t) \cdot \mathcal{S} = (\rightarrow\ ([\mathtt{Bool}\ \mathtt{Int}]\ (\mathrm{List}\ t_3))\ t)$.

\begin{lstlisting}[caption=Example of pattern matching,label=src:match]
(data Dim2 (Dim2 Int Int))

(data (Maybe t)
    (Just t)
    Nothing)

(defun match-let (a) (Pure (-> ((Maybe Dim2)) Int))
    (match a
        ((Just val)
            (let (((Dim2 x y) val))
                (+ x y)))
        (Nothing
            0)))
\end{lstlisting}
$\mathcal{P}$ and $\mathcal{P}_{let}$ are pattern in match and let expressions.
For example, in listings~\ref{src:match}, $(\mathrm{Just}\ val)$ and Nothing at line 9 and 12 are from $\mathcal{P}$
and $(\mathrm{Dim2}\ x\ y)$ at line 10 is from $\mathcal{P}_{let}$.
$Size$ is a function which takes a label and return the number of labels the label's type has.
For example, $Size(\mathrm{Just}) = Size(\mathrm{Nothing}) = 2$ because Maybe type has 2 labels
and $Size(\mathrm{Dim2}) = 1$ because Dim2 type has 1 label in listings~\ref{src:match}.

\begin{figure}[tb]
    \centering
    \begin{tabular}{rlrl}
        $\Gamma \vdash \mathtt{true} : \mathtt{Bool}\ |_\varnothing\ \varnothing$ & (T-True) &
        $\Gamma \vdash \mathtt{false} : \mathtt{Bool}\ |_\varnothing\ \varnothing$ & (T-False) \vspace{5mm} \\

        $\dfrac{x : T \in \Gamma}{\Gamma \vdash x : T\ |_\varnothing\ \varnothing}$ & (T-Var) &
        $\Gamma \vdash z : \mathtt{Int}\ |_\varnothing\ \varnothing$ & (T-Num) \vspace{5mm} \\

        $\dfrac{x : T' \in \Gamma \hspace{5mm} T' \cdot S \equiv_\alpha T}{\Gamma \vdash x : T\ |_{FV_\mathcal{T}(T)}\ \varnothing}$ & (T-VarPoly) \vspace{5mm} \\

        \multicolumn{3}{r}{
        $\dfrac{
            \begin{aligned}
                &\Gamma_0 \vdash \mathcal{P}_{let} : \mathcal{T}_0\ |_{\mathcal{X}_0}\ C_0 \hspace{5mm}
                    \Gamma \vdash e_1 : \mathcal{T}_1\ |_{\mathcal{X}_1}\ C_1 \hspace{5mm}
                    \Gamma, \Gamma_0 \vdash e_2 : \mathcal{T}_2\ |_{\mathcal{X}_2}\ C_2\\
                &\mathcal{X}_0 \cap \mathcal{X}_1 \cap \mathcal{X}_2 = \varnothing \hspace{5mm}
                    C = C_0 \cup C_1 \cup C_2 \cup \{ \mathcal{T}_0 = \mathcal{T}_1 \}
            \end{aligned}
        }{
            \Gamma \vdash (\mathtt{let1}\ \mathcal{P}_{let}\ e_1\ e_2) : \mathcal{T}_2\ |_{\mathcal{X}_0 \cup \mathcal{X}_1 \cup \mathcal{X}_2}\ C
        }$} & (T-Let1) \vspace{5mm} \\

        \multicolumn{3}{r}{
        $\dfrac{
            \begin{aligned}
                &\Gamma \vdash e_1 : \mathcal{T}_1\ |_{\mathcal{X}_1}\ C_1 \hspace{5mm} \Gamma \vdash e_2 : \mathcal{T}_2\ |_{\mathcal{X}_2}\ C_2 \hspace{5mm} \Gamma \vdash e_3 : \mathcal{T}_3\ |_{\mathcal{X}_3}\ C_3 \\
                &\mathcal{X}_1 \cap \mathcal{X}_2 \cap \mathcal{X}_3 = \varnothing \hspace{5mm} C = C_1 \cup C_2 \cup C_3 \cup \{ \mathcal{T}_1 = \mathtt{Bool}, \mathcal{T}_2 = T_3 \}
            \end{aligned}
        }{
            \Gamma \vdash (\mathtt{if}\ e_1\ e_2\ e_3) : \mathcal{T}_2\ |_{\mathcal{X}_1 \cup \mathcal{X}_2 \cup \mathcal{X}_3}\ C
        }$} & (T-If) \vspace{5mm} \\

        \multicolumn{3}{r}{
        $\dfrac{
            \begin{aligned}
                &\Gamma \vdash e_1 : \mathcal{T}_1\ |_{\mathcal{X}_1}\ C_1 \hspace{5mm}
                    \Gamma \vdash e_2 : \mathcal{T}_2\ |_{\mathcal{X}_2}\ C_2 \land \cdots \land \Gamma \vdash e_n : \mathcal{T}_n\ |_{\mathcal{X}_n}\ C_n \\
                &\{t\} \cap FV_\Gamma(\Gamma) = \varnothing \hspace{5mm} \{t\} \cap \mathcal{X}_1 \cap \cdots \cap \mathcal{X}_n = \varnothing\\
                &\mathcal{X} = \{t\} \cup \mathcal{X}_1 \cup \cdots \cup \mathcal{X}_n \hspace{5mm} E = E_\mathcal{T}(\mathcal{T}_1) \\
                &C = C_1 \cup \cdots \cup C_n \cup \{ \mathcal{T}_1 = (E\ (\rightarrow\ (\mathcal{T}_2\ \cdots\ \mathcal{T}_n)\ t)) \}
            \end{aligned}
        }{
            \Gamma \vdash (e_1\ e_2\ \cdots\ e_n) : t\ |_\mathcal{X}\ C
        }$} & (T-App) \vspace{5mm} \\

        \multicolumn{3}{r}{
        $\dfrac{
            \begin{aligned}
                &\Gamma \vdash e_0 : \mathcal{T}_0\ |_{\mathcal{X}_0}\ C_0 \\
                &\Gamma, \Gamma_1 \vdash e_1 : \mathcal{T}_{e1}\ |_{\mathcal{X}_{e1}}\ C_{e1} \land \cdots \land \Gamma, \Gamma_n \vdash e_n : \mathcal{T}_{en}\ |_{\mathcal{X}_{en}}\ C_{en} \\
                &\Gamma_1 \vdash \mathcal{P}_1 : \mathcal{T}_{p1}\ |_{\mathcal{X}_{p1}}\ C_{p1} \land \cdots \land \Gamma_n \vdash \mathcal{P}_{pn} : \mathcal{T}_{pn}\ |_{\mathcal{X}_{pn}}\ C_{pn} \\
                &\mathcal{X}_0 \cap \mathcal{X}_{e1} \cap \cdots \cap \mathcal{X}_{en} \cap \mathcal{X}_{p1} \cap \cdots \cap \mathcal{X}_{pn} = \varnothing \\
                &\mathcal{X} = \mathcal{X}_0 \cup \mathcal{X}_{e1} \cup \cdots \cup \mathcal{X}_{en} \cup \mathcal{X}_{p1} \cup \cdots \cup \mathcal{X}_{pn} \\
                &\begin{aligned}
                    C =\ &C_0 \cup C_{e1} \cup \cdots \cup C_{en} \cup C_{p1} \cup \cdots \cup C_{pn} \cup \\
                         &\{\mathcal{T}_0 = \mathcal{T}_{p1}, \cdots, \mathcal{T}_0 = \mathcal{T}_{pn}\} \cup
                         \{\mathcal{T}_{e1} = \mathcal{T}_{e2}, \cdots, \mathcal{T}_{e1} = \mathcal{T}_{en}\}
                \end{aligned}
            \end{aligned}
        }{
            \Gamma \vdash (\mathtt{match}\ e_0\ (\mathcal{P}_1\ e_1)\ \cdots\ (\mathcal{P}_n\ e_n)) : T_{e1}\ |_\mathcal{X}\ C
        }$} & (T-Match)
    \end{tabular}
    \caption{Typing rule (1/2)}
    \label{fig:typing1}
\end{figure}

\begin{figure}[tb]
    \centering
    \begin{tabular}{rlrl}
        $\Gamma \vdash\ '() :\ '(T)\ |_{\{T\}}\ \varnothing$ & (T-Nil) &
        $\dfrac{L : \mathcal{T}' \in \Gamma \hspace{5mm} \mathcal{T}' \cdot \mathcal{S} \equiv_\alpha \mathcal{T}}{\Gamma \vdash L : \mathcal{T}\ |_{FV_\mathcal{T}(\mathcal{T})}\ \varnothing}$ & (T-Label0) \vspace{5mm} \\

        \multicolumn{3}{r}{
            $\dfrac{
                \begin{aligned}
                    &\Gamma \vdash e_1 : T_1\ |_{\mathcal{X}_1}\ C_1 \land \cdots \land \Gamma \vdash e_n : T_n\ |_{\mathcal{X}_n}\ C_n \\
                    &\mathcal{X}_1 \cap \cdots \cap \mathcal{X}_n = \varnothing \hspace{5mm}
                    \mathcal{X} = \mathcal{X}_1 \cup \cdots \cup \mathcal{X}_n \hspace{5mm}
                    C = C_1 \cup \cdots \cup C_n
                \end{aligned}
            }{\Gamma \vdash [e_1\ \cdots\ e_n] : [T_1\ \cdots\ T_n]\ |_\mathcal{X}\ C}$
        } & (T-Tuple) \vspace{5mm} \\

        \multicolumn{3}{r}{
            $\dfrac{
                \begin{aligned}
                    &\Gamma \vdash e_1 : T_1\ |_{\mathcal{X}_1}\ C_1 \land \cdots \land \Gamma \vdash e_n : T_n\ |_{\mathcal{X}_n}\ C_n \\
                    &\mathcal{X}_1 \cap \cdots \cap \mathcal{X}_n = \varnothing \hspace{5mm}
                    \mathcal{X} = \mathcal{X}_1 \cup \cdots \cup \mathcal{X}_n \\
                    &C = C_1 \cup \cdots \cup C_n \cup \{T_1 = T_2, \cdots, T_1 = T_n \}
                \end{aligned}
            }{\Gamma \vdash\ '(e_1\ \cdots\ e_n) :\ '(T_1)\ |_\mathcal{X}\ C}$
        } & (T-List) \vspace{5mm} \\

        \multicolumn{3}{r}{
        $\dfrac{
            \begin{aligned}
                &\Gamma \vdash e_1 : \mathcal{T}_1\ |_{\mathcal{X}_1}\ C_1 \land \cdots \land
                    \Gamma \vdash e_n : \mathcal{T}_n\ |_{\mathcal{X}_n}\ C_n \\
                &L : \mathcal{T}_0' \in \Gamma \hspace{5mm} \mathcal{T}_0' \cdot \mathcal{S}\equiv_\alpha \mathcal{T}_0 \hspace{5mm} FV(\mathcal{T}_0) \cap \mathcal{X}_1 \cap \cdots \cap \mathcal{X}_n = \varnothing \\
                &FV_\mathcal{T}(\mathcal{T}_0) \cap FV_\Gamma(\Gamma) = \varnothing \hspace{5mm}
                    \mathcal{X} = FV(\mathcal{T}_0) \cup \mathcal{X}_1 \cup \cdots \cup \mathcal{X}_n \\
                &L_{1st} : T_1' \in \Gamma \land \cdots \land L_{nth} : T_n' \in \Gamma \\
                &C = C_1 \cup \cdots \cup C_n \cup \{T_1' \cdot \mathcal{S} = \mathcal{T}_1, \cdots, T_n' \cdot \mathcal{S} = \mathcal{T}_n\} \\
            \end{aligned}
        }{
            \Gamma \vdash (L\ e_1\ \cdots\ e_n) : \mathcal{T}_0\ |_{\mathcal{X}}\ C
        }$} & (T-Label) \vspace{5mm} \\

        \multicolumn{3}{r}{
            $\dfrac{
                \begin{aligned}
                    &\Gamma, x_1 : t_1, \cdots, x_n : t_n \vdash e : \mathcal{T}_0\ |_{\mathcal{X}}\ C_0 \hspace{5mm} \neg io(C)\\
                    &C = \{\mathcal{T} = (\mathtt{Pure}\ (\rightarrow\ (t_1\ \cdots\ t_n)\ \mathcal{T}_0))\} \cup C_0
                \end{aligned}
            }
            {
                \Gamma \vdash (\mathtt{lambda}\ (x_1\ \cdots\ x_n)\ e) : \mathcal{T}\ |_\mathcal{X}\ C
            }$
        } & (T-Lambda) \vspace{5mm} \\

        \multicolumn{3}{r}{
            $\dfrac{
                \begin{aligned}
                    &\Gamma, x_1 : t_1, \cdots, x_n : t_n \vdash e : \mathcal{T}_0\ |_{\mathcal{X}}\ C_0 \hspace{5mm}\\
                    &E = E_\mathcal{T}(\mathcal{T}) \hspace{5mm} (E = \mathtt{Pure}) \Rightarrow \neg io(C)\\
                    &C = C_0 \cup \{\mathcal{T} = (E\ (\rightarrow (\mathcal{T}_1\ \cdots\ \mathcal{T}_n)\ \mathcal{T}_0)) \}
                \end{aligned}
            }{
                \Gamma \vdash (\mathtt{defun}\ \mathrm{name}\ (x_1\ \cdots\ x_n)\ \mathcal{T}\ e) : \mathcal{T}\ |_\mathcal{X}\ C
            }$
        } & (T-Defun)
    \end{tabular}
    \caption{Typing rule (2/2)}
    \label{fig:typing2}
\end{figure}

\begin{figure}[tb]
    \centering
    \begin{tabular}{rlrl}
        $\Gamma \vdash \mathtt{true} : \mathtt{Bool}\ |_\varnothing\ \varnothing$ & (P-True) &
        $\Gamma \vdash \mathtt{false} : \mathtt{Bool}\ |_\varnothing\ \varnothing$ & (P-False) \vspace{5mm} \\

        $\dfrac{x : T \in \Gamma}{\Gamma \vdash x : T\ |_\varnothing\ \varnothing}$ & (P-Var) &
        $\Gamma \vdash z : \mathtt{Int}\ |_\varnothing\ \varnothing$ & (P-Num) \vspace{5mm} \\

        $\Gamma \vdash\ '() :\ '(T)\ |_{\{T\}}\ \varnothing$ & (P-Nil) &
        $\dfrac{L : \mathcal{T}' \in \Gamma \hspace{5mm} \mathcal{T}' \cdot \mathcal{S} \equiv_\alpha \mathcal{T}}{\Gamma \vdash L : \mathcal{T}\ |_{FV_\mathcal{T}(\mathcal{T})}\ \varnothing}$ & (P-Label0) \vspace{5mm} \\

        \multicolumn{3}{r}{
        $\dfrac{
            \begin{aligned}
                &\Gamma \vdash \mathcal{P}_1 : \mathcal{T}_1\ |_{\mathcal{X}_1}\ C_1 \land \cdots \land
                    \Gamma \vdash \mathcal{P}_n : \mathcal{T}_n\ |_{\mathcal{X}_n}\ C_n \\
                &L : \mathcal{T}_0' \in \Gamma \hspace{5mm} \mathcal{T}_0' \cdot \mathcal{S}\equiv_\alpha \mathcal{T}_0 \hspace{5mm} FV(\mathcal{T}_0) \cap \mathcal{X}_1 \cap \cdots \cap \mathcal{X}_n = \varnothing \\
                &FV_\mathcal{T}(\mathcal{T}_0) \cap FV_\Gamma(\Gamma) = \varnothing \hspace{5mm}
                    \mathcal{X} = FV(\mathcal{T}_0) \cup \mathcal{X}_1 \cup \cdots \cup \mathcal{X}_n \\
                &L_{1st} : T_1' \in \Gamma \land \cdots \land L_{nth} : T_n' \in \Gamma \\
                &C = C_1 \cup \cdots \cup C_n \cup \{T_1' \cdot \mathcal{S} = \mathcal{T}_1, \cdots, T_n' \cdot \mathcal{S} = \mathcal{T}_n\} \\
                &Size(L) = 1\ \mbox{for only}\ P_{let}
            \end{aligned}
        }{
            \Gamma \vdash (L\ \mathcal{P}_1\ \cdots\ \mathcal{P}_n) : \mathcal{T}_0\ |_{\mathcal{X}}\ C
        }$} & (P-Label) \vspace{5mm} \\

        \multicolumn{3}{r}{
        $\dfrac{
            \begin{aligned}
                &\Gamma \vdash \mathcal{P}_1 : \mathcal{T}_1\ |_{\mathcal{X}_1}\ C_1 \land \cdots \land
                    \Gamma \vdash \mathcal{P}_n : \mathcal{T}_n\ |_{\mathcal{X}_n}\ C_n \\
                &\mathcal{X}_1 \cap \cdots \cap \mathcal{X}_n = \varnothing \hspace{5mm}
                    \mathcal{X} = \mathcal{X}_1 \cup \cdots \cup \mathcal{X}_n \hspace{5mm}
                    C = C_1 \cup \cdots \cup C_n
            \end{aligned}
        }{
            \Gamma \vdash [\mathcal{P}_1\ \cdots\ \mathcal{P}_n] : [\mathcal{T}_1 \cdots \mathcal{T}_n]\ |_{\mathcal{X}}\ C
        }$} & (P-Tuple) \\
    \end{tabular}
    \caption{Typing rule of pattern}
\end{figure}

\section{Typing Rule}

In this section, I will introduce the typing rule of Baremetalisp.
Before describing the rule, I introduce an assumption
that there is no variable shadowing to make it simple.
This means that every variable should be properly $\alpha$-converted
by using the De Bruijn index technique or variable shadowing should be handled
when implementing the type inference algorithm.

Fig.~\ref{fig:typing1} and \ref{fig:typing2} are the typing rule of
expressions and function definitions.

\section{Effect}
\label{sec:effect}

\end{document}


% !TEX root = ../00_thesis.tex
%-------------------------------------------------------------------------------
\section{Designing \triscale}
\label{sec:triscale}
%-------------------------------------------------------------------------------

In this section, we first describe the data analysis performed by \triscale and how the analysis procedure is linked to the design of experiments~(\cref{subsec:metrics} to \cref{subsec:repeatability}).
We then illustrate how the formalism introduced by \triscale allows to unambiguously describe an entire performance evaluation with only a handful of parameters~(\cref{subsec:parameters}).
Thereafter, we detail the robust and non-parametric statistical methods used by \triscale~(\cref{subsec:triscale_stats}), and discuss how the framework assists a user in deciding the required time span for a series of runs~(\cref{subsec:network_profiling}).
We finally show how \triscale helps assessing the reproducibility of experiments by computing a variability score~(\cref{subsec:reproducibility}).

%-------------------------------------------------------------------------------
\subsection{Runs and Metrics}
\label{subsec:metrics}

\afterpage{
\begin{figure}
    \centering
    \begin{subfigure}{\linewidth}
        \centering
       	\href{\triscalefig{Figure-3a}}{
        \includegraphics[scale=1]{Figures/plot_example_metric.pdf}}
        \caption{\raggedright Raw data (one-way delay) and metric data (95th percentile).}
        \label{fig:analysis_metric}
    \end{subfigure}

    \vspace{5pt}

    \begin{subfigure}{0.45\linewidth}
        \centering
       	\href{\triscalefig{Figure-3b}}{
        \includegraphics[scale=1]{Figures/plot_example_KPI.pdf}}
        \caption{Runs' metric data and corresponding KPI value.}
        \label{fig:analysis_kpi}
    \end{subfigure}
    %
    \hfill
    \begin{subfigure}{0.45\linewidth}
        \centering
     	  \href{\triscalefig{Figure-3c}}{
        \includegraphics[scale=1]{Figures/plot_example_var_score.pdf}}
        \caption{Series' KPI data and corresponding variability score.}
        \label{fig:analysis_score}
    \end{subfigure}
    \caption{Example plots produced by \triscale during the data analysis.
    \Cref{fig:analysis_metric}: computation of the metric (95th percentile on one-way delay) with convergence test (confidence 95\%, tolerance 1\%).
    \Cref{fig:analysis_kpi}: computation of the KPI (75th percentile with 75\% confidence).
    \Cref{fig:analysis_score}: computation of the variability score (25-75th percentiles with 75\% confidence).
    \capt{Sample data from the case study (\cref{sec:triscale_eval}) for the \textit{FillP} congestion-control scheme.}}
    \label{fig:analysis_examples}
\end{figure}
}

Metrics in \triscale evaluate a performance dimension across a run, for example, the mean throughput achieved by a congestion-control scheme over 30\s runtime of a full-throttle flow.
Computing a metric takes the following inputs.

\fakepar{Inputs}
\custommini{%
  \begin{itemize}
    \item The metric \emph{measure}; \eg mean, maximum, \etc
    \item The \emph{convergence} requirements\\
    \begin{tabular}{@{\quad}l@{\quad}r@{\;\;:\;\;}ll@{\quad}l}
      \{  & expected & \multicolumn{2}{@{}l}{true/false,} &\\
          & confidence & $C$  &(\textit{default: 95\%}),  &\\
          & tolerance & $t$   &(\textit{default: 5\%})    &\}
    \end{tabular}
  \item The raw data of the run.
  \end{itemize}
}%

\noindent
In general, any measure can be used. The current implementation (\cref{sec:triscale_implementation}) supports the arithmetic mean, the minimum, the maximum, and any percentile.

\fakepar{Procedure}
If the run is expected to converge, \triscale starts by performing a convergence test, whose purpose is to assess whether the metric has reached a stable value by the end of the run (and hence if it is a good estimate of the long-running performance).
%
To test this, \triscale computes metric values over a sliding window of the raw data points. For each window, whose size is fixed to half of the data points, one metric value is computed, starting with the first half of the data.
The window repeatedly slides by 100th of the number of samples until all data points are used, leading to a set of 100 metric values.%
\triscale performs its convergence test~(detailed in \cref{subsec:triscale_stats}) on the metric values.
This procedure tests the convergence of the \emph{metric} (not the raw data) and damps the impact of transient behavior on the convergence test.
If the test is passed, \triscale returns the median of metric values as run metric.
If convergence is not expected, \triscale simply computes the run metric over the whole raw data.

% To test this, \triscale divides the raw data in 200 chunks. First, it considers the first 100 chunks (\ie the first half of the data) and computes a first value of the measure. Then, \triscale adds one chunk of data and recomputes a new measure value (\ie using the first 101 chunks). The process repeats until all chunks are used, leading to a set of 100 measure values. \triscale performs its convergence test~(detailed in \cref{subsec:triscale_stats}) on the measure data.
% This procedure (i)~tests what we are interested in (\ie the convergence of the \emph{measure}, not of the protocol in general) and (ii)~smooths the effects of ramp-up time by computing the first measure with already half of the run data.
% If the test is passed, \triscale returns the median of the measure data as the metric measure for the run.

\begin{remark}
  If there are less than 100 raw data points, \triscale reduces the number of windows to the number of data points.
  \triscale (arbitrarily) sets a minimum of 20 data points for a convergence test.
\end{remark}

\fakepar{Outputs}
\custommini{%
\begin{itemize}
  \item
  The result of the convergence test (if performed),
  \item
  The metric value for the run,
  \item
  Textual logs; plot of the input data and metric (\Cref{fig:analysis_metric}).

\end{itemize}
}

\fakepar{Link to the experiment design}
The computation of \triscale metrics is linked to the definition of the \emph{runtime}; \ie how long a run should be.
If the evaluation scenario is terminating (\eg transmit 1\MB through a link), the runtime must be long enough to complete the task.
If the evaluation is ``long-running'' (\eg one-way delay in a full-throttle flow), the runtime must be long enough for the metric (the one-way delay) to converge (convergence test details in \cref{subsec:triscale_stats}).
\triscale can analyze preliminary experiments to estimate the required runtime: by performing increasing long runs and test for convergence~(illustrated in \cref{sec:triscale_eval}).

%-------------------------------------------------------------------------------
\subsection{Series and KPIs}
\label{subsec:KPIs}
%-------------------------------------------------------------------------------

\triscale's key performance indicators (KPIs) evaluate performance dimensions across a series of runs.
Performing multiple runs allows to mitigate the inherent variability of the experimental conditions.
KPIs capture this variability by estimating percentiles of the (unknown) metric distributions.
Concretely, a \triscale KPI is a one-sided CI of one percentile; \eg a lower-bound for the 75th percentile of the delay metric estimated with a 75\% confidence level.
Computing a KPI takes the following inputs.

\fakepar{Inputs}
\custommini{%
  \begin{itemize}
    \item
    The {KPI} definition\\
    \begin{tabular}{@{\quad}l@{\quad}r@{\;\;:\;\;}l@{\quad}l}
      \{  & percentile & $p$ &\\
          & confidence & $C$&\}
    \end{tabular}
    \item
    The metric data (computed from a series of runs).
\end{itemize}}

\fakepar{Procedure}
To compute the KPI (\ie to compute a CI for a given percentile), \triscale uses the Thompson's method (\cref{subsec:triscale_stats}), which requires the input data to be \iid.
Thus, \triscale starts by performing an independence test~(\cref{subsec:triscale_stats})
on the metric data before computing the KPI.

\fakepar{Outputs}
\custommini{
\begin{itemize}
  \item The result of the independence test,
  \item The KPI value for the series of runs,
  \item Textual logs; plot of the metric data and corresponding KPI (\Cref{fig:analysis_kpi}).
\end{itemize}
}

\fakepar{Link to the experiment design}
The computation of \triscale KPIs is linked to the definition of the number of runs in a series (\emph{\#\,runs}) and the series time span (\emph{span}).
The minimal number of runs in a series directly follows from the definition of the KPI; \ie the percentile to estimate $p$ and the desired confidence level $C$.
The series time span refers to the time interval used for scheduling the runs in a series (\ie when to run the experiment).
This is important because networks often feature time-dependent conditions; for example, there may be systematically more cross-traffic during daytime than nighttime. Failing to account for such dependencies may bias the results and yield wrong conclusions.
\triscale helps the experimenter handling this problem with a dedicated analysis module called ``network profiling'' (described in~\cref{subsec:network_profiling}).

%-------------------------------------------------------------------------------
\subsection{Sequels and Variability Score}
\label{subsec:repeatability}
%-------------------------------------------------------------------------------

\emph{Sequels} are repetitions of series of runs.
\triscale's variability score evaluates the variations of KPI values across sequels, which enable to detect long-term variations of KPIs and ultimately quantify the reproducibility of an experiment.

Concretely, a variability score is a two-sided CI, \ie a symmetric pair of percentiles. For example, a 75\% confidence interval is defined by the 25-75th percentiles of the delay KPIs from all sequels. Again, we attach a confidence value to the confidence interval, or equivalently, to the percentiles.

\fakepar{Inputs}
\custommini{%
\begin{itemize}
  \item
  The {variability score} definition\\
  \begin{tabular}{@{\quad}l@{\quad}r@{\;\;:\;\;}l@{\quad}l}
    \{  & percentile & $p$ (or 1-$p$) &\\
        & confidence & $C$&\}
  \end{tabular}
  \item
  The KPI values of each sequel.
\end{itemize}}

\fakepar{Procedure}
The procedure is the same as for the KPI: The Thompson's method requires the input data to be \iid~(\cref{subsec:triscale_stats}), thus \triscale performs an independence test on the KPI data before computing the variability score.

\fakepar{Outputs}
\custommini{%
\begin{itemize}
  \item
  The result of the independence test,
  \item
  The variability score value for the entire sequels,
  \item
  Textual logs; plot of the KPI data and corresponding variability score (\Cref{fig:analysis_score}).
\end{itemize}}

\fakepar{Link to the experiment design}
The computation of the variability score is linked to the definition of the number of series (\emph{\#series}).
The minimal number of series directly follows from the definition of the variability score; \ie the percentile to estimate $p$ and the desired confidence level $C$.

%-------------------------------------------------------------------------------
\subsection{Formalism Brings Conciseness}
\label{subsec:parameters}
%-------------------------------------------------------------------------------

\afterpage{
\begin{landscape}
  \begin{table}
      \centering
      \caption{Exemplary evaluation parameters of typical networking use cases.
      \capt{$^{*}$\triscale returns the minimal number of runs (\#runs) and series (\#series) based on the definition of KPI and variability score, respectively.}}
      \input{\PathTab/triscale_parameters.csv}
      \label{table:triscale_param}
  \end{table}
\end{landscape}
}

\triscale formalizes the definition of the evaluation objectives. For each performance dimension, the experimenter defines a metric and convergence requirements~(\cref{subsec:metrics}), a KPI~(\cref{subsec:KPIs}), and a variability score~(\cref{subsec:repeatability}).
\triscale links these objectives with the experiment design, resulting in four additional parameters: the number of runs per series (\emph{\#\,runs}), the number of series (\emph{\#\,series}), the length of a run (\emph{runtime}), and the time span of a series (\emph{span}).

Thanks to this formalism, \triscale meets the \feature{Conciseness} requirement:
Altogether, these 12 parameters are sufficient to \emph{formally describe the entire performance evaluation} such that it can (eventually) be reproduced.
In particular, since the data analysis in \triscale is automated and deterministic, documenting these parameters guarantees computational reproducibility (the ability to recreate the results when all raw data are available~\cite{liu19computational}).

\Cref{table:triscale_param} shows a few examples of concrete parameter settings for typical networking evaluation objectives.
For example, evaluating the latency of a real-time protocol requires high confidence levels for extreme percentiles.
This very quickly increases the number of runs that one must perform:\\
\inlineitem
  at least 90 runs for estimating the 95th percentile with 99\% confidence;\linebreak
\inlineitem
  at least 299 runs for estimating the 99th percentile with 95\% confidence.\linebreak
This illustrates that it is ``easier'' to increase the confidence level of an estimate than to estimate a more extreme percentile with the same confidence level.
Note that both \emph{\#runs} and \emph{\#series} are only derived based on the definition of the KPI and variability score; these parameters are not influenced by the runtime or the time span of an experiment.

The second use case in \Cref{table:triscale_param} (bottom rows) illustrates two different perspectives on ``averages'', using delay as an example:
\\
% \begin{itemize}
    % \item
    \inlineitem
    If the metric is the median and the KPI the 90th percentile, one can conclude that 90\% of the runs have a median delay equal or better than the KPI value.
\\
    % \item
    \inlineitem
    If the metric is the 90th percentile and the KPI the median, one can conclude that, in half of the runs, the 90th percentile of the delay in the run is equal or better than the KPI.
% \end{itemize}
\\
Both are ``averages'' but with different meanings and different requirements in terms of number of runs.

%-------------------------------------------------------------------------------
\subsection{Statistics in \triscale}
\label{subsec:triscale_stats}
%-------------------------------------------------------------------------------

\triscale uses carefully chosen statistical methods.
As discussed in~\cref{sec:stats}, networking performance evaluations should focus on statistics that are both \emph{robust} (\ie that can tolerate outliers) and \emph{non-parametric} (\ie that do not make any assumption on the nature of the data distribution).
This section describes the three statistical methods used in \triscale. We first present the convergence test used in the computation of metrics (\cref{subsec:metrics});
This test is based on the \mbox{Theil-Sen} linear regression~\cite{theil1992RankInvariant, sen1968Estimates}.
We then introduce the computation of confidence intervals using Thompson's method~\cite{thompson1936Confidence}, which requires the data to be \iid. Thus, to verify this assumption, \triscale integrates an independence test that we present last.

%-------------------------------------------------------------------------------
\fakepar{Convergence test}
\label{subsec:test_convergence}
When an evaluation aims to estimate the ``long-running'' performance (\ie the expected performance if the run would run “forever”), one must verify whether the runs are long enough to produce reliable estimates.

\squarepar{%
  To verify this, \triscale implements a convergence test based on the Theil-Sen linear regression~\cite{theil1992RankInvariant, sen1968Estimates}.
  This approach computes the slope of the regression line as the median of all slopes between paired values.
  A $C$\% confidence interval (CI) for the slope is defined as the interval containing the middle $C$\% of slopes between single pairs.
  \triscale convergence test is passed if the $C$\% CI for the regression is included in the tolerance value ($\pm$\,$t$\%).
  To test the convergence of a run, \triscale uses the confidence $C$ and tolerance $t$ parameters specified in the evaluation objectives (\Cref{sec:triscale_overview});
  otherwise defaults to 95\% and 5\%.}

Such a test is sensitive to the scale of the input data.
To remove this dependency, \triscale first maps the data to $[-1, 1]$ using a linear transformation then performs the convergence test on the scaled data.
Hence, the convergence test becomes dimensionless and the same tolerance value can be used for different evaluations without introducing bias.
An example of the Theil-Sen slope (brown, solid), its CI (light orange, solid), and tolerance (black, dotted) is shown in \Cref{fig:analysis_metric}.

%-------------------------------------------------------------------------------
\fakepar{Confidence intervals}
\triscale defines KPIs and variability scores based on CIs for distribution percentiles, which can be computed using a robust and non-parametric approach based on Thompson's method~\cite{thompson1936Confidence}, later shown to be valid for any independent samples of a continuous distribution~\cite{david2005Order}.

Let us denote by $P_p$, the $p$-th percentile of a distribution and $\mathbb{P}(X)$ the probability of an event $X$.
By definition, every data sample $x$ is smaller than $P_p$ with probability $p$ (and larger with probability $1-p$).
For a sorted list of \iid samples $x_i$ (where $i = 1 .. N$), the probability that $P_p$ lies between two consecutive samples follows the binomial distribution~\cite{thompson1936Confidence}:
\begin{equation}
    \mathbb{P}(x_k \leq P_p \leq x_{k+1}) = \binom{N}{k} p^k(1-p)^{N-k}, \quad k = 0 .. N
\end{equation}
where we assume $x_0 \rightarrow - \infty$ and $x_{N+1} \rightarrow +\infty$. From this result, it follows that the probability of $P_p$ to be larger than any sample $x_m$ (where $1\leq m < N$) can be computed as:
\begin{align}
  \nonumber
    \mathbb{P}(x_m \leq P_p)
      &= \mathbb{P}(x_{N-m+1} \geq P_{1-p})\\
  \label{eq:lb}
      &= 1 - \sum_{k=0}^{m-1} \binom{N}{k} p^k(1-p)^{N-k}
\end{align}
\Cref{eq:lb} provides the upper- and lower-bound required for computing of CIs.
Further, one can derive the minimum number of samples $N$ needed to compute a CI for any percentile $p$ with any confidence level $C$~\cite{schmid2014measuring}:
\begin{equation}
\label{eq:minN}
     \cref{eq:lb} \quad \Rightarrow \quad N \;\geq\; \frac{\log(1-C)}{\log(1-p)}
\end{equation}
which defines the minimum number of runs and series required based on the definitions of the KPIs and the variability scores.
If the probability distribution is discrete, \cref{eq:lb} becomes an inequality ($\mathbb{P}(x_m \leq P_p) \geq \ldots$~) that provides a safe (\ie conservative) estimate of which sample $x_m$ is the bound of the CI of interest~\cite{david2005Order}.

This approach provides robust estimates for distribution percentiles and \emph{does not make any assumption on the nature of the underlying distribution}.
It does, however, require that the data samples are \iid. \triscale checks whether this hypothesis holds using an independence test, described below.

%-------------------------------------------------------------------------------
\fakepar{Independence test}
Estimating the percentile of a distribution requires often (if not always) that the samples are \iid (\cref{sec:stats}); this is also the case for Thompson's method~\cite{thompson1936Confidence}.
\triscale implements an empirical independence test to verify whether the \iid assumption holds.

\begin{remark}
  Generally, independence results from the experiment design. For networking experiments, however, it is generally not possible to guarantee independence, \eg the experimental conditions cannot be fully controlled and may be correlated.
  In such cases, it is common to empirically check whether the data are correlated. If the effective dependence between data samples is sufficiently low, it is considered safe to treat the samples as \iid.
\end{remark}

This independence test is applied to the metric data (resp. KPI data) before the computation of a KPI (resp. a variability score).
This poses the particular challenge that the number of data samples may be very small (\eg 3 or 5 KPI values). \triscale's independence test must therefore not be too strict.

The test is divided in two steps. First, \triscale tests whether the data appear \emph{weakly stationary} (\ie no trend and constant autocorrelation structure~\cite{brockwell1991Time}). \triscale verifies this empirically using its convergence test with a confidence of 50\% and tolerance of 10\%; these ``loose'' parameters are used to compensate for (very) small sample sizes.
Second, \triscale computes the \emph{sample autocorrelation coefficients}, denoted by $\widehat{\rho_k}$, which measure the linear dependency between values of a weakly stationary data series.
A series of size $N$ is \iid with 95\% probability if $|\widehat{\rho_k}| \leq 1.95/\sqrt{N}$ for $k \geq 1$~\cite{brockwell1991Time}.

\fakeparQM{What if the tests fail}
The experimenter is responsible for designing the evaluation in such a way that the collected data will (likely) pass the tests.
\triscale facilitates this by guiding the choice of runtime to pass the convergence test and informing about any network time dependencies~(\cref{subsec:network_profiling}) to pass the independence test.
Yet, the data may still be correlated or unstable, leading to failing tests (see examples in ~\cref{sec:triscale_eval}).
Even in such cases, the data still contain useful information.
\triscale metrics, KPIs, or variability scores can be computed, however since the corresponding hypotheses do not hold, the statistics are \emph{only descriptive}~(\cref{sec:stats}); they do not predict the expected performance, and in particular they cannot (and should not be used to) assess the reproducibility of the experiment.

%-------------------------------------------------------------------------------
\subsection{Network Profiling}
\label{subsec:network_profiling}

\begin{figure}
    \centering
   	\href{\triscalefig{Figure-4}}{
    \includegraphics[scale=1]{Figures/plot_flocklab_autocorr.pdf}}

    \caption{Autocorrelation plot for the wireless link quality on FlockLab, based on the raw data collected by the testbed maintainers~\cite{jacob2019datasetLQE} (data from August 2019).
    \capt{The dataset contains one test every two hours. The first peak at lag 12 (\ie 24h) reveals the daily seasonal component. The data also show another at lag 84; which corresponds to one week. Indeed, there is less interference in the weekends than on weekdays: this creates a weekly seasonal component.}}
    \label{fig:flocklab_autocorr}
\end{figure}

\triscale assists the user in deciding on the time span for a series of runs, \ie when should the run be performed in a series. This is important to avoid biasing the evaluation results with time dependencies in the experimental conditions.
Indeed, it is common for real-world networks to exhibit periodic patterns.
For example, there may be a lot more cross-traffic (\ie interference) at specific times. In the statistics literature, these patterns are called \emph{seasonal components}.
Neglecting these may result in biased experiments leading to wrong conclusions, as illustrated in the case study below.

\squarepar{%
  \fakepar{Case study: low-power wireless}
  We run a simple evaluation of Glossy~\cite{ferrari2011Glossy}, a low-power wireless protocol based on synchronous transmissions~(\cref{sec:ST}). Glossy includes as parameter the number of retransmissions of a packet, called $N$. We investigate the impact of two values of $N$ on the reliability of Glossy, measured as the packet reception ratio (PRR). We define our KPI as the median with 95\% confidence level.
  Refer to \cref{append:triscale_artifacts} for the complete case study.%
}

We collect data using the FlockLab testbed~\cite{lim2013FlockLab}.
This testbed is located in an office building, where we expect more interference during daytime than nighttime.
Thus, we schedule a series of 24 runs randomly within one day.\linebreak
  \inlineitem $N=1$ leads to a PRR of 88\%,\\
  \inlineitem $N=2$ leads to a PRR of 84\%.\\
In other words, it appears that doing two retransmissions (instead of one) reduces reliability.

The experiment leads to this (incorrect) conclusion because we have neglected a second seasonal component of the FlockLab testbed: there is a weekly time dependence, revealed by \Cref{fig:flocklab_autocorr}.
To account for this dependency, one must schedule runs with a span of at least one week. When comparing again the performance of Glossy but with tests spanning over a week\\
  \inlineitem $N=1$ leads to a PRR of 80\%,\\
  \inlineitem $N=2$ leads to a PRR of 88\%,\\
which better matches our knowledge about the performance of Glossy.

\fakepar{Conclusion}
This simple example illustrates that using a high confidence level is not enough to avoid drawing wrong conclusions due to the variability in the experimental conditions.
On a real network, short-term variations are unpredictable and (often) unavoidable. This is why it is important to perform multiple runs in a series: it increases the chances to do the experiment in the whole range of favorable to unfavorable conditions.

However, we illustrated that systematic patterns are also present. In other words, there are times where there is consistently more or less interference. Knowing about these dependencies is important to
  ensure fairness in the comparison between protocols, and
  enable reproducibility of the evaluations.
The series span must be long enough such that it does not matter when the series actually starts (\eg a weekend or a weekday)

\squarepar{%
  \triscale integrates a network profiling function that analyzes link quality data (\eg available at~\cite{jacob2019datasetLQE}) and searches for seasonal components in the link quality data. This helps the experimenter detecting (sometimes unexpected) time dependencies, thus choosing a suitable time span for series of runs.}

%-------------------------------------------------------------------------------
\subsection{Assessing Reproducibility}
\label{subsec:reproducibility}

Reproducibility refers to the ability of obtaining ``the same'' results when performing ``the same'' experiment.
In statistics, such property can be investigated using \textit{equivalence testing}~\cite{lakens2017Equivalence}, which checks whether the values of some parameter of interest (\eg the median) obtained for different samples are sufficiently close to be considered ``the same''.
Unfortunately, there is no general way to define ``sufficiently close''; one must define in advance a threshold for the equivalence test based on expertise.
Then, how to assess reproducibility of networking experiments? How to design a ``reproducibility test'' that fairly adapts to different networking contexts and different metrics?
After some failed attempts, we conclude that defining a generic threshold for equivalence testing in networking might not be possible. But it may not be necessary.

We argue that the most important is to confidently estimate the variability of the results, which \triscale computes with its variability score~(\cref{subsec:repeatability}).
This score \emph{quantifies reproducibility}: the larger the score, the less reproducible the results are.
Shall a binary cut between ``reproducible'' and ``not reproducible'' be desired, a threshold can be set based on the variability score; \eg ``Results are said reproducible when the variability score is less than 20\mbps.''.
Such a threshold can only be context-specific; thus, deciding on threshold values relates more to benchmarking and therefore goes beyond the scope of \triscale~(see discussion in \cref{sec:going_further}).


\section{Contractual Money}
    \label{sec:contractual}

 In our opinion, the overwhelming majority of use-cases for public blockchains (even those that claim to provide a general-purpose decentralized world computer) are for financial applications, which do not require Turing-completeness. For instance, if an oracle writes down non-financial data into the blockchain~(such as temperature), this data is usually used further in a financial
 contract. Another trivial observation we make is that many applications use digital tokens with mechanics different from the native token.

For an application developer, the Ergo Platform offers custom tokens~(which are first-class citizens) and a domain-specific language for writing box protecting
 conditions in order to implement flexible and secure financial applications.
 Ergo applications are defined in terms of protecting scripts built into boxes, which may also contain data involved in the execution.
 We use the term {\em contractual money} to define Ergs (and secondary tokens) whose usage is bounded by a contract. This applies to all tokens on the platform in existence because any box with its contents~(Ergs, tokens, data) is bounded by a contract.

 However, we can distinguish between two types of contractual Ergs. The first, called {\em free Ergs}, are the ones that could change their contracts easily and have no restrictions on the outputs or the other inputs of a spending transaction. The second type is {\em bounded Ergs}, whose contracts require the spending transaction to have input and output boxes with specific properties.

 For example, if a box $A$ is protected by just a public key~(so providing a signature against a spending transaction is enough in order to destroy the box), the public key owner can spend $A$ and transfer the Ergs to any arbitrary output box. Thus, the Ergs within $A$ are free.
% to change the contract.
In contrast, imagine a box $B$ protected by a combination of a public key and a condition that demands the spending transaction to create an output box with the same amount of Ergs as in $B$ and whose guarding script has the hash \texttt{rBMUEMuPQUx3GzgFZSsHmLMBouLabNZ4HcERm4N} (in Base58 encoding). In this case, the Ergs in $B$ are bounded Ergs.

 Similarly, we can define free and bounded tokens. An Ergo contract can have several hybrids such as bounded Ergs and free tokens or both bounded under one public key and free under another.

\subsection{Preliminaries For Ergo Contracts}

  While in Bitcoin, a transaction output is protected by a program in a stack-based language named {\em Script}, in Ergo a box is protected by a logic formula which combines predicates over a context with cryptographic statements provable via zero-knowledge protocols using AND, OR, and $k$-out-of-$n$ connectives. The formula is represented as a typed direct
 acyclic graph, whose serialized form is written in a box. To destroy a box, a spending transaction needs to provide arguments (which include zero-knowledge proofs) satisfying the formula.

 However, in most cases, a developer is unlikely to develop contracts in terms of graphs. Instead, he would like to use a high-level language such as ErgoScript, which we provide with the reference client.

 Writing scripts in ErgoScript is easy. As an
 example, for a one-out-of-two signature, the protecting script would be ${pk_1 \|pk_2}$, which means ``prove knowledge of
 a secret key corresponding to the public key $pk_1$ or knowledge of a secret key corresponding to public key $pk_2$''. We have
 two separate documents for help in developing contracts with ErgoScript: the ``ErgoScript Tutorial''~\cite{ergoTutorial}
 and the ``Advanced ErgoScript Tutorial''~\cite{ergoAdvTutorial}. Thus, we do not get into the details of developing contracts with ErgoScript. Rather, we provide a couple of motivating examples in the following sections.

Two more features of Ergo shaping contracting possibilities are:

 \begin{itemize}
    \item {\em Data Inputs: }
 To be used in a transaction, a box need not be destroyed but can instead be read-only. In the latter case, we refer to the box as being part of the {\em data input} of the transaction. Thus, a transaction gets two box sets as its arguments, the inputs and
 data inputs, and produces one box set named {\em outputs}. Data inputs are useful for oracle applications and interacting contracts.

    \item {\em Custom Tokens: }
 A transaction can carry many tokens as long as the estimated complexity for processing them does not exceed a limit, a parameter that is set by miner voting. A transaction can also issue a single token with a unique identifier which is equal to the identifier of a first~(spendable) input box of the transaction. The identifier is unique assuming the collision resistance of an underlying hash function.
 The amount of the tokens issued could be any number within the range $[1, 9223372036854775807]$. The weak preservation rule is followed for tokens, which requires that the total amount of any token in a transaction's outputs should be no more
 than the total amount of that token in the transaction's inputs~(i.e., some amount of token could be burnt). In contrast, the strong reservation rule is followed for Ergs, which requires that the total amount of Ergs in the inputs and outputs must be the same.
 \end{itemize}

\subsection{Contract Examples}
\label{sec:examples}

 In this section, we provide some examples which demonstrate the superiority of Ergo contracts compared to Bitcoin's. The examples include betting on oracle-provided data, non-interactive mixing, atomic swaps, complementary currency, and an initial coin offering implemented on top of the Ergo blockchain.

 \subsubsection{An Oracle Example}
 \label{sec:platform}

 Equipped with custom tokens and data inputs, we can develop a simple oracle example which also shows some design patterns that we discovered while playing with Ergo contracts. Assume that Alice and Bob want to bet on tomorrow's weather by putting money into a box that becomes spendable by Alice if tomorrow's temperature is more than 15 degrees, and spendable by Bob otherwise. To deliver the temperature into the blockchain, a trusted oracle is needed.

 In contrast to Ethereum with its long-lived accounts, where a trusted oracle's identifier is usually known in advance, delivering data with one-time boxes is more tricky. For starters, a box protected by the oracle's key cannot be trusted, as anyone can create such a box. It is possible to include signed data into a box and check the oracle's signature in the contract (we have such an example), but this is quite involved. Instead, a solution with custom
 tokens is very simple.

 Firstly, a token identifying the oracle should be issued. In the simplest case, the amount of this token could be one. We call such a token {\em a singleton token}. The oracle creates a box containing this token along with its data (i.e., the temperature) in register $R_4$ and the UNIX epoch time in register $R_5$.
 In order to update the temperature, the oracle destroys this box and creates a new one with the updated temperature.

 Assume that Alice and Bob know the oracle's token identifier in advance. With this knowledge, they can jointly create a box with a contract that requires first (read-only) data input to contain the oracle's token. The contract extracts the temperature and time from the data input
 and decides who gets the payout. The code is as simple as following:

 \begin{algorithm}[H]
    \caption{Oracle Contract Example}
    \label{alg:oracle}
    \begin{algorithmic}[1]
        \State val dataInput = CONTEXT.dataInputs(0)
        \State val inReg = dataInput.R4[Long].get
        \State val inTime = dataInput.R5[Long].get
        \State val inToken = dataInput.tokens(0).\_1 == tokenId
        \State val okContractLogic = (inTime $>$ 1556089223) \&\&
        \State\hspace{\algorithmicindent}\hspace{\algorithmicindent} ((inReg $>$ 15L \&\& pkA) $||$ (inReg $\le$ 15L \&\& pkB))
        \State inToken \&\& okContractLogic
    \end{algorithmic}
 \end{algorithm}

 This contract shows how a singleton token could be used for authentication. As a possible alternative, the oracle
 can put the time and temperature into a box along with a signature on this data. However, this requires signature verification, which is more complex and expensive compared to
 the singleton token approach. Also, the contract shows how read-only data inputs could be useful for contracts which need to access data stored in some other box in the state. Without data inputs, an oracle must issue one spendable box for each
 pair of Alice and Bob. With data inputs, the oracle issues only a single box.

\subsubsection{A Mixing Example}
 \label{sec:platform}

 Privacy is important for a digital currency but implementing it can be costly or require a trusted setup. Thus, it is desirable to find a cheaper way for coin mixing. As a first step towards that, we offer a non-interactive mixing protocol between two users Alice and Bob that works as follows:
 \begin{enumerate}
    \item{} Alice creates a box which demands the spending transaction to satisfy certain conditions. After that, Alice only listens to the blockchain; no interaction with Bob is needed.
    \item{} Bob creates a transaction spending Alice's box along with one of his own to generate two outputs having identical scripts but different data. Each of Alice and Bob may spend only one of the two outputs but an observer decide which output belongs to whom because they look indistinguishable.
 \end{enumerate}

 For simplicity, we do not consider fee in the example. The idea of mixing is similar to non-interactive Diffie-Hellman key exchange. First, Alice generates a secret value $x$~(a huge number) and publishes the corresponding public value $gX = g^x$. She requires Bob to generate a secret number $y$, and to include into each output two
 values $c_1$, $c_2$, where one value is equal to $g^y$ and the other is equal to $g^{xy}$. Bob uses a random coin to choose meanings for $\{c_1, c_2\}$. Without access to the secrets, an external observer cannot guess with probability better than  $\frac{1}{2}$ whether $c_1$ is equal to $g^y$ or to $g^{xy}$. This is assuming that the cryptographic primitive we use has a certain property, that the Decision Diffie-Hellman (DDH) problem is hard. To destroy an output box, a proof should be given that either $y$ is known such that $c_2 = g^y$, or $x$ is known such that $c_2 = c_1^x$.
 The contract of Alice's box checks that $c_1$ and $c_2$ are well-formed. The code snippets for Alice's coin and the mixing transaction's output are provided in Algorithms \ref{alg:alice} and \ref{alg:mixing-out} respectively. Since ErgoScript currently doesn't have support for proving knowledge of some $x$ such that $c_2 = {c_1}^x$ for arbitrary $c_1$,  we will prove a slightly longer statement that is supported, namely, proving knowledge of $x$ such that $gX = g^x$ and $c_2 = {c_1}^x$. This is called proveDHTuple.

 \begin{algorithm}[H]
    \caption{Alice's Input Script}
    \label{alg:alice}
    \begin{algorithmic}[1]
        \State val c1 = OUTPUTS(0).R4[GroupElement].get
        \State val c2 = OUTPUTS(0).R5[GroupElement].get
        \State
        \State OUTPUTS.size == 2 \&\&
        \State OUTPUTS(0).value == SELF.value \&\&
        \State OUTPUTS(1).value == SELF.value \&\&
        \State blake2b256(OUTPUTS(0).propositionBytes) == fullMixScriptHash \&\&
        \State blake2b256(OUTPUTS(1).propositionBytes) == fullMixScriptHash \&\&
        \State OUTPUTS(1).R4[GroupElement].get == c2 \&\&
        \State OUTPUTS(1).R5[GroupElement].get == c1 \&\& \{
        \State\hspace{\algorithmicindent}  proveDHTuple(g, gX, c1, c2) $||$
        \State\hspace{\algorithmicindent}  proveDHTuple(g, gX, c2, c1)
        \State \}
    \end{algorithmic}
 \end{algorithm}

 \begin{algorithm}[H]
    \caption{Mixing Transaction Output Script}
    \label{alg:mixing-out}
    \begin{algorithmic}[1]
        \State val c1 = SELF.R4[GroupElement].get
        \State val c2 = SELF.R5[GroupElement].get
        \State proveDlog(c2) $||$            // either c2 is $g^y$
        \State proveDHTuple(g, c1, gX, c2) // or c2 is $u^y = g^{xy}$
    \end{algorithmic}
 \end{algorithm}

 We refer the reader to \cite{ergoAdvTutorial} for a proof of indistinguishability of the outputs and details on why Alice and Bob can spend only their respective coins.

\subsubsection{More Examples}

 In this section, we briefly shed light on a few more examples along with links to the documents providing the details and code.

\paragraph{Atomic Swap}
Cross-chain atomic swap between Ergo and any blockchain that supports payment to either SHA-256 or Blake2b-256 hash preimages and time-locks can be done in a similar way to that proposed for Bitcoin~\cite{Nol13}. An Ergo alternative implementation is provided in~\cite{ergoTutorial}. As Ergo also has custom tokens, atomic exchange on the single Ergo blockchain (Erg-to-token or token-to-token) is also possible. An implementation for this can also be found in~\cite{ergoTutorial}.

\paragraph{Crowdfunding}

 We consider the simplest crowdfunding scenario. In this example, a crowdfunding project with a known public key is considered successful if it can collect unspent outputs with a total value not less than a certain amount before a certain height. A project backer creates an output box protected by the following statement: the box can be spent
 if the spending transaction has the first output box protected by the project's key and amount no less than the target amount.
 Then the project can collect (in a single transaction) the biggest backer output boxes with a total value not less than the target amount~(it is possible to collect up to ~22,000 outputs, which is
 enough even for a big crowdfunding campaign). For the remaining outputs, it is possible to construct follow-up transactions. The code can be found in~\cite{ergoTutorial}.

\paragraph{The Local Exchange Trading System}

 Here we briefly demonstrate a Local Exchange Trading System (LETS) in Ergo. In such a system, a member of a community may issue community currency via personal debt. For example, if Alice with zero balance is buying something for $5$
 community tokens from Bob, whose balance is zero as well, her balance after the trade would be $-5$ tokens, and
 Bob's balance would be $5$ tokens. Then Bob can buy something using his $5$ tokens, for example, from Carol.
 Usually, in such systems, there is a limit on negative balances (to avoid free-riding).

 Since a digital community is vulnerable to Sybil attacks~\cite{sybilDef}, some mechanism is needed to prevent such attacks where Sybil nodes create debts.
 The simplest solution is to use a committee of trusted managers that approve new members of the community. A trust-less but more complex solution is to use security deposits made in Ergs. For simplicity, we consider the approach with the committee here.

 This example contains two interacting contracts. A {\em management contract} maintains a list of community members, and a new member can be added if some management condition is satisfied  (for example, a threshold
 signature is provided). A new member is associated with a box containing a token that identifies the member. This box, which contains the {\em member contract}, is protected by a special exchange script that requires the spending transaction to do a fair exchange.
 We skip the corresponding code, which can be found in a separate article~\cite{letsTutorial}.

 What this contract shows, in contrast to the previous example, is that instead of storing the members list, only a short digest of an authenticated AVL+ tree can be included in the box. This allows a reduction in storage requirements for the state. A transaction doing lookup or modification of the member list should provide a proof for AVL+ tree lookup or modification operations. Thus, saving space in the state storage leads to bigger transactions, but this scalability problem is easier to solve.

\paragraph{Initial Coin Offering}

 We discuss an Initial Coin Offering (ICO) example that shows how multi-stage contracts can be created in Ergo. Like most ICOs, our example has three stages. In the first stage, the project raises money in Ergs. In the second stage, the project issues a new token, whose amount equals the number of nanoErgs raised in the first stage. In the third stage, the investors can withdraw issued tokens.

 Note that the first and third stages have many transactions on
 the blockchain, while a single transaction is enough for the second stage. Similar to the previous example, the ICO contract uses an AVL+ tree to store the list of (investor, amount) pairs. The complete code is available at~\cite{icoTutorial}.

\paragraph{More Examples}

 We have even more examples of Ergo applications in \cite{ergoTutorial, ergoAdvTutorial}. These examples include time-controlled emission, cold wallets contracts, rock-paper-scissors game, and many others.


\subsection{Pulsar Accelerations}

\textbf{key}: \texttt{/pulsar}

\subsubsection{Datasets}

\begin{center}
\begin{table}[H]
\begin{tabular}{ | c | c | c | c | }
    \hline
    Variable & Dataset Name & Supplementary Datasets &  attributes \\
    \hline\hline
    Radial distance & \texttt{r\(^*\)} & & \texttt{unit} \\
    \hline
    Spin period & \texttt{P\(^*\)} & \texttt{\(\Delta\)P} & \texttt{unit}\\
    \hline
    Spin period derivative & \texttt{Pdot\_meas\(^*\)} &
    \texttt{\(\Delta\)Pdot\_meas\(^*\)} & \texttt{unit} \\
    \hline
    Orbital period & \texttt{Pb\(^*\)} & \texttt{\(\Delta\)Pb} & \texttt{unit}\\
    \hline
    Orbital period derivative & \texttt{Pbdot\_meas\(^*\)} &
    \texttt{\(\Delta\)Pbdot\_meas\(^*\)} & \texttt{unit} \\
    \hline
    Dispersion Measure & \texttt{DM} & \texttt{\(\Delta\)DM} & \texttt{unit} \\
    \hline
    Pulsar identifier & \texttt{id} & & \\
    \hline
\end{tabular}
\caption*{
    Pulsars can be fit on the timing solutions of both the isolated
    pulsar spin (P, Pdot\_meas) and the binary systems orbit (Pb, Pbdot).
    The period, derivative and corresponding errors are required for either.
    Optionally, the dispersion measure (DM) can be used to provide a better
    acceleration constraint, where available.
}
\end{table}
\end{center}

\subsubsection{Attributes}

\begin{center}
\begin{table}[H]
\begin{tabular}{ | c | c | }
    \hline
    Attribute & Description \\
    \hline\hline
    \texttt{source} & Literature source(s) of data \\
    \hline
    \texttt{m} & Mean stellar mass of tracer stars [\(M_\odot\)] \\
    \hline
\end{tabular}
\end{table}
\end{center}


\hypertarget{premium-allocation-and-default-priority-rules}{%
\section{Premium Allocation and Default Priority
Rules}\label{premium-allocation-and-default-priority-rules}}

Nov 25, 2018

Derived from MM\_2RM

\hypertarget{three-important-differentials-homogeneous-case}{%
\subsection{Three important differentials (homogeneous
case)}\label{three-important-differentials-homogeneous-case}}

From Tasche and other references. Let \(X_u=X=u_1X_1 + u_2X_2\) be a
homogeneous portfolio.

The deriviative of the survival function \(S_u(t)=\text{Pr}(X_u>t)\) is
\[
\nabla_u S(t) = \text{E}[X_i 1_{\{X=t\}}] = \text{E}[X_i \mid X=t] f_u(t)
\] where \(f_u\) is the sensity of \(X_u\).

The deriviative of value at risk \(Q(u)\) for \(X_u\) at a fixed
threshold \(p\) is \[
\nabla_u Q(u) = E[X_i\mid \sum u_ix_i = Q(u,p)]
\]

The deriviative of tail value at risk \(T\) is \[
\nabla_u T(u) = E[X_i\mid \sum u_ix_i>Q(u,p)]
\]

\hypertarget{method-a}{%
\subsection{Method A}\label{method-a}}

For M\textbf{A}jor :-)

Homogeneous portfolio \(X_u=X=u_1X_1 + u_2X_2\).

Regulatory capital measure \(\alpha\), typically VaR or TVaR.
\textbf{Assume \(\alpha=\)TVaR} at a threshold \(p\) close to 1. Thus
\(\alpha(X_u) = \text{E}[X\mid X > F_u^{-1}(p)]\). Total assets
\(\alpha\) have a natural co-measure allocation given by
\(\alpha_i(X_u)= \text{E}[u_iX_i \mid X_u > F_u^{-1}(p)] = u_i \partial T/\partial u_i\).

Distortion \(g\) determines market pricing for risk transfer, via
\(E_g(X) = \int g(S_X(t))dt\).

Price is determined by using \(g\) to price
\(X\wedge \alpha(X):=\text{min}(X, \alpha(X))\).

The resulting pricing functional \(\pi\) can be written in several ways.
Let \(F_u^{-1}\) be the quantile function (i.e.~value at risk) of
\(X_u\). Then \[
\begin{align}
\pi(X_u) &= \int_0^{\alpha(X)} g(S_u(t))dt \\
&= \text{E}[(X_u\wedge \alpha(X_u)) g'(S_u(X)] \\
&= \int_0^1 (F_u^{-1}(p)\wedge \alpha(X_u)) g'(1-p)dp. \\
\end{align}
\]

We both agree that, subject to certain continuity and differentiability
assumptions, \[
\begin{align}
\frac{\partial\pi}{\partial u_i}(u) &= \text{E}\left[\left(X_i 1_{\{X\le \alpha\}} + E[X_i\mid X >  F_u^{-1}(p)]1_{\{X > \alpha\}}\right) g'(S_u(X_u) \right] \\
&= \text{E}[ X_i g'(S(X)) \mid X \le \alpha](1-g(S(\alpha)))+ \text{E}[X_i \mid X > F_u^{-1}(p)]g(S(\alpha)).\\
\end{align}
\] The premium for line \(i\) is \(u_i\partial\pi / \partial u_i\) in
the usual way. Euler implies the premium ``adds-up'' because the
portfolio is homogeneous.

The result can be seen in a couple of ways. From the first defintion of
\(\pi\) as an \(\int_0^\alpha\) and the three differentials noted above
we get \[
\begin{align}
\nabla_u\pi &= \int_0^{\alpha(X)} \nabla_u(g(S_u(t)))dt + g(S_u(\alpha))\nabla_u\alpha(u) \\
&=\int_0^{\alpha(X)} g'(S_u(t))\text{E}[X_i 1_{\{X=t\}}] dt + g(S_u(\alpha))E[X_i\mid X> F_u^{-1}(p) ] \\
&=\int_0^{\alpha(X)} g'(S_u(t))\text{E}[X_i \mid X=t] f_u(t) dt + g(S_u(\alpha))E[X_i\mid X> F_u^{-1}(p) ] \\
&=\text{E}\left[\left(X_i 1_{\{X\le \alpha\}} + E[X_i\mid X> F_u^{-1}(p)]1_{\{X > \alpha\}}\right) g'(S_u(X)) \right]
\end{align}
\] where the last line follows from the conditional expectation (tower
property) formula. Notice that the default expectation is take wrt
\(X>F_u^{-1}(p)\) whereas the outside integral is split at tvar.

Alternatively using the third definition of \(\pi\) \[
\begin{align}
\nabla_u\pi
&= \nabla_u \int_0^1 (F_u^{-1}(p)\wedge \alpha(u)) g'(1-p)dp  \\
&= \int_0^1 \left(\nabla_u F_u^{-1}(p) 1_{\{X_u\le \alpha\}} +
            \nabla_u \alpha(u) 1_{\{X_u > \alpha\}}\right) g'(1-p)dp  \\
&= \int_0^{F(\alpha)} \text{E}[X_i \mid X=F_u^{-1}(p) ] g'(1-p)dp + \text{E}[X_i \mid X> F_u^{-1}(p)] g(S(\alpha)) \\
&= \int_0^{\alpha} \text{E}[X_i \mid X=t ] g'(S(t))f(t)dt + \text{E}[X_i \mid X> F_u^{-1}(p)] g(S(\alpha)) \\
&= \text{E}\left[ \text{E}[X_i \mid X ]1_{\{X\le\alpha\}} g'(S(X_u)) \right]
+ \text{E}[X_i \mid X> F_u^{-1}(p)] g(S(\alpha)) \\
&= \text{E}\left[ X_i 1_{\{X\le\alpha\}} g'(S(X_u)) \right]
+ \text{E}[X_i \mid X> F_u^{-1}(p)] g(S(\alpha)) \\
\end{align}
\] It is important that \(g'(1-p)\) \emph{does not depend on \(u\)}. The
dependence on \(u\) has been subsumed into the re-ordering defined by
\(F_u^{-1}\). The fourth line follows from the third via substituting
\(F(t)=p\).

\hypertarget{properties-of-method-a}{%
\subsubsection{Properties of Method A}\label{properties-of-method-a}}

\begin{itemize}
\tightlist
\item
  \textbf{Assumes and relies critically on homogeneity}
\item
  Result is independent of the default rule
\item
  Produces core of fuzzy game and only measure consistent with
  performance management. (In fuzzy game approach there is an assumption
  that the underlying risks can be fractionally quota shared, not that
  they are homogeneous themselves.)
\end{itemize}

\hypertarget{method-b}{%
\subsection{Method B}\label{method-b}}

Portfolio \(X(u)\) that may or may not be homogeneous. An inhomogenous
example is \(X(u)=X_1(u_1) + X_2(u_2)\) where \(X_i(u_i)\) is a compound
Poisson distribution with expected claim count \(u_i\).

Regulatory capital \(\alpha\) determined by TVaR. Same distortion \(g\)
determines cost of risk transfer.

The insurer sells the residual value of the risk when supported by
assets of \(a\) to the capital markets for a premium \(P(a)\). The sale
is structured by tranche, so the premium is an integral of the premium
density. For a layer attaching at \(x\) (i.e.~a layer \(x\) to \(x+dx\))
the expected loss cost is \(S(x)dx\). As is well known, the expected
losses upto total capital \(a\) are given by \[
\int_0^a S(x)dx.
\] The distortion function \(g\) prices the layer at \(x\) as
\(g(S(x))\). Therefore the total premium is \[
P(a) = \int_0^a g(S(x))dx.
\] The premium density is therefore \[
P'(x) = \frac{dP}{da} = g(S(x)).
\]

The insurer now faces the problem of allocating the premium
\(P(\alpha(X))\) back to lines 1 and 2. Use a co-measure approach---this
is exavtly what our spreadsheet did in the CAS sessions! We have a
stable world, with \(u_1,u_2\) are fixed. The pricing distortion
function \(g\) combined with fixed \(X\) gives a probability distortion
\(g'(S(X))\), i.e.~and \(E_{\Bbb{Q}}[X] := E[Xg'(S(X))]\). Standard
finance theory says that in this situation, with a linear pricing rule,
we price any payoff \(Y\) by \$
E\_\{\Bbb{Q}\}{[}Y{]}=E{[}Yg'(S(X)){]}\$.

We have to specify the payoff to line \(i\) when the insurer only has
assets \(a\). Consider two possibilities.

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\tightlist
\item
  The two lines have equal priority in event of default. The payment to
  line \(i\) is \[
  X_i(a):=
  \begin{cases}
  X_i & X \le a \\
  X_i\frac{a}{X} & X > a \\
  \end{cases}
  = X_i \frac{X\wedge a}{X}.
  \]
\item
  Line 2 has lower priority than line 1. In this case the payout to line
  1 is \(X_1\wedge a\) and the payout to line 2 is \[
  X_2(a):=
  \begin{cases}
  X_2    & X \le a \\
  a-X_1  & X_1 \le a < X  \\
  0      & X_1 > a.
  \end{cases}
  \]
\end{enumerate}

In the case of equal priority the expected recovery to line \(i\) when
the insurer has assets \(a\) is \[
\begin{align}
\text{E}[X_i(a)] &= \text{E}[X_i \mid X \le a ]F(a) + a \text{E}\left[\frac{X_i}{X} \mid X > a \right] S(a) \\
&= \text{E}\left[ X_i\frac{X\wedge a}{X} \right].
\end{align}
\] From the second expression it is obvious this is an additive
allocation---in all cases, not just when \(X\) is a homogeneous family.

Finance theory now tells us the price of the contingent payout
\(X_i(\alpha)\) is \[
\begin{align}
P_i(u)=P_i(\alpha(X_u) &= \text{E}_{\Bbb{Q}}\left[  X_i\frac{X\wedge a}{X} \right] \\
&= \text{E}\left[  X_i\frac{X\wedge a}{X} g'(S(X)) \right] \\
&= \text{E}\left[ \text{E}\left[  X_i\frac{X\wedge a}{X} g'(S(X)) \mid X \right] \right] \\
&= \text{E}\left[ \text{E}\left[\frac{X_i}{X}\mid X \right] (X\wedge a) g'(S(X)) \right] \\
&= \text{E}\left[ \text{E}\left[ X_i \mid X \le \alpha \right] g'(S(X)) \right] (1-g(S(\alpha)))
    + a\text{E}\left[ \text{E}\left[\frac{X_i}{X}\mid X>\alpha \right] g'(S(X)) \right] g(S(\alpha)) \\
&= \text{E}\left[ X_i 1_{\{X \le \alpha \}} g'(S(X)) \right]
    + a\text{E}\left[ \frac{X_i}{X} g'(S(X)) 1_{\{ X>\alpha\}} \right] \\
&= \text{E}_{\Bbb{Q}}\left[ X_i 1_{\{X \le \alpha \}} + a \frac{X_i}{X} 1_{\{ X>\alpha\}} \right] \\
\end{align}
\]

The price component when the insurer remains solvent is the same as for
Method A. However the value of the payment made in the event of
insolvency is different---and depends on the explicit default
assumption: \[
\begin{align}
\text{Method A: } & \text{E}[X_i | X > \alpha]g(S(\alpha) \\
\text{Method B: } & a\text{E}\left[ \frac{X_i}{X} g'(S(X)) \mid X>\alpha \right] g(S(\alpha))
= a\text{E}\left[ \text{E}[\frac{X_i}{X} \mid X] g'(S(X)) 1_{\{ X>\alpha\}} \right] \\
\end{align}
\]

In method A the expectation is the allocation of total assets \(\alpha\)
to line \(i\).

Similar calculations can be performed for the case Line 2 has lower
priority.

\hypertarget{properties-of-method-b}{%
\subsubsection{Properties of Method B}\label{properties-of-method-b}}

\begin{itemize}
\tightlist
\item
  Does \textbf{not} assume or rely on homogeneity
\item
  Result dependents particular the default rule
\end{itemize}


%
% CMPT 300: Operating Systems I - A Course Overview
% Section: Virtual Memory
%
% Author: Jeffrey Leung
%

\section{Virtual Memory}
	\label{sec:virtual-memory}
\begin{easylist}

& \textbf{Virtual memory:} Abstraction of memory management where logical memory can be conceptually larger than the physical address space
	&& Only part of a program is in memory at any given time

& \textbf{Demand paging:} Making pages available in virtual memory only as needed
	&& Decreases I/O requirements and waiting time, and increases number of potential concurrent processes
	&& Indicated by valid-invalid bit in page table (if invalid, the memory access is either illegal or not yet in memory)

\end{easylist}
\subsection{Page Faults}
	\label{subsec:virtual-memory:page-faults}
\begin{easylist}

& \textbf{Page fault:} Legal memory access of a page which is not currently in memory which triggers retrieval
	&& \textbf{Major page fault:} Page is brought from disk
	&& \textbf{Minor page fault:} Page table is updated (e.g. linking shared pages)
	&& If no free pages are available, a page will be removed from memory to make room
	&& To preserve atomicity of instructions which modify data, previous register values are saved and hardware accesses both ends of the data before execution to trigger page faults
	&& Effective Access Time:
	\end{easylist}
	\begin{align*}
		\textrm{Let } p &= \textrm{ page fault rate, } 0 \leq p \leq 1 \\
		& \textrm{ where 0 is no faults, 1 is every reference is a fault} \\
		\textrm{Let } t_m &= \textrm{ memory access time} \\
		\textrm{Let } t_p &= \textrm{ page fault time} \\
		& \textrm{(including interrupt, page read, restart)} \\
		\textrm{Effective access time }
		&= p \times t_p + (1 - p) \times t_m \\
	\end{align*}
	\begin{easylist}

		&&& Example:
		\end{easylist}
		\begin{align*}
			p &= 0.001 \textrm{ 1 fault per 1,000 memory accesses} \\
			t_m &= 200 \textrm{ ns} \\
			t_p &= 8 \textrm{ ms} = 8,000,000 \textrm{ ns}\\
			\textrm{Effective access time }
			&= p \times t_p + (1 - p) \times t_m \\
			&= 0.001 \times 8,000,000 + (1 - 0.001) \times 200 \\
			&= 8,000 + 199.8 \\
			&= 8,200 \textrm{ ns} \\
			\textrm{Slowdown } &= \frac{8200 \textrm{ ns}}{200 \textrm{ ns}} = 40 \textrm{ times slower}
		\end{align*}
		\begin{easylist}

	&& Process:
		&&& Send a trap to the OS
		&&& Save the user registers and process states
		&&& Determine that the interrupt was a page fault
		&&& Check legality of the page access and determine the location of the page
		&&& Issue a read from the disk to a free frame
		&&& Wait until the read request is serviced, with seek and/or latency time
		&&& Transfer the page to a free frame
		&&& While waiting, allocate the CPU to some other process
		&&& Receive a completion interrupt from the disk I/O subsystem
		&&& Save the registers and process state for the other process
		&&& Determine that the interrupt was from the disk
		&&& Correct the page tables to show page is now in memory
		&&& Wait for the CPU to be allocated to this process again
		&&& Restore the user registers, process state, and new page table
		&&& Resume the interrupted instruction

& \textbf{Copy-on-Write (COW):} Method of quickly/efficiently creating a child process by sharing the pages of the parent process in memory and copying the data only when a shared page is modified

& \textbf{Pre-paging:} Bringing pages into memory before they are referenced to decrease page faults
	&& May waste memory and I/O if the page is not used

\end{easylist}
\subsection{Page Replacement}
	\label{subsec:virtual-memory:page-replacement}
\begin{easylist}

& \textbf{Page replacement algorithm:} Method of selecting a victim page to be removed from memory which is designed to minimize fault rate
	&& Dirty/modified bit in page table entries to save swap-out overhead if the victim page was not modified
	&& \textbf{I/O interlock:} Page currently used for I/O is locked in memory and cannot be replaced during a fault

& \textbf{First-In-First-Out (FIFO) page replacement algorithm:} Removing from memory the oldest page upon a fault
	&& Could consistently remove a heavily-used page
	&& \textbf{Bélády's anomaly:} Phenomenon in the FIFO page replacement algorithm where increasing available frames may potentially result in greater page faults

& \textbf{Least Recently Used (LRU) page replacement algorithm:} Removing from memory the page which has not been used for the longest period, upon a page fault
	&& Counter tracking: Using a data field to store CPU clock of the last memory access and searching for the oldest page
		&&& Search is time-consuming, many memory writes, potential clock overflow, requires hardware
	&& Stack tracking: Using a stack created from a doubly-linked list for which each page access moves the page to the top
		&&& Memory reference updating is expensive, requires hardware
		&&& No search is required

& \textbf{Second-chance/clock replacement:} Using a set of reference bits which are set when a page is referenced and reset when a page is replaced, and removing a page which was not used since the last replacement

& \textbf{Least Frequently Used (LRU) page replacement algorithm:} Removing from memory the page which has been used the least
	&& Removes pages which are not used often
	&& Early heavily-used pages will stay in memory
& \textbf{Most Frequently Used (MRU) page replacement algorithm:} Removing from memory the page which has been used the most
	&& Pages with smaller counts are estimated to be newer and kept
	&& Heavily-used pages may be removed more frequently

& \textbf{Optimal page replacement algorithm:} Removing from memory the page which will not be used for the longest period of time, upon a fault
	&& Only possible in theory or when analyzing a past set of page accesses
	&& Used to benchmark existing algorithms

\end{easylist}
\subsection{Frame Allocation}
	\label{subsec:virtual-memory:frame-allocation}
\begin{easylist}

& \textbf{Equal allocation:}

& \textbf{Proportional allocation:} Allocating frames per process relative to the size of the process
	&& Formula:
	\end{easylist}
	\begin{align*}
		\textrm{Let } m &= \textrm{ total number of frames} \\
		\textrm{Let } p_i & \textrm{ be a given process} \\
		\textrm{Let } s_i &= \textrm{ size of process } p_i \\
		\textrm{Page allocation } a_i \textrm{ for } p_i
		&= \frac{s_i}{\sum s_i} \times m
	\end{align*}
	\begin{easylist}

		&&& Example:
		\end{easylist}
		\begin{align*}
			m &= 64 \textrm{ frames} \\
			s_1 \textrm{ for process } p_1 &= 10 \\
			s_2 \textrm{ for process } p_2 &= 127 \\
			\textrm{Page allocation } a_1
			&= \frac{s_1}{\sum s_1} \times m \\
			&= \frac{10}{10+127} \times 64 \\
			&\approx 5
		\end{align*}
		\begin{easylist}

& \textbf{Priority allocation:} Allocating frames per process relative to the priority of the process

& \textbf{Global replacement:}
& \textbf{Local replacement:}

& \textbf{Locality model:} Keeping in memory the pages necessary for the current segment of code

& \textbf{Working set:}
	&& Managed with an interval timer and set of reference bits (per page in memory), which is set when a page is referenced

& \textbf{Thrashing:} Situation where a process is starved of necessary frame allocations and must constantly swap pages

\end{easylist}
\subsection{Kernel Memory Allocation}
	\label{subsec:virtual-memory:kernel-memory-allocation}
\begin{easylist}

& \textbf{Buddy system:} Allocating memory from fixed-size contiguous segments with size to the power of 2
	&& May have up to 50\% internal fragmentation
& \textbf{Slab allocator:} Allocating memory from precreated spaces for kernel data structures
	&& \textbf{Cache:} Paged instantiation space in memory for an object
	&& \textbf{Slab:} Contiguous memory which contains multiple caches
	&& Memory allocation is fast and has no fragmentation

& \textbf{Memory mapping:} Mapping a file to a memory address space so modifications have the behaviour of ordinary memory accesses

\end{easylist}
\clearpage


\subsection{Glossary of Q operators}

Table~\ref{tbl_qops} lists Q operators referenced in this paper
\begin{table}
\centering
\begin{tabular}{|l|l|l|l|l|} \hline \hline
  {\bf Operator} & {\bf Explanation} \\ \hline \hline
  const & creates a constant vector \\ \hline
  vvadd & \(v_1 \leftarrow v_2 + v_3\) \\ \hline
  vssub & \(v_1 \leftarrow v_2 - s_1\) \\ \hline
  sqr & \(v_1 \leftarrow v_2^2\) \\ \hline
  mink & Section~\ref{reducers} \\ \hline
  \(n_C\) & size of chunk in which vectors get evaluated \\ \hline
  \hline
\end{tabular}
\caption{Q operators (selected list)}
\label{tbl_qops}
\end{table}