\newcommand{\pname}{Monte Carlo}

\chapter*{Parameter confidence estimation using the Monte Carlo bootstrap algorithm}
\setcounter{chapter}{1}
\emph{Get some confidence estimates}
\section{Introduction}
The Monte Carlo plugin is used to obtain estimates of the confidence limits for a model's parameters. This is in the context where experimental data exists and a parameter minimization method, such as Levenberg-Marquardt or Nelder-Mead has already been used in order to find a parameter minimum.

The Monte Carlo algorithm is used subsequently at this minimum and will give an estimate of parameter confidence limits corresponding to the variance in the original experimental data.

The plugin has properties such as the size of the Monte Carlo population, minimization algorithm to use (e.g. Nelder-Mead or Levenberg-Marquardt), and on output, confidence limits for each involved parameter.

Plugin properties are documented in more detail in the next section.

\begin{landscape}
\section{Plugin Properties}
Available properties in the \pname\ plugin are listed in the table below.

%\begin{table}[ht]
\centering % used for centering table
\begin{longtable}{p{4cm} l p{3cm}  p{10cm}} % centered columns

Property Name & Data Type & Default Value  & Description \\ [0.5ex] % inserts table
%heading
\hline % inserts single horizontal line
SBML                            &   string              & N/A    &   SBML document as a string. Model to be used by the \pname\ plugin. \\
ExperimentalData   				&	telluriumData 		& N/A    &   Input data.  \\
InputParameterList 				&	listOfProperties    & N/A    &   Parameters to estimate confidence limits for. \\
MonteCarloParameters 			&   listOfProperties 	& N/A    &   Parameters obtained from a Monte Carlo session. \\
ConfidenceLimits				&	listOfProperties	& N/A    &   Confidence limits for each fitted parameter. The confidence limits are calculated at a 95\% confidence level. \\
Experimental\-DataSelectionList & 	stringList			& N/A    &   Selection list for experimental data. \\
FittedDataSelectionList     	& 	stringList			& N/A    &   Selection list for model data. \\
NrOfMCRuns						&   int 				& N/A    &   Number of Monte Carlo data sets to generate and use.\\
MinimizerPlugin					&   string   			& N/A    &	 Minimizer used by the Monte Carlo Engine, e.g. "Levenberg\_Marquardt". \\

\hline %inserts single line
\caption{Plugin Properties}
\label{table:nmPluginProperties}
\end{longtable}
%\end{table}

\end{landscape}

\section{The \texttt{execute(bool inThread)} function}
The \verb|execute()| function will start the \pname\ algorithm. Depending on the problem at hand, the algorithm may run for a long time.

The \verb|execute(bool inThread)|, method supports a boolean argument indicating if the execution of the plugin work will be done in a thread, or not. Threading is fully implemented in the \pname\ plugin.

The inThread argument defaults to \textbf{false}.

Each generated Monte Carlo dataset is available in a file named, MCDataSets.dat (saved in current working directory).

\section{Plugin Events}
The \pname\ plugin uses all of the available plugin events, i.e. the \emph{PluginStarted}, \emph{PluginProgress} and the \emph{PluginFinished} events.

The available data variables for each event are internally treated as \emph{pass through} variables, so any data, for any of the events, assigned prior to
the plugins execute function (in the assignOn() family of functions), can be retrieved unmodified in the corresponding event function.

\begin{table}[ht]
\centering % used for centering table
\begin{tabular}{l l p{9cm}}

Event & Arguments & Purpose and argument types \\ [0.5ex] % inserts table
%heading
\hline % inserts single horizontal line
PluginStarted  	& 	void*, void*  & Signal to application that the plugin has started. Both parameters are \emph{pass through} parameters and are unused internally by the plugin.\\[0.5ex]
PluginProgress	& 	void*, void*  & Communicating progress of fitting. Both parameters are \emph{pass through} parameters and are unused internally by the plugin. \\[0.5ex]
PluginFinished	& 	void*, void*  & Signals to application that execution of the plugin has finished. Both parameters are \emph{pass through} parameters and are unused internally by the plugin.\\

\hline %inserts single line
\end{tabular}
\caption{Plugin Events}
\label{table:MCPluginEvents}
\end{table}

\section{Python example}
The following Python script illustrates how the plugin can be used.

\begin{singlespace}
\lstinputlisting[label=MonteCarloExample,caption={\pname\ plugin example.},language=Python]{Examples/telMonteCarlo.py}
\end{singlespace}

\begin{figure}[ht]
\centering
\includegraphics[width=\textwidth]{MonteCarloOutput.png}
\caption{Output for the example script above, using 1000 Monte Carlo runs. The histogram shows the distribution for the model parameter, 'k1'. The mean for the distribution was 0.980 and  obtained confidence limits were +/- 0.001.}
\label{fig:mcFig}
\end{figure}


\subsection{Performance Analysis}
\label{sec:evaluation-performance-analysis}
Let us now consider the experimental results about system performance recorded by our simulator.
In all the experiments we have considered values stated in Section~\ref{sec:performance-modeling-specification-model} with a preemption policy based on \textit{random selection}.

\subsection{Transient Analysis}
\label{sec:evaluation-transient-analysis}
First, we conduct a \textit{transient analysis} to evaluate the system stationary in order to (i) prove its convergence to a steady-state and (ii) estimate the duration of the transient period.
%
In fact, given a system that converges to stationary, the knowledge of the duration of the transient period is really important to conduct an effective performance evaluation.
%
In particular, even if there exist techniques to reduce the impact of transitory measurements on the final insights, having an estimate for the duration of the transient period allows the analyst to focus performance evaluation on a system in its stationary conditions.

In Figures \ref{fig:evaluation-transient-analysis-throughput-1} and \ref{fig:evaluation-transient-analysis-throughput-2} we show the transient analysis for system running the Off-Loading Policy 1 and 2, respectively.
In this experiment we focused on the global system throughput as it can be considered a good representation of the dependency of the system to its initial state.
The experiment has been conducted considering an ensemble of $5$ replications, where the $i+1$-th replication is initialized with the last seed of the $i$-th replication, so as to achieve the best decoupling between random sequences of different replications.

The results show that the system reaches the steady-state in about $ 2000$ simulated seconds, in both cases.
This result is not surprising because the presence of a stabilizing \textit{infinite-buffer centre}, i.e. the Cloud, largely compensates the possible instabilities produced by the \textit{finite-buffer centre}, i.e. the Cloudlet.

\begin{figure}
	\includegraphics[width=\columnwidth]{fig/evaluation-transient-analysis-throughput-algorithm-1}
	\caption{Transient analysis for the system with OP1.}
	\label{fig:evaluation-transient-analysis-throughput-1}
\end{figure}

\begin{figure}
	\includegraphics[width=\columnwidth]{fig/evaluation-transient-analysis-throughput-algorithm-2}
	\caption{Transient analysis for the system with OP2 (S=N=20).}
	\label{fig:evaluation-transient-analysis-throughput-2}
\end{figure}

\subsection{Steady-State Analysis}
Let us now focus on the performance evaluation in the steady-state, taking into account the following metrics:

\begin{enumerate}
	\item \textit{response time} both global and classed, both for the system as a whole and for each subsystem;

	\item \textit{throughput} both global and classed, both for the system as a whole and for each subsystem;

	\item \textit{population} both global and classed, both for the system as a whole and for each subsystem;

	\item \textit{interrupted ratio} for tasks belonging to the $2^{nd}$ class.

	\item \textit{interrupted response time} for tasks belonging to the $2^{nd}$ class.
\end{enumerate}

In particular, it is interesting to compare performance metrics in the following scenarios:

\begin{enumerate}
	\item \textit{Off-Loading Policy 1}, where no priority distinction is made between classes of tasks;

	\item \textit{Off-Loading Policy 2 ($S=20$)}, where $1^{st}$ class tasks have higher priority than $2^{nd}$ class tasks and the latter have also both (i) high probability to be served by the Cloudlet and, as a consequence, (ii) high risk to be interrupted and incur in the restart overhead.

	\item \textit{Off-Loading Policy 2 ($S=5$)}, where $1^{st}$ class tasks have  higher priority than $2{nd}$ class tasks and the latter have also both (i) low probability to be served by the Cloudlet and, as a consequence, (ii) low risk to be interrupted and incur in the restart overhead.
\end{enumerate}

In Tables \ref{tbl:evaluation-performance-metrics-1}, \ref{tbl:evaluation-performance-metrics-2-20} and \ref{tbl:evaluation-performance-metrics-2-5}, we show the theoretical and experimental results for the system with Off-Loading Policy 1,  Off-Loading Policy 2 having $N=S=20$ and Off-Loading Policy 2 having $N=20,S=5$, respectively.

Experimental results have been computed assuming a system with $S=N=20$ and batch means computations with $k=64$ batches of dimension $b=512$ each.
%
Theoretical results have been computed using the formulas presented in Section~\ref{sec:analytical-model}.
%, assuming the routing probabilities shown in Table~\ref{tbl:evaluation-routing-probabilities} and $E[T_{clt,2,lost}]=1.47445;s$.

We attribute any gap between the theoretical and experimental results to the stringent assumptions we made on the analytical model, which can inevitably cause approximations in the final results.

By comparing the three scenarios, we conclude that:

\begin{enumerate}
	\item the introduction of OP2 w.r.t. OP1 improves the system response time for $1^{st}$ class tasks, whereas it worsen it for $2^{nd}$ class tasks.
	This is expected because OP2 increases the probability for a $1^{st}$ class task to be served by the Cloudlet, which is faster than the Cloud.

	\item moving from $S=20$ to $S=5$ does not have a significant impact on response time for $1^{st}$ class tasks, whereas it improves it for $2^{nd}$ class tasks.
	This may sound less intuitive because a high $S$ increases the probability for a $2^{nd}$ class task to be served by the Cloudlet, which is faster than the Cloud. Nevertheless, a high $S$ also increases the probability for the same tasks to be interrupted in the Cloudlet and lose time.

	\item the previous two points suggest us that a fine tuning of $S$ together with a smarter policy for the selection of the $2^{nd}$ class tasks to interrupt, e.g. interrupt the youngest task in order to minimize the lost time in Cloudlet, would be really valuable to leverage the power of OP2 over OP1.
\end{enumerate}

%\begin{figure}
%	\begin{center}
%		\begin{tabular}{|c||c|c|}
%			\hline
%			Measure & Theoretical & Experimental\\
%			\hline
%			$a_{clt,1}$  & $0.978326334857105$ & $0.97911346521$ \\
%			$a_{clt_2}$  & $0.603529764734761$ & $0.60502880468$ \\
%			$r$          & $0.183573830264005$ & $0.15525744148$ \\
%			\hline
%		\end{tabular}
%	\end{center}
%	\caption{Routing probabilities: comparison between the theoretical result, computed with the analytical model, and the experimental result, computed leveraging our simulator.}
%	\label{tbl:evaluation-routing-probabilities}
%\end{figure}

\begin{figure}
	\begin{center}
		\begin{tabular}{|c||c|c|}
\hline
Measure & Theoretical & Experimental \\
\hline
$N_{clt}$  & $19.0079214380542$ & $18.9657556411\pm 0.061761348$ \\
$N_{clt,1}$  & $6.94705758142083$ & $6.9174978557\pm 0.0221472832$ \\
$N_{clt,2}$  & $12.0608638566334$ & $12.0482577854\pm 0.0676551914$ \\
$T_{clt}$  & $2.97808012093726$ & $2.9329442796\pm 0.0299023279$ \\
$T_{clt,1}$  & $2.22222222222222$ & $2.1928106049\pm 0.017782072$ \\
$T_{clt,2}$  & $3.7037037037037$ & $3.6392880155\pm 0.0399050928$ \\
$X_{clt}$  & $6.38260915293038$ & $6.4226859577\pm 0.0204460156$ \\
$X_{clt,1}$  & $3.12617591163937$ & $3.1401150807\pm 0.0196271592$ \\
$X_{clt,2}$  & $3.25643324129101$ & $3.282570877\pm 0.0064520454$ \\
\hline
$N_{cld}$  & $25.1024179839379$ & $24.8788290839\pm 0.4843210347$ \\
$N_{cld,1}$  & $11.4952963534425$ & $11.6176870943\pm 0.2291824053$ \\
$N_{cld,2}$  & $13.6071216304954$ & $13.2611419897\pm 0.2620827898$ \\
$T_{cld}$  & $4.2956713711267$ & $4.1967104264\pm 0.0414272512$ \\
$T_{cld,1}$  & $4.0$ & $3.965860097\pm 0.0313637462$ \\
$T_{cld,2}$  & $4.54545454545455$ & $4.423180833\pm 0.0515154164$ \\
$X_{cld}$  & $5.86739084706962$ & $5.8591880304\pm 0.1174124089$ \\
$X_{cld,1}$  & $2.87382408836063$ & $2.8987603707\pm 0.05909048$ \\
$X_{cld,2}$  & $2.99356675870899$ & $2.9604276598\pm 0.0591551518$ \\
\hline
$N_{sys}$  & $43.5447719188013$ & $43.8445847251\pm 0.5448264622$ \\
$N_{sys,1}$  & $21.3280515520659$ & $18.53518495\pm 0.2227839341$ \\
$N_{sys,2}$  & $22.2167203667353$ & $25.3093997751\pm 0.3259203125$ \\
$T_{sys}$  & $3.85670891708856$ & $3.535972929\pm 0.0398351701$ \\
$T_{sys,1}$  & $2.87973287200309$ & $3.0441528892\pm 0.0334852226$ \\
$T_{sys,2}$  & $4.7946059203706$ & $4.0113028172\pm 0.0458354286$ \\
$X_{sys}$  & $12.25$ & $12.2818739881\pm 0.1031221489$ \\
$X_{sys,1}$  & $6.0$ & $6.0388754514\pm 0.0428513144$ \\
$X_{sys,2}$  & $6.25$ & $6.2429985368\pm 0.0612224429$ \\
\hline
		\end{tabular}
	\end{center}
	\caption{Performance metrics with OP1.}
	\label{tbl:evaluation-performance-metrics-1}
\end{figure}

\begin{figure}
	\begin{center}
		\begin{tabular}{|c||c|c|}
\hline
Measure & Theoretical & Experimental \\
\hline
$N_{clt}$  & $18.6861348679399$ & $18.6256514408\pm 0.0664027232$ \\
$N_{clt,1}$  & $13.0443511314281$ & $13.0073445344\pm 0.1191309252$ \\
$N_{clt,2}$  & $5.64178373651183$ & $5.6183069064\pm 0.0580175732$ \\
$T_{clt}$  & $2.52746236202645$ & $2.486244959\pm 0.0151247853$ \\
$T_{clt,1}$  & $2.22222222222222$ & $2.1905842105\pm 0.0188772557$ \\
$T_{clt,2}$  & $3.70370370370371$ & $3.6127254526\pm 0.0218732553$ \\
$X_{clt}$  & $7.39323961800082$ & $7.454305304\pm 0.0138303964$ \\
$X_{clt,1}$  & $5.86995800914263$ & $5.9037777336\pm 0.0317748218$ \\
$X_{clt,2}$  & $1.52328160885819$ & $1.5505275704\pm 0.0211578776$ \\
\hline
$N_{cld}$  & $23.8042750961159$ & $23.5478911244\pm 0.4188925236$ \\
$N_{cld,1}$  & $0.520167963429486$ & $0.6022354192\pm 0.0212165955$ \\
$N_{cld,2}$  & $23.2841071326864$ & $22.9456557052\pm 0.4033574016$ \\
$T_{cld}$  & $4.93752153860152$ & $4.8126915196\pm 0.0521333156$ \\
$T_{cld,1}$  & $4.0$ & $4.0785104754\pm 0.0824838383$ \\
$T_{cld,2}$  & $4.9584658104444$ & $4.8350983148\pm 0.0537793315$ \\
$X_{cld}$  & $4.85676038199918$ & $4.8308542672\pm 0.0900199085$ \\
$X_{cld,1}$  & $0.130041990857372$ & $0.1461573408\pm 0.0056344117$ \\
$X_{cld,2}$  & $4.72671839114181$ & $4.6846969265\pm 0.0850510603$ \\
\hline
$N_{sys}$  & $37.3687941909734$ & $42.1735425651\pm 0.4841637065$ \\
$N_{sys,1}$  & $18.3030828690482$ & $13.6095799536\pm 0.1357291534$ \\
$N_{sys,2}$  & $19.0657113219252$ & $28.5639626116\pm 0.3531052396$ \\
$T_{sys}$  & $4.48013019690776$ & $3.4029598386\pm 0.0341771009$ \\
$T_{sys,1}$  & $1.69742545748866$ & $2.2364277477\pm 0.019497486$ \\
$T_{sys,2}$  & $7.15152674675009$ & $4.5340442283\pm 0.0450395882$ \\
$X_{sys}$  & $12.25$ & $12.2851595712\pm 0.1020002877$ \\
$X_{sys,1}$  & $6.0$ & $6.0499350743\pm 0.0368009794$ \\
$X_{sys,2}$  & $6.25$ & $6.2352244969\pm 0.0666726067$ \\
\hline
\hline
		\end{tabular}
	\end{center}
	\caption{Performance metrics with OP2 (N=S=20).}
	\label{tbl:evaluation-performance-metrics-2-20}
\end{figure}

\begin{figure}
	\begin{center}
		\begin{tabular}{|c||c|c|}
\hline
Measure & Theoretical & Experimental \\
\hline
$N_{clt}$  & $13.0466462362487$ & $13.0433572946\pm 0.1000197871$ \\
$N_{clt,1}$  & $13.0443511314281$ & $13.0404451177\pm 0.100159524$ \\
$N_{clt,2}$  & $0.00229510482068997$ & $0.0029121769\pm 0.0003746161$ \\
$T_{clt}$  & $2.22237860239078$ & $2.1917257858\pm 0.0163608319$ \\
$T_{clt,1}$  & $2.22222222222222$ & $2.192336913\pm 0.0157853478$ \\
$T_{clt,2}$  & $3.7037037037037$ & $1.8386687645\pm 0.2026686866$ \\
$X_{clt}$  & $5.87057768744421$ & $5.9175159391\pm 0.0300427259$ \\
$X_{clt,1}$  & $5.86995800914263$ & $5.914127608\pm 0.032255318$ \\
$X_{clt,2}$  & $0.000619678301586293$ & $0.0033883312\pm 0.0024619263$ \\
\hline
$N_{cld}$  & $28.9336326367421$ & $28.7592002142\pm 0.3244410982$ \\
$N_{cld,1}$  & $0.520167963429492$ & $0.5587933651\pm 0.025284303$ \\
$N_{cld,2}$  & $28.4134646733126$ & $28.2004068491\pm 0.3046711815$ \\
$T_{cld}$  & $4.53697681371044$ & $4.4634171571\pm 0.0415547819$ \\
$T_{cld,1}$  & $4.0$ & $4.0717091521\pm 0.1405913069$ \\
$T_{cld,2}$  & $4.54680729861638$ & $4.4716070089\pm 0.0421282903$ \\
$X_{cld}$  & $6.37942231255579$ & $6.3677605014\pm 0.0759473595$ \\
$X_{cld,1}$  & $0.130041990857373$ & $0.1355383067\pm 0.0066949314$ \\
$X_{cld,2}$  & $6.24938032169841$ & $6.2322221947\pm 0.070364113$ \\
\hline
$N_{sys}$  & $42.4981517315996$ & $41.8025575089\pm 0.4144222505$ \\
$N_{sys,1}$  & $20.8154212562937$ & $13.5992384828\pm 0.1218741864$ \\
$N_{sys,2}$  & $21.6827304753059$ & $28.203319026\pm 0.3045407478$ \\
$T_{sys}$  & $3.77115618506066$ & $3.3697751086\pm 0.031978144$ \\
$T_{sys,1}$  & $1.49255296973888$ & $2.2347925896\pm 0.0172187976$ \\
$T_{sys,2}$  & $5.95861527176956$ & $4.4699170668\pm 0.0432799606$ \\
$X_{sys}$  & $12.25$ & $12.2852764406\pm 0.104073231$ \\
$X_{sys,1}$  & $6.0$ & $6.0496659147\pm 0.037506365$ \\
$X_{sys,2}$  & $6.25$ & $6.2356105259\pm 0.0679721177$ \\
\hline
		\end{tabular}
	\end{center}
	\caption{Performance metrics with OP2 (N=20,S=5).}
	\label{tbl:evaluation-performance-metrics-2-5}
\end{figure}

%%
% DISTRIBUTION ANALYSIS
%%
%\subsection{Distribution Analysis}
%\label{sec:evaluation-distribution-analysis}
%In this Section we show the distribution analysis of the Cloudlet global throughput.
%In particular, we focus on both (i) the Probability Density Function (PDF) estimation leveraging distribution fitting, and (ii) the comparison between theoretical and experimental Cumulative Distribution Function (CDF).

%In Figure~\ref{fig:evaluation-distribution-analysis-pdf-throughput-cloudlet-global} and  Figure~\ref{fig:evaluation-distribution-analysis-cdf-throughput-cloudlet-global} we show the PDF estimation and the CDF analysis, respectively, for the global Cloudlet throughput when $S=N=20$, where we adopted the \textit{Freedman-Diaconis Rule} for the binning schema.
%Results show that the best fitting is the \textit{Normal Distribution} with parameters $\mu\approx7.403$ and $\sigma\approx0.364$.
%
%The Normal behavior shown here can be considered as a further good proof of both the system stationary and the effectiveness of the batch means as a tool to study steady-state statistics.

%\begin{figure}
%	\includegraphics[width=\columnwidth]{fig/evaluation-distribution-analysis-pdf-throughput-cloudlet-global}
%	\caption{Distribution analysis (Probability Distribution Function)for the Cloudlet global throughput with threshold $S=N=20$.}
%	\label{fig:evaluation-distribution-analysis-pdf-throughput-cloudlet-global}
%\end{figure}

%\begin{figure}
%	\includegraphics[width=\columnwidth]{fig/evaluation-distribution-analysis-cdf-throughput-cloudlet-global}
%	\caption{Distribution analysis (Cumulative Distribution Function) for the Cloudlet global throughput with threshold $S=N=20$.}
%	\label{fig:evaluation-distribution-analysis-cdf-throughput-cloudlet-global}
%\end{figure}


\chapter{Linear Combinations of Random Variables}

\section{Linear combinations of any random variables}
\section{Linear combinations of normal random variables}


\subsection{Instruction Latency Requirements}
\label{sec:scalar:timing}

Any computation which operates on cryptographic secrets must not
exhibit execution latency which is correlated with the value of the
secret.
Integer multiply and carry-less multiply instructions are principly affected
by this requirement.
Cores which implement the scalar cryptography
extension must interpret the following {\em conditions}\footnote{
Prior versions of this specification described the constant-time indicator
as a {\em hint}. In RISC-V terminology, a hint is a totally optional
indicator to the core, and may always be ignored.
This mechanism is catagorically not a hint in this sense.
It {\em must} be handled by the core, and cannot be ignored.
The word {\em hint} has hence been removed from the specification to
emphasise this point.
} to provide some
guarantees of constant time behaviour to cryptographic code:

\begin{itemize}
\item {\tt rs1 <= rs2} -
    The instruction {\em must} execute with a latency which is
    independent of the values of its input operands.
\item {\tt rs1  > rs2} -
    The instruction {\em may} execute with a latency which is
    independent of the values of its input operands, but is not
    guaranteed to do so.
\end{itemize}

This condition is applied to the following instructions:
{\tt mul},
{\tt mulh},
{\tt mulw},
{\tt mulhs},
{\tt mulhsu},
{\tt clmul},
{\tt clmulh}.
This covers all of the integer multiply instructions in the
M extension, and the carry-less multiply instructions required by the
scalar cryptography extension.

\begin{displayquote}{\em
We considered alternative approaches to this.
For example, a CSR containing an ``enable constant time mode'' bit.
While this is a reasonable approach, we opted to avoid adding
state (and so complicate things like context switches and CSR accesses)
or additional instructions.
}\end{displayquote}

Cores which do not implement any data-dependent optimisations in their
multipliers (e.g., early termination, memoization) do not need to add
any additional logic to interpret this indicator.
Note that this indicator must also be interpreted when {\em fusing}
sequences of multiply instructions. For example, the sequence
\begin{verbatim}
mulh t0, a0, a1
mul  t1, a0, a1
\end{verbatim}
{\em may} be fused into a single operation inside the core.
However, because it meets the {\tt rs1 <= rs2} constraint, the fused
operation must still execution with a latency which is not dependent on
the input operands.
When fusing instruction pairs which partially meet the condition:
\begin{verbatim}
mulh t0, a0, a1 // a0 <= a1, latency must be independent of GPR[rs1], GPR[rs2]
mul  t1, a1, a0 // a1 >  a0, not guaranteed to have data-independent latency.
\end{verbatim}
cores do not need to abide by the data independent latency constraint,
as this is consistent with the un-fused sequence.
Note that the register address choices {\em may} result in different
execution latencies, so long as the numerical values contained in the
sourced registers do not affect the execution latency.
For example,
{\tt mul a1, a2, a3} (a1 = a2 * a3)
may have a different latency profile from self-assignment
{\tt mul a2, a2, a3} (a2 *= a3)
or squaring
{\tt mul a1, a2, a2} (a1 = a2 * a2) -
so long as the {\em contents} of {\tt GPR[a2/a3]} do not affect
the execution latency.
None of these latency requirements apply to floating point operations.


\section{Conclusion}
\label{sec:conclusion}

In this paper we presented \dBoost/, a toolkit that leverages tuple expansion to detect outliers in both numerical and heterogeneous data sets. We demonstrated that well-known machine-learning strategies could be used to flag spurious numerical and to a lesser extent non-numerical data. We also demonstrated that simple correlation modeling is useful in inferring data dependencies and improving the accuracy of outlier detection procedures. We discussed histogram-based models, and showed that they provided a useful tool in analyzing mostly textual data.

We showed that our toolkit performs well on real-world problems, including identifying potentially wrong entries in a people directory and flagging erroneous values generated by faulty sensors. Our toolkit and its source code are available for public use under a permissive license, with the hope of allowing database users to formulate their own type-based rules and find discrepancies in their own data.
Once a large library of rules is developed, we anticipate new challenges such as how to select expansion rules for efficient analysis.

%We believe that the preliminary results presented in this paper are promising, especially in the area of identifying outliers in heterogeneous data.


\chapter{Introduction}

LPS is a Language Prototyping System based on
Modular Monadic Semantics.

For more information, see:

http://lsi.uniovi.es/~labra/LPS/LPS.html

Some papers describing the system are \cite{Labra98, Labra99}.

Modular Monadic Semantics (\cite{LiangHudakJones95, LiangHudak96})
separates values from computations.

A computation can be described by means of a monad \cite{Moggi89}. Using monad
transformers, a monad can be transformed into a different monad with
more computational features.

The system can be seen as a Domain Specific Language embedded in
Haskell \cite{Haskell98}.

In order to derive a programming language specification it is
necessary to provide:

\begin{itemize}
\item A \emph{Parser} for the language
\item A description of the domain values
\item A characterization of the monad that models the
	computation
\end{itemize}


%--------------------------------------------------------------------------
% Discussion
%--------------------------------------------------------------------------

\chapter{Discussion}
\label{cha: discussion}

Sustainable forest management needs accurate information on the extent of forests, of which remote sensing is an effective tool for mapping and monitoring of forest cover. Land and forest cover maps of the Philippines in the past were mainly generated using optical data, but spaceborne radar sensors have been promising as a viable and accurate data source. This study evaluated the suitability of ALOS/PALSAR mosaic data for mapping and monitoring of forest cover types in the Philippines by assessing the following indicators, particularly: the temporal consistency of multi-year PALSAR mosaic data; the presence and consistency of a multi-level classification hierarchy based on a combination of polarimetric, topographic, and texture variables; and accuracy of forest type classification using decision trees.

This study demonstrated the temporal consistency of globally available PALSAR mosaic data. This makes ALOS/PALSAR data suitable for regular and periodic forest monitoring purposes, appropriate for developing operational national forest monitoring systems, and engaging in performance-based incentive schemes such as Reducing Emissions from Deforestation and Forest Degradation (REDD+), wherein data consistency is a key requirement. This consistency was demonstrated by analysing the distribution of radar backscatter vis-a-vis data acquisition dates of PALSAR mosaic data acquired in a single year but the data strips used to put the mosaic together were taken at different seasons, and of PALSAR mosaic data acquired along the same data strip or path but at different years.

The existence of a multi-level classification hierarchy of forest types developed using hierarchical cluster analysis was also demonstrated in the study, which was consistent across annual PALSAR mosaics. This was demonstrated by high Baker’s Gamma indices, which indicated that the hierarchical clustering of forest types were similar and consistent across years, and reinforced the temporal consistency of PALSAR mosaic data. Using polarimetric variables showed the highest consistencies between pairwise dendrograms. The inclusion of topographic or texture variables\textemdash{}while still resulting into high indices\textemdash{}suggested that the variables marginally decreases the consistency of the multi-level classification hierarchy over multi-year PALSAR mosaics. The most consistent multi-level classification hierarchy of forest types guided subsequent forest type classification using decision trees.

Hierarchical multi-level classification provided a suitable approach for quantifying the degree of accuracy in discriminating different forest cover types. Employing a decision tree classification approach identified the most relevant image layers and feature attributes for classifying different classes. Combining polarimetric, topographic, and texture attributes yielded lowest classification error rates compared to use of polarimetric data alone, or the combination of either polarimetric and topographic or polarimetric and texture variables in the classification.

However, even with the best combination of feature attributes used in study, high error rates were obtained in the classification of forest types following the multi-level hierarchical classification. In turn, forest cover types were mapped incorrectly in the resulting annual forest cover maps, and area statistics varied considerably among forest types across years.

In the separate assessment following a heuristic classification approach, misclassification error rates were lower in separating closed and open canopy forests compared to separating between broadleaved, coniferous, and mixed forests. This was in contrast to the findings of Dobson et al. \citeyearpar{dobson_knowledge-based_1996}, particularly in their investigation of the capability of ERS-1 and JERS-1 SAR imagery using a knowledge-based classification with hierarchical decision rules to differentiate structural land cover categories, of which they concluded that L-band was capable of differentiating forest types based on their structural characteristics, particularly as either broadleaved or coniferous, but not canopy attributes like closed or open canopy cover.

Also, within the heuristic approach, the inclusion of topographic variables in either forest groups affected the classification accuracy by yielding lower error rates as compared to including texture variables, which had no effect on improving classification accuracy and was no different than using polarimetric variables alone. This result was similar to the findings of Li et al. (2012) where texture attributes from L-band SAR data were less important than polarimetric attributes.

Nevertheless, the error rates obtained in the heuristic classification approach that aimed to gauge the separation of either closed or open canopy forests; or broadleaved, coniferous, and mixed forests were comparably much higher than using the multi-level hierarchical classification approach, which suggests that using a hierarchical clustering analysis to find natural groupings of forest types in the data yielded better classification accuracies compared to a heuristic method. Also, in the case of discriminating mangroves from other forest types, apparent classification errors (false positive) were produced as a result of the classifier determining elevation as the most parsimonious attribute for its discrimination (from closer inspection of the resulting decision trees).

The low accuracies achieved from discriminating different forest cover types may be attributed to the low sensitivity of data layers and feature attributes used in distinguishing the physical characteristics of the forest types being mapped. It may also be attributed to the incompatibility of discriminating forest attributes by the PALSAR sensor with the forest categories based on the FAO Global Forest Resources Assessment classification scheme. L-band radar backscatter was poorly sensitive to canopy attributes (e.g., closed canopy and open canopy) that characterise the FAO Global Forest Resources Assessment forest cover types. While other studies have indicated better performance of L-band radar backscatter at discriminating forest cover types characterised by forest structural attributes such as broadleaved and coniferous, the error rates obtained in this study suggested otherwise and also showed that error rates obtained for forest types described by forest canopy attributes were slightly lower than the error rates obtained for forests types described by structural attributes.


\chapter{NAG Graphics Library concise summary}

\begin{verbatim}
                    J06A - AXES, GRIDS, BORDERS and TITLES

      J06AAF - Pair of axes for current data region, automatic annotation
      J06ABF - Pair of axes for current data region, user-specified annotation
      J06ACF - Grid for the current data region, automatic annotation
      J06ADF - Grid for the current data region, user-specifiable annotation
      J06AEF - Scaled border for current data region, automatic annotation
      J06AFF - Scaled border for current data region, user-specied annotation
      J06AGF - Single axis under user control
      J06AHF - Plot title, centred at the top of the current data region
      J06AJF - Axis title, centred at side or bottom of current data region
      J06AKF - Pair of logarithmic axes for current data region, automatic
               annotation
      J06ALF - Logarithmic grid for current data region, automatic annotation
      J06AMF - Logarithmic border for current data region, automatic
               annotation
      J06ANF - Single logarithmic axis under user control
      J06APF - Single axis with user-specified position of tick marks and
               annotation
      J06AQF - Single axis with user-supplied annotation, and control over
               position of tick marks and annotation

                    J06B - POINT PLOTTING and STRAIGHT LINE DRAWING

      J06BAF - Plot data points with optional straight lines and markers
      J06BBF - Linear regression line using output from G02CAF, G02CBF,
               G02CCF or G02CDF
      J06BCF - Plots a series of data points with optional error bars
      J06BYF - Key to current NAG pen styles
      J06BZF - Key to current line styles and/or markers

                    J06C - CURVE DRAWING

      J06CAF - Plot single-valued curve through data points
      J06CBF - Plot single-valued curve through data points, called
               point-wise
      J06CCF - Plot possibly multi-valued curve through data points
      J06CDF - Plot possibly multi-valued curve through data points, called
               point-wise

                    J06D - ODE GRAPHICS

      J06DAF - Plots a graph of components of the solution of a system of ODEs,
               comprehensive version, using option setting

                    J06E - GENERAL FUNCTION DRAWING

      J06EAF - Plot user-supplied function over specified range
      J06EBF - Plot user-supplied function over specified range, called
               point-wise
      J06ECF - Plots a parametric curve

                    J06F - SPECIAL FUNCTION DRAWING

      J06FAF - Plot cubic spline in an interval, from its B-spline
               representation
      J06FBF - Plot polynomial represented in Chebyshev form, using output
               from E02ADF or E02AFF

                    J06G - CONTOURING

      J06GAF - Easy-to-use contour map, data on regular rectangular grid
      J06GBF - Comprehensive contour map, data on regular rectangular grid
      J06GCF - Easy-to-use contour map, data on irregular rectangular grid
      J06GDF - Comprehensive contour map, data on irregular rectangular grid
      J06GEF - Easy-to-use contour map, user-supplied function
      J06GFF - Comprehensive contour map, user-supplied function
      J06GGF - Comprehensive contour map, using option setting, data scattered
      J06GYF - Key to contour plot produced with J06GGF
      J06GZF - Key to contour indices

                    J06H - SURFACE VIEWING

      J06HAF - Easy-to-use isometric surface view, data on regular rectangular
               grid
      J06HBF - Comprehensive isometric surface view, data on regular
               rectangular grid
      J06HCF - Perspective surface view, data on regular rectangular grid
      J06HDF - Easy-to-use perspective surface view, data on irregular
               rectangular grid
      J06HEF - Comprehensive perspective surface view, data on irregular
               rectangular grid
      J06HFF - Perspective surface view, sections parallel to either
               horizontal axis
      J06HGF - Perspective view of a three-dimensional histogram
      J06HHF - Annotate data points on a perspective surface view
      J06HJF - Annotate individual data blocks on a 3D histogram
      J06HKF - Isometric surface view of a two-dimensional function f(x,y)
      J06HLF - Perspective surface view of a two-dimensional function f(x,y)

                    J06J - DATA PRESENTATION

      J06JAF - Shaded bar chart, vertical, various styles (easy-to-use)
      J06JBF - Shaded bar chart, vertical, various styles (comprehensive)
      J06JCF - Shaded bar chart, variable width bars
      J06JDF - Shaded bar chart, horizontal, various styles (easy-to-use)
      J06JEF - Shaded bar chart, horizontal, various styles (comprehensive)
      J06JFF - Shaded block chart, variable width and height blocks
      J06JGF - Marker diagram, sorts data into bins
      J06JHF - Marker diagram, subdivision of bins
      J06JKF - Shaded pie chart, (easy-to-use)
      J06JLF - Shaded pie chart, (comprehensive)
      J06JMF - Shaded bar chart, vertical or horizontal, no subdivision of
               bins (easy-to-use)
      J06JNF - Frequency distribution diagram, various styles, integer grid
               input
      J06JPF - Frequency distribution diagram and scatter plot, various
               styles, x,y input data
      J06JYF - Key to numeric values
      J06JZF - Key to area fill styles

                    J06K - VECTOR FIELD PLOTTING

      J06KAF - Plots a two-dimensional vector field diagram
      J06KBF - Plots a three-dimensional vector field diagram
      J06KCF - Plots a two-dimensional vector field diagram from a
               user-supplied function
      J06KDF - Plots a three-dimensional vector field diagram from a
               user-supplied function

                    J06S - STATISTICAL GRAPHICS

      J06SAF - Plots a time-series, and optionally user-supplied forecasts and
               standard error limits
      J06SBF - Plots autocorrelation or partial autocorrelation function of a
               time series
      J06SCF - Plots a cumulative normal probability graph. Data may be
               grouped together and a histogram plotted
      J06SDF - Plots a linear regression line and optional confidence limits
               for data and line
      J06SEF - Draws box and whisker plots

                    J06V - UTILITY ROUTINES

      J06VAF - Returns or defines the unit number for error messages
      J06VBF - Returns or defines the unit number for advisory messages
      J06VCF - Returns or defines the unit number for command sequence output
      J06VDF - Returns or defines the unit number from which Hershey fonts
               will be read (used only by PC Graphics implementations)
      J06VEF - Returns or defines the unit number to which SAVE options should
               be directed
      J06VFF - Reads a set of optional parameters from an external file
      J06VGF - Supplies individual optional parameter for a specified routine
\end{verbatim}