As from the early design stages, the philosophy for \period had been
usability and scientific reproducibility. Therefore its central feature is
its {\bf project file}. This offers the possibility to stop at a certain point
and continue later - maybe even on a totally
different operating system - as if the program had not been stopped.

Along with this comes the {\bf log feature}, where every action that has been
taken is written down with the current date and time. This log
also offers the possibility to include comments, thoughts, etc.
with the machine generated ones.
The design goal for the {\bf log} had been that it can
be read easily by the human user.
Beware, as the program generated documenting messages
are quite extensive even a simple session can produce large output -
this can be a real nuisance but can also help in some cases!

All the other parts of \period are attached as modules to this backbone.

The most essential module is the one for handling the {\bf time string data}.
It offers the possibility to select different parts of the time string.
Thus each and every data point can have up to 4 different
{\bf attributes} that can  be attached to it.
With these attributes, which are named by default:
{\it Date}, {\it Observatory}, {\it Observer} and {\it Other},
each data point can have a label of its own. With this it is easy
for example to differentiate between days,
observers or observatories - even techniques
or different instrumentation.

An example for a data point is:

\begin{tabular}{|c|c|}\hline
\row{{\bf time}&{116.7018519}}
\row{{\bf amplitude}&{11.231}}
\row{{\bf date}&{1996-02-03}}
\row{{\bf observatory}&{KittPeak}}
\ruledrow{{\bf observer}&{Smith}}
\end{tabular}

and the format of the data would be:\\
{\tt 116.7018519     11.231  1996-02-03      KittPeak    Smith}

Thus selecting a certain subset of the time string can be done
by selecting the appropriate labels in each of these attributes.

\note{A point is only added to the current selection if
{\bf all} its attributes are selected.}

These qualities also offer common additional attributes except for
their name, namely:
\myitemize{
\item {\bf color}: this helps to differentiate between different
        attributes in a graph.
\item {\bf weight}: this gives, as a product of the weight of all
        qualities for a certain point, a weight to the point.
        This value then can be used by all the other modules
        when performing calculations.
}

Finally there is the concept of {\bf uncorruptable data},
which means, that the original data should not be shifted, scaled,
etc. in any way. So there are two distinct sets of amplitudes for each
data point:
\myitemize{
\item {\bf original}: the unedited data
\item {\bf adjusted}: the edited data, which can easily be reverted
        to the original values.
}

\note{Again, as \period never wants to change original data, the deletion of
data is not an act of deleting but an act of changing a certain
attribute to ``deleted'' for example. (This label can be changed.)}

The next module is only responsible for {\bf sinusoidal fits} to the
currently selected time string.
It basically consists of a table of frequencies,
amplitudes and phases along with a zero point.

The fit to the data is as follows:\\
\latexonly{$A(t)=Z+\sum A_{i} sin(2\pi(t F_{i}+P_{i})) $}
\latexignore{$A(t)=Z+SUM(A{i} sin(2 \pi(t F{i}+P{i})))$\\}

Frequencies can be active or inactive for a certain fit,
giving more degrees of freedom to the user. The user may check different
solutions to the same time string, or look for effects of certain frequencies
on a Fourier spectrum.

Additional features are that a frequency can either be a {\bf harmonic}
of another frequency (which helps fitting data with nonsinusoidal
shapes) or a {\bf combination} of two other frequencies
(sum or difference of integer multiples of each frequency).

Fits to the data are allowed with almost arbitrary freedom,
but basically there are 3 modes of calculation:
\myitemize{
\item {\bf Calculate}: keeps the frequencies fixed and
        finds the best fit for all selected amplitudes and phases.
\item {\bf Improve}: improves the frequencies as well.
\item {\bf Special}: gives full choice of what frequencies,
        amplitudes and phases should be improved, as well as
        a possibility to calculate
        {\bf amplitude and/or phase variations }
        according to a certain attribute of the time string.
}

The last of the modules of \period gives access to {\bf Fourier} techniques.
This has some interconnections with the {\bf fit} module.

\note{it performs full featured Fourier transformation and does not use
the faster ``Fast Fourier Transform ''(FFT) algorithm, as data
do not have to be equally spaced.}

For bookkeeping, the result of the Fourier calculations are stored
together with the project as long as these are not removed by the user.
Each calculation also has a label of its own for ease of recognition.

One special feature is the possibility to calculate
a Fourier spectrum with {\it weighted} data,
or the possibility to calculate
{\bf Fourier noise}. This means calculating an average amplitude for
a certain frequency range. It can be very useful to determine if
an peak is significant or not.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Starting up \periodname}
\label{basic.start}

Starting \period is as easy as:
\myitemize{
\item typing {\tt \periodname} under Unix(tm)
\item Starting \period from the start menu under
         Windows 95\registered , or
         Windows NT\registered
}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{A small example}
\label{basic.example}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Reading in a time string}
First we have to load a time string.
To do so, please go to the
\helpref{time string folder}{timestring.folder} and press
the \button{Import} in the bottom of the window.
Then you will be asked for the name of the file you want to import.
Please select the file {\tt test.dat} in the samples directory of
the \period installation directory
(the exact location depends on your installation, but it should be
installed in the directory ``samples'' of the installation directory
of \period).

Then you will see that the \helpref{import dialog window}{timestring.import}
will show up. For the moment please just click on the \button{Ok},
as the defaults are acceptable.
For further information please check out the reference above.

As you can see, the window has changed and some further information
is given, e.g. the number of points selected and the total number of
points.

To have a look at the data please press on the \button{Display Graph}.
This will open up a window with the representation of the timestring.
(See \helpref{timestring graph window}{timestring.graph} for more details.)

You already can see some periodicity in the graph itself, so
let us try to find out what frequencies are in the data.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Fourier analysis}
First we have to make a Fourier analysis.
Activate the \helpref{fourier folder}{fourier.folder} by clicking
with the mouse on {\bf Fourier} - but do {\it not} select the menu.

The new dialog offers a lot of possibilities, but as the defaults
for \period are well chosen in this case just pressing on the
\button{Calculate} will start the calculation.

But before starting the calculation \period will ask if it should
subtract an average zero point of -0.007892.
(For more detailed discussion please see
\helpref{Fourier zero point}{fourier.zeropoint}.)
Please choose yes as well and then the calculations will start.

When the calculation has finished, a small window will show up and ask,
if you want to include the frequency with the highest peak.
(The result should be:
Frequency of 11.9162641
and an amplitude of 0.10172852).
Please choose again yes and this frequency will be included
in a list of frequencies.

The Fourier spectrum can also be examined graphically by pressing on the
\button{Display graph}.
The new \helpref{window opening up}{fourier.graph} will display the result.

\note{As you may notice the graph is not smooth.
This is due to the fact that during Fourier calculation
\period tries to minimize
memory usage by memorising only local extrema and skipping all the
points in between.}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Fit one frequency}
So, as we have got a frequency, we can try to fit it to the signal.
Activate the \helpref{fit folder}{period.folder} by clicking
with the Mouse on {\bf Fit} - but not on the menu.

As we have already included one frequency,
we can see its parameters in the table as F1.
As the frequency F1 has not been activated,
please tick the checkbox in front of {\bf F1} to activate it.

Now, at first we have to find out about the true phase
using the least square fit technique.
Just press on the \button{Calculate} and almost immediately
the window will be updated with the new values.

\begin{tabular}{|c|c|c|}\hline
\row{{\bf frequency}&{\bf amplitude}&{\bf phase}}\hline
\row{{11.9162641}&{0.100150376}&{0.0200245}}
\hline\hline
\row{{\bf zero point}&{0.00101803983}&}
\ruledrow{{\bf residuals}&{0.0342341403}&}
\end{tabular}

But the frequency itself has not been improved.
And this is what we actually want to do.
So press now on the \button{Improve all}.
This will also improve the frequency and should give the
following result:

\begin{tabular}{|c|c|c|}\hline
\row{{\bf frequency}&{\bf amplitude}&{\bf phase}}\hline
\row{{11.9870449}&{0.101277217}&{0.00447894}}
\hline\hline
\row{{\bf zero point}&{0.00224986037}&{}}
\ruledrow{{\bf residuals}&{0.0336615961}&{}}
\end{tabular}

This is the best fit that we can reach with a single frequency.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Fourier analysis with residuals}
Now go back to the {\bf Fourier folder} and
select the ``Residuals at original'' entry in the
``Calculation based on'' item.
Then calculate Fourier anew by pressing the \button{Calculate}.

This time you should not be prompted for a zero point, as \period
assumes that the residuals have a mean value of zero.
The fit should already have taken care of it.

Again please include the frequency of the highest point, which in this case
should be: Frequency= 7.16586151 and amplitude: 0.0457409859.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Fit two frequencies}

Now we have found two frequencies, so let's go back to the
{\bf Fit folder} and activate the frequency F2 as well.
Then press again the \button{Calculate}.

After the calculations have finished,
the window will be updated with the new values:

\begin{tabular}{|c|c|c|}\hline
\row{{\bf frequency}&{\bf amplitude}&{\bf phase}}\hline
\row{{11.9870449}&{0.0975994208}&{0.00428761}}
\row{{7.16586151}&{0.0479167213}&{0.25244}}
\hline\hline
\row{{\bf zero point}&{-0.00198521031}&{}}
\ruledrow{{\bf residuals}&{0.00645800843}&{}}
\end{tabular}

Finally improve the frequencies as well
by pressing on the \button{Improve all},
and the window will be updated with
the new values:

\begin{tabular}{|c|c|c|}\hline
\row{{\bf frequency}&{\bf amplitude}&{\bf phase}}\hline
\row{{11.9994309}&{0.100072311}&{0.000117863}}
\row{{6.99670604}&{0.0501719796}&{0.301063}}
\hline\hline
\row{{\bf zero point}&{1.50619639e-05}&{}}
\ruledrow{{\bf residuals}&{0.000281511948}&{}}
\end{tabular}

This is very close to the values chosen for creating
the artificial light curve, which are:

\begin{tabular}{|c|c|c|}\hline
\row{{\bf frequency}&{\bf amplitude}&{\bf phase}}\hline
\row{{12}&{0.1}&{0.0}}
\row{{7}&{0.05}&{0.3}}
\hline\hline
\ruledrow{{\bf zero point}&{0.0}&{}}
\ruledrow{{\bf residuals}&{0.000329267906}&{artificial noise}}
\end{tabular}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Save the Project}

Finally we may want to save the full results.
To do so, please select the \menuentry{Save Project} from the
\menu{File}, and save the project.

\period can be quit by selecting the \menuentry{Quit} from the
\menu{File}.

To continue with all the settings that you have had in your last session
restart \period and then select the \menuentry{Load Project}
from the \menu{File}. Now you can continue as if the work has
not been interrupted.

%%% Local Variables:
%%% mode: latex
%%% TeX-master: "period98"
%%% End:


\chapter[Onset Classification]{Onset Classification}

\section{Method}
Since forecasting actual values for \req\ is not always viable or accurate, an attempt was made to model \req\ event onsets as a classification problem whereby an onset timestep (the one in which the 20 $amu/cm^3$ threshold was crossed) was defined as a ``1", and any other time defined as a ``0". \cite{Denton2016}, which also uses the inferred \req\ from GOES Alfvén waves, indicates that daily averaged Kp and \f\ both are involved in driving the behavior of \req. By then passing relevant measurements such as Kp, $F_{10.7}$, and $V_{SW}$ into a non-linear classification model such as \texttt{patternnet} \citep{MATLAB:2014}, a predictive classification could be made based on these conditions.

Two formats and two time scales were tested: one format consisting of passing in an entire timeseries, where each prediction was based on a sliding window of the current and previous three timesteps as one set of inputs. The other format only considered time periods at and three hours before onset, but treated each time step as its own input and classification. Both formats  are diagrammed in Figure \ref{fig:ClassifyDiagram}. The top diagram shows the classification method where the modeling window slides across one timestep at a time and only spans four timesteps at each onset. The bottom diagram depicts the prediction method where the window slides across all data, and each block of four timesteps attempts to predict an onset one step ahead. Both methods were used to make models for the two time scales of hourly and daily medians of values.

\begin{figure}[htp!]
	\centering
	\includegraphics[width=1\linewidth]{Figures/CH5/ClassifyGraphic2.png}
	\includegraphics[width=1\linewidth]{Figures/CH5/FullGraphic.png}
	\caption{Diagram of classification (top) and prediction (bottom) methods.}
	\label{fig:ClassifyDiagram}
\end{figure}

In order to aid the model in finding event onsets despite being numerically overwhelmed by non-onsets, the targets are weighted to more highly value a "1". This is required since the number of events is similar between hourly and daily timescales, but the number of total time steps is a factor of 24 larger for the hourly scale. As such, the weights are scaled so targets have a value of the logarithm of the number of data points divided by the number of onsets, while all other points have a weight of 1. This gives a typical relative weight of 2-7 for onsets versus non-onsets.

\section{Results}

\subsection{Classification} \label{sec:ClassifyResults}

Figure \ref{fig:OnsetEvents} is a confusion matrix, where onsets (class ``1") and non-onsets (class ``0") are categorized based on their real value labeled the ``Target Class", and the value categorized by the model labeled the ``Output Class". So for example, on a daily timescale, there were 582 event onsets (sum of Target class 1), and the model correctly classified 473 of them (intersection of target class 1 and output class 1). Since this classification model is primarily concerned with correctly classifying onsets, the percentage values given will be for the percent of correctly classified onsets out of the total number of onsets, shown as the green value in the bottom of column 2. This specific figure shows that trying to classify events on an hourly timescale using only the onset hour and three hours before leads to a model that classifies almost no onsets. Using daily values, however, results in a model where a full 80\% of the onsets are correctly detected and classified, but only half of the predicted onsets were actually onsets.

\begin{figure}[htp!]
	\centering
	\includegraphics[width=0.45\linewidth]{Figures/CH5/NNBinaryOnset-hourly.eps}
	\includegraphics[width=0.45\linewidth]{Figures/CH5/NNBinaryOnset-daily.eps}
	\caption{Prediction confusion matrix for hourly (left) and daily (right) \req\ onset events using classification method.}
	\label{fig:OnsetEvents}
\end{figure}

In an attempt to determine what conditions best lead to a correct classification, histograms were made of the conditions associated with a correctly classified onset versus those of an undetected onset. Figure \ref{fig:OnsetEventsHist} shows this for the four variables used.

\begin{figure}[htp!]
	\centering
	\includegraphics[width=0.85\linewidth]{Figures/CH5/NNBinaryOnset-daily-hist.eps}
	\caption{Histogram of onset conditions for daily-averaged \req\ events binned by correctness of prediction.}
	\label{fig:OnsetEventsHist}
\end{figure}

It shows that the model tended to miss onsets during periods of particularly low \f, and during high speed solar winds, but was largely unaffected otherwise.

The next test was to add more obvious indicators of an event onset, such as the data being used to define an onset, and determine if the model could pick that up. By adding \req\ as a factor in classifying \req\ events, the model unsurprisingly does very well, as shown in Figure \ref{fig:OnsetWithreq}.

\begin{figure}[htp!]
	\centering
	\includegraphics[width=0.45\linewidth]{Figures/CH5/NNBinaryOnset-hourly-withreq.eps}
	\includegraphics[width=0.45\linewidth]{Figures/CH5/NNBinaryOnset-daily-withreq.eps}
	\caption{Prediction confusion matrix for hourly (left) and daily (right) \req\ onset events, including \req\ as an input variable, and only looking at three hours before and including onset.}
	\label{fig:OnsetWithreq}
\end{figure}

With a successful true positive classification rate of 99\% and 84\% for hourly and daily 4-hour models respectively, it can be said that including \req\ information makes the models effective for classifying event onset, both validating the model as being able to determine our selection criteria as well as showing the extent to which daily averaging can obscure conditions attributed to an event. Since the \req\ events have a median duration of 14 hours above the $-20$~nT threshold, it is clear that they significantly impact the entire day enough to still be detectable. A histogram of these variables binned by true positive and false negative shows no particularly compelling trends, as seen in Figure \ref{fig:OnsetWithreq-hist}.

\begin{figure}[htp!]
	\centering
	\includegraphics[width=1\linewidth]{Figures/CH5/NNBinaryOnset-hourly-withreq-hist.eps}
	\caption{Histogram of onset conditions for hourly \req\ events including \req\ as an input, binned by correctness of prediction.}
	\label{fig:OnsetWithreq-hist}
\end{figure}

\clearpage

\subsection{Forecasting} \label{sec:ForecastResults}

Using the full data set where each prediction was based on the previous four timesteps of inputs (\f, $K_p$, \dst, and $V_{SW}$) returned two models (daily and hourly). Both were tested with and without \req\ included as an input variable due to its more limited availability. All four confusion matrices are shown in Figure \ref{fig:OnsetFullWithreq}.

\begin{figure}[htp!]
	\centering
	\includegraphics[width=0.45\linewidth]{Figures/CH5/NNBinaryOnset-full-hourly.eps}
	\includegraphics[width=0.45\linewidth]{Figures/CH5/NNBinaryOnset-full-daily.eps}
	\includegraphics[width=0.45\linewidth]{Figures/CH5/NNBinaryOnset-full-hourly-withreq.eps}
	\includegraphics[width=0.45\linewidth]{Figures/CH5/NNBinaryOnset-full-daily-withreq.eps}
	\caption{Prediction confusion matrix for hourly (left column) and daily (right column) \req\ onset events, including \req\ as an input in the bottom row, and using entire timeseries with a four hour sliding window.}
	\label{fig:OnsetFullWithreq}
\end{figure}

It is seen that the selected weighting scheme is not sufficient to pick up hourly events without further tuning, but is overly aggressive with the daily values and ends up creating more false positives than truly correct predictions. That said, being able to predict 66\% of events a day in advance, at the cost of only half of the predicted onsets being accurate, can be of use if the cost of false positives is low. Again, the variables were broken down by value and correctness of prediction, this time taking the median value of each variable across the four-timestep bin. The resulting histograms are shown in Figure \ref{fig:OnsetWithreq-hist-full}.

\begin{figure}[htp!]
	\centering
	\includegraphics[width=1\linewidth]{Figures/CH5/NNBinaryOnset-full-daily-withreq-hist.eps}
	\caption{Histogram of onset conditions for daily \req\ events including \req\ as an input, binned by correctness of prediction.}
	\label{fig:OnsetWithreq-hist-full}
\end{figure}

This model seems to also miss predictions during periods of low solar activity and low density. Considering at least one value had to be less than 20, and one greater than 20, this might indicate that certain events are starting lower in value and barely crossing the threshold, and end up with poor predictions for it.  The model also shows that the false positives tend to follow the same distribution as the true onset values, suggesting that the model is picking up the structure but missing some other information that would determine whether \req\ actually sees a measured increase in value. As this is a first attempt at this sort of model, there is much room for refinement and improvement.

\subsection{Summary}
It has been shown that it is possible to classify a \req\ event onset as being distinct from the three hours preceding it, though this process is less accurate on a daily averaged timescale. This indicates that there are distinguishing characteristics of solar wind and geomagnetic conditions surrounding an event.

It has also been shown that given four days of solar and geomagnetic conditions, an event can be forecasted a day in advance with reasonable accuracy, but also with a number of false positives. These false positives have similar values as the true positives, though, indicating more data are needed to distinguish impending events.

\def\arraystretch{1.5}
 \begin{table}[h]
	\begin{tabular}{CCCCCCCC}
 		0 & 0 & 0 & 0 & 0 & 0 & 0 & 1 \\
 		\hline
 		B_{z_{\tau-7}} & B_{z_{\tau-6}} & B_{z_{\tau-5}} & B_{z_{\tau-4}} & B_{z_{\tau-3}} & B_{z_{\tau-2}} & B_{z_{\tau-1}} & B_{z_{\tau}}  \\
		F_{10.7_{\tau-7}} & F_{10.7_{\tau-6}} & F_{10.7_{\tau-5}} & F_{10.7_{\tau-4}} & F_{10.7_{\tau-3}} & F_{10.7_{\tau-2}} & F_{10.7_{\tau-1}} & F_{10.7_{\tau}}  \\
		K_{p_{\tau-7}} & K_{p_{\tau-6}} & K_{p_{\tau-5}} & K_{p_{\tau-4}} & K_{p_{\tau-3}} & K_{p_{\tau-2}} & K_{p_{\tau-1}} & K_{p_{\tau}}  \\
		\rho_{eq_{\tau-7}} & \rho_{eq_{\tau-6}} & \rho_{eq_{\tau-5}} & \rho_{eq_{\tau-4}} & \rho_{eq_{\tau-3}} & \rho_{eq_{\tau-2}} & \rho_{eq_{\tau-1}} & \rho_{eq_{\tau}}  \\
 		\hline
 	\end{tabular}
 \end{table}


\section{Conclusions}
\label{sec:conclusions}

%%
% SUMMARY
%%
In this work we propose a next-event simulator for a two-layer Cloud system with off-loading policies on class-partitioned workload, whose random components leverage a multi-stream Lehmer pseudo-random number generator.

%%
% CONCLUSIONS
%%
We may conclude that
(i) our simulator returns experimental results that approximates the theoretical ones,
(ii) the adopted pseudo-random number generator has a satisfactory randomness degree,
(iii) the system can achieve the steady-state,
(iv) the adoption of an off-loading policy and the fine tuning of its parameters are crucial for system performances.

%%
% IMPROVEMENTS
%%
Although our results are pretty satisfactory, the proposed solutions could certainly be improved and be subjected to a more in-depth analysis.
%
From an analytical point of view, the proposed analytical model should be refined adjusting some of the very strong assumption we made to simplify it.
%
From an implementation point of view, the proposed solution should be ported from Python to C and leverage multi-threading to achieve better performances, e.g. to speed-up the algorithms to find suitable multipliers for modulus in 64-bit architectures and make faster simulations.
%
From a randomness point of view, the proposed random number generator should be tested more extensively. For example, we may (i) take into account more tests of randomness (ii) use a pseudo-random number generator with a 64-bit modulus and less number of streams.
%
Finally, the simulation model should be extended in order to
(i) study the impact of different thresholds,
(ii) study the influence of different server selection policies for the $2^{nd}$ class task interruption, e.g. equity-selection, and
(iii) achieve more performance evaluation goals, such as what-if analysis with respect to the variation of the arrival and service processes.


\documentclass[aoas,preprint]{imsart}

\RequirePackage[OT1]{fontenc}
\RequirePackage{amsthm,amsmath}
\RequirePackage{natbib}
\RequirePackage[colorlinks,citecolor=blue,urlcolor=blue]{hyperref}
\RequirePackage{hyperref}

% settings
%\pubyear{2005}
%\volume{0}
%\issue{0}
%\firstpage{1}
%\lastpage{8}
%\arxiv{arXiv:0000.0000}

\startlocaldefs
\numberwithin{equation}{section}
\theoremstyle{plain}
\newtheorem{thm}{Theorem}[section]
\endlocaldefs

\begin{document}

\begin{frontmatter}
\title{K-Means Clustering and Adaptive Clustering}
\runtitle{K means clustering and adaptive clustering}

\begin{aug}
\author{\fnms{Eric} \snm{Z. Chen}\ead[label=e1]{chvlyl@gmail.com}}

\runauthor{Eric Z. Chen}

\affiliation{University of Pennsylvania}

\end{aug}

\end{frontmatter}

\section{Introduction}
Clustering analysis is a common unsupervised approach often used to identify the internal structure of the data and can be used to extract useful information from the data without labels. K means clustering is one of the most commonly used approaches. For a given number of clusters, this method identifies the cluster membership for each data point such that the distance between each data point and the cluster centroid within the cluster is minimized. Although K means clustering is widely used, it has several limitations. It requires pre-specified cluster numbers and the algorithm does not guarantee to find the global optimum.  It often fails if the true cluster pattern is complex or the size of the data in each cluster is unbalanced. To identify more complex cluster patterns, one can map the data from data space to the feature space with kernels, which is called kernel K means clustering. To overcome limitations of k means clustering, Efimov et al. recently proposed an adaptive nonparametric clustering approach. This approach begins with a set of seed points defined by small radii and then performs clustering in an adaptive way with increased radius. In each iteration, it performs a statistical test on two points for significance of overlapping between their neighbor points, where the neighbor points is defined by the radii.  The two points can be assigned into one cluster if the overlap of their neighbor points is significant.

\section{Method}

Three clustering algorithms were implemented in Python, namely K means clustering, kernel K means clustering and adaptive clustering. Those functions were wrapped into a Python package. The whole analysis presented in this report is also available as a Jupyter Notebook and can be download from the same github repo.

Features of real data were normalized to [0,1] if they are in different scale. The Euclidean distance measure was used in three clustering algorithm. For kernel K means, the Gaussian kernel was used. The parameter $\sigma$ was tuned by searching in ($1.0,2.0,3.0,5.0$) and the best result was reported.   In order to find the best cluster numbers for  K means and kernel K means clustering, values from $[max(2,true\_n\_clusters-5),true\_n\_clusters+5]$ were tested and the Silhouette scores were calculate. The best cluster number was selected with the largest average Silhouette score. Since the true cluster labels are available, the Rand index was used to compare the performance of the three clustering algorithms.  Check the notebook for details about data analysis.

\begin{table*}
\caption{The Rand scores of K means clustering, kernel K means clustering and adaptive clustering on simulated and real data.}
\label{randscore}
\begin{tabular}{lrrr}
\hline
Dataset & \multicolumn{1}{c}{K means} & \multicolumn{1}{c}{Kernel K means} & \multicolumn{1}{c}{Adaptive clustering} \\
\hline
aggregation & 0.762 & 0.785 & 0.809  \\
compound   & 0.437 & 0.729 &   0.803 \\
D31          &    0.883 & 0.909 &  0.517 \\
flame         &  0.430  & 0.550 & 0.950 \\
jain           &    0.324  & 0.261 &   1.000\\
pathbased &    0.461 & 0.521 & 0.970 \\
R15&    0.792 & 0.892 &   0.928 \\
spiral&    -0.006 & 0.051 &   1.000\\
\hline
%letter &    0.135 &        &   \\
wine & 0.869 & 0.899  &   0.268\\
glass & 0.252 & 0.263 &  0.024\\
thyroid & 0.232 & 0.247 & 0.252\\
%yeast & 0.130 &  &  \\
iris & 0.568 &  0.568 &  0.568\\
l%eaves & 0.297 &    & \\
wdbc & 0.730 &  0.730&  0.003	\\
\hline
\end{tabular}
\end{table*}

\section{Discussion}
The K means and kernel K means clustering do not guarantee to find the global optimum. Thus it is usually repeated with different random centroid initializations to avoid local optimum. Some methods have also been proposed to find a good initializations. K means clustering often fails to identify complex cluster patterns although using kernel can help to alleviate this problem. Another drawback of K means is that it often to identify the correct structure if the size of the data in each cluster is unbalanced. Outliers in the data can also affect the performance of K means clustering. K means clustering also requires user to specify the number of clusters. One great advantage of K means clustering is that this method can handle very large sample size and therefore is widely used in the industry.

Another popular clustering algorithm I often use is DBSCAN. It can find very complex patterns in the data and can identify outliers. For text data, I often use LDA (topic models) to cluster the documents. One major difference of such model from K means clustering is that topic models assign a probability for cluster membership, rather than 0/1. So it is often called soft clustering and it is especially useful in some scenario.

Biomedical data are usually high dimensional. Any clustering method based on distance does not work well in high dimensional data. This is because in high dimension space, the distance between any two date points are almost the same and thus it is difficult to define  the nearest neighbors.

The recently proposed adaptive clustering approach by  Efimov et al. addresses some of the limitations of K means clustering such as unbalance size in different clusters, complex cluster pattern, outliers, unknown number of clusters. Since this approach is still a distance based approach, it is expected to not work well for the high dimensional data. Actually, I found that for the real data with dimensions $>$ 10, this method fails to identify the underlying cluster patterns. One thing I noticed is that the author proposed to use $n_0=2p+2$ as the initial number of neighbors for each data points. When dimension is relatively large, $n_0$ gets large value and thus $h_0$ is large. This causes the weigh matrix fail to initialize properly. Also, when dimension is relatively large, it is difficult to find the neighbors since almost all points are equally distanced. This caused the $h_k$ sequence difficult to generate properly. Therefore, I tried PCA on those data first and perform the adaptive clustering on first three PCA components.

\bibliographystyle{imsart-nameyear}

\end{document}


\chapter{``D'' Standard Extension for Double-Precision Floating-Point,
Version 2.2}

This chapter describes the standard double-precision floating-point
instruction-set extension, which is named ``D'' and adds
double-precision floating-point computational instructions compliant
with the IEEE 754-2008 arithmetic standard.  The D extension depends on
the base single-precision instruction subset F.

\section{D Register State}

The D extension widens the 32 floating-point registers, {\tt f0}--{\tt
  f31}, to 64 bits (FLEN=64 in Figure~\ref{fprs}).  The {\tt f}
registers can now hold either 32-bit or 64-bit floating-point values
as described below in Section~\ref{nanboxing}.

\begin{commentary}
FLEN can be 32, 64, or 128 depending on which of the F, D, and Q
extensions are supported.  There can be up to four different
floating-point precisions supported, including H, F, D, and Q.
\end{commentary}

\section{NaN Boxing of Narrower Values}
\label{nanboxing}

When multiple floating-point precisions are supported, then valid
values of narrower $n$-bit types, \mbox{$n<$ FLEN}, are represented in
the lower $n$ bits of an FLEN-bit NaN value, in a process termed
NaN-boxing.  The upper bits of a valid NaN-boxed value must be all 1s.
Valid NaN-boxed $n$-bit values therefore appear as negative quiet NaNs
(qNaNs) when viewed as any wider $m$-bit value, \mbox{$n < m \leq$
  FLEN}.  Any operation that writes a narrower result to an {\tt f}
register must write all 1s to the uppermost FLEN$-n$ bits to yield a
legal NaN-boxed value.

\begin{commentary}
Software might not know the current type of data stored in a
floating-point register but has to be able to save and restore the
register values, hence the result of using wider operations to
transfer narrower values has to be defined.  A common case is for
callee-saved registers, but a standard convention is also desirable for
features including varargs, user-level threading libraries, virtual
machine migration, and debugging.
\end{commentary}

Floating-point $n$-bit transfer operations move external values held
in IEEE standard formats into and out of the {\tt f} registers, and
comprise floating-point loads and stores (FL$n$/FS$n$) and
floating-point move instructions (FMV.$n$.X/FMV.X.$n$).  A narrower
$n$-bit transfer, \mbox{$n<$ FLEN}, into the {\tt f} registers will create a
valid NaN-boxed value.  A narrower $n$-bit transfer out of
the floating-point registers will transfer the lower $n$ bits of the
register ignoring the upper FLEN$-n$ bits.

Apart from transfer operations described in the previous paragraph,
all other floating-point operations on narrower $n$-bit operations,
\mbox{$n<$ FLEN}, check if the input operands are correctly NaN-boxed,
i.e., all upper FLEN$-n$ bits are 1.  If so, the $n$ least-significant
bits of the input are used as the input value, otherwise the input
value is treated as an $n$-bit canonical NaN.

\begin{commentary}
Earlier versions of this document did not define the behavior of
feeding the results of narrower or wider operands into an operation,
except to require that wider saves and restores would preserve the
value of a narrower operand.  The new definition removes this
implementation-specific behavior, while still accommodating both
non-recoded and recoded implementations of the floating-point unit.
The new definition also helps catch software errors by propagating
NaNs if values are used incorrectly.

Non-recoded implementations unpack and pack the operands to IEEE
standard format on the input and output of every floating-point
operation.  The NaN-boxing cost to a non-recoded implementation is
primarily in checking if the upper bits of a narrower operation
represent a legal NaN-boxed value, and in writing all 1s to the upper
bits of a result.

Recoded implementations use a more convenient internal format to
represent floating-point values, with an added exponent bit to allow
all values to be held normalized.  The cost to the recoded
implementation is primarily the extra tagging needed to track the
internal types and sign bits, but this can be done without adding new
state bits by recoding NaNs internally in the exponent field.  Small
modifications are needed to the pipelines used to transfer values in
and out of the recoded format, but the datapath and latency costs are
minimal.  The recoding process has to handle shifting of input
subnormal values for wide operands in any case, and extracting the
NaN-boxed value is a similar process to normalization except for
skipping over leading-1 bits instead of skipping over leading-0 bits,
allowing the datapath muxing to be shared.
\end{commentary}

\section{Double-Precision Load and Store Instructions}
\label{fld_fsd}

The FLD instruction loads a double-precision floating-point value from
memory into floating-point register {\em rd}.  FSD stores a double-precision
value from the floating-point registers to memory.
\begin{commentary}
The double-precision value may be a NaN-boxed single-precision value.
\end{commentary}

\vspace{-0.2in}
\begin{center}
\begin{tabular}{M@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{imm[11:0]} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{width} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
12 & 5 & 3 & 5 & 7 \\
offset[11:0] & base & D & dest & LOAD-FP \\
\end{tabular}
\end{center}

\vspace{-0.2in}
\begin{center}
\begin{tabular}{O@{}R@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{25} &
\instbitrange{24}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{imm[11:5]} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{width} &
\multicolumn{1}{c|}{imm[4:0]} &
\multicolumn{1}{c|}{opcode} \\
\hline
7 & 5 & 5 & 3 & 5 & 7 \\
offset[11:5] & src & base & D & offset[4:0] & STORE-FP \\
\end{tabular}
\end{center}

FLD and FSD are only guaranteed to execute atomically if the effective address
is naturally aligned and XLEN$\geq$64.

FLD and FSD do not modify the bits being transferred; in particular, the
payloads of non-canonical NaNs are preserved.

\section{Double-Precision Floating-Point Computational Instructions}

The double-precision floating-point computational instructions are
defined analogously to their single-precision counterparts, but operate on
double-precision operands and produce double-precision results.
\vspace{-0.2in}
\begin{center}
\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{27} &
\instbitrange{26}{25} &
\instbitrange{24}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{funct5} &
\multicolumn{1}{c|}{fmt} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{rm} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
5 & 2 & 5 & 5 & 3 & 5 & 7 \\
FADD/FSUB & D & src2 & src1 & RM  & dest & OP-FP  \\
FMUL/FDIV & D & src2 & src1 & RM  & dest & OP-FP  \\
FMIN-MAX  & D & src2 & src1 & MIN/MAX & dest & OP-FP  \\
FSQRT     & D & 0    & src  & RM  & dest & OP-FP  \\
\end{tabular}
\end{center}

\vspace{-0.2in}
\begin{center}
\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{27} &
\instbitrange{26}{25} &
\instbitrange{24}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{rs3} &
\multicolumn{1}{c|}{fmt} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{rm} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
5 & 2 & 5 & 5 & 3 & 5 & 7 \\
src3 & D & src2 & src1 & RM  & dest & F[N]MADD/F[N]MSUB  \\
\end{tabular}
\end{center}

\section{Double-Precision Floating-Point Conversion and Move Instructions}

Floating-point-to-integer and integer-to-floating-point conversion
instructions are encoded in the OP-FP major opcode space.
FCVT.W.D or FCVT.L.D converts a double-precision floating-point number
in floating-point register {\em rs1} to a signed 32-bit or 64-bit
integer, respectively, in integer register {\em rd}.  FCVT.D.W
or FCVT.D.L converts a 32-bit or 64-bit signed integer,
respectively, in integer register {\em rs1} into a
double-precision floating-point
number in floating-point register {\em rd}. FCVT.WU.D,
FCVT.LU.D, FCVT.D.WU, and FCVT.D.LU variants
convert to or from unsigned integer values.
For RV64, FCVT.W[U].D sign-extends the 32-bit result.
FCVT.L[U].D and FCVT.D.L[U] are RV64-only instructions.
The range of valid inputs for FCVT.{\em int}.D and
the behavior for invalid inputs are the same as for FCVT.{\em int}.S.

All floating-point to integer and integer to floating-point conversion
instructions round according to the {\em rm} field.  Note FCVT.D.W[U] always
produces an exact result and is unaffected by rounding mode.

\vspace{-0.2in}
\begin{center}
\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{27} &
\instbitrange{26}{25} &
\instbitrange{24}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{funct5} &
\multicolumn{1}{c|}{fmt} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{rm} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
5 & 2 & 5 & 5 & 3 & 5 & 7 \\
FCVT.{\em int}.D & D & W[U]/L[U] & src & RM  & dest & OP-FP  \\
FCVT.D.{\em int} & D & W[U]/L[U] & src & RM  & dest & OP-FP  \\
\end{tabular}
\end{center}

The double-precision to single-precision and single-precision to
double-precision conversion instructions, FCVT.S.D and FCVT.D.S, are
encoded in the OP-FP major opcode space and both the source and
destination are floating-point registers.  The {\em rs2} field
encodes the datatype of the source, and the {\em fmt} field encodes
the datatype of the destination.  FCVT.S.D rounds according to the
RM field; FCVT.D.S will never round.

\vspace{-0.2in}
\begin{center}
\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{27} &
\instbitrange{26}{25} &
\instbitrange{24}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{funct5} &
\multicolumn{1}{c|}{fmt} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{rm} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
5 & 2 & 5 & 5 & 3 & 5 & 7 \\
FCVT.S.D & S & D & src & RM  & dest & OP-FP  \\
FCVT.D.S & D & S & src & RM  & dest & OP-FP  \\
\end{tabular}
\end{center}

Floating-point to floating-point sign-injection instructions, FSGNJ.D,
FSGNJN.D, and FSGNJX.D are defined analogously to the single-precision
sign-injection instruction.

\vspace{-0.2in}
\begin{center}
\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{27} &
\instbitrange{26}{25} &
\instbitrange{24}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{funct5} &
\multicolumn{1}{c|}{fmt} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{rm} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
5 & 2 & 5 & 5 & 3 & 5 & 7 \\
FSGNJ & D & src2 & src1 & J[N]/JX & dest & OP-FP  \\
\end{tabular}
\end{center}

For XLEN$\geq$64 only, instructions are provided to move bit patterns
between the floating-point and integer registers.  FMV.X.D moves the
double-precision value in floating-point register {\em rs1} to a
representation in IEEE 754-2008 standard encoding in integer register
{\em rd}.  FMV.D.X moves the double-precision value encoded in IEEE
754-2008 standard encoding from the integer register {\em rs1} to the
floating-point register {\em rd}.

FMV.X.D and FMV.D.X do not modify the bits being transferred; in particular, the
payloads of non-canonical NaNs are preserved.

\vspace{-0.2in}
\begin{center}
\begin{tabular}{R@{}F@{}R@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{27} &
\instbitrange{26}{25} &
\instbitrange{24}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{funct5} &
\multicolumn{1}{c|}{fmt} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{rm} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
5 & 2 & 5 & 5 & 3 & 5 & 7 \\
FMV.X.D & D & 0    & src  & 000  & dest & OP-FP  \\
FMV.D.X & D & 0    & src  & 000  & dest & OP-FP  \\
\end{tabular}
\end{center}

\begin{commentary}
  Early versions of the RISC-V ISA had additional instructions to
  allow RV32 systems to transfer between the upper and lower portions
  of a 64-bit floating-point register and an integer register.
  However, these would be the only instructions with partial register
  writes and would add complexity in implementations with recoded
  floating-point or register renaming, requiring a pipeline read-modify-write
  sequence.  Scaling up to handling quad-precision for RV32 and RV64
  would also require additional instructions if they were to follow
  this pattern.  The ISA was defined to reduce the number of explicit
  int-float register moves, by having conversions and comparisons
  write results to the appropriate register file, so we expect the
  benefit of these instructions to be lower than for other ISAs.

  We note that for systems that implement a 64-bit floating-point unit
  including fused multiply-add support and 64-bit floating-point loads
  and stores, the marginal hardware cost of moving from a 32-bit to
  a 64-bit integer datapath is low, and a software ABI supporting 32-bit
  wide address-space and pointers can be used to avoid growth of
  static data and dynamic memory traffic.
\end{commentary}

\section{Double-Precision Floating-Point Compare Instructions}

The double-precision floating-point compare instructions are
defined analogously to their single-precision counterparts, but operate on
double-precision operands.

\vspace{-0.2in}
\begin{center}
\begin{tabular}{S@{}F@{}R@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{27} &
\instbitrange{26}{25} &
\instbitrange{24}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{funct5} &
\multicolumn{1}{c|}{fmt} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{rm} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
5 & 2 & 5 & 5 & 3 & 5 & 7 \\
FCMP & D & src2 & src1 & EQ/LT/LE & dest & OP-FP  \\
\end{tabular}
\end{center}

\section{Double-Precision Floating-Point Classify Instruction}

The double-precision floating-point classify instruction, FCLASS.D, is
defined analogously to its single-precision counterpart, but operates on
double-precision operands.

\vspace{-0.2in}
\begin{center}
\begin{tabular}{S@{}F@{}R@{}R@{}F@{}R@{}O}
\\
\instbitrange{31}{27} &
\instbitrange{26}{25} &
\instbitrange{24}{20} &
\instbitrange{19}{15} &
\instbitrange{14}{12} &
\instbitrange{11}{7} &
\instbitrange{6}{0} \\
\hline
\multicolumn{1}{|c|}{funct5} &
\multicolumn{1}{c|}{fmt} &
\multicolumn{1}{c|}{rs2} &
\multicolumn{1}{c|}{rs1} &
\multicolumn{1}{c|}{rm} &
\multicolumn{1}{c|}{rd} &
\multicolumn{1}{c|}{opcode} \\
\hline
5 & 2 & 5 & 5 & 3 & 5 & 7 \\
FCLASS & D & 0 & src & 001 & dest & OP-FP  \\
\end{tabular}
\end{center}


\documentclass[a4paper]{article}

\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{enumerate}
\usepackage{paralist}
\usepackage{xspace}
\usepackage{fullpage}
\usepackage{color}

\newcommand{\mascot}{\textsf{MASCOT}\xspace}
\newcommand{\scots}{\textsf{SCOTS}\xspace}

\begin{document}
%	\section{Scope of the Repeatability Evaluation}
%		The following elements of the paper can be evaluated using the provided REP package:
%		\begin{compactitem}
%			\item Table~1
%			\item Table~2
%			\item Table~3
%			\item Figure~4
%			\item Figure~5
%		\end{compactitem}
	\section{System Requirements}
		We have built \mascot on top of \scots \cite{Scots}. Therefore, the system requirements and the installation procedure for our software are the same as for \scots. As for \scots, you need a working C++ developer environment, the CUDD library \cite{somenzi2009cudd}, and a working installation of a recent version of MATLAB (the latter is only used for the visualization of some results). Following are the requirements as detailed in the manual of \scots:
		\begin{enumerate}
			\item A working C++ developer environment:
				\begin{itemize}
					\item Mac OS: Install the latest version of Xcode.app including the command line tools.
					\item Linux: Most Linux OS distributions already include all the necessary tools already. We used the compiler GCC 4.9.x.
					\item Windows: \scots has not been tested on a Windows machine.
				\end{itemize}
			\item A working installation of the CUDD library with
				\begin{itemize}
					\item the C++ object oriented wrapper,
					\item the dddmp library, and
					\item the shared library
				\end{itemize}
				option enabled. The package follows the usual configure, make and make install installation routine. We use cudd-3.0.0, with the configuration
				\begin{verbatim}
					$ ./configure --enable-shared --enable-obj --enable-dddmp --prefix=/opt/local/
				\end{verbatim}
				The BDD installation can be tested by compiling a dummy program, e.g. test.cc
				%\hline
				\begin{verbatim}
					#include<iostream>
					#include "cuddObj.hh"
					#include "dddmp.h"
					int main () {
						Cudd mgr(0,0);
						BDD x = mgr.bddVar();
					}
				\end{verbatim}
				%\hline
				by running
				\begin{verbatim}
					$ g++ test.cc -I/opt/local/include -L/opt/local/lib -lcudd
				\end{verbatim}
				It has been reported that on some linux machines, the header files \texttt{util.h} and \texttt{config.h} were missing in \texttt{/opt/local}, and the fix is to manually copy the files to \texttt{/opt/local/include} by running
				\begin{verbatim}
					 $ sudo cp ./util/util.h /opt/local/include/
					 $ sudo cp ./config.h /opt/local/include/
				\end{verbatim}
			\item A working installation of a recent version of MATLAB. We conducted our experiments with version R2016a (9.0.0.341360) 64-bit. To compile the mex files:
				\begin{enumerate}[(a)]
					\item open MATLAB and setup the mex compiler by
						\begin{verbatim}
							>> mex -setup C++
						\end{verbatim}
					\item Open a terminal and go to \texttt{./mfiles/mexfiles/} (within the \mascot directory, see below). Edit the \texttt{Makefile} and adjust the variables
						\begin{verbatim}
							MATLABROOT and CUDDPATH
						\end{verbatim}
						and run
						\begin{verbatim}
						$ make
						\end{verbatim}
						(The MATLAB root directory is returned when typing \texttt{matlabroot} in the command window of MATLAB.)
				\end{enumerate}
		\end{enumerate}
	\section{Directory Structure}
	After you unzip \mascot, you will see the following directory structure:
		\begin{itemize}
			\item \texttt{./bdd/} Contains the C++ source code for the \scots and \mascot classes which use Binary Decision Diagrams as the underlying data structure
			\item \texttt{./doxygen/} C++ Class documentation directory
			\item \texttt{./manual/} Both \scots and \mascot manuals
			\item \texttt{./mascot\_examples/} Examples which were used in the papers \cite{hsu2018lazy1, hsu2018lazy2} demonstrating the usage and performance of \mascot
			\item \texttt{./mfiles} Contains an mfile as a wrapper to the mex-file functions
			\item \texttt{./mfiles/mexfiles/} mex-file to read the C++ output from file
			\item \texttt{./scots\_examples/} Some C++/Matlab programs demonstrating the usage of basic \scots
			\item \texttt{./test/} Some C++/Matlab test programs
			\item \texttt{./utils/} Some C++ header files used by the source codes in \texttt{./bdd/}
		\end{itemize}
	\section{Getting Started}
	 	For validating any of the tables/figures presented in the paper
	 		\begin{enumerate}
%	 			\item go to the corresponding sub-directory in \texttt{./REP\_examples/}. For example, for validating the data in Table 1 of the paper, go to \texttt{./REP\_examples/Table1}.
%	 			\item Inside you will find different sub-directories containing different test cases as presented in the corresponding table/figure. The names of the sub-directories are self-explanatory. For example, inside \texttt{./REP\_examples/Table1}, you will find \texttt{./REP\_examples/Table1/unicycle1A}, \texttt{./REP\_examples/Table1/unicycle2A} and \texttt{./REP\_examples/Table1/unicycle3A}, representing the 1-layered (normal \scots), 2-layered and 3-layered reachability algorithms respectively.
				\item Go to a sub-directory in one of the example folders.
	 			\item Edit the \texttt{Makefile}:
	 				\begin{enumerate}[(a)]
	 					\item adjust the compiler, and
	 					\item adjust the directories of the CUDD library.
	 				\end{enumerate}
	 			\item Compile and run the executable, for example in \texttt{./mascot\_examples/safety/dcdc/LazySafe/dcdc3A/} run
	 				\begin{verbatim}
	 					$ make
	 					$ ./dcdc
	 				\end{verbatim}
	 			%\item Use the .m files to plot results. \textcolor{red}{todo: discuss different modes}
	 		\end{enumerate}
%	 	For Figure 4, you need to perform one more step to plot the trajectory of the unicycle:
%	 	\begin{enumerate}
%	 		\item Open \texttt{MATLAB} and change the working directory to\linebreak \texttt{./REP\_examples/Figure4/unicycle3A}.
%	 		\item In the command window, run
%	 			\begin{verbatim}
%	 				>> unicyclePlot(`plot',3,C)
%	 			\end{verbatim}
%	 			by replacing \texttt{C} with the highest controller number saved in the folder \linebreak \texttt{./REP\_examples/Figure4/unicycle3A/C} (after the executable is run). E.g., if this folder contains files \texttt{C1.bdd} to \texttt{C15.bdd}, replace \texttt{C} by $15$.
%	 	\end{enumerate}
%	 	For Figure~5, Table~1, Table~2 and Table~3, the abstraction and the synthesis times for different number of layers can be found in the log files (\texttt{.txt}-file) stored in the corresponding folders.

	 	\bibliographystyle{plain}
	 	\bibliography{reportbib}
\end{document}


\documentclass[a4paper, 12pt]{article}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{dsfont}
\usepackage[left=2cm, right=2cm, bottom=3cm, top=2cm]{geometry}
\usepackage{graphicx}
\usepackage[utf8]{inputenc}
\usepackage{microtype}
\usepackage{natbib}

\title{Poisson process notes}
\author{Brendon J. Brewer}
\date{}

\begin{document}
\maketitle

%\abstract{\noindent Abstract}

% Need this after the abstract
\setlength{\parindent}{0pt}
\setlength{\parskip}{8pt}

Let $\lambda(t)$ be the rate function. In the current implementation
it is constant, $\lambda(t) = \lambda$,
but it won't always be.

\section{Handling of discrete time}
Time is block height, where one unit equals 2.5 minutes.
The probability of $x_t$ tips in block $t$ is
\begin{align}
p(x_t \,|\, \lambda_t) &= \frac{\lambda_t^{x_t}\exp(-\lambda_t)}{x_t!}
\end{align}

Currently the data starts from the first claim and ends at the current
block height. Any tips before the first claim are considered spurious and
discarded.

Discrete time is currently handled by adding a random offset to the
block times, but that's what I want to fix.

\bibliographystyle{plainnat}
\bibliography{references}

\end{document}


\subsection{gammapy.datasets}
\label{ssec:gammapy-datasets}
\todo{Atreyee Sinha}

The end product of the data reduction process described in Section
\ref{ssec:gammapy-makers} are a set of binned counts, background and IRF maps,
at the DL4 level. The gammapy.datasets subpackage contains classes to bundle
together binned data along with associated models and the likelihood, which
provides an interface to the Fit class (Sec \ref{ssec:gammapy-modeling}) for
modeling and fitting purposes. Depending upon the type of analysis and the
associated statistics, different types of Datasets are supported. MapDataset is
used for 3D (spectral and morphological) fitting, and a 1D spectral fitting is
done using SpectrumDatastet. While the default statistics for both of these is
Cash, their corresponding OnOff versions are adapted for the case where the
background is measured from real off counts, and support wstat statistics. The
predicted counts are computed by convolution of the models with the associate
IRFs. Fitting of precomputed flux points is enabled through FluxPointsDatasets,
using chi2 statistics. Multiple datasets of same or different types can be
bundled together in Datasets (e.g., Figure \ref{fig*:minted:gp_datasets}),
where the likelihood from each constituent member is added, thus facilitating
joint fitting across different observations, and even different instruments
across different wavelengths. Datasets also provide functionalities for
manipulating reduced data, eg: stacking, sub-grouping, plotting, etc. Users can
also create their customized datasets for implementing modified likelihood
methods.

\begin{figure}
	\import{code-examples/generated/}{gp_datasets}
	\caption{A Datasets container with FluxPointsDataset and MapDataset}
	\label{fig*:minted:gp_datasets}
\end{figure}


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

\chapter{Getting Started}
\label{ch-Getting-Started}

Before writing any code:

\begin{enumerate}

\item
{\bf Choose a conceptual interface (see Sections
\ref{sec-What-are-conceptual-interfaces} and
\ref{sec-Which-conceptual-interface}).}
Generally, the choice is fairly obvious.  A structured-grid interface
is clearly inappropriate for an unstructured-grid application.  It is
desirable to use a more specific interface if appropriate, e.g., the
linear-algebraic interface is usable from any type of grid but will
involve much more user work and prevent access to some
grid-type-specific preconditioners.

\item
{\bf Choose your desired solver strategy.}  For the typical user, this
will mean a single Krylov method and a single preconditioner.

\item
{\bf Look up matrix requirements for each solver and preconditioner.}
Each specific solver and preconditioner has requirements from the
input matrix.  This information is provided in several places: Chapter
\ref{ch-Solvers}, the \hypre{} Reference Manual, and
the \hypre{} header files.

\item
{\bf Choose a matrix class that is compatible with your solvers and
preconditioners and your conceptual interface.}  Note that some of the
interfaces currently only support one matrix class choice.

\end{enumerate}
Once the previous decisions have been made, it is time to code your
application to call \hypre{}:
\begin{enumerate}

\item
{\bf Build any necessary auxiliary structures for your chosen
conceptual interface.} This includes, e.g., the grid and stencil
structures if you are using the structured-grid interface.

\item
{\bf Build the matrix, solution vector, and right-hand-side vector
through your chosen conceptual interface.}  Each conceptual interface
provides a series of calls for entering information about your problem
into \hypre{}.

\item
{\bf Build solvers and preconditioners and set solver parameters
(optional).}  Some parameters like convergence tolerance are the same
across solvers, while others are solver specific.

\item
{\bf Call the solve function for the solver.}

\item
{\bf Retrieve desired information from solver.} Depending on your
application, there may be different things you may want to do with the
solution vector.  Also, performance information such as number of
iterations is typically available, though it may differ from solver to
solver.

\end{enumerate}

%-----------------------------------------------------------------------------

\section{A Simple Example}
\label{sec-Simple-Example}

The following code serves as a simple example of the usage of \hypre{}.  In
this example, the structured-grid interface (discussed in Chapter
~\ref{ch-Struct}) is used to enter the problem into \hypre{}, and the
\code{PFMG} Multigrid solver is used to solve the system.  Since the
structured-grid interface currently only supports one underlying matrix class,
there are no choices to make here.  If we were using the semi-structured grid
interface instead, then we would have to choose between the \code{SStruct} and
\code{ParCSR} matrix classes, depending on the solver we want to use.

This example and all other examples in this manual are written in C,
but \hypre{} also supports Fortran.  See Section
\ref{sec-Fortran} for details.

\begin{display}
\begin{verbatim}

/*-----------------------------------------------------------
 * Set up the grid and stencil
 *-----------------------------------------------------------*/

HYPRE_StructGridCreate(MPI_COMM_WORLD, dim, &grid);
HYPRE_StructGridSetExtents(grid, ilower, iupper);
...
HYPRE_StructGridAssemble(grid);

HYPRE_StructStencilCreate(dim, stencil_size, &stencil);
HYPRE_StructStencilSetElement(stencil, 0, offset0);
...

/*-----------------------------------------------------------
 * Set up the matrix, right-hand side, and initial guess
 *-----------------------------------------------------------*/

HYPRE_StructMatrixCreate(MPI_COMM_WORLD, grid, stencil, &A);
HYPRE_StructMatrixInitialize(A);
HYPRE_StructMatrixSetBoxValues(A, ilower, iupper, nelts, elts, Avalues);
...
HYPRE_StructMatrixAssemble(A);

HYPRE_StructVectorCreate(MPI_COMM_WORLD, grid, &b);
HYPRE_StructVectorInitialize(b);
HYPRE_StructVectorSetBoxValues(b, ilower, iupper, bvalues);
...
HYPRE_StructVectorAssemble(b);

HYPRE_StructVectorCreate(MPI_COMM_WORLD, grid, &x);
HYPRE_StructVectorInitialize(x);
HYPRE_StructVectorSetBoxValues(x, ilower, iupper, xvalues);
...
HYPRE_StructVectorAssemble(x);

/*-----------------------------------------------------------
 * Set up the solver
 *-----------------------------------------------------------*/

HYPRE_StructPFMGCreate(MPI_COMM_WORLD, &solver);
HYPRE_StructPFMGSetMaxIter(solver, 50);     	 /* optional */
HYPRE_StructPFMGSetTol(solver, 1.0e-06);    	 /* optional */
HYPRE_StructPFMGSetup(solver, A, b, x);

/*-----------------------------------------------------------
 * Solve the linear system
 *-----------------------------------------------------------*/

HYPRE_StructPFMGSolve(solver, A, b, x);

/*-----------------------------------------------------------
 * Get solution info and free up memory
 *-----------------------------------------------------------*/

HYPRE_StructVectorGetBoxValues(x, ilower, iupper, xvalues);
...

HYPRE_StructPFMGDestroy(solver);
HYPRE_StructGridDestroy(grid);
HYPRE_StructStencilDestroy(stencil);
HYPRE_StructMatrixDestroy(A);
HYPRE_StructVectorDestroy(b);
HYPRE_StructVectorDestroy(x);

\end{verbatim}
\end{display}

%-----------------------------------------------------------------------------

\section{What are conceptual interfaces?}
\label{sec-What-are-conceptual-interfaces}

\begin{figure}
\centering
\includegraphics[width=5in]{fig_concep_iface}
\caption{%
Graphic illustrating the notion of conceptual interfaces.
All of these elements are not necessarily in \hypre{}.}
\label{fig-conceptual-interface}
\end{figure}

The top row of Figure~\ref{fig-conceptual-interface} illustrates a number of
conceptual interfaces.  Generally, the conceptual interfaces are denoted by
different types of computational grids, but other application features might
also be used, such as geometrical information.  These conceptual interfaces are
intended to represent the way that applications developers naturally think of
their linear problem, and provide natural interfaces for them to pass the data
that defines their linear system into \hypre{}.  Essentially, these conceptual
interfaces can be considered convenient utilities for helping a user build a
matrix data structure for \hypre{} solvers and preconditioners.  For example,
applications that use structured grids (such as in the left-most interface in
the Figure~\ref{fig-conceptual-interface}) typically view their linear problems
in terms of stencils and grids.  On the other hand, applications that use
unstructured grids and finite elements typically view their linear problems in
terms of elements and element stiffness matrices.  Finally, the right-most
interface is the standard linear-algebraic (matrix rows/columns) way of viewing
the linear problem.

The second row of Figure~\ref{fig-conceptual-interface} is a set of
linear solver algorithms.  Each linear solver group requires different
information from the user through the conceptual interfaces.  So, the
geometric multigrid algorithm (GMG) listed in the left-most box, for
example, can only be used with the left-most conceptual interface.  On
the other hand, the ILU algorithm in the right-most box may be used
with any conceptual interface.

The third row of Figure~\ref{fig-conceptual-interface} is a list of
data layouts or matrix/vector storage schemes.  The relationship
between linear solver and storage scheme is similar to that of
interface and linear solver.

%-----------------------------------------------------------------------------

\section{Which conceptual interface should I use?}
\label{sec-Which-conceptual-interface}

\hypre{} currently supports four conceptual interfaces:

\begin{itemize}

\item
{\bf Structured-Grid System Interface (\code{Struct}):} This interface is
appropriate for applications whose grids consist of unions of logically
rectangular grids with a fixed stencil pattern of nonzeros at each grid point.
This interface supports only a single unknown per grid point.  See Chapter
\ref{ch-Struct} for details.

\item
{\bf Semi-Structured-Grid System Interface (\code{SStruct}):} This
interface is appropriate for applications whose grids are mostly
structured, but with some unstructured features.  Examples include
block-structured grids, composite grids in structured adaptive mesh
refinement (AMR) applications, and overset grids.  This interface
supports multiple unknowns per cell.
See Chapter \ref{ch-SStruct} for details.

\item
{\bf Finite Element Interface (\code{FEI}):} This is appropriate for
users who form their linear systems from a finite element
discretization.  The interface mirrors typical finite element data
structures, including element stiffness matrices.  Though this
interface is provided in \hypre{}, its definition was determined
elsewhere (please email to Alan Williams william@sandia.gov for
more information).  See Chapter \ref{ch-FEI} for details.

\item
{\bf Linear-Algebraic System Interface (\code{IJ}):} This is the
traditional linear-algebraic interface.  It can be used as a last
resort by users for whom the other grid-based interfaces are not
appropriate.  It requires more work on the user's part, though still
less than building parallel sparse data structures.  General solvers
and preconditioners are available through this interface, but not
specialized solvers which need more information.  Our experience is
that users with legacy codes, in which they already have code for
building matrices in particular formats, find the IJ interface
relatively easy to use.
See Chapter \ref{ch-IJ} for details.

\end{itemize}

Generally, a user should choose the most specific interface that
matches their application, because this will allow them to use
specialized and more efficient solvers and preconditioners without
losing access to more general solvers.