\chapter{ConFrm}
\label{chapter:ConFrm}

ConFrm is a framework for proving confidentiality of storage systems. It contains a new confidentiality definition as well as structures such as layer templates, execution semantics among other things to implement file systems with confidentiality proofs.

\section{Specification: Relatively Deterministic Noninterference}
Figure \ref{fig:NI_Matching_Paths} shows that traditional noninterference definition leads to leakage of confidential data when probability of observing a return value is not uniformly distributed. To address this challenge, This thesis introduces a new confidentiality definition that we call \emph{Relatively Deterministic NonInterference} (RDNI) that takes return value frequencies into account. In the following section we will progressively build this new definition.

\subsection{Basic Definition}
Nondeterministic noninterference can be interpreted as "matching" of executions from equivalent states to equivalent states for some chosen relation between two states
%
\footnote{In reality, nondeterministic noninterference definition does not require relation to be an equivalence. We use "equivalent states" instead of "related states" to make it clear that it is this relation we are referring to when we say "equivalent states" in other chapters.}.
%
More specifically, for each execution from a state, a "matching execution" from a equivalent state is an execution with the same return value where resulting states are equivalent as well. Traditional nondeterministic noninterference definition allows multiple executions to be matched with a single execution. For example, in figure \ref{fig:NI_Matching_Paths}, same execution is matched with two other executions. This flexibility allows matching two set of executions from equivalent states to equivalent states as long as their set of possible return values are the same, but ignores the relative frequencies of the return values.

One way to ensure that observed return value frequencies are the same is, for each possible return value, requiring that the number of executions that returns it being the same from the equivalent states. This can be achieved by enforcing a 1-to-1 matching between executions from the equivalent states. If an execution can be matched with exactly one execution from an equivalent state, then we can conclude that the number of executions that lead to the same return value from the equivalent states are equal.

Since the nondeterminism is what leads to the multiple possible executions, each execution should be the result of some specific sequence of nondeterministic events. In other words, each sequence of nondeterministic events uniquely identifies an execution, that is, executions are deterministic relative to a sequence of nondeterministic events. Therefore, for a particular sequence of nondeterministic events, there can be at most one execution from each equivalent state. We can enforce a 1-to-1 matching by requiring, for each sequence of nondeterministic events, there should be exactly one matching execution from a equivalent state.

This requirement is the core idea behind the RDNI definition, and indeed is sufficient to address our challenge. Figure \ref{fig:RDNI_Matching_Paths} visualizes how the example \ref{fig:Frequency_Leaking_Program} does not satisfy the new definition, although it satisfies the conventional noninterference. There is no matching execution from the equivalent state if the first generated random bit is 1. There is exactly one execution for from each state when generated bit is 1 and they have different return values.

\begin{figure}[H]
    \centering
    \includegraphics[scale=0.5]{templates/figures/matching-paths-rdni.png}
    \caption{There is no corresponding execution for the red and black executions.}
    \label{fig:RDNI_Matching_Paths}
\end{figure}

RDNI formalizes the above notion. RDNI uses an execution relation that takes a sequence of nondeterministic events, which we call an \emph{oracle}, and refers to it whenever it needs to make a nondeterministic choice (e.g., crashing or successfully executing). One important requirement is that the oracle must capture all the nondeterminism in the system. If all possible nondeterminism in the system is captured by the oracle, it is possible to reason about specific sequence of nondeterministic events by reasoning about the oracle itself. This requirement is enforced by ConFrm through the construction of a layer. Figure \ref{fig:RDNI_no_recovery} shows the formalization of this approach.

%% I took out users from here but will add at the end.
\begin{figure}[H]
    \centering
    \begin{verbatim}
    Definition simple_RDNI
        {T} (p: prog T)
       (R: state -> state -> Prop) :=
      forall (o: oracle) (s1 s2: state) (res1: Result T),
        exec o s1 p res1 ->
        R s1 s2 ->
        exists res2,
            exec o s2 p res2 /\
            R (extract_state res1) (extract_state res2) /\
            extract_ret res1 = extract_ret res2.
    \end{verbatim}
    \caption{Simple relatively deterministic noninterference.}
    \label{fig:RDNI_no_recovery}
\end{figure}

Figure \ref{fig:RDNI_no_recovery} states that a program $p$ satisfies \texttt{simple\_RDNI} for any two states $s_1$ and $s_2$ related by $R$, if there is an execution of $p$ from $s_1$ with oracle $o$ that results in $res_1$, then there is an execution of $p$ from $s_2$ with oracle $o$ that with a result $res_2$ such that, states of $res_1$ and $res_2$ are equivalent by $R$, and return values of $res_1$ and $res_2$ are equal.

\subsection{Crash, Reboot, and Recovery}
Since we will be reasoning about crash-safe systems, RDNI should be extended to take crashes, reboots and a recovery into account. We achieve this by changing the execution semantics in the definition with one that captures the entire process of crash-reboot-recovery. There are  important differences in new execution semantics that needs to be explained:
\begin{enumerate}
    \item Execution relation taking two program arguments, program to run and a recovery program,
    \item How the state after a crash followed by a reboot is handled.
 Effects of a reboot of a system may be nondeterministic. One example of this is an asynchronous disk. When a system crashes and reboots, the disk can be in one of the multiple possible states nondeterministically due to buffered and reordered writes. To capture and quantify this source of nondeterminism, we introduce  \emph{reboot state functions} --- or \emph{reboot functions} for short. A reboot function takes a state after a crash and returns the state that the system will be after a reboot. Reboot functions make effects of the reboot on a state deterministic, due to the fact that outcome of a function application is deterministic. Similar to the oracles, different outcomes of a nondeterministic reboot is represented by different reboot functions.

 \item Execution semantics of a crash-reboot-recovery process must capture multiple crash and recovery attempts. One way to achieve this is providing semantics for execution of the original program followed by the multiple consecutive executions of a recovery program. Since each execution requires an oracle and each crash requires a reboot function to determine after-reboot state, the new execution semantics will take a list of oracles and a list of reboot functions.
 \end{enumerate}

 We will explain further details of how executions with recovery implemented in the following section. Figure \ref{fig:RDNI_recovery} shows the formalization with recovery executions.

\begin{figure}[H]
    \centering
    \begin{verbatim}
Definition RDNI_with_recovery
    {T} (p: prog T)
    (rec: prog unit)
    (R: state -> state -> Prop) :=
  forall (l_o: list oracle)
  (l_rf: list (state -> state))
  (s1 s2: state) (res1: Result T),
    exec_with_recovery l_o s1 l_rf p rec res1 ->
    R s1 s2 ->
    exists res2,
        exec_with_recovery l_o s2 l_rf p rec res2 /\
        R (extract_state res1) (extract_state res2) /\
        extract_ret res1 = extract_ret res2.
    \end{verbatim}
    \caption{RDNI with recovery executions.}
    \label{fig:RDNI_recovery}
\end{figure}

{\color{red} One paragraph explaining the changes.}

\subsection{Application specific changes}
There are some application specific changes we made to RDNI. First is the addition of a user to the execution semantics. This change allows us to model multi-user systems and discretionary access control.

Second is conditioning return value equality on a predicate for the user. This way, we can require return value equivalence to hold only for certain users, which is needed to state confidentiality of multi-user systems. For example return value equality is required when the theorem is about adversaries' executions but not needed when it is about normal user's executions.

Third is changing the definition to be about the execution of two programs instead of the same one. This change enables us to reason about functions with different input arguments, because a ConFrm program is a function and its arguments together.
With these changes, we reach our final definition for RDNI, which is shown in Figure \ref{fig:RDNI_final}.

\begin{figure}[H]
    \centering
    \begin{verbatim}
    Definition RDNI
        {T} (u: user) (p1 p2: prog T)
        (rec: prog unit)
       (R: state -> state -> Prop)
       (cond: user -> Prop):=
      forall (l_o: list oracle) (l_rf: list (state -> state))
      (s1 s2: state) (res1: Result T),
        exec_with_recovery u l_o s1 l_rf p1 rec res1 ->
        R s1 s2 ->
        exists res2,
            exec_with_recovery u l_o s2 l_rf p2 rec res2 /\
            R (extract_state res1) (extract_state res2) /\
            (cond u -> extract_ret res1 = extract_ret res2).
    \end{verbatim}
    \caption{Final definition of RDNI}
    \label{fig:RDNI_final}
\end{figure}

\subsection{Termination Sensitivity}
The RDNI definition requires for each execution, an execution to exist from an equivalent state. This was the case for all the definitions presented so far. This requirement is called \emph{Termination Sensitivity}. In its essence, termination sensitivity implies that an adversary cannot learn any confidential information by observing if the program terminates or not. An example of a non-termination sensitive implementation could be a function looping infinitely based on some secret bit. If implementation contains such a loop, then adversary who calls the function can learn the value of the secret bit by waiting a reasonable amount of time to see whether the function terminates or not.

More generally, termination sensitivity is not restricted to infinite loops. Any behavior that causes one execution to "get stuck" while another execution finishes will violate termination sensitivity. Which executions can "get stuck" depends on how the semantics are defined. For example, if the semantics of a read operation on a disk is defined only for addresses that are in bounds, then any execution that attempts an out-of-bounds access will get stuck.

It is also worth pointing out that getting stuck is not the same as returning an error for an invalid operation. In the latter case, semantics are still defined. So, in the above example, if the semantics are defined to return an error in case of an out-of-bounds access, then one in-bounds and one out-of-bounds execution would not violate termination sensitivity.

Although it captures an important aspect of a possible breach of confidentiality, termination sensitivity is not a necessity in confidentiality specifications. Many different systems in the literature use termination insensitive definitions for their specifications. \ref{} A termination insensitive definition requires any pair of existing executions from equivalent states to have the same return value and result in equivalent states. However a program now have freedom to get stuck in some equivalent states.

However, these definitions are generally variants of deterministic noninterference, where termination insensitive variant is a weaker specification. In the nondeterministic case, termination sensitivity is overly restrictive. The requirement of \textbf{any} pair of executions from any two equivalent states to have the same return value and also result in equivalent states diminishes power of nondeterminism greatly. For example an abstraction of an allocation function where an unused resource is nondeterministically allocated would not satisfy termination insensitive nondeterministic noninterference. This restriction makes termination insensitive nondeterministic noninterference an unfitting confidentiality specification in many cases.

Relatively deterministic nature of RDNI allows us to define a termination insensitive variant that is not overly restrictive. Formal definition of termination insensitive RDNI can be found in figure \ref{fig:TI_RDNI} In this variant, pair of executions with the same oracles are allowed to be termination insensitive, but there is no requirement on pair of executions with different oracles. In other words, a pair of executions with different oracles from equivalent states can have different return values and also can result in non-equivalent states. This freedom enables abstractions that are similar to the above example. since return value will be determined by the oracle.

\begin{figure}[H]
    \centering
    \begin{verbatim}
    Definition Termination_Insensitive_RDNI
        {T} (u: user) (p1 p2: prog T)
        (rec: prog unit)
       (R: state -> state -> Prop)
       (cond: user -> Prop):=
      forall (l_o: list oracle) (l_rf: list (state -> state))
      (s1 s2: state) (res1 res2: Result T),
        exec_with_recovery u l_o s1 l_rf p1 rec res1 ->
        exec_with_recovery u l_o s2 l_rf p2 rec res2 ->
        R s1 s2 ->

        R (extract_state res1) (extract_state res2) /\
        (cond u -> extract_ret res1 = extract_ret res2).
    \end{verbatim}
    \caption{Termination insensitive variant of RDNI}
    \label{fig:TI_RDNI}
\end{figure}

\section{Definitions and Meta-theory}
On top pf RDNI, ConFrm also includes structures and meta-theory that developers can use to implement confidential and crash-safe storage systems. This portion consists of two parts: (1) support for abstraction, and (2) the meta-theory that provides relevant theorems to prove confidentiality of implementation from the confidentiality of abstraction. We will first present the infrastructure for defining abstractions and then explain the meta-theory.

\subsection{Abstraction Structures}
\paragraph{Cores.}
ConFrm introduces cores as the main way to model the abstract state of the system and the operations that can be performed on it. A core has four components,
\begin{enumerate}
    \item the state the system
    \item the list of possible operations that can be performed,
    \item the list of possible nondeterminism tokens,
    \item the execution semantics of each operation.
\end{enumerate}

An example core for an in-memory cache can be informally described as
\begin{enumerate}
    \item the state := a partial function from addresses to data
    \item the list of possible operations := \texttt{read}, \texttt{write}, \texttt{evict},
    and \texttt{flush}
    \item the list of possible nondeterminism tokens := continue execution, crash here
    \item the execution semantics of each operation := ...
\end{enumerate}.

{\color{red}Explain the example?}

Also, to ensure that tokens capture all the nondeterminism in the semantics, a proof that shows, given a token, execution semantics are deterministic is required.

\begin{figure}[H]
    \centering
    \begin{verbatim}
Record Core :=
  {
    token : Type;
    state : Type;
    operation : Type -> Type;
    exec: forall T, user -> token -> state ->
        operation T -> @Result state T -> Prop;

    exec_deterministic_wrt_token :
      forall u o s T (p: operation T) ret1 ret2,
        exec u o s p ret1 ->
        exec u o s p ret2 ->
        ret1 = ret2;
  }.
    \end{verbatim}
    \caption{Definition of a core}
    \label{fig:Core_Definition}
\end{figure}

\paragraph{Crashes.}
ConFrm provides support for crash semantics by defining two different execution results: \texttt{Finished}, and \texttt{Crashed}. A \texttt{Finished} result means that program has successfully completed and contains a state and a return value. A \texttt{Crashed} result means that the program crashed during its execution and contains only a state, which represents the state of the system after the crash happened but before rebooting.

Developers define the crash semantics of the system by defining execution rules that lead to a \texttt{Crashed} result. It is developer's responsibility to ensure that defined execution semantics correctly models the system's both normal and crash behavior.

\paragraph{Layers.}
ConFrm also includes the machinery that turns a core to a full layer by equipping it with \texttt{Bind} and \texttt{Return} operations. This eliminates the repetitive work that must to be done to define layers. It also allows framework to provide core-agnostic theorems and tactics to be used in proofs.

Semantics of the layer are derived from the semantics of its core. New  semantics takes a list of tokens (i.e., an oracle) and consumes exactly one at each step.

{\color{red} Some of the Bind/Ret semantics displayed here}

ConFrm also provides some theorems regarding determinism of an execution as well as relationship between oracles and executions like how two executions relate to each other if one's oracle is a prefix of the other's.

\paragraph{Recovery semantics.}
ConFrm provides pre-defined recovery semantics for the systems and adds these semantics when it generates a layer from a core. To distinguish recovery semantics from the semantics of the execution of a single program, we will refer to recovery semantics as executing-with-recovery. In ConFrm's recovery model, only two outcomes are possible when executing-with-recovery: (1) execution can finish without any crashes, or (2) execution crashes then recovers after certain number of attempts. To represent these two outcomes, ConFrm uses two types of recovery result: \texttt{RFinished} and \texttt{Recovered}. \texttt{RFinished} corresponds to case (1) and \texttt{Recovered} corresponds to case (2). Since there is no rule for crashing infinitely many times, the provided semantics implicitly assume that recovery eventually will succeed.

\begin{figure}[H]
    \centering
    \begin{verbatim}
Inductive exec_with_recovery :
forall T, user -> list oracle -> state ->
list (state -> state) -> prog T -> prog unit ->
@Recovery_Result state T -> Prop :=
    | ExecFinished :
      forall T (p: prog' T) p_rec
        u o d d' t,
        exec u o d p (Finished d' t) ->
        exec_with_recovery u [o] d [] p p_rec (RFinished d' t)
    | ExecRecovered :
      forall T (p: prog' T) p_rec
        u o lo d d' get_reboot_state l_grs ret,
        exec u o d p (Crashed d') ->
        exec_with_recovery u lo (get_reboot_state d')
            l_grs p_rec p_rec ret ->
        exec_with_recovery u (o::lo) d (get_reboot_state::l_grs)
            p p_rec (Recovered (extract_state ret)).
    \end{verbatim}
    \caption{Recovery semantics in ConFrm}
    \label{fig:Recovery_Semantics}
\end{figure}

Figure \ref{fig:Recovery_Semantics} displays the formal definition.
Semantics for (1) is stated in \texttt{ExecFinished} rule. It is quite straightforward. If the program successfully executes, then it successfully executes-with-recovery.
Semantics for (2) is stated in \texttt{ExecRecovered} rule and more involved. It is inductively defined to capture repeated attempts of recovery until it succeeds. The rule states that, if the original program crashes, and recovery program executes-with-recovery to some result, then original program executes-with-recovery to the state of that result. Execution uses a new oracle and a new reboot function every time a crash-reboot-recovery cycle happens. Therefore, lengths of those lists implicitly determine how many times the recovery will crash until it succeeds.

\paragraph{Refinements.}
ConFrm's main mechanism for relating abstractions and implementations is refinements.
ConFrm defines a refinement as an object between an implementation layer and a core abstracting it. We extend the standard refinement definition to accommodate both crashes and oracles.

As shown in figure \ref{fig:Core_Refinement_Definition}, a refinement has four components that corresponds the four components of a core, and a theorem states that a successful execution preserves the state refinement relation. The four components are
\begin{itemize}
    \item a \texttt{compile} function, that turns an  abstract operation to its implementation program,
    \item a \texttt{refines} relation that relates an abstract state to an implementation state,
    \item a \texttt{refines\_reboot} relation that relates an abstract reboot state to an implementation reboot state,
    \item and  \texttt{token\_refines} relation that relates an abstract token to an implementation oracle.
\end{itemize}

\begin{figure}[H]
    \centering
    \begin{verbatim}
Record CoreRefinement {O_imp} (L_imp: Layer O_imp) (O_abs: Core) :=
  {
    compile_core : forall T, O_abs.(Core.operation) T -> L_imp.(prog) T;

    refines_core: L_imp.(state) -> O_abs.(Core.state) -> Prop;

    refines_reboot_core: L_imp.(state) -> O_abs.(Core.state) -> Prop;

    token_refines: forall T, user -> L_imp.(state) ->
        O_abs.(Core.operation) T -> (L_imp.(state) ->
        L_imp.(state)) -> L_imp.(oracle) ->
        O_abs.(Core.token) -> Prop;

    exec_compiled_preserves_refinement_finished_core :
      forall T (p2: O_abs.(Core.operation) T) o1 s1 s1' r u,
        (exists s2, refines_core s1 s2) ->
        L_imp.(exec) u o1 s1 (compile_core T p2) (Finished s1' r) ->
        (exists s2', refines_core s1' s2');
  }.
    \end{verbatim}
    \caption{Definition of a core refinement}
    \label{fig:Core_Refinement_Definition}
\end{figure}

Both \texttt{compile} and \texttt{refines} are part of the standard definition. However \texttt{refines\_reboot} and \texttt{token\_refines} relations require more explanation.

We separate \texttt{refines\_reboot} from \texttt{refines} because, in general, \texttt{refines} relation is too strong to hold for after-reboot states but we also needed a relation between them to ensure that recovery restores the original \texttt{refines} relation. {\color{red} Add example here. Cache not having latest value or smth.}

The \texttt{token\_refines} relation is more complicated. On top of the oracle and the token it relates, it takes the following parameters
\begin{itemize}
    \item a user,
    \item an implementation state,
    \item an abstract operation,
    \item and an implementation reboot function.
\end{itemize}
All these parameters are necessary to capture intricate relationship between abstract tokens and implementations' crash and recovery behavior. We can demonstrate the roles they play by examining the following example.

Assume that we are abstracting an implementation of a checksum-based log on an asynchronous disk with a \texttt{write} function.
A crash during a write to a checksum-based log may leave the log in such a state that whether the \texttt{write} succeeded or not would depends on which blocks made it to the disk before crash happened (which is determined by the after-reboot state of the implementation). In other words, success of a write after crash depends on (1) state of the disk just after the crash, and (2) state of the disk after reboot. To determine (1), we need to know the user, the starting state, and data being written, which is in the operation. To determine (2), we need to know the reboot function. Therefore, capturing the behavior of the write in this particular case requires all the parameters listed above. Other operations may require some or all of those parameters as well.

Similar to generating a layer from a core, ConFrm can automatically generate a refinement between two layers given a core refinement between an implementation layer and an abstraction core. A refinement for a layer differs from a refinement for a core in three places. First, \texttt{compile} function transforms programs from the abstraction layer to implementation layer. Second, \texttt{token\_refines} turns into \texttt{oracle\_refines}, which relates an abstract oracle and an implementation oracle.
Third, a finished execution of any compiled program should preserve the refinement. ConFrm also provides \texttt{recovery\_oracles\_refine} relation, which relates list of implementation oracles to list of abstraction oracles by \texttt{oracle\_refines} inductively.

{\color{red} Refinement picture here.}

\paragraph{Horizontal Compositions.}
To enable modular implementations, ConFrm provides automatic derivation of a new, composite core from two given cores via horizontal composition. State of the composite core is a pair that contains the state of each the component cores. This capability allows developers to develop the system in small, self contained parts that can be combined at will when desired without much overhead. A layer derived from a composite ConFrm contains support for "lifting" the programs written in a layer of the one of the component cores to the layer of the composite core. Similarly, it allows automatic derivation of a refinement between the two composite layers if a component of first layer is a refinement of a component of the second layer.

\subsection{Meta-theory}
At the heart of ConFrm lies the theorem \ref{fig:RDNI_Transfer_Definition}, which derives the confidentiality of a compiled program from the confidentiality of its abstraction. The theorem reveals sufficient conditions for preserving RDNI through refinement. The two conditions are:

\begin{enumerate}
    \item there should be a simulation between implementation and abstraction with respect to refinement relations, and
    \item if a list of implementation oracles refine a list of abstract oracles from a state with the first program, then it should refine the same oracle from any state that is equivalent to the first state with the second program.
\end{enumerate}

First condition ensures that there is no execution of a compiled program that is not captured by an execution of an abstract program. This is necessary for a property of any abstract execution to imply a property of any implementation execution. If there was an implementation execution that does not correspond to an abstract execution, then it would not be possible to reason about such execution through an abstract execution.

Second condition can be interpreted as the necessity that abstraction does not inject dependency to the confidential data into abstract oracles. Abstractions modelling some deterministic behaviors of an implementation as nondeterminism is a common pattern. For example, an abstraction of a resource allocator may model the allocation function to return an unused resource nondeterministacally, even though the implementation's behavior is actually deterministic (e.g., returning the first available one).

This property makes sure that developer does not abstract a behavior that depends on the confidential data in such a way. If such action would be permitted, then two implementation executions from equivalent states with the same implementation oracles could correspond to two abstraction executions with different oracles. In such a case, the noninterference of the abstraction with the same oracles wouldn't be strong enough to establish the same fact in implementation, due to the fact that noninterference of the abstraction does not state anything about executions with different oracles. Formalization of this condition can be seen in figure \ref{fig:ORS_Definition}.

{\color{red} Give example for above paragraph.}

\begin{figure}[H]
\centering
\begin{verbatim}
Definition oracle_refines_same_from_equivalent
    (u: user) {T} (p1_abs p2_abs: L_abs.(prog) T)
    rec_abs l_get_reboot_state_imp
    (equivalent_states_abs: L_abs.(state) -> L_abs.(state) -> Prop) :=

forall l_o_imp l_o_abs l_o_abs' s1_imp s2_imp,

    refines_equivalent equivalent_states_abs s1_imp s2_imp ->

    recovery_oracles_refine
        u s1_imp p1_abs rec_abs
        l_get_reboot_state_imp
        l_o_imp l_o_abs ->

    recovery_oracles_refine
        u s2_imp p2_abs rec_abs
        l_get_reboot_state_imp
        l_o_imp l_o_abs' ->

    recovery_oracles_refine
        u s2_imp p2_abs rec_abs
        l_get_reboot_state_imp
        l_o_imp l_o_abs.
\end{verbatim}
\caption{Formalization of oracle refinement being independent of confidential data}
\label{fig:ORS_Definition}
\end{figure}

\paragraph{Simulations.}
The first condition above states that a simulation must exist between the abstraction and the implementation. Since we introduced oracles and crash-and-recovery into execution relations, we modify the standard simulation definition to accommodate those changes.

As shown in figure \ref{fig:Simulation_Definition}, the first change is that the modified simulation definition has three simulation relations, one for the starting states, one for the end states, and one for the oracles. We separate the relation that relates the starting and end state to be able to reason about recovery where the relation that holds at the beginning and at the end are different.

In the context of RDNI transfer of recovery program, start and end simulation relations coincide with the state refinement relations \texttt{refines\_reboot} and \texttt{refines}, respectively. We also define a two relation variant to use in definition  \ref{fig:RDNI_Transfer_Definition}, where start and end relations are both \texttt{refines} relation.

Second change is that a simulation is defined over an entire execution-with-recovery. This allows simulation relation to be broken temporarily after a crash, as long as it is restored by the recovery process. This change is necessary because crashes may expose states that will never appear during a normal execution. This way, refinement relation can only consider the states that appear during normal execution. How to represent crash states is entirely left to the developer.

\begin{figure}[H]
\centering
\begin{verbatim}
Definition Simulation
   u T (p_abs: L_abs.(prog) T) (rec_abs : L_abs.(prog) unit)
   l_get_reboot_state_imp
   l_get_reboot_state_abs
   R_begin R_end :=

  forall l_o_imp s_imp  s_imp' s_abs,
    R_begin s_imp s_abs ->
   L_imp.(exec_with_recovery) u l_o_imp s_imp
    l_get_reboot_state_imp (R.(compile) p_abs)
    (R.(compile) rec_abs) s_imp' ->
    exists l_o_abs s_abs',
        recovery_oracles_refine u s_imp p_abs rec_abs l_get_reboot_state_imp l_o_imp l_o_abs /\
        L_abs.(exec_with_recovery) u l_o_abs s_abs l_get_reboot_state_abs p_abs rec_abs s_abs' /\
        R_end (extract_state_r s_imp') (extract_state_r s_abs') /\
        extract_ret_r s_imp' = extract_ret_r s_abs').
\end{verbatim}
\caption{ConFrm's simulation relation with oracles and execution-with-recovery}
\label{fig:Simulation_Definition}
\end{figure}

\begin{figure}[H]
\centering
\begin{verbatim}
Lemma RDNI_transfer:
  forall O_imp O_abs (L_imp: Layer O_imp) (L_abs: Layer O_abs)
    (R: Refinement L_imp L_abs)
    u T (p1_abs p2_abs: L_abs.(prog) T) rec_abs
    l_get_reboot_state_imp
    l_get_reboot_state_abs
    equivalent_states_abs cond,

    RDNI
      u p1_abs p2_abs rec_abs
      equivalent_states_abs
      cond l_get_reboot_state_abs ->

    Simulation R
      u p1_abs rec_abs
      l_get_reboot_state_imp
      l_get_reboot_state_abs ->

    Simulation R
      u p2_abs rec_abs
      l_get_reboot_state_imp
      l_get_reboot_state_abs ->

    oracle_refines_same_from_equivalent R
      u p1_abs p2_abs rec_abs
      l_get_reboot_state_imp
      equivalent_states_abs ->

    RDNI
      u (R.(compile) p1_abs)
      (R.(compile) p2_abs)
      (R.(compile) rec_abs)
      (refines_equivalent R equivalent_states_abs)
      cond l_get_reboot_state_imp.
\end{verbatim}
\caption{RDNI transfer theorem}
\label{fig:RDNI_Transfer_Definition}
\end{figure}

%%%% SOme conclusion here
\iffalse
\section{Property Transfers}

\subsection{RDNI transfer}
- Required properties

-- SimulationForProgram

-- abstract oracles exist wrt (AOE)

-- oracle refines same from equivalent (ORS)

-- exec compiled preserves validity (Trivial in our case because all of our top states are valid)

-- Termination Sensitive (TS)

\subsection{ORS}
-- have same structure (program flow equivalence) (HSS)

\begin{minted}{coq}
Lemma token_refines_finished_prefix_eq:
forall ...,

token_refines u s1 op1 grs1 o1 t1 ->
token_refines u s2 op2 grs2 o2 t2 ->

exec u s1 o1 (compile op1) (Finished s1' r1) ->
exec u s2 o2 (compile op2) (Finished s2' r2) ->

have_same_structure op1 op2 ->

(exists s1a,refines s1 s1a) ->
(exists s2a, refines s2 s2a) ->

one_prefix_of_other o1 o2 ->
o1 = o2 /\ t1 = t2.
\end{minted}

\begin{minted}{coq}
Lemma token_refines_crashed_prefix_eq:
forall ...,

token_refines u s1 op1 grs1 o1 t1 ->
token_refines u s2 op2 grs2 o2 t2 ->

exec u s1 o1 (compile op1) (Crashed s1') ->
exec u s2 o2 (compile op2) (Crashed s2') ->

have_same_structure op1 op2 ->

(exists s1a,refines s1 s1a) ->
(exists s2a, refines s2 s2a) ->

one_prefix_of_other o1 o2 ->
t1 = t2.
\end{minted}

\begin{minted}{coq}
Lemma oracle_refines_impl_eq:
forall ...,
    oracle_refines u s1 p1 imp_reboot_f o1 oa1 ->
    oracle_refines u s2 p2 imp_reboot_f o2 oa2 ->

    refines s1 s1a ->
    refines s2 s2a ->

    exec u o1 s1 (compile p1) (Finished s1' r1) ->
    exec u o2 s2 (compile p2) (Finished s2' r2) ->

    have_same_structure p1 p2 u s1a s2a ->

    token_refines_finished_prefix_eq ->

    one_prefix_of_other o1 o2 ->
    not_init p1 ->
    not_init p2 ->

    o1 = o2 /\ oa1 = oa2.
\end{minted}

\begin{minted}{coq}
Lemma oracle_refines_independent_from_reboot_function:
forall ...,
    exec u o s (compile p) (Finished s' r) ->
    oracle_refines u s p grs o o_abs ->
    forall grs',
      oracle_refines u s p grs' o o_abs.
\end{minted}

\begin{minted}{coq}
Lemma oracle_refines_prefix_finished_not_crashed:
forall ...,
    oracle_refines u s1 p1 imp_reboot_f o1 oa1 ->
    oracle_refines u s2 p2 imp_reboot_f o2 oa2 ->

    refines s1 s1a ->
    refines s2 s2a ->

    exec u o1 s1 (compile p1) (Finished s1' r1) ->
    exec u o2 s2 (compile p2) (Crashed s2') ->

    have_same_structure p1 p2 u s1a s2a ->

    one_prefix_of_other o1 o2 ->
    not_init p1 ->
    not_init p2 ->
    False.
\end{minted}

These are compositional in the sense that proving corresponding properties for
each operation implies it is true for all programs created from them.

\subsection{AOE}
\fi


\section{Quark or diquark annihilation in hadronic processes.}

\hspace{1.0em}
We consider also hadron-hadron inelastic processes when antiquark or
antidiquark from hadron projectile annihilate with corresponding quark
or diquark from hadron target.
In this case excitation of one baryonic (string with quark and diquark
ends) or mesonic (string with quark and antiquark ends) is created,
respectively. These processes in the Regge theory correspond to cut
reggeon exchange diagrams. Initial energy $\sqrt{s}$
dependences of these processes
cross sections are defined by  intercepts of reggeon exchange trajectories.
For example $\sigma_{\pi^{+}p\rightarrow S(s)} \sim s^{\alpha_{\rho}(0)-1}$,
$S$ notes string and $\alpha_{\rho}(0)$ is the intercept of $\rho$ reggeon
trajectory. Thus $\sigma_{\pi^{+}p\rightarrow S(s)}
$ decreases with energy
rise. Cross sections for other quark and diquark proccesses have simiar
as $\sigma_{\pi^{+}p\rightarrow S(s)}$ initial energy dependences.
Thus quark and diquark annihilation processes are important at
relative low initial energies. Another example of these processes is
$\bar{p}p \rightarrow S$, which is used in the kinetic model to describe
final state of $\bar{p}p$ annihilation.
Simulation of such kind process is rather simple. We should randomly
(according to weight calculated using hadron wave function)
choose quark (antiquark) or diquark (antidiquark) from projectile and
find suitable (with the same flavor content) partner for annihilation
from target. The created string four-momentum will be equal total reaction
four-momentum since annihilated system has small neglected momentum (only
low momenta quarks are able to annihilate).

To determine statistical weights for
 quark annihilation processes are leading to a string production
and separate them from processes, when two or more strings can be produced we
use the Regge motivated total cross section parametrization suggested by
Donnachie and Landshoff \cite{DL92}. Using their parametrization the
statistical weight for the one string production process is given by
\begin{equation}
\label{OSE1} W_{1} = \frac{Y_{hN}s^{-\eta}}{\sigma^{tot}_{hN}(s)}
\end{equation}
and statistical weight to produce two and more strings is given by
\begin{equation}
\label{OSE2} W_{2} = \frac{X_{hN}s^{\epsilon}}{\sigma^{tot}_{hN}(s)},
\end{equation}
where hadron-nucleon total cross sections  $\sigma^{tot}_{hN}(s)$ and its
fit parameters $Y_{hN}$, $X_{hN}$, which do not depend
from the total c.m. energy squared $s$ and depend on type of
projectile hadron $h$ and target nucleon $N$ can be found in \cite{PDG96}.
The reggeon intercept $\eta \approx
0.45$ and the pomeron intercept $\epsilon \approx 0.08$.


\acresetall
\chapter{Live implementation in GNURadio}\label{chapter:live} \label{ch:live}

A live implementation of the scenario classification has been implemented using GNURadio. The models have been trained with the procedures explained in previous chapters and afterward its persistence is achieved using the sklearn library joblib for the feature-based learning and the library PyH5 for the spectrogram based learning.

The selection of the saved models is crucial for the good performance of the application. For the feature-based learning, the models with the best trade-off between validation accuracy and prediction time have been chosen. The selected models are:

\begin{itemize}
    \item K-nearest neighbors with 4 neighbors, trained with the whole (XL) unscaled dataset.
    \item A Decision tree with a tree depth=50, trained with the whole (XL) scaled dataset using a standard scaler.
    \item \ac{SVM} with an RBF complexity of \(\gamma=2^3\), trained with the medium (M) scaled dataset using a standard scaler.
\end{itemize}

For the spectrogram-based learning, an interesting technique is used for choosing the best fit for the real-time implementation. Keras provides routines for saving the model after the total of iterations is done, where one can assume that the model, after extensive training, will have an improving performance with increasing iteration number. However, a long training time can lead to overfitting of the model as seen at the end of section~\ref{ch:image_classification}. Two alternatives to avoid this are provided based on a constant callback of the accuracy and loss parameters. These alternatives are:

\begin{itemize}
    \item Early stopping: a monitored quantity can be selected from the accuracies or losses, and a range of improvement is set by the designer. Constantly, the selected value is checked, and everytime that it reaches a better performance a model's persistence is saved to disk. If there is no improvement in an arbitrary number of iterations thereafter, the process is stopped and the persistence of the model at the last iteration can also be saved to disk.
    \item Model Checkpoint: similarly to early stopping, a monitored quantity is selected, and the best model's persistence with respect to that quantity is saved to disk. However, the whole training process is run to completion, where the persistence of the model at the last iteration can also be saved to disk as well.
\end{itemize}

In this work model checkpoint was selected for model persistence, as it provides the capability of saving the best model with respect to a parameter as well as allowing the observation of the whole process by the cost of training times. The validation loss was selected as monitored quantity, as it represents how different was the predicted data to the training data, and considering that there is no significant improvement of accuracy after a couple hundreds of iterations for any of the models.

Simple blocks have been written to serve as a wrapper for the trained models, and a comparative setup with the implementation used at the DySpan Spectrum Challenge 2017 is carried out. As a first approach, the classification probabilities is extracted in real time. These probabilities state how certain is each of the algorithms at making a decision. For plotting, a modified "QT Time Raster" block is used, to see in the x-axis, ordinally, the possible scenarios from scenario 0 to 9, and the y-axis updates constantly to show outputs of the classifiers. It is important to notice that none of these axes reflect time directly, as it will become clear shortly. For testing, the \ac{PU} transmitter is set to send its packets using the scenarios increasingly for a duration of 2 seconds each. Additionally, different values of \ac{PU} transmission power have been used to determine the performance of the implemented machine learning algorithms facing different values of SNR. Fig~\ref{fig:prob_snr_15} shows these probability plots for an SNR=15dB.

\begin{figure}[!htb]
    \centering
      \includegraphics[width=\textwidth]{figures/prob_snr_15}
      \caption{Decision certainty for an SNR=15dB}
      \label{fig:prob_snr_15}
\end{figure}

The high intensity on these plots is represented with a lighter color and means a higher probability/certainty of a decision. In the top row the spectrogram-based algorithms are shown, and it can be seen that they show a consistent classification for each scenario every 2 seconds. Furthermore, the certainty of Adadelta and Adamax is clearer at the moment of making a decision vs. the certainty of SGD. However, this has little effect in the final result, as still the right scenario has a higher probability and is correctly classified, as seen in Fig~\ref{fig:scn_snr_15}. The row on the bottom shows the feature-based learning algorithms. On first instance it could be understood that they are not classifying correctly the scenarios, as a definite staircase-like fashion, as for the top row, is intuitively expected. However, it is important to notice that the nature of these classification models is different: it is feature based, while the top row is, so to say, sample based. What this means is that the top row classifies scenarios on the go based solely on the input data, whilst the bottom row classifies based on the frame events generated by the blocks described in Fig~\ref{fig:frame_events}. These frame events vary in quantity based on the number of frames that the \ac{PU} is transmitting, reason why in Fig~\ref{fig:scn_snr_15} the classified scenarios show to be longer for scenario 6 (high packet rate) than, for example, scenario 7 (low packet rate). This explains the difference on the output patterns.

\begin{figure}[!htb]
    \centering
      \includegraphics[width=\textwidth]{figures/scn_snr_15}
      \caption{Classified scenario for an SNR=15dB}
      \label{fig:scn_snr_15}
\end{figure}

In Fig~\ref{fig:scn_snr_15}, and in upcoming scenario classification figures, the implementation used in the DySpan Spectrum Challenge 2017 is plotted in the top row, moving the rows from Fig~\ref{fig:prob_snr_15} one position down. It can be seen that the pattern is alike to the feature-based classifiers, as they use the same features and frame events.

Additional plots for the decision probability and classified scenario are shown for SNR=10dB in Figs~\ref{fig:prob_snr_10}, \ref{fig:scn_snr_10}, SNR=5dB in Figs~\ref{fig:prob_snr_5}, ~\ref{fig:scn_snr_5} and SNR=0dB in Figs~\ref{fig:prob_snr_0}, \ref{fig:scn_snr_0}. An evident increase in the uncertainty can be seen with a decrease of the SNR, which is expected. Nevertheless, the spectrogram-based classifiers continue to have a remarkable performance even with low values of \ac{PU} transmit power. An important remark that cannot be seen in the pictures is that for SNR=5dB and below the frequency with which the frame events are generated decreases, given that they depend on detection of \ac{PU} energy. Because of this fact, all feature-based classifiers stop generating outputs consistently, until the point they just stop classifying (or generating outputs whatsoever). This sets a clear advantage for the spectrogram-based classifiers, as they are independent of the \ac{PU} transmission power.

\begin{figure}[!htb]
    \centering
      \includegraphics[width=\textwidth]{figures/prob_snr_10}
      \caption{Decision certainty for an SNR=10dB}
      \label{fig:prob_snr_10}
\end{figure}

\begin{figure}[!htb]
    \centering
      \includegraphics[width=\textwidth]{figures/scn_snr_10}
      \caption{Classified scenario for an SNR=10dB}
      \label{fig:scn_snr_10}
\end{figure}

\begin{figure}[!htb]
    \centering
      \includegraphics[width=\textwidth]{figures/prob_snr_5}
      \caption{Decision certainty for an SNR=5dB}
      \label{fig:prob_snr_5}
\end{figure}

\begin{figure}[!htb]
    \centering
      \includegraphics[width=\textwidth]{figures/scn_snr_5}
      \caption{Classified scenario for an SNR=5dB}
      \label{fig:scn_snr_5}
\end{figure}

\begin{figure}[!htb]
    \centering
      \includegraphics[width=\textwidth]{figures/prob_snr_0}
      \caption{Decision certainty for an SNR=0dB}
      \label{fig:prob_snr_0}
\end{figure}

\begin{figure}[!htb]
    \centering
      \includegraphics[width=\textwidth]{figures/scn_snr_0}
      \caption{Classified scenario for an SNR=0dB}
      \label{fig:scn_snr_0}
\end{figure}


%% beamer packages
% other themes: AnnArbor, Antibes, Bergen, Berkeley, Berlin, Boadilla, boxes,
% CambridgeUS, Darmstadt, Dresden, Frankfurt, Goettingen, Hannover, Ilmenau,
%JuanLesPins, Luebeck, Madrid, Malmoe, Marburg, Montpellier, PaloAlto,
%Pittsburgh, Rochester, Singapore, Szeged, Warsaw
% other colors: albatross, beaver, crane, default, dolphin, dove, fly, lily,
%orchid, rose, seagull, seahorse, sidebartab, structure, whale, wolverine,
%beetle

%\documentclass[xcolor=dvipsnames]{beamer}
\documentclass[table,dvipsnames]{beamer}
\usepackage{beamerthemesplit}
\usepackage{bm,amsmath,marvosym}
\usepackage{listings,color}%xcolor
\usepackage[ngerman]{babel}
\usepackage{natbib}
\usepackage[utf8]{inputenc}
\definecolor{shadecolor}{rgb}{.9, .9, .9}
\definecolor{darkblue}{rgb}{0.0,0.0,0.5}
\definecolor{myorange}{cmyk}{0,0.7,1,0}
\definecolor{mypurple}{cmyk}{0.3, 0.9, 0.0, 0.2}

% make a checkmark
\usepackage{tikz}
\def\checkmark{\tikz\fill[scale=0.4](0,.35) -- (.25,0) -- (1,.7) -- (.25,.15) -- cycle;}

% dot product
\usetikzlibrary{arrows,positioning}
\tikzset{
    %Define standard arrow tip
    >=stealth',
    % Define arrow style
    pil/.style={->,thick}
}

% math stuff
\newcommand{\argmin}{\operatornamewithlimits{argmin}}

\lstnewenvironment{code}{
    \lstset{backgroundcolor=\color{shadecolor},
        showstringspaces=false,
        language=python,
        frame=single,
        framerule=0pt,
        keepspaces=true,
        breaklines=true,
        basicstyle=\ttfamily,
        keywordstyle=\bfseries,
        basicstyle=\ttfamily\scriptsize,
        keywordstyle=\color{blue}\ttfamily,
        stringstyle=\color{red}\ttfamily,
        commentstyle=\color{green}\ttfamily,
        columns=fullflexible
    }
}{}

\lstnewenvironment{codeout}{
    \lstset{backgroundcolor=\color{shadecolor},
        frame=single,
        framerule=0pt,
        breaklines=true,
        basicstyle=\ttfamily\scriptsize,
        columns=fullflexible
    }
}{}

\hypersetup{colorlinks = true, linkcolor=darkblue, citecolor=darkblue,urlcolor=darkblue}
\hypersetup{pdfauthor={A. Richards}, pdftitle={Intro to probabilistic programming}}

\newcommand{\rd}{\textcolor{red}}
\newcommand{\grn}{\textcolor{green}}
\newcommand{\keywd}{\textcolor{myorange}}
\newcommand{\highlt}{\textcolor{NavyBlue}}
\newcommand{\norm}[1]{\left\lVert#1\right\rVert}
\def\ci{\perp\!\!\!\perp}
% set beamer theme and color
\usetheme{Frankfurt}
%\usetheme{Berkeley}
\usecolortheme{orchid}
%\usecolortheme{seagull}

%% modify the font
%\usepackage{fontspec}
%setting a font
%\setsansfont{TeX Gyre Adventor}
%\usepackage{newcent}

%% fix the section title for literature
\renewcommand{\bibsection}{\subsubsection*{\bibname } }

\title[Project teams]{Introduction to probabilistic programming \\ (with PyMC3)}
\author[A. Richards]{A. Richards}
\institute{}
\date[]{02.08.2017}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}
\frame{\titlepage}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\footnotesize
\tableofcontents
\normalsize
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introduction}
\subsection{}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\frametitle{Probabilistic programming}
\footnotesize
\begin{block}{A probabilistic programming language makes it easy to:}
 \begin{enumerate}
  \item write out complex probability models
  \item And subsequently solve these models automatically.
 \end{enumerate}
 \end{block}

\begin{block}{Generally this is accomplished by:}
 \begin{enumerate}
  \item Random variables are handled as a \href{https://en.wikipedia.org/wiki/Language\_primitive}{primitive}
  \item Inference is handled behind the scenes
  \item Memory and processor management is abstracted away
 \end{enumerate}
 \end{block}
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\frametitle{The pros and the cons}
\footnotesize
\textbf{Why you might want to use probabilistic programming}
\begin{enumerate}
 \item \keywd{Customization} - We can create models that have built-in hypothesis tests
 \item \keywd{Propagation of uncertainty} - There is a degree of belief associated prediction and estimation
 \item \keywd{Intuition} - The models are essentially 'white-box' which provides insight into our data
\end{enumerate}
\textbf{Why you might \highlt{NOT} want use out probabilistic programming}
\begin{enumerate}
 \item \keywd{Deep dive} - Many of the online examples will assume a fairly deep understanding of statistics
 \item \keywd{Overhead} - Computational overhead might make it difficult to be production ready
 \item \keywd{Sometimes simple is enough} - The ability to customize models in almost a plug-n-play manner has to come with some cost.
\end{enumerate}
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\frametitle{Bayesian Inference}
\large \highlt{Degree of belief} \\ \ \\
\footnotesize
You are a skilled programmer, but bugs still slip into your code. After a particularly difficult implementation of an algorithm, you decide to test your code on a trivial example. It passes. You test the code on a harder problem. It passes once again. And it passes the next, \textit{even more difficult}, test too! You are \highlt{starting to believe} that there may be no bugs in this code...

\begin{flushleft}
\href{https://github.com/CamDavidsonPilon/Probabilistic-Programming-and-Bayesian-Methods-for-Hackers}{Bayesian methods for hackers}
\end{flushleft}

This is \href{http://www.kdnuggets.com/2016/12/datascience-introduction-bayesian-inference.html}{a nice intro to Bayesian thinking done on kdnuggets (using PyMC3)}
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\frametitle{Some terminology}
\footnotesize
\begin{equation}
P(\theta|x) = \frac{P(x|\theta)P(\theta)}{P(x)}
\end{equation}

\begin{itemize}
 \item \keywd{prior} - $P(\theta)$ - one's beliefs about a quantity before presented with evidence
 \item \keywd{posterior} - $P(\theta|x)$ - probability of the parameters given the evidence
 \item \keywd{likelihood} - $P(x|\theta)$  - probability of the evidence given the parameters
 \item \keywd{normalizing constant} - $P(x)$
\end{itemize}

\begin{itemize}
 \item $P(\theta)$: This big, complex code likely has a bug in it.
 \item $P(\theta|X)$: The code passed all X tests; there still might be a bug, but it is less likely now.
\end{itemize}
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\begin{center}
\includegraphics[scale=0.32]{coin_flip.png}
\end{center}
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Warm up}
\subsection{}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[fragile]
\frametitle{PyMC3}
\footnotesize
\begin{code}
import pymc3 as pm
\end{code}

\begin{itemize}
 \item Developed by John Salvatier, Thomas Wiecki, and Christopher Fonnesbeck \citep{Salvatier16}
 \item Comes with \href{https://github.com/pymc-devs/pymc3/tree/master/pymc3/examples}{loads of good examples}
 \item API is is not backwards compartible with models specified in PyMC2
 \item Can still be run in Python2.7+.
\end{itemize}

\highlt{Basic workflow}
\begin{enumerate}
 \item Define hyperpriors
 \item Open a model context
 \item Perform inference
\end{enumerate}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\frametitle{Markov chain Monte Carlo (MCMC)}
\footnotesize
\keywd{MCMC}
\begin{itemize}
 \item It is an family of algorithms for obtaining a sequence of random samples from a probability distribution for which direct sampling is difficult.
 \item The sequence can then be used to approximate the distribution
 \item It allows for inference on complex models
\end{itemize}

A particularly useful class of MCMC, known as Hamliltonian Monte Carlo, requires \href{https://en.wikipedia.org/wiki/Gradient}{gradient} information which is often not readily available so PyMC3 uses Theano to get around this problem.  Something that has recently made this whole field a lot more interesting is the No-U-turn sampler (NUTS) because there are \highlt{self-tuning strategies} \citep{Hoffman14}.
\\ \ \\
One of the really nice things about probabilistic programming is that \highlt{you do not have to know how inference is performed}, but it can be useful.

\begin{itemize}
 \item \href{http://twiecki.github.io/blog/2015/11/10/mcmc-sampling/}{MCMC for Dummies}
 \item \href{https://arxiv.org/pdf/1206.1901.pdf}{More on Hamliltonian MCMC (Not for dummies)}
 \item \href{http://twiecki.github.io/blog/2014/01/02/visualizing-mcmc/}{How to animate MCMC (for everyone)}
\end{itemize}
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[fragile]
\begin{block}{PyMC3 is an improvement over PyMC2}
\begin{itemize}
 \item Intuitive model specification syntax e.g. \\
 \begin{equation*}
 x \sim N(0,1) \textrm{ becomes } x = \textrm{Normal}(0,1)
 \end{equation*}
 \item Powerful sampling algorithms such as the \href{http://arxiv.org/abs/1111.4246}{No U-Turn Sampler}
 \item \highlt{Variational inference}: \href{http://arxiv.org/abs/1506.03431}{ADVI} for fast approximate posterior estimation as well as \highlt{mini-batch} ADVI for large data sets.
 \item Relies on \href{http://deeplearning.net/software/theano}{Theano} which provides:
 \begin{itemize}
 \item Numpy broadcasting and advanced indexing
 \item Linear algebra operators
 \item Computation optimization and dynamic C compilation
 \item Simple extensibility
 \end{itemize}
 \item Transparent support for \highlt{missing value imputation}
\end{itemize}
\end{block}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\frametitle{Getting started}
\footnotesize

\begin{block}{}
 We will be using probabilistic programming with PyMC3 to perform automatic Bayesian inference on user-defined probabilistic models
\end{block}
\vspace{0.5cm	}
These are some of the best getting started resources out there
\begin{itemize}
 \item \href{https://github.com/pymc-devs/pymc3}{PyMC3 repo}
 \item \href{http://pymc-devs.github.io/pymc3/notebooks/getting_started.html}{Getting started guide}
 \item \href{https://github.com/CamDavidsonPilon/Probabilistic-Programming-and-Bayesian-Methods-for-Hackers}{Bayesian methods for hackers}
\end{itemize}
\vspace{0.5cm}
Now that we have an intuition for Bayesian inference and a general idea of what to expect with PyMC3 lets dive in.
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[fragile]
\frametitle{PyMC3}
\footnotesize
\begin{code}
import pymc3 as pm

n,h,alpha,beta,niter = 100,61,2,2,1000

# context management
with pm.Model() as model:
    p = pm.Beta('p', alpha=alpha, beta=beta)
    y = pm.Binomial('y', n=n, p=p, observed=h)

    start = pm.find_MAP()
    step = pm.Metropolis()
    trace = pm.sample(niter, step, start)
\end{code}

Data $\rightarrow$ Model context $\rightarrow$ Priors $\rightarrow$ Likelihood $\rightarrow$ Sampler $\rightarrow$ Inference
\vspace{0.5cm}
\\ \noindent To the notebooks!
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\frametitle{Where are we...}
\begin{block}{}
 \begin{itemize}
  \item[\checkmark] Overview
  \item[\checkmark] Coin-flip example
  \item[\checkmark] Estimating the mean and standard deviation of a Normal
  \item[\checkmark] Switchpoint analysis of text messages
  \end{itemize}
\end{block}
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[fragile]
\frametitle{There are more examples..}
\begin{block}{}
 But what about linear regression--the classical example??
\end{block}

The linear regression example \href{http://pymc-devs.github.io/pymc3/notebooks/getting_started.html}{is well explained in the docs}, but I did want to point out that we now have access to GLM style formulations in PyMC3.
\vspace{1cm}
\begin{code}
import pymc3 as pm

...

data = dict(x=x, y=y)

with pm.Model() as model:
    pm.glm.glm('y ~ x', data)
    step = pm.NUTS()
    trace = pm.sample(2000, step, progressbar=True)
\end{code}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{PMF}
\subsection{}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\frametitle{Recommenders}

\begin{table}
\begin{center}
What will a user \textit{buy}, \textit{click}, \textit{like}...
\end{center}
\ \\ \ \\
\begin{tabular}{|l|c|c|c|c|c|c|c|c|}
\hline
        & A  &  B & C & D & E & F & G & ... \\
\hline
Frodo   & 1  &  ? & 2 & 1 & 1 & 4 & 1 & ... \\
Sam     & ?  &  ? & 1 & 3 & ? & 3 & 1 & ... \\
Merry   & ?  &  ? & 1 & 1 & ? & 1 & 1 & ... \\
Gimli   & 1  &  1 & ? & 1 & ? & 1 & ? & ... \\
Legolas & 1  &  1 & ? & 1 & ? & 1 & ? & ... \\
\hline
\end{tabular}
\end{table}

\begin{itemize}
 \item Ebay and Amazon who recommends items for purchase
 \item Movies, dating services, social network feeds, recipes, jokes, hikes, ...
\end{itemize}
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\footnotesize

There are numerous types of recommender systems
\begin{itemize}
 \item \keywd{Popularity} - Most viewed, most well-liked, not customized to users
 \item \keywd{User-User} - Recommend items liked by users with similar results
 \item \keywd{Item-Item} - Recommend items similar to what the current user rated favorably
 \item \keywd{Matrix-Factorization} - Estimate a users underlying preferences
\end{itemize}
-------------------------------------------------------------------------------- \\
Two of the most commonly implemented varieties are:
\begin{itemize}
 \item \keywd{collaborative filtering} - Imagine that user 1 and user 2 both like the same 4 science fiction novels we can then infer that if user 1 also likes another similar novel then user 2 will have a good chance of also liking it.
 \item \keywd{Content-based recommender} - These systems also make use of extra features associated with the user
\end{itemize}
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\frametitle{Probabilistic matrix factorization (PMF)}
\footnotesize
\begin{itemize}
 \item Probabilistic approach to the collaborative filtering problem that takes a Bayesian perspective \citep{Salakhutdinov08}.
 \item The ratings $R$ are modeled as draws from a Gaussian distribution
 \item We use precision $\alpha$, a fixed parameter, that reflects the uncertainty of the estimations; the normal distribution is commonly reparameterized in terms of precision, which is the inverse of the variance.
 \item small precision parameters help control the growth of our latent parameters
 \end{itemize}
The following implementation is modified from the \href{https://pymc-devs.github.io/pymc3/notebooks/pmf-pymc.html}{example in the PyMC3 documentation}.
\vspace{1cm}
Back to the notebook!
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\frametitle{Conclusions}
\footnotesize
\begin{itemize}
 \item Our results demonstrate that the mean of means method is our best baseline on our prediction task.
 \item We are able to obtain a significant decrease in RMSE using the PMF MAP estimate obtained via Powell optimization.
 \item We illustrated one way to monitor convergence of an MCMC sampler with a high-dimensionality sampling space
 \item The traceplots using this method seem to indicate that our sampler converged to the posterior.
 \item Results using this posterior showed that attempting to improve the MAP estimation using MCMC sampling actually overfit the training data and increased test RMSE. This was likely caused by the constraining of the posterior via fixed precision parameters $\alpha$, $\alpha U$ and $\alpha V$.
\end{itemize}

\href{https://gist.github.com/macks22/00a17b1d374dfc267a9a}{this gist} is a working version of a fully Bayesian implementation.
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Cool down}
\subsection{}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\frametitle{Neural Nets}
\begin{block}{Thomas Wiecki}
Has a \href{http://twiecki.github.io/blog/2016/06/01/bayesian-deep-learning/}{great blog post talking about exactly how to do this}
\end{block}

The notebook that is provided in this repo has not been significantly modified from  \href{https://github.com/twiecki/WhileMyMCMCGentlySamples/blob/master/content/downloads/notebooks/bayesian_neural_network.ipynb}{its original form}.  Although, check the original repository for the latest version.
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\begin{center}
\includegraphics[scale=0.5]{../notebooks/nn-0.png}
\end{center}
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\begin{center}
\includegraphics[scale=0.5]{../notebooks/nn-1.png}
\end{center}
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\begin{center}
\includegraphics[scale=0.5]{../notebooks/nn-2.png}
\end{center}
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\frametitle{Another take on probabilistic programming}
\footnotesize
\begin{block}{}
 Another way of thinking about this: unlike a traditional program, which only runs in the forward directions, \highlt{a probabilistic program is run in both the forward and backward direction}. It runs forward to compute the consequences of the assumptions it contains about the world (i.e., the model space it represents), but it also runs backward from the data to constrain the possible explanations. In practice, many probabilistic programming systems will cleverly interleave these forward and backward operations to efficiently home in on the best explanations.
\end{block}
\vspace{1cm}
\href{https://plus.google.com/u/0/107971134877020469960/posts/KpeRdJKR6Z1}{Why Probabilistic Programming matters? (Beau Cronin)}
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\frametitle{What did we cover again?}
\begin{block}{}
 \begin{itemize}
  \item[\checkmark] Overview
  \item[\checkmark] Coin-flip example
  \item[\checkmark] Estimating the mean and standard deviation of a Normal
  \item[\checkmark] Switchpoint analysis of text messages
  \item[\checkmark] Probabilistic matrix factorization
  \item[\checkmark] Probabilistic neural networks
  \end{itemize}
\end{block}
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame{
\frametitle{Where to go from here}
\footnotesize

Examples, examples, examples...
\begin{itemize}
 \item \href{https://github.com/pymc-devs/pymc3}{PyMC3 repo}
 \item \href{http://pymc-devs.github.io/pymc3/notebooks/getting_started.html}{Getting started guide}
 \item \href{https://github.com/CamDavidsonPilon/Probabilistic-Programming-and-Bayesian-Methods-for-Hackers}{Bayesian methods
for hackers}
  \item \href{http://twiecki.github.io}{Blog by Thomas Wiecki}
  \item \href{http://www.amazon.com/Doing-Bayesian-Analysis-Second-Edition/dp/0124058884/ref=dp_ob_title_bk}{Doing Bayesian Data Analysis by John Kruschke}
  \item \href{https://github.com/markdregan/Bayesian-Modelling-in-Python}{Resource by Mark Dregan}
\end{itemize}

There is also \href{https://github.com/stan-dev/example-models/wiki}{PyStan} (\href{http://www.stat.columbia.edu/~gelman/research/unpublished/stan-resubmit-JSS1293.pdf}{Stan paper})
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\frame[allowframebreaks]{
\frametitle{References}
\begin{tiny} \bibliography{pp.bib}
\bibliographystyle{apalike}         % Style BST file
\end{tiny}
}

\end{document}


\documentclass{article}

\usepackage[english]{babel}
\usepackage{filecontents}
\usepackage[letterpaper,top=2cm,bottom=2cm,left=3cm,right=3cm,marginparwidth=1.75cm]{geometry}

\usepackage{amsmath}
\usepackage{csquotes}
\usepackage{graphicx}
\usepackage{amsthm}
\usepackage{amsfonts}

\usepackage[colorlinks=true, allcolors=blue]{hyperref}

\usepackage{biblatex}
\begin{filecontents*}[overwrite]{general.bib}
 @article{fokkink2005simplifying,
  title={Simplifying Itai-Rodeh leader election for anonymous rings},
  author={Fokkink, Wan and Pang, Jun},
  journal={Electronic Notes in Theoretical Computer Science},
  volume={128},
  number={6},
  pages={53--68},
  year={2005},
  publisher={Elsevier}
}
\end{filecontents*}
\addbibresource{general.bib}
\nocite{*}

\usepackage{indentfirst}

\usepackage{cleveref}
\newtheorem{lemma}{Lemma}
\newtheorem{theorem}{Theorem}
\begin{document}
\section*{Itai-Rodeh Leader Election for Anonymous Rings}

\subsection*{Introduction}
Itai-Rodeh leader election algorithm is a probabilistic leader election algorithm for anonymous unidirectional rings with asynchronous communication. Additionally, the size of the ring is known to all processes.

Processes select random identities from a finite domain (of size bigger than $1$). Processes with the largest identities start another new election rounds, select new identities, and continue broadcasting messages until a leader is elected. Processes with smaller identities became passive that only pass on the messages they receive. It is assumed that the size of the ring is known to all processes so that each process can recognize its own message. The Itai-Rodeh algorithm terminates with probability one, and eventually, exactly one leader is elected. The expected number of messages is at most $O(n^2)$.

\subsection*{The algorithm}
\subsubsection*{Process $i$ maintains:}
\begin{itemize}
    \item $id_i \in \{1, \ldots , k\}$ --- random identity of a process selected anew each round
    \item $state_i \in \{active,\ passive,\ leader\}$
    \item $round_i \in \mathbb{N}^+$ --- represents the number of the current election round
    \item[$\star$] additionally process keeps track of number of the messages it sent, received and whether leader was selected to properly terminate
\end{itemize}

\subsubsection*{Message format:}
\begin{itemize}
    \item $id$ --- information about the original sender
    \item $round$ --- information about the original sender
    \item $hop$ --- distance that a message travelled
    \item $bit$ --- whether there exist identical process to the original sender (need to select new identity)
    \item[$\star$] additionally message id of the preceding process is send to properly terminate
\end{itemize}

\subsubsection*{Procedures}
Precise description can be found on page 5 in \cite{fokkink2005simplifying}. I will only describe an algorithm with words for simplicity.

\textbf{Initialization:} all processes are active, and each process pi randomly selects its identity $id_i$ and sends the message $(id_i,\ 1,\ 1,\ true)$

\textbf{Passive process:} Upon receipt of a message, passes on the message, increasing the $hop$ counter by one.

\textbf{Active process:} Upon receipt of a message $(id,\ round\ hop,\ bit)$ behaves according to the following steps:
\begin{itemize}
    \item if a process receives message from itself and $bit == true$, then becomes leader
    \item else if a process receives message from itself and $bit == false$, then selects new identity, moves to another round and sends the message $(id_i,\ round_i,\ 1,\ true)$
    \item else if a process receives a message from the identical process then passes it on with $bit == false$ and increased $hop$ counter
    \item else if the process receives a message with pair $(round,\ id)$ lexicographically bigger than itself, then it becomes passive and passes on message with increased $hop$ counter
    \item else purges the message
\end{itemize}

\clearpage

\subsection*{Correctness}
First, let's consider a simpler case in which the algorithm was lucky, and each process's identity is different. Then we would get a problem of leader election for a unidirectional ring with asynchronous communication but this time with unique identities. No $bit$ would change. No process would advance to round 2. Itai-Rodeh algorithm would be reduced to Chang and Roberts algorithm for leader selection.

In the general case, an algorithm has $round$'s and $bit$'s are tracking information about duplicate $id$'s.  On the ring, until a leader is elected there always exists a message with lexicographically largest pair $(round,\ id)$ that travels to its owner (maybe a few of them). If there exists at least one process lexicographically smaller than this message and it reaches him, then one more process will become passive bringing us a step closer to electing a leader. Otherwise, all the processes will move to the next round and with some luck, some processes will become passive. Eventually, the leader will be elected.

If there exist at least $2$ active processes in the same round and the domain of drawing identities is of size $2$ then the probability that they drew different $id$'s is at least $\frac{1}{2}$. Furthermore, the probability that a lexicographically bigger message reaches a lexicographically smaller process to make him passive is at least $\frac{1}{2}$. With a number of rounds converging on infinity probability of a single process becoming passive converges to $1$. With a finite number of processes probability of algorithm terminating equals $1$.

\subsection*{Complexity analysis}

In the worst-case scenario domain of identities equals $\{0,1\}$. Let $n$ be a number of processes. Then expected number of processes with identity $1$ in the first round equals $\frac{n}{2}$. In each following round number of active processes will be reduced by half. The expected number of rounds equals $\log n$.

All the messages that reach its owner have to travel the way around the ring. Consequently, in a round with $k$ active processes, there will be $kn$ messages.

Then the formula for an expected total number of messages throughout the algorithm will be:
$$
O\left(n\left(n + \frac{n}{2} + \frac{n}{4} + \ldots + 1 \right)\right) = O(n^2)
$$

\printbibliography

\end{document}


\section{Introduction}

This document formally defines Standard ML.

To understand the method of definition, at least in broad terms, it helps to
consider how an implementation of ML is naturally
organised.  ML is an interactive
language,\index{4.1}
and a {\sl program}\index{4.2}  consists of a sequence of {\sl top-level
declarations};\index{4.3} the execution
of each declaration modifies the top-level environment, which we call
a {\sl basis}, and reports the modification to the user.

In the execution of a declaration there are three phases:
{\sl parsing}, {\sl elaboration}, and {\sl evaluation}.
Parsing
determines the grammatical form of a declaration.  Elaboration, the
{\sl static} phase, determines whether it is well-typed and
well-formed in other ways, and records relevant type or form information
in the basis. Finally evaluation, the {\sl dynamic} phase, determines the
value of the declaration and records relevant value information in the
basis.  Corresponding to these phases, our formal definition divides
into three parts:  grammatical rules, elaboration rules, and evaluation
rules.  Furthermore, the basis is divided into the {\sl static}
basis and the {\sl dynamic} basis; for example, a variable which has been
declared is associated with a type in the static basis and with a value in
the dynamic basis.

In an implementation, the basis need not be so divided.  But for the
purpose of formal definition, it eases presentation and understanding to
keep the static and dynamic parts of the basis separate.
This is further justified by programming experience.  A large proportion
of errors in ML programs are discovered during elaboration, and identified
as errors of type or form, so it follows that it is useful to perform
the elaboration phase separately.  In fact, elaboration without
evaluation is just what is normally called {\sl compilation};  once
a declaration (or larger entity) is compiled one wishes to evaluate it --
repeatedly -- without re-elaboration, from which it follows that it is
useful to perform the evaluation phase separately.

A further factoring of the formal definition is possible,
because of the structure of the language.  ML consists of a lower level
called the {\sl Core language} (or {\sl Core} for short), a middle level
concerned  with programming-in-the-large called {\sl Modules},
and a very small upper level called {\sl Programs}.
With the three phases described above, there is therefore
a possibility of nine components in the
complete language definition. We have allotted one section to each
of these components, except that we have combined the parsing,
elaboration and evaluation of Programs in one section. The
scheme for the ensuing seven sections is therefore as follows:

\vspace*{3mm}
\begin{tabular}{rccc}
                & {\em Core} & {\em Modules} & {\em Programs} \\
\cline{2-4}
{\em Syntax}    &\multicolumn{1}{|c}{Section 2}
                             &\multicolumn{1}{|c}{Section 3}
                                             &\multicolumn{1}{|c|}{ }\\
\cline{2-3}
{\em Static Semantics}
                &\multicolumn{1}{|c}{Section 4}
                             &\multicolumn{1}{|c}{Section 5}
                                             &\multicolumn{1}{|c|}{Section 8}\\
\cline{2-3}
{\em Dynamic Semantics}
                &\multicolumn{1}{|c}{Section 6}
                             &\multicolumn{1}{|c}{Section 7}
                                             &\multicolumn{1}{|c|}{}\\
\cline{2-4}
\end{tabular}
\vspace*{3mm}

%The Core is
%a complete language in its own right, and its embedding in the full
%language is simple;  therefore each of the three parts of the formal
%description is further divided into two -- one for the Core, and one for
%Modules.

The Core provides many phrase classes, for programming convenience.
But about half of these classes are derived forms, whose meaning can be
given by translation into the other half which we call the
{\sl Bare} language.
Thus each of the three parts for the Core treats only the bare language;
the derived forms are treated in  Appendix~\ref{derived-forms-app}.
This appendix also contains a few derived forms for Modules.
A full grammar for the language is presented in
Appendix~\ref{core-gram-app}.

In\index{5.0} Appendices~\ref{init-stat-bas-app} and~\ref{init-dyn-bas-app}
the {\sl initial basis} is detailed.  This basis,
divided into its static and dynamic parts, contains the static and
dynamic meanings of all predefined identifiers.

The semantics is presented in a form  known as Natural
Semantics.\index{5.1}  It consists of a set of rules allowing
{\sl sentences} of the form
\[ A \vdash phrase \Rightarrow A' \]
to be inferred, where $A$ is often a basis (static or dynamic) and $A'$ a
semantic object
-- often a type in the static semantics and a value in the dynamic
semantics. One should read such a sentence as follows: ``against
the background provided by
$A$, the phrase $phrase$ elaborates -- or evaluates -- to the object
$A'$''.
Although the rules themselves are formal the semantic
objects, particularly the static ones, are the subject of a mathematical
theory which is presented in a succinct form in the relevant sections.
This theory, particularly the theory of types and signatures, will
benefit from a more pedagogic treatment in other publications; the
treatment here is
probably the minimum required to understand the meaning of the rules.

The robustness of the semantics depends upon theorems.
Usually these have been proven, but the proof is not included.
In two cases, however, they are presented as ``claims'' rather than
theorems; these are the claim of principal environments in
Section~\ref{principal-env-sec}, and the claim of principal signatures
in Section~\ref{prinsig-sec}.  We need further confirmation of our
detailed proofs of these claims, before asserting them as theorems.


\section{Elektromanyetizma}

\subimport{./}{electricalforce.tex}
\newpage
\subimport{./}{capacitors.tex}
\newpage
\subimport{./}{magneticforce.tex}
\newpage
\subimport{./}{magneticflux.tex}


\section{init\_arrays module}\label{init_arrays}

\begin{verbatim}
void initialize(array& data, char *tclname)
void initialize_offdiag(sparse_mat& interact, char *nm, int size)
\end{verbatim}

This module provides routines for initialising the model state
variables. {\tt initalize} provides a means of initialising an array
(or iarray) using a TCL handle {\tt tclname}. The Ecolab model arrays
are defined by the following code:
\begin{verbatim}
density = iarray(sum(nsp));
initialize( density,"density");
repro_rate = array(density.size);
initialize( repro_rate,"repro_rate");
mutation = array(density.size);
initialize( mutation,"mutation");
interaction = sparse_mat(density.size);
initialize( interaction.diag, "interaction(diag)" );
\end{verbatim}

Variables of type
\verb|array| or \verb|iarray| may be initialised by assigning the
following array elements:
\begin{description}
\item[list] The value of the array element is either a value, which is
copied into each element of the variable, or it is a Tcl list of
exactly \nsp\ elements, once repetitions have been expanded.
Repetition can be expressed by the syntax $n$\verb|*|{\em tcl-list},
where {\em tcl-list} may be a single value, or a list of values which
is repeated. One may also specify a range by means of the syntax {\em
low}:{\em high}[:{\em step}], where the step parameter may be
ommitted.
\item[random] if this array element is true, then the arrays values
are assigned randomly. Sub indices of this are \verb|seed|,
\verb|maxval| and \verb|minval|. The random values are allocated
uniformly in the range \verb|minval|\ldots\verb|maxval|.
\end{description}

Examples of the preceding (assuming \nsp=5, and the Ecolab model):

\begin{tabular}{lcl}
\verb|set density(list) 10| &$\Longrightarrow$& \verb|density| =
\{10,10,10,10,10\}\\
\verb|set density(list) {1,2*{2,3}}| &$\Longrightarrow$& \verb|density| =
\{1,2,3,2,3\}\\
\verb|set repro_rate(list) .1:.5:.1| &$\Longrightarrow$& \verb|repro_rate|
= \{.1,.2,.3,.4,.5\}\\
\verb|set repro_rate(random) true|\\
\verb|set repro_rate(random,seed) 10|&$\Longrightarrow$&
        \verb|repro_rate| is randomly assigned\\
\verb|set repro_rate(random,maxval) .1| & & values in the range $[-.05,.1]$\\
\verb|set repro_rate(random,minval) -.05|
\end{tabular}

{\tt initialize\_offdiag} initializes the offdiagonal components of a
{\tt sparse\_mat}. The size parameter is the dimension of the matrix.
The diagonal component of a {\tt sparse\_mat} is just an array, so can
be initialized by {\tt initialize}. In terms of Ecolab, the call is:
\begin{verbatim}
initialize_offdiag( interaction, "interaction(offdiag)", density.size);
\end{verbatim}

The offdiagonal elements of a {\tt sparse\_mat} are set by either the
\verb|random| means above, viz.
\begin{verbatim}
set interaction(offdiag,random) true
set interaction(offdiag,random,minval) -0.01
set interaction(offdiag,random,maxval) 0.01
set interaction(offdiag,random,connectivity) 3
set interaction(offdiag,random,seed) 12
\end{verbatim}
where \verb|connectivity| (default \nsp/2) is the average number of
non-zero elements in each row, or by means of the \verb|list|
mechanism. In this case three lists need to be set, \verb|row|, {\tt
col} which contain the indices of the non-zero elements and
\verb|val|, which contains the interaction strength. So the standard
predator-prey equation may be specified by:
\begin{verbatim}
set repro_rate(list) {.1 -.1}
set interaction(diag,list) {-.0001 0}
set interaction(offdiag,val) {-0.001 0.001}
set interaction(offdiag,row) {0 1}
set interaction(offdiag,col) {1 0}
\end{verbatim}


\subsection{Impact of the Assistance System on the Three Performance Parameters}
	\label{sec:resultsHypAC}
	This section presents our analysis results of the t-tests we conducted for the hypotheses groups A, B and C.
	All tests in this section used a significance level of \(\alpha = 0.05\).

	\subsubsection{Impact of the Assistance on Correctness}
		Figure~\ref{fig:AnalysisCorrectness} shows a comparison of the three different assistance levels regarding the correctness of the participants' annotations. The level with 10\% correct pre-annotations was not significantly greater than zero, whereas the level 50\% and the level 90\% assistance revealed significant results.

		\singleFig{4/analysis_correctness.png}{All three levels of assistance regarding the performance dimension correctness. The height of each bar is the mean value of the condition, the whiskers depict the standard error of the mean in both directions.}{AnalysisCorrectness}

		\paragraph{Hypothesis Ai}
		\lqq A \(10\%\) correct assistance system increases the correctness of annotations compared to annotations done without the assistance.\rqq

		There was no significant difference, \(t(21) = -0.521, p = 0.608\ (M = -0.62, SD = 5.601)\), so the null hypothesis is not rejected.

		\paragraph{Hypothesis Aii}
		\lqq A \(50\%\) correct assistance system increases the correctness of annotations compared to annotations done without the assistance.\rqq

		There was a significant difference, \(t(21) = 2.123, p = 0.046\ (M = 3.67, SD = 8.107)\), so the null hypothesis is rejected at the given level of significance.

		\paragraph{Hypothesis Aiii}
		\lqq A \(90\%\) correct assistance system increases the correctness of annotations compared to annotations done without the assistance.\rqq

		There was a significant difference, \(t(21) = 4.367, p < 0.001\ (M = 6.05, SD = 6.502)\), so the null hypothesis is rejected at the given level of significance.

	\subsubsection{Impact of the Assistance on Tempo}
		Figure~\ref{fig:AnalysisTempo} shows a comparison of the three different assistance levels regarding the tempo of the participants. The level with 10\% correct pre-annotations was not significantly less than zero, whereas the level 50\% and the level 90\% assistance revealed significant results.

		\singleFig{4/analysis_tempo.png}{All three levels of assistance regarding the performance dimension correctness. The height of each bar is the mean value of the condition, the whiskers depict the standard error of the mean in both directions.}{AnalysisTempo}

		\paragraph{Hypothesis Bi}
		\lqq A \(10\%\) correct assistance system decreases the average time needed for one annotation compared to annotations done without the assistance.\rqq

		There was no significant difference, \(t(21) = 0.762, p = 0.454\ (M = 0.51, SD = 3.161)\), so the null hypothesis is not rejected.

		\paragraph{Hypothesis Bii}
		\lqq A \(50\%\) correct assistance system decreases the average time needed for one annotation, compared to annotations done without the assistance.\rqq

		There was a significant difference, \(t(21) = -2.151, p = 0.043\ (M = -1.65, SD = 3.608)\), so the null hypothesis is rejected at the given level of significance.

		\paragraph{Hypothesis Biii}
		\lqq A \(90\%\) correct assistance system decreases the average time needed for one annotation compared to annotations done without the assistance.\rqq

		There was a significant difference, \(t(21) = -6.416, p < 0.001\ (M = -1.93, SD = 1.412)\), so the null hypothesis is rejected at the given level of significance.

	\subsubsection{Impact of the Assistance on Misses}
		Figure~\ref{fig:AnalysisMisses} shows a comparison of the three different assistance levels regarding the miss rate of the participants. The level with 10\% correct pre-annotations was not significantly less than zero, whereas the level 50\% and the level 90\% assistance revealed significant results.

		\singleFig{4/analysis_misses.png}{All three levels of assistance regarding the performance dimension misses. The height of each bar is the mean value of the condition, the whiskers depict the standard error of the mean in both directions.}{AnalysisMisses}

		\paragraph{Hypothesis Ci}
		\lqq A \(10\%\) correct assistance system decreases the miss rate per block compared to annotating a block of text done without the assistance.\rqq

		There was no significant difference, \(t(21) = -1.176, p = 0.252\ (M = -1.55, SD = 6.176)\), so the null hypothesis is not rejected.

		\paragraph{Hypothesis Cii}
		\lqq A \(50\%\) correct assistance system decreases the miss rate per block compared to annotating a block of text done without the assistance.\rqq

		There was a significant difference, \(t(21) = -2.383, p = 0.027\ (M = -2.80, SD = 5.508)\), so the null hypothesis is rejected at the given level of significance.

		\paragraph{Hypothesis Ciii}
		\lqq A \(90\%\) correct assistance system decreases the miss rate per block compared to annotating a block of text done without the assistance.\rqq

		There was a significant difference, \(t(21) = -3.591, p = 0.002\ (M = -3.94, SD = 5.147)\), so the null hypothesis is rejected at the given level of significance.