\section{Fl---The Meta Language of Voss}

In this section\footnote{This section is to a large extent modeled
after Chapter 1 in the HOL System DESCRIPTION from Cambridge University.
In particular, many of the early examples are taken from this source.}
we provide an introduction to the functional language FL.

Similar to many theorem provers (e.g., the HOL%
\index{HOL}%
{}
system~\cite{HOLsystem,HOLbook}) the
Voss command language for the verification system is a general
purpose programming language%
\index{programming language}%
{}.
In fact, the FL language shows a strong degree of influence from
the version of ML%
\index{ML}%
{} used in the HOL-88%
\index{HOL-88}%
{} system.
However, there are several differences:  many syntactic but some
more fundamental.
In particular, the functional language used in Voss has lazy evaluation
semantics.
In other words, no expression is evaluated until it is
absolutely needed.
Similarly, no expression is evaluated more than once.
Another difference is that Boolean functions are first-class
objects and can be created, evaluated, compared and printed out.
For efficiency reasons these Boolean functions are represented as
ordered binary decision diagrams%
\index{ordered binary decision diagrams}%
{}.

Fl is an interactive language.
At top-level one can:
\begin{enumerate}
\item define functions (possibly of arity 0),
\item define new concrete types,
\item define aliases for types,
\item modify the parser, and
\item evaluate expressions.
\end{enumerate}
In this section we introduce the language by several examples.

\subsection{Invoking FL}

If the Voss system is installed on your system
and you have the suitable search path set up, it suffices
to type \verb@fl@ to get a stand-alone version of FL. In this manual, we
have used Voss 1.8b throughout. In other words, typing \verb@fl@ yielded:

\begin{hol}
% fl
      /\verb@\@
     /  \verb@\@/\verb@\@
 /\verb@\@ /      \verb@\@
/  Voss 1.8b\verb@\@
VOSS-LIBRARY-DIRECTORY = /isd/local/generic/lib/vosslib

:
\end{hol}
Note that the VOSS-LIBRARY-DIRECTORY%
\index{VOSS-LIBRARY-DIRECTORY}%
{} is installation dependent.
We return to this below and in Section~\ref{vossrc}.

The fl program can take a number of arguments.
\index{command-line arguments}
In particular,
\begin{description}
\item[-d]
Turn debugging mode%
\index{debugging mode}%
{} on.
In this mode a function call trace%
\index{call trace}%
{} will be generated
when a failure that is not caught by an exception handler occurs.
This feature is not as useful as in many other languages, but
is retained for backwards compatibility.
\item[-D]
Turn debugging mode off.
Unless the DEBUG-ON flag is set in the .vossrc file, the default
is for debugging mode to be turned off.
\item[-f n]
Start FL by first reading in the content of the file named n.
\item[-h]
A flag that is needed when fl is used as a subroutine in the
HOL%
\index{HOL}%
{} theorem prover in the HOL-Voss%
\index{HOL-Voss}%
{}
system~\cite{JoyceSegerDAC,SegerJoyceTwoLevel}.
This flag should not be used when FL is used stand-alone.
\item[-I dir]
Set the default search directory%
\index{search directory}%
{} to dir.
\item[-s i]
Set the initial OBDD table size to be $2^i$, where $i$ can range
from 12 to 24.
Note that each OBDD node in this table requires 16 bytes, and thus
the memory requirement increases very rapidly with increasing table size.
Note that FL automatically grows the OBDD table if it needs to, and
the only reason using this flag is to reduce the time it takes
to grow the tables.
The flag is kept for historical reasons, but with the modern
dynamical re-ordering version of the OBDD table, this user setable
constant is rarely needed.
\index{OBDD!table size}
\index{dynamic variable re-ordering}
\item[-o]
Before reaching the fl command prompt, print out all defaults
read from the .vossrc%
\index{.vossrc}%
{} file.
This is useful both for finding out the names of most (but unfortunately
not all) options%
\index{options}%
{} as well as checking that a particular option
has the correct value.
\item[-r i]
Initialize the random number%
\index{random number}%
{} generator with the seed i.
This allows the {\tt rvariable}
\index{rvariable}%
{} command to create new sets
of random variable values.
See the rvariable command description in Section~\ref{rvariable} for
more details.
\item[-v fn]
Store the variable ordering obtained by dynamic variable re-ordering%
\index{variable re-ordering}%
{}
in the file fn.
\index{dynamic variable re-ordering}
\end{description}

\subsection{Expressions}
\index{expressions}
The Fl prompt%
\index{prompt}%
{} is : so lines beginning with this contain
the user's input; all other lines are output of the system.
\begin{hol}
: 2+3;
it::int
5
\end{hol}
Here we simply evaluated the expression 2+3 and FL reduced
it to normal form; in this case computed the result 5. Note that
fl does only support integers%
\index{integers}%
{} as number types.
The integers are represented in arbitrary precision, and grow as needed.

Note also that Voss stores the result of the most recent expression
in a variable called {\tt it}.
\index{it}%
Thus, continuing the example by evaluating the expression {\tt it;} yields:
\begin{hol}
: it;
it::int
5
\end{hol}

\subsection{Declarations}

The declaration%
\index{declaration}%
{} let x = e binds a computation of e to
the variable x.
Note that it does not evaluate e (since the language is fully lazy%
\index{lazy}%
{}).
Only if x is printed or used in some other expression that is evaluated
will it be evaluated.
Also, once e is evaluated, x will refer to the result of the evaluation
rather than the computation.
Hence, the expression e is evaluated at most once, but it may
not be evaluated at all.
\begin{hol}
: let x = 3+3;
x::int
\end{hol}
Note that when expressions are bound to variables, the system simply
prints out the inferred type%
\index{inferred type}%
{} of the expression. We will return to
the typing scheme in FL later.
For now, it suffices to say that FL tries to find as general type as
possible that is consistent with the type of the expression.

A declaration%
\index{declaration!local}%
{} can be made local to the evaluation of an expression
e by evaluating the expression decl in e.
For example:
\begin{hol}
: let y = let x = 4 in x-5;
y::int
\end{hol}
would bind the expression 4 to x only inside the expression
bound to y. Thus, we get:
\begin{hol}
: let x = 2;
x::int
: let y = let x = 4 in x-5;
y::int
: x;
2
: y;
-1
\end{hol}
FL is lexically scoped%
\index{scoping}%
{}, and thus
the binding in effect at the time of definition is the one used.
In other words, if we write:
\begin{hol}
: let x = 2;
x::int
: let y = x*5;
y::int
: let x = 12;
x::int
\end{hol}
and we then evaluate y we will get 10
rather than 60.

Contrary to ML, at the top level FL 1.8b does not allow
simultaneous bindings%
\index{simultaneous bindings}%
{}.
Hence, if we would like to bind the expressions 2 and 4-5 to the
variables x and y respectively, we would have to write:
\begin{hol}
: let x = 2;
x::int
: let y = 4-5;
y::int
\end{hol}
However, inside local bindings, a special keyword {\tt val}
\index{val}%
{}
is available to take a complicated object apart automatically.
For example, if e is an expression of type (int\verb@#@bool) then
we could write:
\begin{hol}
: let top\_level q =
	val (i,b) = q in
	i < 3 => b | F;
top\_level::(int\verb@#@bool)->bool
\end{hol}
In general, the expression to the right of the val keyword
can be an arbitrary complex pattern similar to the patterns%
\index{patterns}%
{}
allowed in function definitions and lambda expressions.
For more details, see the section on pattern matching on page~\ref{val}.

\subsection{Functions}

To define a function%
\index{function}%
{} f with formal parameter x and body e one performs
the declaration: let f x = e.
To apply the function f to an actual parameter e one evaluates
the expression f e.
\begin{hol}
: let f x = x+2;
f::(int) -> (int)
: f 4;
6
\end{hol}
Note that the type inferred for f is essentially ``a function taking
an int as argument and returning an int''.
Applications binds more tightly than anything else in FL; thus for example:
f 3 * 4 would be evaluated as: ((f 3)*4) and thus yield 20.

Functions of several arguments can also be defined:
\begin{hol}
: let add x y = x+2*y;
add::(int) -> ((int) -> (int))
: add 1 4;
9
: let f = add 1;
f::(int) -> (int)
: f 4;
9
\end{hol}
Applications associate%
\index{association rules}%
{} to the left so add 3 4 means (add 3) 4. In the
expression add 3, the
function add is partially applied to 3; the resulting value is the
function of type int\funarrow int which
adds 3 to twice its argument. Thus add takes its arguments one at a time.
We could have made add take a single argument of the cartesian product%
\index{cartesian product}%
{}
type (int\verb@#@int):
\begin{hol}
: let add (x,y) = x+y;
add::((int # int)) -> (int)
: add (3,4);
7
: add 3;
===Type mismatch: (int # int) and int
#### Run-time error
---- Type error
\end{hol}
As well as taking structured arguments (e.g. (3,4)) functions may also return
structured results:
\begin{hol}
: let manhat\_dist (x1,y1) (x2,y2) = (x2-x1, y2-y1);
manhat\_dist::((int # int)) -> (((int # int)) -> ((int # int)))
: manhat\_dist (1,1) (3,5);
(2,4)
\end{hol}

Trying to print%
\index{print}%
{} a function with insufficient number of actual arguments
yield a dash for the function and the type of the expression is printed out.
For example:
\begin{hol}
: (5, manhat\_dist (1,2));
(5,-) ::(int # ((int # int)) -> ((int # int)))
\end{hol}
The only exception to this rule is for concrete types
for which the user has installed a printing function%
\index{printing function}%
{}.
For more details of concrete types, see page~\ref{concreteTypes}.

\subsection{Recursion}

The following is an attempt to define the factorial function:
\begin{hol}
: let fact n = n=0 => 1 | n*fact (n-1);
#### Run-time error
---- Undefined variable (fact)
\end{hol}
The problem is that any free variables in the body of a function have
the bindings they had
just before the function was declared; fact is such a free variable
in the body of the declaration
above, and since it is not defined before its own declaration, an error
results. To make things
clear consider:
\begin{hol}
: let f n = n+1;
f::(int) -> (int)
: let f n = n=0 => 1 | n*f (n-1);
f::(int) -> (int)
: f 3;
9
\end{hol}
Here 3 results in the evaluation of 3*(f 2), but now the first f is
used so f 2 evaluates to 2+1=3.
To make a function declaration hold within its own body, letrec%
\index{letrec}%
{}
instead of let must be used.
The correct recursive%
\index{recursive}%
{} definition of the factorial function is thus:
\begin{hol}
: letrec fact n = n=0 => 1 | n*fact (n-1);
fact::(int) -> (int)
: fact 5;
120
\end{hol}

It should be pointed out that FL currently does not allow direct definition
of mutually recursive functions%
\index{mutually recursive functions}%
{}.
For an example on how this limitation can be dealt with, see
the subsection on concrete type decalartions.

\subsection{Tuples}

If $e\_1, e\_2, \ldots , e\_n$ have types $t\_1, t\_2, \ldots , t\_n$, then
the FL expression $(e\_1, e\_2, \ldots , e\_n)$ have type
$t\_1$\verb@#@$t\_2$\verb@#@$\ldots$\verb@#@$t\_n$.
The standard functions on tuples are fst%
\index{fst}%
{} (first), snd%
\index{snd}%
{} (second), and the infix
operation , (pair%
\index{pair}%
{}).
\begin{hol}
: let q = ((1,2),3);
q::((int # int) # int)
: let qq = (1,2,3);
qq::(int # (int # int))
: q;
((1,2),3)
: qq;
(1,2,3)
: let qqq = (1,"abc");
qqq::(int # string)
: qqq;
(1,"abc")
\end{hol}

\subsection{Lists}

If $e\_1, e\_2, \ldots , e\_n$ have type $t$, then the FL expression
$[e\_1, e\_2, \ldots , e\_n]$ has type ($t$ list%
\index{list}%
{}).
The standard functions on lists are hd%
\index{hd}%
{} (head%
\index{head}%
{}), tl%
\index{tl}%
{} (tail%
\index{tail}%
{}), []%
\index{[]}%
{} (the empty list%
\index{empty list}%
{}), and the infix operation : (cons%
\index{cons}%
{}).
Note that all elements of a list must have the same type (compare
this with a tuple where the size is determined but each member of
the tuple can have different type).
\begin{hol}
: let l = [1,2,3,3,2,1,2];
l::(int list)
: hd l;
1
: tl l;
[2,3,3,2,1,2]
: 0:l;
[0,1,2,3,3,2,1,2]
: letrec (len [] = 0) /\verb!\! (len (a:rest) = 1+len rest);
len::((* list)) -> (int)
: len l;
7
\end{hol}

\subsection{Strings}

A sequence of characters enclosed between \verb@"@ or \verb@`@ is a string%
\index{string}%
{}.
The standard functions on strings are \verb@^@ (catenation%
\index{catenation}%
{}), explode%
\index{explode}%
{}
(make string into list of strings) and
implode%
\index{implode}%
{} (make list of strings into single string).
There are also int2str%
\index{int2str}%
{} and bool2str%
\index{bool2str}%
{} functions that create a string
from an integer or an object of type boolean.
We will return to these later.
\begin{hol}
: let q = "abc and \_12!@@#";
q::string
: let qq = `qw"q qw`;
qq::string
: q^qq;
"abc and \_12!@@#qw"q qw"
: explode q;
["a","b","c"," ","a","n","d"," ","\_","1","2","!","@","@","#"]
: implode ["1", "2"];
"12"
: int2str (1-34);
"-33"
: bool2str ((variable "a") AND (variable "b"));
"a&b"
\end{hol}

\subsection{Polymorphism}

The list processing functions hd, tl, etc. can be used on all types of lists.
\begin{hol}
: hd [1,2,3];
1
: hd ["abc", "edf"];
"abc"
: (hd ["a", "b"]), hd [4,2,1];
("a",4)
: let q = [T,T,F];
q::(bool list)
: hd q;
T
\end{hol}
Thus hd has several types; for example, it is used above with types
(int list) \funarrow int,
(string list) \funarrow string, and (bool list) \funarrow bool.
In fact if ty is any type then hd has the type (ty list) \funarrow ty.
Functions, like hd, with many types are called polymorphic%
\index{polymorphic}%
{},
and FL uses type variables%
\index{type variables}%
{} *, **, ***, etc. to represent their types.
\begin{hol}
: let f x = hd x;
f::((* list)) -> (*)
: letrec map fn [] = []
   /\verb!\!    map fn (h:rest) = (fn h) : (map fn rest);
map::((*) -> (**)) -> (((* list)) -> ((** list)))
: letrec fact n = n=0 => 1 | n*fact (n-1);
fact::(int) -> (int)
: map fact [1,2,3,4,5,6,7];
[1,2,6,24,120,720,5040]
\end{hol}
The FL function map%
\index{map}%
{} takes a function f (with argument type * and result
type **), and a list l
(of elements of type *), and returns the list obtained by applying
f to each element of l
(which is a list of elements of type **). Map can be used at any instance
of its type: above, both *
and ** were instantiated to int; below, * is instantiated to (int list)
and ** to bool. Notice that the
instance need  not be  specified; it is determined by the type checker.
\begin{hol}
: let eq1 x = x=1;
eq1::(int) -> (bool)
: map eq1 [1,2,3,4,12,2,1,2];
[T,F,F,F,F,F,T,F]
\end{hol}

It should be pointed out that FL has a polymorphic type system that
is sightly different from
standard ML's. In particular, only ``top-level'' user-defined functions
can be polymorphic. In
other words, the following works as we would expect.
\begin{hol}
: let null l = l = [];
null::((* list)) -> (bool)
: let f x y = null x OR null y;
f::((* list)) -> (((** list)) -> (bool))
: f [1,2,3] ["abc", "cdef"];
F
\end{hol}
However, if we use the same declaration inside the expression, it must
be monomorphic%
\index{monomorphic}%
{}. In other
words, the following example fails.
\begin{hol}
: let f x y =
    let null l = l = [] in
    null x OR null y;
f::((* list)) -> (((* list)) -> (bool))
: f [1,2,3] ["abc", "cdef"];
===Type mismatch: int and string
#### Run-time error
---- Type error
\end{hol}
In this respect, FL is similar to the functional language called
Miranda\footnote{Miranda is a trademark of
Research Software Ltd.}~\cite{Miranda}.

\subsection{Type Annotations}
Sometimes it is useful to inform the type inference mechanism
of FL what type is expected.
In particular, when using overloaded%
\index{overloaded}%
{} operators or functions
it is quite common to have to explicitly type arguments.
In FL a variable or expression can be annotated%
\index{type annotation}%
{} with its expected
type by enclosing it in curly braces and decorate the expression
with a type expression.
In particular, if we would like to define a function ihd that
return the head of a list, but that only can be used on integer lists,
we could define ihd as follows:
\begin{hol}
let ihd \{l::int list\} = hd l;
\end{hol}
Similarly, if we have overloaded the operator + to either
operate over strings or integers, we can extend this opverloading
with yet another function by declaring
\begin{hol}
overload + \{+::int->int->int\} \{+::string->string->string\} foo;
\end{hol}
If we now were to write a function that adds three integer numbers
we would have to decorate the types so that the overload resolution
can succeed. For example, we could write:
\begin{hol}
let f \{x::int\} \{y::int\} \{z::int\} = x+y+z;
\end{hol}
or we could write
\begin{hol}
let f x y z = \{x+\{y::int\} ::int\}+z;
\end{hol}
although the former is easier to read and more general.

\subsection{Lambda Expressions}

The expression \verb@\@x.e evaluates to a function with formal parameter x
and body e. Thus the
declaration let f x = e is equivalent to let f = \verb@\@x.e. The character
\verb@\@ is our representation of lambda,
and expressions like \verb@\@x.e are called lambda-expressions%
\index{lambda-expressions}%
{}.
\begin{hol}
: \verb!\!x.x+1;
- ::(int) -> (int)

: let q = \verb!\!x.x+1;
q::(int) -> (int)
: q 1;
2
: map (\verb!\!x.x*x) [1,2,3,4,5];
[1,4,9,16,25]
\end{hol}

\subsection{Failures}

Some standard functions fail at run-time on certain arguments, printing
out a string (which is usually the function name) to identify the sort
of failure. A failure%
\index{failure}%
{} with string "t" may also be
generated explicitly by evaluating the expression error "t" (or more
generally error%
\index{error}%
{} e where e has type string).
\begin{hol}
: hd(tl [2]);
Failure:    ----  Cannot compute hd of the empty list

: 1/0;
Failure:    ----  Division by zero

: error "My message";
Failure:    ----   My message
\end{hol}

A failure can be trapped%
\index{trap a failure}%
{} by catch%
\index{catch}%
{}; the value of the expression $e\_1$ catch
$e\_2$ is that of $e\_1$, unless
$e\_1$ causes a failure, in which case it is the value of $e\_2$. One important
property of catch is that it is
(very) strict in its first argument. In other words, (hd ($e\_1$ catch
$e\_2$)) will completely evaluate $e\_1$
even though only the first element in the list may be needed. In view
of FL's lazy semantics%
\index{lazy semantics}%
{}, the
use of catch should be very carefully considered. In particular, the
bindings of catch is dynamic
rather than static so the user beware!

\subsection{Boolean Expressions}

All Boolean expressions%
\index{Boolean expression}%
{} in FL are maintained as ordered binary decision
diagrams. Hence, it
is very easy to compare complex Boolean expressions and to combine
them in different ways.
Boolean variables%
\index{Boolean variable}%
{} are created by variable%
\index{variable}%
{} s, where s is of type string.
The system uses name
equivalence, and thus
\begin{hol}
: let v = variable "v";
v::bool
: v=v;
T
: variable "v" = variable"v";
T
\end{hol}

The constants true%
\index{true}%
{} and false%
\index{false}%
{} are denoted T and F respectively. The
standard boolean functions
are available, i.e., AND%
\index{AND}%
{}, OR%
\index{OR}%
{}, NOT%
\index{NOT}%
{}, XOR%
\index{XOR}%
{}, and =%
\index{=}%
{} are all defined for objects of type Boolean..
Furthermore, there
is a special identity%
\index{identity}%
{} operator ==%
\index{==}%
{} that return true or false depending
on whether the two arguments
represent the same Boolean function or not.

Note that the variable ordering%
\index{variable ordering}%
{} in the OBDD representation is defined
by the order in which each variable function call {\em gets evaluated}.
Since FL is a fully lazy language%
\index{lazy language}%
{}, and thus the order in which expressions
are evaluated is often difficult to predict, it is strongly recommended
that each variable declaration is forced to be evaluated before it
is being used.
Alternatively, one can request that FL re-orders the variables
by evaluating the function var\_order%
\index{var\_order}%
{} and give as argument a list
of variable names.
FL will then apply the dynamic variable re-ordering mechanism and
enforce that the variables mentioned in the list will be the first
arguments and that they will occur in exactly this order.
\begin{hol}
: let a = variable "a";
a::bool
: let b = variable "b";
b::bool
: a AND b;
a&b
: a OR b;
a + b
: NOT a AND NOT b AND T;
a'&b'
: a = b;
a&b + a'&b'
:  a == b;
F
: (a=b) == (a AND b OR NOT a AND NOT b);
T
\end{hol}

The default style for printing Boolean expressions%
\index{printing Boolean expressions}%
{} is as a sum-of-products%
\index{sum-of-products}%
{}.
Since this may require printing an extremely large expression, there
is a user-setable limit on how many products that will be printed
and the maximum size of a product.
For more details how to modify these two parameters, see Section~\ref{vossrc}.

\subsection{Quantifiers}

There are several ways of using quantification%
\index{quantification}%
{}.
The ``traditional'' !x. e%
\index{$!x.\,e$}%
{} (for all x) and ?x. e%
\index{$?x. e$}%
{}
(there is an x) can be used as long as the type of x and e is bool.
In addition, you can also quantify away a variable in an expression
by quant\_forall%
\index{quant\_forall}%
{} v e or quant\_thereis%
\index{quant\_thereis}%
{} v e.
\begin{hol}
: !a. ?b. (a XOR b);
T
: let a = variable "a"; let b = variable "b"; let c = variable "c";
a::bool
b::bool
c::bool
: : : a AND b OR c;
a&b + c
:  quant\_forall a (a AND b OR c);
c
: quant\_thereis (a OR c) (a AND b OR c);
T
\end{hol}
In fact, quant\_forall and quant\_thereis quantifies away all variables
in the first Boolean expression.
For example:
\begin{hol}
: let v s = variable s;
v::(string) -> (bool)
: let a = v "a"; let b = v "b"; let c = v "c"; let d = v "d";
a::bool
b::bool
c::bool
d::bool
: : : : let ex = (a AND NOT b);
ex::bool
: ex;
a&b'
: let nex = ex AND (a=c) AND (b=d);
nex::bool
: quant\_thereis (a AND b) nex;
c&d'
\end{hol}
Note that the actual Boolean expression used as first argument is irrelevant.
The only important fact is on what variables the expression depends.

\subsection{Dependencies}

Sometimes it is useful to find out which Boolean variables a
Boolean function actually depends on.
The built-in function depends%
\index{depends}%
{} takes a list of elements of type
bool and return the union of the variables these functions depend on.
For example:
\begin{hol}
: let v s = variable s;
v::(string) -> (bool)
: let a = v "a"; let b = v "b"; let c = v "c"; let d = v "d";
a::bool
b::bool
c::bool
d::bool
: : : : let ex1 = (a=c) AND d;
ex1::bool
: let ex2 = a = b;
ex2::bool
: depends [ex1];
["a","c","d"]
: depends [ex1,ex2];
["a","b","c","d"]
\end{hol}

Note that the order of the variables in the list returned by depends
is the variable order of the OBDD representation.

\subsection{Substitutions}

Given a Boolean function represented as an OBDD, it is convenient to
be able to apply the function to some arguments.
This can be accomplished by the substitute%
\index{substitute}%
{} command that takes a
list of (variable name, expression) and an expression in which the
simultaneous substitution%
\index{substitution}%
{} is to be made.
For example,:
\begin{hol}
: let v s = variable s;
v::(string) -> (bool)
: let a = v "a"; let b = v "b"; let c = v "c"; let d = v "d";
a::bool
b::bool
c::bool
d::bool
: : : : let ex = (a AND NOT b);
ex::bool
: ex;
a&b'
: substitute [("a", c), ("b", d)] ex;
c&d'
\end{hol}

It should be pointed out that there are no restrictions on the expressions
in the substitutions.
In particular, it is possible to ``swap'' variables.
We illustrate this by continuing the example above:
\begin{hol}
: ex;
a&b'
: substitute [("a", b), ("b", a)] ex;
a'&b
\end{hol}

\subsection{Type Abbreviations}
\index{type abbreviations}

Types can be given names:
\begin{hol}
: new\_type\_abbrev pair = int#int;
: let p = (1,2);
p::(int # int)
\end{hol}
However, as can be seen from the example, the system does not
make any distinction between the new type name
and the actual type. It is purely a short hand that is useful when
defining concrete types below.

\subsection{Concrete Types}

New types (rather than mere abbreviations) can also be defined.
Concrete types%
\index{concrete type}%
{} are types
defined by a set of constructors%
\index{type constructor}%
{} which can be used to create objects
of that type and also (in
patterns) to decompose objects of that type. For example, to define
a type card one could use the
construct type:
\begin{hol}
: lettype card = king | queen | jack | other int;
other::(int) -> (card)
jack::card
queen::card
king::card
\end{hol}
Such a declaration declares king, queen, jack and other as constructors
and gives them
values. The value of a 0-ary constructor such as king is the constant
value king. The value of a
constructor such as other is a function that given an integer value
n produces other(n).
\begin{hol}
: king;
- ::card

: other 9;
- ::card
\end{hol}

Note that there is no print routine%
\index{print routine}%
{} for concrete types. If a print
routine is desired, one has to
define it.
To define functions that take their argument from a concrete type,
we introduce the idea of pattern matching%
\index{pattern matching}%
{}.
In particular
\begin{hol}
let f pat1 = e1
 /\verb@\@ f pat2 = e2
 /\verb@\@ ...
 /\verb@\@ f patn = en;
\end{hol}
denotes a function that given a value v selects the first pattern that
matches $v$, say pati, binds the variables of pati to
the corresponding components of the value $v$ and then evaluates the
expression ei.
We could for example define a print function for the cards in the following way:
\begin{hol}
: let pr\_card king = "K"
  /\verb@\@  pr\_card queen = "Q"
  /\verb@\@  pr\_card jack = "J"
  /\verb@\@  pr\_card (other n) = int2str n;
pr\_card::(card) -> (string)
: pr\_card king;
"K"
: pr\_card queen;
"Q"
: pr\_card jack;
"J"
: pr\_card (other 5);
"5"
\end{hol}
If we now issue the top-level command
\begin{hol}
: install\_print\_function pr\_card;
Installed pretty printer for objects of type: card
\end{hol}
\index{install\_print\_function}
every time we evaluate an expression of type card this routine would
be called and the string printed out on standard out.

Mutually recursive types%
\index{mutually recursive types}%
{} can also be defined. To do so, simply list
the type names on the left
hand side of the equality sign and list the type expressions on the
right hand side. For example:
\begin{hol}
: lettype IExpr, BExpr = Ivar string | Plus IExpr IExpr | ITE BExpr IExpr IExpr,
                         And BExpr BExpr | GEQ IExpr IExpr;
GEQ::IExpr->IExpr->BExpr
And::BExpr->BExpr->BExpr
ITE::BExpr->IExpr->IExpr->IExpr
Plus::IExpr->IExpr->IExpr
Ivar::string->IExpr
\end{hol}
defines two mutually recursive concrete data types for integer expressions
and Boolean expressions (very simple versions!).

Currently, FL does not provide any direct way of defining
mutually recursive functions%
\index{mutually recursive functions}%
{}.
The easiest work-around is to pass the later defined functions as
parameters to the earlier function.
After all functions have been defined, one can re-define the early ones.
To illustrate the approach, consider writing functions that converts
objects of type IExpr and BExpr to strings.
One possible solution is as follows:
\begin{hol}
: let prIExpr prBexpr expr =
    letrec prIExpr (Ivar s) = s
     /\verb@\@    prIExpr (Plus a b) = (prIExpr a)^" + "^(prIExpr b)
     /\verb@\@    prIExpr (ITE c t e) = "if "^(prBexpr c)^" then "^
                                 (prIExpr t)^" else "^(prIExpr e) in
    prIExpr expr;
prIExpr::(BExpr->string)->IExpr->string

: letrec prBExpr (And a b) = (prBExpr a) ^ " AND " ^ (prBExpr b)
   /\verb@\@    prBExpr (GEQ a b) = (prIExpr prBExpr a)^" >= "^
			     (prIExpr prBExpr b);
prBExpr::BExpr->string

: let prIExpr e = prIExpr prBExpr e;
prIExpr::IExpr->string
\end{hol}
Note that we simply pass prBExpr as an argument to the initial definition
of prIExpr.

\subsection{Abstract Types}

In FL one can also hide the definitions of types, type constructors,
and functions. By
enclosing a sequence of type declarations and function definitions
within begin\_abstype%
\index{begin\_abstype}%
{}
end\_abstype%
\index{end\_abstype}%
{} elist, only the constructors and/or functions mentioned
in the elist will be visible
and accessible for other functions and definitions. Thus, one can protect
a concrete type and only
make some abstract constructor functions available. To illustrate the
concept, consider defining a
concrete type called theorem. The only way we would like the user to
be able to create a new theorem is to give a Boolean expression that
denotes a tautology (something always true).
First we define the expression type.
\begin{hol}
: lettype expr =  Forall string expr |
                Thereis string expr |
                Var string |
                True |
                False |
                And expr expr |
                Or expr expr |
                Not expr;
Not::(expr) -> (expr)
Or::(expr) -> ((expr) -> (expr))
And::(expr) -> ((expr) -> (expr))
False::expr
True::expr
Var::(string) -> (expr)
Thereis::(string) -> ((expr) -> (expr))
Forall::(string) -> ((expr) -> (expr))
\end{hol}

We then define the concrete type theorem and the constructor function
is\_taut. Note that we
also define a couple of help functions. However, only the is\_taut function
is exported out of the
abstract type%
\index{abstract type}%
{}, and thus is the only way of creating a theorem.
\begin{hol}
: begin\_abstype;
: lettype theorem = Thm expr;
Thm::(expr) -> (theorem)
: letrec assoc x l = l = [] => error "assoc" |
                let h = hd l in
                (fst h) = x => (snd h) | assoc x (tl l);
assoc::(*) -> ((((* # **) list)) -> (**))
: letrec  (eval (Forall s e) al = !x.(eval e ((s,x):al))) /\verb@\@
        (eval (Thereis s e) al = ?x.(eval e ((s,x):al))) /\verb@\@
        (eval (Var s) al = (assoc s al) catch
                                   (error "Free variable")) /\verb@\@
        (eval True al = T) /\verb@\@
        (eval False al = F) /\verb@\@
        (eval (And e1 e2) al = (eval e1 al) AND (eval e2 al))/\verb@\@
        (eval (Or e1 e2) al = (eval e1 al) OR (eval e2 al)) /\verb@\@
        (eval (Not e) al = NOT (eval e al));
eval::(expr) -> ((((string # bool) list)) -> (bool))
: let is\_taut e = ((eval e []) == T) => Thm e |
                                       error "Not a tautology";
is\_taut::(expr) -> (theorem)
end\_abstype is\_taut;
\end{hol}

We can now use this very safe theorem system, since we can only generate
theorems that are
tautologies. For example
\begin{hol}
: let e = (Forall "a" (Thereis "b" (And (Var "a") (Var "b"))));
e::expr
: is\_taut e;
Failure:    ----   Not a tautology

: let f = (Forall "a" (Thereis "b" (Or (Var "a") (Var "b"))));
f::expr
: is\_taut f;
- ::theorem
\end{hol}

\subsection{Infix Operators}

In order to make the FL code more readable, it is possible to declare
a function to be infix%
\index{infix}%
{} (associating from the left), infixr%
\index{infixr}%
{}
(associating from the right), nonfix%
\index{nonfix}%
{} (no fixity at all), prefix
\index{prefix}%
{} (prefix operator with tighter binding than ``normal'' function definitions),
postfix%
\index{postfix}%
{}, or
of a binder%
\index{binder}%
{} type.
For the infix and infixr directives, the precedence can be given as
a number from 1 to 9, where a higher number binds tighter.
Similarly, prefix also takes a precedence number, but only 0 or 1.
Note that prefix and postfix functions bind higher than any infix function.
Beware that the fixity declaration modifies the parser and
thus remains in effect whether
the function is exported out of an abstract data type or note.
As an illustration of this idea, consider the following example:
\begin{hol}
: lettype expr = Var int |
                Mult expr expr |
                Plus expr expr |
                Negate expr;
Negate::expr->expr
Plus::expr->expr->expr
Mult::expr->expr->expr
Var::int->expr
: letrec eval (Var i) = i
  /\verb@\@     eval (Mult e1 e2) = (eval e1) * (eval e2)
  /\verb@\@     eval (Plus e1 e2) = (eval e1) + (eval e2)
  /\verb@\@     eval (Negate e1) = 0-(eval e1);
eval::expr->int
: let ** a b = Mult a b;
**::expr->expr->expr
: let ++ a b = Plus a b;
++::expr->expr->expr
: infix 4 **;
: infix 3 ++;
: let ' i = Var i;
'::int->expr
: prefix 0 ';
: let q = '1 ++ Negate '2 ** Negate '4;
q::expr
: eval q;
it::int
9
\end{hol}

The next example illustrates how postfix declarations can make the
code more readable.
\begin{hol}
: let ns i = 1000*i;
ns::(int) -> (int)
: postfix ns;
: let to a b = (a,b);
to::(*) -> ((**) -> ((* # **)))
: infix 3 to;
: 2 ns to 4 ns;
(2000,4000)
\end{hol}

Our final example deals with the binder declaration.
The command binder takes a function and makes it into a binder, i.e., an
object that introduces a new bound variable in an expression.
Note that the type of the function declared to be a binder must be
(*\funarrow **)\funarrow string\funarrow **, since the first argument of
a binder function will be a lambda expression and the second argument will
be a string with the name of the bound variable.
Thus, if a function f has been declared as a binder, then
f x.E will be parsed as f (\protect\verb!\! x.E) "x".

\subsection{Overloading}

FL supports a limited amount of user defined overloading%
\index{overloading}%
{} of functions
and operators.
However, in order to avoid an exponential type inference algorithm, the
overloaded operators must be resolved from the types of their arguments only.
To illustrate the construct, consider the following example:
\begin{hol}
: let pplus (a,b) (c,d) = (a+c, b+d);
pplus::(int#int)->(int#int)->(int#int)
: let pprod (a,b) (c,d) = (a*c, b*d);
pprod::(int#int)->(int#int)->(int#int)
: overload + + pplus;
: overload * * pprod;
: (1,2)+(3,4)*(9,3*2);
it::int#int
(28,26)
\end{hol}
Here we overloaded the symbols + and *.
Note that we essentially added new meanings to + and * since we included
the (built-in) versions as possible candidates.

The one area where overloaded operators are somewhat cumbersome to use is
when defining new functions.
Here it is often necessary to decorate the arguments to the functions
in order to make the resolution function succeed.
\begin{hol}
: let f x y z = x*(y+z);
===Type error around line 1
Cannot resolve overloading of `+'
Both `pplus' and `+' matches the type
: let f \{x::int\} \{y::int\} \{z::int\} = x*(y+z);
f::int->int->int->int
\end{hol}
Finally, overloaded operators and functions can of course also
be declared infix, binders, or postfix as any other function or operator.

\subsection{Quotation of Expressions}
\index{quotation of expression}
Sometimes it is convenient to retain the actual text that was used
to denote an expression.
By enclosing the expression in \verb@``@ and \verb@''@, FL will return
a pair consisting of the text of the expression as well as the expression
itself.
\begin{hol}
: `` 1+3*4 '';
it::string#int
(" 1+3*4 ",13)
\end{hol}
Note that it is advisable to include an extra space after the opening quotes
and before the closing quotes since the parser otherwise is likely to
view the quotes as being part of an operator or variable.

\subsection{Circuit Models}

Since the main use of the FL system, and its historical root, is related
to hardware verification, there are a number of built-in
functions specifically tailored towards hardware modeling
and symbolic trajectory evaluation in particular.
Internally, a circuit is represented by a list of nodes (names),
and a next state function%
\index{next state function}%
{}.
The next state function is mapping the current state of the circuit
(including the current values on the inputs) to a new state
of the circuit.
Since the circuit representation is intended for trajectory evaluation,
the value domain for each node in the circuit is $\{0,1,\X,\top\}$
and thus the next state function consists of quaternary%
\index{quaternary}%
{} (four-valued)
extensions of the usual Boolean function.
The type of such circuit is fsm%
\index{fsm}%
{} (for finite state machine%
\index{finite state machine}%
{}) and, by
default, it does not have a print function (since the machines
are usually much too large to be meaningful anyway to the user.
However, for the curious reader, the command print\_fsm%
\index{print\_fsm}%
{} will print out
a pretty complete version of the state machine.
Note that for efficiency reasons, the next state function also
contains delay and fan-in and fan-out information to aid in the
efficient simulation.

In general, there are two ways of creating a fsm object:
\begin{enumerate}
\item
Loading a pre-compiled version of a circuit in .exe format.
\item
Converting a FL structure into an fsm.
\end{enumerate}

\subsubsection{Loading a .exe File}

If the original circuit was described in Berkeley .sim format or
as a SILOS II gate list, there are programs distributed with the
system that can be used to compile an fsm model directly from
these formats.
The common format for such pre-compiled circuit model is a (binary)
file with a .exe%
\index{.exe file}%
{} suffix.
%In Section~\ref{CompanionTools} we discuss in more detail how
%to create such .exe file.
Loading in the .exe file and making it an fsm object simply
involves calling the load\_exe function.

For example, if there is a full\_adder.exe file in the current
working directory, the following command would create an fsm object
of the circuit.
\begin{hol}
: let ckt1 = load\_exe "full\_adder.exe";
ckt1::fsm
\end{hol}
Note that there is no theoretical limit on the number of circuit that can
be loaded into the FL system at any particular point in time.
However, since fsm models are often quite large, it is generally
advisable not to load more models than absolutely necessary.
%(In most cases, only one model will be used, but there are times
%when several models can be useful. We will return to this later
%in Section~\ref{ModelChecking}.)

\subsubsection{Creating an fsm Object Inside FL}
\label{makeSTEsection}

{\bf Warning:} This addition is fairly young and has thus not
been extensively tested. Also, it leaves quite a bit to
be desired in terms of not being very ``clean and simple''.
For a reader that is more interested in using the Voss system rather
than writing a new conversion program from some other netlist format, this
section can be skipped.

The main routine for creating an fsm object is make\_fsm%
\index{make\_fsm}%
{}.
The type of make\_fsm is (Set)\funarrow (fsm)\footnote{Currently, when
FL is invoked, the type of make\_fsm is actually (*)\funarrow (fsm), but
this is a bug that will be removed in the next release.}
Before going into how an object of type Set%
\index{Set}%
{} can be constructed, we
need to make a small digression and introduce the quaternary logic type.
For historical reasons, the name of the quaternary objects is tern%
\index{tern}%
{},
and tern is defined as the concrete type:
\begin{hol}
: lettype tern =  One |
                Zero |
                X |
                Z |
                Val string |
                And tern tern |
                Or tern tern |
                Not tern |
                Glb tern tern |
                Lub tern tern;
Lub::tern->tern->tern
Glb::tern->tern->tern
Not::tern->tern
Or::tern->tern->tern
And::tern->tern->tern
Val::string->tern
Z::tern
X::tern
Zero::tern
One::tern
\end{hol}
where One%
\index{One}%
{}, Zero%
\index{Zero}%
{}, X%
\index{X}%
{},  And%
\index{And}%
{}, Or%
\index{Or}%
{}, and Not%
\index{Not}%
{} are the obvious functions.
Glb%
\index{Glb}%
{} stands for the greatest lower bound and Lub%
\index{Lub}%
{} for the least upper bound.
Z%
\index{Z}%
{} is used to represent the top value%
\index{top value}%
{}.
Finally, Val%
\index{Val}%
{} s is used to refer to the value on node s.
Thus, as a concrete example, the next state function of a node "o" may
be described as (Not (And (Val "in1") (Val "in2"))).

There are four constructor functions for an object of type Set:
\begin{enumerate}
\item
Empty%
\index{Empty}%
{},
\item
Element%
\index{Element}%
{} (string\verb@#@((tern\verb@#@tern) list)),
\item
Union%
\index{Union}%
{} Set Set, and
\item
Sequential%
\index{Sequential}%
{} Set Set.
\end{enumerate}
The Empty is introduced to make writing functions that generate
objects of type Set easier.
Element is the constructor that actually introduces new nodes and
also give driver functions for the node.
In general, Element n gvl, will create a node named n.
This node will at least have (more about this later) the drivers
listed in the gvl list.
A driver is simply a pair of quaternary expressions:
the first object of the pair is a guard, and the second part
is the value being driven when the guard is true.
For a combinational node, the driver list is a single pair whose
guard is One and whose value component is the next state function
of the gate.
For more complex nodes, like register nodes or bus nodes, the guard-value
list is often much longer.

The Union construct is used to gather a collection of these Element
declarations so that an fsm can eventually be made.
Finally, the Sequential constructor takes two objects S1 and S2 of
type Set and merges them into a single object of type Set.
In that sense, Sequential behaves exactly like Union.
The difference is how the two deal with nodes defined in both set S1 and set S2
and for which both nodes may have at least one of their guards enabled
at the same time.
Union will find the greatest lower bound of the values being driven
at the same time whereas Sequential will assume that the driver in the
second set overrides the driver in the first.
To illustrate the difference, consider the following example:
\begin{hol}
: let a = Element ("in1", [(One, One)]);
a::Set
: let b = Element ("in1", [(One, Zero)]);
b::Set
: let ex1 = Union a b;
ex1::Set
: let ex2 = Sequential a b;
ex2::Set
: let m1 = make\_fsm ex1;
m1::fsm
: let m2 = make\_fsm ex2;
m2::fsm
: m1;
\end{hol}
Now m1 and m2 will both be fsm models with a single node called in1.
However, in m1, the next state function of in1 will be $\X$, since that
is the most we can say from the inconsistent driver commands given
in the example.
On the other hand, the next state function of the in1 node in m2 will be Zero.

For an example of using this facility, the directory HDL in the demo
distribution illustrates how one can go about defining a new description
language in order to create an fsm object.

\subsection{Queries to the Circuit Model}

There are five built-in functions that are useful in dealing with
an fsm model: nodes%
\index{nodes}%
{}, fanin%
\index{fanin}%
{}, fanout%
\index{fanout}%
{}, is\_stable%
\index{is\_stable}%
{}, and get\_node\_val%
\index{get\_node\_val}%
{}.
Nodes takes an fsm model and returns a {\em list of lists} of circuit nodes.
The reason for the double listing is that a node may have more than
one name (only from .exe file translations).
Fanin takes an fsm model and a name of a node and returns the
list of node names that the next state function depend on.
Fanout works in a similar way, but for the fanout nodes.
Is\_stable returns T (true) if the circuit is currently stable.
It is mainly used when the simulation is aborted at some
particular time with the "-m" option to STE.
Finally, get\_node\_val takes an fsm object and the name of a node
and returns the encoded version of the current value of the node.
The encoding used is: $\X = (T,T)$, $1=(T,F)$, $0=(F,T)$, and $\top=(F,F)$.
Of course, the two Boolean values are often Boolean functions over some
variables.
The main use of the get\_node\_val function is when the simulation
is aborted for some reason.
Get\_node\_val can then be used to probe the current state of the system.
For example, assuming there is a full\_adder.exe file in the current
working directory, we would get:
\begin{hol}
: let ckt = load\_exe "full\_adder.exe";
ckt::fsm
: nodes ckt;
..[["cout"],["t4"],["t3"],["t2"],["result"],["cin"],["t1"],["b"],["a"]]
: fanin ckt "cout";
["t2","t3","t4"]
: fanout ckt "t3";
["cout"]
: fanout ckt "t4";
["cout"]
: fanout ckt "a";
["t3","t2","t1"]
: get\_node\_val ckt "t2";
..(T,T)
\end{hol}

If the user also loads in the "default.fl" standard library, there is
the very useful function {\em excitation}%
\index{excitation}
that also takes an fsm model
and a node name, but that returns the next state function for binary inputs.
Note, however, that the current version of the excitation function
only works correctly for unit delay nodes.
\begin{hol}
: load "defaults.fl";
-Loading file defaults.fl
T

: excitation ckt "cout";
....
Trace started for node: cout
        Current value:X
.Time: 1
.Trace: Node cout  at time 1: t4' + t3' + t2'
Time: 2

Trace ended for node: cout
"t4' + t3' + t2'"
\end{hol}
We will return to this in Section~\ref{vossrc}.

\subsection{Symbolic Trajectory Evaluation}

There is actually only one built-in command for symbolic trajectory%
\index{symbolic trajectory evaluation}%
{}
evaluation called STE%
\index{STE}%
{}.
In general, STE determines, through symbolic trajectory evaluation, whether
an antecedent/consequent pair hold in for some circuit.
STE will return a Boolean function that gives the condition for the
verification to succeed.
For most applications the desired return value is T.

In general STE is invoked as
\begin{hol}
STE options fsm weak\_list ant\_list cons\_list trace\_list
\end{hol}
where options%
\index{STE options}%
{} is a string that can contain a combinations of the
following flags:
\begin{description}
\item[-a] Abort%
\index{abort STE}%
{} the verification at the first antecedent or consequent failure.
If the verification is aborted, STE will return a Boolean function that
gives {\em the condition for this failure to manifest itself}.
Note that this is contrary to STE's usual behavior which is to return
the Boolean function that gives the conditions for the verification to
succeed.
\item [-m n]
Abort the verification after reaching time n.
\item [-e]
Evaluate evey node in the circuit whether the node is in the
fan-in tree of some node that is checked or traced or not.
In other words, with the -e option, the simulator will compute
the value on every node. Normally, a node whose value
cannot be observed (directly or indirectly) is simply kept at X.
Of course, the STE command can run significantly slower with the
-e option, so beware!
\item [-i]
Allow antecedent failures%
\index{antecedent failures}%
{}.
In other words, compute a straight implication.
The normal behavior of the verification process is to disallow
antecedent failures.
Thus the default verification condition is both to check that every
trajectory the circuit can go thorough that is consistent with the
antecedent is also consistent with the consequent, and that there
is at least one (real) circuit trajectory that is consistent
with the antecedent.
\item [-n]
Allow over-constrained values, i.e., allow nodes to take
on the top value in the value lattice.
Normally, over-constrained values are viewed as failures.
\item[-w]
Do not print out warning messages%
\index{warning messages}%
{}.
\item[-t s]
In addition to printing out trace messages on stderr, also send
the trace events in Postscript%
\index{Postscript waveform}%
{} format to the file s.
By previewing or printing out the file the user gets a waveform diagram for
the traced signals.
\item[-T s]
Same as -t, but generate Postscript code in landscape mode.
\end{description}

The second argument to STE must be an object of the fsm type representing
a circuit that is to be simulated.

The weak\_list is a list of 4-tuples.
Each 4-tuple is of the form (g,n,f,t), where $n$ is a node name, $f$ and $t$
denote start and stop times, and $g$ is a Boolean function
denoting the domain for which this node should be weakened%
\index{weakened}%
{}.
For assignments making the guard true, the next state function of the
circuit node is set to $X$.
This is often useful when verifying a subsystem of a larger system
that has shared input signals.
By weakening%
\index{weakening}%
{} the model, unnecessary computations does not have
to be performed.
Note that weakening a model is a ``safe'' operation in that
the monotonicity of the circuit models guarantee that if we
can verify something in the weakened model, then that same property
is guaranteed to hold in the original model.

The ant\_list and cons\_list are  both lists of five-tuples.
Each five-tuple%
\index{five-tuple}%
{} is of the form $(g,n,v,s,t)$, where $g$ is a Boolean function
denoting the domain for which this assertion/check should be carried out,
$n$ is the name of a node, $v$ is the value to be asserted/checked, and
$s$ and $t$ denote the start and stop times for this assertion/check
respectively.

Finally, the last argument to STE is a list of triples.
Each triple is of the form $(n,s,t)$, where $n$ is a name of a node
to be traced%
\index{traced}%
{} and $s$ and $t$ are the start and stop times for this
trace respectively.

Of course, in practice, it would be quite tedious to have to
write all specifications in terms of lists of five-tuples.
Consequently, a small language (actually a small set of useful functions)
has been defined in the library file "verification.fl".
These functions make it much easier to write specification.
However, it should be remembered that when the verification
is actually performed, all these higher level constructs gets translated
down to the two lists of five-tuples.

For more details on how to use the STE function, we refer the reader
to Section~\ref{tutorial}.


\documentclass[xcolor=dvipsnames]{beamer}

\usepackage[utf8]{inputenc}
\usepackage{default}
\usepackage{beamerthemesplit}
\usepackage{tikz}
\usetikzlibrary{positioning,shapes,arrows}
\usetheme{Berkeley}
\usecolortheme[named=Black]{structure}

\title[]{Floating Base Rigid Body Dynamics Estimation}
\author[]{Francesco Nori, Jorhabib Eljaik}
\date{\today}

\begin{document}
% \maketitle

\begin{frame}
 \titlepage
\end{frame}

\begin{frame}
 \frametitle{Table of contents}
 \tableofcontents
\end{frame}

\section{Introduction}
\begin{frame}
  \frametitle{Sensor fusion on the iCub}
\begin{figure}
  \centering
	  \includegraphics[height=0.55\hsize]{images/png/FT.png}
	  \includegraphics[height=0.55\hsize]{images/png/acc.png}
	  \includegraphics[height=0.55\hsize]{images/png/gyroAcc.png}
\end{figure}
\end{frame}

\begin{frame}
  \frametitle{Sensor fusion on the iCub}
\begin{figure}
  \centering
	  \includegraphics[height=0.55\hsize]{images/pdf/rigidBody.pdf}
\end{figure}
\end{frame}

\begin{frame}
  \frametitle{Sensor fusion on the iCub}
\begin{figure}
  \centering
	  \includegraphics[height=0.55\hsize]{images/pdf/foot.pdf}
\end{figure}
\end{frame}

\begin{frame}
  \frametitle{Sensor fusion on the iCub}
 \begin{eqnarray*}
m    \dot v^B    + \omega^B \times (m       v^B) & = & f^B_1  + ... + f^B_n + mg^B \\
I^B \dot \omega^B + \omega^B \times (I^B \omega^B) & = & \mu^B_1 + ... + \mu^B_n
\end{eqnarray*}
\begin{itemize}
\item $I^B$    : inertia in the body reference frame
\item $m$      : mass of the rigid body
\item $f^B_i$  : i-th force expressed in the body reference frame
\item $\mu^B_i$ : i-th torque expressed in the body reference frame
\item $\omega^B$: angular velocity expressed in the body reference frame
\item $v^B$    : linear velocity in the body reference frame
\item $q$      : quaternion representing the rigid body orientation
\end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Sensor fusion on the iCub}
 \begin{eqnarray*}
m    \textcolor{red}{\dot v^B}    + \omega^B \times (m       v^B) & = & \textcolor{red}{f^B_1  + ... + f^B_n} + mg^B \\
I^B \dot \omega^B + \omega^B \times (I^B \omega^B) & = & \textcolor{red}{\mu^B_1 + ... + \mu^B_n}
\end{eqnarray*}
\begin{itemize}
\item $I^B$    : inertia in the body reference frame
\item $m$      : mass of the rigid body
\item \textcolor{red}{$f^B_i$}  : i-th force expressed in the body reference frame
\item \textcolor{red}{$\mu^B_i$} : i-th torque expressed in the body reference frame
\item \textcolor{green}{$\omega^B$}: angular velocity expressed in the body reference frame
\item \textcolor{red}{$\dot v^B$}    : linear acceleration in the body reference frame
\item $q$      : quaternion representing the rigid body orientation
\end{itemize}
\end{frame}

\section{Bayesian Network for a Floating Base Rigid Body System}
\begin{frame}
 \frametitle{Bayesian Network for a Floating Base Rigid Body System}

 \centering
 \begin{tikzpicture}[
  node distance=1cm and 0cm,
  mynode/.style={draw,circle,text width=1cm,align=center}
  ]
  \node[mynode] (x) {$x$};
  \node[mynode,below=of x] (y) {$y$};
  \path (x) edge[-latex] (y);

  \node[right=of x, right=0.5cm of x]
  {
  $x = \left[ v^B \quad \omega^B \quad f_o \quad \mu_o \quad f_c \quad \mu_c \right]^T$
   };

   \node[right=of y, right=0.5cm of y]
   {
   $y = \left[ f_o \quad \mu_o \quad f_c \quad \mu_c \quad \dot{v}^B \right]^T$
   };
 \end{tikzpicture}

\end{frame}

\section{The Extended Kalman Filter}
\begin{frame}
  \frametitle{The Extended Kalman Filter}
  Given a nonlinear system:
  \begin{align}
   y_k &= h(x) + \rho_m \\
   x_k &= f(x_{k-1}) + \rho_p
  \end{align}

  Where $y$, the measurement vector and $x$, the state vector have gaussian uncertainties.

  After linearizing our dynamical system about an estimate of the current state ${x}_{k|k-1}$, the corresponding Extended Kalman Filter can be obtained following a \textbf{prediction} and \textbf{update} steps.
  \begin{alertblock}{Prediction}
    $\mathbf{x}_{k|k-1} = f(\mathbf{x}_{k-1|k-1})$
  \end{alertblock}

  \begin{alertblock}{\textbf{Update}}
    $\mathbf{x}_{k|k} = x_{k|k-1} + K_k(y_k - h(\mathbf{x}_{k|k-1}))$
  \end{alertblock}
\end{frame}

\begin{frame}
  \frametitle{The Extended Kalman Filter}
 Linearized measurement model: $y = Cx + e$ where:\\
 y = \begin{pmatrix}
  0& 0& \mathbf{I}& 0& 0& 0\\
  0& 0& 0& \mathbf{I}& 0& 0\\
  0& 0& 0& 0& \mathbf{I}& 0\\
  0& 0& 0& 0& 0& \mathbf{I}\\
  S(\bar{\omega}_B)& -S(\bar{V}_B)& \mathbf{I}& 0& \mathbf{I}& 0
 \end{pmatrix} x
+ \begin{pmatrix}
   0\\
   0\\
   0\\
   0\\
   S(\bar{V}^B)\bar{\omega}^B
  \end{pmatrix}
\end{frame}

\begin{frame}
  \frametitle{Extended Kalman Filter results}
  Linear Velocities smoothing
\begin{figure}
  \centering
	  \includegraphics[height=0.70\hsize]{images/png/linVel.png}
\end{figure}
\end{frame}

\begin{frame}
  \frametitle{Extended Kalman Filter results}
   Angular velocities smoothing
\begin{figure}
  \centering
	  \includegraphics[height=0.70\hsize]{images/png/angVel.png}
\end{figure}
\end{frame}

% \section{Update Step of the Kalman Filter as a Bayesian Network}
% \begin{frame}
%   \frametitle{Update Step of the Kalman Filter as a Bayesian Network}
%   \textbf{Update Step} $\leftrightarrow $ \textbf{Conditional probability of} $\mathbf{x}_{k|k-1}$ \textbf{given} $\mathbf{y}_k$ \\
%   in other words, we can also obtain $\mathbf{x}_{k|k}$ as:
%   \begin{equation}
%   \mathbf{x}_{k|k} = E[x_k \; \vert \; y_k, x_{k|k-1}]
%   \end{equation}
%   Where:
%   \begin{align}
%   \mathbf{y}_k \vert_{x_{k|k-1}} &\backsim \mathcal{N}(C\mathbf{x}, R) \\
%   \mathbf{x} &\backsim \mathcal{N}(x_{k|k-1},P_{k|k-1})
%   \end{align}
%
%   And $\mathbf{y}$ has been linearized as: $y=Cx + e$
% \end{frame}

% \section{Solving a Linear System with a Bayesian Network}
% \begin{frame}
%   \frametitle{Solving a Linear System with a Bayesian Network}
%   Given a linear system $\mathbf{Ax} = \mathbf{b}$, the computation of the solution vector $\mathbf{x^*}$ is identical to the inference of the vector of marginal means $\mu = \{\mu_1, ... , \mu_n\}$ over the graph $\mathcal{G}$ with the associated Joint Gaussian Probability Density Function
%
%  \begin{equation}
%   p(\mathbf{x}) \backsim \mathcal{N}(\mu \triangleq \mathbf{A}^{-1}\mathbf{b}, \mathbf{A}^{-1})
%  \end{equation}
%
%  The mean of this probability distribution is the target solution. The solution of the system implies inferring the marginal densities:
%
%  \begin{equation}
%   p(x_i) \backsim \mathcal{N}(\mu_i = \{\mathbf{A^{-1}}\mathbf{b}\}_i,P^{-1}_i = \{\mathbf{A}^{-1}_{ii})
%  \end{equation}
%
%  Where $\mu_i$ and $P_i$ are the marginal mean and inverse variance.
%
% %  Reference: Gaussian Belief Propagation Solver for Systems of Linear Equations. Ori Shental 1 , Paul H. Siegel and Jack K.   Wolf, Danny Bickson and Danny Dolev
% \end{frame}

\end{document}


\section{Debugging}%
\label{sec:debugging}%
\subsection{Net Weights}
\label{subsec:net_weights}
%
In an attempt to better understand the source of this unexpected behavior,
multiplicative weights (referred to as `nw' for `network weights' in
Fig.~\ref{fig:bad_convergence}) were introduced to scale the individual
contribution from each of the `learned' functions $S$, $T$, and $Q$,
explicitly:
%
\begin{align}
  S &\rightarrow \alpha_{S}\, S \\
  T &\rightarrow \alpha_{T}\, T \\
  Q &\rightarrow \alpha_{Q}\, Q.
\end{align}
%
By varying each of these weights individually allows us to selectively `tune'
how much each of these functions contribute when running inference on the
trained model.
%
Note that in the limit $\alpha_{S}, \alpha_{T}, \alpha_{Q} \rightarrow 0$, we
recover generic HMC, and as can be seen in Fig.~\ref{fig:bad_convergence},
the error in the average plaquette $\delta_{\phi_{P}} \simeq 0$, as expected.
%
As an additional sanity check, we looked at how the error in the average
plaquette behaves for different values of the weights $\alpha_{i}$ ($i = S, T,
Q$).
%
Explicitly, beginning with $\vec{\alpha} \equiv [\alpha_{S}, \alpha_{Q},
\alpha_{T}] = [0, 0, 0]$, we increase each of the weights one by one and compute
the average value of the plaquette difference.
%
For example, the blue line (Transformation $(Q)$ function) in
Fig.~\ref{fig:plaq_diff_vs_net_weights} was obtained by keeping both
$\alpha_{S}$ and $\alpha_{T}$ fixed and $0$ and varying $\alpha_{Q} \in
[0.1, 0.25, 0.5, 0.75, 1.0, 1.5, 2.0, 5.0]$, and similarly for $\alpha_{S}$ and
$\alpha_{Q}$.
%
\begin{figure}
  \centering
  \begin{subfigure}[t]{0.48\textwidth}
    \caption{$N_{LF} = 10$}
    \includegraphics[width=\textwidth]{new_figures/plaq_error/plaq_diff_vs_net_weights_lf10.pdf}
  \end{subfigure}
  % \vspace{2pt}
  % \hfill
  % \centering
  \begin{subfigure}[t]{0.48\textwidth}
    \caption{$N_{LF} = 12$}
    \includegraphics[width=\textwidth]{new_figures/plaq_error/plaq_diff_vs_net_weights_lf12.pdf}
  \end{subfigure}
  % \vspace{2pt}
  \begin{subfigure}[b]{0.48\textwidth}
    \caption{$N_{LF} = 16$}
    \includegraphics[width=\textwidth]{new_figures/plaq_error/plaq_diff_vs_net_weights_lf16.pdf}
  \end{subfigure}
  \caption{Plaquette difference $\delta_{\phi_{P}}$ for different values of the
    net weights $\vec{\alpha} \equiv [\alpha_{S}, \alpha_{T}, \alpha_{Q}]$.
    Note that $\delta_{\phi_{P}} \rightarrow 0$ as $\vec{\alpha} \rightarrow
  [0, 0, 0]$, as expected.}%
\label{fig:plaq_diff_vs_net_weights}
\end{figure}
%
These results seem to indicate that each of the individual functions contribute
separately to the error, with the scaling ($S$) and translation ($T$) functions
having the largest effect.
%  }}}
\subsection{Updates (11/11/2019)}
\begin{todolist}
  \item[\done] Ensure reproducibility across training/inference runs when
    using same input parameters.
    \begin{itemize}
      \item Essential for debugging the bias in the average plaquette.
      \item Somewhat tricky problem due to the fact that tensorflow
        has two distinct methods of specifying a seed: graph-level and
        operation-level. Additionally, when using horovod for distributed
        training across multiple ranks, we must ensure that each rank gets a
        different seed otherwise they will all be training identical copies of
        the model.
    \end{itemize}

  \item[\done] Implement reversibility checker that ensures that the L2HMC
    dynamics (i.e.\ the augmented HMC sampler) is reversible.
    \begin{itemize}
      \item Starting with $\xi = (x, v, d)$, run the dynamics in the forward
        direction to get $\xi^{\prime}$. If $\mathbf{L}_{\theta}
        \xi =  \xi^{\prime}$, and $\mathbf{F} \xi = \mathbf{F} (x, v, d) = (x,
        v, -d)$, then a complete (invertible) update step can be written as
        $\mathbf{FL}_{\theta}\xi = \xi^{\prime}$.
        %
      \item If our sampler is reversible, running the dynamics backwards on
        $\xi^{\prime}$ should return us to the original state $\xi$.
        %
        \begin{equation}
          \mathbf{FL}_{\theta}\mathbf{FL}_{\theta} \xi = \xi
        \end{equation}
    \end{itemize}

  \item[\done] Try increasing floating point precision (\texttt{tf.float32 -->
    tf.float64}) (\textbf{\textcolor{red}{Error still present.}})

  \item[\done] Try anti-symmetric Gaussian Mixture Model and see if the trained
    model is an accurate representation of the target distribution (e.g.\ by
    looking at the locations of the means).
    % \href{https://l2hmc.slack.com/archives/CK0SMC6NS/p1567623563026900}{(link
    % to post)}.

  \item[\done] At James' suggestion, we decided to look at the
    kinetic/potential energies and the Hamiltonian at the beginning and end of
    each trajectory (\textbf{\textcolor{red}{Solved! Issue was being caused by
    unexpected resampling of the momentum}}).
    % Fig~\ref{fig:potential_energy},~\ref{fig:kinetic_energy},~\ref{fig:hamiltonian}).
  \end{todolist}
\section{GMM Results}%
\label{sec:gmm_results}
\begin{figure}[htpb]
  \centering
  \includegraphics[width=0.5\textwidth]{updates/single_chain}
  \caption{Inference run shown for a single chain using the L2HMC
  sampler trained on this gaussian mixture model.}%
  \label{fig:gmm_single_chain}
\end{figure}

\begin{figure}[htpb]
  \centering
  \begin{subfigure}[t]{0.48\textwidth}
    \caption{L2HMC samples}
    \includegraphics[width=\textwidth]{updates/means_hist_observed}
  \end{subfigure}
  % \hfill
  \begin{subfigure}[t]{0.48\textwidth}
    \caption{true target distribution}
    \includegraphics[width=\textwidth]{updates/means_hist_true}
  \end{subfigure}
  \caption{Histograms of $\langle x\rangle$ and $\langle y\rangle$ in this
  two-dimensional target space.}
\end{figure}
% }}}


\chapter{Long-term surface water change detection}
\label{ch5}

\begin{abstract}
	Methods to detect long-term surface water changes are discussed. A simple method based on reflectance percentile composites and linear regression is presented. As an example, Siling Lake in the Tibetan Plateau is used as a study area. The advantages and drawbacks of the method are discussed.

	\begin{center}
		\begin{tikzpicture}[every node/.style={inner sep=0,outer sep=0}]
		\node[draw=none,shade,blur shadow={shadow blur steps=5}] {
			\includegraphics[width=3in]{01.4-change-detection/figures/change-detection-dubai}
		};
		\end{tikzpicture}
	\end{center}

	\textbf{Keywords:} $M_3$, reflectance percentiles, NDWI, linear regression, long-term surface water changes.

\end{abstract}

{
	\setlength{\parindent}{0pt}This chapter is based on \bibentry{donchyts2016earth}.
}

%% Start the actual chapter on a new page.
\newpage

\section{Introduction}
\dropcap{A}{s} we have seen in the previous three chapters, accurate surface water detection is a complex task and may require many steps. However, different land use changes may occur at different temporal scales. If we are interested only in long-term (inter-annual) land-use changes, more generic statistical methods can be applied to detect these changes. With sufficient observations available and under the assumption that statistics of reflectance values for different years remain the same, we can use relatively simple methods, when compared to those discussed in the Chapter \ref{ch4}.

The first step that should be done when analyzing optical passive sensor satellite imagery is the elimination of clouds and cloud shadow effects. Cleaning images from cloud, cloud shadows, and snow can be a challenging and time-consuming process, especially when images partially covered by clouds need to be considered. Many methods were developed to do this properly, as has been discussed in chapters \ref{ch2}, \ref{ch3}, and \ref{ch4}. These methods can be used to construct completely cloud-free images, or to extract information required to analyze temporal changes in different land cover classes.

As an alternative to this, we can generate inter-annual composites directly from the top-of-atmosphere or surface reflectance values. In recent years, this approach was used in \citet{Hansen2013} to study forest cover changes by employing a combination of metrics, such as:
\begin{enumerate*}[label=(\emph{\alph*})]
	\item selected percentile values
	\item mean reflectance values for selected percentile ranges
	\item slope of linear regression of band reflectance values versus image date
\end{enumerate*}. Furthermore, they make use of supervised classification methods based on decision trees to relate these metrics to homogeneously varying subsets of data.

Here, a similar approach to estimate long-term surface water changes is introduced. However, instead of developing multiple metrics like in \citet{Hansen2013}, a single combined metric employing percentiles is used to estimate average cloud-free reflectance values and the slope of linear regression to identify pixels where long-term changes have been occurring.

The resulting method is also more resource efficient because applying linear regression after averaging is cheaper to compute. The cost of applying linear regression directly to reflectance values is $O(n^3)$, and the cost to calculate the average value for every pixel is $O(n)$, where n is the number of analyzed images. The $O$ notation is frequently used in computer science to indicate scalability of the algorithm with the growth of the dataset. By employing a two-step approach, surface water changes can be estimated in almost $O(n)$ time, making it attractive to be applied across multiple sensors, assuming similarity in reflectance values among different satellite sensors for some spectral bands. For surface water change studies, the most used spectral index is \gls{NDWI}. The index uses near-infrared and green bands. These bands have similar spatial and spectral resolution across multiple Landsat missions and seem to be in agreement with regards to spectral response and spectral resolution, except for Landsat 8. For Landsat 8, the OLI sensor covers the thinner spectral range for the near-infrared band when compared to TM and ETM+ sensors used by Landsat 4, 5, and 7 \citet{roy2016characterization, angal2014cross}. A detailed comparison of spectral responses between Landsat 5 and 7 can be found in \citet{teillet2001radiometric} and between Landsat 7 and 8 in \citet{flood2014continuity}. Additionally, the literature says that data produced from Landsat was cross-calibrated to ensure consistency and continuity of values between different missions \citet{mishra2014radiometric}. This makes combining images across different Landsat sensors, and the use of statistical methods to process their values, very promising.

\begin{figure}[H]
	\includegraphics[width=1.0\textwidth,left]{01.4-change-detection/figures/aral}
	\caption{Aral Sea, Uzbekistan. False-color reflectance percentile composite (swir1, nir, green, 20\%). The red circle indicates the location where reflectance and \gls{NDWI} values shown on charts were plotted. The composite images and the time series were computed from 4325 Landsat scenes between 1984 and 2017. \opt{source}{Source: \url{https://code.earthengine.google.com/c1ccc09c6b5e7d73bd3a3601f8edfaf3}}}
	\label{fig:ch4-aral-sea}
\end{figure}

Surface water is very dynamic and may change on a daily, monthly, and annual basis. To estimate long-term, inter-annual surface water changes from raw satellite images, we have to exclude effects caused by both clouds and by intra-annual or seasonal variations, assuming these changes remain the same across years. Examples of intra-annual changes can be seasonal changes in surface water due to natural processes, a regular water cycle, changes of surface water levels caused by tidal effects in coastal areas, and variability in surface water levels due to man-made activities, such as the operation of reservoirs, which may also cause surface water changes in the downstream rivers. Long-term surface water changes may be due to natural changes of water boundaries, such as erosion or accretion, natural changes caused by climate changes, or manmade changes in rivers or coastal zones (embankments, land reclamation, construction of reservoirs).

In reality, a combination of these surface water changes may occur and interfere with each other, making the task of surface water change detection extremely difficult.

To demonstrate the variability of reflectance values in different bands for an area where both long and short-term changes took place, a long-term time series in the middle of the Aral Sea is obtained for pixels which have dried up during the past few decades, as shown in Figure \ref{fig:ch4-aral-sea}. This area has faced dramatic changes regarding surface water and, as can be seen from the reflectance values, this has influenced both reflectance and corresponding \gls{NDWI} value changes. While it would be possible to detect the trend of \gls{NDWI} values from the raw reflectance value time series, doing this may be less efficient, mainly because \gls{NDWI} values for many pixels corresponding to clouds may look very similar to the values corresponding to water. Additionally, it would require significantly more computing resources.

\section{Long-term surface water change detection}

To address long-term surface water changes, we can first try to exclude short-term variability of reflectance values by computing average images for a long time intervals, excluding effects of clouds and cloud shadows in this way. By estimating this type of composite images for multiple time intervals, followed by the application of spectral water indices, such as \gls{NDWI}, we should be able to reconstruct long-term variability of the surface water changes, which will be reflected in the variability of the \gls{NDWI} values. One of the important questions arising using this method is how to select the best percentile, allowing to minimize the effect of clouds and cloud shadows, and at the same time, avoiding the appearance of cloud shadows in the images.

The method will work only if a sufficient number of observations is available. A large number of images is required to ensure that the distribution of values, used to compute reflectance percentile composites, converges to the actual distribution representing different land or atmosphere values for a given location  is based on similar distributions. Ideally, the resulting percentile should look the same for two areas when no long-term surface water changes take place.

Because surface water has a very distinctive spectral signature, with very low reflectance values in almost all bands, the presence or absence of water in a given pixel will be reflected in the final distribution represented as a probability distribution function (PDF) or a cumulative distribution function (CDF) for a given location.

\afterpage{%

	\begin{figure}
		\includegraphics[width=1.0\textwidth,left]{01.4-change-detection/figures/Tibet-lake-changes}
		\caption{Siling Lake, Tibetan Plateau, China. Two reflectance composite images at the top-left show how the lake looked like in 80's (left) and how it looks like today (right). The blue color indicates submerged land due to climate changes. \opt{source}{Source: \url{https://code.earthengine.google.com/87d0057d8b3d28817b1da7cfc1bd6b6e}}}
		\label{fig:ch4-tibet-lake}
	\end{figure}

	\begin{figure}
		\includegraphics[width=1.0\textwidth,left]{01.4-change-detection/figures/Tibet-time-series}
		\caption{Estimating surface Siling Lake, Tibetan Plateau, China. The actual TOA reflectance values (left-top), annually-averaged (20\%) reflectance values (left-middle) and \gls{NDWI} values, estimated from annually-averaged reflectance values (left-bottom). The three charts on the left indicate values and distributions of the sun parameters for the images used to compute these values.}
		\label{fig:ch4-tibet-lake-time-series}
	\end{figure}

	\clearpage
}

To demonstrate the main steps used in the methods, surface water changes which have occurred around the Siling Lake are analyzed - one of the lakes of Tibetan Plateau, China. In the last few decades, an enormous area of new surface water has been created due to climate changes. Figure \ref{fig:ch4-tibet-lake} shows the final estimate for the submerged land, equal to $22.5 km^2$.

A straightforward and efficient way to estimate long-term surface water changes may be to use a two-step approach. First, the intensity percentile composites are computed for all temporal intervals $T$ used for the change detection analysis:

\begin{equation}
F(\rho) = \int_{-\infty}^{\rho^i} P(\rho)d\rho
\end{equation}

where $F$ - cumulative distribution function, the superscript index $i$ denotes the $i^{th}$ percentile, $\rho$ - reflectance values for a given band.

Then, for every percentile reflectance value $\rho^i$, the spectral index is computed as an image:

\begin{equation}
I = \frac{\rho_{green}^i-\rho_{nir}^i}{\rho_{green}^i+\rho_{nir}^i} \\
\end{equation}

After that, the linear regression is performed on a set of all index values for all intervals $T$:

\begin{equation}
I = \beta_0 + \beta_1 T + \epsilon
\end{equation}

The resulting slope of the linear regression $\beta_1$ is then analyzed to identify pixels, where significant surface water changes took place.

Usually, the percentile is determined empirically and corresponds to low reflectance values, but not too low, to avoid confusing water with cloud shadows, which can also be very dark for green and nir (or swir) bands used to estimate spectral indices. For those pixels, where the slope $\beta_1$ of the linear regression is significant. The spectral index values $I$ are also tested to exclude false positive changes, detected for images where most images correspond to water or land:

\begin{equation}
\begin{split}
\begin{aligned}
I &= min\left(I, I_{min}^{water}\right) \\
I &= max\left(I, I_{max}^{land}\right)
\end{aligned}
\end{split}
\label{eq:water-land-suppression}
\end{equation}

where $I_{min}^{water}$ and $I_{max}^{land}$ indicate minimum and maximum values of the spectral index to be considered as water and land correspondingly. The equation \ref{eq:water-land-suppression} is applied for every interval used during temporal averaging.

The first equation of the \ref{eq:water-land-suppression} allows to filter pixels, where the slope of the regression is significant, with all values still belonging to water. The second equation of the \ref{eq:water-land-suppression} does the same to eliminate locations where all of the temporal intensity values belong to the land.

Additionally, \gls{NDVI} vegetation index is used similarly to remove locations, where, for example, deforestation took place. In this case, \gls{NDWI} values may also change significantly in time, but the actual changes do not correspond to surface water changes.

\afterpage{%

	\begin{figure}
		\includegraphics[width=1.0\textwidth,left]{01.4-change-detection/figures/images_real}
		\caption{Examples of false-color (swir1, nir, green) images from 1998 acquired by Landsat TM sensor for Siling Lake, Tibetan Plateau, China. \opt{source}{Source: \url{https://code.earthengine.google.com/882ab2929f536676d56bc79cbc895ded}}
		}
		\label{fig:ch4-tibet-lake-false}
	\end{figure}

	\begin{figure}
		\includegraphics[width=1.0\textwidth,left]{01.4-change-detection/figures/images_percentiles}
		\caption{False-color (swir1, nir, green) reflectance percentile images estimated from 751 images acquired by multiple NASA Landsat missions during 1984-2017, Siling Lake, Tibetan Plateau, China}
		\label{fig:ch4-tibet-lake-percentiles}
	\end{figure}
	\clearpage
}

The actual number of images available need to be adjusted based on the cloud frequency present for a given area. For the area around this lake, the average cloud frequency is 13\%, with relatively low intra-annual variation, as estimated by \citet{wilson2016remotely} from MODIS images. However, for some areas on Earth, mainly near the equator, 95\% of the images may be covered by clouds. This means, that to apply this method, many more images need to be analyzed. In this case, only long-term surface water changes may be estimated using passive optical sensors.

% t-test using regression \url{https://en.wikipedia.org/wiki/Student%27s_t-test#Slope_of_a_regression_line}
% non-parametric tests \url{ftp://cran.r-project.org/pub/R/web/packages/trend/vignettes/trend.pdf}

% CDF sun parameters mismatch, topographic errors \url{https://code.earthengine.google.com/c9ed4d65ee90db7d4944e4c257969e1b}
% \url{https://code.earthengine.google.com/5ddaeea0946642afe23d7557c3c0c657}

\section{Topographic noise for inconsistent image collections}
Even though the method described in Chapter \ref{ch5} allows detection of surface water changes at high accuracy, a substantial commission error may occur in mountain regions. These errors are caused mainly by combined errors of elevation and azimuth, causing differences in hill shadows in composite images, used to detect surface water changes. For global analysis, most of these errors were eliminated by masking-out the final surface water changes images with the topographic index derived from \gls{HAND}. The topographic mask, constructed by HAND < 40m, was used to filter out these errors. The \gls{HAND} dataset used for the processing was generated from 30m \gls{SRTM} and some auxiliary 90m datasets to cover areas where it was not acquired (>60 degree north latitude) \citet{donchyts2016hand}. However, for very accurate surface water change estimates this may also result in omission errors in the areas when DEM values are incorrect. For the time being, no free high-resolution DEM exists to be used as a topographic index (via \gls{HAND}). Therefore, the Aqua Monitor website does not perform this correction during on-the-fly estimation of surface water changes. This may change in future versions, when a more appropriate method is introduced.

\begin{figure}
	\centering
	\includegraphics[width=1\textwidth]{01.8-aqua-monitor/figures/problem1}
	\caption{False-positive composites (swir1, nir, green) and surface water changes commission errors due to inconsistent sun parameters in the samples used to compute changes in the hilly areas (2000-2015). Top: upstream of the Lake Mead (\href{http://aqua-monitor.appspot.com/?from=2000&to=2013&view=36.103119715292486,-113.93795967102045,13z&max_doy=365}{36.10, -113.90}); bottom: river near Yogongxiang, China (\href{http://aqua-monitor.appspot.com/?mode=dynamic&from=2000&to=2013&view=30.269128374988604,94.89677429199217,12z&max_doy=365&averaging_months1=36&averaging_months2=36}{30.27, 94.90}).}
	\label{fig:am-topographic-errors}
\end{figure}

Examples of these errors are demonstrated in Figure \ref{fig:am-topographic-errors}.

The same errors were reported in the \citet{Hansen2013} dataset, which uses similar methods to estimate surface water changes (interval mean percentile composites versus percentile composites in Aqua Monitor).

A time consuming approach to eliminate these errors could be to perform topographic correction on every image before passing them to the change detection algorithm. However, this may significantly increase the amount of resources needed, making this type of analysis hardly achievable today.

\section{Conclusions and Discussion}

The method presented in this chapter showed surprisingly good performance for most of the places on Earth and was used to analyze global surface water changes over the last thirty years. Despite its simplicity, the method can very accurately detect long-term surface changes. Additionally, it is easy to implement using the Google Earth Engine parallel processing platform.

Another advantage of the method is that it is less resource intensive when compared to a more streamlined approach to detecting surface water changes. Hence it can be used for large planetary-scale studies and for a wide range of users, which is demonstrated in Chapter \ref{ch6}. For example, all images are first classified e.g. using supervised machine learning methods, and then the changes are computed from the resulting thematic maps.

However, it may be difficult to reliably detect surface water changes when:

\begin{enumerate}[label=(\alph*)]
	\item \label{enum:changes-low-count} the number of images used to compute percentiles is low
	\item \label{enum:changes-complex-trend} surface water changes follow a more complex pattern than a one directional trend
	\item \label{enum:changes-multple-classes} multiple land-use changes are present, represented by low reflectance values but irrelevant to surface water changes
	\item \label{enum:changes-topo} complex topographic conditions combined with unequally distributed sun parameters in different time intervals
\end{enumerate}

Some of these issues can be easily addressed, for example, by changing empirically chosen percentiles to ensure one captures pixels free from cloud and snow effects.

Additionally, image samples used to compute percentiles can also be selected to only represent certain seasons, where some of the effects are less present, filtering image collections by day-of-year or by sun parameters, to avoid the most evident topographic effects.

The methods presented here work best when reflectance values, representing complex land-use and atmospheric changes, are similarly distributed. While for surface water this is frequently true, it may be less trivial under very complex land-use change \ref{enum:changes-multple-classes}. To detect these kind of changes automatically, additional inference steps may be required, for example, where different patterns can be recognized in the distributions such as those presented in Chapter \ref{ch4}, Figure \ref{fig:prob-sampled-water-cloud-snow}.

While linear regression may be a good choice to detect monotonic long-term changes, surface water may follow much more complex trends, requiring the use of more complex methods to capture them. For example, logistic regression can be used instead of linear regression to detect abrupt changes such as construction or decommissioning of reservoirs, or to analyze autocorrelation to detect recurring surface water changes.

With the increasing number of satellite images available, the use of statistical methods may be a powerful instrument, providing an easy way for change or anomaly detection before the use of more complex methods.


\section{Essential ML ideas}
\smallskip \hrule height 2pt \smallskip

\begin{itemize}
	\item Never ever \underline{ever} touch the test set
	\item You know you are overfitting when there is a big test between train and test results.  E.g. metric of percent wrong.
	\item Need to be comfortable taking a hit on fitting accuracy if you can get a benefit on the result.
	\item Bias vs variance trade-off.
		High bias when the model is too simple \& doesn't fit the data well.
		High variance is when small changes to the data set lead to large solution changes.
	\item If features are non discriminative in the beginning, they don't work for any classifier.  % week 4 reminder
	\item Your feature vector often has a smaller dimension that the feature space.    % week 4, Friday.
		If you have too long of a feature vector, you may get overfitting.
	\item You need to prevent the optimizer from getting an easy way out.  % week 7 audio
	\item Whenever we are building a discriminative classifier,
        		we should not expect it to reason about things it has never seen before
    		You can't classify on something that has only seen + points.
    		The classifier needs to see some + and some - or it will fail miserably.   % week 8 audio
	\item We should always avoid making hard decisions early.  % week 8 audo.
		 E.g. don't put a lot of trust in classifiers early on in bagging.
\end{itemize}

You can do $l_2$ normalization for a feature vector to get a unit vector:   % week 6 audio.
	Convert $x$ to $\hat{x}$ so that if you form $||\hat{x}||_2^2 = 1$
	Can also do $l_1$


In this section, we discuss dynamic steady-state power and temperature analysis
under process variation. Unlike transient analysis, this analysis cannot be done
one time step at a time, since the repetitive workload needs to be taken into
account at once in order to calculate the corresponding dynamic steady state.
Thus, similarly to the contrast between \sref{transient-analysis} and
\sref{dynamic-steady-analysis}, the solutions in \sref{chaos-transient-analysis}
and this section differ. However, they still rely on the same methodology
outlined in \sref{chaos-uncertainty-analysis} and shown in
\fref{chaos-overview}.

\subsection{\problemtitle}

The system model is the same as the one in \sref{chaos-transient-analysis}. The
only difference is that it is more convenient to define the power model as
follows:
\begin{equation} \elab{chaos-power-model-bulk}
  \mp = \f(\vu, \mq).
\end{equation}
The function $\f: \real^\nu \times \real^{\np \times \ns} \to \real^{\np \times
\ns}$ is supposed to return the periodic power profile that corresponds to the
periodic workload being analyzed.

\inputalgorithm{chaos-dynamic-steady-solution-iterative}
The solution to probabilistic dynamic steady-state analysis is based on the
deterministic one presented in \sref{dynamic-steady-solution}. The power,
temperature, and other vectors that appear in \sref{dynamic-steady-solution}
become stochastic in the present context, which also concerns the boundary
condition given in \eref{dynamic-steady-condition}. The pseudocode for a
procedure that delivers \mq for a fixed \vu is listed in
\aref{dream-dynamic-steady-solution}. The algorithm does not take account of the
interdependence between power and temperature; however, this interdependence can
be addressed via one of the techniques presented in \sref{power-temperature}. In
this section, we use the iterative approach illustrated in
\aref{dream-dynamic-steady-solution-iterative}. For clarity, this algorithm is
rewritten here as shown in \aref{chaos-dynamic-steady-solution-iterative}; the
main difference is that the calculation of power on line~3 is now based on
\eref{chaos-power-model-bulk}.

\begin{remark}
The application of the linear approximation described in
\sref{power-temperature} is problematic in this case. This technique is suitable
when the only varying parameter is temperature, and all other parameters have
nominal values. In that case, it is relatively easy to decide on a
representative temperature range and apply a curve-fitting procedure. In this
case, however, the power model has multiple parameters that range far from their
nominal values.
\end{remark}

To recapitulate, the quantity of interest \g in \fref{chaos-overview} is the
dynamic steady-state power and temperature profiles, which are denoted by \mp
and \mq, respectively. The calculation of this quantity is shown in
\aref{chaos-dynamic-steady-solution-iterative}.

\subsection{Surrogate Construction}

At Stage~3 in \fref{chaos-overview}, the procedure delineated in
\sref{chaos-construction} is applied to
\aref{chaos-dynamic-steady-solution-iterative} from Stage~1 with respect to the
output of Stage~2. Concretely, \aref{chaos-dynamic-steady-solution-iterative} is
utilized inside \aref{chaos-construction} via Algorithm~G. In this case,
Algorithm~G calls \aref{chaos-dynamic-steady-solution-iterative} and returns \mp
or \mq or both, depending on what is actually needed for the subsequent
calculations, in a suitable format.

Suppose, for instance, that the designer is interested in analyzing solely the
dynamic steady-state temperature profile \mq. Following
\rref{chaos-multidimensional-output} concerning vector-valued quantities, \g is
treated as an $\np \ns$-element row vector, in which case each coefficient
$\hat{\g}_{\vi}$ in \eref{chaos-expansion} is also such a vector. The projection
matrix, which is defined in \eref{chaos-projection-matrix}, and
\aref{chaos-construction} should be reinterpreted accordingly: \vg is an $\nq
\times \np \ns$ matrix whose row~$j$ is \mq computed at point~$j$ of the
quadrature in \eref{chaos-coefficient} and reshaped into a row vector.
Similarly, $\hat{\vg}$ should be understood as an $\nc \times \np \ns$ matrix
whose row~$i$ is coefficient~$i$ of the expansion in \eref{chaos-expansion}.
Recall that a certain ordering is assumed to be imposed on quadrature points and
polynomial terms.

The constructed \ac{PC} expansion can now be post-processed as required, which
is already the topic of Stage~4 in \fref{chaos-overview}; see
\sref{chaos-processing}.


\documentclass[11pt]{article}
\usepackage{geometry}
\geometry{a4paper,left=2.5cm,right=2.5cm,top=2.5cm,bottom=2.5cm}
\usepackage{natbib}
\usepackage{color}
\definecolor{mygreen}{RGB}{28,172,0} % color values Red, Green, Blue
\definecolor{mylilas}{RGB}{170,55,241}
\usepackage{epsfig}
\usepackage{amssymb,amsmath}
\usepackage{enumerate}
\usepackage{enumitem}
\usepackage[utf8]{inputenc}
\usepackage{hyperref}
\usepackage{mathtools}

\newcommand{\ssd}{\text{ssd}}
\newcommand{\sS}{\mathsf{S}}
\newcommand{\tot}{\text{tot}}

\begin{document}

\input{symbols}

\section*{One-Layer Rotating Shallow Water Model}

\subsection*{Classical Form}

The one-layer, two-dimensional rotating shallow water model
on a rotating $f$-plane can be written as,
\begin{align}
\frac{\partial u}{\partial t} + \left(\bf{u} \cdot \nabla\right) u - f v
&= - g \frac{\partial h}{\partial x},\\
\frac{\partial v}{\partial t} + \left(\bf{u} \cdot \nabla\right) v + f u
&= - g \frac{\partial h}{\partial y},\\
\frac{\partial h}{\partial t} + \nabla \cdot \left( h \bf{u} \right) &= 0.
\end{align}
This describes the motion of a pancake like fluid in that it is thin in the vertical
and much longer in the horizontal.  It contains pressure forces due to the free surface
and a Coriolis pseudo-force because of the rotating frame of reference.

The fluid moves as columns that can be
translated in the horizontal and stretched/contracted in the vertical.  If the
height of a column changes then the voriticty must change, as can be reflected
in the fact that, in the absence of forcing and dissipation,
Potential Vorticity is conserved following the motion,
$$
\frac{D}{Dt} \left(
\frac{ \frac{\partial v}{\partial x} - \frac{\partial u}{\partial y} + f }{h} \right) = 0.
$$

\subsection*{Conservation Form}

There are a variety of forms, these equations can be written.
One of them is conservation where the three fields that have time
derivatives are $U = hu$, $V = hv$ and $h$.
\begin{align}
\frac{\partial U}{\partial t}
+ \frac{\partial}{\partial x}\left( \frac{U^2}{h} + \frac{g h^2}{2} \right)
+ \frac{\partial}{\partial y}\left( \frac{U V}{h}  \right)
- f V
&= 0,\\
\frac{\partial V}{\partial t}
+ \frac{\partial}{\partial x}\left( \frac{U V}{h}  \right)
+ \frac{\partial}{\partial y}\left( \frac{V^2}{h} + \frac{g h^2}{2} \right)
+ f U
&= 0,\\
\frac{\partial h}{\partial t} + \nabla \cdot \left( h \bf{u} \right) &= 0.
\end{align}

Conservation form is attractive because it can help to ensure that, using a clever numerical
scheme, some quantitites are conserved.  Note that if you have topography then there
are source terms that appear on the right-hand side and this causes some problems.

\subsection*{Vorticity-Bernoulli Form}

A third form arises from rewriting the nonlinear
acceleration terms as a gradient and a cross product term.  Using a vector identity,
it can be shown that the above system is mathematically equivalent to the following,
\begin{align}
\frac{\partial u}{\partial t}  - q h v
&= - \frac{\partial B}{\partial x},\\
\frac{\partial v}{\partial t}  + q h u
&= - \frac{\partial B}{\partial y},\\
\frac{\partial h}{\partial t} + \nabla \left( h \bf{u} \right) &= 0.
\end{align}
Note that above we have defined the vorticity and the Bernoulli function,
\begin{align}
q &= \frac{\zeta + f}{h}
 = \frac{\frac{\partial v}{\partial x} - \frac{\partial u}{\partial y} + f}{h},\\
B & = g h + \frac12 \left( u^2 + v^2 \right).
\end{align}

Before we look at solving this complicated set of equations

\subsection*{ $1 \frac12$ Dimensional Limit}

We assume that none of the variables depend on one horizontal direction, say $y$.
But, it is very important to realize that the velocity in that direction is not necessarily zero.
Indeed, if you have flow in the $x$-direction, the Coriolis force will deflect it to the right,
which will then generate a flow that is perpendicular.  This will continue and often give rise
to inerital oscialltions in the horizontal.  So we can have motion in either direction but
the motion only changes with respect to $x$.

If we simply the governing equations we get
\begin{align}
\frac{\partial u}{\partial t}  - q h v
&= - \frac{\partial B}{\partial x},\\
\frac{\partial v}{\partial t}  + q h u
&= 0,\\
\frac{\partial h}{\partial t} + \frac{\partial}{\partial x} \left( h u \right) &= 0.
\end{align}
where the vorticity and the Bernoulli function simplify to,
\begin{align}
q & = \frac{\zeta + f}{h} = \frac{\frac{\partial v}{\partial x} + f}{h},\\
B & = g h^2 + \frac12 \left( u^2 + v^2 \right).
\end{align}

\subsection*{Conserved Quantities}

In the purely conservative or nondissipative limit,
there are three quantities that are exactly conserved.

1) Mass:
$$
M = \int_D h \, dA
$$

2) Total Energy: sum of potential and kinetic energies
$$
E = \frac12 \int_D \left(g h^2 + h( u^2 + v^2)\right) \, dA
$$

3) Potenal Enstrophy:
$$
Q = \frac12 \int_D  h q^2 \, dA
$$

In a numerical model we cannot expect these to be conserved
but we would like them to be close to be conserved.
If they are very badly conserved than this could reflect that
the numerical scheme is behaving badly.
However, just because these are conserved that does not
guarantee that the solution is correct.
But they are usually good indicators as to how our method is
doing in the conservative limit.

Of course when nonconservative forces are introduced things will change.
One might argue that since the world is non-dissipative then we don't
need to worry about conserving these.  However, it is desirable to
know that basis of your model is well behaved and therefore why
we should worry about conserved quantities.

\end{document}


%-----------------------------------------------------------------------------------------------
\section{Introduction}

    Polytropic        processes---\emph{poly}:        many,        \emph{tropic}:         forms,
    ways~\cite{2020-NaaktgeborenC-engrXiv}---are a versatile class of equilibrium thermodynamics
    processes          with          many          applications          in          engineering
    thermodynamics~\cite{2002-MoranMJ+ShapiroHN-LTC,                 2013-CengelYA+BolesMA-AMGH,
    2015-KroosKA+PotterMC-Cengage,  1986-JonesJB+HawkinsGA-Wiley},  given   by   the   following
    relationship
    %
    \begin{equation}
        Pv^n = \mathsf{c} = \mbox{const.},
        \label{eq:polytropic}
    \end{equation}
    %
    \noindent where $P$ is the system pressure, $v$ the system specific volume, and $n$  is  the
    polytropic exponent.

    Polytropic       processes       are       said       to       find        support        in
    measurements~\cite{2013-CengelYA+BolesMA-AMGH,                   2002-MoranMJ+ShapiroHN-LTC,
    1985-WylenG-Wiley};         however,          theory~\cite{2012-ChristiansJ-IntJMechEngEduc,
    2020-NaaktgeborenC-engrXiv} predicts a fairly restrictive set of conditions---on the process
    boundary and internal conditions and on the underlying substance model---are required for  a
    process to follow Eq.~(\ref{eq:polytropic}) \emph{exactly}---see, for instance, Theorem~3 of
    reference~\cite{2020-NaaktgeborenC-engrXiv}.

    Thus, in non-ideal  settings,  polytropic  processes  either  (i)~hold  approximately  in  a
    \emph{local} neighborhood of  a  given  state,  for  constant-$n$,  or  (ii)~the  polytropic
    exponent must be generalized into a function of a state property, such  as  temperature,  or
    even further generalized.

    Reference~\cite{2020-NaaktgeborenC-engrXiv} brings useful definitions for  discussions  like
    this, such as that of a \emph{logical process},  and  also  those  of  \emph{exact}  and  of
    \emph{local} polytropic processes.

    In \emph{exact polytropic process}, Eq.~(\ref{eq:polytropic}) holds exactly with a constant,
    unique polytropic exponent, for the entire duration of the \emph{logical process}. They  are
    shown to be able to represent any straight line segment process in $\log P  \times  \log  v$
    coordinates~\cite{2020-NaaktgeborenC-engrXiv}.

    Moreover, process whose representations in $\log P \times \log v$  coordinates  are  curved,
    are shown to be able to be  approximated  by  a  finite  number  of  \emph{local  polytropic
    processes} within  finite  error  intervals~\cite{2020-NaaktgeborenC-engrXiv}.  Observations
    like these attest the flexibility of processes based on the  polytropic  relationship,  thus
    justifying the flexibility encoded in their name.

    Despite their enormous flexibility, the defining concept  of  polytropic  processes  can  be
    further generalized as to allow for increased flexibility, so that some  processes  families
    with curved representation in $\log P  \times  \log  v$  coordinates  might  have  an  exact
    representation in such further generalized process relation  concept.  The  introduction  of
    such generalizations can be of theoretical and of applied interest.

    Therefore, this work proposes one such generalization, named \emph{polyekthetic  processes},
    that form a \emph{larger process set} of which  the  polytropic  process  set  is  a  proper
    subset, so that any polytropic process is a particular case of a polyekthetic  process,  but
    not necessarily the opposite.

    The origin  (etymology)  for  the  proposed  `polyekthetic'  term  is  also  given,  and  an
    application yielding exact polyekthetic processes  (but  not  exactly  polytropic  ones)  is
    provided.

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