\section*{New Clock Stability Application}

\gpstkapp{Clock Tools}, a recent addition to the GPSTk, allows for
basic clock stability analyses.  \gpstkapp{Clock Tools} implement
clock time-domain frequency stability metrics as well as data editing,
noise identification, and plotting routines.  The \gpstkapp{Clock
  Tools} are interoperable with other GPSTk programs, allowing clock
analyses to be easily run alongside other GPS analyses.

Given RINEX GPS observation and navigation files, clock estimates may
be generated using the GPSTk \gpstkapp{Observed Range Deviation (ORD) Tools}.
Kalman filter and time interval analyzer data-sets provide another
source of clock data.  For instance, the TSC 5110A Time Interval
Analyzer (TIA) compares two input clocks and outputs the phase
difference between them at a 10- to 100-Hz sampling rate.  These clock
estimates are used for time-domain frequency stability analysis.

Frequency stability measures the ability of a clock to maintain its nominal frequency over a given period of time.  From input clock data, both short-term and long-term stability can be assessed.  The Allan variance represents the variance of a clock from its nominal value over a range of averaging times.  The Allan variance is an IEEE standard for stability analysis~\cite{ieee1139}.  An Allan variance plot is often helpful in stability analysis.

The \gpstkapp{Clock Tools} suite currently computes the Allan, overlapping Allan, modified Allan, total Allan, overlapping Hadamard, and dynamic Allan deviation stability metrics.  These \gpstkapp{Clock Tools} may be run from the command line with their output piped to other GPSTk programs.  Data formatting and outlier removal routines for GPS and time interval analyzer data-sets facilitate compatibility with the \gpstkapp{Clock Tools} stability programs.

\subsection*{Design}

The \gpstkapp{Clock Tools} applications are encapsulated, so that the output of
one tool acts as the input to the next.  By using redirection and
piping the user is able to connect the \gpstkapp{Clock Tools} together in a way
that allows for flexibility in analysis and ease of use.

Routines within the \gpstkapp{Clock Tools} suite fall into four functional categories: input parsing, data grooming, data analysis, and plotting.  Input parsing takes data generated outside of \gpstkapp{Clock Tools} and puts it in a format understood within the suite.  Data grooming cleans the data of outliers before analysis.  Data analysis performs the frequency stability calculations.  Plotting creates a graphical representation of the frequency stability.

\subsection*{Implementation}

As mentioned, \gpstkapp{Clock Tools} has four functional categories: input
parsing, data grooming, data analysis, and plotting.
Table~\ref{table:clockapps} presents a description and example use of
each tool.  Note that \gpstkapp{ordClock} makes an estimate of the receiver’s
clock offset by averaging the ORDs of all the GPS satellites at each
epoch.  An epoch is an instant in time in which GPS data is recorded.
%
\begin{table*}
\centering
\caption{Description and example invocations of \gpstkapp{Clock Tools}.}
\label{table:clockapps}
\begin{tabular}{lll} \hline \hline
\emph{Tool} & \emph{Description} & \emph{Example} \\ \hline
\gpstkapp{ORDPhaseParser} & Parses data generated by the \gpstkapp{ORD Tools} & \gpstkcommand{ordGen –o input.o –e input.n | } \\
 & &\gpstkcommand{ordClock|ORDPhaseParser>parsed.dat} \\ \hline
\gpstkapp{TIAPhaseParser} & Parses data generated by the & \gpstkcommand{TIAPhaseParser < raw.dat > parsed.dat} \\
   &  TSC 5110A Timing Interval Analyzer. & \\ \hline
\gpstkapp{rmoutlier} & Removes outlier data within a set of  data. & \gpstkcommand{rmoutlier < parsed.dat} \\ \hline
\gpstkapp{nallandev} & Computes the Allan deviation. & \gpstkcommand{nallandev < parsed.dat} \\ \hline
\gpstkapp{oallandev} & Computes the overlapping Allan deviation. & \gpstkcommand{oallandev < parsed.dat} \\ \hline
\gpstkapp{mallandev} & Computes the modified Allan deviation. & \gpstkcommand{mallandev < parsed.dat} \\ \hline
\gpstkapp{totvar} & Computes the total Allan deviation. & \gpstkcommand{totvar < parsed.dat} \\ \hline
\gpstkapp{ohadamarddev} & Computes the overlapping Hadamard & \gpstkcommand{ohadamarddev < parsed.dat} \\
& deviation. & \\ \hline
\gpstkapp{dallandev} & Computes the dynamic Allan deviation. & \gpstkcommand{dallandev < parsed.dat} \\ \hline
\gpstkapp{allanplot} & Plots the output of \gpstkapp{nallandev}, \gpstkapp{oallandev}, & \gpstkcommand{nallandev < parsed.dat | allanplot} \\
& \gpstkapp{ohadamarddev}, \gpstkapp{totvar}, and \gpstkapp{mallandev}. & \\ \hline
\gpstkapp{ddevplot.m} & Plots the output of dallandev. & \gpstkcommand{octave ddevplot.m} \\ \hline \hline
\end{tabular}
\end{table*}
%
The input parsers are the classes \gpstkapp{ORDPhaseParser} and
\gpstkapp{TIAPhaseParser}.  The data grooming tool is
\gpstkapp{rmoutlier}.  The data analysis tools are
\gpstkapp{nallandev}, \gpstkapp{oallandev}, \gpstkapp{mallandev},
\gpstkapp{totvar}, \gpstkapp{ohadamarddev}, and \gpstkapp{dallandev}.
The plotting scripts are \gpstkapp{allanplot} and
\gpstkapp{ddevplot.m}.  Data flows from the parsers to data grooming
to data analysis and finally to plotting.

\subsection*{Example Usage and Plots}

Two example command lines are given below.  The first command
generates clock estimates using the GPSTk ORD tools (\gpstkapp{ordGen} and
\gpstkapp{ordClock}), parses the data (\gpstkapp{ORDPhaseParser}), then removes outliers
(\gpstkapp{rmoutlier}), computes the overlapping Allan deviation (\gpstkapp{oallandev}), and
finally writes the data to a file (\gpstkcommand{output.oadev}).  The second example
takes data in from a file produced by the Timing Interval Analyzer
(\gpstkcommand{raw.dat}), parses the data (\gpstkapp{TIAPhaseParser)}, computes the overlapping
Hadamard variance (\gpstkcommand{ohadamard}), and plots the output (\gpstkcommand{allanplot}).
%
\begin{scriptsize}
\begin{lstlisting}
ordGen –o input.o –e input.n | ordClock
| ORDPhaseParser | rmoutlier |
oallandev > output.oadev

raw.dat | TIAPhaseParser |
ohadamard | allanplot
\end{lstlisting}
\end{scriptsize}
%
Another example is shown below.  This example is an analysis performed on a reference station that is part of the NGA GPS Monitor Station Network (MSN).

This analysis compares the results of running an overlapping Allan
deviation calculation on data generated by \gpstkapp{ordClock} from
unsmoothed raw RINEX files versus data output by the NGA Kalman
filter. The \gpstkapp{ordClock} and Kalman filter data sets cover
different time periods, but both data sets are good representatives of
nominal MSN data. The overlapping Allan deviation of the \gpstkapp{ordClock}
generated data is represented by the blue line.  The overlapping Allan
deviation of the Kalman filter generated data is represented by the
green line.  The lighter slanted red line shows the 5071A CFS
time-domain stability specification.  The darker red line along the
bottom represents the cesium’s flicker floor.  Note that drift removal
may be necessary depending on the input dataset and the deviation
computation performed.
%
\begin{figure*}
  \centering
  \includegraphics[width=5in,bb=65 387 547 727]{clockapps.eps}
  \caption{Frequency Stability of \gpstkapp{ordClock} and Kalman Filter Data}
  \label{fig:clockapps}
\end{figure*}
%
Figure~\ref{fig:clockapps} shows that the frequency stability of the
clock estimates generated by the Kalman filter lies within the CFS
specifications, but that the frequency stability of the output
generated by \gpstkapp{ordClock} from the raw data does not.  Using
raw GPS data and \gpstkapp{ordClock} a stability trend is apparent,
but further filtering and smoothing of the data is necessary to get
more accurate clock stability estimates.


\chapter{Introduction}

The constraints, that we are talking about here, are not like the constraints in classical mechanics. They appear when we try to get from the Lagrange to the Hamilton formalism.
\begin{itemize}
\item $L(q_i,\dot{q}_i)$, \ where $i = 1, ..., n$ degrees of freedom \\
The mechanical properties of a system are completly described by the Lagrangian.
\end{itemize}
We will study constraints from a mathematical point of view, not a physical:
\begin{itemize}
\item Classical mechanics: physical constraints lead to changes in the mathematical description.
\item Now: most general description of Hamiltonian theory. The constraints will follow from the Lagrangian.
\end{itemize}

Why do we need the Hamilton formalism? \\
The most important fact is that a Hamiltonian system (described by coordinates $q_i$ and momenta $p_i$) can be quantized in a canonical way:
\begin{align}
L(q_i,\dot{q}_i) \ \longrightarrow \ H(q_i,p_i) \ \longrightarrow \ H(\hat{q}_i,\hat{p}_i) .
\end{align}
Nowadays, there are of course other methods of quantization, like the Feynman path integral, but we won't focus on quantization here. For us, it is important to know what happens when we try to get from the Lagrangian to the Hamiltonian. \\

How does it work?
\begin{enumerate}
\item Calculate the generalized momenta
\begin{align}\label{eq:momentum}
q_i \ \longrightarrow \ p_i \equiv \frac{\partial L(q_i,\dot{q}_i)}{\partial \dot{q}_i}.
\end{align}
This step is always possible, it results in $p_i(q_i,\dot{q}_i)$.
\item Build the Hamiltonian
\begin{align}\label{eq:hamilton}
H(q_i,p_i) = \sum_{i = 1}^n p_i \dot{q}_i - L(q_i,\dot{q}_i).
\end{align}
The expression on the right side still contains the velocities $\dot{q}_i$, so we have to express them through the generalized coordinates and momenta, by inverting \eqref{eq:momentum}
\begin{align}
p_i(q_i,\dot{q}_i) \longrightarrow \dot{q}_i = \dot{q}_i(q_i,p_i),
\end{align}
and insert in the equation \eqref{eq:hamilton}. Sometimes (if the Lagrangian is degenerate), this step is not possible. We will investigate, what to do in this cases.
\end{enumerate}

We will start with discrete and finite dimensional systems and then move on to continuous systems by introducing field theoretical aspects.


\documentclass[preprint]{sigplanconf}

\usepackage{graphicx}
\usepackage{comment}
\usepackage{amsmath}
\usepackage{xspace}
\usepackage{amssymb}
\usepackage{stmaryrd}
\usepackage{proof}
\usepackage{multicol}
\usepackage[nodayofweek]{datetime}
\usepackage{etex}
\usepackage[all, cmtip]{xy}
\usepackage{xcolor}
\usepackage{listings}
\usepackage{multicol}
\newcommand\hmmax{0} % default \newcommand\bmmax{0} % default 4
\usepackage{bm}
\usepackage{cmll}

\newcommand{\fname}[1]{\ulcorner #1 \urcorner}
\newcommand{\fconame}[1]{\llcorner #1 \lrcorner}

\newcommand{\xcomment}[2]{\textbf{#1:~\textsl{#2}}}
\newcommand{\amr}[1]{\xcomment{Amr}{#1}}
\newcommand{\roshan}[1]{\xcomment{Roshan}{#1}}

\newcommand{\asterix}[0]{*}

\newcommand{\ie}{\textit{i.e.}\xspace}
\newcommand{\eg}{\textit{e.g.}\xspace}

\newcommand{\lcal}{\ensuremath{\lambda}-calculus\xspace}
\newcommand{\G}{\ensuremath{\mathcal{G}}\xspace}

\newcommand{\code}[1]{\lstinline[basicstyle=\small]{#1}\xspace}
\newcommand{\name}[1]{\code{#1}}

\def\newblock{}

\newenvironment{floatrule}
    {\hrule width \hsize height .33pt \vspace{.5pc}}
    {\par\addvspace{.5pc}}

\newtheorem{theorem}{Theorem}[section]
\newtheorem{lemma}[theorem]{Lemma}
\newtheorem{definition}[theorem]{Definition}
\newtheorem{proposition}[theorem]{Proposition}
\newenvironment{proof}[1][Proof.]{\begin{trivlist}\item[\hskip \labelsep {\bfseries #1}]}{\end{trivlist}}

\newcommand{\arrow}[1]{\mathtt{#1}}

\newcommand{\dgm}[2][0.95]{
\begin{center}
\scalebox{#1}{
\includegraphics{diagrams/#2.pdf}
}
\end{center}
}

%subcode-inline{bnf-inline} name langRev
%! swap+ = \mathit{swap}^+
%! swap* = \mathit{swap}^*
%! dagger =  ^{\dagger}
%! assocl+ = \mathit{assocl}^+
%! assocr+ = \mathit{assocr}^+
%! assocl* = \mathit{assocl}^*
%! assocr* = \mathit{assocr}^*
%! identr* = \mathit{uniti}
%! identl* = \mathit{unite}
%! dist = \mathit{distrib}
%! factor = \mathit{factor}
%! eta = \eta
%! eps = \epsilon
%! eta+ = \eta^+
%! eps+ = \epsilon^+
%! eta* = \eta^{\times}
%! eps* = \epsilon^{\times}
%! trace+ = trace^+
%! trace* = trace^{\times}
%! ^^^ = ^{-1}
%! (o) = \circ
%! (;) = \fatsemi
%! (*) = \times
%! (+) = +
%! LeftP = L^+
%! RightP = R^+
%! LeftT = L^{\times}
%! RightT = R^{\times}
%! alpha = \alpha
%! bool = \textit{bool}
%! color = \textit{color}
%! Gr = G

%subcode-inline{bnf-inline} regex \{\{(((\}[^\}])|[^\}])*)\}\} name main include langRev
%! Gx = \Gamma^{\times}
%! G = \Gamma
%! [] = \Box
%! |-->* = \mapsto^{\asterix}
%! |-->> = \mapsto_{\ggg}
%! |--> = \mapsto
%! <--| = \mapsfrom
%! |- = \vdash
%! <><> = \approx
%! ==> = \Longrightarrow
%! <== = \Longleftarrow
%! <=> = \Longleftrightarrow
%! <-> = \leftrightarrow
%! ~> = \leadsto
%! -o+ = \multimap^{+}
%! -o* = \multimap^{\times}
%! -o = \multimap
%! ::= = &::=&
%! /= = \neq
%! @@ = \mu
%! [^ = \lceil
%! ^] = \rceil
%! forall = \forall
%! exists = \exists
%! empty = \epsilon
%! Pi = \Pi
%! Pi0 = \Pi^{o}
%! PiEE* = \Pi^{\eta\epsilon}_{*}
%! PiEE+ = \Pi^{\eta\epsilon}_{+}
%! PiEE = \Pi^{\eta\epsilon}
%! CatSet = \textbf{Set}
%! theseus = Theseus
%! sqrt(x) = \sqrt{#x}
%! surd(p,x) = \sqrt[#p]{#x}
%! inv(x) = \frac{1}{#x}
%! frac(x,y) = \frac{#x}{#y}
%! * = \times

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}

\conferenceinfo{POPL'13}{}
\CopyrightYear{}
\copyrightdata{}
\titlebanner{}
\preprintfooter{}

\title{Fractional Types}

\authorinfo{*}{*}{*}
\maketitle

\begin{abstract}

\end{abstract}

\category{D.3.1}{Formal Definitions and Theory}{}
\category{F.3.2}{Semantics of Programming Languages}{}
\category{F.3.3}{Studies of Program Constructs}{Type structure}

\terms
Languages, Theory

\keywords continuations, information flow, linear logic, logic programming,
quantum computing, reversible logic, symmetric monoidal categories, compact
closed categories.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{The Game}

We start with a type {{A}} and build terms of the types {{A}}, {{Id_A}},
{{Id_{Id_a} }}, etc.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Level of Atoms}

We start with the kind {{type}} and terms of kind {{type}}:

%subcode{bnf} include main
% kinds, k ::= type
% value types, b ::= 0 | 1 | b + b | b * b

%subcode{proof} include main
%@  ~
%@@ 0 : type
%
%@  ~
%@@ 1 : type
%
%@  b1 : type
%@  b2 : type
%@@ b1 + b2 : type
%
%@  b1 : type
%@  b2 : type
%@@ b1 * b2 : type

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{ {{Pi}} Combinators}

Now we introduce isomorphisms between terms of kind {{type}}. This is where
the {{Pi}} combinators appear.

%subcode{bnf} include main
% kinds, k ::= type
% value types, b ::= 0 | 1 | b + b | b * b
%
% identity types, t0 ::= Id_k(b1,b2)
% iso ::= zeroe | zeroi
%     &|& swap+ | assocl+ | assocr+
%     &|& identl* | identr*
%     &|& swap* | assocl* | assocr*
%     &|& dist | factor
% comb., c ::= iso | id | sym c | c (;) c | c (+) c | c (*) c

%subcode{proof} include main
%@  b : k
%@@ zeroe : Id_k(0+b,b)
%
%@  b : k
%@@ zeroi : Id_k(b,0+b)
%---
%@  b1 : k
%@  b2 : k
%@@ swap+ : Id_k(b1+b2,b2+b1)
%---
%@  b1 : k
%@  b2 : k
%@  b3 : k
%@@ assocl+ : Id_k(b1+(b2+b3),(b1+b2)+b3)
%---
%@  b1 : k
%@  b2 : k
%@  b3 : k
%@@ assocr+ : Id_k((b1+b2)+b3,b1+(b2+b3))
%---
%@  b : k
%@@ unite : Id_k(1 * b, b)
%
%@  b : k
%@@ uniti : Id_k(b, 1 * b)
%---
%@  b1 : k
%@  b2 : k
%@@ swap* : Id_k(b1 * b2,b2 * b1)
%---
%@  b1 : k
%@  b2 : k
%@  b3 : k
%@@ assocl* : Id_k(b1*(b2*b3),(b1*b2)*b3)
%---
%@  b1 : k
%@  b2 : k
%@  b3 : k
%@@ assocr* : Id_k((b1*b2)*b3,b1*(b2*b3))
%---
%@  b1 : k
%@  b2 : k
%@  b3 : k
%@@ distrib : Id_k((b1+b2)*b3,(b1*b3)+(b2*b3))
%---
%@  b1 : k
%@  b2 : k
%@  b3 : k
%@@ factor : Id_k((b1*b3)+(b2*b3),(b1+b2)*b3)
%---
%@ b : k
%@@ id : Id_k(b,b)
%
%@ c : Id_k(b1,b2)
%@@ sym c : Id_k(b2,b1)
%---
%@ c1 : Id_k(b1,b2)
%@ c2 : Id_k(b2,b3)
%@@ c1(;)c2 : Id_k(b1,b3)
%---
%@ c1 : Id_k(b1,b3)
%@ c2 : Id_k(b2,b4)
%@@ c1(+)c2 : Id_k(b1+b2,b3+b4)
%---
%@ c1 : Id_k(b1,b3)
%@ c2 : Id_k(b2,b4)
%@@ c1(*)c2 : Id_k(b1*b2,b3*b4)

We will give the semantics in an usual style to simplify the presentation of
next section. First we define values and clauses:

%subcode{bnf} include main
% values, v ::= () | left v | right v | (v,v)
% clauses, m ::= (1/v,v)

%subcode{proof} include main
%@  ~
%@@ () : 1
%
%@  v : b1
%@@ left v : b1 + b2
%
%@  v : b2
%@@ right v : b1 + b2
%---
%@  v1 : b1
%@  v2 : b2
%@@ (v1,v2) : b1 * b2

The intuition behind clauses is the following: if applying
{{c : Id_k(b1,b2)}} to {{v1 : b1}} yields {{v2 : b2}}, we say that
the clause {{ (1/v1, v2) }} has type {{c}}.

%subcode{proof} include main
%@ zeroe : Id_k(0+b,b)
%@ v : b
%@@ (1/right v, v) : zeroe
%
%@ zeroi : Id_k(b,0+b)
%@ v : b
%@@ (1/v, right v) : zeroi
%---
%@ swap+ : Id_k(b1+b2,b2+b1)
%@ v : b1
%@@ (1/left v, right v) : swap+
%---
%@ swap+ : Id_k(b1+b2,b2+b1)
%@ v : b2
%@@ (1/right v, left v) : swap+
%---
%@ assocl+ : Id_k(b1+(b2+b3),(b1+b2)+b3)
%@ v : b1
%@@ (1/ left v, left (left v)) : assocl+
%---
%@ assocl+ : Id_k(b1+(b2+b3),(b1+b2)+b3)
%@ v : b2
%@@ (1/ right (left v), left (right v)) : assocl+
%---
%@ assocl+ : Id_k(b1+(b2+b3),(b1+b2)+b3)
%@ v : b3
%@@ (1/ right (right v), right v) : assocl+
%---
%@ assocr+ : Id_k((b1+b2)+b3,b1+(b2+b3))
%@ v : b1
%@@ (1/ left (left v), left v) : assocr+
%---
%@ assocr+ : Id_k((b1+b2)+b3,b1+(b2+b3))
%@ v : b2
%@@ (1/ left (right v), right (left v)) : assocr+
%---
%@ assocr+ : Id_k((b1+b2)+b3,b1+(b2+b3))
%@ v : b3
%@@ (1/ right v, right (right v)) : assocr+
%---
%@ unite : Id_k(1 * b, b)
%@ v : b
%@@ (1/((),v), v) : unite
%
%@ uniti : Id_k(b, 1 * b)
%@ v : b
%@@ (1/v, ((),v)) : uniti
%---
%@ swap* : Id_k(b1 * b2,b2 * b1)
%@ v1 : b1
%@ v2 : b2
%@@ (1/(v1,v2), (v2,v1)) : swap*
%---
%@ assocl* : Id_k(b1*(b2*b3),(b1*b2)*b3)
%@ v1 : b1
%@ v2 : b2
%@ v3 : b3
%@@ (1/(v1,(v2,v3)), ((v1,v2),v3)) : assocl*
%---
%@ assocr* : Id_k((b1*b2)*b3,b1*(b2*b3))
%@ v1 : b1
%@ v2 : b2
%@ v3 : b3
%@@ (1/((v1,v2),v3), (v1,(v2,v3))) : assocr*
%---
%@ distrib : Id_k((b1+b2)*b3,(b1*b3)+(b2*b3))
%@ v1 : b1
%@ v3 : b3
%@@ (1/(left v1,v3), left (v1,v3)) : distrib
%---
%@ distrib : Id_k((b1+b2)*b3,(b1*b3)+(b2*b3))
%@ v2 : b2
%@ v3 : b3
%@@ (1/(right v2,v3), right (v2,v3)) : distrib
%---
%@ factor : Id_k((b1*b3)+(b2*b3),(b1+b2)*b3)
%@ v1 : b1
%@ v3 : b3
%@@ (1/(left (v1,v3)), (left v1,v3)) : factor
%---
%@ factor : Id_k((b1*b3)+(b2*b3),(b1+b2)*b3)
%@ v2 : b2
%@ v3 : b3
%@@ (1/(right (v2,v3)), (right v2,v3)) : factor
%---
%@ id : Id_k(b,b)
%@ v : b
%@@ (1/v,v) : id
%
%@ c : Id_k(b2,b1)
%@ (1/v2, v1) : c
%@@ (1/v1, v2) : sym c
%---
%@ c1 : Id_k(b1,b2)
%@ c2 : Id_k(b2,b3)
%@ (1/v1, v2) : c1
%@ (1/v2, v3) : c2
%@@ (1/v1, v3) : c1 (;) c2
%---
%@ c1 : Id_k(b1,b3)
%@ (1/v1, v3) :: c1
%@@ (1/left v1, left v3) : c1 (+) c2
%
%@ c2 : Id_k(b2,b4)
%@ (1/v2, v4) :: c2
%@@ (1/right v2, right v4) : c1 (+) c2
%---
%@ c1 : Id_k(b1,b3)
%@ c2 : Id_k(b2,b4)
%@ (1/v1, v3) :: c1
%@ (1/v2, v4) :: c2
%@@ (1/(v1,v2), (v3,v4)) : c1 (*) c2

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{ {{Pi}} semantics I}

Now we introduce isomoprhisms between terms of type {{Id_k(b1,b2)}}. This is
where we start reasoning about equivalence of the {{Pi}}-combinators
themselves. For {{c1 : Id_k(b1,b2)}} and {{c2 : Id_k(b1,b2)}}, terms of type
{{Id_{Id_k(b1,b2)}(c1,c2)}} would witness that {{c1}} and {{c2}} are
isomorphic (up to equivalence at the next level).

For example, given the combinator {{uniti}} at type {{bool = 1+1}}:

%subcode{proof} include main
%@ uniti : Id_k(1+1, 1 * (1+1))
%@ v : 1+1
%@@ (1/v, ((),v)) : uniti

when viewed as a type, the elements of {{uniti}} are:
{{ (1/left (), ((), left ())) }}
and
{{ (1/right (), ((), right ())) }}

Using our isomorphisms we can apply {{ id (*) unite }} to the above to
produce
{{ (1/left (), left ()) }}
and
{{ (1/right (), right ()) }}.

In other words, there is an isomorphism {{alpha = id (*) unite}} beween
{{uniti}} and {{id}} at type {{bool}}. We now need to generalize this idea to
the full language. We possibly (probably) need to add the meadow rules so
that we can convert a clause to a regular value, use the isomorphisms on it,
and then translate it back to a clause.

%subcode{bnf} include main
% kinds, k ::= type
% value types, b ::= 0 | 1 | b + b | b * b
%
% identity types, t0 ::= Id_k(b1,b2)
% iso ::= zeroe | zeroi
%     &|& swap+ | assocl+ | assocr+
%     &|& identl* | identr*
%     &|& swap* | assocl* | assocr*
%     &|& dist | factor
% comb., c ::= iso | id | sym c | c (;) c | c (+) c | c (*) c
%
% identity types, t1 ::= Id_{t0}(c1,c2)
% alpha ::= ...

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\end{document}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


\XtoCBlock{Sqrt}
\label{block:Sqrt}
\begin{figure}[H]\includegraphics{Sqrt}\end{figure}

\begin{XtoCtabular}{Inports}
In & Input u\tabularnewline
\hline
\end{XtoCtabular}

\begin{XtoCtabular}{Outports}
Out & Result of sqrt(|u|)\tabularnewline
\hline
\end{XtoCtabular}

\subsubsection*{Description:}
Square root computation of absolute input value.

% include optional documentation file
\InputIfFileExists{\XcHomePath/Library/Math/Doc/Sqrt_Info.tex}{\vspace{1ex}}{}

\subsubsection*{Implementations:}
\begin{tabular}{l l}
\textbf{FiP8} & 8 Bit Fixed Point Implementation\tabularnewline
\textbf{FiP16} & 16 Bit Fixed Point Implementation\tabularnewline
\textbf{FiP32} & 32 Bit Fixed Point Implementation\tabularnewline
\textbf{Float32} & 32 Bit Floating Point Implementation\tabularnewline
\textbf{Float64} & 64 Bit Floating Point Implementation\tabularnewline
\end{tabular}

\XtoCImplementation{FiP8}
\index{Block ID!4816}
\nopagebreak[0]
% Implementation details
\begin{tabular}{l l}
\textbf{Name} & FiP8 \tabularnewline
\textbf{ID} & 4816 \tabularnewline
\textbf{Revision} & 0.1 \tabularnewline
\textbf{C filename} & Sqrt\_FiP8.c \tabularnewline
\textbf{H filename} & Sqrt\_FiP8.h \tabularnewline
\end{tabular}
\vspace{1ex}

8 Bit Fixed Point Implementation

% Implementation data structure
\XtoCDataStruct{Data Structure:}
\begin{lstlisting}
typedef struct {
     uint16        ID;
     int8          *In;
     int8          Out;
} SQRT_FIP8;
\end{lstlisting}

\ifdefined \AddTestReports
\InputIfFileExists{\XcHomePath/Library/Math/Doc/Test_Sqrt_FiP8.tex}{}{}
\fi
\XtoCImplementation{FiP16}
\index{Block ID!4817}
\nopagebreak[0]
% Implementation details
\begin{tabular}{l l}
\textbf{Name} & FiP16 \tabularnewline
\textbf{ID} & 4817 \tabularnewline
\textbf{Revision} & 0.1 \tabularnewline
\textbf{C filename} & Sqrt\_FiP16.c \tabularnewline
\textbf{H filename} & Sqrt\_FiP16.h \tabularnewline
\end{tabular}
\vspace{1ex}

16 Bit Fixed Point Implementation

% Implementation data structure
\XtoCDataStruct{Data Structure:}
\begin{lstlisting}
typedef struct {
     uint16        ID;
     int16         *In;
     int16         Out;
} SQRT_FIP16;
\end{lstlisting}

\ifdefined \AddTestReports
\InputIfFileExists{\XcHomePath/Library/Math/Doc/Test_Sqrt_FiP16.tex}{}{}
\fi
\XtoCImplementation{FiP32}
\index{Block ID!4818}
\nopagebreak[0]
% Implementation details
\begin{tabular}{l l}
\textbf{Name} & FiP32 \tabularnewline
\textbf{ID} & 4818 \tabularnewline
\textbf{Revision} & 0.1 \tabularnewline
\textbf{C filename} & Sqrt\_FiP32.c \tabularnewline
\textbf{H filename} & Sqrt\_FiP32.h \tabularnewline
\end{tabular}
\vspace{1ex}

32 Bit Fixed Point Implementation

% Implementation data structure
\XtoCDataStruct{Data Structure:}
\begin{lstlisting}
typedef struct {
     uint16        ID;
     int32         *In;
     int32         Out;
} SQRT_FIP32;
\end{lstlisting}

\ifdefined \AddTestReports
\InputIfFileExists{\XcHomePath/Library/Math/Doc/Test_Sqrt_FiP32.tex}{}{}
\fi
\XtoCImplementation{Float32}
\index{Block ID!4819}
\nopagebreak[0]
% Implementation details
\begin{tabular}{l l}
\textbf{Name} & Float32 \tabularnewline
\textbf{ID} & 4819 \tabularnewline
\textbf{Revision} & 0.1 \tabularnewline
\textbf{C filename} & Sqrt\_Float32.c \tabularnewline
\textbf{H filename} & Sqrt\_Float32.h \tabularnewline
\end{tabular}
\vspace{1ex}

32 Bit Floating Point Implementation

% Implementation data structure
\XtoCDataStruct{Data Structure:}
\begin{lstlisting}
typedef struct {
     uint16        ID;
     float32       *In;
     float32       Out;
} SQRT_FLOAT32;
\end{lstlisting}

\ifdefined \AddTestReports
\InputIfFileExists{\XcHomePath/Library/Math/Doc/Test_Sqrt_Float32.tex}{}{}
\fi
\XtoCImplementation{Float64}
\index{Block ID!4820}
\nopagebreak[0]
% Implementation details
\begin{tabular}{l l}
\textbf{Name} & Float64 \tabularnewline
\textbf{ID} & 4820 \tabularnewline
\textbf{Revision} & 0.1 \tabularnewline
\textbf{C filename} & Sqrt\_Float64.c \tabularnewline
\textbf{H filename} & Sqrt\_Float64.h \tabularnewline
\end{tabular}
\vspace{1ex}

64 Bit Floating Point Implementation

% Implementation data structure
\XtoCDataStruct{Data Structure:}
\begin{lstlisting}
typedef struct {
     uint16        ID;
     float64       *In;
     float64       Out;
} SQRT_FLOAT64;
\end{lstlisting}

\ifdefined \AddTestReports
\InputIfFileExists{\XcHomePath/Library/Math/Doc/Test_Sqrt_Float64.tex}{}{}
\fi


\maketitle

\setlength{\epigraphwidth}{0.6\textwidth}
\epigraph{\it Mathematics is a process of staring hard enough with enough perseverance at the fog of muddle and confusion to eventually break through to improved clarity. I’m happy when I can admit, at least to myself, that my thinking is muddled, and I try to overcome the embarrassment that I might reveal ignorance or confusion. }{William Thurston}

\section*{How to use these notes.}
\label{sec:intro}
\addcontentsline{toc}{section}{\nameref{sec:intro}}

Linear algebra is the study of linearity. The main players of this story are the vectors, but instead of studying vectors individually, we study collections of vectors, called {\bf vector spaces}, and maps between vector spaces, called {\bf linear transformations}.

Because linearity is such a simple condition (Section \ref{section:VectorSpaces}), linear algebra is one of the most widely applied branches of mathematics.\\\\

These notes provide a very, very brief introduction to linear algebra.
You'll learn enough to be able to continue the study of the subject on your own.

Each day you will be given a set of problems to solve in class.
You should attempt as many problems as you can, and it is ok to not finish all the problems before the next class.
However, you should make an honest attempt to read and understand the various definitions and theorems.\footnote{These notes are likely to contain \sout{a few} several \sout{typos} mistakes. Please do tell if you find any, thanks in advance.}


\documentclass{sigplanconf}
\usepackage{url}
\usepackage{proof}
\usepackage{amssymb}
\usepackage{stmaryrd}
\usepackage{listings}
\usepackage{graphicx}
\usepackage{comment}

\newcommand{\dgm}[2][1.5]{
\begin{center}
\scalebox{#1}{
\includegraphics{diagrams/#2.pdf}
}
\end{center}
}
\newcommand{\todo}[1]{\textbf{TODO:} #1}
\newcommand{\jacques}[1]{\textsc{Jacques says:} #1}
\newcommand{\amr}[1]{\textsc{Amr says:} #1}

\newtheorem{theorem}{Theorem}[section]
\newtheorem{lemma}[theorem]{Lemma}
\newtheorem{definition}[theorem]{Definition}
\newtheorem{proposition}[theorem]{Proposition}

%subcode-inline{bnf-inline} name Pi
%! swap+ = \mathit{swap}^+
%! swap* = \mathit{swap}^*
%! dagger =  ^{\dagger}
%! assocl+ = \mathit{assocl}^+
%! assocr+ = \mathit{assocr}^+
%! assocl* = \mathit{assocl}^*
%! assocr* = \mathit{assocr}^*
%! identr* = \mathit{uniti}
%! identl* = \mathit{unite}
%! dist = \mathit{distrib}
%! factor = \mathit{factor}
%! (o) = \fatsemi
%! (;) = \fatsemi
%! (*) = \times
%! (+) = +
%! foldB = fold_B
%! unfoldB = unfold_B
%! foldN = fold_N
%! unfoldN = unfold_N
%! trace+ = \mathit{trace}^{+}
%! trace* = \mathit{trace}^{\times}
%! :-* = \multimap
%! :-+ = \multimap^{+}
%! emptyset = \emptyset

%subcode-inline{bnf-inline} regex \{\{(((\}[^\}])|[^\}])*)\}\} name main include Pi
%! [^ = \ulcorner
%! ^] = \urcorner
%! [v = \llcorner
%! v] = \lrcorner
%! [[ = \llbracket
%! ]] = \rrbracket
%! ^^^ = ^{\dagger}
%! eta* = \eta
%! eps* = \epsilon
%! Union = \bigcup
%! in = \in
%! |-->* = \mapsto^{*}
%! |-->> = \mapsto_{\ggg}
%! |-->let = \mapsto_{let}
%! |--> = \mapsto
%! <--| = \mapsfrom
%! |- = \vdash
%! <=> = \Longleftrightarrow
%! <-> = \leftrightarrow
%! -> = \rightarrow
%! ~> = \leadsto
%! ::= = ::=
%! amp = \&
%! /= = \neq
%! vi = v_i
%! di = d_i
%! si = s_i
%! sj = s_j
%! F = \texttt{F}
%! T = \texttt{T}
%! forall = \forall
%! exists = \exists
%! empty = \emptyset
%! Sigma = \Sigma
%! eta = \eta
%! where = \textbf{where}
%! epsilon = \varepsilon
%! least = \phi
%! loop+ = loop_{+}
%! loop* = loop_{\times}
%! CatC = {\mathcal C}
%! CatA = {\mathcal A}
%! gamma = \gamma
%! {[ = \{
%! ]} = \}
%! elem = \in
%! dagger = ^\dagger
%! alpha = \alpha
%! beta = \beta
%! rho = \rho
%! @@ = \mu
%! @ = \,@\,
%! Pow = \mathcal{P}
%! Pi = \Pi
%! PiT = \Pi^{o}
%! PiEE = \Pi^{\eta\epsilon}_{+}
%! PiT = \Pi^{o}
%! PiTF = \Pi^{/}
%! bullet = \bullet
%! * = \times

\begin{document}
\conferenceinfo{POPL '14}{date, City.}
\copyrightyear{2014}
\copyrightdata{[to be supplied]}

\title{\ldots}
\authorinfo{\ldots}
           {\ldots}
           {\ldots}

\maketitle

\begin{abstract}
\ldots
\end{abstract}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Background: {{Pi}} }
\label{sec:pi}

We review our language {{Pi}} providing the necessary background and
context for our higher-order extension.\footnote{The presentation in this
  section focuses on the simplest version of {{Pi}}. Other versions
  include the empty type, recursive types, and trace operators but these
  extensions are orthogonal to the higher-order extension emphasized in this
  paper.} The terms of {{Pi}} are not classical values and functions;
rather, the terms are isomorphism witnesses.  In other words, the terms of
{{Pi}} are proofs that certain ``shapes of values'' are isomorphic.
And, in classical Curry-Howard fashion, our operational semantics shows how
these proofs can be directly interpreted as actions on ordinary values which
effect this shape transformation. Of course, ``shapes of values'' are very
familiar already: they are usually called \emph{types}.  But frequently one
designs a type system as a method of classifying terms, with the eventual
purpose to show that certain properties of well-typed terms hold, such as
safety.  Our approach is different: we start from a type system, and then
present a term language which naturally inhabits these types, along with an
appropriate operational semantics.

\paragraph*{Data.}
We view {{Pi}} as having two levels:  it has traditional values, given by:
%subcode{bnf} include main
% values, v ::= () | left v | right v | (v, v)

\noindent and these are classified by ordinary types:
%subcode{bnf} include main
% value types, b ::= 1 | b + b | b * b

\noindent
Types include the unit type {{1}}, sum types {{b1+b2}}, and product types
{{b1*b2}}.  Values include {{()}} which is the only value of type {{1}},
{{left v}} and {{right v}} which inject~{{v}} into a sum type, and
{{(v1,v2)}} which builds a value of product type.  These values should be
regarded as largely ancillary: we do not treat them as first-class citizens,
and they only occur when observing the effect of an isomorphism.

\paragraph*{Isomorphisms.} The important terms of {{Pi}} are witnesses to
(value) type isomorphisms.  They are also typed, by the shape of the (value)
type isomorphism they witness {{b <-> b}}.  Specifically, they are witnesses
to the following isomorphisms:
%subcode{bnf} include main
%! columnStyle = r@{\hspace{-0.5pt}}r c l@{\hspace{-0.5pt}}l
%swap+ :&  b1 + b2 & <-> & b2 + b1 &: swap+
%assocl+ :&  b1 + (b2 + b3) & <-> & (b1 + b2) + b3 &: assocr+
%identl* :&  1 * b & <-> & b &: identr*
%swap* :&  b1 * b2 & <-> & b2 * b1 &: swap*
%assocl* :&  b1 * (b2 * b3) & <-> & (b1 * b2) * b3 &: assocr*
%dist :&~ (b1 + b2) * b3 & <-> & (b1 * b3) + (b2 * b3)~ &: factor

\noindent Each line of the above table introduces a pair of dual
constants\footnote{where {{swap*}} and {{swap+}} are self-dual.} that witness
the type isomorphism in the middle.  These are the base (non-reducible) terms
of the second, principal level of {{Pi}}. Note how the above has two
readings: first as a set of typing relations for a set of constants. Second,
if these axioms are seen as universally quantified, orientable statements,
they also induce transformations of the (traditional) values. The
(categorical) intuition here is that these axioms have computational content
because they witness isomorphisms rather than merely stating an extensional
equality.

The isomorphisms are extended to form a congruence relation by adding the
following constructors that witness equivalence and compatible closure:

%subcode{proof} include main
%@  ~
%@@ id : b <-> b
%
%@ c : b1 <-> b2
%@@ sym c : b2 <-> b1
%
%@ c1 : b1 <-> b2
%@ c2 : b2 <-> b3
%@@ c1(;)c2 : b1 <-> b3
%---
%@ c1 : b1 <-> b3
%@ c2 : b2 <-> b4
%@@ c1 (+) c2 : b1 + b2 <-> b3 + b4
%
%@ c1 : b1 <-> b3
%@ c2 : b2 <-> b4
%@@ c1 (*) c2 : b1 * b2 <-> b3 * b4
\noindent The syntax is overloaded: we use the same symbol at the value-type level
and at the isomorphism-type level for denoting sums and products.  Hopefully
this will not cause undue confusion.

It is important to note that ``values'' and ``isomorphisms'' are completely
separate syntactic categories which do not intermix. The semantics of the
language come when these are made to interact at the ``top level'' via
\emph{application}:
%subcode{bnf} include main
% top level term, l ::= c v

\noindent
To summarize, the syntax of {{Pi}} is given as follows.

\begin{definition}{(Syntax of {{Pi}})}
\label{def:Pi}
%subcode{bnf} include main
% value types, b ::= 1 | b+b | b*b
% values, v ::= () | left v | right v | (v,v)
%
% iso.~types, t ::= b <-> b
% base iso ::= swap+ | assocl+ | assocr+
%     &|& unite | uniti | swap* | assocl* | assocr*
%     &|& dist | factor
% iso comb., c ::= iso | id | sym c | c (;) c | c (+) c | c (*) c
% top level term, l ::= c v
\end{definition}

The language presented above, at the type level, models a commutative ringoid
where the multiplicative structure forms a commutative monoid, but the
additive structure is just a commutative semigroup.  Note that the version of
{{Pi}} that includes the empty type with its usual laws exactly captures, at
the type level, the notion of a \emph{semiring} (occasionally called a
\emph{rig}) where we replace equality by isomorphism.  Semantically, {{Pi}}
models a \emph{bimonoidal category} whose simplest example is the category of
finite sets and bijections. In that interpretation, each value type denotes a
finite set of a size calculated by viewing the types as natural numbers and
each combinator {{c : b1 <-> b2}} denotes a bijection between the sets
denoted by~{{b1}} and~{{b2}}.

Operationally, the semantics of {{Pi}} is given using two mutually recursive
interpreters: one going forward and one going backwards. The use of {{sym}}
switches control from one evaluator to the other. We will present the
operational semantics in the next section along with the extension with
fractional types and values. For now, we state without proof that the
evaluation of well-typed combinators always terminates and that {{Pi}} is
logically reversible, i.e., that for all combinators {{c : b1 <-> b2}} and
values {{v1 : b1}} and {{v2 : b2}} we have the forward evaluation of {{c v1}}
produces {{v2}} iff the backwards evaluation of {{c v2}} produces {{v1}}.

As is usual with type theories, the coherence conditions (pentagonal and
triangle identity) are not explicit, but would correspond to certain identity
types being trivial.

\section{ {{Pi}} with trace}

In order to take a step toward being able to write the Int construction in
{{Pi}} to give it fractional types, we want to add a trace combinator to it,
with the following type:

%subcode{proof} include main
%@  c : b1 * b <-> b2 * b
%@@ trace c : b1 <-> b2

This kind of combinator allows us to cancel out a common factor. When the type
{{0}} is removed from the language, it is always possible to do this, but adding
computational content becomes tricky. For example, consider permutations on the
finite set of size {{6}}. If we wish to trace one of these to get a permutation
on the set of size {{3}}, we are able to, but which set of size {{3}}? There
are several different ways to do this, but there is no obvious canonical answer.

More concretely, suppose we have a combinator {{c : 3 * 2 <-> 3 * 2}}. The
combinator {{trace c : 3 <-> 3}} can be constructed in two obvious ways: let
{{(trace c) v}} run {{c}} on {{(v, true)}} or on {{(v, false)}}. It is possible
to choose {{c}} so that depending on which default value of type {{2}} is used,
a different combinator results.

To fix this, we parameterize {{trace}} with a value {{v : b}}, as follows:

%subcode{proof} include main
%@  c : b1 * b <-> b2 * b
%@  v : b
%@@ trace_v c : b1 <-> b2

It remains to show that this is ``well-behaved''; that is, we want it to obey
some (ideally all) of the trace properties, or at the very least some subset of
them that is sufficient to prove some necessary properties for {{Pi}} extended
with fractional types, as presented in the next few sections.

\subsection{Alternatives}

If this formulation of trace does not work, we have a few alternatives:

\begin{itemize}

\item Don't bother choosing a default element at all. We did this previously
with the relational semantics, without much success, but perhaps there's a
better way of looking at it.

\item Choose a canonical representative of the type {{b}} that's being traced
out. This seems like it's a strictly worse option than parameterizing it, but
it's still on the table, at least for now.

\item Focus on the combinator. Jacques pointed out that our old version of trace
``worked'' whenever the part of {{c}} acting on {{b}} was equivalent to the
identity. This seems promising, but I'm not quite sure how to think about it
yet, so I'm ignoring it for now. It's definitely something we want to look at,
though, especialy if the current approach doesn't work.

\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Syntax of Fractionals}

The types of {{Pi}} correspond to the natural numbers. Our goal is to have a
type system that corresponds to the (positive) rational numbers.

\begin{definition}{(Syntax of {{PiTF}})}
\label{def:PiTF}
%subcode{bnf} include main
% value types, r ::= b1 / b2
% values, f ::= (v1 |--> v2, c)
%
% iso.~types, t ::= r <=> r
% base iso ::= swap+ | assocl+ | assocr+
%     &|& unite | uniti | swap* | assocl* | assocr*
%     &|& dist | factor
%     &|& eta | epsilon
% iso comb., c ::= iso | id | sym c | c (;) c | c (+) c | c (*) c
% top level term, l ::= c v
\end{definition}

If we restrict our attention to types {{b / 1}} and values {{ () |--> v amp id}},
we recover {{Pi}}.

In algebra, the rational number {{a/b}} denotes
$\{ (a','b) ~|~ a * b' = a' * b \}$. We essentially use the same denotation but
add computational content, i.e., the type {{a/b}} denotes
$\{ (a',b',c) ~|~ c : a * b' \leftrightarrow a' * b \}$ where $c$ is a {{Pi}}
combinator witnessing the equivalence of {{a * b'}} and {{a' * b}}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Higher-Order Reversible Functions}

To get from {{Pi}}~\cite{James:2012:IE:2103656.2103667} types and combinators
to a higher order setting, we hope to add \emph{fractional types} to the
language. Recall that to construct the (positive) rational numbers {{Q}}, we
can take pairs of positive integers {{(m, n)}} and quotient by the
equivalence relation that says {{(m1, n1)}} is equal to {{(m2, n2)}} if
{{m1 * n2 = m2 * n1}}. We can write this as an inference rule as follows:

%subcode{proof} include main
%@ m1 * n2 = m2 * n1
%@@ (m1, n1) = (m2, n2)

\noindent
Adding in computational content, pi-style, suggests that we want something like:

%subcode{proof} include main
%@ c : A1 * B2 <-> B1 * A2
%@@ {[c]} : (B1 |--> A1) <=> (B2 |--> A2)

\noindent
However, this does not quite work. To see why, recall that we want to treat the
pair {{(m, n)}} (written here as {{A |--> B}}) as an internalization of the
reversible function space. Thus, the type {{(B1 |--> A1) <=> (B2 |--> A2)}}
should be a transformation of a {{Pi}} combinator of type {{B1 <-> A1}} into a
{{Pi}} combinator of type {{B2 <-> A2}}. In order to do this, we need a trace
combinator (TODO: draw a diagram that demonstrates this) with the type

%subcode{proof} include main
%@ c : A * C <-> B * C
%@@ trace c : A <-> B

\noindent
This is an issue, since prior attempts at defining an adequate trace operator
failed: we got a language that could express all relations, but was no longer
reversible in a meaningful sense.

%%%%%%%%%%%%%%%%%%%
\subsection{Defining trace}

The trace operator had two problems: it allowed arbitrary function definition,
and it would not work in a language that contained the empty type {{0}}. The
former problem arose due to the logic programming-style interpretation we
assigned to trace: it would create *all* possible values of type {{C}}, then run
the given combinator on them and throw away the branches that did not return the
same {{C}} value.

We can solve this problem by parameterizing the trace operator with a value {{v
: C}}. This results in the following new typing rule for trace:

%subcode{proof} include main
%@ c : A * C <-> B * C
%@ v : C
%@@ trace_v c : A <-> B

\noindent
This ends up solving both problems: we give the trace a default value, and
prevent it from running on the empty type (since {{C}} now must be inhabited).
However, we still must assign dynamic semantics to trace. The na\"ive solution
of running {{c}} on the pair of the input value and {{v}} does not work, as this
is trivially irreversible---consider, for example, {{trace_v swap*}}, which
takes any value of the same type as {{v}} and returns {{v}}. Thus, the semantics
for {{trace}} must be slightly more complicated.

Recall that in {{Pi}}, combinators can be viewed as permutations on finite sets.
A combinator of type {{A * C <-> B * C}} can be seen as two separate
permutations: one on {{A}} (or equivalently, B, since they must have the same
size and thus the same denotation as a finite set) and one on {{C}}. If we
apply the fragment of the combinator that acts on {{C}} enough times, we will
eventually get out the same value that we started with\footnote{I want to prove
that this is actually true; having the extra {{A}} there seems like it might
complicate things.}. Thus, the semantics that we want is for {{(trace_v c) v'}}
to run {{c}} on the pair of {{v'}} and the last {{C}} value (starting with
{{v}}) until the {{C}} value matches {{v}}, at which point it returns the {{B}}
value returned by the combinator. In pseudocode:

\begin{verbatim}
TODO: figure out how to do the code
environment in subcode

trace v c vin =
  v0 = v
  <vout, v'> = c <vin, v>

  while (v' != v)
    <vout, v'> := c <vin, v'>

  return vout
\end{verbatim}

A more concise formulation as an inference rule is as follows:

%subcode{proof} include main
%@ exists v0 : C. c <v_{in}, v> = <v_{out}, v>
%@@ (trace_v c) v_{in} = v_{out}

This is easily reversible: {{(trace_v c)dagger = trace_v (c dagger)}}
\footnote{Also need to prove this.}.

%%%%%%%%%%%%%%%%%%%
\subsection{Higher-Order Combinators}

Now that we have the trace combinator defined, we can proceed with defining
higher-order combinators. Note that this parameterizes our definition of
$\{c\}$ by {{v}}, the value of type {{A}} (or equivalently, type {{B}}) used
in the trace:

%subcode{proof} include main
%@ c : A1 * B2 <-> B1 * A2
%@@ {[c]}_v : (B1 |--> A1) <=> (B2 |--> A2)

\noindent
We want this to be a transformation on combinators, taking a combinator of type
{{B1 <-> A1}} to a combinator of type {{B2 <-> A2}}. This can be achieved by
letting the combinator {{{[c]}_v c'}} be {{trace_v (c ; c' * id)}}, where
{{c : B1 <-> A1}} and {{v : A1}}.

From here, we want to define bifunctors {{/}}, {{*}}, and {{+}}, to make sure
that our definition of functions is truly higher-order.

\begin{itemize}

\item {{(B |--> A) / (D |--> C) = (A * D) |--> (B * C)}}, with

{{{[c1]}_{v1} : ((B |--> A) <=> (D |--> C)) / {[c2]}_{v_2} : ((B' |--> A') <=> (D' |--> C')) = {[shuffle ; c1 * c2dagger ; shuffle]}_{<v1, c2 v2>}}}
%%: B1 * A2 |--> A1 * B2 <=> D1 * C2 |--> C1 * D2}},
where
{{shuffle : (A * B) * (C * D) <-> (A * C) * (B * D)}}.

\item {{(B |--> A) * (D |--> C) = (B * D) |--> (A * C)}}, with

\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\bibliographystyle{abbrvnat}
\bibliography{cites}
\end{document}


\section{Reduced formulation to local variables.}

\subsection{Formulation}

Let us start with
\begin{equation}
  \label{eq:AC-L7}
  \begin{array}{l}
  \varPhi_1(U,P) =  - U_{k+1}  + \widehat W P_{k+1}  + U_{\mathrm{free}}\\ \\
  \varPhi_2(U,P) =  P_{\n} - \proj_{\nbR^{a}_+} (P_{\n} - \rho_{\n}\circ (U_{\n} +e \circ  U_{\n,k}) ) \\ \\
  \varPhi_3(U,P) =  P_{\t} - \proj_{\widehat {\bf D}(P_{\n},U_{\n})} (P_{{\t}} - \rho_{\t}\circ \,U_{\t} )
\end{array}
\end{equation}
where the modified friction disk for a contact $\alpha$ is
\begin{equation}\label{eq:AC-L3}
  \widehat {\bf D}^\alpha(P^\alpha_{\n,k+1},U_{\n,k+1}^{\alpha}) = {\bf D}(\mu(\proj_{\nbR_+} (P^\alpha_{\n,k+1} - \rho^\alpha_{\n}\,(U_{\n,k+1}^{\alpha}+e^\alpha U_{\n,k}^{\alpha}) )).
\end{equation}
\subsection{Structure of the Jacobians}

Let us denote the one element of the  generalized Jacobian by  $ H(U,P) \in \partial \Phi(U,P)$ which has the structure
\begin{equation}
  \label{eq:AC-L6}
   H(U,P) =
   \left[\begin{array}{cccc}
       - I & 0 &  \widehat W_{\n\n} & \widehat W_{\n\t} \\ \\
       0  & -I  &  \widehat W_{\t\n} & \widehat W_{\t\t} \\ \\
       \partial_{U_{\n}} \Phi_2(U,P) & 0 &   \partial_{P_{\n}} \Phi_2(U,P) & 0 \\ \\
       \partial_{U_{\n}} \Phi_3(U,P) &  \partial_{U_{\t}} \Phi_3(U,P) &  \partial_{P_{\n}} \Phi_3(U,P)  & \partial_{P_{\t}} \Phi_3(U,P)
   \end{array}\right]
\end{equation}

\subsection{Computation of the gradients}

Let us consider the single contact case.
\paragraph{Computation of the gradients of $\Phi_2$}
\begin{equation}
  \label{eq:AC-T1}
  \begin{array}{l}
  \varPhi_2(U,P) =  P_{\n} - \proj_{\nbR^{a}_+} (P_{\n} - \rho_{\n} (U_{\n} +e  U_{\n,k}) ) \\ \\
\end{array}
\end{equation}
\begin{itemize}
\item \textbf{If} $P_{\n} - \rho_{\n} (U_{\n} +e  U_{\n,k}) \geq 0 $, we get
  \begin{equation}
    \label{eq:AC-T2}
    \begin{array}{l}
      \varPhi_2(U,P) =  + \rho_{\n} (U_{\n} +e  U_{\n,k})
    \end{array}
  \end{equation}
  and
  \begin{equation}
    \label{eq:AC-T3}
    \begin{array}{l}
     \partial_{U_{\n}} \varPhi_2(U,P) =  + \rho_{\n} \\ \\
     \partial_{P_{\n}} \varPhi_2(U,P) =  0 \\ \\
    \end{array}
  \end{equation}
\item \textbf{If} $P_{\n} - \rho_{\n} (U_{\n} +e  U_{\n,k})  < 0 $, we get
  \begin{equation}
    \label{eq:AC-T4}
    \begin{array}{l}
      \varPhi_2(U,P) =  P_{\n}
    \end{array}
  \end{equation}
  and
  \begin{equation}
    \label{eq:AC-T5}
    \begin{array}{l}
     \partial_{U_{\n}} \varPhi_2(U,P) =  0 \\ \\
     \partial_{P_{\n}} \varPhi_2(U,P) =  1 \\ \\
    \end{array}
  \end{equation}
\end{itemize}
\paragraph{Computation of the gradients of $\Phi_3$}
\begin{equation}
  \label{eq:AC-TT1}
  \begin{array}{l}
  \varPhi_3(U,P) =  P_{\t} - \proj_{\widehat {\bf D}(P_{\n},U_{\n})} (P_{\t} - \rho_{\t} U_{\t} ) \\ \\
\end{array}
\end{equation}
\begin{itemize}
\item \textbf{If} $\|P_{\t} - \rho_{\t} U_{\t}\| \leq \mu \max (0 ,P_{\n} - \rho_{\n} (U_{\n} +e  U_{\n,k}) ) $  , we get
\begin{equation}
  \label{eq:AC-TT2}
  \begin{array}{l}
  \varPhi_3(U,P) =  + \rho_{\t} U_{\t}
\end{array}
\end{equation}
and
 \begin{equation}
    \label{eq:AC-TT3}
    \begin{array}{l}
     \partial_{U_{\n}} \varPhi_3(U,P) =  0 \\ \\
     \partial_{P_{\n}} \varPhi_3(U,P) =  0 \\ \\
     \partial_{U_{\t}} \varPhi_3(U,P) =  + \rho_{\t} \\ \\
     \partial_{P_{\t}} \varPhi_3(U,P) =  0 \\ \\
    \end{array}
  \end{equation}
\item \textbf{If} $\|P_{\t} - \rho_{\t} U_{\t}\| > \mu \max (0 ,P_{\n} - \rho_{\n} (U_{\n} +e  U_{\n,k}) ) $  , we get
\begin{equation}
  \label{eq:AC-TT4}
  \begin{array}{l}
  \varPhi_3(U,P) =  P_{\t} - \mu \max(0,P_{\n} - \rho_{\n} (U_{\n} +e  U_{\n,k}) )  \Frac{P_{\t} - \rho_{\t} U_{\t} }{ \| P_{\t} - \rho_{\t} U_{\t}\| }
\end{array}
\end{equation}

\begin{itemize}
\item  \textbf{If} $P_{\n} - \rho_{\n} (U_{\n} +e  U_{\n,k}) \leq 0$, we get
  \begin{equation}
  \label{eq:AC-TT5}
  \begin{array}{l}
  \varPhi_3(U,P) =   P_{\t}
\end{array}
\end{equation}
and
 \begin{equation}
   \label{eq:AC-TT6}
   \begin{array}{l}
     \partial_{U_{\n}} \varPhi_3(U,P) =  0 \\ \\
     \partial_{P_{\n}} \varPhi_3(U,P) =  0 \\ \\
     \partial_{U_{\t}} \varPhi_3(U,P) =  0 \\ \\
     \partial_{P_{\t}} \varPhi_3(U,P) =  I_2 \\ \\
   \end{array}
 \end{equation}
\item  \textbf{If} $P_{\n} - \rho_{\n} (U_{\n} +e  U_{\n,k}) > 0$, we get
\begin{equation}
  \label{eq:AC-TT7}
  \begin{array}{l}
  \varPhi_3(U,P) =  P_{\t} - \mu (P_{\n} - \rho_{\n} (U_{\n} +e  U_{\n,k}) )  \Frac{P_{\t} - \rho_{\t} U_{\t} }{ \| P_{\t} - \rho_{\t} U_{\t}\| }
\end{array}
\end{equation}
and
 \begin{equation}
   \label{eq:AC-TT8}
   \begin{array}{l}
     \partial_{U_{\n}} \varPhi_3(U,P) =  \mu \rho_{\n}  \Frac{P_{\t} - \rho_{\t} U_{\t} }{ \| P_{\t} - \rho_{\t} U_{\t}\| }\text{{\bf WARNING} case was not taken into account}\\ \\
     \partial_{P_{\n}} \varPhi_3(U,P) =  -\mu  \Frac{P_{\t} - \rho_{\t} U_{\t} }{ \| P_{\t} - \rho_{\t} U_{\t}\| } \\ \\
     \partial_{U_{\t}} \varPhi_3(U,P) =  \mu\rho_{\t}(P_{\n} - \rho_{\n} (U_{\n} +e  U_{\n,k}) ) \Gamma(P_{\t} - \rho_{\t} U_{\t})  \\ \\
     \partial_{P_{\t}} \varPhi_3(U,P) =  I_2-\mu(P_{\n} - \rho_{\n} (U_{\n} +e  U_{\n,k}) ) \Gamma(P_{\t} - \rho_{\t} U_{\t})  \\ \\
   \end{array}
 \end{equation}
\end{itemize}

\end{itemize}

\subsection{Rearranging the cases}

{\bf TO BE COMPLETED}
\section{Formulation with global variables.}

\subsection{Formulation}
Let us start with
\begin{equation}
  \label{eq:GAC-L1}
  \begin{array}{l}
  \Psi_{1}^{a}(v,U,P) =  - \widehat M v_{k+1}  +  H P_{k+1}  + q \\ \\
  \Psi_{1}^{b}(v,U,P) =  - U_{k+1}  + H^\top v _{k+1}  + b \\ \\
  \Psi_2(v,U,P) =  P_{\n} - \proj_{\nbR^{a}_+} (P_{\n} - \rho_{\n}\circ (U_{\n} +e \circ  U_{\n,k}) ) \\ \\
  \Psi_3(v,U,P) =  P_{\t} - \proj_{\widehat {\bf D}(P_{\n},U_{\n})} (P_{{\t}} - \rho_{\t}\circ \,U_{\t} )
\end{array}
\end{equation}
where the modified friction disk for a contact $\alpha$ is
\begin{equation}\label{eq:GAC-L2}
  \widehat {\bf D}^\alpha(P^\alpha_{\n,k+1},U_{\n,k+1}^{\alpha}) = {\bf D}(\mu(\proj_{\nbR_+} (P^\alpha_{\n,k+1} - \rho^\alpha_{\n}\,(U_{\n,k+1}^{\alpha}+e^\alpha U_{\n,k}^{\alpha}) )).
\end{equation}

\subsection{Structure of the Jacobians}

 Let us denote the one element of the  generalized Jacobian by  $ H(v,U,P) \in \partial \Psi(s,U,P)$ which has the structure
\begin{equation}
  \label{eq:GAC-L3}
   H(v,U,P) =
   \left[\begin{array}{ccccc}
       - \widehat M & 0 & 0 & H_{\n} & H_{\t} \\ \\
        H_{\n}^\top &  - I & 0 & 0 &0 \\ \\
        H_{\t}^\top &  0  & -I & 0 &0 \\ \\
        0 & \partial_{U_{\n}} \Psi_2(v,U,P) & 0 &   \partial_{P_{\n}} \Psi_2(v,U,P) & 0 \\ \\
        0 & \partial_{U_{\n}} \Psi_3(v,U,P) &  \partial_{U_{\t}} \Psi_3(v,U,P) &  \partial_{P_{\n}} \Psi_3(v,U,P)  & \partial_{P_{\t}} \Psi_3(v,U,P)
   \end{array}\right]
\end{equation}

We clearly have
\begin{equation}
  \label{eq:equivalentJacobian}
  \begin{array}{lcl}
     \partial_{U} \Psi_2(v,U,P) &=& \partial_{U} \Phi_2(U,P) \\
     \partial_{P} \Psi_2(v,U,P) &=& \partial_{P} \Phi_2(U,P) \\
     \partial_{U} \Psi_3(v,U,P) &=& \partial_{U} \Phi_3(U,P) \\
     \partial_{P} \Psi_3(v,U,P) &=& \partial_{P} \Phi_3(U,P) \\
  \end{array}
\end{equation}
and we get
\begin{equation}
  \label{eq:GAC-L4}
   H(v,U,P) =
   \left[\begin{array}{ccccc}
       - \widehat M & 0 & 0 & H_{\n} & H_{\t} \\ \\
        H_{\n}^\top &  - I & 0 & 0 &0 \\ \\
        H_{\t}^\top &  0  & -I & 0 &0 \\ \\
        0 & \partial_{U_{\n}} \Phi_2(U,P) & 0 &   \partial_{P_{\n}} \Phi_2(U,P) & 0 \\ \\
        0 & \partial_{U_{\n}} \Phi_3(U,P) &  \partial_{U_{\t}} \Phi_3(U,P) &  \partial_{P_{\n}} \Phi_3(U,P)  & \partial_{P_{\t}} \Phi_3(U,P)
   \end{array}\right]
\end{equation}

\subsection{Simplification ?}
Since the second line $\Psi_1^b$ is linear, we should be able to derive a reduced Jacobian using the chain rule. Let us define $\widetilde \Psi$
\begin{equation}
  \label{eq:chainrule}
  \widetilde \Psi(v,P)  = \Psi(v,H^\top v +b,P)
\end{equation}

\begin{equation}
  \label{eq:GAC-L5}
  \begin{array}{l}
  \widetilde \Psi_{1}(v,P) =  - \widehat M v_{k+1}  +  H P_{k+1}  + q \\ \\
  \widetilde \Psi_2(v,P) =  P_{\n} - \proj_{\nbR^{a}_+} (P_{\n} - \rho_{\n}\circ (H^\top_{\n}v+b_{\n} +e \circ  U_{\n,k}) ) \\ \\
  \widetilde \Psi_3(v,P) =  P_{\t} - \proj_{\widehat {\bf D}(P_{\n},U_{\n})} (P_{{\t}} - \rho_{\t}\circ \,(H^\top_\t v + b_\t) )
\end{array}
\end{equation}

\paragraph{Chain rule}
\begin{equation}
  \label{eq:chainrule1}
  \begin{array}{lcl}
  \partial_v \widetilde \Psi_{2,3}(v,P) &=&  \partial_v \Psi_{2,3}(v,H^\top v +b,P)  \\ \\
  &=& H_{\n}^\top \partial_{U_\n} \Phi_{2,3}(H^\top v + b,P) + H_{\t}^\top \partial_{U_\t} \Phi_{2,3}(H^\top v + b,P)
\end{array}
\end{equation}

\begin{equation}
  \label{eq:GAC-L6}
   H(v,P) =
   \left[\begin{array}{ccc}
       - \widehat M &   H_{\n} & H_{\t} \\ \\
       H_{\n}^\top \partial_{U_\n} \Phi_{2}(H^\top v + b,P) &   \partial_{P_{\n}} \Phi_2(H^\top v + b,P) & 0 \\ \\
       \begin{array}{c}
         H_{\n}^\top \partial_{U_\n} \Phi_{3}(H^\top v + b,P) \\
         \quad \quad + H_{\t}^\top \partial_{U_\t} \Phi_{3}(H^\top v + b,P)\\
     \end{array}
     &  \partial_{P_{\n}} \Phi_3(H^\top v + b,P)  & \partial_{P_{\t}} \Phi_3(H^\top v + b,P)
   \end{array}\right]
\end{equation}

\paragraph{discussion}
\begin{itemize}
\item Formulae has to be checked carefully
\item I do not known if there an interest in the simplification. With sparse matrices, it is perhaps easier to deal with~(\ref{eq:GAC-L4})
\end{itemize}

%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End:


\documentclass[12pt]{article}
\usepackage{graphicx}
\usepackage{amssymb}
\usepackage{multirow}
%\usepackage{subfig}

%\input epsf.sty
%\topmargin   0.25in
\topmargin -.5cm \textheight 21cm

\oddsidemargin -.125cm

\textwidth 16cm

\newcommand{\ra}{\rangle}
\newcommand{\la}{\langle}
\newcommand{\T}{\widetilde \Phi_{CFT}}
\newcommand{\Cn}{{\cal C}_n}
\newcommand{\vp}{\varphi}

\newcommand{\B}{b'}
\newcommand{\C}{c'}
\newcommand{\bB}{\bar b'}
\newcommand{\bC}{\bar c'}
\newcommand{\Bu}{B_{\vec u}}
\newcommand{\VV}{{\cal V}}
\newcommand{\II}{{\cal I}}
\newcommand{\HH}{{\cal H}}
\newcommand{\MM}{{\cal M}}
\newcommand{\BB}{{\cal B}}
\newcommand{\CC}{{\cal C}}
\newcommand{\OO}{{\cal O}}
\newcommand{\QQ}{{\cal Q}}
\newcommand{\PP}{{\cal P}}
\newcommand{\EE}{{\cal E}}
\newcommand{\LL}{{\cal L}}
\newcommand{\SSS} {{\cal S}}
%\newcommand{\lll}{\langle\langle}
%\newcommand{\rrr}{\rangle\rangle}
\newcommand{\half}{{1\over 2}}
\newcommand{\wt}{\widetilde}
\newcommand{\wh}{\widehat}
\newcommand{\wc}{\check}
\newcommand{\wb}{\bar}
\newcommand{\RR}{{\cal R}}
\newcommand{\NN}{{\cal N}}
\newcommand{\TT}{{\cal T}}
\newcommand{\bet}{\beta'}
\newcommand{\gam}{\gamma'}
\newcommand{\WW}{{\cal W}}
\newcommand{\nl}{\hspace{-.65cm}}
\newcommand{\bd}{\begin{displaymath}}
\newcommand{\ed}{\end{displaymath}}
\newcommand{\ba}{\begin{eqnarray}}
\newcommand{\ea}{\end{eqnarray}}
\newcommand{\be}{\begin{equation}}
\newcommand{\ee}{\end{equation}}
\newcommand{\ben}{\begin{eqnarray}}
\newcommand{\een}{\end{eqnarray}}
\newcommand{\refb}[1]{(\ref{#1})}
\newcommand{\p}{\partial}
\newcommand{\sectiono}[1]{\section{#1}}
\setcounter{equation}{0}
\renewcommand{\theequation}{\thesection.\arabic{equation}}

\def\sqr#1#2{{\vcenter{\vbox{\hrule height.#2pt
         \hbox{\vrule width.#2pt height#1pt \kern#1pt
            \vrule width.#2pt}
         \hrule height.#2pt}}}}
\def\square{\mathop{\mathchoice\sqr66\sqr66\sqr{3.75}4\sqr34\,}\nolimits}

\begin{document}
\section{Methodology}
By comparing the statistic of the observed lensed galaxies to the theoretical
predictions one can constrain the intrinsic luminosity function. Here we make
use of the observed sub-mm galaxies  located between $z = 1$ and $z = 4$ with
the  redshift distribution of sources from Simpson et al. 2014 \cite{Simpson:2014lr}, $
dN/dz \propto \exp\left[-(\ln(z+1)-\ln(1+z_\mu))^2/2\sigma_z^2\right]/\left[(z+1)\sigma_z\sqrt{2\pi}\right]$, where $z_\mu = 2.6$, $\sigma_z = 0.2$ to constrain the intrinsic luminosity function. To this end, we test several theoretical models which include broken power law and Schechter luminosity functions with various parameters and test them against the data. Similar analysis appeared, e.g.  in  Lima et al. 2010a \cite{Lima:2010a}, Lima et al. 2010b \cite{Lima:2010b}, Wardlow et al. (2013) \cite{Wardlow:2013}, etc.

 In the following we first describe our way to model the foreground population, we then discuss the calculation of the lensing statistics, and, finally, we list our choices for the intrinsic luminosity functions.

\subsection{Magnification by an individual lens}

We begin by summarizing the properties of the lenses. We use two ways to model our halos: (1) as a single isothermal sphere (SIS), and (2) a NFW profile (Navarro et al. 1997).  The NFW profile describes the outskirts of halos better whereas the SIS profile is good in describing the inside of a halo since it yields the  observed flat rotational curves. Here we make use of the both profiles to create the total probability distribution function.

In general, the magnification can be calculated as follows
\begin{equation}
\mu(\theta) = \frac{1}{(1-\kappa(\theta))^2-|\gamma(\theta)|^2},
\end{equation}
where  $\theta$ is the angular  coordinate in the lens plane, $\kappa$ is the convergence and $\gamma $ the shear, which depend on the properties of the lens and its distance from the source.

We start with the NFW halos. In this case the convergence and shear are given by
\begin{equation}
\kappa_{NFW}(\theta) = \frac{M_{vir}fc_{200}^2}{2\pi r_{200}^2}\frac{F\left(c_{200}\theta/\theta_{200}\right)}{\Sigma_{cr}}~~~~\textrm{and}~~~~\gamma(\theta) = \frac{M_{vir}f c_{200}^2}{2\pi r_{200}^2}\frac{G\left(c_{200}\theta/\theta_{200}\right)}{\Sigma_{cr}},
\label{Eq:kappa}\end{equation}
with  the critical projected density is given by
\begin{equation}
\Sigma_{cr} = \frac{1}{4\pi G(1+z)}\frac{D_A^s)}{D_A^l)D_A^{ls})},
\end{equation}
where $D_A^s$, $D_A^l$ and $D_A^{ls}$  are the angular diameter distance between the observer and the source,  the observer and the lens and the lens and the source respectively. In eq.  \ref{Eq:kappa}  F and G are two functions given by Takada and Jian 2003 \cite{Takada:2003}, for which we assumed a truncated NFW profile (truncated at $r_{vir}$).  $M_{vir}$ is the virial mass, $r_{200}$ is the comoving virial radius, $\theta_{200}$ is the angular size on the lens plane which corresponds to  $r_{200}$, $c_{200}$ is the concentration parameter of the dark matter halos calculated as in Diemer and Kravtsov (2014) \cite{Diemer:2014} and  $f = \left[\log(1+c_{200})-c_{200}/(1+c_{200})\right]^{-1}$.

The magnification of SIS can be written as
\begin{equation}
\mu_{SIS}(\theta)= \left(1-\frac{\theta_E}{|\theta|}\right)^{-1},~~~~\textrm{with}~~~~\theta_E = 4\pi\frac{\sigma_V^2}{c^2}\frac{D_{A}(r_{ls})}{D_A(r_s)}.
\end{equation}
Here $\sigma_V^2$ is the velocity  dispersion which we take from a simulation by Evrard et al. (2008) \cite{Evrard:2008}. In this simulation the dependence of $\sigma_V^2$ on the halo mass and redshift is provided which allows us to apply our model to high and low redshift galaxies.

Next for each given source we need to sum up the contributions to the total magnification from different lenses. Here we generate abundances of halos at each redshift using the Sheth-Tormen (1999) \cite{Sheth:1999} formalism which gives the number of halos per unit volume in each mass bin.

\subsection{Lensing Statistics}

The magnification of a source galaxy by a foreground galaxy depends on the profile of the foreground galaxy, redshifts of the lens and of the source and the impact parameter.  To model the probability distribution of lensing the  procedure is as follows. We first model the differential probability distribution $P(\mu)$ for a particular pair of source which emits light at $z_s$ and lens of mass $M_l$ which deflects the the light ray at $z_l$ where we account for a wide range of impact parameters. We next sum over the distribution of redshift sources and the masses and the redshifts of the  lenses to get the total probability distribution function.

Next, we calculate the total probability for lensig with the magnification larger than some $\mu$, $P(>\mu)$ and the probability density for magnification $\mu$, $P(\mu) = -dP(>\mu)/d\mu$. In this we generally follow the approach taken in Lima et al. (2010a) \cite{Lima:2010a}.

It should be noted that neither SIS nor NFW profiles fully describe the observations with SIS being a better match at small distances from the halo center and NFW better describing the outskirts. To be closer to reality,  we smoothly glue the probability densities $P_{SIS}(\mu)$ and $P_{NFW}(\mu)$ so that the former dominates at large magnifications (small impact parameters) and the latter dominates at small  magnifications (large impact parameters). We make sure that the resulting probability density, $P_{tot}(\mu)$, is normalized to unity.

We further use this probability density to estimate the effect of lensing on the observed luminosity function. To this end we calculate the mean magnification at given observed flux and compare it to data  \begin{equation}
 <\mu>(S_{obs}) = \int_0^\infty \mu P(\mu|S_{obs})  d\mu,
 \end{equation}
where the probability for lesning with magnification $\mu$ given the observed flux \cite{Lima:2010b} is
\begin{equation}
P(\mu|S_{obs}) = \frac{1}{N}\frac{P(\mu)}{\mu}\frac{dn}{dS}\left(\frac{S_{obs}}{\mu}\right), ~~~\textrm{where}~~~N = \frac{dn_{obs}(S_{obs})}{dS_{obs}} = \int  \frac{P(\mu)}{\mu}\frac{dn}{dS}\left(\frac{S_{obs}}{\mu}\right)d\mu.
\end{equation}
Here $ dn_{obs}(S_{obs})/dS_{obs}$ is the observed luminosity function and $dn/dS$ is the intrinsic one which we discuss in the next section.

In addition we calculate the expected fraction of the sources of observed flux $S_{obs}$ lensed with magnification greater than $\mu$
\begin{equation}
Fr = \frac{\int_\mu^\infty P(\mu|S_{obs})}{\int_0^\infty P(\mu|S_{obs})}.
\end{equation}

\subsection{Intrinsic luminosity function}

The effects of lensing are expected to be manifested at the bright-luminosity end of the luminosity function. Therefore it is natural to assume that the faint-luminosity end has undergone a negligible amount of lensing.
We use the faint-luminosity number counts recently reported by Karim et al. (2013) to normalize our intrinsic luminosity functions.

We use two functional forms to fit the number counts:
\begin{enumerate}
\item The Shechter function with
\begin{equation}
\frac{dn}{dS} = \frac{n_\star}{S_\star}\left(\frac{S}{S_\star}\right)^{-\alpha}\exp\left(-S/S_\star\right)
\end{equation}
with the parameters $n_s = 424$ $mJ^{-1}deg^{-2}$, $S_\star = 8$ [mJy], $\alpha = 1.1$ (from Karim et al. 2013) and $n_s = 424$ $mJ^{-1}deg^{-2}$, $S_\star = 7$ [mJy], $\alpha = 1.9$ (steep).
\item The broken power law
\begin{equation}
\frac{dn}{dS} = N_s\left(\frac{S}{S_\star}\right)^{-\beta_1},~~~~\textrm{for}~~~~S<S_\star,
\end{equation}
\begin{displaymath}
\frac{dn}{dS} = N_s\left(\frac{S}{S_\star}\right)^{-\beta_2},~~~~\textrm{for}~~~~S>S_\star,
\end{displaymath}
with the parameters $N_s = 25$ $mJ^{-2}deg^{-2}$, $S_\star = 8$ [mJy], $\beta_1 = 2$ and $\beta_2 = 18$.
\end{enumerate}

\begin{thebibliography}{9}

{\footnotesize

\bibitem{Simpson:2014}
J. M. Simpson, et al.,
ApJ, 788 (2014) 125.

\bibitem{Lima:2010a}
M. Lima, B. Jain, M. Devlin,
MNRAS, 406 (2010) 2352.

\bibitem{Lima:2010b}
M. Lima, B. Jain, M. Devlin,  J. Aguirre,
ApJL, 717 (2010) 31.

\bibitem{Wardlow:2013}
J.L.~Wardlow, et al.,
ApJ 762 (2013).

\bibitem{Takada:2003}
M.~Takada, B. Jain,
MNRAS 344 (2003) 857.

\bibitem{Diemer:2014}
B.~Diemer, A. V. Kravtsov,
arXiv:1407.4730.

\bibitem{Evrard:2008}
A.~E. Evrard et al.,
ApJ 672 (2008) 122.

\bibitem{Sheth:1999}
R. K. Sheth, G. Tormen,
 MNRAS  308 (1999) 119.
}
\end{thebibliography}
\end{document}


\chapter{A Second Approach : Constraint Based Learning}

As seen in the previous chapter, the initial approach suffered from significant difficulty scaling. Even simple two argument functions took upwards of 400 seconds to complete. This was mainly due to the sheer size of the ground learning task, and the complexity from combinations of rule and where predicates.

\section{Top Down Vs. Bottom Up}
The main issue with the interpreted approach is that it is bottom-up. To learn the output of a rule, it must first iterate down the expression tree (shown in Figure \ref{fig:expr_tree_2}), calculate the value of each simple sub-expression, then iterate back up the tree combining values until a value is known for the entire rule body. My second approach overcomes this issue by implementing a top down approach. \\ \\

\begin{figure}[h!]
\centering
\includegraphics[width=0.55\textwidth]{C1/expression_tree.png}
\caption{Expression tree for a simple expression}
\label{fig:expr_tree_2}
\end{figure}
\mbox{}\\
The idea behind this new approach is simple. By maintaining an ``equality constraint'', the tool keeps track of what each expression is supposed to be equal to (as defined by the input examples). Then, as the program iterates down the expression tree, it fails if it ever finds some easily provable equality failure, i.e 1 = 2. \\ \\
For example, if it knows that \lstinline{call(f, 2) = 5} and that the body of function f is \lstinline{(2 * X) + 1}, then it can deduce that
\begin{align*}
(2*2) + 1 &= 5 \\
(2*2) &= 4 \\
2 &= 2
\end{align*}
So there are no contradictions. \\ \\
However, if instead there is an example stating that \lstinline{call(f, 2) == 6}, with the same function, then instead we get %{
\begin{align*}
(2*2) + 1 &= 6 \\
(2*2) &= 5 \\
\end{align*}
Which fails because 5 is not a multiple of 2.

\subsection{Dealing with termination}
One issue with this new approach is that it does not automatically handle programs which do not terminate. Whilst these programs do not stop clingo from finding a solution, they are incorrect as the generated constraints never become simple enough to have a contradiction be proved. \\ \\
To deal with this, the tool has to check input examples for termination. While this is typically an undecidable problem, for my small target language it is decidable and computable. To represent this in ASP, there needed to be a way to represent the next step of execution of an expression. For example, we can say that \lstinline!next_step(add(1, mul(2, 3)), mul(2, 3))!, meaning that it next evaluates \lstinline!mul(2, 3)!. \\ \\
I then define termination as :
\begin{itemize}
\item If an expression is simple, containing only constants, then it terminates.
\item If the next step of an expression terminates, then that expression also terminates.
\end{itemize}
\mbox{}\\
This approach is fairly efficient as it as another top down approach, and generates a similar number of rules in the ground program as the constraint checking rules.
\mbox{}\\
\section{ASP Representation}
I represent this approach using the following ASP predicates.

\begin{center}
\begin{tabular}{| c | m{0.7\linewidth} |}
\hline
\textbf{ASP Term} & \textbf{Semantics} \\
\hline
\lstinline!eq(Expr, Val)!
&
\mbox{}\newline
An equality constraint. Expr, when evaluated, should equal Val. \newline
\\
\hline
\lstinline!is_call(call(F, Expr))!
&
\mbox{}\newline
Represents if a function is called. Used to generate more ground skeleton rules. \newline
\\
\hline
\lstinline!terminates(Expr)!
&
\mbox{}\newline
Represents if an expression terminates. \newline
\\
\hline
\lstinline!next_step(A, B)!
&
\mbox{}\newline
The next step of the execution of expression A is expression B.\newline
\\
\hline
\end{tabular}
\end{center}
\mbox{}\\
Now, these predicates are used in the following rules. \\

\lstinputlisting[language=Prolog, firstline=32, lastline=32, firstnumber=32, label=lst:eq_gen, caption=Equality generation]{../ASP/eq/eq_rules.lp}
\mbox{} \\
\ref{lst:eq_gen} generates initial equality constraints given by the examples.  \\

\lstinputlisting[language=Prolog, firstline=33, lastline=33, firstnumber=33, label=lst:eq_const, caption=Equality contradiction]{../ASP/eq/eq_rules.lp}
\mbox{} \\
\ref{lst:eq_const} constrains equality on constants. The tool should fail if two different constants are equal. \\

\lstinputlisting[language=Prolog, firstline=34, lastline=37, firstnumber=34, label=lst:eq_const_mul, caption=Multiplication contradictions]{../ASP/eq/eq_rules.lp}
\mbox{} \\
\ref{lst:eq_const_mul} handles edge cases when dealing with multiplication. If multiplying any expression by 0, then it should be equal to 0, and if multiplying two things together, then the answer should be a multiple of them both. \\

\lstinputlisting[language=Prolog, firstline=38, lastline=38, firstnumber=38, label=lst:term_constraint, caption=Termination contradiction]{../ASP/eq/eq_rules.lp}
\mbox{} \\
\ref{lst:term_constraint} handles termination. The tool fails if an input example does not terminate.\\

\lstinputlisting[language=Prolog, firstline=40, lastline=40, firstnumber=40, label=lst:is_call, caption=Is\_call generation]{../ASP/eq/eq_rules.lp}
\mbox{} \\
\ref{lst:is_call} generates \lstinline{is_call} predicates, which are used to generate more ground instances of skeleton rules. \\ %{

\lstinputlisting[language=Prolog, firstline=42, lastline=45, firstnumber=42, label=lst:eq_call, caption=Constraint propagation through function calls]{../ASP/eq/eq_rules.lp}
\mbox{} \\
\ref{lst:eq_call} handles propagation of equality constraints through function calls. If a called function is equal to some value, then the body of the function (with correct arguments) is also equal to that value. \\

\lstinputlisting[language=Prolog, firstline=47, lastline=60, firstnumber=47, label=lst:eq_math, caption=Constraint propagation through arithmetic operations]{../ASP/eq/eq_rules.lp}
\mbox{} \\
\ref{lst:eq_math} specifies generation of equality predicates with arithmetic, through use of the opposite operations. Addition terms in the head of the rule are necessary to handle edge cases such as division by zero. \\

\lstinputlisting[language=Prolog, firstline=62, lastline=63, firstnumber=62, label=lst:eq_pair, caption=Constraint propagation through tuples]{../ASP/eq/eq_rules.lp}
\mbox{}\\
\ref{lst:eq_pair} describes the propagation of equality constraints through tuple pairs. If a tuple of expressions is equal to a tuple of values, then the respective halves of the tuple are equal to each other. \\

\lstinputlisting[language=Prolog, firstline=65, lastline=66, firstnumber=65, label=lst:term, caption=Termination]{../ASP/eq/eq_rules.lp}
\mbox{} \\
\ref{lst:term} defines termination. If an expression is a constant, then it terminates, or if the next step of an expression terminates then that expression also terminates. \\

\lstinputlisting[language=Prolog, firstline=68, lastline=68, firstnumber=68, label=lst:next_init, caption=Next step initialisation]{../ASP/eq/eq_rules.lp}
\mbox{} \\
\ref{lst:next_init} generates the initial \lstinline!next_step! predicates. If there exists an example input, then it is the next step of some arbitrary term \lstinline!e!. \\

\lstinputlisting[language=Prolog, firstline=82, lastline=82, firstnumber=82, label=lst:next_is, caption=Next step grounding improvement]{../ASP/eq/eq_rules.lp}
\mbox{} \\
\ref{lst:next_is} exists to reduce the grounding. If any expression is a next step, we generate an \lstinline{is_next_step} predicate, used in the remaining \lstinline{next_step} rules.\\

\lstinputlisting[language=Prolog, firstline=70, lastline=73, firstnumber=70, label=lst:next_func, caption=Next step propagation through function calls]{../ASP/eq/eq_rules.lp}
\mbox{} \\
\ref{lst:next_func} handles the next step of function calls. The next step of a function call is the body of that function. \\

\lstinputlisting[language=Prolog, firstline=65, lastline=81, firstnumber=65, label=lst:next_match, caption=Next step propagation through arithmetic operations]{../ASP/eq/eq_rules.lp}
\mbox{} \\
\ref{lst:next_match} generates \lstinline{next_step} predicates for arithmetic and tuples. The next step of an arithmetic expression is the argument that is not constant. %{

\section{Learning}
The actual learning task operates in a similar way to my initial approach. The task is again encoded as an ASP program, where the solution is a subset of the Answer Set of this program. \\ \\
By enumerating all possible rule bodies in the skeleton rules, a choice rule can be used to generate answer sets with each combination of skeleton rule, keeping the answer sets which do not fail the equality constraints. However, because \lstinline!where! rules are no longer being used, the skeleton rules now contain full bodies. This means that unfortunately the number of skeleton rules becomes large, numbering in the thousands for even simple tasks. To avoid this scaling poorly once again, I decided to implement a number of simple optimisations.%{

\subsection{Using inbuilt arithmetic}
As part of the first approach, arithmetic was represented with my own predicates \lstinline{add(A, B)}, \lstinline{sub(A, B)} and \lstinline{mul(A, B)} because the tool needed to evaluate expressions that the grounder would not be able to compute (i.e the value of function calls or where variables). \\ \\ %{
However, in my new approach I have made partial use of the clingo inbuilt arithmetic. If inside function arguments, or the rule body has no function calls at all, then the tool knows that all sub expressions will be arithmetic and it can make use of the simple \lstinline{+, -} and \lstinline{*}. \\ \\
The main advantage of this approach is that it vastly reduces the ground output. As the inbuilt operations are computed by the grounder, if two different expressions compute the same output number, then they are not repeated in the ground output. For example, \lstinline{X + X} and \lstinline{2 * X} are semantically equivalent, so when ground with \lstinline!X = 3! both produce the term \lstinline!6!, corresponding to one output rule.

\section{A Worked Example : Greatest common divisor}
Once again I will use Euclid's algorithm for the Greatest Common Divisor \cite{Euclid} to illustrate this new approach. Because the tool still does not have modulo as part of its target language, the simplified definition is used: \\

\lstinputlisting[language=Haskell, firstline=2, lastline=5]{../ASP/eq/gcd.lp}
\mbox{} \\
As input, I will be using the following examples : \\

\lstinputlisting[language=Prolog, firstline=34, lastline=40]{../ASP/eq/gcd.lp}
\mbox{} \\
Which cover both cases $(X < Y)$ and $(X > Y)$ while also not being too simplistic. \\ \\
After running the learning task, the resulting Answer Set contains the terms: \\

\begin{lstlisting}
choose(1,2).
choose(2,150, 0).
choose(3,159, 1, 1).
\end{lstlisting}
\mbox{} \\
These terms correspond to the following skeleton rules : \\

\begin{lstlisting}
rule(R, gcd, (N0, N1), N0) :- is_call(call(gcd, (N0, N1))), choose(R, 2).

rule(R, gcd, (N0, N1), call(gcd, ((N0 - N1), (N1 - 0)))) :-
		is_call(call(gcd, (N0, N1))),
		choose(R, 150, 0).

rule(R, gcd, (N0, N1), call(gcd, ((N1 * 1), (N0 * 1)))) :-
		is_call(call(gcd, (N0, N1))),
		choose(R, 190).
\end{lstlisting}
\mbox{} \\
Which then corresponds to the Haskell program (simplified for readability):

\begin{lstlisting}
gcd x y
	| x == y = x
	| x > y	 = gcd (x - y) y
	| x < y	 = gcd y x
\end{lstlisting}
\mbox{} \\
What is interesting is that whilst it has not learned the exact target program, the learned program is still correct. This is due to the optimisations preferring rules with shorter bodies.\\ \\
To see why this result is returned, it is useful to look at the corresponding \lstinline{eq} predicates for each example. \\ \\%{
The example \lstinline{example(call(gcd,(8,12)),4)} produces the terms :\\ %{
\begin{multicols}{2}
\begin{lstlisting}
eq(call(gcd,(8,12)),4).
eq(call(gcd,(12,8)),4).
eq(call(gcd,(4,8)),4).
eq(call(gcd,(8,4)),4).
eq(call(gcd,(4,4)),4).
eq(4, 4).
next_step(e,call(gcd,(8,12))).
next_step(call(gcd,(8,12)),call(gcd,(12,8))).
next_step(call(gcd,(12,8)),call(gcd,(4,8))).
next_step(call(gcd,(4,8)),call(gcd,(8,4))).
next_step(call(gcd,(8,4)),call(gcd,(4,4))).
next_step(call(gcd,(4,4)),4).
\end{lstlisting}
\end{multicols}
\mbox{}\\
Because these terms are all created without constraints failing, the respective rule bodies are returned as a solution.

\section{Performance}
While this new approach does perform better than the old one, it still suffers from a lot of the same issues limiting performance. \\ \\
Because of the large number of combinations of skeleton rules, they can still grow very large very quickly, lowering the performance of my tool. In addition, expanding the language bias to different types also has an adverse effect on this.

\subsection{Reducing the language bias}
As a way to deal with the explosive expansion of skeleton rules, I implemented a way to help contain this by artificially limiting the language bias. \\ \\
By removing operations from the bias that will not be used in the output functions, the tool can remove a large number of skeleton rules that will have no effect on the output of the learning task. In a similar way, learning can be limited to only tail recursive programs, meaning that the skeleton rules only use inbuilt arithmetic operations, further increasing performance. \\ \\
Of course, this method for improving performance is limited by the knowledge of the user. If they have no idea what the output function will look like, this is completely unhelpful, but in many cases they may have even a small idea of what operations will be used. Alternatively, users can iteratively add operations to the background knowledge, starting with a minimal set and gradually increasing it until a valid solution is found.

\pagebreak
\section{Full ASP Listing}
\lstinputlisting[firstline=32, firstnumber=32]{../ASP/eq/eq_rules.lp}

\pagebreak
%\renewcommand\bibname{{References}}
%\bibliography{References}
%\bibliographystyle{plain}