\documentclass{article}
\usepackage{fullpage}
\usepackage{nopageno}
\usepackage{amsmath}
\usepackage{amssymb}
\allowdisplaybreaks

\newcommand{\abs}[1]{\left\lvert #1 \right\rvert}

\begin{document}
\title{Notes}
\date{February 26, 2014}
\maketitle

\section*{lesson 13}
laplace transform for $ft)$ on $0\le t<\infty$
\begin{align*}
  \mathcal{L}\{f\}&=F(x)=\int_0^{\infty}{e^{-st}f(t)\,\mathrm{d}t}\\
  \intertext{inverse transform}
  f(t)&=\frac{1}{2\pi i}\int_{c-i\infty}^{c+i\infty}{F(s)e^{st}\,\mathrm{d}s}
\end{align*}
note $F(s)$ will typically be defined on $s\ge s_0$ (as described in introductory courses). $F(x)$ is analytic on $\text{Re}(s_s)\ge s_0$ on half-planes in $\mathbb{C}$.

page 101
\begin{align*}
  PDE&&u_t&=u_{xx}&0\le&x<\infty,&0<&t<\infty\\
  BC&&u_x(0,t)-u(0,t)&=0&&&0<&t<\infty\\
  IC&&u(x,0)=u_0
\end{align*}
$u_x$ is temperature gradient. $u_x=u$. $-cu_x$ is heat flow (in positive direction). when $u>0$ heat flows out of the rod and if $u<0$ then heat is flowing into rod. if the BC had a + instead of a $-$ we would have an unstable condition where more heat means the heat increases at a greater rate and boom. extra credit for this neh?
\begin{align*}
  U(x,s)&=\mathcal{L}\{u(x,t)\}\\
  \mathcal{L}\{f'(t)\}&=sF(s)-f(0)\\
\end{align*}
\begin{align*}
  PDE&&sU(x,s)-u(x,0)&=U_{xx}(x,s)\\
  &&\frac{\mathrm{d}^2U}{\mathrm{d}x^2}-sU&=-u_0\\
  BC&&U_x(0,s)-U(0,s)&=0\\
  \intertext{solution of DE. Can assume s is positive (and large)}
  &&U(x,s)&=c_1\text{ etc from pg 102}
\end{align*}
\end{document}


\documentclass{article}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\usepackage[pdftex]{graphicx}
%\usepackage{amsmath}

\begin{document}

\section{A note for Svar function in Matlab}

\noindent
\begin{verbatim}
 Marco Aiolfi
 maiolfi@iol.it
 Bocconi University and Banca Intesa, Milan
\end{verbatim}

SVAR verifies the identification conditions for a given structural form to
be imposed on an estimated VAR model. The require inputs are the set of
constraints to be placed on the elements of the A and B matrices so that
\begin{eqnarray}
Vec(A) &=&s_{A}\cdot \gamma _{A}+d_{A}  \label{res} \\
Vec(B) &=&s_{B}\cdot \gamma _{B}+d_{B}.  \nonumber
\end{eqnarray}

Here is an example.

Consider a 2 variables VAR and suppose you want Choleski identification:
\begin{equation}
A=\left[
\begin{array}{cc}
1 & 0 \\
a_{21} & 1
\end{array}
\right] ,B=\left[
\begin{array}{cc}
b_{11} & 0 \\
0 & b_{22}
\end{array}
\right] .
\end{equation}

Using \ref{res} the constraints can be rewritten as follows:
\begin{eqnarray}
\left[
\begin{array}{c}
1 \\
a_{21} \\
0 \\
1
\end{array}
\right]  &=&\left[
\begin{array}{c}
0 \\
1 \\
0 \\
0
\end{array}
\right] \cdot \left[ a_{21}\right] +\left[
\begin{array}{c}
1 \\
0 \\
0 \\
1
\end{array}
\right]  \\
\left[
\begin{array}{c}
b_{11} \\
0 \\
0 \\
b_{22}
\end{array}
\right]  &=&\left[
\begin{array}{cc}
1 & 0 \\
0 & 0 \\
0 & 0 \\
0 & 1
\end{array}
\right] \cdot \left[
\begin{array}{c}
b_{11} \\
b_{22}
\end{array}
\right] +\left[
\begin{array}{c}
0 \\
0 \\
0 \\
0
\end{array}
\right] .
\end{eqnarray}
After creating $s_{A},d_{A},s_{B},d_{B}$ the SVAR procedure is run with
\begin{verbatim}
[a,b,a_se,b_se]=svar1(results,sa,sb,da,db,afree,bfree)
\end{verbatim}

\noindent
where \texttt{results} is a VARE structure, \texttt{sa},\texttt{sb},\texttt{da%
},\texttt{db}, are the constraints and \texttt{afree} and \texttt{bfree} are
the number of free parameters in $A$ and $B$ matrices.

The demo file \textit{svar\_d.m} gives an example of SVAR procedure for a 5
variables VAR.

The interested reader can find details about identification and estimation
of a structural VAR models in Amisano and Giannini (1997). A good reference
for alternative identification schemes and their application to monetary
policy analys is Favero (2000).

\section{References}
\begin{enumerate}
\item[]   Amisano, G., and Giannini, C., (1997). \textit{Topics in
structural var econometrics}. Second edition, Springer Verlag, New York.

\item[] Favero, C. A., (2000). Applied Macroeconometrics. Oxford
University Press, Oxford.

\end{enumerate}

\end{document}


% Generated by GrindEQ Word-to-LaTeX 2008
% ========== UNREGISTERED! ========== Please register! ==========
% LaTeX/AMS-LaTeX

\documentclass[a4paper]{article}
\usepackage{anysize}
\marginsize{1cm}{1cm}{1cm}{1cm}

\usepackage{amssymb}
\usepackage{amsmath}
\usepackage[pdftex]{graphicx}
\usepackage{epsfig}
\usepackage{subfigure}
\usepackage{listings}
\lstset{language=haskell}
\lstset{commentstyle=\textit}
\lstset{mathescape=true}
%\lstset{labelstep=1}
%\lstset{backgroundcolor=,framerulecolor=}
\lstset{backgroundcolor=,rulecolor=}
\linespread{2.0}

\begin{document}

%%% remove comment delimiter ('%') and select language if required
%\selectlanguage{spanish}

\noindent
\section{Concrete Subtyping}

\noindent The downcasting operation that would allow us to safely use references that expect a smaller heap in a context where a larger heap is available requires some preliminary work.

\noindent First of all let us understand what kind of operation we will perform whenever we try to use a heap $h$ that is too large with respect to the get or set functions of the reference:

\begin{enumerate}
\item  We downcast the larger heap to an adequately smaller one

\item  We perform our computation on the downcast heap, thereby obtaining a new smaller heap

\item  We store the new smaller heap in the corresponding locations of the original heap
\end{enumerate}

\noindent The three steps listed above are summarized in the following diagram:

\begin{figure}[h]
\centerline{\psfig{file=heap_upcasting.png,height=5cm}} \caption{An example of picture.\label{fig:example}}
\end{figure}

\noindent The downcast operation is implemented easily enough on heaps thanks to the transitivity of the subtyping relationship. We just need to specify that:

\begin{lstlisting}
New h $\alpha$ $\le$ h
downcast=delete
\end{lstlisting}

And the first step of the computation is covered. Now we define the in-place substitution operation with an appropriate predicate:

\begin{lstlisting}
HList h $\wedge$ HList $h'$ $\wedge$ $h'$ $\le$ h $\Rightarrow$ InPlaceSubstitute h h'
    inPlaceSubstitute : h $\to$ $h'$ $\to$ $h'$
\end{lstlisting}

This new predicate is instanced inductively on the length of the prefix$\ h$:

\begin{lstlisting}
InPlaceSubstitute Nil h
    inPlaceSubstitute Nil h = h
\end{lstlisting}

and

\begin{lstlisting}
InPlaceSubstitute (h::tl) ($h'$::$tl'$)
    inPlaceSubstitute (h::tl) ($h'$::$tl'$) = h::(inPlaceSubstitute tl $tl'$)
\end{lstlisting}

Thanks to this new operator, which we could consider an upcasting operator of sorts, we can now define the proper downcasting operation for references:

\begin{lstlisting}[frame=tb,mathescape]{somecode}
HList h,HList $h'$, h $\le$ $h'$ $\Rightarrow$ Reference $h'$ $\alpha\le$ Reference $\alpha$
downcast (Reference get set)=Reference
		($\lambda$h.upcast h (get (downcast h)))
		($\lambda$v.$\lambda$h.upcast h (set v (downcast h)))
	where upcast h (x,$h'$) = (x, inPlaceSubstitute $h'$ h)
\end{lstlisting}

This operation invokes the get and set functions of a reference with the downcast (smaller) heap with respect to the input (larger) heap, and then rebuilds a larger heap by stitching together the input heap with the resulting heap from the get or set operation.

\noindent

\end{document}

% == UNREGISTERED! == GrindEQ Word-to-LaTeX 2008 ==


% Fact sheet for MATH 300, for Fall 2014.
%
\documentclass[11pt]{article}
% Nice page size.
\setlength{\textwidth}{7in} \setlength{\textheight}{9.8in}
\setlength{\topmargin}{-1in} \setlength{\oddsidemargin}{-0.25in}
\setlength{\evensidemargin}{-0.25in}
%
% No page numbering.
\pagestyle{empty}
\usepackage{graphicx}
\usepackage{epstopdf}
\DeclareGraphicsRule{.tif}{png}{.png}{`convert #1 `dirname #1`/`basename #1 .tif`.png}
\usepackage{color}
\usepackage{hyperref}
\usepackage{amssymb}
\usepackage{algpseudocode}
\begin{document}
\thispagestyle{empty}
\includegraphics{../../../psulogo_horiz_bw.eps}\hfill\includegraphics{../../../deptlogo}
\vspace{10pt}
\begin{center}
{\large\bf STAT 671}    \\*[5pt] {\Large Statistical Learning I}
\\*[12pt] {\large Fall 2019}
\\ {\large Homework 2}
\\ {\large Due October 28$^{th}$ at the beginning of class}
\end{center}
\vspace{1cm}
\noindent

%\section{Kernalized ridge regression}
%\begin{enumerate}
%\item Code the kernalized ridge regression for the 2d example that you already used for the simple classifier and the perceptron. Show your code.
%\item Show 3 examples of results obtain with simulated data in 2 dimensions, using 3 different kernels.
%\end{enumerate}
%\section{MNIST dataset}
%\begin{enumerate}
%\item Import the MNIST dataset. It is available on D2L. A R file is available for reading the files and run a simple classifier.  you will find online similar code in case you use Matlab or other high level language.
%\item Try to run the kernelized ridge regression for the digit zero versus all the other ones.  You will see that the size of the training set is too large. Sample a smaller training set, say of size 100. Now, you should be able to run it. Experiment with larger training set size. Report the performances, learning time and testing time on a graph.
%\end{enumerate}
\section{Kernels}
\begin{enumerate}
\item let $(x,y) \in \mathbb{R}^+ \times \mathbb{R}^+$, where $\mathbb{R}^+=\{x \in \mathbb{R};x \geq 0\}$, the ``french positive\rq\rq{} real numbers.
\begin{enumerate}
\item
Verify that
$$\min(x,y) = \int_0^\infty \mathbb{I}_{t\leq x} \mathbb{I}_{t\leq y} dt$$
where
$$\mathbb{I}_A =  \left\{
\begin{tabular}{ll}
1 & \mbox{ if A is true}\\
0 & \mbox{otherwise}
\end{tabular}
\right.
$$

\item Use the previous question to show that $K(x,y)=\min(x,y)$ is a pd kernel over $\mathbb{R}^+$
\item Show that $\max(x,y)$ is not a pd kernel over  $\mathbb{R}^+$.
\end{enumerate}
\item Consider a probability space $(\Omega,\mathcal{A},P)$
\begin{enumerate}
\item Define for any two events $A$ and $B$,
$$K_1(A,B)=P(A \cap B)$$
where $A \cap B$ is the intersection between the events A and B
Verify that $K_1$ is positive definite. Hint: $P(A)=E[\mathbb{I}_A]$
\item Define for any two events $A$ and $B$,
$$K_2(A,B)=P(A \cap B)-P(A)P(B)$$
Verify that $K_2$ is positive definite.
\end{enumerate}
\end{enumerate}
\section{Kernels and RKHS}
\begin{enumerate}
\item Define the RKHS  over $\mathbb{R}^d$
$$K(x,y)=x^Ty+c$$
where $c>0$.
\begin{enumerate}
\item
What is the RKHS associated with the kernel $K$? no proof is required.
\item
What is the inner product in this RKHS? no proof required.
\item
Verify the reproducing property
\end{enumerate}
\item Define the RKHS  over $\mathbb{R}^d$
$$K(x,y)=(x^Ty)^2$$
where $c>0$.
The RKHS associated with the kernel $K$ is $\{f_S;f_S(x)=x^T S x\}$ where $S$ is a symmetric $(d,d)$ matrix. The inner product is
$$<f_{S_1},f_{S_2}>=<S_1,S_2>_F$$
\begin{enumerate}
\item
Verify the reproducing property.
\item
Why do we require that $S$ is symmetric?
\end{enumerate}
\item Define the RKHS  over $\mathbb{R}^d$
$$K(x,y)=(x^Ty+c)^2$$
where $c>0$.
\begin{enumerate}
\item
What is the RKHS associated with the kernel $K$? no proof is required.
\item
What is the inner product in this RKHS? no proof required.
\item
Verify the reproducing property
\end{enumerate}
\end{enumerate}
\section{Fisher kernel}
Let\footnote{If you are not familiar with probabilistic models, do not panic! come to see me.} $\theta \in \mathbb{R}$ be a parameter and let $p_\theta$ be a probabilistic model (i.e a point mass function or a density) over a set $\mathcal{X}$ indexed by $\theta$. Let $\theta_0 \in \mathbb{R}$ be a specific value for $\theta$.

Let us define the Fisher score at $x \in \mathcal{X}$ as
\begin{equation}
\phi(x,\theta_0) = \frac{\delta}{\delta \theta} \ln p_\theta(x) \mbox{ evaluated at } \theta=\theta_0
\end{equation}
assuming that this quantity exists.

Define $I(\theta)$, the Fisher information associated with the parameter $\theta$, i.e.,
\begin{equation}
I(\theta)=E[\phi^2(X,\theta)]
\end{equation}
where $E$ stands for expectation and $X$ is a random variable with distribution $p_\theta$.

The Fisher kernel is then
\begin{equation}
k(x,x')=\frac{\phi(x,\theta_0)\phi(x',\theta_0)}{I(\theta_0)}
\end{equation}
where
\begin{enumerate}
\item Verify that $k(.,.)$ is a positive definite kernel over $\mathcal{X}$
\item Consider the following model: $x \in \{0,1\}$, $X \sim Bernoulli(\theta)$, $0 < \theta < 1$, that is
\begin{equation}
p_\theta(x)=\theta^x(1-\theta)^{(1-x)}
\end{equation}
We recall that in this case $E[X]=\theta$ and $Var[X]=E[(X-\theta)^2]=\theta(1-\theta)$

Compute $k(x,x')$

Hint: you will find $$k(x,x')=\frac{(x-\theta_0)(x'-\theta_0)}{\theta_0(1-\theta_0)}$$
\item
Assume now $x=(x_1,x_2)$ with $x_1 \in \{0,1\}$ and $x_2 \in \{0,1\}$.
We consider the following model where $X=(X_1,X_2)$, $X_1$ and $X_2$ are independent with the same $Bernoulli(\theta)$ distribution.
Compute $k(x,x')$.
\end{enumerate}

\end{document}


\newcommand{\Up}{\ensuremath{\mathit{up}}}
\newcommand{\Down}{\ensuremath{\mathit{down}}}
\newcommand{\Left}{\ensuremath{\mathit{left}}}
\newcommand{\Right}{\ensuremath{\mathit{right}}}
\newcommand{\Wait}{\ensuremath{\mathit{wait}}}

\section{From Cost-Optimal MAPF to ASP}
The core of our translation of MAPF to ASP, like other existing encodings, is inspired by translations from planning to SAT \cite{}, where the makespan $m$ is a parameter of the encoding. Given a MAPF problem $P$, our ASP program that has a model iff there exists a conflict-free solution of makespan $m$. Moreover, if the program has a model then such a model describes a cost-optimal solution.

To represent the map, we use the predicates $rangeX/1$, $rangeY/1$ and $obstacle/2$, where the first two are used to define the size of the grid and the third to define the $(X,Y)$ that are obstacles. For each robot $R\in\{1,\ldots,r\}$ we add a fact of the form $goal(R,X_R,Y_R)$ establishing that $(X_R,Y_R)$ is the goal of $R$.

Our translation uses predicates to represent the position of the agents and the actions performed at each time step in $\mathcal{T}=\{0,\ldots,m\}$. Specifically, the atom $exec(R,A,T)$ represents the fact that robot $R$ performs action $A$ at time $T$, where $T$ can take any value in $\{0,\ldots,m-1\}$, and $A$ a value in $\mathcal{A}=\{\Up,\Down,\Left,\Right,\Wait\}$.

To model the position of agents, we use predicate $at$, such that $at(R,X,Y,T)$ represents that robot $R$ is at cell $(X,Y)$ at time $T$. Its dynamics is defined by rules of the form:
\begin{equation}
\begin{split}
at(R,X,Y,t) \leftarrow &exec(R,A,t-1),at(R,X',Y',t-1), \\&delta(A,X',Y',X,Y), \label{position}
\end{split}
\end{equation}
for each $t\in\{1,\ldots,m\}$, which state that the position of robot $R$ is $(X,Y)$ at time $T$ when the position of the robot at time $T-1$ was $(X',Y')$ and the agent performs an action $A\in\mathcal{A}$ that is such that $delta(A,X',Y',X,Y)$ holds true. Predicate $delta$ is defined in the obvious way for each action $A$; for example, the encoding includes a rule that establishes that atom $delta(\Right,X,Y,X+1,Y)$ is in a model whenever $(X,Y)$ is a cell in the map. We observe that the number of rules of form \eqref{position} is $\mathcal{O}(rmC)$, where $C$ is the number of cells in the map.

To express the fact that each agent performs exactly one action at any time step in $t\in\{0,\ldots, T-1\}$ we write:
\begin{equation}
  1 \{exec(R,A,t) : action(A)\} 1 \leftarrow robot(R).
\end{equation}
These are exactly $R$ generating rules that force the cardinality of the set $\{exec(R,A,t) : action(A)\}$ to be exactly one. We note that the encoding is such that atom is in every model $action(A)$, for each action in $\mathcal{A}$.

The two rules above do not restrict the moves of the agent enough. First we establish that no two different agents are allowed to cross the border of a cell in parallel. To that end, for every $t\in\{1,\ldots,m\}$ we add:
\begin{gather}
  \begin{split}
\leftarrow &on(R_1,X+1,Y,t-1), on(R_2,X,Y,t-1), \\ &on(R_1,X,Y,t), on(R_2,X+1,Y,t),R_1!=R_2.
\end{split}\\
\begin{split}
\leftarrow &on(R_1,X,Y+1,t-1), on(R_2,X,Y,t-1),\\ &on(R_1,X,Y,t), on(R_2,X,Y+1,t),R_1!=R_2.
\end{split}
\end{gather}
Observe that this generates $\mathcal{O}(r^2mC)$ rules in the grounded representation. In addition, no two robots can be at the same cell, and no robot can exit the map, so for every $t\in \{0,\ldots,m\}$ we generate:
\begin{align}
&\leftarrow on(R,X,Y,t), not\: rangeX(X).\\
&\leftarrow on(R,X,Y,t), not\: rangeY(Y). \\
&\leftarrow on(R_1,X,Y,t),on(R_2,X,Y,t),R_1!=R_2. \\
&\leftarrow on(R,X,Y,t),obstacle(X,Y).
\end{align}
Finally, we express that all robots have to be in their goal position at time step $m$:
\begin{align}
  \leftarrow robot(R), not\: at\_goal(R,t),
\end{align}
where $at\_goal/2$ is defined in the following way:
\begin{align}
at\_goal(R,m) \leftarrow on(R,X,Y,m), goal(R,X,Y).
\end{align}
\subsection{Cost-Optimal Solutions}


\documentclass{article}

\usepackage[table,xcdraw]{xcolor}
\usepackage{float}
\usepackage[euler]{textgreek}
\usepackage{fancyhdr}
\pagestyle{fancy}

\title{Parallel Orbital Simulation Environment (POSE)}
\author{Dylan R. Wagner}

\begin{document}

  \pagenumbering{gobble}
  \maketitle

  \section{Context}

  This document will describe the aspects of the simulation software including: operation, orbital model including models of perturbing forces, concurrent parallel design, input and output, model of orbital collisions and simulation of spacecraft logic. Additional aspects related to stages of simulation development will also be provided.

  \section{Summary of Operation}

  \paragraph{1)}

  The software is to take in parameters relating to the simulation environment. Read in the initial input file defining the state of objects in orbit at time 0. These objects will be added alongside entities pertaining to the orbital environment such as the Earth, Moon, Sun and other “Smart” objects.

  \paragraph{2)}

  The simulation will then calculate acceleration vectors for each object in the environment then update the corresponding velocity vector and position. For “Smart” objects, custom logic evaluates the environment within the simulation then updates internal state. When the simulation has completed calculations for the current time interval, collision detection and modeling is evaluated. Any new bodies generated by the collision detection and modeling algorithm will be added to the current pool of bodies in the simulation. At this point, the current state of the bodies in the simulation will be logged to a file.

  \paragraph{3)}

  From this point on, the simulation repeats until a stop condition is reached. This stop condition is tied to the total runtime or triggered by defined event(s) within the simulation. At the end of simulation statics will be logged to a flat file.

  \section{Orbital Simulation Method}

  The simulation software will use Cowell’s method. Cowell’s method involves adding together acceleration vectors acting on bodies in orbit. This summed acceleration vector can be separated in X, Y, Z components then integrated to find velocity with velocity being integrated to find spacial displacement.

  \subsection{Main Algorithm}

  \section{Models of Perturbing Forces}

  \begin{itemize}
  	\item Large Body Gravity

	\[ a_x = \frac{Gm_j(r_{jx} - r_{ix})}{r^3_{ij}} \]

	\[ a_y = \frac{Gm_j(r_{jy} - r_{iy})}{r^3_{ij}} \]

	\[ a_z = \frac{Gm_j(r_{jz} - r_{iz})}{r^3_{ij}} \]

  	\item Earth Non-spherical Gravity
  	\item Solar Radiation
  	\item Drag

  	\item Magnetic Fields
  	\item Propulsion
  \end{itemize}

  \section{GPU Acceleration}

Most calculations on bodies within the simulation will be accelerated by one or many graphic processing units. Calculations pertaining to the orbital perturbations will be at the heart of the shader program. It is important to note that not all calculations will be performed on the GPU but the bulk will. By using GPU acceleration, massive amount of orbital debris can be included into the simulation. Using GPU acceleration the simulation can scale by using multiple GPUs.

  \section{Input and Output}

The input and output to the simulation will consist of only text based files or streams. Below definitions for all input and output at all stages of the simulation are provided.

  \subsection{Input at Start-up}

  The simulation at startup needs some information pertaining the celestial environment. This information consists of the bodies which will be simulated. The bodies are ether debris or spacecraft; each needing additional attributes which define the object. Below attributes for both debris and spacecraft are listed:

  \paragraph{Debris}
  \begin{itemize}
  	\item ID (Unique)
  	\item X, Y, Z (Geocentric) locations in the simulation space
  	\item vX, vY, vZ (Geocentric) initial velocity values
  	\item Shape (Cube or Spheroid)
  	\item Dimensions W, L, H
  	\item Material (Eg: Aluminum or Aluminium oxide)
  \end{itemize}

  \paragraph{Spacecraft}
  \begin{itemize}
    	\item ID (Unique)
    	\item Spacecraft Name
    	\item Orientation (\textalpha, \textbeta, \textgamma)
  	\item X, Y, Z (Geocentric) locations in the simulation space
  	\item vX, vY, vZ (Geocentric) initial velocity values
  	\item Opt01a: Shape (Cube or Spheroid)
  	\item Opt01a: Dimensions W, L, H
  	\item Opt02b: Spacecraft model file
  \end{itemize}

  The objects read in at start up will be listed sequentially in a flat file using Javascript Object Notation (JSON).

  \subsection{Simulation Output}

	The simulation will produce results throughout the simulation and at simulation stop condition. The simulation will be constantly writing to the Object Data file defined below. At simulation stop, a summary file will be provided containing information on majors events occurred.

  \paragraph{Object Data}

  \paragraph{Simulation Summary}

  \section{Simulation Environment}

  \subsection{Coordinate System}

  \subsection{Solar - Planetary Interactions}

  \section{Model of Orbital Collisions}

  \section{Simulation of Spacecraft Logic}

  \section{Stages of Development}

  \section{Domain}

\end{document}


\documentclass{sig-alternate}

\usepackage[utf8]{inputenc}
\usepackage[numbers]{natbib}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{url}

\newcommand{\Any}{\mathbf{any}}
\newcommand{\Top}{\mathbf{value}}
\newcommand{\Nil}{\mathbf{nil}}
\newcommand{\False}{\mathbf{false}}
\newcommand{\True}{\mathbf{true}}
\newcommand{\Boolean}{\mathbf{boolean}}
\newcommand{\Number}{\mathbf{number}}
\newcommand{\String}{\mathbf{string}}
\newcommand{\Void}{\mathbf{void}}
\newcommand{\Const}{\mathbf{const}}
\newcommand{\Self}{\mathbf{self}}

\def\dstart{\hbox to \hsize{\vrule depth 4pt\hrulefill\vrule depth 4pt}}
\def\dend{\hbox to \hsize{\vrule height 4pt\hrulefill\vrule height 4pt}}

\begin{document}

\permission{Permission to make digital or hard copies of all or part of this work for
   personal or classroom use is granted without fee provided that copies are
   not made or distributed for profit or commercial advantage and that copies
   bear this notice and the full citation on the first page. Copyrights for
   components of this work owned by others than the author(s) must be
   honored. Abstracting with credit is permitted. To copy otherwise, or
   republish, to post on servers or to redistribute to lists, requires prior
   specific permission and/or a fee. Request permissions from
   Permissions@acm.org.}
\conferenceinfo{Dyla}{'14, June 09-11 2014, Edinburgh, United Kingdom}
\CopyrightYear{is held by the owner/author(s). Publication rights licensed to
ACM.}
\crdata{978-1-4503-2916-3/14/06}

\title{Typed Lua: An Optional Type System for Lua}

\numberofauthors{3}

\author{
\alignauthor
André Murbach Maidl\\
  \affaddr{PUC-Rio}\\
  \affaddr{Rio de Janeiro, Brazil}\\
  \email{amaidl@inf.puc-rio.br}
\alignauthor
Fabio Mascarenhas\\
  \affaddr{UFRJ}\\
  \affaddr{Rio de Janeiro, Brazil}\\
  \email{mascarenhas@ufrj.br}
\alignauthor
Roberto Ierusalimschy\\
  \affaddr{PUC-Rio}\\
  \affaddr{Rio de Janeiro, Brazil}\\
  \email{roberto@inf.puc-rio.br}
}

\date{June 12th 2014}

\maketitle

\begin{abstract}
Dynamically typed languages trade flexibility and ease of
use for safety, while statically typed languages prioritize
the early detection of bugs, and provide a better framework
for structure large programs. The idea of optional typing
is to combine the two approaches in the same
language: the programmer can begin development with
dynamic types, and migrate to static types as the
program matures. The challenge is designing a type system
that feels natural to the programmer that is used to
programming in a dynamic language.

This paper presents the initial design of Typed Lua, an
optionally-typed extension of the Lua scripting language.
Lua is an imperative scripting language with first
class functions and lightweight metaprogramming mechanisms.
The design of Typed Lua's type system has a novel combination
of features that preserves some of the idioms that Lua
programmers are used to, while bringing static type
safety to them. We show how the major features of the
type system type these idioms with some
examples, and discuss some of the design issues we faced.
\end{abstract}

\category{D.3.1}{Programming Languages}{Formal Definitions and Theory}[Semantics]
\category{F.3.3}{Logics and Meanings of Programs}{Studies of Program Constructs}[Type structure]

\keywords{Lua programming language, type systems, optional typing, gradual typing}

\section{Introduction} \label{sec:intro}

Dynamically typed languages such as Lua avoid static types in favor of
runtime {\em type tags} that classify the values they compute, and
their implementations use these tags to perform runtime (or dynamic)
checking and guarantee that only valid operations are
performed~\citep{pierce2002tpl}.

The absence of static types means that programmers do not need to
bother about abstracting types that might require a complex type
system and type checker to validate, leading to simpler and more flexible
languages and implementations. But this absence may also hide bugs
that will be caught only after deployment if programmers do not properly
test their code.

In contrast, static type checking helps programmers detect many
bugs during the development phase. Static types also provide a
conceptual framework that helps programmers define modules
and interfaces that can be combined to structure the development
of large programs.

The early error detection and better program structure afforded by
static type checking can lead programmers to migrate their code from
a dynamically typed to a statically typed language, once their simple
scripts become complex programs~\citep{tobin-hochstadt2006ims}.
As this migration involves languages with different syntax and
semantics, it requires a complete rewrite of existing programs instead
of incremental evolution from dynamic to static types.

Ideally, programming languages should offer programmers the
option to choose between static and dynamic typing:
\textit{optional type systems}~\citep{bracha2004pluggable} and
\textit{gradual typing}~\citep{siek2006gradual} are two approaches
that offer programmers the option to use type annotations where static
typing is needed, incrementally migrating a system from dynamic
to static types. The difference between these two approaches is the
way they treat runtime semantics: while optional type systems
do not affect the runtime semantics,
gradual typing uses runtime checks to ensure that dynamically typed
code does not violate the invariants of statically typed code.

This paper presents the initial design of Typed Lua:
an optional type system for Lua that is complex enough to
preserve some of the idioms that Lua programmers are already
used to, while adding new constructs that help programmers
structure Lua programs.

Lua is a small imperative scripting language with first-class
functions (with proper lexical scoping) where the main data
structure is the {\em table}, an associative array that can
play the part of arrays, records, maps, objects, etc.
with syntactic sugar and metaprogramming through operator overloading built into
the language. Unlike other scripting languages, Lua has very
limited coercion among different data types.

The primary use of Lua has always been as an embedded language
for configuration and extension of other applications.
Lua prefers to provide mechanisms instead of fixed policies
for structuring programs, and even features
such as a module system and object orientation are a matter of
convention instead of built into the language.
The result is a fragmented ecosystem of libraries, and
different ideas among Lua programmers on how they should use
the language features and how they should structure programs.

The lack of standard policies
is a challenge for the design of a static type system for the Lua
language. The design of Typed Lua is informed by a (mostly
automated) survey of Lua idioms used in a large corpus of Lua
libraries, instead of relying just on the semantics of the
language.

Typed Lua allows statically typed Lua code to coexist and
interact with dynamically typed code. The Typed Lua compiler
warns the programmer about type errors, but always generates
Lua code that runs in unmodified Lua implementations. The
programmer can enjoy some of the benefits of static types even
without converting existing Lua modules to Typed Lua:
a dynamically typed module can export a statically typed
interface, and statically typed users of the module will have
their use of the module checked by the compiler.

Unlike gradual type systems, Typed Lua does not insert runtime
checks between dynamically and statically typed parts of the
program. Unlike some optional type systems, the statically
typed subset of Typed Lua is sound by design, so a later
version of the Typed Lua compiler can swicth to gradual
instead of just optional typing.

We cover the main parts of the design, along with
how they relate to Lua, in Sections~\ref{sec:atomic}
through~\ref{sec:classes}. Section~\ref{sec:review} reviews
related work on mixing static and dynamic typing in the same
language. Finally, Section~\ref{sec:con} gives some
concluding remarks and future extensions for Typed Lua.

\section{Atomic Types and Functions}
\label{sec:atomic}

Lua values can have one of eight {\em tags}: {\em nil}, {\em boolean},
{\em number}, {\em string}, {\em function}, {\em table}, {\em userdata},
and {\em thread}. In this section, we will see how Typed Lua assigns types to
values of the first five.

Figure~\ref{fig:typelang} gives the abstract syntax of Typed Lua
types. Only {\em first-class types} correspond to actual Lua
values; {\em second-class types} correspond to expression lists,
and Typed Lua uses them to type multiple assignment and function
application.

Types are ordered by a subtype relationship, where
any first-class type is a subtype of $\Top$. The rest of the
subtype relationship is standard: union types are supertypes
of their parts, $\Number$, $\Boolean$, and $\String$ are
supertypes of their respective literal types, function
types are related by contravariance on the input part and
covariance in the output part, table types have width
subtyping, with depth subtyping on $\Const$ fields,
tuple and vararg types are covariant.

The {\em dynamic type} $\Any$ allows dynamically typed code to
interoperate with statically typed code; it is a subtype of
$\Top$, but
neither a supertype nor a subtype of any other type. We relate
$\Any$
to other types with the {\em consistency} and {\em consistent-
subtype}
relationships used by gradual type systems~\citep{siek2006gradual,siek2007objects}.
 In practice, we can
pass a value of the dynamic type anytime we want a value of some
other type, and can pass any value where a value of the dynamic type
is expected, but these operations are tracked by the type system,
and the programmer can choose to be warned about them.

\begin{figure}[!ht]
\textbf{Type Language}\\
\dstart
$$
\begin{array}{rlr}
\multicolumn{3}{c}{\textbf{First-class types}} \\
T ::= & \;\; L & \textit{literal types}\\
& | \; B & \textit{base types}\\
& | \; \Top & \textit{top type}\\
& | \; \Any & \textit{dynamic type}\\
& | \; \Self & \textit{self type}\\
& | \; T \cup T & \textit{disjoint union types}\\
& | \; S \rightarrow S & \textit{function types}\\
& | \; \{F, ..., F\} & \textit{table types}\\
& | \; X & \textit{type variables}\\
& | \; \mu X.T & \textit{recursive types}\\
& | \; X_i & \textit{projection types}\\
L ::= & \multicolumn{2}{l}{\False \; | \; \True \; | \; {<}{\it number}{>} \; | \; {<}{\it string}{>} } \\
B ::= & \multicolumn{2}{l}{\Nil \; | \; \Boolean \; | \; \Number \; | \; \String} \\
F ::= & T:T \; | \; \Const \; T:T & \textit{field types} \\
\multicolumn{3}{c}{} \\
\multicolumn{3}{c}{\textbf{Second-class types}} \\
S ::= &  \multicolumn{2}{l}{\; \Void \; | \; V \; | \; V \cup S} \\
V ::= & \;\; T & \\
& | \; T* & \textit{vararg types}\\
& | \; T \times V & \textit{tuple types}
\end{array}
$$
\dend
\caption{Abstract syntax of Typed Lua types}
\label{fig:typelang}
\end{figure}

Typed Lua allows optional type annotations in variable function
declarations. It assigns the dynamic type to any parameter that
does not have a type annotation, but assigns more precise
types to unannotated variables, based on the type of the
expression that gives the initial value of the variable.

In the following example, we use type annotations in a function
declaration but do not use type annotations in the declaration
of a local variable:
\begin{verbatim}
    local function factorial(n: number): number
      if n == 0 then
        return 1
      else
        return n * factorial(n - 1)
      end
    end
    local x = 5
    print(factorial(x))
\end{verbatim}

The compiler assigns the type $\Number$ to the local variable \texttt{x},
and this example compiles without warnings. Typed Lua allows
programmers to combine annotated code with
unannotated code, as we show in the following example:
\begin{verbatim}
    local function abs(n: number)
      if n < 0 then
        return -n
      else
        return n
      end
    end
    local function distance(x, y)
      return abs(x - y)
    end
\end{verbatim}

The compiler assigns the dynamic type $\Any$ to the input
parameters of \texttt{distance} because they do not have type annotations.
Subtracting a value of type $\Any$ from another also yields a value of
type $\Any$ (Lua has operator overloading, so the minus operation
is not guaranteed to return a number in this case), but
consistent subtyping lets us pass a value of type $\Any$ to a
function that expects a $\Number$.

Even though the return types
of both {\tt abs} and {\tt distance} are not given, the compiler is able to
infer a return type of $\Number$ to both functions, as they are
local and not recursive.

Lua has first-class functions, but they have some peculiarities. First,
the number of arguments passed to a function does not need to
match the function's arity; Lua silently drops extra arguments after
evaluating them, or passes {\tt nil} in place of any missing arguments.
Second, functions can return any number of values, and the number
of values returned may not be statically known. Third, Lua also has
multiple assignment, and the semantics of argument passing match
those of multiple assignment (or vice-versa); calling a function is like
doing a multiple assignment where the left side is the parameter list
and the right side is the argument list.

Typed Lua uses {\em second-class types} to encode the peculiarities
of argument passing, multiple returns, and multiple assignment. We call
them second-class because these types do not correspond to actual
values and cannot be assigned to variables or parameters: they are an
artifact of the interaction between the type system and the semantics of Lua.

As we can see in Figure \ref{fig:typelang}, a second-class
type in Typed Lua can be a tuple of first-class types
optionally ending in a variadic type, or a union of these
tuples. A variadic type $T*$ is a generator for a
sequence of values of type $T \cup \Nil$. Unions of tuples play
an important part in functions that are overloaded on the
return type, together with {\em projection types}. Both are
explained in the next
section.

In its default mode of operation, Typed Lua always adds a
variadic tail to the parts of a function type if none is
specified, to match the semantics of Lua function calls. In the
examples above, the types
of {\tt factorial} and {\tt abs} are actually
$\Number \times \Top * \rightarrow \Number \times \Nil *$,
and the type of {\tt distance} is $\Any \times \Any \times \Top *
\rightarrow \Number \times \Nil *$.

If we call {\tt abs} with extra arguments, Typed Lua silently
ignores them, as the type signature lets {\tt abs} receive any
number of extra arguments. If we call {\tt abs} in the right side
of an assignment to more than one lvalue, Typed Lua checks if the
first lvalue has a type consistent with $\Number$, and any other
lvalues need to have a type consistent with $\Nil$.

There is an optional stricter mode of operation where
Typed Lua does not give variadic tails to the parts
of a function type unless the programmer explictly
declares it, and so will also check all function calls
for arity mismatch.

A variadic type can only appear in the tail position of a tuple,
because Lua takes only the first value of any expression that
appears
in an expression list that is not in tail position. The following
example
shows the interaction between multiple returns and expression
lists:

\begin{verbatim}
    local function multiple()
      return 2, "foo"
    end
    local function sum(x: number, y: number)
      return x + y
    end
    local x, y, z = multiple(), multiple()
    print(sum(multiple(), multiple())
\end{verbatim}

Function {\tt multiple} is
$\Top * \rightarrow \Number \times \String \times \Nil *$,
and {\tt sum} is $\Number \times \Number \times \Top * \rightarrow
\Number \times \Nil *$. In the right side of the multiple assignment,
only the first value produced by the first call to multiple gets used, so
the type of the right side is $\Number \times \Number \times \String \times \Nil*$,
and the types assigned to {\tt x}, {\tt y}, and {\tt z} are respectively $\Number$,
$\Number$, and $\String$. This also means that the call to {\tt sum} compiles
without errors, as the first two components of the tuple are consistent with
the types of the parameters, and the other components are consistent with
$\Top$.

\section{Unions}
\label{sec:unions}

Typed Lua uses union types to encode some common Lua idioms:
optional values, overloading based on the tags of input parameters,
and overloading on the return type of the functions.

Optional values are unions of some type and $\Nil$, and are so
common that Typed Lua uses the {\tt t?} syntax for these unions.
They appear any time a function has optional parameters, and
any time the program reads a value from an array or map.

\begin{verbatim}
    local function message(name: string,
                           greeting: string?)
      local greeting = greeting or "Hello "
      return greeting .. name
    end

    print(message("Lua"))
    print(message("Lua", "Hi"))
\end{verbatim}

In this example, the second parameter is optional but, in the
first line of the function, we declare a new variable that is
guaranteed to have type $\String$ instead of $\String \cup \Nil$.
In Lua, any value except {\tt nil} and {\tt false} are ``truthy",
so the short-circuiting {\tt or} operator is a common way of
giving a default value to an optional parameter. Typed Lua
encodes this idiom with a typing rule: if
the left side of {\tt or} has type $T \cup \Nil$ and the right side has type $T$ then the {\tt or} expression has type $T$.

Declaring a new {\tt greeting} variable that shadows the
parameter is not necessary:

\begin{verbatim}
    local function message(name: string,
                           greeting: string?)
      greeting = greeting or "Hello "
      return greeting .. name
    end
\end{verbatim}

Typed Lua lets the assignment $x = x \ \mathbf{or} \ e$ change
the type of $x$ from $t \cup \Nil$ to $t$,
as long as the type of $e$ is a subtype of $t$, $x$ is local
to the current function, and it is not assigned in
another function. The change only affects the type of $x$
in the remainder of the current scope. In the case of {\tt
greeting}, the assignment on line three changes its type to
$\String$.

Overloaded functions use the {\tt type} function to inspect
the tag of their parameters, and perform different actions
depending on what those tags are. The simplest case overloads
on just a single parameter:

\begin{verbatim}
    local function overload(s1: string,
                            s2: string|number)
      if type(s2) == "string" then
        return s1 .. s2
      else
        -- string.rep: (string, number) -> string
        return string.rep(s1, s2)
      end
    end
\end{verbatim}

Typed Lua has a small set of type predicates that, when used
over a local variable in a condition, constrain the type of that
variable. The function above uses the {\tt type(x) == "string"}
predicate which constrains the type of $x$ from $T \cup \String$ to
$\String$ when the predicate is true and $T$ otherwise.
This is a simplified form of {\em flow
typing}~\cite{guha:flow,tobin:occur}. As with {\tt or}, the
variable must be local to the function, and cannot be assigned
to in another function.

The type predicates can only discriminate based on tags, so they
are limited on the kinds of unions that they can discriminate. It
is possible to discriminate a union that combines a table type with
a base type, or a table type with a function type, or a two base types,
but it is not possible to discriminate between two different function
types.

Functions that overload their return types to signal the occurrence
of errors are another common Lua idiom. In this idiom, a function
returns its normal set of return values in case of success but,
if anything fails, returns {\tt nil} as the first value, followed
by an error message or other data describing the error, as in the
following example:

\begin{verbatim}
    local function idiv(d1: number, d2: number):
          (number, number)|(nil, string)
      if d2 == 0 then
        return nil, "division by zero"
      else
        local r = d1 % d2
        local q = (d1 - r)/d2
        return q, r
      end
    end
\end{verbatim}

There is also special syntax for this idiom: we could
annotate the return type of {\tt idiv} with {\tt (number, number)?}
to denote the same union\footnote{The parentheses are always
necessary here: {\tt number?} is {\tt number|nil}, while {\tt (number)?}
is {\tt (number)|(nil, string)}.}.

The full type of {\tt idiv} is $\Number \times \Number \times
\Top * \rightarrow (\Number \times \Number \times \Nil *) \cup
(\Nil \times \String \times \Nil *)$. A typical client of this
function would use it as follows:

\begin{verbatim}
    local q, r = idiv(n1, n2)
    -- q is number|nil, r is number|string
    if q then
      -- q and r are numbers
    else
      -- r is a string
    end
\end{verbatim}

When Typed Lua encounters a union of tuples in the right side
of an declaration, it stores the the union in a special type
environment with a fresh name and assigns {\em projection types}
to the variables in the left side of the declaration. If the type
variable is $X$, variable {\tt q} gets type $X_1$ and variable
{\tt r} gets type $X_2$.

If we need to check a projection type
against some other type, we take the union of the corresponding
component in each tuple. But if a variable with a projection
type appears in a type predicate, the predicate discriminates
against all tuples in the union. In the example above,
$X$ is $(\Number \times \Number \times \Nil *) \cup
(\Nil \times \String \times \Nil *)$ outside of the {\tt if}
statement, but $\Number \times \Number \times \Nil *$ in the
{\tt then} block and $\Nil \times \String \times \Nil *$ in
the {\tt else} block.

Notice that we could also discriminate {\tt r} using
{\tt type(r) == "number"} as our predicate, with the same
result. The first form is more succinct, and more idiomatic.
We can also use projection types to write overloaded functions
where the type of a parameter depends on the type of another
parameter.

Assigning to a variable with a projection type is forbidden,
unless the union has been discriminated down to a single tuple,
Unrestricted assignment to these variables would be unsound,
as it could break the dependency relation between the types
in each tuple that is part of the union.

Currently, a limitation of our overloading mechanisms is that
the return type cannot depend on the input types; we cannot
write a function that is guaranteed to return a number if
passed a number and guaranteed to return a string if passed
a string, for example. While intersection types provide
a way to express the type of such a function as $\Number
\rightarrow \Number \cap \String \rightarrow \String$,
more sophisticated flow typing is needed to actually check
that a function has this type, and we are still working on this
problem.

\section{Tables and Interfaces}
\label{sec:tables}

Tables are the main mechanism that Lua has to build data
structures. They are associative arrays where any value
(except {\tt nil}) can be a key, but with language support
for efficiently using tables as tuples, arrays (dense or sparse),
records, modules, and objects. In this section,
we show how Typed Lua encodes tables as arrays, records, tuples,
and plain maps in its type system.

Typed Lua uses the same framework to represent the different
uses that a Lua table has: {\em table types}. A table type
$\{ t_{1}:u_{1}, \ldots, t_{n}:u_{n}\}$ represents a map
from values of type $t_i$ to values of type $u_i$.

The concrete syntax of Typed Lua has syntax for
common table types. One syntax defines table types for
maps: it is written \texttt{\{ t: u \}},
and maps to the table type $\{t:u\}$.
This table type represents a map that maps values of type
$t$ to values of type $u$.
Another syntax defines table types for arrays:
it is written \texttt{\{ t \}}, and is equivalent to
the table type
$\{\Number:t\}$. A third syntax defines
table types for records:
it is written \texttt{\{ s1: t1, ..., sn: tn \}}, where
each $s_i$ is a literal number, string, or boolean,
and maps to the table type $\{s_{1}:t_{1}, ..., s_{n}:t_{n}\}$,
where each $s_i$ is the corresponding literal type.

The example below shows how we can define a map from
strings to numbers; the dot syntax for field access
in Lua is actually syntactic sugar for indexing a table
with a string literal:

\begin{verbatim}
    local t: { string: number } = { foo = 1 }
    local x: number = t.foo       -- x gets 1
    local y: number = t["bar"]    -- runtime error
\end{verbatim}

When accessing a map, there is always the possibility that
the key is not there. In Lua, accessing a non-existing key
returns {\tt nil}. Typed Lua is stricter, and raises a runtime
error in this case. To get a map with the behavior of standard
Lua tables, the programmer can use an union:

\begin{verbatim}
    local t: { string: number? } = { foo = 1 }
    local x: number = t.foo       -- compile error
    local y: number = t.bar or 0  -- y gets 0
    local z: number? = t["bar"]   -- z gets nil
\end{verbatim}

Now the Typed Lua compiler will complain about the assignment
on line two. The following example shows how we can declare
an array:
\begin{verbatim}
    local days: { string } = { "Sunday", "Monday",
      "Tuesday", "Wednesday", "Thursday",
      "Friday", "Saturday" }
    local x = days[1]          -- x gets "Sunday"
    local y = days[8]          -- runtime error
\end{verbatim}

Notice that we have the same strictness with missing
elements, unless the type of the elements has {\tt nil}
as a possible value.

While this runtime check is an instance where the semantics
of a Typed Lua program deviates from the semantics of
plain Lua, the alternatives would be to make all
arrays and maps have an element type that includes {\tt nil},
and either make the programmer narrow the type with {\tt or}
or an {\tt if} statement, making using the elements more
incovenient, or make {\tt nil} a subtype of every type,
reducing the amount of type safety in the system. Notice
that this does not change the semantics of dynamically
typed programs, as the runtime checks are only added when
the table has a strict static type.

If we want to declare a tuple, we can leave the
variable declaration unannotated and let Typed Lua assign
a more specific table type to the variable.
If we remove the annotation in the previous example,
the compiler assigns the following table type to \texttt{days}:
\begin{align*}
\{{1:\String},\;{2:\String},\;{3:\String},\;{4:\String},\;\\
{5:\String},\;{6:\String},\;{7:\String}\}
\end{align*}

This type is not a subtype of $\{\Number:\String\}$, nor
is $\{\Number:\String\}$ a subtype of $\{\Number:
\String\cup\Nil\}$, because in both cases the subtype
relationship would be unsound. In the first case,
a table type with the same fields as the type above,
plus $8: \Number$, is a subtype of the table type
above, so would also be a subtype of $\{\Number:\String\}$,
which is clearly unsound. In the second case, covariance
in the type of mutable fields is also unsound, for the
same reason as the unsoundness of array covariance.

While the record type above, $\{\Number:\String\}$, and
$\{\Number: \String\cup\Nil\}$ are disjoint, all three
types are valid for the table constructed in the example.
Typed Lua actually assigns different types to a table constructor
expression depending on the context where it is used.

Finally, the next example shows how we can declare a record:

\begin{verbatim}
    local person: { "firstname": string,
                    "lastname": string } =
      { firstname = "Lou", lastname = "Reed" }
\end{verbatim}

We could leave the type annotation out, and Typed Lua would
assign the same type to {\tt person}.

As records get bigger, and types of record fields get more
complicated, writing table types can be unwieldy, so Typed
Lua has {\em interfaces} as syntactic sugar for record types:

\begin{verbatim}
    local interface Person
      firstname: string
      lastname: string
    end
\end{verbatim}

The declaration above declares {\tt Person} as an alias to
the record type $\{$``firstname": $\String$,
 ``lastname": $\String\}$ in
the remainder of the current scope. We can now use {\tt Person} in
type declarations:

\begin{verbatim}
    local function greet(person: Person)
      return "Hello, " .. person.firstname ..
             " " .. person.lastname
    end
    local user1 = { firstname = "Lewis",
                    middlename = "Allan",
                    lastname = "Reed" }
    local user2 = { firstname = "Lou" }
    local user3 = { lastname = "Reed",
                    firstname = "Lou" }
    local user4 = { "Lou", "Reed" }
    print(greeter(user1)) -- Hello, Lewis Reed
    print(greeter(user2)) -- Error
    print(greeter(user3)) -- Hello, Lou Reed
    print(greeter(user4)) -- Error
\end{verbatim}

If our record type has fields that can be {\tt nil}, we need
to use an explicit type declaration when declaring a
variable of this record type, as the following example shows:

\begin{verbatim}
    local interface Person
      firstname: string
      middlename: string?
      lastname: string
    end
    local user1: Person = { firstname = "Lewis",
                            middlename = "Allan",
                            lastname = "Reed" }
    local user2: Person = { lastname = "Reed",
                            firstname = "Lou" }
\end{verbatim}

We need an explicit type declaration because neither of
the types that the Typed Lua compiler assigns to the
table constructors above is a subtype of $\{$``firstname":
$\String$, ``middlename": $\String \cup \Nil$, ``lastname":
$\String\}$, the type that {\tt Person} describes.

We can also use interfaces to define recursive types:

\begin{verbatim}
    local interface Element
      info: number
      next: Element?
    end
\end{verbatim}

It is common in Lua programs to build a record incrementally,
starting with an empty table, as in the following example:

\begin{verbatim}
    local person = {}
    person.firstname = "Lou"
    person.lastname = "Reed"
\end{verbatim}

Ideally, we want the type of {\tt person} to change as the
table gets built, from $\{\}$ to $\{$``firstname": $\String\}$
and finally to $\{$``firstname": $\String$, ``lastname":
 $\String\}$. This is tricker than the type change introduced
by assignment that we saw in Section 2.2, as what is changing
is not just the type of the variable {\tt person} but the
type of the value that {\tt person} points to. This is safe
in the example above, but not in the example below:

\begin{verbatim}
    local bogus = { firstname = 1 }
    local person: {} = bogus
    person.firstname = "Lou"
    person.lastname = "Reed"
\end{verbatim}

The assignment on line two is perfectly legal, as the type
of {\tt bogus} is a subtype of $\{\}$. But changing the type
of {\tt person} would be unsound: {\tt person.firstname} is
now a $\String$, but {\tt bogus.firstname} is still typed
as a $\Number$. We do not even need to declare a type for
aliasing to be a problem:

\begin{verbatim}
    local person = {}
    local bogus = person
    bogus.firstname = 1
    person.firstname = "Lou"
    person.lastname = "Reed"
\end{verbatim}

Taken individually, the changes to the type of the two
variables look fine, but aliasing makes one of them unsound.
The location of the change also matters, as the next example
shows:

\begin{verbatim}
    local person = {}
    local bogus = { firstname = 1 }
    do
      person.firstname = 1
      bogus = person
    end
    do
      person.firstname = "Lou"
    end
    -- bogus.firstname is now "Lou"
\end{verbatim}

The initial type of {\tt person} in all of these examples is
$\{\}$, but the {\em origin} of this type judgment matters
on whether it is sound to allow a change to the type of
{\tt person} or not, even if the change is always towards
a subtype of the current type.

Typed Lua tags a variable with a table type as either
{\em open} or {\em closed}. If a variable gets its type
from a table constructor then it is open, otherwise it is
always closed. The type of an open variable may change
by field assignment, subject to three restrictions: the
variable must be local to the current block, the new type
must be a subtype of the old type, and the variable
cannot have been assigned to in another function.

An variable with an open table type may be aliased, but
these aliases are not open. Any mutation on these aliases
is not a problem, as the type of the original reference
can only change towards a subtype. For mutable fields
this means that the type of the field cannot change
once it is added to the type of the table.

Using a variable with an open type can also trigger a
type change, if the type of the missing fields has
{\tt nil} as a possible value. This lets the programmer
incrementally create an instance of an interface with
an optional type:

\begin{verbatim}
    local interface Person
      firstname: string
      middlename: string?
      lastname: string
    end
    local user = {}
    user.firstname = "Lou"
    user.lastname = "Reed"
    local person: Person = user
\end{verbatim}

Table types are the foundation for modules and objects in
Typed Lua. Type changes triggered by field assignment are
also an important part of Typed Lua's support for the
idiomatic definition of Lua modules, which are the
subject of the next section.

\section{Modules}
\label{sec:modules}

Lua's module system, like other parts of the language, is
a matter of convention. When Lua first needs to load a
module, it executes the module's source file as a function;
the value that this function returns is the module, and Lua
caches it for future loads. While a module can be any
Lua value, most modules are tables where the fields
of the table are functions and other values that the
module exports.

The modules that we surveyed build this table using
three distinct styles. In the first style, the module's
source file ends
with a {\tt return} statement that uses a table constructor
with the exported members. In the second style, the
module declares an empty table in the beginning of its
source file, adds exported members to this table
throughout the module, and returns this table at the end.

These two styles are straightforward for Typed Lua, which
can just take the type of the first value that the module
returns and use it as the type of the module.

In the third style, which has been deprecated in the current
version of Lua, a module begins with a call to the {\tt module}
function. This function installs a fresh table as the
global environment for the rest of the module, so any
assignments to global variables are field assignments to
this table. The {\tt module} function also sets an {\tt \_M}
field in this table as a circular reference to the table
itself, so the module can end with {\tt return \_M}, but
this explicit return is not necessary.

While this style has been deprecated, our survey indicated
that around a third of Lua modules in a popular module
repository still use this style, so Typed Lua also
supports this style: it treats accesses to global
variables as field accesses to an open table
in the top-level scope.

\section{Objects and Classes}
\label{sec:classes}

Lua's built-in support for object-oriented programming is
minimal. The basic mechanism is the {\tt :} syntactic
sugar for method calls and method declarations.
The Lua compiler translates {\tt obj:method(args)}
to an operation that evaluates {\tt obj}, looks
for a field named ``method" in the result, then calls
it with the result of evaluating {\tt obj} as the
first argument, followed by the result of evaluating
the argument list in the original expression.

We can use table types and the {\em self type}
to represent objects,
and Typed Lua has syntactic sugar to make defining these
types easier:

\begin{verbatim}
    interface Shape
      x, y: number
      const move: (dx: number, dy: number) => ()
    end
\end{verbatim}

The double arrow in the type of the two methods is
syntactic sugar for having a first parameter named
{\tt self} with type $\Self$. The
{\tt const} qualifier is necessary for covariance
in the types of the methods, and to make subtyping
among object types work.

While {\tt :} is syntactic sugar in plain Lua, Typed Lua
uses it to type-check method calls, to bind any ocurrence
of the $\Self$ type in the type of the method to the
receiver. Indexing a method but not immediately calling
it with the correct receiver is a compile-time error.

There is still the matter of how to construct a value with
the object type above. The following example shows one
way:

\begin{verbatim}
    local shape = { x = 0, y = 0 }
    const function shape:move(dx: number,
                              dy: number)
      self.x = self.x + dx
      self.y = self.y + dy
    end
\end{verbatim}

The {\tt :} syntactic sugar that the example uses also comes
from Lua, and assigns a function to the field with a first
parameter named {\tt self}, plus any other parameters. Typed
Lua adds the {\tt const} annotation, and gives type $\Self$
to the implicit parameter {\tt self}.

Lua has a mechanism for Self-like (or JavaScript-like)
 delegation of missing
fields in a table. After {\tt setmetatable(t1,
\{ \_\_index = t2 \})}, Lua looks up in {\tt t2} any missing
fields of {\tt t1}. Lua programmers often use this mechanism
to simulate classes, as in the following example:

\begin{verbatim}
    local Shape = { x = 0, y = 0 }
    const function Shape:new(x: number, y: number)
      local s = setmetatable({},
                             { __index = self })
      s.x = x
      s.y = y
      return s
    end
    const function Shape:move(dx: number,
                              dy: number)
      self.x = self.x + dx
      self.y = self.y + dy
    end
    local shape1 = Shape:new(0, 5)
    local shape2: Shape = Shape:new(10, 10)
\end{verbatim}

In the last line of the example, notice how we can refer
to {\tt Shape} in the type annotation, as a shortcut
to the table type that Typed Lua has assigned
to this variable.

Typed Lua assigns the type
$\Self \times \Number \times \Number \times
\Top* \rightarrow \Self \times \Nil*$ to
{\tt new}. In a {\tt setmetatable} expression,
if the type $t_1$ of the first operand is a supertype
of the type $t_2$ of the second operand's {\_\_index} field,
it changes the type of the first operand to $t_2$,
so the local variable {\tt s}
has the same type as {\tt self}.

We can also use {\tt setmetatable} to simulate single
inheritance, as {\tt setmetatable} on a table constructor
assigned to a fresh local variable gives this variable
an open type, which lets us add new methods and override
existing ones:

\begin{verbatim}
    local Circle = setmetatable({},
                                { __index = Shape })
    Circle.radius = 0
    const function Circle:new(x: number,
                              y: number,
                              radius: value)
      local c = setmetatable(Shape:new(x, y),
                             { __index = self })
      c.radius = tonumber(radius)
      return c
    end
    const function Circle:area()
      return math.pi * self.radius * self.radius
    end
\end{verbatim}

In the first line of the redefinition of {\tt new},
notice how we can call {\tt Shape}'s constructor inside
the overridden constructor. A limitation of this class
system is that the overridden constructor must be a
subtype of the original constructor, so the type of
{\tt radius} has to be very permissive.

If we erase all type and {\tt const} annotations, the
two examples above are valid Lua code, with the same
semantics as the Typed Lua code.

The current version of Typed Lua does not have a polymorphic
type system, so programmers currently cannot hide the
calls to {\tt setmetatable} behind nicer abstractions, as
some Lua libraries do. A few Lua programs also use
other features of {\tt setmetatable} which are currently
not typeable, such as operator overloading.

\section{Related Work}
\label{sec:review}

Common LISP introduced optional type annotations in the early
eighties~\citep{steele1982ocl}, but they were optimization
hints to the compiler instead of types for static checking.
These annotations were unsafe, and could crash the program
when wrong.

\citet{abadi1989dts} used tagged pairs and explicit
injection and projection operations (coercions) to embed dynamic
typing in the simply-typed lambda calculus. Dynamically-typed
values had a {\tt Dynamic} static type. \citet{thatte1990qst}
removes the necessity of explicit coercions with a system
that automatically inserts coercions and checks them for
correctness.

\textit{Soft typing}~\citep{cartwright1991soft} starts
with a dynamically-typed language, and layers a static
type system with a sophisticated global type inference
algorithm on top, to try to find errors in programs
without needing to rewrite them. In cases where an error
may or may not be present, it warns the programmer and
inserts a runtime check. One problem with the soft
typing approach was the complexity of the inferred
types, leading to errors that were difficult to understand
and fix.

While the goal of soft typing is catching errors,
\textit{dynamic typing}~\citep{henglein1994dts} is
another approach for optimizing dynamically-typed programs.
First the program is translated to a program that uses
a {\tt Dynamic} type and explicit coercions and runtime checks,
then a static analysis removes some  of these coercions and
checks.

Instead of trying to add static checking to a dynamic
language, \citet{findler2002chf} enhances
the dynamic checks with the possibility of {\em contracts}
that give assertions about the input and output of (possibly
higher-order) functions. In case of higher-order functions,
the actual failing check can be far away from the actual
source of the error, so contracts can also add {\em blame
annotations} to values as a way to trace failures back to
the source.

Strongtalk \citep{bracha1993strongtalk,bracha1996strongtalk} is
an optionally-typed version of Smalltalk. It has a
polymorphic structural type system that programmers can use
to annotate Smalltalk programs, but type annotations can be
left out; unannotated terms are dynamically typed, and can
be cast to any static type. The interaction of the dynamic
type with the rest of the type system is unsound, so
Strongtalk uses the dynamically-checked semantics of
Smalltalk when executing programs, even if the programs
are statically typed.

Pluggable type systems~\citep{bracha2004pluggable} generalize
the idea of Strongtalk, to have type systems that can be
layered on top of a dynamic language without influencing
its runtime semantics. These systems can be unsound in
themselves, or in their interaction with the dynamically
typed part of the language, without sacrificing runtime
safety, as the semantics of the language catch any
runtime errors caused by an unsound type system.

Dart~\citep{dart} and TypeScript~\citep{typescript} are
two recent examples of languages with optional type systems
in this style. Dart is an object-oriented language with
a semantics that is similar to Smalltalk's, while TypeScript
is an object-oriented extension of JavaScript. Dart has a
nominal type system, while TypeScript has a structural one,
but both type systems are designed on purpose with unsound
parts (such as covariant arrays in case of Dart, and
covariant function return types in case of TypeScript) to
increase programmer convenience. The interaction of
statically and dynamically typed code is also unsound.

\citet{tobin-hochstadt2006ims} shows how programs
in the untyped lambda calculus can be incrementally
translated to the simply typed lambda calculus, using
contracts to guarantee that the untyped part cannot
cause errors in the typed part, as a model on how
scripts in a dynamically typed language can be
incrementally translated to a statically typed
language. This approach has been realized in the
Typed Scheme (later Typed Racket) language~\citep{tobin-hochstadt2008ts,tobin:occur}.

Gradual typing~\citep{siek2006gradual} combines the
optional type annotations of optional and pluggable
type systems with higher-order contracts. The gradual
type system is the simply typed lambda calculus enriched
with a {\em dynamic type} $?$, where a value with the
dynamic type can assume any type, and vice-versa.
A dynamic value that assumes a static type generates
a runtime check for a first-order value, or a wrapper
for a higher-order value. A static value that assumes
the dynamic type is tagged. The whole system is sound:
any runtime errors in a well-typed program must happen
in the dynamic parts.

While both gradual typing and the approach of
\citep{tobin-hochstadt2006ims} have the goal of
having a sound interaction of dynamically and statically
typed code, they differ in the granularity, with the
gradual typing providing a finer-grained transition from
dynamically typed to statically typed code.

Gradual typing has been combined with subtyping in
a simple object calculus~\citet{siek2007objects}, with
a nominal, polymorphic type system~\citet{ina:gradual},
with a row polymorphism~\citet{tobin:gradual},
and with the polymorphic lambda calculus~\citet{ahmed2011bfa}.
Gradual typing also adopted blame tracking from
higher-order
contracts~\citet{siek2010blame,ahmed2001bfa,wadler2009wpc}.

While Typed Racket is the first fully-featured programming
language with a sound mixture of dynamic and static typing,
Gradualtalk~\citep{allende2013gts} is the first
fully-featured language with a fine-grained gradual type
system. In Gradualtalk's case, the extra runtime checks
needed by gradual typing impose a big runtime
cost~\citep{allende2013cis}, and the programmer has the
option of turning off these checks, and downgrading
Gradualtalk to an optional type system.

Grace~\citet{black2013sg} is an object-oriented language
with optional typing. Grace is not an dynamically typed
language that has been extended with an optional type system,
but a language that has been designed from the ground up
to have both static and dynamic typing. \citet{homer2013modules}
explores some useful patterns that derive from Grace's
use of objects as modules and its brand of optional
structural typing, which can also be expressed with
Typed Lua's modules as tables.

The main feature of Typed Racket's type system is
{\em occurrence typing}~\citep{tobin:occur}, where
the type of a variable can be refined through tests
using predicates that check the runtime type of
the variable. As these types of checks are common in
other languages, but ocurrence typing is not sound
in the presence of mutation, related systems have
appeared~\citep{guha:flow,winther:flow,pearce:whiley}.

Tidal Lock~\citep{tidallock} is a prototype of another optional
type system for Lua. Compared with Typed Lua, Tidal Lock
has richer record types, and a more robust system of
incremental evolution of these record types, but it lacks
unions and support for expressing objects and classes.

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

This paper presented the initial design of Typed Lua,
an optional type system for the Lua scripting language.
While Lua shares several characteristics with other
dynamic languages such as JavaScript, so Typed Lua's
type system has several parts in common with optional
and gradual type systems for dynamic languages,
Lua also has some uncommon features.

These language features demanded features in the type
system that are not present in the type systems of these
other languages: functions with flexible arity and
their interaction with multiple assignment, functions
that are overloaded on the {\em number} of values
they return, and how to support the idiomatic way of
handling their return values, and incremental evolution
of record and object types.

Typed Lua is a work in progress: while the design covers
most of the Lua language as it is actually used by Lua
programmers, there are missing parts. A major omission
of the current version is the lack of polymorphic function
and table types, which will be present in the next version.
The {\tt setmetatable} primitive that we briefly saw in
Section~6 has several other uses that are currently
outside of the scope of the type system: operator
overloading, proxies, changing the behavior of built-in
types, multiple inheritance, etc. Finally, Lua has
one-shot delimited continuations~\citep{james2011yield}
in the form of {\em couroutines}~\citep{moura:coro},
which are also currently ignored by the type system.

Unlike some of the other optional type systems,
the type system of Typed Lua does not have deliberately
unsound parts, but we still do not have proofs that the
novel parts of our type system are sound.

Finally, while we our survey of Lua modules gives some
confidence that the design of Typed Lua is useful for
the majority of Lua programs, we have to validate the
design by using Typed Lua to to type a representative
sample of Lua modules.

\bibliographystyle{abbrvnat}
\bibliography{typedlua}

\end{document}


    \filetitle{nnzendog}{Number of endogenised data points}{plan/nnzendog}

	\paragraph{Syntax}\label{syntax}

\begin{verbatim}
[N,NREAL,NIMAG] = nnzendog(P)
\end{verbatim}

\paragraph{Input arguments}\label{input-arguments}

\begin{itemize}
\itemsep1pt\parskip0pt\parsep0pt
\item
  \texttt{P} {[} plan {]} - Simulation plan.
\end{itemize}

\paragraph{Output arguments}\label{output-arguments}

\begin{itemize}
\item
  \texttt{N} {[} numeric {]} - Total number of endogenised data points;
  each shock at each time counts as one data point.
\item
  \texttt{NREAL} {[} numeric {]} - Number of endogenised data points
  with anticipation mode 1.
\item
  \texttt{NIMAG} {[} numeric {]} - Number of endogenised data points
  with anticipation mode 1i.
\end{itemize}

\paragraph{Description}\label{description}

\paragraph{Example}\label{example}


\subsection{First-degree price discrimination}

perfect. have complete knowledge of customers


\chapter{Introduction}\label{ch:introduction}

Program verification is a grand challenge with significant impact in computer science.
Its main difficulty is in great part due to complicated program features such as concurrent execution, \hide{of threads,} pointers, \hide{with unbounded heap size,} recursive function calls, \hide{with recursions,} and unbounded basic data types~\cite{ClarkeJS05}. Subsequently, it is extremely tedious to develop a verification algorithm that handles all features. Researches on program verification typically address some of these features and simplify others. Verification tools however are required to support as many features as possible. Since implementation becomes increasingly unmanageable with additional features, incorporating algorithms for all features in verification tools can be a nightmare for developers.

One way to address the implementation problem is by reduction. If verifying a new feature can be transformed to existing features, development efforts can be significantly reduced.
In this paper, we propose an algorithm to extend intraprocedural (recursion-free) program analyzers to verify recursive programs. Such analyzers supply an \emph{inductive invariant} when a program is verified to be correct and support program constructs such as assumptions, assertions, and nondeterministic values. Our algorithm transforms any recursive program into recursion-free ones and invokes an intraprocedural program analyzer to verify properties about the generated recursion-free programs. The verification results allow us to infer properties on the given recursive program.

Our algorithm proceeds by iterations. In each iteration, it transforms the recursive program into a recursion-free program that \emph{under-approximates} the behaviors of the original and sends the under-approximation to an intraprocedural program analyzer. If the analyzer verifies the under-approximation, purported \emph{function summaries} for recursive functions are computed. Our algorithm then transforms the original recursive program into more recursion-free programs with purported function summaries. It finally checks if purported function summaries are correct by sending these recursion-free programs to the analyzer.

Compared with other analysis algorithms for recursive programs, our approach is very lightweight. It only performs syntactic transformation and requires standard functionalities from underlying intraprocedural program analyzers. Moreover, our technique is very modular. Any intraprocedural analyzer providing proofs of inductive invariants can be employed in our algorithm. With the interface between our algorithm and program analyzers described here, incorporating recursive analysis with existing program analyzers thus only requires minimal implementation efforts. Recursive analysis hence benefits from future advanced intraprocedural analysis with little cost through our~lightweight and~modular~technique.

We implement a prototype using \textsc{CPAchecker} (over 140 thousand lines of \textsc{Java} code) as the underlying program analyzer~\cite{BeyerK11}. In our prototype, 1256 lines of \textsc{OCaml} code are for syntactic transformation and 705 lines of \textsc{Python} code for the rest of the algorithm. 270 lines among them are for extracting function summaries. Since syntactic transformation is independent of underlying program analyzers, only about 14\% of code need to be rewritten should another analyzer be employed. We compare it with program analyzers specialized for recursion in experiments. Although \textsc{CPAchecker} does not support recursion, our prototype scores slightly better than the second-place tool \textsc{Ultimate Automizer} on the benchmarks in the 2014 Competition on Software Verification~\cite{svcomp14}.
Encouraged by the result, we submitted and successfully published our approach
on Static Analysis Symposium~\cite{ChenHTWW14}.
We further participated the 2015 Competition on Software
Verification~\cite{svcomp15} under the name \textsc{CPArec}~\cite{ChenHTWW15}.

\hide{
Notice that in order to simplify the implementation effort, we turned off important optimizations such as adjust block encoding provided in \textsc{CPAchecker}, the performance of the prototype can be even better with those optimizations turned on.
}

\noindent
\textbf{Organization:}
Chapter~\ref{ch:related} describes related works.
Preliminaries are given in Chapter~\ref{ch:preliminaries}.
We give an overview of our technique in Chapter~\ref{ch:overview}.
Technical contributions are presented in Chapter~\ref{ch:proving-via-transformation}.
Chapter~\ref{ch:experiments} reports experimental results.
Finally, some insights and improvements are discussed in Chapter~\ref{ch:conclusion}.

\hide{
Difference compared with Whale
In general, Whale tries to extend Lazy Abstraction to verify interprocedural program.
It mainly constructs an iARG with path conditions that can encode function calls and check for reachability of bug.
Also it introduces an extended covering relation over summaries of function calls to deal with recursion.
Our work, however, uses bounded times of unwinding to construct paths across functions,
and we find reasonable summaries for recursive functions when proving safety of program.

For guessing summaries, both Whale and our work use under-approximation of function calls.
In Whale, the under-approximation of a function call is constructed through exploring paths without function call in the called function.
In our work, the function call is unwound and transformed, and the exploration is achieved by the program analyzer we used.
With our method, we can create more precise under-approximation by unwinding more times before transforming.

For proving summaries, Whale and our work apply the Hoare rule of recursion. Whale defines the covering relation between summaries upon Hoare rule of consequence for proving. Our work, in other way, directly proves by the used program analyzer.
}


\documentclass[a4paper,11pt]{article}

\usepackage[english]{babel}

\usepackage[left=2.5cm, right=2.5cm]{geometry}

\setlength{\parindent}{0em}

\begin{document}

 The material contained in this Documentation
is in part also contained in the function \texttt{example.ci} of the
package.

\section{Main and interaction effect analysis}

Organise your data in a \texttt{data.frame} X. Eg.:

\begin{verbatim}
instance algorithm class results
inst1    alg1      boh1   40
inst1    alg2      boh1   40
...
inst1    alg1      boh2   40
inst1    alg2      boh2   40
...
\end{verbatim}

\texttt{instance, algorithm} and \texttt{class} must be factors. Note
that the columns names can be redefined but \texttt{class} must remain.

\begin{verbatim}
> formula <- results ~ instance * algorithm
\end{verbatim}

See R documentation for formula syntax (above all on the difference
between the sign ``*'' and ``+'' in the formula).

\bigskip
Parametric analysis:
\begin{verbatim}
> aov(formula,data=X)
\end{verbatim}

No need for the library so far. Everything is already in R.

\medskip

Then load the library:

\begin{verbatim}
> source("lib_effects.R")
\end{verbatim}

Nonparametric analysis (by ranks):
\begin{verbatim}
>  Friedman.test(formula,data=X)
\end{verbatim}

Nonparametric permutation analysis :
\begin{verbatim}
> permut.aov(formula,data=X,method="same",B=IN.PERM,type="csp")
\end{verbatim}

Values \texttt{eff1} \texttt{eff2} \texttt{inter} represent main inteeractions and
intereaction effects, respectively.

\section{Post-hoc analysis}

The packages \texttt{lattice} e \texttt{Hmisc} must be installed.

Organise your data in a \texttt{data.frame} X. Eg.:

\begin{verbatim}
instance algorithm class results
inst1    alg1      boh1   40
inst1    alg2      boh1   40
...
inst1    alg1      boh2   40
inst1    alg2      boh2   40
...
\end{verbatim}

instance, algorithm and class must be factors.

Then from R, load the library:

\begin{verbatim}
> source("lib_posthoc.R")
\end{verbatim}

for a parametric analysis:

\begin{verbatim}
> R <-AP.SCI(results~algorithm*instance,data=X,method="Parametric",test="Tukey")
> plot.ci(R)
\end{verbatim}

Note that, in the formula above \texttt{algorithm * instance} accounts
also for a significant interaction while \texttt{algorithm + instance}
does not account for interaction.

\smallskip

In the nonparametric case:

\begin{verbatim}
> R<-AP.SCI(results~algorithm+instance,data=X,method="Ranks",test="Conover")
> plot.ci(R)
\end{verbatim}

Interaction cannot be handled in this case. The output will be in a file
named \texttt{plot.ci.eps}. For
improving graphical layout edit the function \texttt{plot.ci.xclass}.

\bigskip

If instead the analysis includes more than one class of instances that
for some reason one wants to maintain distinct:

\begin{verbatim}
> R <- AP.SCI.wrapper.class(results~algorithm*instance,data=X,
                            method="Parametric",test="Tukey")
> plot.ci.xclass(R)
\end{verbatim}

or

\begin{verbatim}
> R <- AP.SCI.wrapper.class(results~algorithm+instance,data=X,
                            method="Ranks",test="Conover")
> plot.ci.xclass(R)
\end{verbatim}

The output will be in a file named \texttt{plot.ci.xclass.eps}. For
improving graphical layout edit the function \texttt{plot.ci.xclass}.

\subsection{Complete nomenclature}

\begin{description}
\item[\texttt{formula}:] ...
\item[\texttt{method}:] \texttt{"Parametric", "Ranks", "Permutations"}
\item[\texttt{test}:] Parametric case: \texttt{"Tukey", "LSD",
    "LSDBonferroni", "Sheffe"}\\ Nonparametric case:
  \texttt{"Conover","Sheskin","Permutations"}, i.e.,  Friedman test from
  Conover or Sheskin or permutation test on ranks.
\item[\texttt{alpha}:] is the family or experiment wise error rate.
\item[\texttt{adj.method}:] only in Permutation method.
  \texttt{"simul.Bonferroni", ``none'' "Bonferroni"}
\item[\texttt{type}:] \texttt{"csp","usp"} Constrained and Unconstrained
  Synchrnised Permutations
\item[\texttt{B}:] only in Permutation method. Numer of Monte Carlo
  Samples from the permutation space.
\end{description}

\medskip
Values
\begin{description}
\item \texttt{lower} and \texttt{upper}
\end{description}

 %   plot.hsu(Y,file=paste(ex,"-csp-",wh,sep=""),"CSP",dev="eps")

\end{document}


\section{Mixed Task Sets}
A simple solution would be to schedule asynchronous tasks/events whenever there
is time available. However this might lead to starvation.

\subsection{Polling Server (RM)}
A polling server is an additional periodic task which is used to serve aperiodic
requests. An aperiodic task is schedulable if (sufficient but not necessary):
\begin{equation*}
	\left(1 + \ceil{\frac{C_a}{C_s}}\right)T_s \leq D_a
\end{equation*}
Where $C_a, C_s, D_a, T_s$ are the total computation time of the aperiodic
request, the computation time of one server task, the deadline of the aperiodic
request, and the period of the server task. It is assumed that one aperiodic
request is served before another task arrives.

When no task is available and the server has highest priority, the server looses
its timeslot to the other tasks.

\subsection{Total Bandwidth Server (EDF)}
A certain cpu utilization (bandwidth) is reserved for the server.  When the
$k$th aperiodic request arrives it receives the deadline
\begin{equation*}
	d_k = \max\left( r_k, d_{k-1} \right) + \frac{C_k}{U_s}
\end{equation*}
where $C_k$ is the total execution time of the request and $U_s$ is the
utilization factor of the server. The request is then treated as a normal
periodic task.

The schedule is feasible iff $U_p + U_s \leq 1$. Where $U_p$ is the processor
utilitation of the periodic tasks.


\documentclass[11pt]{article}
\usepackage{amsfonts, amsmath, amssymb, amsthm, fullpage, mdwlist, fancyhdr}

\setlength{\textheight}{9.25in}
\setlength{\textwidth}{6.5in}
\setlength{\topmargin}{0.0in}
\setlength{\headheight}{0.0in}
\setlength{\headsep}{0.0in}
\setlength{\leftmargin}{0.0in}
\setlength{\oddsidemargin}{0.0in}
\setlength{\parindent}{0pc}

\begin{document}

\title{Smoothing}
\author{Alex Zhu}
\date{KSA Math Olympiad Training 2013}

\maketitle

\section{Useful Facts}
\begin{enumerate}
  \item \textbf{Jensen's inequality:} Suppose $f$ is a function convex over some interval $I$. Then if $x_1, x_2, \ldots, x_n$ lie in $I$, then \[ \frac{f(x_1) + f(x_2) + \cdots + f(x_n)}{n} \geq f \left( \frac{x_1 + x_2 + \cdots + x_n}{n} \right). \] In other words, if $f$ is convex and $\sum x_i$ is fixed, $\sum f(x_i)$ is minimized when all $x_i$'s are equal.
  \item \textbf{Karamata's inequality:} Suppose $f$ is a convex function over some interval $I$. If $x_1 \geq x_2 \geq \cdots \geq x_n$ and $y_1 \geq y_2 \geq \cdots \geq y_n$ are reals in $I$ such that the sequence $(x_1, x_2, \ldots, x_n)$ majorizes $(y_1, y_2, \ldots, y_n)$, then \[ f(x_1) + f(x_2) + \cdots + f(x_n) \geq f(y_1) + f(y_2) + \cdots + f(y_n). \]
  (The sequence $(x_1, x_2, \ldots, x_n)$ is said to \emph{majorize} $(y_1, y_2, \ldots, y_n)$ if $x_1 + x_2 + \cdots + x_n = y_1 + y_2 + \cdots + y_n$, and $x_1 + x_2 + \cdots + x_k \geq y_1 + y_2 + \cdots + y_k$ for $1 \leq k \leq n-1$.)
  \item \textbf{Convex maxima:} If $f$ is a convex function over an interval $I$, then the maximum of $f$ is attained at an endpoint of $I$.
\end{enumerate}

\section{Common Techniques}
\begin{itemize}
  \item \textbf{Tangent line approximation:} If we are trying to minimize the sum $f(x_1) + f(x_2) + \cdots + f(x_n)$ given that $x_1 + x_2 + \cdots + x_n = S$, it can be helpful to compare $f$ with the linear function $ax + b$ that is tangent to $f$ at $\frac{S}{n}$.
  \item \textbf{Ad hoc comparisons:} Suppose $f$ is a function. The crux of smoothing is that pushing variables $x$ and $y$ together or apart can guarantee $f(x) + f(y)$ to increase or decrease. Knowing whether $f$ is convex can significantly facilitate smoothing, but analyzing the change of $f(x) + f(y)$ is possible even when, say, $x$ lies in a concave region of $f$ while $y$ lies in a convex region. In such a case, an ad hoc algebraic comparison could be used instead.
  \item \textbf{Introducing a constraint:} Sometimes, adding a constraint to a homogeneous inequality makes it equivalent to minimizing $\sum f(x_i)$ for some function $f$, making it susceptible to the smoothing methods.
  \item \textbf{Variable substitution:} Smoothing works best when the variables have a fixed sum. If the variables satisfy some other sort of constraint, it can be helpful to perform a variable substitution such that the new variables have a fixed sum. For example, if we have variables $a,b,c$ subject to $abc = 1$, then if we perform the substitution $a = e^x, b = e^y, c = e^z$, our new constraint becomes $x+y+z=0$.
\end{itemize}

\section{Problems}

\begin{enumerate}
  \item (Nesbitt) Show that if $a,b$, and $c$ are positive real numbers, then \[ \frac{a}{b+c} + \frac{b}{a+c} + \frac{c}{a+b} \geq \frac{3}{2}. \]

  \item If $x,y$, and $z$ are positive real numbers satisfying $x + y + z = xyz$, show that \[ \sqrt{1+x^2} + \sqrt{1+y^2} + \sqrt{1+z^2} \geq 6. \]

  \item (USAMO 1980) Prove that for real numbers $a,b,c$ in the interval $[0,1]$, \[ \frac{a}{b+c+1}+\frac{b}{c+a+1}+\frac{c}{a+b+1}+(1-a)(1-b)(1-c) \le 1. \]

  \item (USAMO 1977) If $ a,b,c,d,e$ are positive numbers bounded by $ p$ and $ q$, i.e, if they lie in $ [p,q], 0 < p$, prove that
\[ (a + b + c + d + e)\left(\frac {1}{a} + \frac {1}{b} + \frac {1}{c} + \frac {1}{d} + \frac {1}{e}\right) \le 25 + 6\left(\sqrt {\frac {p}{q}} - \sqrt {\frac {q}{p}}\right)^2\]
and determine when there is equality.

  \item (USAMO 1999) Let $a_{1}, a_{2}, \dots, a_{n}$ ($n > 3$) be real numbers such that \[ a_{1} + a_{2} + \cdots + a_{n} \geq n \qquad \mbox{and} \qquad a_{1}^{2} + a_{2}^{2} + \cdots + a_{n}^{2} \geq n^{2}.  \] Prove that $\max(a_{1}, a_{2}, \dots, a_{n}) \geq 2$.

  \item (USAMO 2003) Let $ a$, $ b$, $ c$ be positive real numbers. Prove that
\[ \dfrac{(2a + b + c)^2}{2a^2 + (b + c)^2} + \dfrac{(2b + c + a)^2}{2b^2 + (c + a)^2} + \dfrac{(2c + a + b)^2}{2c^2 + (a + b)^2} \le 8. \]

  \item (Poland 1996) Suppose $x,y,z$ are real numbers such that $x + y + z = 1$ and $x,y,z > -\frac{3}{4}$. Prove that \[ \frac{x}{1+x^2} + \frac{y}{1+y^2} + \frac{z}{1+z^2} \leq \frac{9}{10}. \]

  \item (2009 ISL) Let $a,b,c$ be positive real numbers such that $\frac{1}{a} + \frac{1}{b} + \frac{1}{c} = a + b + c$. Prove that: \[ \frac{1}{(2a+b+c)^2} + \frac{1}{(a+2b+c)^2} + \frac{1}{(a+b+2c)^2} \leq \frac{3}{16}. \]

  \item (Romania 99) Show that for all positive reals $x_1, x_2, \ldots, x_n$ with $x_1 x_2 \cdots x_n = 1$, we have \[ \frac{1}{n-1 + x_1} + \cdots + \frac{1}{n - 1 + x_n} \leq 1. \]

  \item (Japan 1997) Show that for all positive reals $a,b,c$,
  \[ \frac{(a+b-c)^2}{(a+b)^2+c^2} + \frac{(b+c-a)^2}{(b+c)^2 + a^2} + \frac{(c+a-b)^2}{(c+a)^2 + b^2} \geq \frac{3}{5}. \]

  \item Show that if $r > 1$ and $x_1, x_2, \ldots, x_n$ are $n$ positive real numbers such that $x_1 x_2 \cdots x_n = 1$, then
  \[ x_1^r + x_2^r + \cdots + x_n^r \geq x_1 + x_2 + \cdots + x_n. \]

  \item (USAMO 1998) Let $a_0,a_1,\cdots ,a_n$ be numbers from the interval $(0,\pi/2)$ such that \[ \tan (a_0-\frac{\pi}{4})+ \tan (a_1-\frac{\pi}{4})+\cdots +\tan (a_n-\frac{\pi}{4})\geq n-1.  \] Prove that \[ \tan a_0\tan a_1 \cdots \tan a_n \geq n^{n+1}.  \]

  \item The numbers $x_1, x_2, \ldots, x_n$ obey $-1 \leq x_1, x_2, \ldots, x_n \leq 1$ and $x_1^3 + x_2^3 + \cdots + x_n^3 = 0$. Prove that \[ x_1 + x_2 + \cdots + x_n \leq \frac{n}{3}. \]

  \item Let $\, a_1, a_2, a_3, \ldots \,$ be a sequence of positive real numbers satisfying $\, \sum_{j=1}^n a_j \geq \sqrt{n} \,$ for all $\, n \geq 1$. Prove that, for all $\, n \geq 1, \,$  \[ \sum_{j=1}^n a_j^2 > \frac{1}{4} \left( 1 + \frac{1}{2} + \cdots + \frac{1}{n} \right).  \]

  \item Let $a_1, a_2, \ldots, a_n$ be distinct positive integers such that each subset of $\{a_1, a_2, \ldots, a_n\}$ has a different sum. Prove that \[ \frac{1}{a_1} + \frac{1}{a_2} +  \cdots + \frac{1}{a_n} < 2. \]

  \item (USA TST 2007) Let $ n$ be a positive integer and let $ a_1 \leq a_2 \leq \cdots \leq a_n$ and $ b_1 \leq b_2 \leq \cdots \leq b_n$ be two nondecreasing sequences of real numbers such that
\[ a_1 + \cdots + a_i \leq b_1 + \cdots + b_i \text{ for every } i = 1,\ldots,n - 1 \]
and
\[ a_1 + \cdots + a_n = b_1 + \cdots + b_n. \]
Suppose that for any real number $ m$, the number of pairs $ (i,j)$ with $ a_i - a_j = m$ equals to the number of pairs $ (k,l)$ with $ b_k - b_l = m$. Prove that $ a_i = b_i$ for $ i = 1,\ldots,n$.

% \item (Erdos?) Define $\{u_i\}_{i\ge1}$ by $u_1=2$, $u_{i+1} = u_i^2 - u_i + 1$ for $i\ge1$. If $n$ is a positive integer and $a_1,a_2,\ldots,a_n$ is a sequence of numbers with $\frac{1}{a_1}+\cdots+\frac{1}{a_n}<1$, show that $\frac{1}{a_1}+\cdots+\frac{1}{a_n} \le \frac{1}{u_1}+\cdots+\frac{1}{u_n}$.

% \item (Romania TST) Let $z_1,z_2,\ldots,z_n$ be $n$ complex numbers in a closed disk $D$. Prove that there exists $z\in D$ satisfying $z^n = z_1z_2\cdots z_n$.

\end{enumerate}
\end{document}

1) smoothing operation
2) majorization
  - proof for n=2,3
  - proof for general n
3) corollary: karamata
corollaries of those:
  - weighted jensen
  - max/min of convex/concave are at endpoints
  - inflection point theorem