\section{Augmenting the Stellar Grid}\label{sec:results}

We GP models for the 5D stellar grid in this section. The training data are selected from evolutionary tracks in both primary and additional girds as mentioned in Table~\ref{tab:grid}. The role of additional grid is increasing the grid resolution for evolutionary tracks with the 'hook'.
%As discussed in the previous section, the kernel function in the 'hook' area are much more complex than other regions , and hence a GP model requires more information to map the feature in this region.
The total training data includes $\sim$15,000 evolutionary tracks ($\sim$10,000,000 stellar models). Off-grid tracks are split by 50-to-50 for validating (in the training progress) and testing (after the training progress) GP models.
The section scenario is applied. For each section, we train one \textsc{Exact} GP model for each output parameter with 20,000 training and 20,000 validating data. For the testing purpose, we sample 50,000 data points in the whole{\it EEP} range. Note that we do not use models with $\tau \geq$ 20.0 Gyr, {\it [Fe/H]}$_{\rm surf} \leq$ -0.6 dex, or $T_{\rm eff} \geq$ 7000$K$ in testing dataset.

Here we summary our set up for training GP models for the stellar grid.
\begin{itemize}
\item Model Type: \textsc{Exact GP} with the section scenario
\item Kernel: Mat32 %(for all outputs)
\item Mean Function: Neural Network with 6 linear layers x 128 nodes per layer and element-wise function (Elu)
\item Likelihood Function: Gaussian Likelihood Function
\item Loss Function: Exact marginal likelihood
\item Optimiser: Adam including AMSGRAD variant
\item Early Stoping: controlled by the validating {\it EI}
\end{itemize}

\subsection{Overview of Results}

At the beginning, we train an \textsc{Exact GP} model for the whole {\it EEP} range as a standard reference. Testing errors for this model are listed in Table~\ref{tab:results}. Compared with 2D and 3D cases, testing errors remarkably rise with increasing demission. For example, {\it EI} for $T_{\rm eff}$ goes up to 46K, which is much higher than that for the 2D (16K) or the 3D model (24K).

We then train GP models with the section scenario. We gradually increase the number of sections and track down the changes in testing errors.
We find that testing {\it EI} is not significantly improved when the grid are divided by more than 10 sections. We list the testing errors for different cases in Table~\ref{tab:results}. As it shown that, testing {\it EI}s for 10-, 20-, and 100-sections cases are very close. It turns out that the 10-sections case is the most efficient strategy and we take this case as the best result. We refer this model set as GP-Grid Model here after. Following analysis are all based on it.

A overview of testing errors can also be seen in Figure~\ref{fig:5d_test_vs_input}, where we demonstrate rolling medians and rolling standard deviations of testing errors as a function of input parameters.
%
Median values are approximate along zero in most plots, indicating good agreement between GP predictions and true values.
%
The 68\% confidential intervals are generally small and do not significantly vary. However, the 95\% confidential intervals vary in large dynamic ranges and clearly depend on $M$, {\it EEP}, and $\rm {\it [Fe/H]}_{init}$. The long tails in marginal distributions are similar to what is illustrated in Figure~\ref{fig:2dtest}: GP predictions are relatively poor in some particular regions. Because the systematic uncertainty are not uniform through the parameter space, marginal error distributions do not well describe the systematic uncertainties. We hence investigate systematic uncertainty in a local scale.

\begin{table*}
	\centering
	\caption{Training and validating errors for GPR Models}
	\label{tab:results}
	\begin{tabular}{cccccccccc}
		\hline
		Model Type&Inputs&$N_{\rm Training}$ &Sampling rate &\multicolumn{5}{c}{Testing Errors (at 68/95/99.7\%)} \\
		 \hline
		 \multicolumn{4}{c}{}& $T_{\rm eff}$ &$\log g$  &$R$  &{\it [Fe/H]}$_{\rm surf}$   &$\tau$ \\
		 \multicolumn{4}{c}{}&  (K)& ($10^{-3}$dex) & ($10^{-3}R_{\odot}$)  &  ($10^{-3}$dex)  & ($10^{-2}$Gyr) \\
		 \hline
		 Exact GP & 2D & 20,000 x 1 &96\% & 1/5/11 & 1/3/8 & 2/6/14 & 0.5/2/12 &  1/3/9 \\
		 %SVGP & 2D & 2,000 x 10  &96\% & 1/5/11 & 1/4/10 & 3/7/14  & 0.3/2/14 & 1/4/10  \\
		 \hline
		 Exact GP & 3D & 20,000 x 1 & 5\% & 2/6/16 & 1/4/10 & 3/7/17 &  2/6/22 & 2/7/22 \\
		 %Exact GP (5 sections) & 3D & 20,000 x 5 & 20\% & 2/6/17 &1/4/10 & 3/7/16& 1/3/18& 2/6/19\\
		  Exact GP (10 sections) & 3D & 20,000 x 10 & 50\% & 2/5/15 &1/4/11 & 2/7/17& 1/3/20& 2/6/19\\
		% SVGP (too slow) & 3D & 2,000 x 50 & 25\% & 3/7/16 & \\
		 %SVGP (too slow)  & 3D & 5,000 x 20 & 25\% & 2/7/15 & & & & & \\
		 %GIGP (Relu + normal data)& 3D & 100K & 25\% & 2/7/14  & & & & & \\
		 %GIGP (Relu + normal data)& 3D & 200K & 50\% & 4/8/17  & & & & & \\
		 %GIGP (Relu + grid data)& 3D & 220K & 50\% & 5/10/28 & & & & & \\
		 %GIGP (elu + grid data)& 3D & 220K & 50\% & 7/12/29 & & & & & \\
		 %\hline
		 %Exact GP (multitask) & 3D & 20,000 x 1 & 5\% & memory  &  &  &   &  \\
		  \hline
		 Exact GP & 5D & 20,000 x 1 & 0.2\% & 3/9/34 & 2/5/18 & 4/11/36 & 2/7/30 & 3/9/27  \\
		 Exact GP (3 sections) & 5D& 20,000 x 3 & 0.6\% &  3/8/27 & 2/5/18 & 3/7/26 & 1/4/24 &3/7/22 \\
		 %Exact GP (3 sections) & 5D& 20,000 x 3 & 0.6\% &  2.5/7.7/27.4 & 15/45/177 & 26/73/257 & 9/42/236 &26/73/226 \\
		 Exact GP (5 sections) & 5D& 20,000 x 5 & 1\% &  2/7/25 & 1/4/15 & 3/7/24 & 1/4/21 &2/6/22 \\
		 %Exact GP (5 sections) & 5D& 20,000 x 5 & 1\% &  2.4/7.2/24.8 & 13/39/152 & 25/71/242 & 9/39/207 &21/64/215 \\
		 Exact GP (10 sections) & 5D& 20,000 x 10 & 2\% & 2/7/27  & 1/4/14 & 2/7/26 &1/4/20 & 2/6/21\\
		 %Exact GP (10 sections) & 5D& 20,000 x 10 & 2\% & 2.4/7.1/26.8  & 14/40/141 & 24/70/263 &9/37/196 & 21/64/208\\
		 Exact GP (20 sections) & 5D& 20,000 x 20 & 4\% & 2/7/26  & 1/4/14 & 2/7/27 &1/3/18 & 2/6/22 \\
		 %Exact GP (20 sections) & 5D& 20,000 x 20 & 4\% & 2.2/6.9/26.1  & 13/38/141 & 24/72/290 &9/32/182 & 19/61/218 \\
		  Exact GP (100 sections) & 5D& 20,000 x 100 & 20\% & 2/7/25  & 1/4/14 & 2/7/26 &1/3/17 & 2/6/18 \\
		 % Exact GP (100 sections) & 5D& 20,000 x 100 & 20\% & 2.2/6.7/25.8  & 13/36/157 & 23/67/283 &8/34/185 & 19/59/190\\
		 %GIGP (Elu) & 5D & 10 x10,000 & 1\% & 5/12/34 & & & & \\
		 %GIGP (Relu) & 5D & 10 x10,000 & 1\% & 6/13/47 & & & & \\
		 %GIGP & 5D &  & 2\%, 5\%, 10\%, 25\%  & memory & & & & \\
		% \hline
		 % \multicolumn{9}{c}{GP a subset of 5D data-hook}\\
		 %\hline
		 %Exact GP EEP = 0.2-0.4 & 5D & 20,000 x 1 & 1\% & 2/7/20 &&&\\
		 %Exact GP EEP = 0.3-0.4 & 5D & 20,000 x 1 & 2\% & 3/8/21  &&&\\
		 %Exact GP EEP = 0.3-0.35 & 5D & 20,000 x 1 & 3\% & 2/7/17 &&&\\
		  %Exact GP EEP = 0.3-0.32 & 5D & 20,000 x 1 & 8\% & 2/5/14 &&&\\
		 %Exact GP EEP = 0.3-0.31 & 5D & 20,000 x 1 & 16\% & 2/4/13  &&&\\
		  \hline
	\end{tabular}
\end{table*}

\begin{figure*}
	\includegraphics[width=2.0\columnwidth]{ 5d-testing_vs_inputs.pdf}
    \caption{ Roll medians and 68/95\% confidential intervals of testing errors against GP model  inputs. Black solid lines indicate the median value; grey and blue shadowes represent the 68\% and 95\% confidential interval. Testing errors of $T_{\rm eff}$, $\log g$, and $R$ mainly depend on $M$ and{\it EEP}. Metallicity error strongly depends on $M$,{\it EEP}, and {\it [Fe/H]}$_{\rm init}$, and age error has a significant correlation to{\it EEP} and {\it [Fe/H]}$_{\rm init}$. However, testing errors do not obviously relate to $Y_{\rm init}$ or $\alpha_{\rm MLT}$. }
  \label{fig:5d_test_vs_input}
\end{figure*}
%

\subsection{Mapping Systematical Uncertainties using another GP model}\label{sec:sys}

As shown in Figure~\ref{fig:5d_test_vs_input}, systematical uncertainties relate to $M$,{\it EEP}, and {\it [Fe/H]}$_{\rm init}$ but not to $Y_{\rm init}$ or $\alpha_{\rm MLT}$.  Thus, a comprehensive model can be described as a function of $M$,{\it EEP}, and {\it [Fe/H]}$_{\rm init}$. In the $M$-$EEP$-$\rm {\it [Fe/H]}_{init}$ space, we divide this 3D space into equal-size segments and examine local error distributions.
The choice of segment size matters. It needs to be small enough for only presenting the local feature, but it can not be very small so that there are not enough data points for proper statistical analysis.
%
To find an appropriate size, we apply a statistic test. The purpose of the test is to check wether the local distribution has a tail feature. The condition we apply is either the ratio between 68\% and 95\% confidential intervals less than 2.5, or the ratio between 68\% and 99.7\% confidential intervals less than 4.
%
After several attempts, we decide to divide the input range into 40 equally spaced segments for $M$, 50 for {\it EEP}, and 20 for {\it [Fe/H]}$_{\rm init}$. Hence there are 43,911 (41 x 21 x 51) gird points. We compute a rolling standard deviation for each grid point by using the data in a 3-segments (1.5 previous and 1.5 after) range across each demission. The statistic test shows that $\sim90\%$ points meeting the above condition.

We present local systematic uncertainties for $T_{\rm eff}$ ($\sigma T_{\rm eff}$) on the $M-{\it EEP}$ diagram in Figure \ref{fig:5d_sys_teff}. As it can be seen that, local $\sigma T_{\rm eff}$ values are mostly below $\sim$4K in the low-mass regions and raise up when mass is greater than 1.05$\rm M_{\odot}$. More important, there are substructures randomly appear in the parameter space.
We visually inspect local systematic uncertainties for all output parameters and find similar features.
%The substructures are expected because this is the residual of a flexible kernel function.
Because of the existence of substructures, it is not convinced to describe the systematic uncertainty with any simple mathematical expressions. We hence use another GP model (GP-SYS model here after) to map three fundamental inputs ($M$, {\it EEP}, and {\it [Fe/H]}$_{\rm init}$) to local systematic uncertainty of each output parameter.

Here we discuss how we set up the GP-SYS model.
There are 43,911 data points in total. We randomly select 32,000 data points as the training dataset and use the rest 11,311 data points as the validating dataset. Because the training data size exceeds the 20,000 limit for \textsc{Exact GP}, we use other approach for the large data sample.
%
As discussed in Section \ref{sec:gpmodel}, the SVGP framework can be applied for large data sample when the kernel function is not very complex. It hence suitable for training the systematic uncertainty. We use 10,000 inducing points which are randomly selected in the 3D space. The training data is split into 10 batches for the SVGP training.
%
We use a constant mean function and the RBF kernel because the data distribution is smooth. The variational evidence lower bound (ELBO) is adopted as the loss function. This approach is designed for when there is too much data for the exact inference. We set up Early Stopping by tracking the RMSE value of validating data. The training progress terminates when the RMSE value stops decreasing for 30 iterations.
The likelihood function and the optimiser are same as those for training GP-Grid models.
Our set up for the GP-SYS model is listed as follow.
\begin{itemize}
\item Model Type: SVGP with 10,000 inducing number.
\item Model Inputs: $M$, {\it EEP}, and {\it [Fe/H]}$_{\rm init}$
\item Model Outputs: $\sigma_{T_{\rm eff}}$, $\sigma_{\log g}$, $\sigma_{R}$, $\sigma_{\rm {\it [Fe/H]}_{surf}}$, and $\sigma_{\tau}$.
\item Training dataset: 3200 x 10 data points
\item Validating dataset: 11,311 data points
\item Kernel: RBF (for all outputs)
\item Mean Function: Constant Mean Function
\item Likelihood Function: Gaussian Likelihood Function
\item Loss Function: The variational evidence lower bound (ELBO)
\item Optimiser: Adam including AMSGRAD variant
\item Early Stoping: when validating RMSE stops decreasing for 30 iterations
\end{itemize}

\begin{figure}
	\includegraphics[width=1.0\columnwidth]{5d_sys_teff.pdf}
	\includegraphics[width=1.0\columnwidth]{5d_sys_effective_T_std_predictions.pdf}
    \caption{Local systematic uncertainty (1-$\sigma$) for $T_{\rm eff}$ on the $M - EEP$ diagram for {\it [Fe/H]}$_{\rm init}$ = 0.0. The actual distribution is on the top and GP predictions are presented at the bottom.}
  \label{fig:5d_sys_teff}
\end{figure}

We train GP-SYS models with the above method. Figure \ref{fig:5d_sys_teff} includes a comparison between the actual and the GP-trained $\sigma_{T_{\rm eff}}$. It shows that the GP-SYS model well reproduces the $\sigma_{T_{\rm eff}}$ distributions. However, it should be noted that the GP-SYS model is only a smooth approximation because the training data resolution is not sufficient enough. We examine validating errors for all five outputs and summary their average values in Table \ref{tab:sys}. For instance, the average validating error for $\sigma_{T_{\rm eff}}$ is only 0.15K. Given that the residuals are much smaller than typical observed uncertainties, they can be ignored.

\begin{table}
	\centering
	\caption{Residual of GP models for systematic uncertainty}
	\label{tab:sys}
	\begin{tabular}{lc}
		\hline
		GP output& Average Validating Errors (ABS) \\
		\hline
		$\sigma_{T_{\rm eff}}$  (K) & 0.15 \\
		$\sigma_{\log g}$  ($10^{-3}$dex)   & 0.08 \\
		$\sigma_{R}$ ($10^{-3}R_{\odot}$)   & 0.2 \\
		$\sigma_{\rm {\it [Fe/H]}_{\rm surf}}$ ($10^{-3}$dex) & 0.09 \\
		$\sigma_{\tau}$ ($10^{-2}$ Gyr)  & 0.2\\
		%$\sigma_{\Delta\nu} (\mu Hz)$ & 0.01\\
		  \hline
	\end{tabular}
\end{table}

\section{Modelling stars with GP-trained models}\label{sec:augmentation}

Now we are able to predict observable outputs with the GP-Grid model and estimate the systematical uncertainty for each prediction with the GP-SYS model. We demonstrate a GP-trained Kiel diagram comparing with the stellar grid in Figure~\ref{fig:5d_augmentation}. GP has transformed the sparse model grid into a non-sparse model set.

\begin{figure*}
	\includegraphics[width=1.3\columnwidth]{5d-au-mass.pdf}
	\includegraphics[width=0.7\columnwidth]{5d-au-mass-sys.pdf}
	%\includegraphics[width=1.2\columnwidth]{5d-au-feh.pdf}
	%\includegraphics[width=0.65\columnwidth]{5d-au-feh-sys.pdf}
	%\includegraphics[width=1.2\columnwidth]{5d-au-y.pdf}
	%\includegraphics[width=0.65\columnwidth]{5d-au-y-sys.pdf}
	%\includegraphics[width=1.2\columnwidth]{5d-au-alpha.pdf}
	%\includegraphics[width=0.65\columnwidth]{5d-au-alpha-sys.pdf}
    \caption{ Left: a GP-trained Kiel diagram compared with the stellar grid. Right: GP-predicted systematical uncertainties for all GP-trained models.}
  \label{fig:5d_augmentation}
\end{figure*}

\subsection{A GP-Trained Model Set}

Here we augment the stellar grid.
We randomly sample 5,000,000 model data points with uniform distribution for all inputs. This GP-trained model set hence includes five fundamental inputs ($M$, {\it EEP}, {\it [Fe/H]}$_{\rm init}$, $Y_{\rm init}$, and $\alpha_{\rm MLT}$), five outputs, ($T_{\rm eff}$, $\log g$,  $R$,  {\it [Fe/H]}$_{\rm surf}$, and  $\tau$), and five systematic uncertainties ($\sigma_{T_{\rm eff}}$, $\sigma_{\log g}$,  $\sigma_{R}$,  $\sigma_{\rm {\it [Fe/H]}_{\rm surf}}$, and $\sigma_{\tau}$). This model set can be downloaded at \url{a-place-for-data}.

\subsection{Modelling Fake Stars with GP-trained Models}

With the GP-trained model set, we model 1,000 fake stars to examine the accuracy of our method. Fake stars are randomly selected on off-grid tracks. To avoid the edge effect, fakes stars are selected in the range of $T_{\rm eff}$ = [4700K, 6800K], $\log g$ = [3.7, 4.6], {\it [Fe/H]}$_{\rm surf}$ = [-0.35,0.35], $M$ = [0.85,1.15], {\it EEP} = [0.05,0.95], $Y_{\rm init}$ = [0.25,0.31], and $\alpha_{\rm MLT}$ = [1.8,2.4].
%
We use four observables, i.e., $T_{\rm eff}$, $\log g$, $R$, and {\it [Fe/H]}$_{\rm surf}$, as constraints. We apply typical observed uncertainty that is $\pm$50K for $T_{\rm eff}$ (high-resolution spectroscopy), $\pm0.005$dex for $\log g$ (seismology), $3\%$ for $R$ (seismology), and $\pm0.05$dex for {\it [Fe/H]}$_{\rm surf}$ (high-resolution spectroscopy). Observed value for each constraint is calculated with true value plus a random noise which follows a Gaussian distribution. For example, we pick a model with $T_{\rm eff}$ = 5000K and generate a random noise of -25K from a Gaussian function whose standard deviation is 50K. The fake observed value is 4975$\pm$50 K.

We fit fake stars using the Maximum Likelihood Estimate (MLE) method with the original stellar grid and the GP-trained models. Note that the error term in MLE formula contents observed and systematic uncertainties given by GP-SYS models ($\sigma^{2} = \sigma_{obs}^{2} +  \sigma_{sys}^{2} $) when fitting to GP-trained models. We make marginal likelihood distribution and use the 16th, 50th, 84th percentiles to estimate a fundamental parameter and its uncertainty.
%
We present likelihood distributions of inferred stellar parameters for a representative fake star in Figure \ref{fig:fit_comparison}.
Observed constraints for this fake star are $T_{\rm eff}$ = 4926$\pm$50K, $\log g$ = 4.536$\pm$0.005, {\it [Fe/H]}$_{\rm surf}$ =  0.34$\pm$0.05, and $R$ =  0.829$\pm$0.025$R_{\odot}$. True values of fundamental stellar parameters are $M$ = 0.861$\rm M_{\odot}$, $\tau$ = 10.8Gyr, $\rm {\it [Fe/H]}_{init}$ = 0.403, $Y_{\rm init}$ = 0.281, and $\alpha_{\rm MLT}$ = 2.356.
%
Compared with the stellar grid, GP-trained model set has a completed statistical sampling and hence gives more sensible posteriors. The improvement for the age is obvious. It is under-sampled in the model grid and hence the inferred age does not actually converge. The Gird-based modelling infers an age of $7.7^{+3.2}_{-4.2}$Gyr, and GP-based modelling gives $8.3^{+2.6}_{-2.8}$Gyr. Compared with the true value (10.8 Gyr), GP determines a more accurate and precise result than the original grid.
%
For initial metallicity, initial helium fraction, and the mixing-length parameter, GP makes it possible to statistically estimate these parameters. In this example, GP determines ${\it [Fe/H]}_{\rm init}$ and $Y_{\rm init}$ values very close to true values. The mixing-length parameter is not constrained because no correlated observable is given. This comparison clearly shows the advantage of GP-based modelling. It clearly improve the sampling of a sparse grid and hence improve the accuracy and precision of estimates.

\begin{figure*}
	\includegraphics[width=1.9\columnwidth]{gp_fitting.pdf}
    \caption{Probability distributions of estimated fundamental parameters from grid-based (Top) and GP-based modelling (Bottom) for a fake star. Observed constraints for this fake star are $T_{\rm eff}$ = 4926$\pm$50K, $\log g$ = 4.536$\pm$0.005, {\it [Fe/H]}$_{\rm surf}$ =  0.34$\pm$0.05, and $R$ =  0.829$\pm$0.025$R_{\odot}$. True values of fundamental parameters are $M$ = 0.861 $\rm N_{\odot}$, $\tau$ = 10.8 Gyr, $\rm {\it [Fe/H]}_{init}$ = 0.403, $Y_{\rm init}$ = 0.281, $\alpha_{\rm MLT}$ = 2.356, which are represented by blue dashes.}
  \label{fig:fit_comparison}
\end{figure*}

We now examine the accuracy of inferred mass and age of GP-based modelling. We calculate offsets between true and estimated values and divide them by estimated uncertainties for 1,000 fake stars. If offsets form a normal distribution, it would indicate that the fitting is only affected by random noises.
%
We demonstrate this examination in Figure \ref{fig:fake_test}. Mass offsets nicely follow a normal distribution for both the grid and GP-trained models. Age differences fits a normal distribution for GP-trained models, but slightly shift by $\sim$-0.2 for the grid.
This trend consists with what is illustrate in Figure \ref{fig:fit_comparison}: the centre of probability distribution of age shifts to lower end because of the under-sampling issue. The results infer that GP-based modelling gives reasonable accurate estimates, and moreover, it fixes the systematic offsets in the original stellar grid.

\begin{figure*}
	%\includegraphics[width=1.8\columnwidth]{fake-stars-test.pdf}
	\includegraphics[width=1.8\columnwidth]{fake-stars-test-2.pdf}
    \caption{Differences between true and estimated values over estimated uncertainty of 1000 fake stars. Count distributions of offsets are demonstrated on the right side.}
  \label{fig:fake_test}
\end{figure*}


\section{Voting}

Many parameters can be changed on-the-fly via miners voting, such as instructions costs, computational cost limit per block,
block size limit, storage fee factor, block version, and so on. Voting for the block version~(so for a soft-fork)
lasts for 32 epochs~(see epoch length below), and requires more than 90 percent of the miners to vote for the change.
For less critical changes~(such as block size limit), simple majority is enough. We will further refer to the changes
of the first kind as to foundational changes, and we refer to the changes of the second kind as to everyday changes.
Per block, a miner can vote for two everyday changes and also one foundational change, with the votes to be included
into the header of the block.

To vote "Yes"~("I'm agree on the change proposed"), and also to propose change in the first block of an epoch, a miner
is publishing identifier of the change directly in the block header. To vote "No" (or avoid voting at all, which is
the same), a miner is simply writing zero value instead of a corresponding byte (another option is to provide a vote
identifier which is not being considered within the epoch).

System constants:
\begin{itemize}
\item{} Voting epoch length = 1024 blocks.
\item{} Voting epochs per foundational change = 32
\item{} Voting epochs before approved foundational change activation = 128
\end{itemize}

\subsection{Parameters table}
\label{sec:params-table}

The following table describes vote identifiers, default values (during launch), possible steps, and also minimum and maximum values.
If the step is not defined in the table, its value is defined as $\max(\lfloor current\_value / 100 \rfloor, 1)$.
If minimum value for a parameter is not defined, it equals to zero. If maximum value is not defined, it equals to
1,073,741,823.

To propose or vote for increasing a parameter, a miner is inluding a parameter identifier ($id$) into the block header.
If the miner is for decreasing parameter, he is including ($-id$) into the block header.

% DON'T EDIT THIS TABLE.
% it is auto-generated by org.ergoplatform.tools.DefaultParametersPrinter

\begin{tabular}{*{6}{l}}
    Id & Description & Default & Step & Min & Max \\
    \hline
    1 & Storage fee factor (per byte per storage period) & 1250000 & 25000 & 0 & 2500000 \\
    2 & Minimum monetary value of a box & 360 & 10 & 0 & 10000 \\
    3 & Maximum block size & 524288 & - & 16384 & - \\
    4 & Maximum cumulative computational cost of a block & 1000000 & - & 16384 & - \\
    5 & Token access cost & 100 & - & - & - \\
    6 & Cost per one transaction input & 2000 & - & - & - \\
    7 & Cost per one data input & 100 & - & - & - \\
    8 & Cost per one transaction output & 100 & - & - & - \\
    120 & Soft-fork (increasing version of a block) & - & - & - & - \\
\end{tabular}

Parameter values are to be written into extension section on first block of a voting epoch,
that is, in the extension of a block when its $height\,mod\,1024 = 0$.
Parameters for initial moment of time~$(height = 1)$ are simply hardcoded.

\subsection{Proposing a change and voting for it}

To propose a change, in the first block of a voting epoch (of $1,024$ blocks, so in a block of
$height\,mod\,1024 = 0$), a miner is posting an identifier of a vote for a change. There are three slots (three bytes)
in a block header for changes to propose, with two slots reserved for everyday changes and the third one for
proposing a softfork. Slot not occuppied by a proposal is to be set to zero. Votes could come in any order.
Examples of the bytes: $(0, 1, 120)$, $(120, -3, 0)$. In the first case, a miner is proposing to increase storage fee factor ($id:1$), and
also proposes a soft-fork ($id:120$), In the second case, a miner is proposing to decrease block size ($id:-3$), and also
 is proposing a soft-fork ($id:120$).

To vote for a proposal~(which is, again, proposed in the first block of an epoch) within the epoch, a miner is including vote identifier
into the block header. Identifiers not proposed in the first block of the epoch are ignored.

If majority of votes within an epoch are supporting an everyday change (so at least 513 blocks are containing an
identifier), a new value of the parameter should be written into the extension section of the first block of the next
epoch.

\subsection{Voting for a soft-fork}

A soft-fork happens when a protocol version supported by the network is being increased.
The protocol version is being written into every block header, with initial value during launch to be set to 1.

Semantics behind versioning is not defined ahead of time by the protocol and so up to clients and their developers.
During a soft-fork, protocol developers are able do disable some existing validation rules from~\ref{sec:validation},
while also introduce new ones.

The protocol version upgrade is to be done in the following steps:
\begin{enumerate}
    \item{} A protocol developer implements and releases a software with changed rules.
    This software may deactivate some of existing rules, while also introduce new logic.
    \item{} A miner is proposing to increase protocol version and put deactivated rules
    into extension.
    \item{} Other miners are voting within 32 epochs for the proposal
    \item{} If the soft-fork proposal is being rejected~(so if it gathers no more than $90\%$ of votes during voting period, i.e.
            no more than $\lfloor 32 * 1024 * 90 / 100 \rfloor = 29491$ votes), new voting may be proposed next epoch
            after the voting done.
    \item{} If the soft-fork proposal is being approved, activation period of 32 epochs is starting. The first block
    after the activation period is called activation height. It is prohibited to vote for a new soft-fork during the
    activation and also on the activation height. Soft-fork data is still to be
    written to corresponding extension sections~(see below) during the activation period, and on activation height.
    Block version written into extensions is to be increased from the first block of the activation period, while protocol
    version in headers is still the same. Protocol version in headers is increased from the activation height.
\end{enumerate}

To start voting for a soft-fork, a miner needs to publish the identifier $120$ in the first block of the epoch, consider,
for example, that its height is $h_s$. Next epoch, a miner should post height when start fork was proposed ($122: h_s$)
in the extension section of the block, and number of votes collected in the previous epochs $v_s$ should be written
there as well as ($121: v_s$).

Examples:

\begin{itemize}
    \item{} Assume that a vote for soft-fork is proposed in block number $1024$ (by writing a record into the extension
            with a key equals to $120$ and any value). Assume that within this epoch,
            so before block number $2048$, $500$ votes were collected. Thus a miner which is generating block
            $\#2048$ must write height when the soft-fork voting has been started in the extension section of the block
            as ($122: 1024$ key-value pair), as well as number of votes supporting the fork gathered within the epoch
            done (in form of $121: 500$). Assume that the new epoch started with the block $\#2048$ brings 600 votes for
            fork. Then a miner generating the block $\#3072$ must write down the following pairs there: $(121, 1100)$ and
            $(122, 1024)$.
    \item{} The voting is to be done on height $1024 + 1024*32 = 33792$, so the last vote could be written into the
            block $\#33791$. Block $\#33792$ still should contain correct values for votes collected and voting starting
            height.
    \item{} Lets assume that voting for the soft-fork was not successful, i.e. no more than $29491$ votes for soft-fork
            have been gathered between blocks $\#1024$~(inclusive) and $\#33792$~(exclusive). Then the next epoch block,
            so the block $\#34816$ should clear the old voting parameter values. A new voting for soft-fork may be
            started in this new epoch, so in the block $\#34816$, if the block contains a vote for the soft-fork
            (i.e. a record with key = 120 in the extension section), then the block must contain new starting height
            and votes collected values (i.e. following pairs: $(121: 0)$ and $(122: 34816)$). If there is no new voting
            started, all the parameters regarding soft-fork voting must be cleared off of the block $\#34816$.
    \item{} Now assume that the voting for the soft-fork was successful, i.e. more than $29491$ votes for soft-fork
            have been gathered between blocks $\#1024$~(inclusive) and $\#33792$~(exclusive). In this case, activation
            epoch is starting immediately after voting has been done, so on height $33792$. Activation epoch lasts for
            32 epochs, so the first block after activation period has height of $33792$. Please note that any vote
            for a soft-fork during the activation period is prohibited. Also, on a first block of a voting epoch
            soft-fork voting parameters should be written~(height when voting had been started and also number of votes
            collected). On the first block after activation, protocol version written into a block must be increased.
            The first block after activation should carry soft-fork voting parameters. The parameters must be cleared
            next epoch, so in a block $\#33792$. A new voting may be started in the block $\#33792$, similarly to the
            case of non-successful voting.
\end{itemize}


%!TEX root = main.tex

\section{Background}
\label{sec:background}

In this section, we introduce the bcrypt algorithm and outline the
computationally expensive steps to motivate the design decisions we made. The
second part gives a short overview of our two target FPGA families and their
features.

\subsection{The bcrypt password hash}
\label{sec:bcrypt}

Provos and Mazi\`{e}res published the bcrypt hash function~\cite{BCRYPT_paper}
in 1999, which, at its core, is a cost-parameterized, modified version of the
Blowfish encryption algorithm. The key concepts are a tunable cost parameter and
the pseudo-random access of a 4 KByte memory. bcrypt is used as the default
password hash in OpenBSD since version 2.1~\cite{BCRYPT_paper}. Additionally, it
is the default password hash in current versions of Ruby on Rails and PHP.

\begin{figure*}[tb] \centering
\removelatexerror
\begin{minipage}{.45\linewidth}
\begin{algorithm2e}[H]
	\KwIn{cost, salt, key}
	\KwOut{state}
	$state \leftarrow$ InitState$()$\;
	$state \leftarrow$ ExpandKey$(state, salt, key)$\;
	\KwSty{Repeat} ($2^{cost}$) \Begin{
		$state \leftarrow$ ExpandKey$(state, 0, salt)$\;
		$state \leftarrow$ ExpandKey$(state, 0, key)$\;
	}
	\KwRet{$state$}\;
	\caption{EksBlowfishSetup}
	\label{alg:eksblowfishsetup}
\end{algorithm2e}
\end{minipage}
	\hspace{0.5cm}
\begin{minipage}{.45\linewidth}
\begin{algorithm2e}[H]
	\KwIn{cost, salt, key}
	\KwOut{hash}
	$state \leftarrow$ EksBlowfishSetup$(cost,salt,key)$\;
	$ctext \leftarrow$ ``OrpheanBeholderScryDoubt''\;
	\KwSty{Repeat} ($64$) \Begin{
		$ctext \leftarrow$ EncryptECB$(state, ctext)$\;
	}
	\KwRet{Concatenate$(cost,salt,key)$}\;
	\caption{bcrypt}
	\label{alg:bcrypt}
\end{algorithm2e}
\end{minipage}
\end{figure*}

bcrypt uses the parameters \textit{cost}, \textit{salt}, and \textit{key} as
input. The number of executed loop iterations is exponential in the
\textit{cost} parameter, \cf Algorithm~\ref{alg:eksblowfishsetup}
(\texttt{EksBlowfishSetup}). The computation is divided into two phases: First,
Algorithm~\ref{alg:eksblowfishsetup} initializes the internal state, which has
the highest impact on the total runtime. Afterwards, Algorithm~\ref{alg:bcrypt}
(\texttt{bcrypt}) encrypts a fixed value repeatedly using this state.

In its structure, bcrypt makes heavy use of the Blowfish encryption function.
This is a standard 16-round Feistel network, which uses SBoxes and subkeys
determinded by the current $state$. Its blocksize is 64-bit and during every
round, an f-function is evaluated: it uses the 32-bit input as four 8-bit
addresses for the SBoxes and computes $(S_0(a) + S_1(b)) \oplus S_2(c) + S_3(d)$
%
\texttt{EksBlowfishSetup} is a modified version of the Blowfish key schedule. It
computes a state, which consists of 18 32-bit subkeys and four SBoxes -- each
256 $\times$ 32 bits in size -- which are later used in the encryption process.
The state is initially filled with the digits of $\pi$ before an
\texttt{ExpandKey} step is performed: After adding the input key to the subkeys,
this step successively uses the current state to encrypt blocks of its
\textit{salt} parameter and updates it with the resulting ciphertext. In this
process, \texttt{ExpandKey} computes 521 Blowfish encryptions. If the salt is
fixed to zero, the function resembles the standard Blowfish key schedule. An
important detail is that the input key is only used during the very first part
of the \texttt{ExpandKey} steps. \texttt{bcrypt} finally uses
\texttt{EncryptECB}, which is effectively a Blowfish encryption.

\subsection{Special-Purpose Hardware}
\label{sec:special-hardware}

While general-purpose hardware, \ie CPUs, offers a wide variety of instructions
for all kinds of programs and algorithms, usually only a smaller subset is
important for a specific task. More importantly, the generic structure and
design of the architecture might impose restrictions and become cumbersome, \ie
when registers are too small or memory access latency becomes a bottleneck.
Reconfigurable hardware like FPGAs and special-purpose hardware like ASICs are
far more specialized -- they are dedicated to a single task.

An FPGA consists of a large area of programmable logic resources (the fabric),
\eg lookup tables (LUTs), shift registers, multiplexers and storage elements,
and a fixed amount of dedicated hardware modules, \eg memory cores (BRAM),
digital signal processing units or even processor hardcores, and can be
specialized for a given task.
%
In this work, we target two different Xilinx FPGA families. The main platform is
zedboard, more precisely its Zynq-7000 XC7Z020 FPGA. It is located in the
low-power low-cost segment. The second target is the Virtex-7 XC7VX485T FPGA
which is a high-performance device.

The Zynq-7000 consists mainly of a dual-core ARM Cortex A9 CPU, while the fabric
area and resources are comparable to an Xilinx Artix-7 FPGA. The zedboard allows
easy access to the logic inside the fabric and memory modules via direct memory
access and provides several interfaces, \eg AXI4, AXI4-Stream, AXI4-Lite or
Xillybus. It is a good choice for hardware/software co-design and in the context
of this work provides a self-contained system including complex means for
password generation and fast hardware designs. The Virtex-7 on the other hand,
offers a five times larger fabric area and seven times more memory cores at the
cost of more power consumption and a higher device price.


\section{Appendix 3: $\textrm{Set_target}$ update}

\begin{figure}[h]
\begin{center}
	\scriptsize{
	\begin{python}
# Determine the local (wrt positioner centre) coordinates for the
# target.
self.x_fibre_local = self.x_fibre_focal - self.x_centre_focal
self.y_fibre_local = self.y_fibre_focal - self.y_centre_focal
(self.r_fibre_local, self.theta_fibre_local) = util.cartesian_to_polar(self.x_fibre_local, self.y_fibre_local)

if fiber == 1:
	(self.r_fibre_local, self.theta_fibre_local) = (self.r_fibre_local + param.R_CORRECTION_IR, self.theta_fibre_local + param.THETA_CORRECTION_IR)
elif fiber == 0:
	(self.r_fibre_local, self.theta_fibre_local) = (self.r_fibre_local + param.R_CORRECTION_VISIBLE, self.theta_fibre_local + param.THETA_CORRECTION_VISIBLE)
elif fiber == -- 1:
	(self.r_fibre_local, self.theta_fibre_local) = (self.r_fibre_local + param.R_CORRECTION_CALIBRATION, self.theta_fibre_local + param.THETA_CORRECTION_CALIBRATION)
	\end{python}
	}
	\caption{Code modifying the position targeted by the actuator, as function of the fiber used.}
	\label{fig:appendix:set_target:position}
\end{center}
\end{figure}

\begin{figure}[h]
\begin{center}
	\scriptsize{
	\begin{python}
positioner_IR = False
positioner_fiducial = False
positioner_empty = False

for item in circles_test.IR:
	if positioner == item:
		positioner_IR = True

for item in circles_test.fiducial:
	if positioner == item:
		positioner_fiducial = True

for item in circles_test.empty:
	if positioner == item:
		positioner_empty = True

if fiber == 1 and positioner_IR == False:
	return False

if positioner_fiducial == True:
	return False

if positioner_empty == True:
	return False
	\end{python}
	}
	\caption{Code ensuring that Empty and Fiducial can not be set on any target, and that only IR actuator can be set on target desired to be surveyed with an IR fiber.}
	\label{fig:appendix:set_target:attribution}
\end{center}
\end{figure}


\subsection*{Concurrency Support}
\label{conc_supp}
The following concurrency support is provided:

\begin{itemize}
\item \(\texttt{concurrent\_execute(}\texttt{f}_\texttt{1}, \cdots \texttt{f}_\texttt{n}\texttt{)}\): \(\textit{primitive}\), setup multiple threads for concurrent execution. For each nullary function \(\texttt{f}_\texttt{i}\) that returns \texttt{undefined}, setup a thread \(\texttt{t}_\texttt{i}\) that executes the code in the body of \(\texttt{f}_\texttt{i}\). The thread that called \texttt{concurrent\_execute} also executes concurrently with all \(\texttt{t}_\texttt{i}\). Returns \texttt{undefined}. This is an atomic operation.
\item \texttt{test\_and\_set(p)}: \(\textit{primitive}\), assumes the head of pair \texttt{p} is a boolean \(b\). Sets the head of \texttt{p} to \texttt{true}. Returns \(b\). This is an atomic operation.
\item \texttt{clear(p)}: \(\textit{primitive}\), sets the head of pair \texttt{p} to \texttt{false}. Returns \texttt{undefined}. This is an atomic operation.
\end{itemize}


\section{Examples from Euler-Lagrange}


% ---------------------------------------------------------
% Project: PhD KAPPA
% File: results.3.tex
% Author: Andrea Discacciati
%
% Purpose: Paper III (results)
% ---------------------------------------------------------

\section{Paper III}

In this paper we reviewed the definition of RAP and its estimation,  and critically discussed certain misinterpretations appeared in the epidemiologic literature. Furthermore, we showed how RAP estimation is sensitive to the specification of the age-disease association.

\subsection{Misinterpretations of risk and rate advancement periods}

We identified three major misinterpretations of RAP: first, equating RAP with the difference in mean survival times; second, interpreting RAP as the time by which the survival curve for the exposed individuals is shifted compared with that for the unexposed; third, equating the RAP to a simple ratio of two logRRs.

\subsubsection{RAP as a difference in mean survival time}

The most common misinterpretation of RAP equates it with difference in mean survival time. The two are, however, profoundly different quantities and using the former to estimate the latter will inevitably lead to flawed conclusions.

Definition of RAP is given in equation (\ref{eq:definitionrap}) and is interpreted as the difference in baseline age at which exposed individuals ($e_1$) reach the same rate of the disease as unexposed individuals ($e_0$), under the assumption of a monotonic increase in event rate over age and conditional on disease-free survival to some baseline age.

Mean survival time, on the other hand, equals the area under the survival curve \citep{muldowney_darth_2012}. Consequently, difference in mean survival time between unexposed and exposed individuals is defined as:
\begin{equation*}
\mu_{e_0} - \mu_{e_1} = \int_0^{+\infty} S(t|e_0) dt - \int_0^{+\infty} S(t|e_1) dt,
\end{equation*}
and is interpreted as the difference in the mean (expected) survival time between unexposed and exposed subjects.

\begin{table}[]
\begin{center}
\caption[Data from an hypothetical cohort study of 20 individuals followed up for 36 months]{Data from an hypothetical cohort study of 20 individuals (10 exposed and 10 unexposed) followed up for 36 months}
\label{table:examplesurvival}
\begin{adjustbox}{max width=\textwidth}
\begin{threeparttable}
\begin{tabular}{l|c|cccccccccc}
 \hline
 Unexposed & Follow-up (months)\tnote{a} & 6 & 6+ & 7 & 11+ & 16 & 16 & 19+ & 22 & 23 & 36 \\
 \cline{2-12} & Baseline age (years)  & 67 & 65 & 58 & 61 & 67 & 62 & 50 & 58 & 47 & 52 \\ \hline \hline
 Exposed & Follow-up (months)\tnote{a} & 1 & 4+ & 5 & 6 & 6+ & 6 & 11 & 12+ & 15 & 22 \\
 \cline{2-12} & Baseline age (years) & 61 & 67 & 58 & 49 & 52 & 56 & 50 & 49 & 51 & 57 \\ \hline
\end{tabular}
\begin{tablenotes}
\item [a]\footnotesize + indicates a censored observation.
\end{tablenotes}
\end{threeparttable}
\end{adjustbox}
\end{center}
\end{table}

Table \ref{table:examplesurvival} reports synthetic data from an hypothetical cohort study with 10 exposed an 10 unexposed participants, including age at baseline in years, followed up for 36 months. Fitting a Cox PH model to these data, with baseline age and exposure as covariates, resulted in an estimated $\widehat{\RAP}= 1.594 / 0.109 = 14.6$ years, as per equation (\ref{eq:para_rap}). Thus, under the model, we would expect exposed subjects to experience the same disease rate as that among unexposed subjects who were 14.6 years older at baseline.

To calculate difference in survival time for the same data, we estimated the two survival curves from the PH model previously fitted, one for exposed and one for unexposed subjects, fixing baseline age to the sample mean (57 years) [equation (\ref{eq:phmodelssurv})]. The estimated difference in mean survival between exposed and unexposed was equal to 9.2 months. Therefore, under the model, we would expect the exposed subjects to live 9.2 months less as compared with the unexposed subjects. This means that if one were to employ RAP to estimate mean--survival difference, one would overestimate the latter by more than 13 years or, equivalently, over 19-fold.

There are other distinctions between RAP and difference in mean survival time that are worth to be mentioned. First, the estimated RAP can be larger than the maximum follow-up time, while the difference in mean survival must by definition be smaller than the largest follow-up time. Second, mean survival can be estimated only if one observes the upper tail of the survival distribution, which is often not the case due to censoring. This is true unless one is willing to assume some parametric distribution for the p.d.f. of survival time $T$ and then extrapolate the survival curve beyond the observed follow-up period. Third, the unit of measurement of RAP is only determined by that of baseline age, and has nothing to do with the unit of measurement of follow-up time. This means that if in table \ref{table:examplesurvival} the follow-up times were days instead of months,  RAP would still be 14.6 years, but the difference in mean survival time would become 9.2 days.

\subsubsection{RAP as a shift of the survival curve}

RAP has been interpreted as ``by how many months or years the survival curve among the exposed is `advanced' or brought forward compared with the survival curve among the unexposed'' \citep{brunekreef_brave_2007}. However, under PH, RAP is the difference in baseline age for which the survival curve for the unexposed individuals is equal to the survival curve for the exposed individuals, given that all other covariates are kept constant. In other words, RAP is the difference in baseline ages $a_0-a_1$ such that $S(t|e_0,a_0,\textbf{c})=S(t|e_1,a_1,\textbf{c})$.

In fact, under PH, equation (\ref{eq:phmodelssurv}) holds and by taking the complementary log-log transformation of $S(t|e,a,\mathbf{c})$, one obtains
\begin{equation*}
\log \left[-\log\left[S(t|e,a,\mathbf{c})\right]\right]=\log\left[-\log\left[S_0(t)\right]\right] + \beta_1 e + \beta_2  g(a) + \sum_{i=1}^k \beta_{i+2}  c_i,
\end{equation*}
from which equation (\ref{eq:rapsimplified}) immediately follows.

RAP can therefore be equally defined as the difference in baseline age by which a group of \mbox{$e_1$-exposed} subjects experiences the same survival as $e_0$-exposed subjects, assuming a strictly increasing disease rate over age and disease-free survival to baseline age.

\subsubsection{RAP as a concept similar to relative risk}

RRs measure the association between an exposure and the occurrence of a disease. Although they may vary with age, they do not conceptually depend on age. RAP, on the other hand, are not measures of association in the traditional sense, but rather they measure the exposure dependence of a relation between age and disease. As \citet{brenner_risk_1993} pointed out ``given a fixed magnitude of the exposure-disease association, risk or rate advancement periods are inversely related to the age gradient of disease risk or rate''. In particular, even strong exposure-disease associations can be dominated by the age effect, depending on the strength of the age disease association, resulting in short advancement periods.

To illustrate this point, imagine two diseases, $d_1$ and $d_2$, whose rates $h_1(a,e)$ and $h_2(a,e)$ are functions of a binary exposure $e$ and age at baseline $a$ (measured in years). In particular, $h_1(a,e)=k_1  4^e  a^5$ and $h_2(a,e)=k_2  1.1^e  a^{1/5}$, where $k_1$ and $k_2$ are baseline rates, possibly depending on follow-up time. The exposure-disease association is stronger for $d_1$ (RR = 4) than for $d_2$ (RR = 1.1), at any given baseline age. After logarithmic transformation of these models, the RAP for $d_1$ is found from
\begin{equation*}
\log\left( k_1 \right) + 5 \log\left(a_0\right) = \log \left(k_1\right) + \log\left(4\right) + 5 \log\left(a_1\right),
\end{equation*}
which gives $(4^{1/5}-1)a_1=0.32 a_1$; similarly, RAP for $d_2$ is $(1.1^{1/5}-1)a_1=0.61 a_1$ [see equation (\ref{eq:para_log_rap})]. Therefore, RAP is greater for $d_2$ than for $d_1$ at any baseline age, despite the RR being higher for $d_1$ than for $d_2$.

This simple example shows the fact that strong associations --- that is, large RRs --- need not lead to a large RAP, or vice versa. RAP thus provide a different perspective on RRs and shows that even exposures that are strongly positively associated with the occurrence of the disease  may not turn out to be important from a public-health point of view, if what they do is to shift a very steep age-incidence curve by a short time period.

\subsection{Misspecification of the age-disease association}

Estimation of RAP is particularly sensitive to the form of the age-disease dependence $g(a)$ in the rate or risk model. This means that if the true association between the occurrence of the disease and baseline age is non-linear, including age in the model as a linear term ($g(a)=a$) can severely bias the RAP estimates.

Suppose for example that the risk $r$ of a disease $d$ follows the logistic model
\begin{equation}
\logit(r)= -10 + \log\left(2\right)e + 2 \log\left(a\right).
\label{eq:logisticrap}
\end{equation}

From equation (\ref{eq:para_log_rap}), RAP at baseline age $a_1$ is equal to $0.414a_1$, so that, between baseline ages of, say, 45 and 80 years, RAP increases from 11.7 to 20.8 years.

To assess the bias deriving from misspecifying the functional form of age, we carried out a simulation from a population in which exposure $e$ followed a Bernoulli(0.5) distribution, baseline age $a$ followed a Uniform(45,80) distribution (independent of $e$), and $d$ was randomly generated from the logistic model (\ref{eq:logisticrap}). Taking 2,000 samples of size 500 each, we estimated RAP from the misspecified logistic model $\logit(r)= \beta_0 + \beta_1 e + \beta_2 a.$ The mean and median simulated RAP estimates were 25.4 and 21.5 years, constant over baseline age, not even in the correct range --- that is, between 11.7 and 20.8 years. Figure \ref{fig:rap_kd} shows the distribution of the 2,000 RAP estimates from the misspecified model.

\begin{figure}[]
\centering
\includegraphics[width=.7\linewidth]{figures/rap_kd.pdf}
\caption[Distribution of biased RAP estimates due to model misspecification in a simulation study]{Distribution of 2,000 RAP estimates from the misspecified logistic model in the simulation study. The dashed vertical line indicates the mean of the distribution (25.4 years), while the solid vertical line indicates the median (21.5 years).}
\label{fig:rap_kd}
\end{figure}

\subsection{Body mass index and prostate cancer mortality rate advancement period}
\label{sec:example_rap_bmi}

Using the updated COSM data presented in section \ref{section:updated_paper1}, we observed no evidence of non-linearity between baseline age and prostate cancer MR ($p_{\textrm{non-linearity}}=0.18$) and, at the same time, the assumption of monotonicity in the age-disease association seemed to hold (data not shown).

Based on equation (\ref{eq:para_rap}), the RAP comparing obese men at baseline ($\ge 30$ \kgmsq) with normal-weight men (21.0--22.9 \kgmsq) was equal to 18 months. Therefore, under the model, one would expect obese men to experience the same prostate cancer MR as that among normal-weight men who were 18 months older at baseline. The RAP for every 5-unit increment in BMI was equal to 8 months.

Even if there was not enough evidence to reject the linearity assumption in the age-disease relation, the sensitivity of the previous estimates was examined by modeling age with a natural logarithm transform [equation (\ref{eq:para_log_rap}) for RAP applies]. The RAP comparing obese men ($\ge 30$ \kgmsq) with normal-weight men (21.0--22.9 \kgmsq) was equal to 11 months for  men aged 45 years old at baseline and 17 months for  men aged 70 years old. The RAP for every 5-unit increment in BMI increased linearly from 5  to 7 months for men aged 45 and 70 years old, respectively. This, again, illustrates the high sensitivity of RAP to the form of the age-disease dependence.


\documentclass[slidestop]{beamer}

\title{NGS barcodes}
\providecommand{\myConference}{NGS work discussion}
\providecommand{\myDate}{Wednesday, 5 June 2013}
\author{Jeroen F. J. Laros}
\providecommand{\myGroup}{Leiden Genome Technology Center}
\providecommand{\myDepartment}{Department of Human Genetics}
\providecommand{\myCenter}{Center for Human and Clinical Genetics}
\providecommand{\lastCenterLogo}{
  \raisebox{-0.1cm}{
    \includegraphics[height = 1cm]{lgtc_logo}
    %\includegraphics[height = 0.7cm]{ngi_logo}
  }
}
\providecommand{\lastRightLogo}{
  %\includegraphics[height = 0.7cm]{nbic_logo}
  %\includegraphics[height = 0.8cm]{nwo_logo_en}
  %\hspace{1.5cm}\includegraphics[height = 0.7cm]{gen2phen_logo}
}

\usetheme{lumc}

\begin{document}

% This disables the \pause command, handy in the editing phase.
%\renewcommand{\pause}{}

% Make the title page.
\bodytemplate

% First page of the presentation.
\section{Introduction}
\begin{frame}
  \frametitle{Barcoding}

  Idea:
  \begin{itemize}
    \item Add a sequence to identify a sample.
    \begin{itemize}
      \item Usually in the adapter.
    \end{itemize}
    \item Use this sequence to \emph{demultiplex} a dataset.
  \end{itemize}
  \bigskip
  \pause

  Characteristics:
  \begin{itemize}
    \item No ``difficult sequences'':
    \begin{itemize}
      \item Mononucleotide stretches.
      \item \bt{GC}-content.
    \end{itemize}
    \item Sequencing error correction.
    \begin{itemize}
      \item A barcode must have a distance of at least $3$ to all others.
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Edit distance (or Levenshtein distance)}
  \[
    \mathrm{lev}_{a, b}(i, j) =
    \begin{cases}
      \mathrm{max}(i, j) & \hspace{-2.25cm}\mathrm{if\ min}(i, j) = 0,\\
      \mathrm{min}
      \begin{cases}
        \mathrm{lev}_{a, b}(i - 1, j) + 1\\
        \mathrm{lev}_{a, b}(i, j - 1) + 1 & \mathrm{otherwise.}\\
        \mathrm{lev}_{a, b}(i - 1, j - 1) + [a_i \neq b_j]\\
      \end{cases}
    \end{cases}
  \]
  \bigskip

  Allows for insertions, deletions and substitutions.
  \bigskip
  \pause

  Example (distance = 3):
  \begin{center}
    \bt{%
      GATCGGACC-G\\
      | |||| || |\\
      G-TCGGTCCCG\\
    }
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{Hamming distance}
  \[
    \mathrm{ham}_{a, b} = \sum_{i = 0}^{|a|} [a_i \neq b_i]
  \]
  \bigskip

  Only allows for substitutions.
  \bigskip
  \pause

  Example (distance = 5):
  \begin{center}
    \bt{%
      GATCGGACCG\\
      | \ \ | \ |||\\
      GTCGGTCCCG\\
    }
  \end{center}
\end{frame}

\section{Barcode design}
\begin{frame}[fragile]
  \frametitle{The \bt{barcode} package}

  Tool kit for:
  \begin{itemize}
    \item Creating barcodes.
    \begin{itemize}
      \item Specify length.
      \item Maximum mononucleotide stretch length.
      \item Minimum distance to other barcodes.
      \begin{itemize}
        \item Edit distance.
        \item Hamming distance.
      \end{itemize}
    \end{itemize}
    \pause
    \item Checking barcode lists.
    \begin{itemize}
      \item Check the distance constraint.
      \begin{itemize}
        \item Edit distance.
        \item Hamming distance.
      \end{itemize}
    \end{itemize}
  \end{itemize}
  \bigskip
  \pause

  \begin{lstlisting}[language=bash]
    pip install barcode
  \end{lstlisting}
\end{frame}

\section{Checking existing lists}
\begin{frame}
  \begin{table}[]
    \begin{center}
      {\small
        \begin{tabular}{lrr}
          name            & total & removed\\
          \hline
          FlexSel         &  10   &  2\\
          MID             & 151   &  0\\
          MP\_index       &  48   & 30\\
          NexteraCustom   &  12   &  2\\
          Nextera         &  12   &  2\\
          PB              &  11   &  1\\
          SAGE            &  12   &  2\\
          smallRNA\_new   &   6   &  1\\
          smallRNA\_old   &   5   &  0\\
          SOL-MP-L        &  12   &  1\\
          SrekNeo         &   8   &  0\\
          TruSeq          &  12   &  2\\
          TruSeqSmallRNA  &  48   & 14\\
          TruSeqUni       &  12   &  0\\
        \end{tabular}
      }
    \end{center}
    \caption{Bad barcodes based on the edit distance.}
  \end{table}
\end{frame}

\begin{frame}
  \begin{table}[]
    \begin{center}
      {\small
        \begin{tabular}{lrr}
          name            & total & removed\\
          \hline
          FlexSel         &  10   &  2\\
          MID             & 151   &  0\\
          MP\_index       &  48   & 26\\
          NexteraCustom   &  12   &  0\\
          Nextera         &  12   &  0\\
          PB              &  11   &  0\\
          SAGE            &  12   &  2\\
          smallRNA\_new   &   6   &  0\\
          smallRNA\_old   &   5   &  0\\
          SOL-MP-L        &  12   &  0\\
          SrekNeo         &   8   &  0\\
          TruSeq          &  12   &  0\\
          TruSeqSmallRNA  &  48   &  1\\
          TruSeqUni       &  12   &  0\\
        \end{tabular}
      }
    \end{center}
    \caption{Bad barcodes based on the Hamming distance.}
  \end{table}
\end{frame}

\section{Conclusions}
\begin{frame}
  \frametitle{Be careful with barcodes}

  Only the ``MID'' set seems to be usable for 454 and Ion Torrent.
  \bigskip
  \pause

  Make sure to use the \emph{Hamming distance} when demultiplexing Illumina
  data.
  \bigskip
  \pause

  For the following sets, do not use error correction:
  \begin{itemize}
    \item FlexSel.
    \item MP\_index.
    \item SAGE.
    \item TruSeqSmallRNA.
  \end{itemize}
  \bigskip
  \bigskip
  \pause

  Do not mix barcode sets, do not design them yourself.
\end{frame}

\section{Questions?}
\lastpagetemplate
\begin{frame}
  \begin{center}
    Acknowledgements:
    \bigskip
    \bigskip

  \end{center}
\end{frame}

\end{document}


\subsection{Survival functions}


\section{Problem Description}

We want to exploit the parallelism of sequential scientific Fortran code without
having to heavily modify the code itself. There are a multitude of ways to do this but
we focus on using FPGAs (Field Programmable Gate Arrays).

A FPGA is an integrated circuit that contains an array of programmable logic blocks and interconnects which
wire the blocks together. These logic blocks operate in parallel and are programmed using a Hardware Description Language(HDL)
such as Verilog or VHDL. Currently designing programs in a HDL is a tedious and error prone process, especially
as programs start to become more complex \cite{complex}.
However, code that is highly parallelizable can result in significant performance gains when synthesized to
run on a FPGA.

The main focus in research on synthesizing sequential code to HDL has been on creating compilers which generate
HDL code from C, C++, and MATLAB rather than Fortran. The goals of many of these compilers are focused on reducing programming
time and software maintenance issues rather than optimising for performance. Often, optimizing
for space and architecture optimizations requires modifying of the original source code, and are not
provided by the compilers themselves \cite{hlstools}.

There can be a multitude of ways to parallelize certain sequential code, for example consider the Fortran95 program in
listing~\ref{f95} which adds 1 to each element of a 12 element array.

\lstinputlisting[caption={F95 Loop}, label=f95, xleftmargin=4.0ex]{code/loop.f95}

Considering that each array element is independent of one another during the adding operation
it's entirely possible to perform the addition of each element in parallel. We can tune how much
we parallelize the array addition using factors of the size of the array. In this case the factors of 12 are 1, 2, 3, 4, 6, and 12.

For each factor \textbf{f} of 12 there exists a factor \textbf{f'} such that \textbf{f * f'} = 12. Let \textbf{f} be the number of
circuits and \textbf{f'} be the number of additions performed by each component, increasing \textbf{f} increases the degree of
parallelization but also increases the total area used on a FPGA board.

Given a cost model and a program we want to optimise a program with respect to the given cost model, this
involves generating equivalent variants of the given program, and then selecting the program which
gives the best result from the given model to synthesize.


We now present the structure of the protocol using notation for key material,
elliptic curve operations and
identities mostly adopted from NIST SP 800-56A Rev. 3~\cite{sp800-56a-rev3}.
%
One notable difference is that we refer to the two roles executing the protocol
as the initiator $I$ and the responder $R$.
%
We do this to avoid confusing roles with the parties taking them on.
%
Values in the analysis are subscripted with $I$ and $R$ when necessary to
distinguish which role is associated with the values.
%

%------------------------------------------------------------------------- sub
\subsection{Preliminaries}
\label{sec:preliminaries}
Private/public key pairs are written
$\langle d_{t,\mathit{id}},\,Q_{t,\mathit{id}}\rangle$,
where $d$ is the private key, $Q$ the public key, $t \in \{e, s\}$ denotes
whether the key is ephemeral or static, and $\mathit{id}$ is the role or
party controlling the key pair.
%
When irrelevant, we drop the subscript or parts thereof.
%
Ephemeral key pairs are generated fresh for each instantiation of the protocol
and static key pairs are long-term keys used for authentication.
%
Static key pairs are suitable for either regular signatures or
challenge-response signatures.
%
When a party uses regular signatures for authentication, we say that they use
the \emph{signature based authentication method}, or \mSig{} for short.
%
When a party uses challenge-response signatures for authentication, we say that
they use the \emph{static key authentication method}, or \mStat{} for short.
%
The latter naming may appear confusing since signature keys are equally static,
but is chosen to make the connection to the \mSpec{} clear.
%
We adopt the challenge-response terminology for this style of authentication
from~\cite{DBLP:conf/crypto/Krawczyk05}.
%

\mEdhoc{} relies on \mCose{}~\cite{rfc8152} for elliptic curve operations and
transforming points into bitstrings, and we therefore abstract those as
follows.
%
Signatures and verification thereof using party $A$'s key pair are
denoted \mSign{A}$(\cdot)$ and \mVf{A}$(\cdot)$ respectively.
%
The DH-primitive combining a private key $d$ and a point $P$ is denoted
$\mDH(d,P)$.
%
We abuse notation and let these function symbols denote operations on both
points and the corresponding bitstrings.
%

%------------------------------------------------------------------------- sub
\subsection{Framework Structure}
\label{sec:framework}
\mEdhoc{}'s goal is to establish an \mOscore{} security context,
including session key material \mbox{denoted \mSessKey{}}, and optionally transfer
application data \mADone{}, \mADtwo{} and \mADthree{}.
%
To accomplish this, the
\mSpec{}~\cite{our-analysis-selander-lake-edhoc-00} gives
a three-message protocol pattern, shown in Figure~\ref{fig:edhocFramework}.
%
We first describe this pattern and the parts that are common to all key
establishment methods.
%
Then we describe authentication and derivation of keys in more detail.
%
The latter is what differentiate the key establishment methods from each other.
%

\subsubsection{Protocol Pattern}
The first two messages negotiate authentication methods \mMethod{} and a
ciphersuite \mSuites{}.
%
In \mMethod{}, the initiator $I$ proposes which authentication method each
party should use.
%
These may differ, leading to four possible combinations:
\mSigSig{}, \mSigStat{}, \mStatSig{} and \mStatStat{}.
%
We refer to these \emph{combinations} of authentication methods simply as
\emph{methods} to align with the \mSpec{} terminology.
%
The first authentication method in a combination is the one proposed for the
initiator and the last is the one proposed for the responder.
%
The responder $R$ may reject the choice of method
or cipher suite with an error message, resulting in negotiation across
multiple \mEdhoc{} sessions.
%
Our analysis excludes error messages.
%

\mEdhoc{}'s first two messages also exchange connection identifiers \mCi{} and
\mCr{}, and public ephemeral keys, \mGx{} and \mGy{}.
%
The connection identifiers \mCi{} and \mCr{}, described in Section 3.1 of the
\mSpec{}, deserve some elaboration.
%
The \mSpec{} describes these identifiers as not serving a security purpose for
\mEdhoc{}, but only as aiding message routing to the correct \mEdhoc{} processing
entity at a party.
%
Despite this, the \mSpec{} states that they may be used by \mOscore{}, or other
protocols using the established security context, without restricting how they
are to be used.
%
Because \mEdhoc{} may need them in clear-text for routing, \mOscore{} cannot
rely on them being secret.
%
Section 7.1.1 of the \mSpec{} requires the identifiers to be unique.
%
Uniqueness is defined to mean that $\mCi{} \not = \mCr{}$ for a given session
and the \mSpec{} requires parties to verify that this is the case.
%
The same section also require that \mOscore{} must be able to retrieve the
security context based on these identifiers.
%
The intended usage of \mCi{} and \mCr{} by \mOscore{} is not made specific and
therefore it is not clear which properties should be verified.
%
We verify that the parties agree on the established values.
%

The two last messages provide identification and authentication.
%
Parties exchange identifiers for their long-term keys, \mIdcredi{} and \mIdcredr{},
as well as information elements, \mAuthi{} and \mAuthr{}, to authenticate
that the parties control the corresponding long-term keys.
%
The content of \mAuthi{} and \mAuthr{} depends on the authentication method
associated with the corresponding long-term key.
%
For example, if $\mMethod{} = \mSigStat{}$, the responder $R$ must either
reject the offer or provide an \mIdcredr{} corresponding to a key pair
$\langle\mPriv{R},\ \mPub{R}\rangle$ suitable for use with challenge-response
signatures, and
compute \mAuthr{} based on the static key authentication method \mStat{}.
%
In turn, the initiator $I$ must provide an \mIdcredi{} corresponding to a key
pair $\langle\mPriv{I},\ \mPub{I}\rangle$ suitable for a regular signature,
and compute
\mAuthi{} based on the signature based authentication method \mSig{}.
%

\subsubsection{Authentication}
Regardless of whether \mStat{} or \mSig{} is used to compute \mAuthr{}, a
MAC is first computed over \mIdcredr{}, \mCredr{}, a transcript hash of the
information exchanged so far, and \mADtwo{} if included.
%
The MAC is the result of encrypting the empty string with the Authenticated
Encryption with Additional Data (AEAD) algorithm from the ciphersuite
\mSuites{}, using the mentioned information as additional data.
%
The MAC key is derived from the ephemeral key material
\mGx{}, \mGy{}, \mX{} and \mY{}, where $I$
computes $\mDH(\mX,\ \mGy)$ and $R$ computes $\mDH(\mY,\ \mGx)$, both resulting in
the same output in the usual DH way.
%

In case $R$ uses the \mSig{} authentication method, \mAuthr{} is $R$'s
signature over the MAC itself and the data that the MAC already covers.
%
In case $R$ uses the \mStat{} authentication method, \mAuthr{} is simply the
MAC itself.
%
However, when using \mStat{}, the key for the MAC is derived, not only from the
ephemeral key material, but also from $R$'s long-term key
$\langle\mPriv{R},\ \mPub{R}\rangle$.
%
For those familiar with \mOptls, this corresponds to the 1-RTT semi-static
pattern computing the MAC key \textsf{sfk} for the \textsf{sfin}
message~\cite{DBLP:conf/eurosp/KrawczykW16}.
%
The content of \mAuthi{} is computed in the corresponding way for the initiator
$I$.
%
In Figure~\ref{fig:edhocFramework}, we denote a MAC using a key derived from
both $\langle\mPriv{R},\ \mPub{R}\rangle$ and $\langle\mX,\ \mGx\rangle$ by
$\mathit{MAC}_I$, and a MAC using a key derived from
both $\langle\mPriv{I},\ \mPub{I}\rangle$ and $\langle\mY,\ \mGy\rangle$ by
$\mathit{MAC}_R$.
%

Parts of the last two messages are encrypted and integrity protected, as
indicated in~\ref{fig:edhocFramework}.
%
The second message is encrypted by XORing the output of the key derivation
function HKDF (see Section~\ref{sec:keysched}) on to the plain text.
%
The third message is encrypted and integrity protected by the AEAD algorithm
determined by the ciphersuite \mSuites{}.
%

\begin{figure}
\centering
\tikzset{>=latex, every msg/.style={draw=thick}, every node/.style={fill=none,text=black}}
\begin{tikzpicture}
    \node (ini) at (0, 0) {Initiator};
    \draw [very thick] (0, -0.25) -- (0,-2.3);
    \draw [very thick] (5.75, -0.25) -- (5.75,-2.3);
    \node (res) at (5.75,0) {Responder};
    \msg{1em}{ini}{res}{\mMsgone: \mMethod, \mSuites, \mGx, \mCi, \mADone};
    \msg{3em}{res}{ini}{\mMsgtwo: \mCi, \mGy, \mCr, \{\mIdcredr, \mAuthr, \mADtwo\}};
    \msg{5em}{ini}{res}{\mMsgthree: \mCr, \{\mIdcredi, \mAuthi, \mADthree\}};
    \draw [line width=1mm] (-0.75,-2.3) -- (0.75,-2.3);
    \draw [line width=1mm] (5.75-0.75,-2.3) -- (5.75+0.75,-2.3);
    \node (padding) at (0,-2.5) {};
    \end{tikzpicture}
    \begin{tabular}{|c|c|c|}
        \hline
        \mMethod & \mAuthi & \mAuthr\\
        \hline
        \mSigSig{} & $\mSign{I}(\cdot)$ & $\mSign{R}(\cdot)$ \\
        \mSigStat{} & $\mSign{I}(\cdot)$ & $\textit{MAC}_R(\cdot)$\\
        \mStatSig{} & $\textit{MAC}_I(\cdot)$ & $\mSign{R}(\cdot)$\\
        \mStatStat{} & $\textit{MAC}_I(\cdot)$ & $\textit{MAC}_R(\cdot)$\\
        \hline
    \end{tabular}
    \caption{Structure of \mEdhoc{}: $\{t\}$ means $t$ is encrypted and integrity
protected.}
\label{fig:edhocFramework}
\end{figure}

\subsubsection{Key Schedule}
\label{sec:keysched}
At the heart of \mEdhoc{} is the key schedule depicted in
Figure~\ref{fig:kdfdiagram}.
%
\mEdhoc{} uses two functions from the \mHkdf{} interface~\cite{rfc5869} to derive keys.
%
\mHkdfExtract{}
constructs uniformly distributed key material from random input and a salt,
while \mHkdfExpand{} generates keys from key material and a salt.
%

The key schedule is rooted in the ephemeral DH key
\mGxy{}, which is computed as $\mDH(\mX, \mGy)$ by $I$ and as $\mDH(\mY, \mGx)$
by $R$.
%
From \mGxy{}, three intermediate keys \mPRKtwo, \mPRKthree{} and
\mPRKfour{} are derived during the course of protocol execution.
%
Each of them is used for a specific message in the protocol, and from
these intermediate keys, encryption and integrity keys
(\mKtwoe, \mKtwom{}, \mKthreeae, and \mKthreem) for that message are derived.
%
The salt for generating \mPRKtwo{} is the empty string.
%

The protocol uses a running transcript hash $th$, which includes the information
transmitted so far.
%
The value of the hash, denoted $th_i$ for the $i$th message, is included in key
derivations as shown in Figure~\ref{fig:kdfdiagram}.
%

Successful protocol execution establishes the session key material \mSessKey{}
for \mOscore{}.
%
\mSessKey{} can be considered a set that always includes \mGxy{}.
%
If the initiator uses the \mStat{} authentication method, \mSessKey{} also
includes
$\mDH(\mY,\ \mGi{}) = \mDH(\mPriv{I},\ \mGy)$, which we denote $P_I$.
%
If the responder uses the \mStat{} authentication method, it also includes
$\mDH(\mX,\ \mGr{}) = \mDH(\mPriv{R},\ \mGx)$, which we denote $P_R$.
%
From the session key material, a key exporter (\mEdhoc-Exporter) based on
\mHkdf{} is used to extract keys required for \mOscore{}.
%

\begin{figure*}[!h]
\centering
\scalebox{.785}{
\input{kdfdiagram.tex}
}
\caption{Key schedule: Light blue boxes hold DH keys ($P_e, P_I, P_R$),
orange boxes intermediate key material (\mPRKtwo, \mPRKthree, \mPRKfour), and
dark blue boxes keys for \mAead{} or \mXor{} encryption
(\mKtwoe, \mKtwom, \mKthreeae, \mKthreem).
Dashed boxes are conditionals.}
\label{fig:kdfdiagram}
\end{figure*}

As an illustrative example of the entire process, we refer to
Figure~\ref{fig:edhocsigstat}, which depicts the protocol pattern, operations
and key derivations for the \mSigStat{} method in more detail.
%
\begin{figure*}[ht]
\centering
\scalebox{.7}{
\tikzset{>=latex, every msg/.style={draw=thick}, every node/.style={fill=none,text=black}}
\begin{tikzpicture}
    \node (ini) at (0, 0) {Initiator};
    \draw [very thick] (0, -0.5) -- (0,-14.8);
    \draw [very thick] (9, -0.5) -- (9,-14.8);
    \node[below=0.5em of ini,fill=white] {$
    \begin{array}{c}
        \text{Knows}\ \langle\mPriv{I},\ \mPub{I}\rangle,\ \mIdcredi,\ \mIdcredr,\ \mADone,\ \mADthree
    \end{array}
    $};
    \node (res) at (9,0) {Responder};
    \node[below=0.5em of res,fill=white] {$
    \begin{array}{c}
        \text{Knows}\ \langle\mPriv{R},\ \mPub{R}\rangle, \ \mIdcredr,\ \mADtwo
    \end{array}$};
    \action{3.5em}{ini}{Generates $\mMethod,\ \mSuites,\ \mCi,\ \langle\mX{},\ \mGx\rangle$};
    \msg{6.5em}{ini}{res}{\mMsgone: \mMethod, \mSuites, \mGx, \mCi, \mADone};
    \action{7.0em}{res}{$
      \begin{array}{c}
          \text{Generates } \mCr,\ \langle\mY{},\ \mGy\rangle\\
          \ \ P_e = \mDH(\mY,\ \mGx{})\\
          \ \ P_R = \mDH(\mPriv{R},\ \mGx{})\\
        \mTHtwo = \mHash(\mMsgone, \langle \mCi, \mGy, \mCr \rangle)\\
        \mPRKtwo = \mHkdfExtract(\textrm{``\phantom{}''}, P_e) \\
        \mPRKthree = \mHkdfExtract(\mPRKtwo, P_R) \\
        \mKtwom = \mHkdfExpand(\mPRKthree, \mTHtwo) \\
        \mMactwo = \mAead(\mKtwom; \langle \mIdcredr, \mTHtwo, \mCredr, \mADtwo \rangle; \textrm{``\phantom{}''}) \\
        \mKtwoe = \mHkdfExpand(\mPRKtwo, \mTHtwo)
      \end{array}$};
    \msg{21.7em}{res}{ini}{\mMsgtwo: \mCi, \mGy, \mCr, $\overbrace{\mKtwoe\ \mXor\ \langle \mIdcredr, \mMactwo, \mADtwo \rangle}^{\mCipher}$};
    \action{22.5em}{ini}{$
      \begin{array}{c}
        %\mTHtwo = \mHash(\mMsgone, \langle \mCi, \mGy, \mCr \rangle) \
        \ P_e = \mDH(\mX,\ \mGy{})\\
        \mPRKtwo = \mHkdfExtract(\textrm{``\phantom{}''}, P_e) \\
        %\mKtwoe = \mHkdfExpand(\mPRKtwo,\mTHtwo)\\
        %\mGrx = \mCredr^{x} \\
        \ \ P_R = \mDH(\mX,\ \mPub{R})\\
        \mPRKfour = \mPRKthree = \mHkdfExtract(\mPRKtwo, P_R) \\
        %\mKtwom = \mHkdfExpand(\mPRKthree, \mTHtwo) \\
        \mKthreeae = \mHkdfExpand(\mPRKthree, \mTHtwo) \\
        \mTHthree = \mHash(\mTHtwo, \mCipher, \mCr)\\
        \mKthreem = \mHkdfExpand(\mPRKfour, \mTHthree) \\
        \mMacthree = \mAead(\mKthreem; \langle \mIdcredi, \mTHthree, \mCredi, \mADthree \rangle; \textrm{``\phantom{}''}) \\
        \mSigthree = \mSign{I}(\langle \langle \mIdcredi, \mTHthree, \mCredi, \mADthree \rangle, \mMacthree \rangle)
      \end{array}$};
    \msg{35.5em}{ini}{res}{$\mMsgthree: \mCr, \mAead(\mKthreeae; \mTHthree; \langle \mIdcredi, \mSigthree, \mADthree \rangle$)};
    \action{36em}{res}{$
    \begin{array}{c}
        \mTHthree = \mHash(\mTHtwo, \mCipher, \mCr)\\
        \mKthreem = \mHkdfExpand(\mPRKthree, \mTHthree) \\
        \mKthreeae = \mHkdfExpand(\mPRKthree, \mTHthree)
    \end{array}$};
    \draw [line width=1mm] (-2,-14.8) -- (2,-14.8);
    \draw [line width=1mm] (7,-14.8) -- (11,-14.8);
    \end{tikzpicture}
}
    \caption{The \mSigStat{} method.
    Tuples are denoted $\langle\cdot\rangle$, and the hash function \mHash{} is
    as determined by \mSuites{}.}
\label{fig:edhocsigstat}
\end{figure*}
%------------------------------------------------------------------------- sub


\section{Problem Statement}

\acrfull{lfd} is defined as a technique that develops policy from examining
state to action mappings \cite{argall_survey_2009}. The state are expressed in
terms of the features and the actions are the motion primitives. The action
causes changes in the state of the world. The world consist of the robot and
the environment.

The \acrshort{lfd} problem can be defined as follows \cite{argall_survey_2009}.

The world consist of states $S$ and actions $A$. The mapping between states by
way of actions is defined by a probabilistic transition function $T(s`|s, a) $
; $S \times A \times S \rightarrow [0,1]$. $s`$ is the resultant state due to
the execution of the action $a$ on the initial state $s$. As we all know the
world is not fully observable all the time. Only a part of the world $Z$ is
observable. The learning has to be made on the observable states $Z$.

A policy $\pi : Z \rightarrow A $ selects action based on observations of world
state. A policy determines which action $a$ to execute from $A$ based on the
observations $Z$.

The demonstrations used in our approach consist of pairs of initial state and
final state. Initial state is the state before the execution of an action while
final state is the state after the execution of the state. The demonstrations
$d$ consist of pairs of demonstrated initial state $z$ and final state $z`$
Demonstrations $d \in D$ formally as $k$ pairs of initial-final states: $d =
{(z^i , {z`}^i)} \text{where} (z^i, {z`}^i) \in Z \text{and}  i = 0,...,k$

\subsection{Deriving a policy: Goal based mapping}

In these methods of policy learning of \acrshort{lfd}, the policy tries to
predict the state of the world once the action is executed based on the current
state of the world.

The perspective adopted is that multiple demonstrations of the same action can
help to understand the key aspects of the action. In other words, when an
action shares similar goal across multiple demonstrations, it might suggest
that corresponding goal must be achieved in-order to reproduce the action. So
these methods of policy learning takes the demonstrations as input and provides
a list of goals to be satisfied as output for reproduction of the action.

This prediction is the passed to a planner who tries to find a plan to execute
the action to reach the predicted goal state as illustrated in figure \ref{goal
based learning}(\cite{argall_survey_2009})
\begin{figure}[htp]
\centering
\includegraphics[scale=0.8]{images/plans_policy_derivation.png}
\caption[Deriving a policy : goal based]{Policy Derivation by determining the
goal of the actions \cite{argall_survey_2009}}
\label{goal based learning}
\end{figure}
\subsection {Goal based mapping on relevant features}

The policy learning with the complete set of features of the observed states
faces a drawback that it requires a lot of demonstrations. So to learn on fewer
demonstrations we need to do determine the relevant features of the states and
do the policy learning only based on these relevant features.

When an action shares similar components across multiple demonstrations, it
might suggest that these components are the essential features of the state
that should be reproduced by the robot. In these methods the relevant features
$R$ of the states are determined based on the likelihoods of the
demonstrations, before the goal state prediction.

The policy learning technique first determines which are the relevant aspects
of the states for reproducing the action and these are then provided to the
predictor function which predicts the goal state as illustrated in figure
\ref{feature goal based learning}  (modified from \cite{argall_survey_2009}) .

\begin{figure}[htp]
\centering
\includegraphics[scale=0.6]{images/features_plans_policy_derivation.png}
\caption[Deriving a policy : feature based ]{Policy derivation using first
extracting relevant features and then determining the goal state of the robot
(modified from \cite{argall_survey_2009})}
\label{feature goal based learning}
\end{figure}


\documentclass{article}
\usepackage{amsmath}

\begin{document}

	\title{Cardano's Formula for Cubic Equations}
	\author{Gina Captain-Briggs}
	\date{November 18 2021
	\section{Abstract}
	     Gerolamo Cardano was born in Pavia in 1501 as the illegitimate child of a jurist. He attended the University of Padua and became a physician in the town of Sacco, after being rejected  by his home town of Milan. He became one of the most famous doctors in all of Europe, having treated the Pope. He was also an astrologer and an avid gambler, to which he wrote the Book on Games of Chance, which was the first serious treatise on the mathematics of probability |1|.
	\section{1 Introduction to Cardano's Formula}
	Cardano's formula for solution of cubic equations for an equation like;
	$ x3 + a1x2 + a2x + a3 = 0 $
	the parameters Q, R, S and T can be computed thus,
	$Q= 3a2-a2 1 /3$ $R= 9a1a2 - 27a3 -2a 3 1 / 54$ $S=3   R+   -Q3 + R2$
	$T =    R -   Q3 + R2$

	to give the roots;
	$x1 = S+T - 1/3a1$
	$x2 = -(S + T)/2 -a1/3
	$X3 =

	Note: x3 must not have a co-efficient.

	\section{1.1 Some Examples}
	\begin{list}
		x
		x
	\end{list}

\end{document}


% !TEX root = ../main.tex
\newpage
\section{Introduction} \label{sec:Introduction}
%\subsection{Motivation for this work}
In 2013, the European Union launched one of the largest funded scientific project ever. With the Human Brain Project \cite{humanbrainproject}, scientists and researchers aimed to reconstruct the human brain through supercomputer-based models and to advance neuroscience, medicine, and computing. Across the globe different fields of science are drawing inspiration from the human brain. \\

One such approach is to model the behaviour of biological neurons and to quantify the information processes in the brain from stimuli from the senses or from electrical and chemical processes in the body. A given neuron receives hundreds of impulses in the form of neurotransmitters from its neighbours, almost exclusively on its dendrites and cell body. These stimuli add up to an excitatory or inhibitory influence on the electrical membrane potential of the neuron, so that the potential \textsl{spikes} when excitation is higher than an internal threshold. This explosion of electrical activity is called the \textsl{action potential} \cite{IntroductionModelingDynamics}. At the neuron's synapse, the action potential is converted into a chemical signal again, in the form of a neurotransmitter release, and the neuron joins the interneuronal communication \cite{ActionPotentialsAndSynapses}. %Most neurons in the central nervous system use either the excitatory neurotransmitter glutamate (AMPA or NMDA) or the inhibitory neurotransmitter GABA \cite{MathFoundationNeuroscience, Zhang2012}.
We will speak of the presynaptic neuron as the neuron that sends a signal and of the postsynaptic neuron as the neuron that receives a signal. \\

%At this point, the neuron releases its own neurotransmitter and joins the interneuronal communication \cite{IntroductionModelingDynamics}.

The neuron dynamics are largely captured by this spiking behaviour, on which most efforts of finding a description have been concentrated.
In 1952, Hodgkin and Huxley formulated a mathematical model for the action potentials in neurons, using a set of nonlinear differential equations that approximates the electrical characteristics of the neuron elements. The authors were awarded the 1963 Nobel Prize in Physiology or Medicine \cite{nobel1963} for their work.\\

As the human brain contains more than 100 billion neurons \cite{Herculano2009} it is unfeasible to study complex models at this scale, setting aside the complexity of the Hodgkin-Huxley model. The topology of neuronal networks displays traits of small-worldness, wiring optimisation, and heterogeneous degree distributions \cite{Bullmore2010}, for which it is difficult to pin down one type of network architecture. Through the mean-field reduction (\MFR) \cite{OttAntonsen2008, OttAntonsen2009, OttAntonsen2010}, one can reduce a large network of indistinguishable neurons to a low-dimensional dynamical system, described by the attraction of a mean-field variable to a reduced manifold.
In this work we will study the \MFR of different types of networks of pulse-coupled Theta neurons using the recent advancements on networks with arbitrary topologies \cite{OttAntonsen2017}. \\

%\subsection{Modelling neuronal behaviour}
%Neurons communicate through electrical and chemical signals, in the form of action potentials and neurotransmitters respectively. We will speak of the presynaptic neuron as the neuron that sends a signal and of the postsynaptic neuron as the neuron that receives a signal. %When the membrane voltage of a presynaptic neuron reaches an internal threshold, the neuron \textsl{spikes} (or \textsl{fires}) and an electrical signal travels down the neuron axons \cite{IntroductionModelingDynamics}.

%As signals are converted from electrical to chemical and back, we can easily model the communication process as entirely electrical, consisting solely of action potentials. %We will use a pulse-shaped curve, modulated by a dynamic variable of the neuron (for example the phase angle for the Theta neuron). The magnitude of the response of the postsynaptic neuron can be modeled by a coupling strength. The inhibitory/excitatory behavior can be modeled by allowing a negative/positive coupling strength between neurons \cite{Luke2013, Martens2020, Montbrio2015, OttAntonsen2017}.
% Another electrical communication process occurs when current flows between neurons proportional to the difference in their membrane voltages, known as \textsl{gap junctions}. We will follow the work that has been done on pulse-shaped coupling.
%We will avoid modeling the two communication modes at the same time, due to tractability \cite{Martens2020}.

Neurons have the ability to adjust the intensity of their response to in- and outbound signals depending on their activity in a process called \textsl{synaptic plasticity}. We can observe how neurons release a different quantity of neurotransmitters, or relocate the neurotransmitter receptors. The average intensity of the response is referred to as the \textsl{synaptic strength}. Plastic changes to the brain structure are believed to be the foundation of learning and the memory. One can quantify and model these changes to the network topology using Hebbs postulate on the correlation of neuron activity in the network \cite{Hebb1949}. Changes to the network topology are easily modeled as changes to the synaptic strength.\\

The work presented here is thus two-fold:  we study the dynamics of pulse-coupled neurons \textsl{on} networks, and the dynamics \textsl{of} such networks when their topology evolves over time. First, we will treat the existing theory on neuron models, network topologies and the \MFR in detail, before investigating the synchronisation dynamics of different neuronal networks. Using the acquired knowledge, the theory on learning dynamics is examined, upon which more advanced learning models are formulated and compared to each other.


\documentclass[10pt,a4page]{article}
\usepackage{fontspec}
\usepackage{xunicode}
\usepackage{xltxtra}
\usepackage{xgreek}

\setmainfont[Mapping=tex-text]{Linux Biolinum O}

\def\parallelold{\mathbin{\|}}

% Load the package
\usepackage{gr-math}

\pagestyle{empty}

\def\arraystretch{1.3}

\begin{document}
\section*{Overview of the package \texttt{gr-math}}
\begin{enumerate}
\item \verb|gr-math| collects several mathematical functions in Greek:
  \begin{center}
    \begin{tabular}{l|l}
      \textbf{Command} & \textbf{Result} \\\hline
      \verb|\sin x| & $\sin x$ \\\hline
      \verb|\cos x| & $\cos x$ \\\hline
      \verb|\tan x| & $\tan x$ \\\hline
      \verb|\arcsin x| & $\arcsin x$ \\\hline
      \verb|\arccos x| & $\arccos x$ \\\hline
      \verb|\arctan x| & $\arctan x$ \\\hline
      \verb|\cot x| & $\cot x$ \\\hline
      \verb|\sec x| & $\sec x$ \\\hline
      \verb|\csc x| & $\csc x$ \\\hline
      \verb|\arccot x| & $\arccot x$ \\\hline
      \verb|\arcsec x| & $\arcsec x$ \\\hline
      \verb|\arccsc x| & $\arccsc x$ \\\hline
      \verb|\gcd(\nu\,,\,\mu)| & $\gcd(\nu\,,\,\mu)$ \\\hline
      \verb|\lcm(\nu\,,\,\mu)| & $\lcm(\nu\,,\,\mu)$
    \end{tabular}
  \end{center}
\item Limits.\\
  It is customary in Greek school mathematics to write $x\to x_0$ under the symbol of \verb|lim|. \verb|gr-math| offers the macro \verb|\limdisplay| for this.\\
  Thus, \verb|\limdisplay{x\to x_0}f(x)| results in $\limdisplay{x\to x_0}f(x)$.
\item Parallel lines.\\
  \LaTeX\ offers \verb|\parallel| for parallel lines: $\varepsilon_1\parallelold\varepsilon_2$. \verb|gr-math| redefines \verb|\parallel| to produce: $\varepsilon_1\parallel\varepsilon_2$.
\item A symbol for the right angle.\\
  With \verb|\hat{A} = 1\rightangle| you get $\hat{A} = 1\rightangle$.
\end{enumerate}
\end{document}


\subsection{Hyperbolic discounting}