\documentclass[11pt]{article}

\input{preamble}

%\usepackage{tikz}
%\usepackage{tikz-qtree}
\usepackage{qtree}
\usepackage{xfrac}

\title{week 3: ROC curves, Normalization and PCA}
\author{\url{http://mlvu.github.io}}
\begin{document}

\maketitle
\section{Exam questions}

At this point in the course, it's a good idea to have a look at the practice exam. The homework prepares you for the exam, but the format of the homework questions is different from that of the exam questions. Here are some questions you should be able to answer based on the material covered so far. You can find two complete practice exams on Canvas.

\begin{enumerate}
\item What is the advantage of gradient descent over random search?
\choicesv{In gradient descent, parallel searches are allowed to communicate.}{Gradient descent is less likely to get stuck in local minima.}{Gradient descent computes the direction of steepest descent, random search approximates it.\an}{Gradient descent is easier to parallelise.}

% 12 R
\item Why is accuracy a bad loss function to use in gradient descent?
\choicesv{It is expensive to compute.}{It makes the gradient zero almost everywhere. \an}{It is unreliable in situations with high class imbalance.}{The confidence interval is high on small test sets.}

% 11 R
\item I'm performing spam classification. I represent each email by three numbers: how often the word \emph{pill} occurs, how often the word \emph{hello} occurs and how often the word \emph{congratulations} occurs. What are these three attributes called?
\choicesv{The instances}{The classes}{The features \an}{The principal components}
\end{enumerate}

\noindent Here we see the derivation of the gradient of the squared-error loss for linear regression.

\begin{align}
\frac{\kp \frac{1}{2}\sum_i \left(f(x_i) - y_i\right)^2}{\kp b}	&= \frac{1}{2}\frac{\kp \sum_i \left(x_iw + b - y_i\right)^2}{\kp b}  \label{line:zero}\\
&= \frac{1}{2}\sum_i \frac{\kp \left(x_iw + b - y_i\right)^2}{\kp b} \label{line:sum}\\
&= \frac{1}{2}\sum_i \frac{\kp \left(x_iw + b - y_i\right)^ 2}{\kp \left(x_iw + b - y_i\right)} \frac{\kp \left(x_iw + b - y_i\right)}{\kp b} \label{line:chain}\\
&= \sum_i \left(x_iw + b - y_i\right) \frac{\kp \left(x_iw + b - y_i\right)}{\kp b} \label{line:exp}\\
&=  \ans{\sum_i\left ( x_iw + b - y_i\right)}{...} \label{line:final}
\end{align}

\begin{enumerate}[resume]

% 12 A
\item To get from line (\ref{line:zero}) to line (\ref{line:sum}), we use the
\choices{Chain rule}{Product rule}{Exponent rule}{Sum rule \an}

%12 A
\item To get from line (\ref{line:sum}) to line (\ref{line:chain}), we use the
\choices{Chain rule \an}{Product rule}{Exponent rule}{Sum rule}

\item In line \ref{line:final}, the correct result is
\choicesv{$\sum_i \left({x_i}^2w + b - y_i\right)$}{$\sum_i x_i \left(x_iw + b - y_i\right)$}{$\sum_i \left( x_iw + b - y_i\right)$ \an}{$\sum_i \left(x_iw + b - y_i\right)^2$}

\end{enumerate}

\section{ROC Curves and confusion matrices}

In this section, we'll look at evaluation metrics. This section covers the lecture ``Methodology 1'' and section 2.2 of Peter Flach's \emph{Machine Learning} (see the PDF on Canvas).

As a running example, we will use the following classification dataset:

\begin{center}
	\begin{tabular}{c c c c}
		& ${x_1}$ & ${x_2}$ & label\\
		\hline
		\kc{a} & 1 & 0 & \rc{Neg} \\
		\kc{b} & 2 & 0 & \bc{Pos} \\
		\kc{c} & 3 & 0 & \bc{Pos} \\
		\kc{d} & $\sfrac{1}{2}$ & 1 & \bc{Pos} \\
		\kc{e} & 2 & 2 & \bc{Pos} \\
		\kc{f} & 0 & 3 & \rc{Neg} \\
		\kc{g} & 1 & 3 & \rc{Neg} \\
		\kc{h} & 2 & 3 & \rc{Neg} \\
		\hline
	\end{tabular}
\end{center}
If you have trouble with the exercises below, we recommend drawing the data in its feature space, and drawing the decision boundary of each classifier.

\subsection{A linear classifier}

\qu As a first classifier, $c_\text{\oc{lin}}$, we will use a diagonal line crossing all the points where $x_1 = x_2$. Points above this line will be classified as \rc{Neg}, points below or on the line as \bc{Pos}. How do we describe this classifier mathematically? Fill in the blanks:
	\[
	c_\text{\oc{lin}}(x_1, x_2) = \begin{cases} \text{\bc{Pos}} & \text{ if } \ans{x_1 \geq x_2}{\ldots} \\ \text{\rc{Neg}} & \text{otherwise}\end{cases}\p
	\]
\ans{The diagonal that the question asks for (the decision boundary) is the set of points where $x_1 = x_2$. If $x_1 > x_2$, we're above this line, so we should classify the point as \bc{Pos}.}{}

\noindent $c_\text{lin}$ is a simple classifier. Let's try a more complex one before we move on.

\qu Let $c_\oc{2}$ be the classifier whose decision boundary crosses the points $(0, 1)$ and $(1, 1.5)$, with the class \emph{Neg} above the line. Draw this line first. How do we define this classifier?
	\[
	c_\oc{2}(x_1, x_2) = \begin{cases} \text{\bc{Pos}} & \text{ if } \ans{- 0.5 x_1 + x_2 - 1 < 0}{\ldots} \\ \text{\rc{Neg}} & \text{otherwise}\end{cases}
	\]
\ans{

We could fill the given values in to the equation $ax_1 + bx_2 + c = 0$ and solve for zero. But that would give us two problems: it's a lot of work, and we have two equations for three variables. There are infinitely many pairs $a$ and $b$ that would give us this decision boundary. Let's make things easier by assuming that $b$ is 1, and rewriting to $x_2 = -ax_1 - c$. This is just the familiar function for a line in the plane: $-a$ is the slope, and $-c$ is the bias.

The given points tell us that the line crosses the $x_2$ axis at 1, and the slope should be $0.5$. Thus, $-a = 0.5$ and $-c = 1$. A quick check tells us that for a point below the line, $(0,0)$, the quantity $- 0.5 x_1 + x_2 - 1$ is negative, so such points should be classified as \bc{Pos}.

Here is a diagram of the data and the boundaries for the two classifiers:

{\centering
\includegraphics[width=0.7\linewidth]{{w3.linear}.pdf}
}

}{}

\qu We will compare the linear classifier $c_\text{\oc{lin}}$ with a \emph{decision tree} classifier, $c_\text{\oc{tree}}$. Here is the decision tree:

\Tree[.{$x_2 > 1.5$?} [.{$x_1 > 0.5$?} [.{\ans{\bc{Pos}}{\oc{A}}} ][.{\ans{\bc{Pos}}{\oc{B}}} ] ][.{$x_1 > 1.5$?} [.{\ans{\rc{Neg}}{\oc{C}}} ][.{\ans{\bc{Pos}}{\oc{D}}} ] ] ]

\noindent If the inequality on the node is true, move right, otherwise move left.

This tree divides the feature space into four \textbf{segments} (\oc{A}, \oc{B}, \oc{C} and \oc{D}). To each segment we assign the majority class in that segment (using \bc{Pos} for a draw). Label the leaves \oc{A}, \oc{B}, \oc{C} and \oc{D} with classes.

\ans{Here is a diagram of the data and the boundaries for the tree classifier:

{\centering
\includegraphics[width=0.7\linewidth]{{w3.tree}.pdf}
}

}{}

\qu In this exercise we don't do any training (we just evaluate the given classifiers), so we'll evaluate all metrics on a single given dataset.

If you do train, you would \emph{split} your dataset. You would compute your evaluation metrics on the \ans{validation data}{\ldots} during hyperparameter selection and on the \ans{test data}{\ldots} during final testing.

Evaluating on the training data is the worst sin you can commit in Machine Learning. Can you think of a situation when you would still want to \emph{compute} the training loss?

\ans{Getting good training loss, but poor validation loss is a sure sign of overfitting. If overfitting is likely (as it is in decision trees and neural networks), you may want to compare the training loss to the validation loss to see if overfitting explains the poor performance.}{}

\qu Give the \emph{confusion matrices} for classifiers $c_\text{\oc{lin}}$ and $c_\text{\oc{tree}}$.
\ans{

\begin{center}
\begin{tabular}{c c | c c}
$c_\text{\oc{lin}}$  & & predicted & \\
 & & Pos & Neg \\
\hline
true & Pos & 3 & 1 \\
     & Neg & 1 & 3 \\
\end{tabular}
\end{center}

\begin{center}
\begin{tabular}{c c | c c}
$c_\text{\oc{tree}}$  & & predicted & \\
 & & Pos & Neg \\
\hline
true & Pos & 4 & 0 \\
     & Neg & 2 & 2 \\
\end{tabular}
\end{center}
}{}

\qu From the confusion matrices, we can compute several metrics. Compute the accuracy, precision, recall, true positive rate and false positive rate

\ans{
We compute these metrics from the four values of the confusion matrix: the number of true positives (TP), true negatives (TN), false positives (FP) and false negatives(FN):

\begin{center}
\begin{tabular}{c c | c c}
  & & predicted & \\
 & & \bc{Pos} & \rc{Neg} \\
\hline
true & \bc{Pos} & T\bc{P} & F\rc{N} \\
     & \rc{Neg} & F\bc{P} & T\rc{N} \\
\end{tabular}
\end{center}

\begin{center}
\bgroup
\def\arraystretch{2}
\begin{tabular}{r c c c}
& & $c_\text{\oc{lin}}$ & $c_\text{\oc{tree}}$	 \\
\hline
accuracy & $\frac{T\bc{P} + T\rc{N}}{\text{total}}$ & $\sfrac{3}{4}$ & $\sfrac{3}{4}$ \\
precision & $\frac{T\bc{P}}{T\bc{P} + F\bc{P}}$ & $\sfrac{3}{4}$ & $\sfrac{2}{3}$\\
recall & $\frac{T\bc{P}}{T\bc{P} + F\rc{N}}$ & $\sfrac{3}{4}$ & $1$ \\
true positive rate & $\frac{T\bc{P}}{T\bc{P} + F\rc{N}}$  & $\sfrac{3}{4}$ & $1$ \\
false positive rate & $\frac{F\bc{P}}{T\rc{N} + F\bc{P}}$  & $\sfrac{1}{4}$ & $\sfrac{1}{2}$\\
\end{tabular}
\egroup
\end{center}

Most of these are pretty intuitive, if you work out the meaning of the various sums. For instance, the false positive rate is the proportion of actual negatives, that were predicted to be positive.

}{}

\noindent To plot a ROC and precision/recall curves, and to compute AUC metrics, we need to turn our simple binary classifier into a \emph{ranking} classifier. That is, we don't just want classifications, we want it to rank the data from most \rc{Neg} to most \bc{Pos}. How we do this depends on the classifier.

\qu How do we turn a linear classifier into a ranking classifier? Give the ranking that $c_\text{lin}$ assigns to the training data.

\ans{We compute the distance to the classification boundary (the negative distance on one side, and the positive on the other), and rank points by this distance. For this course (the homework and the exam), you don't actually need to compute the distance, it's fine to draw the dataset and ``measure'' the distances. We'll make sure that all examples allow this approach.

Here's the sort of diagram you should end up with:

{\centering
\includegraphics[width=0.9\linewidth]{{w3.ranking}.pdf}
}

So, for $c_\text{\oc{lin}}$ the ranking from negative to positive is
\[
\bf{\rc{f}~\rc{g}~\rc{h}~\bc{d}~\bc{e}~\rc{a}~\bc{b}~\bc{c}}~\text{.}
\]}{}

\qu
How do we turn a decision tree classifier into a ranking classifier? Give the ranking that $c_\text{tree}$
 assigns to the training data.

\ans{
We group the points by the way the decision tree segments the feature space. We then assign each segment a class probability based on the relative frequencies of \emph{training} data points. We sort the groups by class probability. Points within the same group are ranked equal.

For $c_\text{\oc{tree}}$ the ranking from negative to positive is
\[
(\rc{\bf{f}}~\rc{\bf{g}})~(\rc{\bf{h}}~\bc{\bf{e}})~(\rc{\bf{a}}~\bc{\bf{b}}~\bc{\bf{c}})~(\bc{\bf{d}}) \text{.}
\]
Brackets indicate equal rank.
}{}

We can't tell whether our ranking is perfect, because the training data doesn't give us a correct \emph{ranking}, only a correct \emph{labeling}. But for some pairs of instances we \emph{do} know how they should be ranked: all pairs of positive and negative examples.

We can visualize this in a matrix with \rc{negative} instances on the horizontal axis, and \bc{positive} instances on the vertical, both sorted with the most positive (according to the classifier's ranking) in the bottom left corner. The matrix is usually colored \gc{green} for pairs that are ranked correctly, \rc{red} for pairs ranked incorrectly, and \yc{yellow} for pairs that are ranked equal.

\qu

\begin{enumerate}
\item Draw the coverage matrices of $c_\text{\oc{lin}}$ and $c_\text{\oc{tree}}$.

\ans{

\begin{center}
\begin{tabular}{c | c c c c}
	\bc{d} & \cellcolor{DarkRed}   & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} \\
	\bc{e} & \cellcolor{DarkRed}   & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} \\
	\bc{b} & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} \\
	\bc{c} & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} \\
	\hline
	$c_\text{\oc{lin}}$ & \rc{a} & \rc{h} & \rc{g} & \rc{f} \\
\end{tabular}
\end{center}

\begin{center}
\begin{tabular}{c | c c c c}
	\bc{e} & \cellcolor{DarkRed}   & \cellcolor{DarkOrange} & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} \\
	\bc{c} & \cellcolor{DarkOrange}   & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} \\
	\bc{b} & \cellcolor{DarkOrange} & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} \\
	\bc{d} & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} \\
	\hline
	$c_\text{\oc{tree}}$ & \rc{a} & \rc{h} & \rc{f} & \rc{g} \\
\end{tabular}
\end{center}

}{}

\item How many ranking errors does each classifier make on the training data?
\ans{$c_\text{lin}$ makes 2 ranking errors. $c_\text{tree}$ makes 2.5, counting each tie as half a ranking error.}{}

\item If we have class imbalance (one class has more instances than the other), how can we tell by the coverage matrix?

\ans{It will be non-square. The more stretched out, the higher the class imbalance.}{}

\end{enumerate}

\qu How do we convert a coverage matrix to an \textbf{ROC plot}? How does the green area in a coverage matrix relate to the ROC plot? How do they differ?

\ans{We can convert the coverage matrix to ROC space by normalizing the axes. That is, if we have a green cell at $(2, 3)$, counting from the bottom left, we can draw a point in ROC space at $(\sfrac{2}{4}, \sfrac{3}{4})$. That is, we know we have a classifier that can achieve a true positive rate of $\sfrac{3}{4}$ and a false negative rate of $\sfrac{2}{4}$.

{\centering
\includegraphics[width=0.9\linewidth]{{w3.roc}.pdf}
}

The green area gives us an estimate of the probability of a ranking error. The same is true of the \emph{Area Under the Curve}. For the latter, we draw the convex hull of all achievable classifiers, and compute the area.

An important difference is that the green area in a coverage matrix may be \emph{concave}. For instance:

\begin{center}
\begin{tabular}{c | c c c c}
	e & \cellcolor{DarkRed}   & \cellcolor{DarkRed} & \cellcolor{DarkRed} & \cellcolor{DarkGreen} \\
	c & \cellcolor{DarkRed}   & \cellcolor{DarkRed} & \cellcolor{DarkRed} & \cellcolor{DarkGreen} \\
	b & \cellcolor{DarkRed} & \cellcolor{DarkRed} &
	    \cellcolor{DarkRed} & \cellcolor{DarkGreen} \\
	d & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} & \cellcolor{DarkGreen} \\
	\hline
	$c_\text{poor}$ & a & h & f & g \\
\end{tabular}
\end{center}

The corresponding ROC curve is convex (it covers the bottom right half of the ROC space).

Since a classifier with AUC below 0.5 is pretty useless, we don't usually worry about this. The differences between the (normalized) coverage matrix and the ROC space are not important for reasonable classifiers and large datasets.

}{}

\section{Whitening}

\paragraph{Basis systems} The \emph{standard basis system} (in 2D) is just the vectors $b_1 =\begin{pmatrix}1 \\0\end{pmatrix}$ and $b_2 = \begin{pmatrix}0 \\1\end{pmatrix}$. When a point has coordinates $(x, y)$, that just means that we can get to the point by adding $x$ times the $b_1$ vector to $y$ times the $b_2$ vector.

For the standard basis, we just end up at the point $\begin{pmatrix}x \\y\end{pmatrix}$. But we can also use a nonstandard basis. If a point $p$ has coordinates $(x, y)$ in the coordinate system with basis vectors $b_1$, $b_2$, it means that $p$ has coordinates $xb_1 + yb_2$ in the standard basis system.

\qu Convert the following points to a representation in the standard basis system.

\begin{enumerate}
	\item The point $\begin{pmatrix}1 \\1\end{pmatrix}$ expressed in the coordinate system with basis vectors $b_1 = \begin{pmatrix}2 \\0\end{pmatrix}$, $b_2 = \begin{pmatrix}0 \\2\end{pmatrix}$. \ans{$x = 1, y=1$, so we get to the standard basis point by computing $1 \cdot b_1 + 1 \cdot b_1 = \begin{pmatrix}2 \\2\end{pmatrix}$}{}
	\item The point $\begin{pmatrix}5 \\3 \end{pmatrix}$ expressed in the coordinate system with basis vectors $b_1 = \begin{pmatrix}0 \\1\end{pmatrix}$, $b_2 = \begin{pmatrix}1 \\0\end{pmatrix}$. \ans{$\begin{pmatrix}3 \\5 \end{pmatrix}$}{}
	\item The point $\begin{pmatrix}1 \\2 \end{pmatrix}$ expressed in the coordinate system with basis vectors $b_1 = \begin{pmatrix}1 \\2\end{pmatrix}$, $b_2 = \begin{pmatrix}3 \\4\end{pmatrix}$. \ans{$\begin{pmatrix} 7\\ 10\end{pmatrix}$}{}
\end{enumerate}

\qu A basis system is \textbf{orthonormal} if two conditions hold:
\begin{enumerate}
	\item \ans{The basis vectors all have norm (i.e. length) 1. (normality)}{\ldots}
	\item \ans{The angles between any two basis vectors are $90\deg$. (orthogonality) }{\ldots}
\end{enumerate}
Consider the following three bases:
\[
	\A     = \begin{pmatrix}0 & 1\\1 & 1\end{pmatrix} \;\;
	\B     = \begin{pmatrix}1 & -1\\1 & 1\end{pmatrix} \;\;
	\bm{C} = \sqrt{\sfrac{1}{2}}\begin{pmatrix}1 & -1\\1 & 1\end{pmatrix}
\]
The columns of each matrix are the basis vectors (it may help to draw them in standard coordinates). Which of these have orthogonal basis vectors? Which one is orthonormal?
\ans{The columns of $\A$ are neither normal nor orthogonal. Matrix $\B$ has orthogonal columns, but they are not unit vectors (vectors of length one). Matrix $\C$ represents an orthonormal basis.}{}

\qu Why is it useful to have an orthonormal basis?
\ans{Matrices representing an orthonormal basis are \emph{orthogonal}. This means that $\C^{-1} = \C^T$. This means that we can easily transform from and to the basis without having to compute an expensive matrix inverse.}

\paragraph{Covariance and normal distributions}

PCA is closely related to the normal distribution. We can think of PCA as a basis transformation that makes it look like the data was sampled from a standard multivariate normal distribution: it makes the variance 1 in every dimension, and the covariance 0 for every pair of dimensions.

\qu Here is some data.

\begin{tabular}{c c}
$x_1$ & $x_2$ \\
\hline
0 & 2 \\
2 & 0 \\
0 & 2 \\
2 & 0 \\
\hline
\end{tabular}

\noindent Compute the sample covariance.

\ans{
We first compute the sample mean: $\bm{m} = \begin{pmatrix} 1 \\ 1\end{pmatrix}$.

Subtracting the sample mean, and arranging the data in a matrix (with instances as columns), we get
\[
\X =  \begin{pmatrix} -1 & 1 & -1 & 1 \\  1 & -1 & 1 & -1 \end{pmatrix} \p
\]

The sample covariance is
\begin{align*}
\bm{S} = \frac{1}{n-1} \X\X^T = \frac{1}{3}\begin{pmatrix} 4 & -4  \\  -4 & 4 \end{pmatrix}
\end{align*}
}{}

\noindent Let $\y = \A\x + \bt$ be an \emph{affine} transformation (a linear transformation $\A$ followed by a translation $\bt$). We draw $\x$ from a standard normal distribution
\[
N(\mathbf{0}, \mathbf{I}) = N\left( \begin{pmatrix}0 \\ 0\end{pmatrix}, \begin{pmatrix}1 & 0 \\ 0 & 1\end{pmatrix} \right)
\]
and compute $\y$. This is equivalent to sampling from a normal distribution with mean $\bm{\mu} = \bt$ and covariance $\bm{\Sigma} = \A\A^T $.

\qu Let
\[
\mathbf{A} = \begin{pmatrix} 1 & 0 \\ 0 & 2\end{pmatrix}, \mathbf{t} = \begin{pmatrix} 1 \\ 1\end{pmatrix}
\]
Sampling $\x$ from $N(\bm{0}, \bm{I})$ is easy: we just sample $x_1$ and $x_2$ independently from a \emph{uni}variate standard normal distributions. Here are some \href{https://goo.gl/Jw7Hjm}{standard normally distributed numbers}:
\[
0.5, 1.1, 0.1, 0.9, -0.2, 1.3
\]

\noindent Turn these into three samples from $N(\bm{0}, \bm{I})$ and transform them to samples from $N(\bm{\mu},\bm{\Sigma})$.

\ans{
Using samples
\[
\x^1 = \ma{0.5, & 1.1}^T, \;\; \x^2 = \ma{0.1, & 0.9}^T \;\; \x^3 = \ma{-0.2, & 1.3}^T
\]
and computing $\y^1 = \A\x^1 + \bt$, we get:
\[
\y^1 = \ma{1.5, & 3.2}^T, \;\; \y^2= \ma{1.1, & 2.8}^T \;\; \y^3 = \ma{0.8, & 3.6}^T\p
\]
}{}

\paragraph{Bonus question:} Compute the sample covariance of the resulting data, and the actual covariance $\Sigma$.

\ans{For the sample covariance, follow the same procedure as in the previous question. After a bit of calculating, we get:
\[
\bf{S} \approx \ma{0.123 & 0.06\\0.06 & 0.16}
\]

The true covariance we get by computing $\bf{\Sigma} =\A\A^T = \ma{1 & 0 \\ 0 & 4}$. They're quite different at the moment. If we increase the size of the sample, $\bf{S}$ will converge to $\bf{\Sigma}$.
}{}
%
%\paragraph{Singular value decomposition}
%\emph{These questions may be a little challenging if you're new to Linear Algebra. If you're struggling, have another look at the slides from the \emph{Methodology 2} lecture. If you can't work it out, read the answer, and see if you can repeat the process on another matrix.}
%
%\begin{Exercise}
%Let $\A$ be a linear transformation. This transformation has two eigenvectors, which are aligned with the standard basis vectors. The eigenvalue along the horizontal axis is $3$, and along the vertical axis is $2$. What is $\A$?
%
%\ans{$\A$ is a \emph{scaling matrix}. That means it's a diagonal matrix, with the eigenvalues on the diagonal:
%\[
%\begin{pmatrix} 3 & 0 \\ 0  & 2 \end{pmatrix}
%\]
%}{}
%\end{Exercise}
%
%Let $\B$ be a linear transformation. $\B$ has two eigenvectors, one points in the direction of the horizontal axis rotated by 45 degrees, and the other in the direction of the vertical axis rotated by 45 degrees.
%The eigenvalue for the first is 5, and for the second is 2. What is $\B$?
%\ans{
%If the eigenvectors were axis-aligned (as with $\A$), $\B$ would be
%\[
%\bm{Z} = \begin{pmatrix} 5 & 0 \\ 0  & 2 \end{pmatrix}
%\]
%We can use this by decomposing $\B$ in three steps: rotating by -45 degrees to align the axes to the eigenvectors, applying $\bm{Z}$ and rotating back. The rotation matrix for a 45 degree rotation is
%\[
%\U = \sqrt{\sfrac{1}{2}}\begin{pmatrix} 1 & -1 \\ 1 & 1\end{pmatrix} \p
%\]
%Since $\U$ is orthogonal (its columns form an orthonormal basis), we can take the transpose $\U^T$ to rotate back. Putting all this together, we get
%\[
%\B\x = \U\Z\U^T\x \p
%\]
%
%This is the eigenvalue decomposition of $\B$. This gives us
%
%\begin{align*}
%\B = \U\Z\U^T &= \sqrt{\sfrac{1}{2}}\begin{pmatrix}1 & -1\\1 & 1\end{pmatrix}\begin{pmatrix} 5 & 0 \\ 0 & 2\end{pmatrix}\sqrt{\sfrac{1}{2}}\begin{pmatrix}1 & 1\\-1 & 1\end{pmatrix}\\
%&= \frac{1}{2}\begin{pmatrix}1 & -1\\1 & 1\end{pmatrix}\begin{pmatrix} 5 & 0 \\ 0 & 2\end{pmatrix}\begin{pmatrix}1 & 1\\-1 & 1\end{pmatrix}\\
%&= \frac{1}{2}\begin{pmatrix}5 & -2\\5 & 2\end{pmatrix}\begin{pmatrix}1 & 1\\-1 & 1\end{pmatrix} \\
%&= \frac{1}{2}\begin{pmatrix}7 & 3\\3 & 7\end{pmatrix} = \begin{pmatrix}3.5 & 1.5\\1.5 & 3.5\end{pmatrix}
%\end{align*}
%
%%As usual, we can check with \href{https://goo.gl/v8d4Yg}{Wolfram Alpha} to see we haven't made any mistakes. You may get $-\U$ instead of $\U$. The negatives cancel out, so the SVD can work out both ways.
%}{}

\end{document}


\section{Introduction}

There has been a proliferation of new programming languages for audio Digital Signal Processing (DSP) including languages such as SuperCollider~\cite{supercollider}, Faust~\cite{orlarey2009faust}, and PureData~\cite{puredata}.
These languages provide a high-level interface to make DSP programming more approachable for new-comers to the field of audio programming.
DSP programming poses a particular challenge to novice programmers, as writing a DSP program requires an understanding of traditional programming concepts such as loops and conditionals, as well as the ability to reason about DSP issues such as time vs frequency domain.
To assist beginning DSP programmers we turn to the Programming by Example paradigm.

Programming by Example (PBE)~\cite{cypher93,lieberman01} is a program synthesis technique
where users do not write code directly, but instead provide examples that illustrate how the envisioned
code should behave. A PBE synthesis engine takes those input and output examples and
automatically generates code that implements the illustrated functionality. Of course, there might be more than
one program that is a good fit for the given examples, so the user may need to provide more examples.
However, the PBE techniques are based on various additional domain knowledge and heuristics, and have even been successfully applied in industrial software, for example in spreadsheets with the FlashFill tool~\cite{flashfill}.

Our goal is to make DSP programming more accessible to a larger audience by using Digital Signal Processing Programming by Example (DSP-PBE)~\cite{SantolucitoFARM}.
In order to do this, we developed a tool called \ourTool for DSP-PBE.
DSP-PBE is a paradigm that uses techniques from programming languages research to generate DSP programs based on audio input and output examples.
\ourTool extends prior work on DSP-PBE~\cite{SantolucitoFARM} with the ability to synthesize nontrivial filter types and generate a range of various code structures.
Additionally, \ourTool generates executable code, in SuperCollider, that allows the user to inspect, modify, and reuse the result of synthesis in their own coding projects.

\ourTool takes input $i$ and output $o$, which are audio files, and synthesizes the DSP program, $F$, that minimizes the distance between the transformed input, $F(i)$, and the output $o$.
A key part of this technique is that the user receives readable DSP program code that can be further tuned or edited as the user sees fit, opening the door for learning opportunities and creative invention.

\subsection{Motivating Example}

\begin{figure}
\begin{lstlisting}
(
SynthDef(\dsp_pbe, {|out=0|

   var main_in, id7, out6, lpf5, hpf4, psh1;
   main_in = PlayBuf.ar(2, ~buf);
   psh1 = FreqShift.ar(\pitchRatio, -399.999,
                       \mul, 0.55,
                       \in, In.ar());
   hpf4 = HPF.ar(\freq, 10100.0,
                 \mul, 1.562e-10,
                 \in, psh1);
   lpf5 = LPF.ar(\freq, 3860.002,
                 \mul, 0.85,
                 \in, psh1);
   out6 = Mix.ar(2, [hpf4, lpf5]);
   id7 = 0.7 * out6;
   Out.ar(out, id7);

}).add;
)
\end{lstlisting}
\caption{The SuperCollider program synthesized by \ourTool to simulate the effect of a trumpet hat mute.}
\label{fig:sc_code}
\end{figure}

In order to illustrate how \ourTool works, consider a scenario where a user wants apply the effect of a trumpet mute on their own sound, for example a recording of their voice.
The audio files for this example are given in our evaluation (cf. Sec.~\ref{sec:eval}, Table~\ref{table:eval}).
To start, a user provides an audio input example file of the trumpet without a mute (``00 none'' in Table~\ref{table:eval}), and an audio output example file (``01 hat'' in Table~\ref{table:eval}) of the trumpet playing the same note with the mute.
The user then invokes \ourTool on these two files, and the tool generates the SuperCollider program shown in Fig.~\ref{fig:sc_code}.
With this code, the user can then both use the program directly in a larger SuperCollider project, or edit the code directly.

In summary, this paper makes the following contributions.

\begin{enumerate}
\item We propose a framework for the synthesis of DSP programs that utilize noncommutative filter types
\item We propose an algorithm to search through the possible structural forms of a DSP filter program
\item We present our tool, \ourTool, which synthesizes SuperCollider programs from audio input/output examples, and evaluate \ourTool over a set of benchmarks
\end{enumerate}


This is implementation of efficient and simple model for simulation of
High-resolution atomic force microscopy (AFM), scanning probe microscopy (STM)
and inelastic tunneling microscopy (IETS) images using classical forcefileds.

There are two versions of the code:

\begin{enumerate}
   \item currently developed Python/C++ version in PyProbe\_nonOrtho (branch master
    );
        to get quick esence of this model you can also try web interface hostet here: http://nanosurf.fzu.cz/ppr/
        for more details see wikipage:
        https://github.com/ProkopHapala/ProbeParticleModel/wiki
   \item Legacy fortran version in SHTM\_springTip2 (branch fortran );
        more detailed description o the fortran version is here:
        http://nanosurf.fzu.cz/wiki/doku.php?id=probe\_particle\_model
\end{enumerate}
\cite{phapalamechhighresol}
\cite{phapalaoriginhighresol}

\section{C++ \& Python version}

\subsection{Examples of results}

\subsection{How it works}

\begin{itemize}

    \item  Pauli-repulsion ( currently approximated by repulsive part of
    Lenard-Jones potential $r^{-12}$ )
    \item van der Waals attraction ( currently approximated by attractive part
    of Lenard-Jones potentia $r^{-6}$ )
    \item electrostatic ( currently can be computed as coulomb pairwise
    interaction between PP and point charges in centers of atoms of sample, or
    by reading electrostatic force-field obtained by derivative of sample
    Hartree potential as described in supplementary of this paper
    \cite{phapalaoriginhighresol}.

\end{itemize}

The computation of images is divided into two parts:
\begin{enumerate}
    \item Precompute vector Forcefield ( Fx(x,y,z), Fy(x,y,z), Fz(x,y,z) ) over
    sample and store it on a 3D-grid. ( see getLenardJonesFF and getCoulombFF
    functions for more details ). After individial components of forcefiled are
    sampled ( i.e. Lenard-Jones and electrostatic ) they are summed up to form
    one single total effective forcefield in which Probe-Particle moves.

    \item relax Probe-Particle attached to the tip under influence of the total
    effective forcefield. The relaxation of Probe-Particle is done using "Fast
    Inertial Realxation Engine" (FIRE) algorithm
    \cite{ebitzekstructrelaxmadesimple}. implemented in
    FIRE:move() function. In each step of relaxation the forcefield on the grid
    is interpolated in interpolate3DvecWrap function, considering periodic
    boundary condition. From python the relaxation is called as relaxTipStroke
    function providing 1D-array of tip positions, and obtaining back 1D-array of
    Probe-Particle position after the relaxation and of force between tip
    ProbePartcile and sample at that position. The lateral scan in (x,y) to
    obtained stack of images is done by calling relaxTipStroke at different
    (x,y) position of tip, where each call of relaxTipStroke does one approach
    along z-direction.

\end{enumerate}

\subsection{Why it is splitted like this ?}

This splitting of computation ( first sampling of forcefiled on the grid, and
than relaxation using interpolation) has several advantages over strightforward
computation of interaction on the fly during relaxation process.

\begin{itemize}

    \item \textbf{It is faster} - if there is ~100 atoms of sample, summing over
    each pairwise Lennard-Jones interactions, is much slower, than just
    interpolating the forcefield from the grid. Because force evaluation is done
    several-times for each voxel of the 3D scanning grid, it is more efficient
    to precompute it just once for each voxel, and then interpolate.

    \item \textbf{It is more flexible and general} - Decoupling of relaxation
    process and computation of forcefiled allows us to plug-in any forcefield.
    The original motivation was to used electrostatic forcefield obtained from
    Hartree potential from DFT calculation. However, it is not limited to that.
    We can plug in e.g. a derivative of potential energy of probe peraticle
    (i.e. Xe or CO ) obtained by scanning it in DFT code, in similar way as Guo
    did in \cite{chshguohighresolmodel} . The only limitation here is computational cost of obtaining
    such potential from ab-initio calculation.
\end{itemize}

\subsection{Code structure}
The code is divided into Python and C++, where performance intensive
computations are done in C++ and python is used as convenient scripting
interface for doing tasks like file I/O, plotting, memory management. For
binding of Python and C++ is used python ctypes library.

\subsubsection{Dependencies:}
\begin{itemize}
    \item \textbf{C++} : g++ ( tested with g++ (Ubuntu 4.8.1-2ubuntu1~12.04) 4.8.1 )
    \item \textbf{Python} : python ( 2.7.3 ), numpy (1.9.2), matplotlib ( 1.4.3 ), ctypes
    ( 1.1.0 )
\end{itemize}

\subsubsection{C++ source:}
\begin{itemize}
    \item  ProbeParticle.cpp - implementation of all performance intensive
    ProbeParticle model as dynamic library which can be called dynamically from
    python.
    \item Vec3.cpp,Mat3.cpp math subroutines for operations with 3D vectors and
    metrices
\end{itemize}

\subsubsection{Python source:}
\begin{itemize}
    \item ProbeParticle.py - Interface between C++ core and python ising
    C-types. Here are also defined some python rutines like:
    \begin{itemize}
        \item  conversion from Force to frequency shift ( Fz2df ),
        \item  evaluation of Lenard-Jones coeffitints ( getAtomsLJ )
        \item  copy sample geometry to simulate periodic boundary condition (
        PBCAtoms )
        \item automatic setup of imagining area acroding to geometry of
        nonperiodic sample ( autoGeom )
        \item default parameters of simulation ( params ) with subroutine to
        read this parameters from a file ( loadParams )
    \end{itemize}

    \item  test2.py, testServer2.py - two examples of python scripts with run
    actual computations using ProbeParticle library. The idea is that this files
    can be modified by user to match particular task
    \item basUtils.py - routines for loading of molecule geometry from
    xyz-format, ( loadAtoms ), finding bonds and other.
    \item Element.py and elements.py contains just parameters of atoms form
    periodic table ( like effective raidus, color for visualization etc. ). It
    is used by basUtils.py

\end{itemize}


% !TEX root = collhdl_ICRA_17.tex

\section{Evaluation and Case Studies}
\label{sec:simu}

\subsection{General Simulation Setup}
\label{sec:setup}
The simulative setup is as follows.
We apply our collision detection, isolation and identification algorithm in simulation to an \emph{Atlas} robot consisting of cylinders and cuboids as collision geometry from \cite{DRCSim}.
We assume perfect measurements of the generalized joint forces and the force/torque sensors unless stated differently, meaning all sensors measure the true value without noise or delay.
Force/torque sensors are placed at the end-effectors (feet and hands), before the first arm and leg joints and at the upper torso after the three back joints (see Fig.~\ref{fig:coll_singlecontact_overview}).
Furthermore, all acting external forces comply with the assumption of a pushing force and the line of action of the forces is chosen such that it does not intersect with any other collision body before the contact point.
The robot pose (see Fig.~\ref{fig:coll_singlecontact_overview}) has been chosen in such a way that the whole body Jacobian has full rank.
The robot is modeled in free space, meaning there are no other external forces acting on the robot than the collision forces.
The simulation is done on a standard Core i7-3770 PC and the algorithm is run as compiled Matlab functions.
With the current implementation, the majority of the runtime for all contact cases is spent on the not yet optimized intersection algorithm.

\subsection{Ideal Analysis of Single Contacts}
\label{sec:eval_single_static}
We compare the ideal performance of the isolation based on estimated generalized external forces $\hat{\bm{\tau}}_\epsilon$ only (Sec.~\ref{sec:isolation}) to the isolation based only on force/torque sensor measurements $\hat{\bm{\mathcal{F}}}_{\mathrm{ext},S}$ (from (\ref{eqn:cmp})) for a single contact.
Dynamic effects due to the observer and load compensation are neglected for sake of clarity.
The contact points are distributed randomly and equally over the robot surface.
Figure~\ref{fig:coll_singlecontact_overview} depicts the results of the isolation procedures with some representative samples of the 3000 tested points.
With both methods, the contact points are isolated correctly up to rounding errors, if possible.
The contacts at the pelvis cannot be seen by any force/torque sensor and can therefore only be isolated with the generalized external forces acting on the base.
The maximum and mean execution times for the isolation of the one contact in this experiment were 0.67~ms and 0.25~ms using force/torque sensors as well as 0.57~ms and 0.17~ms using joint torque measurements only.
\begin{figure}
\begin{center}
\begin{overpic}{figures/collest_single_allresults_nosim/coll_est_sc_all_nosim}
\put(82,54){\line(-1,-2){7}}
\put(56,11){\line(1,2){11}}
\put(67,35){F/T sensor}
\end{overpic}
\end{center}
\caption{Distribution of true ($\bm{r}_\mathrm{C}$) and estimated contact locations using two different methods.
The points $\hat{\bm{r}}_C(\hat{\bm{\tau}}_\epsilon)$ are isolated using only generalized external forces and the points $\hat{\bm{r}}_C(\hat{\bm{\mathcal{F}}}_{\mathrm{ext,S}})$ are isolated using the force/torque sensor measurements only.
For the pelvis (base link) and first torso links, no force measurement is available. Therefore contact points at these links cannot be found with the latter method.
All overlying points are identical up to rounding errors.}
\vspace*{-0.8cm}
\label{fig:coll_singlecontact_overview}
\end{figure}

\subsection{Ideal Analysis of Multiple Contacts}
\label{sec:eval_multi_static}
In the following, we analyze multiple contacts of the type specified in Sec.~\ref{sec:eval_single_static}.

\subsubsection{Two Contacts at different links}

The considered contact points are located at different links, since two contacts at the same link cannot be located in our setup. In order to be able to do so, one would need two force/torque sensors in the same link.
5000 random combinations were examined.

The algorithm using generalized forces is able to isolate all two contact point coordinates up to rounding errors if the rank of the Jacobian in (\ref{eqn:force_identification}) is sufficiently high, e.g. $\mathrm{rank}(\bm{J})=12$ for $N_\mathrm{C}=2$ contact points.
Figure~\ref{fig:coll_multicontact_rankJ} shows the success of the isolation for different contact links, which is equivalent to the plot of the rank deficit
\begin{equation}
RD=6N_\mathrm{C}-\mathrm{rank}(\bm{J}).
\label{eqn:rank_deficit}
\end{equation}
For example, a contact at the pelvis (torso chain link 1) and another contact at the left lower leg (left leg chain link 4) does only produce 10 nonzero columns in the stacked Jacobian and the isolation fails (see corresponding entry in Fig.~\ref{fig:coll_multicontact_rankJ}).
If instead the foot on the left leg chain (link 6) is in contact, then 12 nonzero columns exist and the isolation succeeds.

For a rank deficit, the isolation method minimizes the Cartesian error of the stacked identified wrenches and finds contact points on the entire following kinematic chain.
The distribution of errors for different ranks of the Jacobian is shown in Fig.~\ref{fig:hist_rank_err_2coll}.
An error $\leq$ 25~cm occurs in about 80\% of the cases with the joint configuration from Fig.~\ref{fig:coll_singlecontact_overview}.
Please note that in case of a rank deficit, the algorithm may accidentally estimate an additional contact point, which would be located close to the base.
The error is then calculated between the real contact points and the ones estimated in the same kinematic chain.
The maximum and mean execution times for the isolation in this experiment were 0.75~ms and 0.28~ms using force/torque sensors as well as 31.8~ms and 3.6~ms using joint torque measurements only.

\begin{figure}
\begin{center}
\includegraphics[width=\columnwidth]{figures/collest_multi_stat_2coll_rankmat/rankmat_fig_2coll_Modus2}
\end{center}\vspace*{-0.3cm}
\caption{Overview of success and failure for the isolation of two simultaneous contacts.
The $x$-axis gives the first contact link and the $y$-axis the second one.
The second and the last body of the torso chain have no collision body in the model, the according columns are therefore left empty.
A green upward triangle marks the successful isolation of both contact points for the given combination.
A red downward triangle marks a combination for which it was impossible to isolate the contacts correctly due to rank loss of the combined Jacobian in (\ref{eqn:multi_iso}).
In some fields, green and red triangles are plotted meaning that for this combination, the isolation was only partly correct.
For the combination of the fifth link in the right leg and the first link of the right arm, this is due to the fact, that for some contacts, the joint torque threshold for the last joint is not exceeded and the algorithm is therefore started with a loss of rank in the Jacobian.
However, when reducing the joint torque threshold or starting the algorithm with the correct contact links, this could not be observed anymore.
In the other cases, the contact point was estimated correctly by accident with a rank deficient Jacobian.
Overall 5000 combinations were tested.}\vspace*{-0.5cm}
\label{fig:coll_multicontact_rankJ}
\end{figure}

\begin{figure}
\vspace*{-0cm}
\begin{center}
% Um die Prozentangaben für Overpic zu generieren: Skript histogram_error_rank.m im Bildordner ausführen und aus Textausgaben entnehmen.
\begin{overpic}{figures/collest_multi_stat_2coll_error_rank/hist_rank_err_2coll}
\put(50,78){\line(2,0){10}}
\put(63,76){$100\%$}

\put(49,47){\line(2,3){8}}
\put(56,61){$34\%$}

\put(43,35){\line(1,1){15}}
\put(55,52){$21\%$}

\put(55,36){\line(2,1){7}}
\put(55,40){$11\%$}

\put(68,17){\line(1,1){15}}
\put(80,34){$2\%$}
\end{overpic}
\end{center}
\caption{Histogram of the maximum point estimation error for two contacts with different random contact configurations. Read: ``34\% of the results for $\mathrm{rank}(\bm{J})=11$ lie between 15 and 25~cm.''}
\label{fig:hist_rank_err_2coll}
\vspace*{-0.3cm}
\end{figure}

\subsubsection{Contacts at four end-effectors}

For the considered 30~DoF humanoid, it is possible to detect and isolate up to $N_\mathrm{C}=5$ contacts, if the rank deficit $RD$ is zero.
This is the case for four contacts at the end-effectors of every kinematic chain (feet, hands) and an additional contact located at the torso or first shoulder link, which is the typical manipulation scenario from Fig~\ref{fig:manip}.
The distribution of position errors for this case are depicted in Fig.~\ref{fig:error_rank_manipcoll} with markers for different rank deficits $RD$.

Without rank deficit, the isolation is successful in all but 5 of the 5000 examined points, where there was no rank deficit.
The errors occur in situations, where the joint torque threshold for the last joint in at least one chain is not exceeded.
This leads to a Jacobian with rank-deficit for the first iteration step of the algorithm, making it in a few cases impossible to find the correct contact link.
However, if the threshold is reduced to $10^{-5}$~N or Nm (for all  $\lVert\bm{f}_{\mathrm{ext},i}\rVert<1$), or the algorithm is started with perfect information about the contact links, no errors are observed.
The maximum and mean execution times for the isolation in this experiment were 0.92~ms and 0.52~ms using force/torque sensors as well as 43.2~ms and 11.0~ms using joint torque measurements only.

\begin{figure*}
\begin{center}
\includegraphics{figures/collest_multi_stat_manipcoll_error/error_rank_manipcoll_hist_breit}
\end{center}\vspace*{-0.4cm}
\caption{Distribution of the isolation position error based on joint torques only with contacts at all end-effectors for different rank deficits $RD$ of the Jacobian.
The position error distributions are drawn over the location for a fifth contact.
The fifth contact location can be none (only four contacts) or any of the links, which are not an end-effector link.
Therefore the four columns of the end-effectors are left empty.
The columns of the second and the last torso chain link are left empty, because their model does not have any contact bodies, making it impossible to place contacts at these links.
Markers in the lines denote the mean errors of all contact points including this link.
The distribution lines are normalized to the highest corresponding value of the distribution.}\vspace*{-0.7cm}
\label{fig:error_rank_manipcoll}
\end{figure*}

\subsubsection{Benefits of additional force/torque sensors}

The results show the benefits of supplementary force/torque sensors, see Table~\ref{tab:sensor_benefits}.
Without force/torque sensors, up to five contacts can be detected, isolated and identified correctly under certain conditions.
With force/torque sensors in the distal links, at least the generalized external manipulation and locomotion forces can be found and further contacts can be isolated by additional force/torque sensors (max. one per sensor) or the first method (up to 5 in theory).
%
\begin{table}
\caption{Possibilities of collision detection, isolation and identification with different numbers of force/torque sensors in the kinematic tree. The sensors are meant to be added up down the lines of the table.}\label{tab:sensor_benefits}
\begin{tabular}{|p{2.8cm}|p{5cm}|}
\hline
sensors & possibilities\\\hline
only joint torque and base movement sensors & identify ground contact and manipulation contacts, detect single collision, isolate and identify single collision under certain conditions (see Fig.~\ref{fig:error_rank_manipcoll})\\\hline
distal force/torque sensors & full elimination of ground contact and manipulation forces, detection isolation and identification of single collisions, multiple collisions can be detected, isolated and identified in many cases\\\hline
additional force/torque sensors in the kinematic chains & detect isolate and identify one additional contact wrench per additional sensor\\\hline
\end{tabular}\vspace*{-0.3cm}
\end{table}

\subsection{Time Series Analysis of a Single Contact}
The influence of the observer dynamics on the isolation and identification is investigated by using generalized external forces including observer dynamics.
The external force acts over a sinus half wave with an amplitude of one and a cycle time of 40~ms.
The observer is run at a sample frequency of 1000~Hz and $K_O=500$ as suggested in \cite{Haddadin2014}.
In this simulation, the observer error and the error in acceleration estimation for the force/torque sensor compensation are assumed to follow the dynamics presented in (\ref{eqn:obs_dynamic}) and (\ref{eqn:qDD_dyn}) respectively.
%
\begin{figure}
\begin{center}
\includegraphics{figures/colltest_single_filter/colltest_single_filter_f}
\end{center}\vspace*{-0.4cm}
\caption{The $x$-component of the external force $\bm{f}_\mathrm{ext}$, the external force estimated with force/torque sensors  $\hat{\bm{f}}_{\mathrm{ext}}(\hat{\bm{\mathcal{F}}}_{\mathrm{ext,S}})$ according to (\ref{eqn:cmp}) and (\ref{eqn:cmp_ext_vorher}) as well as the external force estimated with the observed generalized forces $\hat{\bm{f}}_{\mathrm{ext}}(\hat{\tau}_\epsilon)$ according to (\ref{eqn:force_identification}) is depicted over time for a collision of  20~ms.
When using the generalized forces for identification, the estimated external force is a first order filtered version of the real force with time constant $K_O^{-1}$.
Using compensated force/torque sensors, the estimated force follows the real force without any delay.}\vspace*{-0.6cm}
\label{fig:coll_singlecontact_filter}
\end{figure}
%
With both methods described before, the contact point is isolated correctly up to numerical errors.
If the observed generalized joint forces are used for isolation, there is a delay of one time step, as the filtered generalized forces are still zero for the first time step of the collision.

Fig.~\ref{fig:coll_singlecontact_filter} shows the external forces over the collision time and the forces identified with and without the use of force/torque sensors.
It can be seen that if no force/torque sensors are used, the contact force is estimated with a delay of approximately 3~ms.
It has to be noted, that the collision will be seen about 10~ms longer with the observer dynamics taken into account.
This timespan depends on the thresholds for the generalized external forces, which was here chosen to be 0.001~N or 0.001~Nm, respectively and the filter frequency $1/K_O$.
Furthermore, when using force/torque sensors, smaller delay but larger error in the estimated external force can be observed.
As the error of $\hat{\ddot{\bm{q}}}$ is driven by $\bm{\tau}_\mathrm{ext}$ and $\bm{M}(\bm{q})$ is nearly constant for the robot at standstill, the contact point can still be estimated correctly with the compensated force/torque sensor.


\documentstyle[11pt]{article}

\setlength{\textheight}{8.75in}
\setlength{\textwidth}{7.0in}
\setlength{\footheight}{0.0in}
\setlength{\topmargin}{0.25in}
\setlength{\headheight}{0.0in}
\setlength{\headsep}{0.0in}
\setlength{\oddsidemargin}{-.35in}
\setlength{\parskip}{1ex plus .2ex minus .2ex}
\setlength{\parindent}{0pc}
\setcounter{topnumber}{5}
\setcounter{dbltopnumber}{5}

\newcommand{\GpC}[1]{{\bf GpC: #1 \\}}
\newcommand{\StQ}[1]{{\bf StQ: #1 \\}}

\title{\Large\bf
PdTRAV \\
Politecnico di Torino Reachability Analysis for Verification \\
(Release 2.0Beta)
}

\author{
\parbox{1.5in}{\begin{center}
               Gianpiero Cabodi
               \end{center}}
\parbox{1.5in}{\begin{center}
               Stefano Quer
               \end{center}}
\\~\\
\parbox{3in}{\begin{center}
             Politecnico di Torino \\
             Dip.\ di Automatica e Informatica \\
             Turin, ITALY
             \end{center}}
}

%\date{~}

\begin{document}

\maketitle
\thispagestyle{empty}
\small

%###############################################################################

\newpage

\setcounter{page}{1}
\normalsize
\tableofcontents

\newpage

%###############################################################################
%###############################################################################
%###############################################################################

\section{Introduction}

The Politecnico di Torino Reachability Analysis for Verification
(PdTRAV) package provides functions to perform BDD based
symbolic reachability analysis of Finite State Machines (FSMs).
The functions are intended for use within the field of formal verification
of sequential circuits.

The package can be used as:
\begin{itemize}
\item
as a black box, i.e., a library of functions to be linked with an application
\item
as a clean box which may be worked into and expanded by a programmer.
\end{itemize}

The CMD sub--package provides a simple textual user interface for
users who simply want to perform reachability and BDD operations.

The package includes the following sub--packages (directories):
\begin{itemize}
\item
Decision Diagram Interface (DDI): almost all BDD package dependencies are
concentrated here.
DDI can also be viewed as a portability interface for a chosen BDD package.
Moreover, it provides some higher level abstractions such as BDD based
types (monolithic/partitioned Boolean functions, arrays of Boolean functions,
variables, variable arrays and sets).
The present implementation relies on the CUDD package by Fabio Somenzi
(version 2.3.0).
\item
Utility (PDTUTIL): memory management, string manipulation and
other low level non BDD routines.
\item
CUDD interface (CUPLUS): this directory contains some
extensions to the CUDD package.
All BDD package extensions (mostly recursive functions working of BDD nodes)
have been (and should be) created in this directory, or in a similar one in
the case of porting to another BDD package.
\item
Finite State Machine (FSM): this package contains routines for storing/loading
and manipulating a FSM structure.
The BLIF format is presently supported for FSM netlists. We also
introduce a FSM dump format based on the DDDMP BDD format
(see dddmp package inside the CUDD package).
\item
Transition Relation (TR): symbolic traversals are based on transition
relations.
This directory provides manipulation functions, i.e., sorting, partitioning,
clustering, for monolithic and partitioned transition relations.
Support for transitive closure is also included.
\item
Traversal (TRAV): image computations and full traversals are available from
this package. Invariant (assertion based) checking, is included.
\item
Conjunctive and disjunctive partitioning (PART).
This directory supplies the user with routines to conjunctively and
disjunctively partition a BDD.
\item
Command user interface (CMD): a textual interactive user interface for the
package.
It allows to issue commands and to parse them by calling the functionalities
of the other packages.
\end{itemize}

Mutual interactions and references among sub--packages exist internally.
Some of the sub--packages have been build up mainly as bottom layers for other sub--packages,
but they could be used as stand--alone packages as well by any application.
E.g. the DDI package is the only one required for an application which
requires Boolean function manipulation only, without requiring the
FSM, transition relation and traversal packages.
In the following we assume that the reader is familiar with BDDs, basic
operations using BDDs, and symbolic traversals.
The reader should refer to~\cite{Bryant86,Bryant92} for a survey on these
topics.

%###############################################################################
%###############################################################################
%###############################################################################

\section{How to Get and Install PdTRAV}

%###############################################################################

\subsection{The PdTRAV Package}

The PdTRAV package is available via anonymous FTP from ...
A compressed tar file named pdtrav-2.0.tar.gz can be found in directory
pub.
Once you have this file,
\begin{verbatim}
gzip -dc pdtrav-2.0.tar.gz | tar xvf -
\end{verbatim}
will create directory pdtrav-2.0 and its subdirectories.
These directories contain the package, including documentation and a few usage
examples.

There is a README file with instructions on configuration and installation
in pdtrav-2.0.
You can use a compiler for either ANSI C or C++.
To compile and link the package the user should run the main {\sf Makefile}
in the src directory (generated by autoconf).
The user can choose different setting options depending on
the hardware/OS on which the installation has to be performed.
The {\sf Cudd-2.3.0} package is required by pdtrav
on a sibling directory of the PdTrav.
Information on the {\sf Cudd-2.3.0} can be found from
{\sf http://vlsi.colorado.edu/~fabio}.

Once the user has made the libraries and executable program, he can test
the program in the {\sf exp} directory.
Such a directory contains a few {\sf blif} files on which to run
PdTRAV (cmd interface), and
a few script files showing how to run it.
From the root directory type, for example:
\begin{verbatim}
cd <root directory>/pdtrav-2.0/exp/trav
../../bin/pdtrav
source s1423TravOrdTrMon.cmd
\end{verbatim}
This runs the traversal program on the {\sf s1423} circuit and with a
variable ordering optimized for the monolithic transition relation
representation.
On a $400$MHz Pentium II processor with $128$ Mbytes of main memory and
running Linux RedHat 5.2 Apollo it takes about $40$ seconds.
The output produced by the program can be checked against the contents of
the file s1423TravOrdTrMon.out.
More information on the pdtrav program can be found in the README file on
the root of the distribution.
(ImgTime: 0.65 sec)(TotalTime: 3.19 sec)
TravLevel 4: [|Tr|: 758881] [|From|: 556][|To|: 1228][|Reached|: 1397][\#ReachedStates: 392225]
(ImgTime: 1.19 sec)(TotalTime: 4.89 sec)
TravLevel 5: [|Tr|: 758881] [|From|: 1275][|To|: 3168][|Reached|: 3316][\#ReachedStates: 2.08012e+06]
(ImgTime: 2.71 sec)(TotalTime: 8.34 sec)
TravLevel 6: [|Tr|: 758881] [|From|: 3152][|To|: 7496][|Reached|: 7763][\#ReachedStates: 8.49328e+06]

Another possibility is the {\sf src/test} directory, which shows some
examples of how to use pdtrav as a library. The {\sf test} executable
(testPdtrav) is moved in the bin directory, too.

If you want to be notified of new releases of the PdTRAV package, send a
message to the authors {cabodi,quer}@polito.it.
Moreover, send feedback to the same authors.

%###############################################################################
%###############################################################################
%###############################################################################

\section{User's Manual}

This section describes the use of the PdTRAV package and sub--packages as a
black box.

%###############################################################################

\subsection{Compiling and Linking}

To build an application that uses PdTRAV, you should add
a line

\begin{verbatim}
#include "<pkg>.h"
\end{verbatim}

to your source files, and should link $lib<pkg>.a$ (for any given
$<pkg>$ within PdTRAV you need) to your executable.
Some platforms require specific compiler and linker flags.
Refer to the Makefile in the top level directory of the distribution.

A brief description of the main sub--packages packages follows.
They are characterized by a set of functions and manager structure
(accessed to by pointer) describing a consistent working
environment for operations.
Moreover, DDI defines the BDD based data types used by our package.

%###############################################################################

\subsection{The DDI package}

This package is intended as a portability interface and a higher level
abstraction of the BDD package. It is used by all other PdTRAV packages
working with BDDs, but it might be used as a stand--alone package as well.

A {\bf DDI manager} is defined in quite a similar way CUDD does. In summary,
it is a structure (type Ddi\_Mgr\_t)
containing all informations about a given BDD environment,
with a set of variables, hash/cache tables, and BDD nodes/functions.
DDI uses its own descriptor (a "C" structure), which, besides pointing to a CUDD manager,
allows handling extra informations, like variable names and auxiliary indexes.
These are additional variable attributes (names and integer indexes), which
are particularly useful as absolute variable references.
We introduced them for use in multiple manager frameworks or whenever an
application involves several runs of the same program, without a constant
correspondence between variable indexes and physical entities
(circuit inputs/outputs/latches).

%###############################################################################

\subsubsection{Basic Data Structures}

Besides extending manager capabilities, DDI introduces strong typing
for objects represented using BDDs, and uses ``handles'' as a
mechanism for allocation/freeing. More specifically, four types
are presently defined and managed as abstract data types,
all available in scalar and array form:

\begin{itemize}

\item
{\bf Variable (Ddi\_Var\_t, Ddi\_Vararray\_t)}
A variable is uniquely referenced by an integer index within a given manager,
and optionally by a variable name and/or an auxiliary index (auxid).
A variable $v$ is also caracterized by a position in variable
ordering, which is not fixed (and generally differs from the index) if
dynamic variable ordering is enabled.
A variable is often represented in BDD packages (e.g. CUDD) by the
corresponding positive literal (a BDD).
We clearly distinguish a variable $v$ from the corresponding
literals ($v$ and $\overline{v}$), which
are in DDI Boolean functions (type {\bf Ddi\_Bdd\_t}).
Variable arrays are useful whenever we need groups of variables with
well
defined positions, for instance to establish a correspondence between
present and next state variables (in FSM traversal), or between
Boolean functions and variables (in compose operations).

\item
{\bf Variable Sets (Ddi\_Varset\_t, Ddi\_Varsetarray\_t)}
A variable set is a group of variables with no defined position or
ordering. Variable sets are represented in some packages (e.g. SIS) by
bit vectors, in CUDD by BDD cubes.
DDI internally uses the latter strategy, and externally provides
usual set operators. Variable sets are useful as inputs for
support management and quantification operators.

\item
{\bf Boolean Functions (Ddi\_Bdd\_t, Ddi\_Bddarray\_t)}
A Boolean function is either a monolithic, partitioned (conjunctively
or disjunctively) or meta BDD. We adopt the BDD
acronym to emphasize the Decision Diagram based representation.
Partitioned representations are recursive. The terms of a
conjunctive form are BDDs, so they may be partitioned themselves.
Arrays of BDDs are useful whenever we need to represent vectors of
functions, e.g. for output or next state functions of circuits.
Internally, partitioned BDDs are stored as trees with monolithic BDDs
as leaves.
Meta BDDs are a particular BDD representation described in
\cite{MetaBDDs}.

\item
{\bf Expressions (Ddi\_Expr\_t, Ddi\_Exprarray\_t)}
Expressions are more general than BDDs. They may include BDDs (since
monolitic and partitioned BDDa are Boolean expressions), but they are
expecially concieved for invariants and temporal logic (e.g. CTL)
formulas.
Moreover, expression leaves are not necessarily BDDs. They might be
string identifiers, to be associated to BDDs at later steps of symbolic
manipulations.

\end{itemize}

All of the above types are implemented by resorting to handles. The
handle mechanism hides the ref/deref BDD node allocation style
implemented in CUDD. Handles are dynamically allocated structures
pointing to CUDD BDD nodes, and only accessed to by pointers.
Handles are allocated, freed, duplicated. A handle represents a
reference to a BDD node, so a ref/reref operation is implicitly done
any time a handle is created/released. The only exception to this
general rule are variables, which are never duplicated nor freed (except
when freeing a DDI manager)

Handles are expecially useful as an intermediate portability layer
between the
higher levels and CUDD\footnote{Other BDD packages could be introduced
by partly rewriting DDI}. Moreover they enable storing additional
informations characterizing DDI entities, like name, code, extra
pointers.
Names are expecially concieved for debug and/or log purposes, codes
can distinguish particular subtypes (e.g. monolithic/partitioned forms
or operators in expressions). We use pointers for list based
management of allocated DDI objects, and to keep a reference to the
owner DDI manager (this avoids passing manager to most functions).

We call the above data types {\bf DDI nodes}.
%%GENERIC TYPE

%##############################################################################

\subsubsection{Operators}

An operation may either generate a new result DDI node, or modify an
existing one, following the accumulator operation style.
Most operations returning scalar data are provided with
both options. They gerate a new DDI node (e.g. c = Ddi\_BddAnd(a,b)),
or they accumulate (e.g. Ddi\_BddAndAcc(a,b))
the result in the first operand, after freeing old data). Conversely,
operations on array data always modify an existing DDI node (explicit
calls to proper ``Alloc'' or ``Dup'' functions are required to generate
new arrays). Going to operand data, whenever an operation requires
data transfer to a destination DDI node, two options are available:
{\em copying} or {\em moving}. In the former case, data are duplicated
(new DDI nodes are generated and CUDD nodes implicitly referenced), in
the latter one pointers (partitions, sub-expressions, new array
entries) are copied and actually moved to a new owner DDI node.

{\sf Make} is used in names to enforce creation (allocation) of new
data (e.g. {\sf Ddi\_BddMakeMono} creates a monolitic BDD from a non
monolitic one), {\sf Set } is used to specify data transformation
directly one the parameter (e.g. {\sf Ddi\_BddSetMono} transforms a non
monolitic BDD to monolitic).

Manipulations on non scalar objects
(e.g. arrays and partitioned BDDs) support both {\em insert/extract}
and {\em read/write} operations. {\sf Insert} always creates a new
array slot (or partition), {\sf Extract} removes the returned slot
(partition), {\sf Write} overwrites (and frees) an existing array slot
(partition). {\sf Insert} and {\sf Write} always generate a duplicate
of the manipulated object (so that the received parameter is still
owned by the calling procedure), {\sf Extract} and {\sf Read} make no
duplicate of the returned object (but the result of {\sf Extract} is
owned by the calling procedure after removal from array or partitioned BDD).

The following operators are presently supported:

\begin{itemize}

\item

DDI-CUDD conversions. Functions performing conversions between
different types are named $Ddi\_<type>MakeFromCU$ and $Ddi\_<type>ToCU$
(being type one of the Ddi types) are provided for conversions from/to CUDD
objects. Conversions from CUDD always generate a new DDI node (with
implicit node referencing), whereas
their dual ...ToCU counterparts simply read CUDD node pointers (with
no node referencing). Memory allocation is done only in case of
arrays (e.g. Ddi\_BddarrayToCU), which require a dynamically allocated
array of pointers.

\item

Management of (conjunctively and disjunctively) partitioned forms.

\item
Standard BDD operators: ITE, AND, OR, ... AND-EXIST, ..., constrain,
restrict ...
They are implemented by resorting to the corresponding CUDD functions.
Most operators support partitioned BDDs, with restrictions as
described in the DDI package documentation.

\item
Load/store to file. Boolean functions and variables may be stored to file.
The functions are implemented through the {\em dddmp} package
(distributed with CUDD) which provides efficient dumping of BDDs and arrays of BDDs.
Partitioned forms are managed by proper headers (considered as comments by dddmp)

\end{itemize}

It must be noted that the results of all operators are implicitly referenced
(unless explicitly stated in the function documentation), while explicit
free-ing is required for all types.

%###############################################################################

\subsection{FSM}

Each FSM has an internal representation.
Each internal representation can be stored on secondary memory on what we
call a FSM file.
This gives the user the possibility to store intermediate computation
results and to exchange information on a FSM and BDD basis.
A result of this strategy is to allow the user to perform with great
flexibility a certain number of (expensive) operations such as partially
traverse a FSM, store intermediate results, and restart reachability analysis
afterwards.

Internal and external (on files) formats are pretty alike one to the other.
They contain information about the size of the FSM (number of inputs,
outputs, latches), names, and BDD representations (for initial state set,
next states and output functions, transition relations, and so on).
The current format is the following one:

{\small
\begin{verbatim}
.Fsm <name>

.Size
  .i <Number of Primary Inputs>
  .o <Number of Primary Outputs>
  .l <Number of Memory Elements>
.EndSize

.Ord
  .ordFile <File Name for the Variable Order File>
.EndOrd

.Name
  .i <Name of Primary Input Variables>
  .ps <Name of Present State Variables>
  .ns <Name of Next State Variables>
.EndName

.Index
  .i <Variable Index for Primary Inputs>
  .ps <Variable Index for Present State Variables>
  .ns <Variable Index for Next State Variables>
.EndIndex

.Delta
  .bddFile <File Name for the Next State Functions BDD File>
.EndDelta

.Lambda
  .bddfile <File Name for the Output Functions BDD File>
.EndLambda

.InitState
  .bddFile <File Name for the Initial State Set BDD File>
.EndInitState

.Tr
  .bddFile <File Name for the Transition Relation BDD File>
.EndTr

.Reached
  .bddFile <File Name for the Reachable State Set BDD File>
.EndReached

.EndFsm
\end{verbatim}
}

In general, not all the sections are present, depending on the ``state''
of the program.
For example, the reachable state set at the beginning does not exist and
storing the FSM implies not storing the section
{\small
\begin{verbatim}
.Reached
  .bddfile <File Name for the Reachable State Set BDD File>
.EndReached
\end{verbatim}
}

Functions are given to perform a certain number of operations on the
FSM structure.
Namely we allow the user to:
\begin{itemize}
\item
Initialize an internal representation for the FSM
\item
Duplicate an internal representation for the FSM
\item
Destroy an internal representation for the FSM
\item
Store a FSM representation with the previous format
\item
Load a FSM representation.
\end{itemize}
Given the name of the FSM the names of the various files are automatically
created and dealt with.
Typically if {\sf name} is the name of the FSM file, {\sf name.ord} is the
name of the variable order file, {\sf namedelta.bdd} is the name of the file
containing the next state function BDD representation, and so on.
During storing and loading operations two modes are permitted: In the first
mode the FSM file and all the BDD files are loaded, in the second mode only the
FSM file is loaded.
This features allows the user to explicitly concentrate on the objects
he really cares about.
For example next state functions, the transition relation and the reachable
state set can be loaded separately and optimized with different variable
orders in different working sections.
The package provides functions to manage (such as load and store or perform
operation on) singular object belonging to a FSM (such as BDDs).
Normally the FSM description has to be loaded or created before any other
object belonging to it (such as the transition relation).

%###############################################################################

\subsection{TR management}

Functions for creating and manipulating transition relations are provided by
this package.
More specifically:

\begin{itemize}
\item TR creation: from next--state functions and variable arrays
(inputs, present/next--state).
From scratch (GpC{To be done.}).
\item TR sorting: variants of the IWLS95 heuristics are provided, the goal
being a good partition sorting for efficient early smoothing with conjunctive
partitioning
\item TR clustering: linear conjunction of partitions controlled by a
size threshold.
\item TR subsetting: an external constraint is used to constrain a TR
by means of conjunction.
\item TR partitioning
\item Abstractions oriented to approximate reachability.
\end{itemize}

%###############################################################################

\subsection{Traversals}

This package provides several routines for image/preimage computations,
traversals,
transitive closure of a State Transition Graph. All tasks are accomplished
working on transition relations and characteristic functions of state sets.

A traversal manager includes all data involved in a traversal, namely the TR,
state sets, settings, etc.
Standard traversals as well as more specialized ones are supported.

%###############################################################################

\subsection{The CMD user interface}

PdTRAV is equipped with an interactive textual user interface.
It is intended for users who plan not to link PdTRAV packages as an object
library.
Commands are issued on a line by line basis.

If the first character of a command is the exclamation mark "!", a system
call is issued instead.
This allows to execute basic system commands such as "more", "ls", etc.

If the first character of a command is "\#" the command is ignored, i.e., it
is supposed to be a comment.
This is especially useful to write script files.
In fact, the command "source" gives the possibility to read from a
source-script file instead that from standard input.

If the first character of the command is "@" this indicates that a script
file with parameter is used.
For example
{\small
\begin{verbatim}
@script1.cmd a b c
\end{verbatim}
}
runs the script file script1.cmd (containing some \$1, \$2 and \$3) with
parameters a, b and c.

For more information on the commands see the documentation in the {\sf cmd\\doc}
directory and the on-line documentation (command {\sf help}).

%###############################################################################

\subsection{Setting Parameters}

All packages require parameter setting for their operations.
For each package, proper functions support set/show and restoring of default
settings package provides several functions to set the parameters that control
various functions.
The value of these settings are usually stored into the relative manager
structure.
A lot of commands can receive additional options.
These options usually overwrite the generic settings.

%###############################################################################
%###############################################################################
%###############################################################################

%\section{An example}
%

%###############################################################################
%###############################################################################
%###############################################################################

\section{Programmer's Manual}

This section should provide additional detail on the working of the PdTRAV
package and on the programming conventions followed in its writing.
The additional detail should help those who want to write procedures that
directly manipulate the DDI and other PdTRAV data structures.
Anyway, the Programmer manual, for a visibility of the package as a clear
box, {\bf is not provided in this release.}

%###############################################################################
%###############################################################################
%###############################################################################

\section{Acknowledgments}

Contributors and early adopters to be defined.

%###############################################################################
%###############################################################################
%###############################################################################

\bibliographystyle{unsrt}
%\bibliographystyle{plain}
%\bibliography{/home/cabodi/pap/dac99/biblio}
\bibliography{/disk1/paper/biblio/biblio}

\end{document}


\section{Operation of Encryption Keys}
\markboth{Operation Encryption}{Operation Encryption}
\thispagestyle{myheadings}
\label{ope}

\subsection{One Extra Pair of Keys for Encryption and Decryption}
\label{ope-epk}

Decryption of an encrypted text means to apply one's private key
to an unreadable text. In order to prevent users from ``signing''
unreadable texts blindly,
users are provided by {\em two different pairs of keys}:
one pair for signature and verification; the other pair for
encryption and decryption.

The public encryption key is certified by the same authority which
issues the signature certificate to the user. Therefore,
the encryption user certificate is combined with the same
forward certification path to make up an
{\em encryption recipient certificate}
(X.509 type ``certificates'').

A signature originator certificate is distinguished from
an encryption recipient certificate by the object identifiers
of their public key infos.
The standards (X.509, Annex H, \cite{cci4}) define
object identifiers for {\em signature algorithms}
and for {\em encryption algorithms}, respectively.
See paragraph \ref{ds-ca} above for reference.

\subsection{Security Requirements}
\label{ope-sr}

The application of a wrong encryption key is not that dangerous,
in that the main effect will be, that nobody in the world is able
to decrypt the text. In that case, the recipient might provide
the sender with the correct public encryption key.
However, one must be aware of intruders
who try to trigger information by offering masqueraded
encryption recipient certificates.
This is encountered by certificate checks:
before encrypting a text for a partner,
a user checks the encryption recipient certificate at an
appropriate security level.

\subsection{Change of Keys}
\label{ope-ck}

\subsubsection{Old and New Decryption Key}
\label{ope-ondk}

In order to avoid confusion by a change of encryption keys,
every user has not only one, but {\em two}
private decryption keys on his smartcard
(DecryptionSKnew and DecryptionSKold are described
in paragraph \ref{decsk} above):

\begin {center}
\begin {tabular}{|c|c|c|}
\hline
{\em issuer} & {\em serial no}& {\em key} \\ \hline
$<issuer>_{Cert-old}$ & $<serial-no>_{Cert-old}$ & $B_{Sold}$    \\ \hline
$<issuer>_{Cert-new}$ & $<serial-no>_{Cert-new}$ & $B_{Snew}$    \\ \hline
\end {tabular}
\end {center}

\label{fig-ope-ondk}
\stepcounter{Abb}
{\footnotesize Fig.\arabic{Abb}: Private decryption keys}
\\
{\footnotesize $<issuer>_{Cert-old}$ denotes the issuer name of the
old decryption certificate;
$<serial-no>_{Cert-old}$ denotes the serial number of the
old decryption certificate;
$B_S$ denotes the private (``secret'') key
of the user $B$, in this case for the purpose of decryption}
\\[1em]
A sender of an encrypted message should inform the recipient,
which public encryption key he used,
in order to enable the recipient to apply his correct private decryption key.
There is only one unique way to do that without using redundant
message encoding.
That is, by sending the issuer name and the serial number
of the public encryption certificate along with the encrypted message.
The recipient has to map that information on his respective private
decryption key.
Therefore, the smartcard table for the old and
new private decryption key is organized this way.
Also, this allows the user to store more than two decryption keys,
and even cross-certificate mappings for the keys.
\\
In case of confusion, the recipient can ask the sender
for the encryption recipient certificate in order to check it;
he can (and should) also provide the sender by the correct certificate.

\subsubsection{Reencrypting Stored Encrypted Texts}
\label{ope-set}

When receiving a new pair of decryption keys and a new
encryption recipient certificate,
the user has to decrypt all of his stored encrypted texts
by applying the old decryption key,
and then to encrypt them again
by applying the new encryption key, which he reads from the new certificate.
In general, this applies not for the complete texts, but only for
the DES-keys, by which the texts are symmetrically encrypted.
The DES-keys will not change, such that the texts themselves
need not be reencrypted.

\subsubsection{Steps to Change Keys}
\label{ope-sck}

User keys are created by the users themselves.
In case of a change of a pair of encryption and decryption keys,
on the smartcard
the expired secret decryption key will switch its status from
``new'' to ``old'', while the newly created secret decryption
key will be stored with the status ``new''.
The public encryption key would be included in a prototype
certificate which is sent to the user-CA with request of
updating and signing the certificate.
After reception of the signed certificate the user
replaces the old encryption key certificate on his smartcard
by this new one. The old one is not needed any more
(``EncrCertificate'', see \ref{enccert}).
Now, the user sends his new encryption certificate
to all his important communication parnters.
He also reencrypts all his locally stored encrypted texts (see \ref{ope-set}).

\subsection{The Smartcard Table
``Trusted Public Encryption Keys''}
\label{ope-tpvk}

In order to support confidential communication between partners without
use of directories and without repeated checks of certificates,
users maintain tables of trusted public encryption keys
on their smartcards.
The users can read and write the lines of their smartcard tables.

Before adding a new public key to that list, the respective
encryption recipient certificate is to be checked at security level 3.
After that, the certificate is thrown away and will not be used any more.

There is no security risk with the late update of such an entry.
When using an old encryption key, the partner is able to decrypt the
text anyway, in that he keeps one old decryption key on his smartcard.
If the encryption key applied is even older, the recipient will not
be able to decrypt the text, and no person in the world would be able,
either. This is the occasion to provide the partner with the actual
encryption key.


\documentclass{article}

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

\usepackage{listings} % Required for inserting code snippets
\usepackage{geometry}
\geometry{margin=0.7in}
\usepackage[usenames,dvipsnames]{color} % Required for specifying custom colors and referring to colors by name
\usepackage{amssymb}
\usepackage{amsmath}
\usepackage{mathtools}
\usepackage{tikz}
\usepackage{enumerate}
\usepackage[T1]{fontenc}

\delimitershortfall-1sp
\newcommand\abs[1]{\left|#1\right|}

\definecolor{DarkGreen}{rgb}{0.0,0.4,0.0} % Comment color
\definecolor{highlight}{RGB}{255,251,204} % Code highlight color

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

\begin{document}

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

\section*{Problem 1}
\begin{flushleft}
\textit{Several useful inequalities involving absolute values can be derived from the triangle inequality by a judicious choice for a and b.}
\begin{enumerate}[(a)]
For any of these examples, we can redefine $x$ and $y$ to be $a$ and $b$, which will help us reduce to the following variants of the triangle inequalities. For each of the following inequalities, I use the following format $\abs{a} + \abs{b} \leq \abs{a+b}$.

\item $\abs{x} - \abs{y} \leq \abs{x-y}$ \\
\vspace{.3cm}
Here we will let $a=(x-y)$ and $b=y$. Then, we see that \\
\begin{center}
$\abs{x-y+y} \leq \abs{x-y} + \abs{y} \implies \abs{x} \leq \abs{x-y} + \abs{y} \implies \abs{x} - \abs{y} \leq \abs{x-y}$
\end{center}

\item $\abs{x} - \abs{y} \leq \abs{x+y}$ \\
\vspace{.3cm}
Here we will let $a=(x+y)$ and $b=-y$. Then, we see that \\
\begin{center}
$\abs{x+y+(-y)} \leq \abs{x+y} + \abs{-y} \implies \abs{x} \leq \abs{x+y} + \abs{y} \implies \abs{x} - \abs{y} \leq \abs{x+y}$
\end{center}

\item $\abs{x} + \abs{y} \geq \abs{x-y}$ \\
\vspace{.3cm}
Here we will let $a=x$ and $b=-y$. Then, we see that \\
\begin{center}
$\abs{x+(-y)} \leq \abs{x} + \abs{-y} \implies \abs{x-y} \leq \abs{x} + \abs{y}$
\end{center}

\item $\abs{\abs{x} - \abs{y}} \leq \abs{x-y}$ \\
\vspace{.5cm}
To prove this, we will set up 2 different equations. \\
\begin{center}
\begin{tabular}{c c}
(1) $\abs{y-x+x} \leq  \abs{y-x} + \abs{x}$ &
(2) $\abs{x-y+y} \leq \abs{x-y} + \abs{y}$ \\
\end{tabular}
\end{center}
(1) We can move the $\abs{x}$ from the left side to the right side and take negative one out of the left hand side, \\
which gives us $-(\abs{x}-\abs{y}) \leq \abs{y-x} $. \\
(2) We can move the $\abs{y}$ from the left side to the right side, which gives us $\abs{x}-\abs{y} \leq \abs{x-y}$. \\
\vspace{0.5cm}
From the properties of absolute values, we know $\abs{x-y} = \abs{y-x}$ and if $x \geq a$ and $x \geq -a$ then $x \geq \abs{a}$. \\

From the combination of these two facts, we now have $\abs{\abs{x}-\abs{y}} \leq \abs{x-y}$.
\end{enumerate}
\end{flushleft}

\section*{Problem 2}
\begin{flushleft}
Recall the definition of what it means for $S \subset \mathbb{R}$ to be \textit{bounded above, bounded below} and just \textit{bounded}. Prove that $S$ is bounded if and ony if there is a real number $M > 0$ such that
\begin{center}
$\forall s \in S, \abs{s} \leq M$
\end{center}

\textbf{Proof} \\
\vspace{.3cm}

Let's assume $S \subset \mathbb{R}$, then $\abs{s} \leq M$ means that $-M < s < M$, $\forall s \in S$. $S$ is bounded above if there exists some $X \in \mathbb{R}$ such that $\forall s \in S$, $s < X$. Likewise, $S$ is bounded below if there exists some $x \in \mathbb{R}$ such that $\forall s \in S$, $x < s$.  Thus, we see that $M$ is in fact an upper bound for $S$ because $s < M$, $\forall s \in S$ and that $-M$ is in fact a lower bound for $S$ because $-M < s$, $\forall s \in S$. Therefore, since $S$ is bounded above and below, $S$ is, by definition, bounded.
\end{flushleft}

\section*{Problem 3}
\begin{flushleft}
We say that a function f is \textit{invertible} if $f^{-1} = \{ (b,a) : (a,b) \in f \}$ is also a function, in which case we call it the inverse function to $f$. Notice that \\
\begin{center}
$f^{-1}(b) = (a) \leftrightarrow b = f(a)$,
\end{center}
assuming that $f^{-1}$ is a function.
\begin{enumerate}[(a)]
\item If $f$ is invertible, what are the domain and range of $f^{-1}$? \\
\item Which of the following functions are invertible? For those that are invertible, give the inverse. \\
\end{enumerate}
\begin{center}
\begin{tabular}{l l}
$l = \{(x,y) \in \mathbb{R}^2 : y = 2x + 1\}$ & Inverse: $y=\frac{x-1}{2}$, Domain: $\mathbb{R}$, Range: $\mathbb{R}$ \\
\vspace{.2cm}
$c = \{(x,y) \in \mathbb{R}^2 : y \geq 0, x^2 + y^2 = 1\}$ & Not invertible \\
\vspace{.2cm}
$s = \{(x,y) \in \mathbb{R}^2 : y = x^2\}$ & Not invertible\\
\vspace{.2cm}
$ \sqrt = (x,y) \in \mathbb{R}^2 : y \geq 0, y^2 = x\}$ & Inverse: $y=x^2$, Domain: $\mathbb{R}$, Range: $[0, \infty)$ \\
\vspace{.2cm}
$sin = \{(x,y) \in \mathbb{R}^2 : y = sin(x)\}$ & Not invertible \\
\end{tabular}
\end{center}
\end{flushleft}

\section*{Problem 4}
\begin{flushleft}
Assume that $g$ is bounded function, that is, $\abs{g(x)} < B$ for all $x \in \mathbb{R}$. Prove that
$\displaystyle \lim_{x \to 0}  x \cdot g(x) = 0$. \\

\vspace{.5cm}

\begin{center}
$c=0$, $L=0$, $f(x)=x \cdot g(x)$
\end{center}

$\abs{f(x) - L} < \epsilon \implies \abs{x \cdot g(x) - 0} < \epsilon \implies \abs{x \cdot g(x)} < \epsilon$. \\
\vspace{.2cm}
At its max, $g(x)$ can be no greater than $B$. Thus, we know $B$ is an upper bound for $f(x)$. We can rewrite $f(x)$ as $\abs{x \cdot B}$. Thus, $\abs{x \cdot B} < \epsilon \implies -\epsilon < x \cdot B < \epsilon$. By dividing by $B$ on both sides, we have $\frac{-\epsilon}{B} < x < \frac{\epsilon}{B}$. \\

\subsection*{Proof}
Let $\delta_\epsilon = \frac{\epsilon}{B}$. Then $\abs{x - 0} < \delta_\epsilon \implies \delta_\epsilon < x - 0 < \delta_\epsilon$. \\
\begin{center}
$\frac{-\epsilon}{B} < x < \frac{\epsilon}{B}$ \\
\vspace{.2cm}
$-\epsilon < x \cdot B < \epsilon$ \\
\vspace{.2cm}
$\abs{x \cdot B} < \epsilon$
\end{center}

Since we said $g(x) < B$, $\forall x \in \mathbb{R}$, we know the following inequality to be true: $x \cdot g(x) < \abs{x \cdot B} < \epsilon$. This completes the proof.
\end{flushleft}

\section*{Problem 5}
\begin{flushleft}
Using the \textquotedbl$\epsilon - \delta$\textquotedbl \hspace{.01cm} definition to prove that \\
\begin{enumerate}[(a)]
\item $\displaystyle \lim_{x \to 2} (4x+1) = 9$

\begin{center}
$\abs{f(x) - L} < \epsilon \implies \abs{(4x+1) - 9} < \epsilon \implies \abs{4x-8} < \epsilon \implies  \abs{4(x-2)} \implies \abs{x-2} < \frac{\epsilon}{4}$ \\
\end{center}

\subsection*{Proof}

Let $\delta_\epsilon \implies \frac{\epsilon}{4}$. Then, $0 < \abs{x-2} < \frac{\epsilon}{4} \implies -\frac{\epsilon}{4} < x-2 < \frac{\epsilon}{4}$. \\
\begin{center}
\vspace{.2cm}
$\frac{\epsilon}{4} < x-2 < \frac{\epsilon}{4}$ \\
\vspace{.2cm}
$-\epsilon < 4(x-2) < \epsilon$ \\
\vspace{.2cm}
$-\epsilon < 4x-8 < \epsilon$ \\
\vspace{.2cm}
$-\epsilon < (4x+1)-9 < \epsilon$ \\
\vspace{.2cm}
$\abs{(4x+1)-9} < \epsilon$ \\
\end{center}

This completes the proof because we showed $\abs{f(x) - L} < \epsilon$ for a specific $\delta$. \\

\item $\displaystyle \lim_{x \to 5} \sqrt{x + 4} = 3$

\begin{center}
$\abs{f(x) - L} < \epsilon \implies \abs{\sqrt{x + 4} - 3} < \epsilon$ implies \\
\vspace{.3cm}
$-\epsilon < \sqrt{x + 4} - 3 < \epsilon$ \\
\vspace{.2cm}
$-\epsilon  + 3< \sqrt{x + 4} < \epsilon + 3$ \\
\vspace{.2cm}
$(-\epsilon  + 3)^2 < x + 4 < (\epsilon + 3)^2$ \\
\vspace{.2cm}
$(-\epsilon  + 3)^2 - 9 < x - 5 < (\epsilon + 3)^2 - 9$ \\
\end{center}

You can see that we subtracted 9 to both sides at the end. That is because our $\abs{x-p}$ value is $\abs{x-5}$. \\

\subsection*{Proof}
Let $\delta_\epsilon = (\epsilon + 3)^2 - 9$. Then, $0 < \abs{x-5} < (\epsilon + 3)^2 + 9$ implies \\
\begin{center}
\vspace{.2cm}
$(-\epsilon  + 3)^2 - 9 < x - 5 < (\epsilon + 3)^2 - 9$ \\
\vspace{.2cm}
$(-\epsilon  + 3)^2 < x + 4 < (\epsilon + 3)^2$ \\
\vspace{.2cm}
$-\epsilon  + 3< \sqrt{x + 4} < \epsilon + 3$ \\
\vspace{.2cm}
$-\epsilon < \sqrt{x + 4} - 3 < \epsilon$ \\
\end{center}

This completes the proof because we showed $\abs{f(x) - L} < \epsilon$ for a specific $\delta$. \\

\item $\displaystyle \lim_{x \to 3} \frac{1}{8 - 4x} = \frac{1}{4}$

\begin{center}
$\abs{f(x) - L} < \epsilon \implies \abs{\frac{1}{8 - 4x} - \frac{1}{4}} < \epsilon$ implies \\
\vspace{.3cm}
$-\epsilon < \frac{1}{8 - 4x} - \frac{1}{4} < \epsilon$ \\
\vspace{.2cm}
$-\epsilon + \frac{1}{4} < \frac{1}{-4(x-2)} < \epsilon + \frac{1}{4}$ \\
\vspace{.2cm}
$4\epsilon - 1 > \frac{1}{x-2} > -4\epsilon - 1$ \\
\vspace{.2cm}
$\frac{1}{4\epsilon - 1} > x-2 > \frac{1}{-4\epsilon - 1}$ \\
\vspace{.2cm}
$\frac{1}{4\epsilon - 1} - 1> x-3 > \frac{1}{-4\epsilon - 1} - 1$ \\
\end{center}

You can see that we subtracted 1 to on sides at the end. That is because our $\abs{x-p}$ value is $\abs{x-3}$. \\

\subsection*{Proof}

Let $\delta_\epsilon = \frac{1}{-4\epsilon - 1} - 1$. Then, $0 < \abs{x-3} < \frac{1}{-4\epsilon - 1} - 1$ implies \\
\begin{center}
\vspace{.2cm}
$\frac{1}{4\epsilon - 1} - 1 > x - 3 > \frac{1}{-4\epsilon - 1} - 1$ \\
\vspace{.2cm}
$\frac{1}{4\epsilon- 1} > x - 2 > \frac{1}{-4\epsilon - 1}$ \\
\vspace{.2cm}
$4\epsilon - 1 > \frac{1}{x - 2} > -4\epsilon - 1$ \\
\vspace{.2cm}
$-\epsilon + \frac{1}{4} < \frac{1}{-4(x-2)} < \epsilon + \frac{1}{4}$ \\
\vspace{.2cm}
$-\epsilon < \frac{1}{-4(x-2)} - \frac{1}{4} < \epsilon$ \\
\vspace{.2cm}
$-\epsilon < \frac{1}{8-4x} - \frac{1}{4} < \epsilon$ \\
\end{center}

This completes the proof because we showed $\abs{f(x) - L} < \epsilon$ for a specific $\delta$. \\

\end{enumerate}
\end{flushleft}

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

\end{document}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                                 %
%  GEANT manual in LaTeX form                              %
%                                                                 %
%  Michel Goossens (for translation into LaTeX)                   %
%  Version 1.00                                                   %
%  Last Mod. Jan 24 1991  1300   MG + IB                          %
%                                                                 %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\Origin{R.Brun,F.Bruyant,A.McPherson}
\Submitted{01.11.83}                     \Revised{18.11.93}
\Version{Geant 3.16}\Routid{GEOM199}
\Makehead{The volume data structure -- JVOLUM}

\section{The data structure {\tt JVOLUM} and {\tt JGPAR}}

The meaning of the variables in the data structure {\tt JVOLUM} shown
in fig. \ref{fg:geom199-1}
is the following:

\begin{DLtt}{MMMMMMMM}
\item[ISEARC] search flag {\tt [GEOM400], [GEOM410]}:
\begin{DLtt}{MMMM}
\item[$=$0] volume positioning order or ordering by \Rind{GSNEXT}/\Rind{GSNEAR};
\item[$<$0] binary search as defined by \Rind{GSORD};
\item[$>$0] user ordering \Rind{GSUNEA}/\Rind{GUNEAR};
\end{DLtt}
\item[ISHAPE] system shape number (see {\tt [GEOM050]};
\item[NIN] number of volumes contained in the mother volume --
if negative the volume is divided;
\item[NMED] medium number for the volume;
\item[NPAR] number of shape parameters;
\item[NATT] number of attributes;
\item[PAR] array of shape parameters;
\item[IAT] array of attributes;
\item[IAXIS] direction of the division (see {\tt [GEOM130]});
\item[IVO] system volume number;
\item[NDIV] number of divisions ({\tt -NDVMX}, if computed dynamically,
see {\tt [GEOM140]});
\item[C0] coordinate value at which the division starts;
\item[STEP] coordinate step for the division;
\item[NR] user copy number;
\item[IROT] rotation matrix number defining the orientation of the volume
with respect to the mother reference system;
\item[X,Y,Z] position of the volume with respect to the mother reference
system;
\item[KONLY] {\tt ONLY/MANY} flag, see {\tt [GEOM110]} for more information;
\end{DLtt}

\begin{figure}[hbt]
     \centering
     \epsfig{file=eps/geom199-1.eps,width=14cm}
     \caption{Example of geometrical tree structure}
     \label{fg:geom199-1}
\end{figure}