\chapter{Schedule Properties and Argumentation}
\label{properties}

Schedule properties such as feasibility are modelled using frameworks to explain the satisfaction of properties. The definitions of efficiency and fixed decision frameworks extend from the definition of the feasibility framework. In this chapter, this extension is interesting because, this can be generalised to reason about arbitrary number of properties, using a extended framework. We apply this generalisation to interval scheduling to illustrate applications of argumentation.
\linespace
We use stability over other notions of good extensions such as admissibility and completeness to accurately model schedule constraints. This is because we know that existing problems, such as the stable marriage problem can be modelling using stability \cite{aa}.

\section{Frameworks}
\label{unionframeworks}

In order to reason about an arbitrary number of properties, we inductively construct the expressible properties over an extendable framework, denoted by $\pair{Args}{\rightsquigarrow_0}$. An arbitrary property $P_k$ is modelled by the framework $\pair{Args}{\rightsquigarrow_k}$. To be correct, we must preserve that extension $E$ is stable on $\pair{Args}{\rightsquigarrow_0\cup\rightsquigarrow_k}$ if $E$ is also stable on $\pair{Args}{\rightsquigarrow_0}$ and $P(S)$ holds. Let $\rightsquigarrow,\rightsquigarrow_1,\rightsquigarrow_2\subseteq Args^2$ be arbitrary frameworks.

\begin{definition}
	A framework $\pair{Args}{\rightsquigarrow}$ stability-models a schedule property $P$ iff for all extensions $E$ and corresponding schedules $S$, $E$ is stable on $\pair{Args}{\rightsquigarrow}$ $\Leftrightarrow$ $P(S)$
\end{definition}

\begin{definition}
	A framework $\pair{Args}{\rightsquigarrow}$ conflict-models a schedule property $P$ iff for all extensions $E$ and corresponding schedules $S$, $E$ is conflict-free on $\pair{Args}{\rightsquigarrow}$ $\Leftrightarrow$ $P(S)$
\end{definition}

These definitions are used to make concise proofs.

\begin{proposition}
	$\rightsquigarrow_F$ stability-models feasibility \cite{aes}.
\end{proposition}

\begin{proposition}
	$\rightsquigarrow_S$ stability-models feasibility and efficiency \cite{aes}.
\end{proposition}

\begin{proposition}
	$\rightsquigarrow_D$ stability-models feasibility and satisfaction of fixed decisions \cite{aes}.
\end{proposition}

\begin{definition}
	\label{conflictmodellable}

	A schedule property $P$ is conflict-modellable iff there exists a framework that conflict-models $P$.
\end{definition}

\begin{definition}
	\label{stablemodellable}

	A schedule property $P$ is stability-modellable iff there exists a framework that stability-models $P$.
\end{definition}

Definitions \ref{conflictmodellable} and \ref{stablemodellable} intuitively specifies that a property can be verified using AAFs. In context of schedules, stability-modellable constraints are useful because it shows an application of argumentation. However, a stability-modellable constraint is not equivalent to using any argumentation framework. For example, the constraint $a+b+c+d\leq 2$ is not stability-modellable because stability does not count the number of conflicting attacks or unattacked arguments. But in value-based argumentation frameworks, it is possible to define an altered form of stability that is sensitive to attack weights. To find an extension in this weighted-stability, this problem can be reduced into a subset sum problem, which cannot be solved in polynomial time.

\begin{lemma}
	\label{buildconflictfreeness}
	$E$ is conflict-free on $\pair{Args}{\rightsquigarrow_1}$ and on $\pair{Args}{\rightsquigarrow_2}$ iff $E$ is conflict-free on $\pair{Args}{\rightsquigarrow_1\cup\rightsquigarrow_2}$.

	\begin{proof}
		To prove the forward implication, assume $E$ is conflict-free on $\pair{Args}{\rightsquigarrow_1}$ and on $\pair{Args}{\rightsquigarrow_2}$. To aim for a contradiction, assume $E$ is not conflict-free on $\pair{Args}{\rightsquigarrow_1\cup\rightsquigarrow_2}$. Then there exists $e_1,e_2\in E$ such that $e_1(\rightsquigarrow_1\cup\rightsquigarrow_2)e_2$. Then $e_1\rightsquigarrow_1 e_2$ or $e_1\rightsquigarrow_2 e_2$. Both cases lead to a contradiction, so $E$ is conflict-free on $\pair{Args}{\rightsquigarrow_1\cup\rightsquigarrow_2}$.
		\linespace
		To prove the backward implication, assume $E$ is conflict-free on $\pair{Args}{\rightsquigarrow_1\cup\rightsquigarrow_2}$. To aim for a contradiction, assume $E$ is not conflict-free on $\pair{Args}{\rightsquigarrow_1}$. Then there exists $e_1,e_2\in E$ such that $e_1\rightsquigarrow_1 e_2$. Then $e_1(\rightsquigarrow_1\cup\rightsquigarrow_2)e_2$, which contradicts the most recent assumption. Therefore, $E$ is conflict-free on $\pair{Args}{\rightsquigarrow_1}$, and also conflict-free on $\pair{Args}{\rightsquigarrow_2}$ by similar argument.
	\end{proof}
\end{lemma}

\begin{figure}[H]
	\begin{center}
		\begin{tikzpicture}
			\node[node](a) at (0, 2){a};
			\node[node, shaded](b) at (2, 2){b};
			\node[node](c) at (2, 0){c};
			\node[node, shaded](d) at (0, 0){d};
			\draw[arrow](a) -- (c);
			\draw[arrow](c) -- (b);
			\draw[arrow](d) -- (a);
		\end{tikzpicture}\hspace{1cm}
		\begin{tikzpicture}
			\node[node](a) at (0, 2){a};
			\node[node, shaded](b) at (2, 2){b};
			\node[node](c) at (2, 0){c};
			\node[node, shaded](d) at (0, 0){d};
			\draw[arrow, dashed](b) -- (a);
			\draw[arrow, dashed](c) -- (b);
			\draw[arrow, dashed](c) -- (d);
		\end{tikzpicture}\hspace{1cm}
		\begin{tikzpicture}
			\node[node](a) at (0, 2){a};
			\node[node, shaded](b) at (2, 2){b};
			\node[node](c) at (2, 0){c};
			\node[node, shaded](d) at (0, 0){d};
			\draw[arrow](a) -- (c);
			\draw[arrow](c) -- (b);
			\draw[arrow](d) -- (a);
			\draw[arrow, dashed](b) -- (a);
			\draw[arrow, dashed](c) -- (b);
			\draw[arrow, dashed](c) -- (d);
		\end{tikzpicture}
	\end{center}
	\caption{Lemma \ref{buildconflictfreeness} states that given a conflict-free extension over two attack sets on the same arguments, the extension is conflict-free on the merged framework. The figure illustrates this by merging the left and middle frameworks to produce the right framework.}
\end{figure}

\begin{lemma}
	\label{buildstability}
	If $E$ is stable on $\pair{Args}{\rightsquigarrow_1}$ and $E$ is conflict-free on $\pair{Args}{\rightsquigarrow_2}$, then $E$ is stable on $\pair{Args}{\rightsquigarrow_1\cup\rightsquigarrow_2}$.

	\begin{proof}
		Assume $E$ is stable on $\rightsquigarrow_1$ and $E$ is conflict-free on $\rightsquigarrow_2$. By definition of stability, $\forall a\in Args\setminus E\ \exists e\in E\ e\rightsquigarrow_1 a$. Then $\forall a\in Args\setminus E\ \exists e\in E\ e(\rightsquigarrow_1\cup\rightsquigarrow_2)a$. So every argument not in $E$ is attacked by some argument in $E$. $E$ is conflict-free on $\rightsquigarrow_1$ because $E$ is stable on $\rightsquigarrow_1$. Since $E$ is conflict-free on $\rightsquigarrow_1$ and on $\rightsquigarrow_2$, we use Lemma \ref{buildconflictfreeness} to show that $E$ is also conflict-free on $(\rightsquigarrow_1\cup\rightsquigarrow_2)$. Therefore $E$ is stable on $\pair{Args}{\rightsquigarrow_1\cup\rightsquigarrow_2}$.
	\end{proof}
\end{lemma}

\begin{figure}[H]
	\begin{center}
		\begin{tikzpicture}
		\node[node](a) at (0, 2){a};
		\node[node](b) at (2, 2){b};
		\node[node, shaded](c) at (2, 0){c};
		\node[node, shaded](d) at (0, 0){d};
		\draw[arrow](a) -- (c);
		\draw[arrow](c) -- (b);
		\draw[arrow](d) -- (a);
		\end{tikzpicture}\hspace{1cm}
		\begin{tikzpicture}
		\node[node](a) at (0, 2){a};
		\node[node](b) at (2, 2){b};
		\node[node, shaded](c) at (2, 0){c};
		\node[node, shaded](d) at (0, 0){d};
		\draw[arrow, dashed](b) -- (a);
		\draw[arrow, dashed](b) -- (d);
		\end{tikzpicture}\hspace{1cm}
		\begin{tikzpicture}
		\node[node](a) at (0, 2){a};
		\node[node](b) at (2, 2){b};
		\node[node, shaded](c) at (2, 0){c};
		\node[node, shaded](d) at (0, 0){d};
		\draw[arrow](a) -- (c);
		\draw[arrow](c) -- (b);
		\draw[arrow](d) -- (a);
		\draw[arrow, dashed](b) -- (a);
		\draw[arrow, dashed](b) -- (d);
		\end{tikzpicture}
	\end{center}
	\caption{Lemma \ref{buildstability} allows stable extensions of attacks to grow with conflict-free attacks. The left framework is the base framework and the right framework is the extended framework.}
\end{figure}

\begin{lemma}
	\label{reduceconflictfreeness}
	If $E$ is stable on $\pair{Args}{\rightsquigarrow_1\cup\rightsquigarrow_2}$, then $E$ is conflict-free on $\pair{Args}{\rightsquigarrow_1}$.

	\begin{proof}
		Assume $E$ is stable on $\pair{Args}{\rightsquigarrow_1\cup\rightsquigarrow_2}$. By definition of stability, $E$ is conflict-free on $\pair{Args}{\rightsquigarrow_1\cup\rightsquigarrow_2}$.  By Lemma \ref{buildconflictfreeness}, $E$ is conflict-free on $\pair{Args}{\rightsquigarrow_1}$.
	\end{proof}
\end{lemma}

\begin{figure}[H]
	\begin{center}
		\begin{tikzpicture}
			\node[node](a) at (0, 2){a};
			\node[node](b) at (2, 2){b};
			\node[node, shaded](c) at (2, 0){c};
			\node[node, shaded](d) at (0, 0){d};
			\draw[arrow](a) -- (c);
			\draw[arrow](b) -- (a);
			\draw[arrow](c) -- (b);
			\draw[arrow](d) -- (a);
		\end{tikzpicture}\hspace{3cm}
		\begin{tikzpicture}
			\node[node](a) at (0, 2){a};
			\node[node](b) at (2, 2){b};
			\node[node, shaded](c) at (2, 0){c};
			\node[node, shaded](d) at (0, 0){d};
			\draw[arrow](a) -- (c);
			\draw[arrow](c) -- (b);
		\end{tikzpicture}
	\end{center}
	\caption{Lemma \ref{reduceconflictfreeness} states that given a stable extension, removing attacks preserves the extension's conflict-freeness, as shown from left to right.}
\end{figure}

\begin{lemma}
	\label{reducestability}
	If $E$ is stable on $\pair{Args}{\rightsquigarrow_1\cup\rightsquigarrow_2}$ and $\forall a\in Args\setminus E\ (\exists e\in E\ e\rightsquigarrow_2 a)\implies(\exists e\in E\ e\rightsquigarrow_1 a)$, then $E$ is stable on $\pair{Args}{\rightsquigarrow_1}$.

	\begin{proof}
		\begin{flalign*}
			&E\text{ is stable on }\pair{Args}{\rightsquigarrow_1\cup\rightsquigarrow_2}&\\
			&\land\forall a\in Args\setminus E\ (\exists e\in E\ e\rightsquigarrow_2 a)\implies(\exists e\in E\ e\rightsquigarrow_1 a)\\
			\implies&E\text{ is conflict-free on }\pair{Args}{\rightsquigarrow_1\cup\rightsquigarrow_2}\\
			&\land\forall a\in Args\setminus E\ \exists e\in E\ e(\rightsquigarrow_1\cup\rightsquigarrow_2)\\
			&\land\forall a\in Args\setminus E\ (\exists e\in E\ e\rightsquigarrow_2 a)\implies(\exists e\in E\ e\rightsquigarrow_1 a)\\
			&\textit{definition of stability}\\
			\implies&E\text{ is conflict-free on }\pair{Args}{\rightsquigarrow_1}\\
			&\land\forall a\in Args\setminus E\ \exists e\in E\ (e\rightsquigarrow_1 a\lor e\rightsquigarrow_2 a)\\
			&\land\forall a\in Args\setminus E\ (\exists e\in E\ e\rightsquigarrow_2 a)\implies(\exists e\in E\ e\rightsquigarrow_1 a)\\
			&\textit{definition of $\cup$}\\
			\implies&E\text{ is conflict-free on }\pair{Args}{\rightsquigarrow_1}\\
			&\land\forall a\in Args\setminus E\ ((\exists e\in E\ e\rightsquigarrow_1 a)\lor(\exists e\in E\ e\rightsquigarrow_2 a))\\
			&\land\forall a\in Args\setminus E\ (\exists e\in E\ e\rightsquigarrow_2 a)\implies(\exists e\in E\ e\rightsquigarrow_1 a)\\
			&\textit{distribute $\lor$ over $\exists$}\\
			\implies&E\text{ is conflict-free on }\pair{Args}{\rightsquigarrow_1}\\
			&\land\forall a\in Args\setminus E\ ((\exists e\in E\ e\rightsquigarrow_1 a)\lor(\exists e\in E\ e\rightsquigarrow_1 a))\\
			&\textit{substitute $\rightsquigarrow_2$ to $\rightsquigarrow_1$}\\
			\implies&E\text{ is conflict-free on }\pair{Args}{\rightsquigarrow_1}\\
			&\textit{idempotency of $\lor$}\\
			&\land\forall a\in Args\setminus E\ \exists e\in E\ e\rightsquigarrow_1 a\\
			\implies&E\text{ is stable on }\pair{Args}{\rightsquigarrow_1}\\
			&\textit{definition of stability}
		\end{flalign*}
	\end{proof}
\end{lemma}

\begin{figure}[H]
	\begin{center}
		\begin{tikzpicture}
		\node[node](a) at (0, 2){a};
		\node[node](b) at (2, 2){b};
		\node[node, shaded](c) at (2, 0){c};
		\node[node, shaded](d) at (0, 0){d};
		\draw[arrow, dashed](c) -- (a);
		\draw[arrow](c) -- (b);
		\draw[arrow](d) -- (a);
		\draw[arrow, dashed](d) -- (b);
		\end{tikzpicture}\hspace{3cm}
		\begin{tikzpicture}
		\node[node](a) at (0, 2){a};
		\node[node](b) at (2, 2){b};
		\node[node, shaded](c) at (2, 0){c};
		\node[node, shaded](d) at (0, 0){d};
		\draw[arrow](c) -- (b);
		\draw[arrow](d) -- (a);
		\end{tikzpicture}
	\end{center}
	\caption{Lemma \ref{reducestability} states that given a stable extension, removing attacks on multi-attacked arguments preserves the extension's stability, as shown from left to right.}
\end{figure}

\begin{theorem}[\textbf{Union of modelling frameworks}]
	\label{modelling}
	Let $P_0,...,P_K$ be schedule properties with $K$ properties. Let $P_{\intset{i,j}}$ be an aggregate schedule property where for all schedules $S$, $P_{\intset{i, j}}(S)\iff\forall k\in\intset{i,j}\ P_k(S)$.
	\linespace
	If $\rightsquigarrow_0$ stability-models $P_0$, and $\forall k\in\intset{1,K}\ \rightsquigarrow_k$ conflict-models $P_k$, and for all extensions $E$, $\forall a\in Args\setminus E\ \forall k\in\intset{1,K}\ \big((\exists e\in E\ e\rightsquigarrow_k a)\implies(\exists e\in E\ e\rightsquigarrow_0 a)\big)$, then $\left(\bigcup_{k=0}^K\rightsquigarrow_k\right)$ stability-models $P_{\intset{0,K}}$.

	\begin{proof}
		Take arbitrary $K\in\mathbb{N}$. To prove forward implication:
		\begin{enumerate}
			\item$\rightsquigarrow_0$ stability-models $P_0$\hfill given
			\item$\forall k\in\intset{1,K}\ \rightsquigarrow_k$ conflict-models $P_k$\hfill given
			\item$\forall a\in Args\setminus E\ \forall k\in\intset{1,K}\ \big((\exists e\in E\ e\rightsquigarrow_k a)\implies(\exists e\in E\ e\rightsquigarrow_0 a)\big)$\\\null\hfill given
			\item$E$ is stable on $\pair{Args}{\bigcup_{k=0}^K\rightsquigarrow_k}$\hfill assumption
			\item$\forall a\in Arg\setminus E\ \left(\left(\exists e\in E\ e\left(\bigcup_{k=0}^K\rightsquigarrow_k\right) a\right)\implies(\exists e\in E\ e\rightsquigarrow_0 a)\right)$\\\null\hfill 3
			\item$E$ is stable on $\pair{Args}{\rightsquigarrow_0}$\hfill lemma \ref{reducestability}, 4, 5
			\item$P_0(S)$\hfill 1, 6
			\item Take arbitrary $k\in\intset{1,K}$
			\begin{level}
				\item$E$ is conflict-free on $\pair{Args}{\rightsquigarrow_k}$\hfill lemma \ref{reduceconflictfreeness}, 4
				\item$P_k$(S)\hfill 2, 9
			\end{level}
			\item$\forall k\in\intset{1,K}\ P_k(S)$\hfill 8, 10
			\item$P_{\intset{0,K}}(S)$ \hfill 7, 11
		\end{enumerate}

		To prove backward implication:
		\begin{enumerate}
			\item$\rightsquigarrow_0$ stability-models $P_0$\hfill given
			\item$\forall k\in\intset{1,K}\ \rightsquigarrow_k$ conflict-models $P_k$\hfill given
			\item$P_{\intset{0,K}}(S)$\hfill assumption
			\item$P_0(S)$\hfill 3
			\item$E$ is stable on $\pair{Args}{\rightsquigarrow_0}$\hfill 1, 4
			\item Recursively over $k\in\intset{1,K}$
			\begin{level}
				\item $P_k(S)$\hfill 3
				\item $E$ is conflict-free on $\pair{Arg}{\rightsquigarrow_k}$\hfill 2, 7
				\item $E$ is stable on $\pair{Arg}{\bigcup_{k'=0}^k\rightsquigarrow_{k'}}$\hfill lemma \ref{buildstability}, 5, 8
			\end{level}
			\item $E$ is stable on $\pair{Arg}{\bigcup_{k=0}^K\rightsquigarrow_k}$\hfill 6, 9
		\end{enumerate}
	\end{proof}
\end{theorem}

\begin{figure}[H]
	\begin{center}
		\begin{tikzpicture}
			\node[node, shaded](a) at (0, 1.5){a};
			\node[node](b) at (1.5, 1.5){b};
			\node[node, shaded](c) at (1.5, 0){c};
			\node[node](d) at (0, 0){d};
			\draw[arrow](a) -- (b);
			\draw[arrow](b) -- (a);
			\draw[arrow](c) -- (d);
			\draw[arrow](d) -- (c);
			\draw(-0.5,-0.5) rectangle (2,2);
			\node at (0.8, -0.8){stability-models $P_0$};
		\end{tikzpicture}\raisebox{1.4cm}{\huge{$\land$}}
		\begin{tikzpicture}
			\node[node, shaded](a) at (0, 1.5){a};
			\node[node](b) at (1.5, 1.5){b};
			\node[node, shaded](c) at (1.5, 0){c};
			\node[node](d) at (0, 0){d};
			\draw[arrow](b) -- (c);
			\draw(-0.5,-0.5) rectangle (2,2);
			\node at (0.8, -0.8){conflict-models $P_1$};
		\end{tikzpicture}\raisebox{1.4cm}{\huge{$\land$ ... $\land$}}
		\begin{tikzpicture}
			\node[node, shaded](a) at (0, 1.5){a};
			\node[node](b) at (1.5, 1.5){b};
			\node[node, shaded](c) at (1.5, 0){c};
			\node[node](d) at (0, 0){d};
			\draw[arrow](b) -- (d);
			\draw(-0.5,-0.5) rectangle (2,2);
			\node at (0.8, -0.8){conflict-models $P_K$};
		\end{tikzpicture}\linespace
		{\huge{$\Updownarrow$}}
		\linespace
		\begin{tikzpicture}
			\node[node, shaded](a) at (0, 2){a};
			\node[node](b) at (2, 2){b};
			\node[node, shaded](c) at (2, 0){c};
			\node[node](d) at (0, 0){d};
			\draw[arrow](a) -- (b);
			\draw[arrow](b) -- (a);
			\draw[arrow](b) -- (c);
			\draw[arrow](b) -- (d);
			\draw[arrow](c) -- (d);
			\draw[arrow](d) -- (c);
			\draw(-0.5,-0.5) rectangle (2.5, 2.5);
			\node at (1, -0.8){stability-models $P_{\intset{0,K}}$};
		\end{tikzpicture}
		\vspace{-\baselineskip}
	\end{center}
	\caption{Theorem \ref{modelling} allows manipulation of an aggregate property, $P_{\intset{0,K}}$ from carefully extending frameworks, while preserving stability. This theorem is a key statement in framing argumentation semantics for arbitrary scheduling problems.}
\end{figure}

Theorem \ref{modelling} cannot be applied to $\rightsquigarrow_S$ or $\rightsquigarrow_D$ because they remove attacks from the $\rightsquigarrow_F$. The theorem does not capture removal of attacks from a commonly-extendable framework because there is ambiguity between the order of removal and insertion of attacks. Formally, $(\rightsquigarrow\cup \rightsquigarrow^+)\setminus \rightsquigarrow^-\neq (\rightsquigarrow\setminus\rightsquigarrow^-)\cup\rightsquigarrow^+$ for arbitrary frameworks $\rightsquigarrow,\rightsquigarrow^-,\rightsquigarrow^+$.

\section{Interval Scheduling}
\label{interval}

Makespan schedules are extended to discrete time-indexed interval scheduling. We will show an application of Theorem \ref{modelling} to interval scheduling. Let $T$ be the exclusive upper-bound of indexed time where $\mathcal{T}=\{0,...,T-1\}$. The assignment matrix $\mathbf{x}\in\mathcal{M}\times\mathcal{J}\times\mathcal{T}$ is extended such that $x_{i,j,t}=1$ iff job $j$ is starts work on machine $i$ at time $t$. Each machine job pair $\pair{i}{j}$ has a start time $s_{i,j}\in\mathcal{T}^{mn}$ and finish time $f_{i,j}\in\{0,...,T\}^{mn}$, where $j$ must be completed within the $[s_{i,j},f_{i,j})$ interval. The objective is to minimise the total completion time.

\begin{align*}
	\min_{\mathbf{x}}\ &C_{\max}\text{ subject to:}\\
	\forall i\in\mathcal{M}\ \forall j\in\mathcal{J}\ \forall t\in\mathcal{T}\ &C_{\max}\geq x_{i,j,t}(t+p_j)\\
	\forall j\in\mathcal{J}\ &\sum_{i\in\mathcal{M}}\sum_{t\in\mathcal{T}}x_{i,j,t}=1&\alpha\\
	\forall i\in\mathcal{M}\ \forall t\in\mathcal{T}\ &\sum_{j\in\mathcal{J}}\sum_{t'=\max\{t-p_j+1,0\}}^t x_{i,j,t'}\leq 1&\beta\\
	\forall i\in\mathcal{M}\ \forall j\in\mathcal{J}\ \forall t\in\{0,...,s_{i,j}-1\}\ &x_{i,j,t}=0&\gamma\\
	\forall i\in\mathcal{M}\ \forall j\in\mathcal{J}\ \forall t\in\{f_{i,j}-p_j+1,...,T-1\}\ &x_{i,j,t}=0&\delta\\
	\forall\triple{i}{j}{t}\in D^-\ &x_{i,j,t}=0&\varepsilon\\
	\forall\triple{i'}{j}{t'}\in D^+\ \forall i\in\mathcal{M}\setminus\{i'\}\ \forall t\in\mathcal{T}\ &x_{i,j,t}=0&\zeta\\
	\forall\triple{i}{j}{t'}\in D^+\ \forall t\in\mathcal{T}\ &&\\
	t\leq t'-p_j\lor t\geq t'+p_j\implies&x_{i,j,t}=0&\eta\\
\end{align*}

$\alpha$ models feasibility, that all jobs must be allocated. $\beta$ models that machines cannot process multiple jobs at the same time. $\gamma$ and $\delta$ models the restriction of start and end times respectively. $\varepsilon$ and $\zeta$ models negative and positive fixed decisions respectively. Equivalently, $\zeta$ can be modelled by $\forall\triple{i}{j}{t'}\in D^+\ \exists t\in\mathcal{T}\ x_{i,j,t}=1$. $\zeta$ is defined as such to simplify the proof that the union of these properties is modellable. $\eta$ models enforces that $j$ is working on $i$ at $t$, but does not specify the when $j$ starts. Note that $\gamma,\delta,\zeta$ and $\eta$ can be modelled using $\varepsilon$. We use more constants to give better explanations, because each constraint have different explanations. For argumentation, let $Args=\mathcal{M}\times\mathcal{J}\times\mathcal{T}$.

\begin{figure}[H]
	\begin{center}
		\includegraphics[width=.8\linewidth]{figures/interval.png}
	\end{center}
	\caption{An interval schedule, where black areas are assignments and the grey areas show invalid slots because of negative fixed decisions or other job assignees.}
\end{figure}

\begin{definition}
	\label{intervalalpha}

	Let $\rightsquigarrow_\alpha$ be the base-feasibility framework such that $\triple{i}{j}{t}\rightsquigarrow_\alpha\triple{i'}{j'}{t'}\Leftrightarrow i\neq i'\land j=j'\land t\neq t'$
\end{definition}

$\rightsquigarrow_\alpha$ can be interpreted as an generalisation of $\rightsquigarrow_F$ with time.

\begin{lemma}
	\label{stabilityalpha}
	$\rightsquigarrow_\alpha$ stability-models $\alpha$.

	\begin{proof}
		To prove forward implication: $E$ is stable on $\pair{Args}{\rightsquigarrow_\alpha}$. Take arbitrary $j\in\mathcal{J}$. To aim to contradict, assume $\sum_{i\in\mathcal{M}}\sum_{t\in\mathcal{T}}x_{i,j,t}>1$. Then $\exists\triple{i}{j}{t},\triple{i'}{j}{t'}\in E$ where $x_{i,j,t}=1$ and $x_{i',j,t'}=1$ such that $i\neq i'$ or $t\neq t'$. By definition of $\rightsquigarrow_\alpha$, $\triple{i}{j}{t}\rightsquigarrow_\alpha\triple{i'}{j}{t'}$. Hence $E$ is not conflict-free, then $E$ is not stable. By contradiction, $\sum_{i\in\mathcal{M}}\sum_{t\in\mathcal{T}}x_{i,j,t}\leq 1$. To aim to contradict, assume $\sum_{i\in\mathcal{M}}\sum_{t\in\mathcal{T}}x_{i,j,t}=0$. Then $\forall i\in\mathcal{M}\ \forall t\in\mathcal{T}\ x_{i,j,t}=0$. Then $\forall i\in\mathcal{M}\ \forall t\in\mathcal{T}\ \triple{i}{j}{t}\not\in E$. Then $E$ is not stable. By contradiction, $\sum_{i\in\mathcal{M}}\sum_{t\in\mathcal{T}}x_{i,j,t}>0$. Therefore $\alpha$ holds.
		\linespace
		To prove backward implication: From $\alpha$, there is exactly one $i\in\mathcal{M}$ and $t\in\mathcal{T}$ such that $x_{i,j,t}=1$. So $E$ is conflict free. Also, for all $j$, $\triple{i}{j}{t}\in E$ attacks every other $\pair{i}{t}$, so $E$ is stable.
	\end{proof}
\end{lemma}

\begin{definition}
	\label{intervalbeta}

	Let $\rightsquigarrow_\beta$ be the sequential-feasibility framework such that $\triple{i}{j}{t}\rightsquigarrow_\beta\triple{i'}{j'}{t'}\Leftrightarrow i=i'\land(t'\leq t\leq t'+p_j'\lor t\leq t'<t+p_j)$.
\end{definition}

\begin{lemma}
	\label{conflictfreenessbeta}
	$\rightsquigarrow_\beta$ conflict-models $\beta$.

	\begin{proof}
		To show $E$ is conflict-free implies $\beta$: Take arbitrary $i\in\mathcal{M}$, $t\in\mathcal{T}$. To aim for a contradiction, assume $\sum_{j\in\mathcal{J}}\sum_{t'\in\max\{t-p_j+1,0\}}x_{i,j,t'}\geq 2$. Then there exists some $j_1,j_2\in\mathcal{J}$ and some $t_1,t_2\in\mathcal{T}$ such that $0\leq t_1,t_2\leq t$ and $x_{i,j_1,t_1}+x_{i,j_2,t_2}=2$. Then $\triple{i}{j_1}{t_1}\in E$ and $\triple{i}{j_2}{t_2}\in E$. By conduction of $\beta$, then either $t_1\leq t_2\leq t_1+p_1$ or $t_2\leq t_1\leq t_2+p_2$. By definition of $\rightsquigarrow_\beta$, $\triple{i}{j_1}{t_1}\rightsquigarrow_\beta\triple{i}{j_2}{t_2}$. But this contradicts that $E$ is conflict-free. Therefore $\beta$ holds.
		\linespace
		To show $\beta$ implies $E$ is conflict-free: Assume $\beta$ holds. Take arbitrary $i\in\mathcal{M}$, $t\in\mathcal{T}$. Then there does not exists overlapping jobs $j_1$ and $j_2$ such that $x_{i,j_1,t_1}+x_{i,j_2,t_2}=2$. Then $\triple{i}{j_1}{t_1}\not\in E$ and $\triple{i}{j_2}{t_2}\not\in E$. Therefore, $E$ is conflict-free.
	\end{proof}
\end{lemma}

\begin{definition}
	\label{intervalgamma}

	Let $\rightsquigarrow_\gamma$ be a start-feasibility framework such that

	$\rightsquigarrow_\gamma=\{\pair{\triple{i}{j}{t}}{\triple{i}{j}{t}}\ |\ i\in\mathcal{M},j\in\mathcal{J},0\leq t<s_{i,j}\}$.
\end{definition}

\begin{definition}
	\label{intervaldelta}
	Let $\rightsquigarrow_\delta$ be a finish-feasibility framework such that

	$\rightsquigarrow_\delta=\{\pair{\triple{i}{j}{t}}{\triple{i}{j}{t}}\ |\ i\in\mathcal{M},j\in\mathcal{J},f_{i,j}-p_j<t<T\}$.
\end{definition}

\begin{definition}
	\label{intervalepsilon}

	Let $\rightsquigarrow_\varepsilon$ be the negative fixed decision feasibility framework such that

	$\rightsquigarrow_\varepsilon=\{\pair{\triple{i}{j}{t}}{\triple{i}{j}{t}}\ |\ \pair{i}{j}\in D^-,t\in\mathcal{T}\}$.
\end{definition}

\begin{definition}
	\label{intervalzeta}

	Let $\rightsquigarrow_\zeta$ be a positive fixed decision feasibility framework such that
	$\rightsquigarrow_\varepsilon=\{\pair{\triple{i}{j}{t}}{\triple{i}{j}{t}}\ |\ i\in\mathcal{M}, \triple{i'}{j}{t'}\in D^+, i\neq i', t\in\mathcal{T}\}$.
\end{definition}

\begin{definition}
	\label{intervaleta}

	Let $\rightsquigarrow_\eta$ be a positive fixed decision feasibility framework such that
	$\rightsquigarrow_\varepsilon=\{\pair{\triple{i}{j}{t}}{\triple{i}{j}{t}}\ |\triple{i}{j}{t'}\in D^+, t\in\mathcal{T}, t\leq t'-p_j\lor t\geq t'+p_j\}$.
\end{definition}

\begin{lemma}
	\label{conflictfreenessset}
	Let $\mathcal{A}\subseteq Args$ be the set of arbitrary negative fixed decisions. A schedule $S$ satisfies these decisions if property $P_\mathcal{A}$ holds. Formally $P_\mathcal{A}\iff\forall a\in\mathcal{A}\ x_a=0$. If $\rightsquigarrow_\mathcal{A}$ is defined by $\rightsquigarrow_\mathcal{A}=\{\pair{a}{a}\ |\ a\in\mathcal{A}\}$, then $\rightsquigarrow_\mathcal{A}$ conflict-models $P_\mathcal{A}$.

	\begin{proof}
		To prove forward implication: Assume $E$ is conflict free on $\pair{Args}{\rightsquigarrow_\mathcal{A}}$. Take arbitrary $a\in\mathcal{A}$. To aim for a contradiction, assume $x_a=1$. Then $a\in E$. By definition of $\rightsquigarrow_\mathcal{A}$, $a\rightsquigarrow_\mathcal{A} a$. But this contradicts $E$ is conflict-free so $x_a=0$. Therefore $P_\mathcal{A}(S)$ holds.
		\linespace
		To prove backward implication: Assume $P_\mathcal{A}(S)$ holds. Take arbitrary $a\in\mathcal{A}$. To aim for a contradiction, assume $a\rightsquigarrow_\mathcal{A}a$. Then $a\in E$, so $x_a=1$. This contradicts $P_\mathcal{A}(S)$, so $E$ is conflict-free.
	\end{proof}
\end{lemma}

\begin{figure}[H]
	\centering
	\begin{tikzpicture}
	\node[node, shaded](a) at (0, 2){a};
	\node[node](b) at (2, 2){b};
	\node[node](c) at (2, 0){c};
	\node[node](d) at (0, 0){d};
	\draw[arrow](c) to [loop](c);
	\draw[arrow](d) to [loop](d);
	\draw(-1,-1) rectangle (3, 3);
	\end{tikzpicture}\raisebox{2cm}{conflict-models $P_\mathcal{A}$ with $\mathcal{A}=\{c, d\}$}
	\caption{Self-attacking arguments cannot be members of stable extensions. Lemma \ref{conflictfreenessset} exploits self-attacks to conflict-model negative fixed decisions.}
\end{figure}

\begin{lemma}
	\label{intervalstabilitydependence}
	For all extensions $E$, $\forall a\in Args\setminus E\ \forall\lambda\in\{\beta,\gamma,\delta,\varepsilon,\zeta,\eta\}\ \big((\exists e\in E\ e\rightsquigarrow_\lambda a)\implies(\exists e\in E\ e\rightsquigarrow_\alpha a)\big)$.

	\begin{proof}
		Take arbitrary extension $E$ and arbitrary $a\in Args\setminus E$. If $\lambda\neq\beta$ and $\exists e\in E\ e\rightsquigarrow_\lambda a$, then $a=e$ from the definition of $\rightsquigarrow_\lambda$. But $e\not\in Args\setminus E$. By contradiction, $\lambda=\beta$.
		\linespace
		If $m=0$ or $T=0$, then $Args=\varnothing$, so the proof is trivial.
		\linespace
		If $m=1$ and $T=1$, then by definition of $\rightsquigarrow_\beta$, $\rightsquigarrow_\beta=\varnothing$. So $\neg\exists e\in E\ e\rightsquigarrow_\beta a$. As the condition does not hold, $\exists e\in E\ e\rightsquigarrow_\alpha a$.
		\linespace
		Otherwise, let $a=\triple{i}{j}{t}$. Because $m>2$ or $T>2$, then there exists $i$ and $t$ such that $\pair{i}{t}\neq\pair{i'}{t'}$. By definition of $\rightsquigarrow_\alpha$, $\triple{i'}{j}{t'}\rightsquigarrow_\alpha a$.
	\end{proof}
\end{lemma}

\begin{theorem}[\textbf{Interval schedule feasibility is stability-modellable}]
	\label{intervalfeasibilty}

	Let $\Lambda(S)$ iff $\forall\lambda\in\{\alpha,\beta,\gamma,\delta,\varepsilon,\zeta,\eta\}\ \lambda(S)$. $\Lambda$ is stability-modellable.

	\begin{proof}\
		\begin{enumerate}
			\item $\rightsquigarrow_\gamma$ conflict-models $\gamma$ \hfill definition of $\rightsquigarrow_\gamma$, lemma \ref{conflictfreenessset}
			\item $\rightsquigarrow_\delta$ conflict-models $\delta$ \hfill definition of $\rightsquigarrow_\delta$, lemma \ref{conflictfreenessset}
			\item $\rightsquigarrow_\varepsilon$ conflict-models $\varepsilon$ \hfill definition of $\rightsquigarrow_\varepsilon$, lemma \ref{conflictfreenessset}
			\item $\rightsquigarrow_\zeta$ conflict-models $\zeta$ \hfill definition of $\rightsquigarrow_\zeta$, lemma \ref{conflictfreenessset}
			\item $\rightsquigarrow_\eta$ conflict-models $\eta$ \hfill definition of $\rightsquigarrow_\eta$, lemma \ref{conflictfreenessset}
			\item $\left(\bigcup_{\lambda\in\{\alpha,\beta,\gamma,\delta,\varepsilon,\zeta,\eta\}}\rightsquigarrow_\lambda\right)$ stability-models $\Lambda$\\\indent\hfill lemma \ref{stabilityalpha}, lemma \ref{conflictfreenessbeta}, 1, 2, 3, 4, 5, lemma \ref{intervalstabilitydependence}, theorem \ref{modelling}
			\item $\Lambda$ is stability-modellable \hfill 6
		\end{enumerate}
	\end{proof}
\end{theorem}

We have shown an application of argumentation to scheduling with Theorem \ref{modelling}. Theorem \ref{modelling} is relevant because we have shown that we can use argumentation with interval scheduling, as shown in Theorem \ref{intervalfeasibilty}. Theorem \ref{modelling} is key in extensions to scheduling.


\section{Conversions beween WPDSs and NWAs (namespace
  \texttt{opennwa::nwa\_pds})}
\label{Se:Conversions}

It is possible to convert an NWA into a WALi WPDS and vice versa.
However, the construction of an NWA from a WPDS is not the inverse
of constructing a WPDS from an NWA, i.e., one cannot perform the two
conversions in sequence and obtain the identity conversion.

At a high level, the WPDS to NWA conversion works by making the NWA encode both the state
of the WPDS and its top-of-stack symbol. A WPDS rule of the form $\langle
p,q_1 \rangle \hookrightarrow \langle p,q_2 \rangle$ leaves the stack height
unchanged, and is thus associated with an internal NWA transition; in this
case, that transition goes from the state $(p,q_1)$ to $(p,q_2)$. The symbol
of a transition is associated with the top-of-stack symbol of the source
state, so in this example, the symbol labeling that transition would be
$q_1$. In other words, the WPDS rule $\langle p,q_1 \rangle \hookrightarrow
\langle p,q_2 \rangle$ is translated to the NWA internal transition
$((p,q_1), q_1, (p,q_2))$.
WPDS push rules correspond to NWA call transitions, and WPDS pop rules
correspond to NWA return transitions.\footnote{
This encoding is motivated by our uses of both WPDSs and NWAs in program
analysis. It is common for WPDSs to have just one state, $p$, and to use the
top-of-stack symbol to encode the ``current'' program point. Pushing
something onto the stack corresponds to a call, and popping corresponds to a
return. For NWAs, we use the states themselves to encode the current program
point. (The function that
converts a WPDS into an NWA supports multi-state WPDSs, however; a WPDS rule
of the form $\langle p_1,q_1 \rangle \hookrightarrow
\langle p_2,q_2 \rangle$ is translated to the NWA internal transition
$((p_1,q_1), q_1, (p_2,q_2))$.)}

The conversion in the other direction creates a WPDS with one primary state
and one ``helper'' state for each NWA state that appears in the exit position
of a return transition. The NWA's state is encoded by the symbol at the top of the WPDS's
stack -- essentially the inverse of the encoding described in the previous
paragraph. A slight complication arises in the case of return
transitions. The NWA is able to look at both the exit node and the call
predecessor. In the WPDS this would correspond to looking at the top two stack
symbols -- but the WPDS is only allowed to look at the top \emph{one}. Hence each NWA return transition becomes
two WPDS rules: the first pops the top symbol (which corresponds to the
current NWA state) and remembers what it was using the helper state; the
second rule looks at the call predecessor and the helper state to dispatch to
the corresponding return site.

The library also offers two kinds of variants of this conversion. First, there
is a backwards variant that can be used for backwards dataflow-analysis
problems. Second, the resulting WPDS can stack either calls or returns. The
``stacking-calls'' version turns a call transition $(c, \sigma, e)$ into a
WPDS rule $\langle p, c\rangle \hookrightarrow \langle p, e c\rangle$ --
leaving the call predecessor $c$ on the stack. (This is the translation
described in the previous paragraph.) The ``stacking-returns'' version
has, in general, several WPDS push rules for each NWA call transition. Each
push rule leaves a potential return site on the stack. (For example, if there
is a call transition $(c,\sigma,e)$ and a return transition $(x, c, \sigma',
r)$, then the WPDS will have a rule $\langle p,
c\rangle\hookrightarrow\langle p, e r\rangle$.)

The following functions are in the namespace \texttt{opennwa::nwa\_pds}
and, except for \texttt{plusWpds()}, are declared in the header
\texttt{opennwa/nwa\_pds/conversions.hpp}. The \texttt{WPDS} type is
\texttt{wali::wpds::WPDS}, and is declared in \texttt{wali/wpds/WPDS.hpp}.

\begin{functionlist}
  \functionDefEarly{void}{WpdsToNwa}{Nwa \& out, const WPDS\& pds}{}
  \functionDef{NwaRefPtr}{WpdsToNwa}{const WPDS\& pds}{}
    Converts \texttt{pds} to an NWA, either storing the result in
    \texttt{nwa} or returning it.

\clearpage
  \functionDefFirstEarly{WPDS}{NwaToWpdsCalls}{Nwa const \& nwa, WeightGen const \& wg}{}
  \functionDefEarlyNoCloseParen{WPDS}{NwaToWpdsCalls}{\parbox[t]{4in}{Nwa const \& nwa, WeightGen const \& wg,\\ref\_ptr<Wrapper> wr)}}
  \functionDefEarly{WPDS}{NwaToBackwardsWpdsCalls}{Nwa const \& nwa, WeightGen const \& wg}{}
  \functionDefEarly{WPDS}{NwaToWpdsReturns}{Nwa const \& nwa, WeightGen const \& wg}{}
  \functionDef{WPDS}{NwaToBackwardsWpdsReturn}{Nwa const \& nwa, WeightGen const \& wg}{}
    These functions each construct a WPDS that is equivalent to \texttt{nwa} using the
    appropriate method (backwards or forwards flow, and stacking calls or
    stacking returns), returning the result. Uses \texttt{wg} to determine
    weights for the WPDS's transitions. The second variant of
    \texttt{NwaToWpdsCalls} takes a \texttt{wali::wpds::Wrapper} reference
    \texttt{wr}, and the WPDS is constructed by passing \texttt{wr} to the
    constructor. This feature can be used, for instance, if you would like the
    resulting WPDS to support witness tracing. (If \texttt{wr} is
    \texttt{NULL}, then the second version is equivalent to the first.)

  \functionDefFirst{State}{getProgramControlLocation}{}{}
    Returns the program state $p$ used as the primary WPDS state in the
    result of the \texttt{NwaToWpds*} variants.

  \functionDefFirst{State}{getControlLocation}{State exit, State call, State return}{}
    Returns the WPDS state $p_{q_x}$ or $p_{q_3}$ used as a ``helper'' state
    for return transitions from \texttt{exit} to \texttt{return} with
    \texttt{call} as a predecessor.

  \functionDefFirst{WPDS}{plusWpds}{Nwa const \& nwa, const WPDS\& base}{}
    This function returns a WPDS that is the
    product of the NWA \texttt{nwa} and WPDS \texttt{base}, as described in the ``Explicit
    NWA plus PDS'' construction from \cite[\S6]{advancedquerying}. This
    function is declared in the header
    \texttt{opennwa/nwa\_pds/plusWpds.hpp}.
\end{functionlist}

\subsection{WPDS to NWA}
\label{Se:WpdsToNwa}

The \texttt{WpdsToNwa} functions convert a WPDS into an NWA in a manner
faithful to the encoding sketched out in the introduction to this section.

Assume that we have a WPDS $(P, \Gamma, \Delta )$
where $\Delta = (\Delta_0, \Delta_1, \Delta_2)$. This
WPDS is converted into an NWA $(Q,\Sigma,\{\},\delta,\{\})$ using the following rules:

\begin{mathpar}
{\inferrule*[left=\textsc{States}]
  { p \in P \\ q \in \Gamma }
  { (p,q) \in Q }
}
\and
{\inferrule*[left=\textsc{Alphabet}]
  { q \in \Gamma }
  { q \in \Sigma }
}
\and
\\
{\inferrule*[left=\textsc{Internal}]
  { \langle p,q \rangle \hookrightarrow \langle p',q' \rangle \in  \Delta_1 }
  { ( (p,q), q, (p',q') ) \in \delta_i  }
}
\and
{\inferrule*[left=\textsc{Call}]
  { \langle p,q_c \rangle \hookrightarrow \langle  p',q_e \hspace{.1cm} q_r \rangle \in \Delta_2 }
  { ( (p,q_c), q_c, (p',q_e) ) \in \delta_c }
}
\and
{\inferrule*[left=\textsc{Return}]
  { \langle p'',q_x \rangle \hookrightarrow \langle p''',\epsilon  \rangle \in \Delta_0 \\
     \langle p,q_c \rangle \hookrightarrow \langle p',q_e \hspace{.1cm} q_r  \rangle \in \Delta_2 }
  { ( (p'',q_x), (p,q_c), q_x, (p''',q_r) ) \in \delta_r }
}
\end{mathpar}

Note that these rules generate an NWA return transition for each pair of WPDS pop
and push rules; there is no constraint between the two rules.  This is
because, with the exception of the ``revealed'' stack symbol $q_r$,
everything that the push rule talks about concerns the call predecessor
$(p,q_c)$ and entry node $(q', q_e)$; nothing that the pop rule talks about ---
$p''$, $q_x$, or $p'''$ --- has any relation to those. (A consequence is that the
number of NWA transitions may be quadratic in the number of
WPDS rules.)

In the resulting NWA, $Q_0$ and $Q_f$ are empty; client code must set the initial and
final states as appropriate (with \texttt{addInitialState(State)} and
\texttt{addFinalState(State)}. The keys that are generated for the names of the
NWA states are part of the interface of this function; they are generated by
\texttt{getKey(p, q)} where \texttt{p} and \texttt{q} are the keys of the
WPDS state and stack symbol being converted.

All weights on WPDS rules are ignored, and do not survive in any way in the
resulting NWA. The client information for all states in the resulting NWA are
set to \texttt{null}.

\begin{figure}[t]
  \centering
    \begin{itemize}
      \centering
      \item{ $\langle p,main \rangle \hookrightarrow \langle p,q_1 \rangle$}
      \item{ $\langle p,q_1 \rangle \hookrightarrow \langle p,c_1 \rangle$}
      \item{ $\langle p,c_1 \rangle \hookrightarrow \langle p,e \hspace{.1cm} r_1 \rangle$}
      \item{ $\langle p,e \rangle \hookrightarrow \langle p,q_2 \rangle$}
      \item{ $\langle p,q_2 \rangle \hookrightarrow \langle p,q_3 \rangle$}
      \item{ $\langle p,q_3 \rangle \hookrightarrow \langle p,x \rangle$}
      \item{ $\langle p,x \rangle \hookrightarrow \langle p,\epsilon \rangle$}
      \item{ $\langle p,r_1 \rangle \hookrightarrow \langle p,q_4 \rangle$}
      \item{ $\langle p,q_4 \rangle \hookrightarrow \langle p,q_5 \rangle$}
      \item{ $\langle p,q_5 \rangle \hookrightarrow \langle p,c_2 \rangle$}
      \item{ $\langle p,c_2 \rangle \hookrightarrow \langle p,e \hspace{.1cm} r_2 \rangle$}
      \item{ $\langle p,r_2 \rangle \hookrightarrow \langle p,q_6 \rangle$}
      \item{ $\langle p,q_6 \rangle \hookrightarrow \langle p,exit \rangle$}
    \end{itemize}
  \caption{An example WPDS.}
  \label{Fi:WpdsToNwa1}
\end{figure}

For example, the NWA created from the WPDS shown in
\figref{WpdsToNwa1} is shown in \figref{WpdsToNwa2}.

\begin{figure}[t]
  \centering
    \nwaimage[1]{Figures/pds-equivalent}
  \caption{The NWA resulting from converting the WPDS in \figref{WpdsToNwa1} into an NWA.}
  \label{Fi:WpdsToNwa2}
\end{figure}

\subsection{NWA to WPDS}
\label{Se:NWAtoPDS}

An NWA can also be converted into a WPDS. Weights for the rules of the
resulting WPDS are provided using a mechanism described below.  In this way
it is possible to use
the WPDS reachability queries that are a part of the main WALi library on
NWAs.  As mentioned in the introduction to \sectref{Conversions}, there are
four variations on the NWA-to-WPDS conversion: forward flow with call states
on the stack, backward flow with call states on the stack, forward flow with
return states on the stack, and backward flow with return states on the
stack. All four variations use \texttt{WeightGen} to determine weights for
WPDS rules.

\texttt{WeightGen} is an abstract class that client code must subclass to
calculate the weights of the rules in the generated WPDS.  It allows the
underlying NWA to be decoupled from the weight domain used in the WPDS.  See
\cite[\S4-\S5]{wali} for details about weight domains.

There is a trivial weight domain (containing $\overline{1}$ and
$\overline{0}$ only) implemented in the class \texttt{wali::Reach}, defined in
\texttt{wali/Reach.hpp}. A \texttt{WeightGen} subclass that returns elements
from this reachability domain is provided as the \texttt{ReachGen} class,
defined in \texttt{opennwa/WeightGen.hpp}. \texttt{ReachGen} returns
$\overline{1}$ for all transitions.

In addition, we provide shortest-path weights and two variants on a
\texttt{WeightGen} subclass for them. The shortest path weights are
implemented in the class \texttt{wali::ShortestPathSemiring} in
\texttt{wali/ShortestPathSemiring.hpp}; a semiring element of this class
consists of just a single integer. The two \texttt{WeightGen} implementations
we provide (both defined in \texttt{opennwa/WeightGen.hpp}) are
\texttt{ShortestPathGen} and \texttt{ShortestWordGen}. Both set the weight of
each WPDS rule to have a length 1 (note that this is different from the
semiring $\overline{1}$ element), except that \texttt{ShortestWordGen} uses
length 0 for rules that correspond to $\varepsilon$ transitions. Thus
\texttt{ShortestPathGen} results in a WPDS with weights that describe the
length of the shortest \emph{path} through the NWA, from the initial
configurations, while \texttt{ShortestWordGen} results in a WPDS with weights
that describe the length of the shortest \emph{word}.

The following operations are virtual methods of \texttt{WeightGen} intended to
be overridden:

\begin{functionlist}
  \functionDef{sem\_elem\_t}{WeightGen::getOne}{}{const = 0}  \nopagebreak
    Returns an instance of the $\bar{1}$ element of the weight domain.

  \functionDefFirstNoCloseParen{sem\_elem\_t}{getWeight}{%
      \parbox[t]{4in}{
        State source, ClientInfoRefPtr sourceInfo, \\
        Symbol symbol, Kind k, \\
        State target, ClientInfoRefPtr targetInfo ) const}}  \nopagebreak
    Computes and returns the weight for the rule corresponding to the
    transition from \texttt{source} to \texttt{target} (of
    kind \texttt{k})
    labeled with symbol \texttt{symbol}. By default, returns \texttt{getOne()}.

  \functionDefFirstNoCloseParen{sem\_elem\_t}{getWildWeight}{%
      \parbox[t]{4in}{
        State source, ClientInfoRefPtr sourceInfo, \\
        State target, ClientInfoRefPtr targetInfo ) const}}
    Computes and returns the weight for the WPDS rule corresponding to the
    transition from \texttt{source} to \texttt{target} labeled with the
    meta-symbol \wild. By default, returns \texttt{getOne()}.

  \functionDefFirst{sem\_elem\_t}{getExitWeight}{State src, ClientInfoRefPtr srcInfo}{const}
  This method computes the weight (in the desired semiring) for the return rule of
  the WPDS corresponding to the exit \texttt{src}.
  Note: the value is generally the same as \texttt{getOne()}, which is what the
  default implementation returns.

\end{functionlist}

\subsubsection{Forwards flow stacking calls}
\label{Se:wpds-forwards-flow-stacking-calls}

\noindent The conversion is performed by:

\begin{mathpar}

{\inferrule*%%[left=\textsc{States}]
  { }
  {p \in P}
}
\and
{\inferrule*
  { (q_x,q_c,\sigma,q_r) \in \delta_r }
  { p_{q_x} \in P }
}
\and
{\inferrule*
  { q \in Q }
  { q \in \Gamma }
}
\and
{\inferrule*%%[left=\textsc{Internal}]
  { (q,\sigma,q') \in \delta_i }
  { \langle p,q \rangle \stackrel{w_1}{\hookrightarrow} \langle p,q' \rangle \in \Delta_1 }
}
\and
{\inferrule*%%[left=\textsc{Call}]
  { (q_c,\sigma, q_e) \in \delta_c }
  {  \langle p,q_c \rangle \stackrel{w_2}{\hookrightarrow} \langle p, q_e \hspace{.1cm} q_c \rangle\in \Delta_2 }
}
\and
{\inferrule*%%[left=\textsc{Return}]
  { (q_x,q_c,\sigma,q_r) \in \delta_r }
  { \langle p,q_x \rangle \stackrel{w_0}{\hookrightarrow} \langle p_{q_x},\epsilon \rangle \in \Delta_0 \\
   \langle p_{q_x},q_c \rangle \stackrel{w_3}{\hookrightarrow} \langle p,q_r \rangle\in \Delta_1  }
}
\end{mathpar}
\begin{align*}
\text{where }
w_0 & = \begin{cases}
        \mathtt{wg.getWildWeight}(q_x,CI_{q_x},q_r,CI_{q_r}), & \text{if } \sigma = \text{\wild} \\
        \mathtt{wg.getWeight}(q_x,CI_{q_x},\sigma,\mathtt{EXIT\_TO\_RET},q_r,CI_{q_r}), & \text{otherwise}
      \end{cases}  \\
w_1 &= \begin{cases}
         \mathtt{wg.getWildWeight}(q,CI_q,q',CI_{q'}), & \text{if } \sigma = \text{\wild} \\
         \mathtt{wg.getWeight}(q,CI_q,\sigma,\mathtt{INTRA},q',CI_{q'}), & \text{otherwise}
      \end{cases} \\
w_2 &= \begin{cases}
         \mathtt{wg.getWildWeight}(q_c,CI_{q_c},q_e,CI_{q_e}), & \text{if } \sigma = \text{\wild} \\
         \mathtt{wg.getWeight}(q_c,CI_{q_c},\sigma,\mathtt{CALL\_TO\_ENTRY},q_e,CI_{q_e}), & \text{otherwise}
      \end{cases} \\
w_3 &= \mathtt{wg.getOne}()
\end{align*}

For example, the WPDS resulting from converting the NWA
shown in \figref{NwaToWpds1} into a WPDS is shown in
\figref{NwaToWpds4}. \\

\subsubsection{Backwards flow stacking calls}

The backwards-flow conversions are equivalent to calling
\texttt{wali::\-nwa::\-construct::\-reverse} and then the corresponding forwards
flow version. When reversing, call transitions become return transitions (and
vice versa), and so call sites become return sites (and vice versa).
Return sites in the original automaton behave as call sites in the reversed
automaton, and thus this version of the NWA-to-WPDS conversion stacks return
states. (In
other words, the \texttt{Calls} and \texttt{Returns} part of
\texttt{NwaTo\-Backwards\-WpdsCalls} and
\texttt{NwaTo\-Backwards\-WpdsReturns} refer to the behavior of the states in
the reversed automaton, not the role they play in the original.)

For example, the result of converting the NWA in
\figref{NwaToWpds1} into a backwards flow WPDS is shown in \figref{NwaToWpds5}.

Formally, the conversion is performed by:

\begin{mathpar}
{\inferrule*%%[left=\textsc{States}]
  { }
  {p \in P}
}
\and
{\inferrule*
  { (q_c,\sigma,q_e) \in \delta_c }
  { p_{q_e} \in P }
}
\and
{\inferrule*
  { q \in Q }
  { q \in \Gamma }
}
\and
{\inferrule*%%[left=\textsc{Internal}]
  { (q,\sigma,q') \in \delta_i }
  { \langle p,q' \rangle \stackrel{w_1}{\hookrightarrow} \langle p,q \rangle \in \Delta_1 }
}
\and
{\inferrule*%%[left=\textsc{Call}]
  { (q_c,\sigma, q_e) \in \delta_c \\ (q_x,q_c,\gamma,q_r) \in \delta_r }
  { \langle p,q_e \rangle \stackrel{w_0}{\hookrightarrow} \langle p_{q_e},\epsilon \rangle \in \Delta_0 \\
    \langle p_{q_e},q_r \rangle \stackrel{w_3}{\hookrightarrow} \langle p,q_c  \rangle \in \Delta_1 }
}
\and
{\inferrule*%%[left=\textsc{Return}]
  { (q_x,q_c,\sigma,q_r) \in \delta_r }
  {  \langle p,q_r \rangle \stackrel{w_2}{\hookrightarrow} \langle p,q_x \hspace{.1cm} q_r
  \rangle \in \Delta_2 }
}
\end{mathpar}
\begin{align*}
\text{where }
w_0 &= \begin{cases}
           \mathtt{wg.getWildWeight}(q_c,CI_{q_c},q_e,CI_{q_e}), & \text{if } \sigma = \text{\wild} \\
           \mathtt{wg.getWeight}(q_c,CI_{q_c},\sigma, \mathtt{CALL\_TO\_ENTRY},q_e,CI_{q_e}), & \text{otherwise}
      \end{cases} \\
w_1 &= \begin{cases}
           \mathtt{wg.getWildWeight}(q,CI_q,q',CI_{q'}), & \text{if } \sigma = \text{\wild} \\
           \mathtt{wg.getWeight}(q,CI_q,\sigma, \mathtt{INTRA},q',CI_{q'}), & \text{otherwise}
       \end{cases} \\
w_2 &= \begin{cases}
          \mathtt{wg.getWildWeight}(q_x,CI_{q_x},q_r,CI_{q_r}), & \text{if } \sigma = \text{\wild} \\
          \mathtt{wg.getWeight}(q_x,CI_{q_x},\sigma, \mathtt{EXIT\_TO\_RET},q_r,CI_{q_r}), & \text{otherwise}
      \end{cases} \\
w_3 &= \mathtt{wg.getOne}()
\end{align*}

\subsubsection{Forwards flow stacking returns}

As an example, converting the NWA in \figref{NwaToWpds1} into a WPDS results
in the WPDS shown in \figref{NwaToWpds2}. \\

The conversion is performed by:

\begin{mathpar}
{\inferrule*%%[left=\textsc{States}]
  { }
  {p \in P}
}
\and
{\inferrule*
  { (q_x,q_c,\sigma,q_r) \in \delta_r }
  { p_{q_x} \in P }
}
\and
{\inferrule*
  { q \in Q }
  { q \in \Gamma }
}
\and
{\inferrule*%%[left=\textsc{Internal}]
  { (q,\sigma,q') \in \delta_i }
  { \langle p,q  \rangle \stackrel{w_1}{\hookrightarrow} \langle p,q' \rangle \in \Delta_1 }
}
\and
{\inferrule*%%[left=\textsc{Call}]
  { (q_c,\sigma, q_e) \in \delta_c \\ (q_x,q_c,\gamma,q_r) \in \delta_r }
  { \langle p,q_c \rangle \stackrel{w_2}{\hookrightarrow}  \langle p, q_e \hspace{.1cm} q_r \rangle \in \Delta_2 }
}
\and
{\inferrule*%%[left=\textsc{Return}]
  { (q_x,q_c,\sigma,q_r) \in \delta_r }
  { \langle p,q_x \rangle \stackrel{w_0}{\hookrightarrow} \langle p_{q_x},\epsilon \rangle \in  \Delta_0 \\
    \langle  p_{q_x},q_r \rangle \stackrel{w_3}{\hookrightarrow} \langle p,q_r \rangle \in \Delta_1 }
}
\end{mathpar}
\begin{align*}
\text{where }
w_0 &= \mathtt{wg.getOne}() \\
w_1 &= \begin{cases}
           \mathtt{wg.getWildWeight}(q,CI_q,q',CI_{q'}), & \text{if } \sigma = \text{\wild} \\
           \mathtt{wg.getWeight}(q,CI_q,\sigma, \mathtt{INTRA},q',CI_{q'}), & \text{otherwise}
       \end{cases} \\
w_2 &= \begin{cases}
           \mathtt{wg.getWildWeight}(q_c,CI_{q_c},q_e,CI_{q_e}), & \text{if } \sigma = \text{\wild} \\
           \mathtt{wg.getWeight}(q_c,CI_{q_c},\sigma, \mathtt{CALL\_TO\_ENTRY},q_e,CI_{q_e}), & \text{otherwise}
      \end{cases} \\
w_3 &= \begin{cases}
          \mathtt{wg.getWildWeight}(q_x,CI_{q_x},q_r,CI_{q_r}), & \text{if } \sigma = \text{\wild} \\
          \mathtt{wg.getWeight}(q_x,CI_{q_x},\sigma, \mathtt{EXIT\_TO\_RET},q_r,CI_{q_r}), & \text{otherwise}
      \end{cases}
\end{align*}

\subsubsection{Backwards flow stacking returns}

As an example, converting the NWA in
\figref{NwaToWpds1} into a backwards flow WPDS results in
the WPDS shown in \figref{NwaToWpds3}. \\

\noindent The conversion is performed by:

\begin{mathpar}
{\inferrule*[left=\textsc{States}]
  { }
  {p \in P}
}
\and
{\inferrule*
  { (q_c,\sigma,q_e) \in \delta_c }
  { p_{q_e} \in P }
}
\and
{\inferrule*
  { q \in Q }
  { q \in \Gamma }
}
\and
{\inferrule*%%[left=\textsc{Internal}]
  { (q,\sigma,q') \in \delta_i }
  { \langle  p,q' \rangle \stackrel{w_1}{\hookrightarrow} \langle p,q \rangle \in \Delta_1 }
}
\and
{\inferrule*%%[left=\textsc{Call}]
  { (q_c,\sigma, q_e) \in \delta_c }
  { \langle  p,q_e \rangle \stackrel{w_0}{\hookrightarrow} \langle p_{q_e},\epsilon \rangle \in \Delta_0 \\
    \langle  p_{q_e},q_c \rangle \stackrel{w_3}{\hookrightarrow} \langle p,q_c \rangle \in \Delta_1  }
}
\and
{\inferrule*%%[left=\textsc{Return}]
  { (q_x,q_c,\sigma,q_r) \in \delta_r }
  { \langle p,q_r \rangle \stackrel{w_2}{\hookrightarrow} \langle p,q_x \hspace{.1cm} q_c  \rangle \in \Delta_2 }
}
\end{mathpar}
\begin{align*}
\text{where }
w_0 &= \mathtt{wg.getOne}() \\
w_1 &= \begin{cases}
           \mathtt{wg.getWildWeight}(q,CI_q,q',CI_{q'}), & \text{if } \sigma = \text{\wild} \\
           \mathtt{wg.getWeight}(q,CI_q,\sigma, \mathtt{INTRA},q',CI_{q'}), & \text{otherwise}
       \end{cases} \\
w_2 &= \begin{cases}
          \mathtt{wg.getWildWeight}(q_x,CI_{q_x},q_r,CI_{q_r}), & \text{if } \sigma = \text{\wild} \\
          \mathtt{wg.getWeight}(q_x,CI_{q_x},\sigma, \mathtt{EXIT\_TO\_RET},q_r,CI_{q_r}), & \text{otherwise}
      \end{cases} \\
w_3 &= \begin{cases}
           \mathtt{wg.getWildWeight}(q_c,CI_{q_c},q_e,CI_{q_e}), & \text{if } \sigma = \text{\wild} \\
           \mathtt{wg.getWeight}(q_c,CI_{q_c},\sigma, \mathtt{CALL\_TO\_ENTRY},q_e,CI_{q_e}), & \text{otherwise}
      \end{cases}
\end{align*}

\begin{figure}[p]
  \centering
  \begin{minipage}{\textwidth}
    \nwaimage[1]{Figures/pre-pds-nwa}
    \caption{An example NWA.}
    \label{Fi:NwaToWpds1}
  \end{minipage}
  \begin{minipage}{0.42\textwidth}
    \begin{itemize}
      \centering
      \item{ $\langle p,main \rangle \hookrightarrow \langle p,q_1 \rangle$}
      \item{ $\langle p,q_1 \rangle \hookrightarrow \langle p,c_1 \rangle$}
      \item{ $\langle p,e \rangle \hookrightarrow \langle p,q_2 \rangle$}
      \item{ $\langle p,q_2 \rangle \hookrightarrow \langle p,q_3 \rangle$}
      \item{ $\langle p,q_3 \rangle \hookrightarrow \langle p,x \rangle$}
      \item{ $\langle p,r_1 \rangle \hookrightarrow \langle p,q_4 \rangle$}
      \item{ $\langle p,q_4 \rangle \hookrightarrow \langle p,q_5 \rangle$}
      \item{ $\langle p,q_5 \rangle \hookrightarrow \langle p,c_2 \rangle$}
      \item{ $\langle p,r_2 \rangle \hookrightarrow \langle p,q_6 \rangle$}
      \item{ $\langle p,q_6 \rangle \hookrightarrow \langle p,exit \rangle$}
      \item{ $\langle p,c_1 \rangle \hookrightarrow \langle p,e \hspace{.1cm} c_1 \rangle$}
      \item{ $\langle p,c_2 \rangle \hookrightarrow \langle p,e \hspace{.1cm} c_2 \rangle$}
      \item{ $\langle p,x \rangle \hookrightarrow \langle p_x, \epsilon \rangle$}
      \item{ $\langle p_x,c_1 \rangle \hookrightarrow \langle p,r_1 \rangle$}
      \item{ $\langle p,x \rangle \hookrightarrow \langle p_x, \epsilon \rangle$}
      \item{ $\langle p_x,c_2 \rangle \hookrightarrow \langle p,r_2 \rangle$}
    \end{itemize}
    \caption{The WPDS resulting from calling \texttt{NwaToWpdsCalls} on \figref{NwaToWpds1}}
    \label{Fi:NwaToWpds4}
  \end{minipage}
  \hspace{0.1\textwidth}
  \begin{minipage}{0.42\textwidth}
    \centering
    \begin{itemize}
      \centering
      \item{ $\langle p,q_1 \rangle \hookrightarrow \langle p,main \rangle$}
      \item{ $\langle p,c_1 \rangle \hookrightarrow \langle p,q_1 \rangle$}
      \item{ $\langle p,q_2 \rangle \hookrightarrow \langle p,e \rangle$}
      \item{ $\langle p,q_3 \rangle \hookrightarrow \langle p,q_2 \rangle$}
      \item{ $\langle p,x \rangle \hookrightarrow \langle p,q_3 \rangle$}
      \item{ $\langle p,q_4 \rangle \hookrightarrow \langle p,r_1 \rangle$}
      \item{ $\langle p,q_5 \rangle \hookrightarrow \langle p,q_4 \rangle$}
      \item{ $\langle p,c_2 \rangle \hookrightarrow \langle p,q_5 \rangle$}
      \item{ $\langle p,q_6 \rangle \hookrightarrow \langle p,r_2 \rangle$}
      \item{ $\langle p,exit \rangle \hookrightarrow \langle p,q_6 \rangle$}
      \item{ $\langle p,r_1 \rangle \hookrightarrow \langle p,x \hspace{.1cm} r_1 \rangle$}
      \item{ $\langle p,r_2 \rangle \hookrightarrow \langle p,x \hspace{.1cm} r_2 \rangle$}
      \item{ $\langle p,e \rangle \hookrightarrow \langle p_e, \epsilon \rangle$}
      \item{ $\langle p_e,r_1 \rangle \hookrightarrow \langle p,c_1 \rangle$}
      \item{ $\langle p,e \rangle \hookrightarrow \langle p_e, \epsilon \rangle$}
      \item{ $\langle p_e,r_2 \rangle \hookrightarrow \langle p,c_2 \rangle$}
    \end{itemize}
    \caption{The result of calling \texttt{NwaToBackwardsWpdsCalls} on \figref{NwaToWpds1}}
    \label{Fi:NwaToWpds5}
  \end{minipage}
  \begin{minipage}{0.42\textwidth}
    \centering
    \begin{itemize}
      \centering
      \item{ $\langle p,main \rangle \hookrightarrow \langle p,q_1 \rangle$}
      \item{ $\langle p,q_1 \rangle \hookrightarrow \langle p,c_1 \rangle$}
      \item{ $\langle p,e \rangle \hookrightarrow \langle p,q_2 \rangle$}
      \item{ $\langle p,q_2 \rangle \hookrightarrow \langle p,q_3 \rangle$}
      \item{ $\langle p,q_3 \rangle \hookrightarrow \langle p,x \rangle$}
      \item{ $\langle p,r_1 \rangle \hookrightarrow \langle p,q_4 \rangle$}
      \item{ $\langle p,q_4 \rangle \hookrightarrow \langle p,q_5 \rangle$}
      \item{ $\langle p,q_5 \rangle \hookrightarrow \langle p,c_2 \rangle$}
      \item{ $\langle p,r_2 \rangle \hookrightarrow \langle p,q_6 \rangle$}
      \item{ $\langle p,q_6 \rangle \hookrightarrow \langle p,exit \rangle$}
      \item{ $\langle p,c_1 \rangle \hookrightarrow \langle p,e \hspace{.1cm} r_1 \rangle$}
      \item{ $\langle p,c_2 \rangle \hookrightarrow \langle p,e \hspace{.1cm} r_2 \rangle$}
      \item{ $\langle p,x \rangle \hookrightarrow \langle p_x, \epsilon \rangle$}
      \item{ $\langle p_x,r_1 \rangle \hookrightarrow \langle p,r_1 \rangle$}
      \item{ $\langle p,x \rangle \hookrightarrow \langle p_x, \epsilon \rangle$}
      \item{ $\langle p_x,r_2 \rangle \hookrightarrow \langle p,r_2 \rangle$}
    \end{itemize}
    \caption{The WPDS resulting from calling \texttt{NwaToWpdsReturns} on \figref{NwaToWpds1}}
    \label{Fi:NwaToWpds2}
  \end{minipage}
  \hspace{0.1\textwidth}
  \begin{minipage}{0.42\textwidth}
    \centering
    \begin{itemize}
      \centering
      \item{ $\langle p,q_1 \rangle \hookrightarrow \langle p,main \rangle$}
      \item{ $\langle p,c_1 \rangle \hookrightarrow \langle p,q_1 \rangle$}
      \item{ $\langle p,q_2 \rangle \hookrightarrow \langle p,e \rangle$}
      \item{ $\langle p,q_3 \rangle \hookrightarrow \langle p,q_2 \rangle$}
      \item{ $\langle p,x \rangle \hookrightarrow \langle p,q_3 \rangle$}
      \item{ $\langle p,q_4 \rangle \hookrightarrow \langle p,r_1 \rangle$}
      \item{ $\langle p,q_5 \rangle \hookrightarrow \langle p,q_4 \rangle$}
      \item{ $\langle p,c_2 \rangle \hookrightarrow \langle p,q_5 \rangle$}
      \item{ $\langle p,q_6 \rangle \hookrightarrow \langle p,r_2 \rangle$}
      \item{ $\langle p,exit \rangle \hookrightarrow \langle p,q_6 \rangle$}
      \item{ $\langle p,r_1 \rangle \hookrightarrow \langle p,x \hspace{.1cm} c_1 \rangle$}
      \item{ $\langle p,r_2 \rangle \hookrightarrow \langle p,x \hspace{.1cm} c_2 \rangle$}
      \item{ $\langle p,e \rangle \hookrightarrow \langle p_e, \epsilon \rangle$}
      \item{ $\langle p_e,c_1 \rangle \hookrightarrow \langle p,c_1 \rangle$}
      \item{ $\langle p,e \rangle \hookrightarrow \langle p_e, \epsilon \rangle$}
      \item{ $\langle p_e,c_2 \rangle \hookrightarrow \langle p,c_2 \rangle$}
    \end{itemize}
    \caption{The result of calling \texttt{Nwa\-To\-Backwards\-Wpds\-Returns} on \figref{NwaToWpds1}}
    \label{Fi:NwaToWpds3}
  \end{minipage}
\end{figure}


% Machine Learning
A machine is said to be learning from past Experiences(data feed in) with respect to some class of Tasks, if it's Performance in a given Task improves with the Experience.

According to a famous person, Machine Learning is a system that can learn from example through self-improvement and without being explicitly coded by programmer. The breakthrough comes with the idea that a machine can singularly learn from the data (\textit{i.e.} media database of real life objects, numbers dataset from algorithms, face images, job dtabase) to produce accurate results.

Machine learning combines data with statistical tools to predict an output. This output is then used by corporate to makes actionable insights. Machine learning is closely related to data mining and Bayesian predictive modeling. The machine receives data as input, use an algorithm to formulate answers.

A typical machine learning tasks are to provide a recommendation. For those who have a Netflix account, all recommendations of movies or series are based on the user's historical data. Tech companies are using unsupervised learning to improve the user experience with personalizing recommendation.

\subsection{Machine Learning vs. Traditional Programming}
Traditional programming differs significantly from machine learning. In traditional programming, a programmer code all the rules in consultation with an expert in the industry for which software is being developed. Each rule is based on a logical foundation; the machine will execute an output following the logical statement. When the system grows complex, more rules need to be written. It can quickly become unsustainable to maintain.

Machine learning is supposed to overcome this issue. The machine learns how the input and output data are correlated and it writes a rule. The programmers do not need to write new rules each time there is new data. The algorithms adapt in response to new data and experiences to improve efficacy over time.

\subsection{How does Machine learning work}
Machine learning is the virtual brain where all the learning takes place. The way the machine learns is similar to the human being. Humans learn from experience. The more we know, the more easily we can predict. By analogy, when we face an unknown situation, the likelihood of success is lower than the known situation. Machines are trained the same. To make an accurate prediction, the machine sees an example. When we give the machine a similar example, it can figure out the outcome. However, like a human, if its feed a previously unseen example, the machine has difficulties to predict.

The core objective of machine learning is the learning and inference. First of all, the machine learns through the discovery of patterns. This discovery is made thanks to the data. One crucial part of the data scientist is to choose carefully which data to provide to the machine. The list of attributes used to solve a problem is called a feature vector. You can think of a feature vector as a subset of data that is used to tackle a problem.

The machine uses some fancy algorithms to simplify the reality and transform this discovery into a model. Therefore, the learning stage is used to describe the data and summarize it into a model.

For instance, the machine is trying to understand the relationship between the wage of an individual and the likelihood to go to a fancy restaurant. It turns out the machine finds a positive relationship between wage and going to a high-end restaurant: This is the model

\subsubsection{Inferring}
When the model is built, it is possible to test how powerful it is on never-seen-before data. The new data are transformed into a features vector, go through the model and give a prediction. This is all the beautiful part of machine learning. There is no need to update the rules or train again the model. You can use the model previously trained to make inference on new data.

The life of Machine Learning programs is straightforward and can be summarized in the following points:
\begin{enumerate}
\item Define a question
\item Collect data
\item Visualize data
\item Train algorithm
\item Test the Algorithm
\item Collect feedback
\item Refine the algorithm
\item Loop 4-7 until the results are satisfying
\item Use the model to make a prediction
\end{enumerate}

There are two main types of Learning,
\subsubsection{Supervised learning}
An algorithm uses training data and feedback from humans to learn the relationship of given inputs to a given output. For instance, a practitioner can use marketing expense and weather forecast as input data to predict the sales of cans.

You can use supervised learning when the output data is known. The algorithm will predict new data.

There are two categories of supervised learning:
\paragraph{Classification}
Imagine you want to predict the gender of a customer for a commercial. You will start gathering data on the height, weight, job, salary, purchasing basket, etc. from your customer database. You know the gender of each of your customer, it can only be male or female. The objective of the classifier will be to assign a probability of being a male or a female (\textit{i.e.}, the label) based on the information (\textit{i.e.}, features you have collected). When the model learned how to recognize male or female, you can use new data to make a prediction. For instance, you just got new information from an unknown customer, and you want to know if it is a male or female. If the classifier predicts male = 70\%, it means the algorithm is sure at 70\% that this customer is a male, and 30\% it is a female.

The label can be of two or more classes. The above example has only two classes, but if a classifier needs to predict object, it has dozens of classes (\textit{e.g.} glass, table, shoes, etc. each object represents a class).

\paragraph{Regression}
When the output is a continuous value, the task is a regression. For instance, a financial analyst may need to forecast the value of a stock based on a range of feature like equity, previous stock performances, macroeconomics index. The system will be trained to estimate the price of the stocks with the lowest possible error.

\subsubsection{Unsupervised learning}
In unsupervised learning, an algorithm explores input data without being given an explicit output variable (\textit{e.g.} explores customer demographic data to identify patterns)

You can use it when you do not know how to classify the data, and you want the algorithm to find patterns and classify the data for you

Challenges and Limitations of Machine learning
The primary challenge of machine learning is the lack of data or the diversity in the dataset. A machine cannot learn if there is no data available. Besides, a dataset with a lack of diversity gives the machine a hard time. A machine needs to have heterogeneity to learn meaningful insight. It is rare that an algorithm can extract information when there are no or few variations. It is recommended to have at least 20 observations per group to help the machine learn. This constraint leads to poor evaluation and prediction.

\subsection{Application}
There are plenty of application fields where ML is being used for better performance,
\subsubsection{Augmentation}
Machine learning, which assists humans with their day-to-day tasks, personally or commercially without having complete control of the output. Such machine learning is used in different ways such as Virtual Assistant, Data analysis, software solutions. The primary user is to reduce errors due to human bias.
\subsubsection{Automation}
Machine learning, which works entirely autonomously in any field without the need for any human intervention. For example, robots performing the essential process steps in manufacturing plants.
\subsubsection{Finance Industry}
Machine learning is growing in popularity in the finance industry. Banks are mainly using ML to find patterns inside the data but also to prevent fraud.
\subsubsection{Government organization}
The government makes use of ML to manage public safety and utilities. Take the example of China with the massive face recognition. The government uses Artificial intelligence to prevent jaywalker.
\subsubsection{Healthcare industry}
Healthcare was one of the first industry to use machine learning with image detection.
\subsubsection{Marketing}
Broad use of AI is done in marketing thanks to abundant access to data. Before the age of mass data, researchers develop advanced mathematical tools like Bayesian analysis to estimate the value of a customer. With the boom of data, marketing department relies on AI to optimize the customer relationship and marketing campaign.
\subsubsection{Supply Chain}
Machine learning gives terrific results for visual pattern recognition, opening up many potential applications in physical inspection and maintenance across the entire supply chain network.

Unsupervised learning can quickly search for comparable patterns in the diverse dataset. In turn, the machine can perform quality inspection throughout the logistics hub, shipment with damage and wear.

For instance, IBM's Watson platform can determine shipping container damage. Watson combines visual and systems-based data to track, report and make recommendations in real-time.

In past year stock manager relies extensively on the primary method to evaluate and forecast the inventory. When combining big data and machine learning, better forecasting techniques have been implemented (an improvement of 20 to 30 \% over traditional forecasting tools). In term of sales, it means an increase of 2 to 3 \% due to the potential reduction in inventory costs.

\paragraph{Google Car}
For example, everybody knows the Google car \textbf{Waymo}. The car is full of lasers on the roof which are telling it where it is regarding the surrounding area. It has radar in the front, which is informing the car of the speed and motion of all the cars around it. It uses all of that data to figure out not only how to drive the car but also to figure out and predict what potential drivers around the car are going to do. What's impressive is that the car is processing almost a gigabyte a second of data.

For our case we use logistic regression (discussed in Appendix app:4) and the algorithm is discussed in Proposal chapter \ref{ch:3}.


\documentclass[a4paper]{article}

\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{hyperref}
\usepackage{graphicx}
\usepackage{geometry}

\geometry{
    letterpaper,
    left=   1.5in,
    right=  1.5in,
    top=    1.3in,
    bottom= 1.4in
}

\newcommand{\partd}[2]{\frac{\partial #1}{\partial #2}}
\newcommand{\dih}{\mathrel{\rm dih}}

\parindent=0mm
\parskip=5pt

\title{A Tool for Formal Verification of Nonlinear Inequalities}

\author{Alexey Solovyev}

% Document
\begin{document}
% Title
\maketitle

% Content
\tableofcontents

\pagebreak
% References
\begin{thebibliography}{9}
\bibitem{HOL} HOL Light home page\\
  \url{http://www.cl.cam.ac.uk/~jrh13/hol-light}

\bibitem{HOL-repo} HOL Light repository\\
  \url{https://github.com/jrh13/hol-light}

\bibitem{HOL-tutorial} HOL Light tutorial\\
	\url{http://www.cl.cam.ac.uk/~jrh13/hol-light/tutorial_220.pdf}

\bibitem{flyspeck} The Flyspeck project\\
	\url{https://github.com/flyspeck/flyspeck}

\bibitem{bernstein}C\'esar Mu\~noz and Anthony Narkawicz, {\it Formalization of a Representation of Bernstein Polynomials and Applications to Global Optimization}, Journal of Automated Reasoning, DOI: 10.1007/s10817-012-9256-3\\
	\url{http://shemesh.larc.nasa.gov/people/cam/Bernstein/}
\end{thebibliography}

% Introduction
\section{Introduction}
This document describes a tool for verification of nonlinear inequalities in HOL Light proof assistant~\cite{HOL, HOL-tutorial}. This tool was developed as a part of the Flyspeck project (a formal proof of the Kepler conjecture)~\cite{flyspeck}. The tool is capable to verify multivariate nonlinear strict inequalities on rectangular domains. More specifically, the tool can handle inequalities in the form
\[\forall {\bf x} \in D \implies f({\bf x}) < g({\bf x}),\]
where $D = \{(x_1, \ldots, x_n)\ |\ a_i \le x_i \le b_i\}$ and $f$, $g$ are functions which may include all usual arithmetic operations, square roots, arccosines, and arctangents. The maximal number of variables is 8. Future releases of the tool will include all elementary functions and will have no restriction on the number of variables. Moreover, it will be possible to verify inequalities on non-rectangular domains.

Internally, the tool uses interval arithmetic with Taylor approximations (with second-order error terms).

The document is organized as follows. The next section describes the installation process. Then a quick introduction of tool functions is presented. After that, a more detailed description of tool functions is given and special options are described. The last two sections describe several examples and test cases.

% Installation
\section{Installation}
First of all, if you don't have OCaml and HOL Light installed, then you need to install them. The verification tool was tested with Ocaml 3.09.3 and Ocaml 3.12.1 and with one of the latest versions of HOL Light (r149 in the HOL Light repository).  HOL Light installation instructions can be found in John Harrison's HOL Light tutorial~\cite{HOL-tutorial}.

Alternatively, one can download and run the following script written by Alex Krauss: \url{https://bitbucket.org/akrauss/hol-light-workbench}. This script will download and install the latest version of HOL Light and other necessary programs.

The installation of the tool for verification of nonlinear inequalities is very simple. Download the distribution from

\vspace{-5pt}
\url{http://code.google.com/p/flyspeck/downloads/list}

\vspace{-5pt}
or get the latest version from the Flyspeck repository with the shell command

\vspace{-5pt}
\verb|svn co http://flyspeck.googlecode.com/svn/trunk/formal_ineqs|

The tool can be placed in any directory on your computer. It is important to inform HOL Light about tool's location. It can be done with the following OCaml command:

\verb|load_path := "path to the tool directory" :: !load_path;;|

After the path is set, the tool can be loaded with the command

\verb|needs "verifier/m_verifier_main.hl";;|

The tool loads the standard HOL Light library \verb|Multivariate/realanalysis.ml|. The loading process of this library could take pretty long time, so it is recommended to use a checkpointed version of HOL Light with preloaded multivariate analysis libraries.

Before loading the tool, it is also possible to change some global options. These options are described in section \ref{global}.

% Examples
\section{Quick Start}

The polynomial inequality
\begin{multline*}
-\frac{1}{\sqrt{3}} \le x \le \sqrt{2},\ -\sqrt{\pi} \le y \le 1
\implies x^2 y - x y^4 + y^6 + x^4 - 7 > -7.17995
\end{multline*}
can be verified with the following script

\begin{verbatim}
(* make sure that load_path contains the path to formal_ineqs *)
needs "verifier/m_verifier_main.hl";;
open M_verifier_main;;

let ineq =
  `-- &1 / sqrt(&3) <= x /\ x <= sqrt(&2) /\
   -- sqrt(pi) <= y /\ y <= &1
   ==> x pow 2 * y - x * y pow 4 + y pow 6 - &7 + x pow 4 > -- #7.17995`;;

let th, stats = verify_ineq default_params 5 ineq;;
\end{verbatim}

The first parameter of the verification function \verb|verify_ineq| contains verification options. We use default values given by the constant \verb|default_params|. Available options are described in section \ref{verification}.

The second parameter specifies the precision of formal floating point operations. This parameter determines the maximal number of significant digits of any result returned by a formal floating point operation. Here, digits are not decimal. Internally all natural numbers are represented using a fixed base (see section \ref{global} for more details). This base is relatively large (the default value is 100) to speed up arithmetic operations. Actual precision of formal floating point operations depends on the precision parameter and on the base of the internal representation of natural numbers. If the base value is 100 and the precision parameter is 5 as in the example above, then the precision of formal floating point operations is 10 decimal digits: $100^5 = 10^{10}$. Note that the verification of the example will fail if the precision parameter is 4 or less. On the other hand, if the precision parameter is 10, the verification will succeed but it will take a little more time.

The third parameter is the inequality itself given as a HOL Light term. The format of this term is simple: it is an implication with bounds of variables in the antecedent and an inequality in the consequent. The bounds of all variables should be in the form $\text{\it a constant expression} <= x$ or $x <= \text{\it a constant expression}$. For each variable, upper and lower bounds must be given. The inequality must be a strict inequality ($<$ or $>$). The inequality may include \verb|sqrt|, \verb|atn|, and \verb|acs| functions. The constant \verb|pi| ($\pi$) is also allowed.

The verification function returns a HOL Light theorem and a record with some verification information which includes verification time.

% Verification Functions
\section{Verification Functions}\label{verification}
The main verification function \verb|verify_ineq| is contained in \verb|M_verifier_main| module defined in \verb|verifier/m_verifier_main.hl|. The function has 3 arguments and its type is
\begin{verbatim}
verify_ineq : verification_parameters -> int -> term -> thm * verification_stats
\end{verbatim}

The first parameter contains verification options defined in the following record
\begin{verbatim}
type verification_parameters =
{
  (* If true, then monotonicity properties can be used *)
  (* to reduce the dimension of a problem *)
  allow_derivatives : bool;
  (* If true, then convexity can be used *)
  (* to reduce the dimension of a problem *)
  convex_flag : bool;
  (* If true, then verification on internal subdomains can be skipped *)
  (* for a monotone function *)
  mono_pass_flag : bool;
  (* If true, then raw interval arithmetic can be used *)
  (* (without Taylor approximations) *)
  raw_intervals_flag : bool;
  (* If true, then an informal procedure is used to determine *)
  (* the optimal precision for the formal verification *)
  adaptive_precision : bool;
  (* This parameter might be used in cases when the certificate search *)
  (* procedure returns a wrong result due to rounding errors *)
  (* (this parameter will be eliminated when the search procedure is corrected) *)
  eps : float;
};;
\end{verbatim}
A detailed description of these parameter is omitted in this document. In most cases, it is enough to use the constant \verb|default_params| which turns all verification flags on and sets \verb|eps = 0|. In rare cases, it is necessary to adjust \verb|eps| to get a result. This can be done with the command
\begin{verbatim}
verify_ineq {default_params with eps = 1e-10} 5 ineq_tm;;
\end{verbatim}

The second parameter of the verification function specifies the precision of formal floating point operations. This parameter determines the maximal number of significant digits of any result returned by a formal floating point operation. Here, digits are not decimal. Internally all natural numbers are represented using a fixed base (see section \ref{global} for more details). This base is relatively large (the default value is 100) to speed up arithmetic operations. Actual precision of formal floating point operations depends on the precision parameter and on the base of the internal representation of natural numbers. In many cases, if the verification function fails, it is enough to increase the precision parameter to get a result.

The third parameter of the verification function is a HOL Light term which specifies an inequality itself. The format of this term is the following:
\begin{verbatim}
bounds of variables ==> an inequality
\end{verbatim}
The bounds of all variables should be in the form $\text{\it a constant expression} <= x$ or $x <= \text{\it a constant expression}$. For each variable, upper and lower bounds must be provided. The order in which the bounds are given is irrelevant. Bounds of variables may be connected with \verb|/\| or with \verb|==>|. The inequality must be a strict inequality ($<$ or $>$). The inequality may include \verb|sqrt|, \verb|atn|, and \verb|acs| functions. The constant \verb|pi| ($\pi$) is also allowed.

The verification function returns a theorem and some verification information defined in the record
\begin{verbatim}
type verification_stats =
{
  total_time : float;
  formal_verification_time : float;
  certificate : Verifier.certificate_stats;
};;
\end{verbatim}
The field \verb|total_time| contains total verification time. The field \verb|formal_verification_time| contains time taken by the formal verification procedure only (this time doesn't include time for constructing a solution certificate and for other preparations). The last field \verb|certificate| contains information about a solution certificate.

The conclusion of the returned theorem is not exactly the same as the third parameter of the verification function: the order of bounds of variables may be altered and variables which are not used in the inequality are eliminated. For example, commands
\begin{verbatim}
let th1, _ = verify_ineq default_params 3
  `&1 <= y /\ y <= &2 /\ &1 <= x /\ x <= &3 ==> x + y < &6`;;
let th2, _ = verify_ineq default_params 3
  `&1 <= y /\ y <= &2 /\ &1 <= x /\ x <= &3 ==> y < &3`;;
\end{verbatim}
return
\begin{verbatim}
th1 = |- (&1 <= x /\ x <= &3) /\ &1 <= y /\ y <= &2 ==> x + y < &6
th2 = |- &1 <= y /\ y <= &2 ==> y < &3
\end{verbatim}

% Options
\section{Global Options}\label{global}
The options which affect the arithmetic operations with natural and floating point numbers must be set before the verification tool is loaded. After the verification tool is loaded, arithmetic options may not be changed. To set arithmetic options, load the file \verb|arith_options.hl| located in the root directory of the tool. The available options are listed below.

\begin{enumerate}
% base
\item[\bf base] Determines the base for representing natural numbers. Default HOL Light
representation of natural numbers is binary (i.e., its base is 2). A higher base increases speed of arithmetic operations but it also requires more memory to remember additional theorems. The default value of the base is \verb|100|. To set a new base, use the command

\verb|Arith_options.base := 200;;|

% min_exp
\item[\bf min\_exp] Determines the minimal exponent in the representation of floating point numbers. Each floating point number is represented as a triple $(s, n, e)$ where $s$ is a boolean value which determines the sign of the number, $n$ and $e$ are natural numbers which represent the mantissa and the exponent. The value corresponding to $(s, n, e)$ is given by

\[f = (-1)^{\text{if $s$ then $1$ else $0$}} \times n \times b^{e - min\_exp}\]
where $b$ is the base of the representation of natural numbers.

% cached
\item[\bf cached] If this value is true, then results of all natural number operations are cached. The default value is \verb|true|.

% float_cached
\item[\bf float\_cached] If this value is true, then results of all floating point operations are cached. The default value is \verb|true|.

% init_cache_size
\item[\bf init\_cache\_size] Determines the initial size of the cache for results of arithmetic operations. The default value is \verb|10000|.

% max_cache_size
\item[\bf max\_cache\_size] Determines the maximal size of the cache for results of arithmetic operations. The default value is \verb|20000|. Note: each cached operation has its own cache.

\end{enumerate}

The file \verb|verifier_options.hl| contains the option \verb|info_print_level| which controls the amount of information printed by a verification process. This option can be changed at any time:

\verb|Verifier_options.info_print_level := 0;;|

Possible values are: 0~(no information is printed); 1~(all essential information is printed); 2~(all information is printed). The default value is 1.

The next example shows how to change default options:
\begin{verbatim}
(* The arithmetic options must be set before loading the verification tool *)
needs "arith_options.hl";;

(* Increase the arithmetic base *)
Arith_options.base := 200;;

(* Increase the cache size *)
Arith_options.max_cache_size = 40000;;

(* Load the verification tool *)
needs "verifier/m_verifier_main.hl";;

(* The verification option can be changed at any time *)
Verifier_options.info_print_level := 2;;

open M_verifier_main;;
\end{verbatim}

% Additional Examples
\section{Additional Examples}
The verification tool distribution contains several example files. The file \verb|examples_poly.hl| contains polynomial inequalities from the paper \cite{bernstein}. The command

\verb|needs "examples_poly.hl";;|

will load this file and run all polynomial inequality tests. To run all tests again, type \verb|run_tests();;|

To run a specific test, type \verb|run_{test_name}();;| where \verb|{test_name}| is one of the following: \verb|schwefel|, \verb|rd|, \verb|caprasse|, \verb|lv|, \verb|butcher|, \verb|magnetism|, \verb|heart|.

Here is the list of all examples.
\begin{itemize}
% schwefel
\item[\bf schwefel]
\begin{eqnarray*}
&-5.8806 \times 10^{-10} < (x_1 - x_2^2)^2 + (x_2 - 1)^2 + (x_1 - x_3^2)^2 + (x_3 - 1)^2\\
&(x_1, x_2, x_3) \in [(-10,-10,-10),(10,10,10)]
\end{eqnarray*}

% rd
\item[\bf rd]
\begin{eqnarray*}
&-36.7126907 < -x_1 + 2 x_2 - x_3 - 0.835634534\, x_2 (1 + x_2)\\
&(x_1, x_2, x_3) \in [(-5,-5,-5),(5,5,5)]
\end{eqnarray*}

% caprasse
\item[\bf caprasse]
\begin{eqnarray*}
&-3.1801 < -x_1 x_3^3 + 4 x_2 x_3^2 x_4 + 4 x_1 x_3 x_4^2 + 2 x_2 x_4^3 + 4 x_1 x_3 + 4 x_3^2 - 10 x_2 x_4 - 10 x_4^2 + 2\\
&(x_1, x_2, x_3, x_4) \in [(-0.5,-0.5,-0.5,-0.5),(0.5,0.5,0.5,0.5)]
\end{eqnarray*}

% lv
\item[\bf lv]
\begin{eqnarray*}
&-20.801 < x_1 x_2^2 + x_1 x_3^2 + x_1 x_4^2 - 1.1 x_1 + 1\\
&(x_1, x_2, x_3, x_4) \in [(-2,-2,-2,-2), (2,2,2,2)]
\end{eqnarray*}

% butcher
\item[\bf butcher]
\begin{eqnarray*}
&-1.44 < x_6 x_2^2 + x_5 x_3^2 - x_1 x_4^2 + x_4^2 - \frac{1}{3} x_1 + \frac{4}{3} x_4\\
&(x_1, x_2, x_3, x_4, x_5, x_6) \in [(-1,-0.1, -0.1, -1, -0.1, -0.1), (0,0.9,0.5,-0.1,-0.05,-0.03)]
\end{eqnarray*}

% magnetsim
\item[\bf magnetism]
\begin{eqnarray*}
&-0.25001 < x_1^2 + 2 x_2^2 + 2 x_3^2 + 2 x_4^2 + 2 x_5^2 + 2 x_6^2 + 2 x_7^2 - x_1\\
&(x_1,x_2,x_3,x_4,x_5,x_6,x_7) \in [(-1,-1,-1,-1,-1,-1,-1), (1,1,1,1,1,1,1)]
\end{eqnarray*}

% heart
\item[\bf heart]
\begin{equation*}
\begin{split}
&-1.7435 < -x_1 x_6^3 + 3 x_1 x_6 x_7^2 - x_3 x_7^3 + 3 x_3 x_7 x_6^2 - x_2 x_5^3 + 3 x_2 x_5 x_8^2 - x_4 x_8^3 + 3 x_4 x_8 x_5^2 - 0.9563453\\
&(x_1,x_2,x_3,x_4,x_5,x_6,x_7,x_8) \in [(-0.1, 0.4, -0.7, -0.7, 0.1, -0.1, -0.3, -1.1),\\ &\phantom{(x_1,x_2,x_3,x_4,x_5,x_6,x_7,x_8) \in [ }(0.4, 1, -0.4, 0.4, 0.2, 0.2, 1.1, -0.3)]
\end{split}
\end{equation*}
\end{itemize}

The file \verb|examples_flyspeck.hl| contains some inequalities from the Flyspeck project~\cite{flyspeck}. The command

\verb|needs "examples_flyspeck.hl";;|

will load this file and run some easy inequality tests. To rerun these tests, use the command \verb|test_easy();;|. To run more difficult tests, type \verb|test_medium();;| or \verb|test_hard();;|.
(Warning: medium tests require about 30 minutes, hard tests require more than 5 hours.)

Some Flyspeck inequalities are listed below.
\begin{eqnarray*}
\Delta(x_1,\ldots,x_6) &= &x_1 x_4(-x_1 + x_2 + x_3 - x_4 + x_5 + x_6)\\
&& + x_2 x_5(x_1 - x_2 + x_3 + x_4 - x_5 + x_6)\\
&& + x_3 x_6(x_1 + x_2 - x_3 + x_4 + x_5 - x_6)\\
&& - x_2 x_3 x_4 - x_1 x_3 x_5 - x_1 x_2 x_6 - x_4 x_5 x_6,\\[6pt]
\Delta_4 &=& \partd{\Delta}{x_4},\\[6pt]
\dih_x(x_1,\ldots,x_6) &=& \frac{\pi}{2} - \arctan\left(\frac{-\Delta_4(x_1,\ldots,x_6)}{\sqrt{4 x_1 \Delta(x_1,\ldots,x_6)}}\right),\\[6pt]
\dih_y(y_1,\ldots,y_6) &=& \dih_x(y_1^2, \ldots, y_6^2).
\end{eqnarray*}

\begin{itemize}
% 1
\item[\bf 4717061266]
\begin{eqnarray*}
\Delta(x_1, x_2, x_3, x_4, x_5, x_6) > 0,\quad 4 \le x_i \le 6.3504
\end{eqnarray*}

% 2
\item[\bf 7067938795]
\begin{eqnarray*}
&\dih_x (x_1, \ldots, x_6) - \pi/2 + 0.46 < 0,\\
&4 \le x_{1,2,3} \le 6.3504,\ x_4 = 4,\ 3.01^2 \le x_{5,6} \le 3.24^2
\end{eqnarray*}

% 3
\item[\bf 3318775219]
\begin{eqnarray*}
&\begin{split}
0 < &\dih_y (y_1, \ldots, y_6) - 1.629 + 0.414 (y_2 + y_3 + y_5 + y_6 - 8.0)\\
	&- 0.763 (y_4 - 2.52) - 0.315 (y_1 - 2.0),
\end{split}\\
&2 \le y_i \le 2.52
\end{eqnarray*}

\end{itemize}

% Test Results
\section{Test Results}
This section contains time test results for inequalities described in the previous section. All tests were performed on Intel Core i5, 2.67GHz running Ubuntu 9.10 inside Virtual Box 4.2.0 on a Windows 7 host; the Ocaml version was 3.09.3; the base of arithmetic was 200; the caching was turned on.

\begin{center}
Polynomial inequalities

\begin{tabular}{l@{\quad} r r r r r}
%{r@{\quad}rl}
\hline
\multicolumn{1}{l}{\rule{0pt}{12pt}Inequality ID}&
\multicolumn{1}{l}{\phantom{x}\# variables}&
\multicolumn{1}{l}{\phantom{x}precision}&
\multicolumn{1}{l}{\phantom{x}total time (s)}&
\multicolumn{1}{l}{\phantom{x}formal verification (s)}\\
\hline\rule{0pt}{12pt}%
schwefel	& 3	& 5		& 26.329 &	19.145 \\
rd			& 3 & 5		& 1.593 &	0.017 \\
caprasse	& 4 & 5		& 8.057	&	1.286 \\
lv			& 4	& 5		& 1.875 &	0.030 \\
butcher		& 6 & 5		& 3.609 &	0.035 \\
magnetism	& 7 & 5		& 7.007 &	1.347 \\
heart		& 8 & 5		& 17.298 &	1.277 \\
\hline
\end{tabular}
\end{center}

\begin{center}
Flyspeck inequalities

\begin{tabular}{l@{\quad} r r r r r}
%{r@{\quad}rl}
\hline
\multicolumn{1}{l}{\rule{0pt}{12pt}Inequality ID}&
\multicolumn{1}{l}{\phantom{x}precision}&
\multicolumn{1}{l}{\phantom{x}total time (s)}&
\multicolumn{1}{l}{\phantom{x}formal verification (s)}\\
\hline\rule{0pt}{12pt}%
2485876245a	& 4 & 5.530 & 0.058 \\
4559601669b & 4 & 4.679 & 0.048 \\
4717061266  & 4 & 27.1 & 0.250 \\
5512912661  & 4 & 8.860 & 0.086 \\
6096597438a & 4 & 0.071 & 0.071 \\
6843920790  & 4 & 2.824 & 0.076 \\
SDCCMGA b   & 4 & 9.012 & 0.949 \\
TSKAJXY-TADIAMB\footnotemark[1] & 4 & 75.9 & 21.2 \\
7067938795  & 4 & 431   & 387 \\
5490182221  & 4 & 1726  & 1533 \\
3318775219  & 4 & 17091 & 15226 \\
\hline
\end{tabular}
\end{center}
\footnotetext[1]{Reduced to a polynomial inequality}

\end{document}