\RequirePackage[l2tabu, orthodox]{nag}
\documentclass{article}

\usepackage[letterpaper]{geometry}
\usepackage{booktabs}
\usepackage{mathtools}
\usepackage[binary-units=true]{siunitx}
\usepackage{tikz}
\usepackage[final]{pdfpages}

\title{ECE 487 Assignment 8}
\author{Michael Kwok}
\begin{document}

\maketitle
\subsection*{Address}
\begin{enumerate}
    \item \verb|01110110.11101110.01100111.01111010|: \verb|118.238.103.122|
    \item \verb|10101111.11000011.11111000.00011100|: \verb|175.195.248.028|
\end{enumerate}
\subsection*{Mask}
Mask:   \verb|11111111 1111111x xxxxxxxx xxxxxxxx|

Address:\verb|00010100 00100010 00001100 00111000|

First Address: \verb|00010100 00100010 00000000 00000000|: 20.34.0.0

Final Address: \verb|00010100 00100011 11111111 11111111|: 20.35.255.255

\subsection*{Subnets}
\verb|11111111 11xxxxxx xxxxxxxx xxxxxxxx -> 2^22| addresses \verb| -> 2^15| address/subnet
\begin{enumerate}
    \item Mask: \( \log_2(2^{(32-15)}) = 17 \)
    \item Addresses per subnet: \( 2^{(32-17)} = 2^{15}\)
    \item \verb|Mask: 11111111 11111111 1xxxxxxx xxxxxxxx|\\
          \verb|First: 00010000 00000000 00000000 00000000|: 16.0.0.0\\
          \verb|Last:  00010000 00000000 01111111 11111111|: 16.0.127.255
    \item \verb|Mask: 11111111 11111111 1xxxxxxx xxxxxxxx|\\
          \verb|First: 00010000 00111111 10000000 00000000|: 16.63.128.0\\
          \verb|Last:  00010000 00111111 11111111 11111111|: 16.63.255.255
\end{enumerate}

\subsection*{Fragments}
Input:
\begin{itemize}
    \item M = 1: More fragments after this
    \item HLEN = 5: Header 20 bytes
    \item Payload = \(820 - 20\) bytes = 800 bytes
    \item Offset = 100
\end{itemize}

Split into 2 fragments:

Fragment 1:
\begin{itemize}
    \item M: 1
    \item Total Length: 420
    \item Offset: 100
\end{itemize}

Fragment 2:
\begin{itemize}
    \item M: 1
    \item Total Length: 420
    \item Offset: \(100 + 400/5 = 150\)
\end{itemize}

\subsection*{Checksum}
\begin{tabular}{ccccc}
      & 4 & 5 & 0 & 4 \\
      & 0 & 0 & D & C \\
      & 0 & 1 & 0 & 0 \\
      & 0 & 0 & 6 & 4 \\
      & 1 & 0 & 0 & 6 \\
      & 0 & A & 0 & C \\
      & 0 & E & 0 & 5 \\
      & 0 & C & 0 & 6 \\
    + & 0 & 7 & 0 & 9 \\
    \midrule
      & 8 & 2 & 6 & A
\end{tabular}
\\\\
\verb|0x826A = 1000 0010 0110 1010|\\
One's complement:\\
\verb|0111 1101 1001 0101 = 0x7D95|\\

\end{document}


% ==============================================================================
%
%                               A B S T R A C T
%
% ==============================================================================
\chapter*{Abstract} % -------------------------------------------------------- %
\label{ch:app:abstract}
% ---------------------------------------------------------------------------- %

The objective  of this  project is  to realize a  system for  measuring analog
signals  in  the kilohertz  to  low  megahertz  range  with a  digital  signal
processing  system  in  real  time,  offering  an  affordable  alternative  to
expensive oscilloscopes  and spectrum  analyzers. The basic components  of the
system are a  Red Pitaya STEMlab for signal acquisition  and processing  and a
personal  computer  or  mobile  device  for  data  visualization  and  further
analysis.

To  allow transmission  over  an  Ethernet connection  and  to improve  signal
quality, the high-rate data stream coming from the STEMlab's analog-to-digital
converter  is   decimated  to  a   lower-rate  signal  using   the  integrated
FPGA. During decimation, the signal passes through one of six filter chains to
attenuate aliasing  effects.

The chains  run on  the STEMlab's  FPGA. They are based  on a  combination of
FIR  and CIC  filters,  and  decimate the  incoming  \SI{125}{\MHz} signal  to
output frequencies  between \SI{50}{\kHz} and \SI{25}{\MHz},  depending on the
chain. They  achieve  an  aliasing  attenuation of  \SI{60}{\dB}  and  exhibit
negligible passband droop. A  signal-to-noise ratio of up  to \SI{84}{\dB} has
been measured.

The decimated signal is then passed on  to an embedded GNU/Linux and sent to a
client over  a network connection. A newly  developed oscilloscope application
allows observation  of the signal  from a  client device.  The  application is
based on JavaScript,  allowing for easy deployment across any  platform with a
modern browser available.

All components created for this project  are provided under the MIT license. A
comprehensive toolchain covering filter design, FPGA tools, embedded GNU/Linux
and front end  development, along with documentation, allows  anyone to extend
and modify the system and to tailor it to their needs.

\vfill

%<<< KEYWORDS
\paragraph{Key Words:}
Red Pitaya,
STEMlab,
Xilinx,
FPGA,
Oscilloscope,
Spectrum Analyzer,
DSP,
Digital Signal Processing,
Digital Filters,
FIR Filter,
CIC Filter,
Lowpass,
Sampling,
Downsampling,
Decimation,
Aliasing,
Attenuation,
FFT,
JavaScript,
Web Application,
VHDL,
C,
C++,
Open Source,
MIT License.
%>>> KEYWORDS
%^^A vim: foldenable foldcolumn=4 foldmethod=marker foldmarker=<<<,>>>


\documentstyle[11pt,reduce]{article}
\title{Truncated Power Series}
\date{}
\author{Alan Barnes \\
School of Engineering \& Applied Science  \\
Aston University, Aston Triangle, \\
Birmingham B4 7ET \\ GREAT BRITAIN  (now retired)\\
Email: Alan.Barnes45678@gmail.com \\[0.1in]
and \\[0.1in]
Julian Padget \\
School of Mathematics, University of Bath \\
Claverton Down, Bath, BA2 7AY \\
GREAT BRITAIN \\
Email: jap@maths.bath.ac.uk}
\begin{document}
\maketitle
\index{power series} \index{truncated power series}
\index{Barnes, Alan} \index{Padget, Julian}
\section{Introduction}
\index{Power series expansions}
This package implements formal power series expansions in one
variable using the domain mechanism of REDUCE. This means that power
series objects can be added, multiplied, differentiated etc. like other
first class objects in the system. A lazy evaluation scheme is used in
the package and thus terms of the series are not evaluated until they
are required for printing or for use in calculating terms in other
power series. The series are extendible giving the user the impression
that the full infinite series is being manipulated.  The errors that
can sometimes occur using series that are truncated at some fixed depth
(for example when a term in the required series depends on terms of an
intermediate series beyond the truncation depth) are thus avoided.

Below we give a brief description of the operators available in the
power series package together with some examples of their use.

\subsection{PS Operator}

Syntax:

\noindent{\tt PS}(EXPRN:{\em algebraic},DEPVAR:{\em kernel},
ABOUT:{\em algebraic}):{\em ps object}

\index{PS operator}
The {\tt PS} operator returns a  power series object
(a tagged domain element)
representing the univariate formal power series expansion of EXPRN with
respect to the dependent variable DEPVAR about the expansion point
ABOUT.  EXPRN may itself contain power series objects.

The algebraic expression ABOUT should simplify to an expression
which is independent of the dependent variable DEPVAR, otherwise
an error will result.  If ABOUT is the identifier {\tt INFINITY}
then the power series expansion about DEPVAR = $\infty$ is
obtained in ascending powers of 1/DEPVAR.

\index{PSEXPLIM operator}
If the command is terminated by a semi-colon, a power series object
representing EXPRN is compiled and then a number of terms of the
power series expansion are evaluated and printed.  The expansion is
carried out as far as the value specified by {\tt PSEXPLIM}.  If,
subsequently, the value of {\tt PSEXPLIM} is increased, sufficient
information is stored in the power series object to enable the
additional terms to be calculated without recalculating the terms
already obtained.

If the command is terminated by a dollar symbol, a power series object
is compiled, but at most one term is calculated at this stage.

If the function has a pole at the expansion point then the correct
Laurent series expansion will be produced.

\noindent The following examples are valid uses of {\tt PS}:
\begin{verbatim}
    psexplim 6;
    ps(log x,x,1);
    ps(e**(sin x),x,0);
    ps(x/(1+x),x,infinity);
    ps(sin x/(1-cos x),x,0);
    ps(gamma x,x,3);
    ps(psi x,x,0);
    ps(polygamma(2,x),x,-2);
\end{verbatim}

\index{power series ! of user defined function}
New user-defined functions may be expanded provided the user provides
LET rules giving

\begin{enumerate}
\item the value of the function at the expansion point
\item a differentiation rule for the new function.
\end{enumerate}

\noindent For example
\begin{verbatim}
    operator sech;
    forall x let df(sech x,x)= - sech x * tanh x;
    let sech 0 = 1;
    ps(sech(x**2),x,0);
\end{verbatim}

\index{power series ! of integral}
The power series expansion of an integral may also be obtained (even if
REDUCE cannot evaluate the integral in closed form).  An example of
this is

\begin{verbatim}
    ps(int(e**x/x,x),x,1);
\end{verbatim}

Note that if the integration variable is the same as the expansion
variable then REDUCE's integration package is not called; if on the
other hand the two variables are different then the integrator is
called to integrate each of the coefficients in the power series
expansion of the integrand.  The constant of integration is zero by
default.

\subsection{PSEXPLIM Operator}

\index{PSEXPLIM Operator}
Syntax:

\hspace*{2em} {\tt PSEXPLIM}(UPTO:{\em integer}):{\em integer}

\hspace*{4em} or

\hspace*{2em} {\tt PSEXPLIM}():{\em integer}

Calling this operator sets an internal variable of the
TPS package to the value of UPTO (which should evaluate to an integer).
This internal variable controls how many terms of a power series are printed.
The value returned by {\tt PSEXPLIM} is the previous value of this variable.
The default value is six.

If {\tt PSEXPLIM} is called with no argument, the current value for
the expansion limit is returned.

\subsection{PSPRINTORDER Switch}

\index{PSPRINTORDER Switch}
Syntax:

\hspace*{2em} {\tt ON PSPRINTORDER}

\hspace*{4em} or

\hspace*{2em} {\tt OFF PSPRINTORDER}

When {\tt ON} this switch causes the remainder of the power series
to be printed in big-O notation.   Otherwise, three dots are printed.
 The default is {\tt ON}.

\subsection{PSORDLIM Operator}

\index{PSORDLIM operator}
Syntax:

\hspace*{2em} {\tt PSORDLIM}(UPTO:{\em integer}):{\em integer}

\hspace*{4em} or

\hspace*{2em} {\tt PSORDLIM}():{\em integer}

An internal variable is set to the value of {\tt UPTO} (which should
evaluate to an integer). The value returned is the previous value of
the variable.  The default value is 15.

If {\tt PSORDLIM} is called with no argument, the current value is
returned.

The significance of this control is that the system attempts to find
the order of the power series required, that is the order is the
degree of the first non-zero term in the power series.  If the order
is greater than the value of this variable an error message is given
and the computation aborts. This prevents infinite loops in examples
such as

\begin{verbatim}
        ps(1 - (sin x)**2 - (cos x)**2,x,0);
\end{verbatim}

where the expression being expanded is identically zero, but is not
recognized as such by REDUCE.

\subsection{PSTERM Operator}

\index{PSTERM operator}
Syntax:

\hspace*{2em} {\tt PSTERM}(TPS:{\em power series object},
NTH:{\em integer}):{\em algebraic}

The operator {\tt PSTERM} returns the NTH term of the existing
power series object TPS. If NTH does not evaluate to
an integer or TPS to a power series object an error results.  It
should be noted that an integer is treated as a power series.

\subsection{PSORDER Operator}

\index{PSORDER operator}
Syntax:

\hspace*{2em} {\tt PSORDER}(TPS:{\em power series object}):{\em integer}

The operator {\tt PSORDER} returns the order, that is the degree of
the first non-zero term, of the power series object TPS.
TPS should evaluate to a power series object or an error results. If
TPS is zero, the identifier {\tt UNDEFINED} is returned.

\subsection{PSSETORDER Operator}

\index{PSSETORDER operator}
Syntax:

\hspace*{2em} {\tt PSSETORDER}(TPS:{\em power series object},
ORD:{\em integer}):{\em integer}

The operator {\tt PSSETORDER} sets the order of the power series
TPS to the value ORD, which should evaluate to an integer. If
TPS does not evaluate to a power series object, then an error
occurs. The value returned by this operator is the previous order of
TPS, or 0 if the order of TPS was undefined.  This
operator is useful for setting the order of the power series of a
function defined by a differential equation in cases where the power
series package is inadequate to determine the order automatically.

\subsection{PSDEPVAR Operator}

\index{PSDEPVAR operator}
Syntax:

\hspace*{2em} {\tt PSDEPVAR}(TPS:{\em power series object})
:{\em identifier}

The operator {\tt PSDEPVAR} returns the expansion variable of the
power series object TPS. TPS should evaluate to a power
series object or an integer, otherwise an error results. If TPS
is an integer, the identifier {\tt UNDEFINED} is returned.

\subsection{PSEXPANSIONPT operator}

\index{PSEXPANSIONPT operator}
Syntax:

\hspace*{2em}
{\tt PSEXPANSIONPT}(TPS:{\em power series object}):{\em algebraic}

The operator {\tt PSEXPANSIONPT} returns the expansion point of the
power series object TPS. TPS should evaluate to a power
series object or an integer, otherwise an error results. If TPS
is integer, the identifier {\tt UNDEFINED} is returned. If the
expansion is about infinity, the identifier {\tt INFINITY} is
returned.

\subsection{PSFUNCTION Operator}

\index{PSFUNCTION operator}
Syntax:

\hspace*{2em}
{\tt PSFUNCTION}(TPS:{\em power series object}):{\em algebraic}

The operator {\tt PSFUNCTION} returns the function whose expansion
gave rise to the power series object TPS. TPS should
evaluate to a power series object or an integer, otherwise an error
results.

\subsection{PSCHANGEVAR Operator}

\index{PSCHANGEVAR operator}
Syntax:

\hspace*{2em} {\tt PSCHANGEVAR}(TPS:{\em power series object},
X:{\em kernel}):{\em power series object}

The operator {\tt PSCHANGEVAR} changes the dependent variable of the
power series object TPS to the variable X. TPS
should evaluate to a power series object and X to a kernel,
otherwise an error results.  Also X should not appear as a
parameter in TPS. The power series with the new dependent
variable is returned.

\subsection{PSREVERSE Operator}

\index{PSREVERSE operator}
Syntax:

\hspace*{2em}
{\tt PSREVERSE}(TPS:{\em power series object}):{\em power series}

Power series reversion.  The power series TPS is functionally
inverted.  Four cases arise:

\begin{enumerate}
\item If the order of the series is 1, then the expansion point of the
inverted series is 0.

\item If the order is 0 {\em and} if the first order term in TPS
is non-zero, then the expansion point of the inverted series is taken
to be the coefficient of the zeroth order term in TPS.

\item If the order is -1 the expansion point of the inverted series
is the point at infinity.  In all other cases a REDUCE error is
reported because the series cannot be inverted as a power series.
Puiseux \index{Puiseux expansion} expansion would be required to
handle these cases.

\item If the expansion point of TPS is finite it becomes the
zeroth order term in the inverted series. For expansion about 0 or the
point at infinity the order of the inverted series is one.
\end{enumerate}

If TPS is not a power series object after evaluation an error results.

\noindent Here are some examples:
\begin{verbatim}
        ps(sin x,x,0);
        psreverse(ws); % produces series for asin x about x=0.
        ps(exp x,x,0);
        psreverse ws; % produces series for log x about x=1.
        ps(sin(1/x),x,infinity);
        psreverse(ws); % series for 1/asin(x) about x=0.
\end{verbatim}

\subsection{PSCOMPOSE Operator}

\index{PSCOMPOSE operator}
Syntax:

\hspace*{2em} {\tt PSCOMPOSE}(TPS1:{\em power series},
TPS2:{\em power series}):{\em power series}

\index{power series ! composition}
{\tt PSCOMPOSE} performs power series composition.
The power series TPS1 and TPS2 are functionally composed.
That is to say that TPS2 is substituted for the expansion
variable in TPS1 and the result expressed as a power series. The
dependent variable and expansion point of the result coincide with
those of TPS2.  The following conditions apply to power series
composition:

\begin{enumerate}
\item If the expansion point of TPS1 is 0 then the order of the
TPS2 must be at least 1.

\item If the expansion point of TPS1 is finite, it should
coincide with the coefficient of the zeroth order term in TPS2.
The order of TPS2 should also be non-negative in this case.

\item If the expansion point of TPS1 is the point at infinity
then the order of TPS2 must be less than or equal to -1.

\end{enumerate}

If these conditions do not hold the series cannot be composed (with
the current algorithm terms of the inverted series would involve
infinite sums) and a REDUCE error occurs.

\noindent Examples of power series composition include the following.

\begin{verbatim}
    a:=ps(exp y,y,0);  b:=ps(sin x,x,0);
    pscompose(a,b);
    % Produces the power series expansion of exp(sin x)
    % about x=0.

    a:=ps(exp z,z,1); b:=ps(cos x,x,0);
    pscompose(a,b);
    % Produces the power series expansion of exp(cos x)
    % about x=0.

    a:=ps(cos(1/x),x,infinity);  b:=ps(1/sin x,x,0);
    pscompose(a,b);
    % Produces the power series expansion of cos(sin x)
    % about x=0.
\end{verbatim}

\subsection{PSSUM Operator}

\index{PSSUM operator}
Syntax:

\begin{tabbing}
\hspace*{2em} {\tt PSSUM}(\=J:{\em kernel} = LOWLIM:{\em integer},
COEFF:{\em algebraic}, X:{\em kernel}, \\
\> ABOUT:{\em algebraic}, POWER:{\em algebraic}):{\em power series}
\end{tabbing}

The formal power series sum for J from LOWLIM to {\tt INFINITY} of

\begin{verbatim}
      COEFF*(X-ABOUT)**POWER
\end{verbatim}

or if ABOUT is given as {\tt INFINITY}

\begin{verbatim}
      COEFF*(1/X)**POWER
\end{verbatim}

is constructed and returned. This enables power series whose general
term is known to be constructed and manipulated using the other
procedures of the power series package.

J and X should be distinct simple kernels. The algebraics
ABOUT,  COEFF and POWER should not depend on the
expansion variable X, similarly the algebraic ABOUT should
not depend on the summation variable J.  The algebraic POWER should be
a strictly increasing integer valued function of J for J in the range
LOWLIM to {\tt INFINITY}.

\begin{verbatim}
   pssum(n=0,1,x,0,n*n);
   % Produces the power series summation for n=0 to
   % infinity of x**(n*n).

   pssum(m=1,(-1)**(m-1)/(2m-1),y,1,2m-1);
   % Produces the power series expansion of atan(y-1)
   % about y=1.

   pssum(j=1,-1/j,x,infinity,j);
   % Produces the power series expansion of log(1-1/x)
   % about the point at infinity.

   pssum(n=0,1,x,0,2n**2+3n) + pssum(n=1,1,x,0,2n**2-3n);
   % Produces the power series summation for n=-infinity
   % to +infinity of x**(2n**2+3n).
\end{verbatim}

\subsection{PSTAYLOR Operator}

Syntax:

\noindent{\tt PSTAYLOR}(EXPRN:{\em algebraic},DEPVAR:{\em kernel},
ABOUT:{\em algebraic}):{\em ps object}

\index{PSTAYLOR operator}
The {\tt PSTAYLOR} operator returns a  power series object
(a tagged domain element)
representing the univariate formal Taylor series expansion of EXPRN with
respect to the dependent variable DEPVAR about the expansion point
ABOUT.  Unlike the operator PS it directly evaluates the nth derivative of the
expression  EXPRN wrt the variable DEPVAR at the expansion point ABOUT to find
the nth term of the series.   Poles (and other singularities) at the expansion
point will cause an error -- PS and TAYLOR are more robust in this respect.
The PSTAYLOR operator may be useful in contexts where PS fails to build a suitable
 recurrence relation automatically and reports too deep a recursion in
{\tt ps!:unknown!-crule}. A typical example is the expansion of the $\Gamma$
function about an expansion point which is not a non-positive integer.

The algebraic expression ABOUT should simplify to an expression
which is independent of the dependent variable DEPVAR, otherwise
an error will result.

If ABOUT is the identifier {\tt INFINITY}
then the power series expansion about DEPVAR = $\infty$ is
obtained in ascending powers of 1/DEPVAR.

\subsection{PSCOPY Operator}

\index{PSCOPY operator}
Syntax:

\hspace*{2em} {\tt PSCOPY}(TPS:{\em power series}):{\em power series}

This procedure returns a copy of the power series {\tt TPS}. The copy
has no shared sub-structures in common with the original series.  This
enables substitutions to be performed on the series without
side-effects on previously computed objects. For example:

\begin{verbatim}
    clear a;
    b := ps(sin(a*x)), x, 0);
    b where a => 1;
\end{verbatim}

will result in {\tt a} being set to 1 in each of the terms of the
power series and the resulting expressions being simplified. Owing to
the way power series objects are implemented using Lisp vectors, this
has the side-effect that the value of {\tt b} is changed.  This may be
avoided by copying the series with {\tt PSCOPY} before applying the
substitution, thus:

\begin{verbatim}
    b := ps(sin(a*x)), x, 0);
    pscopy b where a => 1;
\end{verbatim}

\subsection{PSTRUNCATE Operator}

\index{PSTRUNCATE operator}
Syntax:

\hspace*{2em} {\tt PSTRUNCATE}(TPS:{\em power series} POWER: {\em integer)}
:{\em algebraic}

This procedure truncates the power series {\tt TPS} discarding terms
of order higher than {\tt POWER}. The series is extended automtically
if the value of {\tt POWER} is greater than the order of last term
calculated to date.

\begin{verbatim}
    b := ps(sin x, x, 0);
    a := pstruncate(b, 11);
\end{verbatim}

will result in {\tt a} being set to the eleventh order polynomial
resulting in truncating the series for $sin x$ after the term
involving $x^{11}$.

If {\tt POWER} is less than the order of the series then $0$ is
returned.  If {\tt POWER} does not simplify to an integer or if
{\tt TPS} is not a power series object then Reduce errors result.

\subsection{Arithmetic Operations}

\index{power series ! arithmetic}
As power series objects are domain elements they may be combined
together in algebraic expressions in algebraic mode of REDUCE in the
normal way.

For example if A and B are power series objects then the commands
such as:

\index{+ ! power series} \index{- ! power series}
\index{/ ! power series} \index{* ! power series}
\index{** ! power series}
\begin{verbatim}
    a*b;
    a/b;
    a**2+b**2;
\end{verbatim}

will produce power series objects representing the product,quotient
and the sum of the squares of the power series objects A and B
respectively.

\subsection{Differentiation}

\index{power series ! differentiation}
If A is a power series object depending on X then the input
{\tt df(a, x);} will produce the power series expansion of the
derivative of A with respect to X.

{\em Note} however that currently the input  {\tt int(a, x);} will
not work as intended; instead one must input
{\tt ps(int(a, x),x,0);}
in order to obtain the power series expansion of the integral of
{\tt a}.

\section{Restrictions and Known Bugs}

If A is a power series object and X is a variable
which evaluates to itself then currently expressions such as {\tt a*x}
do not evaluate to a single power series object (although the
result is formally valid).  Instead use {\tt ps(a*x,x,0)} {\em etc.}.

Similarly expressions such as {\tt sin(A)} where {\tt A} is a PS object
currently will not be expanded. For example:

\begin{verbatim}
    a:=ps(1/(1+x),x,0);
    b:=sin a;
\end{verbatim}

will not expand {\tt sin(1/(1+x))} as a power series. In fact

\begin{verbatim}
          SIN(1 - X + X**2 - X**3 + .....)
\end{verbatim}

will be returned. However,

\begin{verbatim}
    b:=ps(sin(a),x,0);
\end{verbatim}

or

\begin{verbatim}
    b:=ps(sin(1/(1+x)),x,0);
\end{verbatim}

should work as intended.

The handling of functions with essential singularities is currently
erratic: usually an error message

\hspace*{2em} {\tt ***** Essential Singularity}

or

\hspace*{2em} {\tt ***** Logarithmic Singularity}

occurs but occasionally a division by
zero error or some drastic error like (for PSL) binding stack
overflow may occur.

There is no simple way to write the results of power series
calculation to a file and read them back into REDUCE at a later
stage.
\end{document}


\chapter{Evaluation}

\section{Two bit XOR: The minimal case}\label{S:XOR}

\subsubsection{Description}

The starting point for the evalatuion is examining the ORBM reconstructions in a two bit pattern, where two of the same model are combining to form the data. This model makes one bit on in a two bit pattern, i.e. $[1 , 0]$ or $[0 , 1]$. The training set is the two bit XOR truth table and it provides the minimal case to compare the full correction calculation, versus that of the proposed approximation (see Equation \ref{eq:Full-Corretion} and \ref{eq:Approx-Correction} respectively).

\begin{figure}[h]
  \begin{center}
    \includegraphics[width=0.3\textwidth]{Assets/Two-Bit-RBM.png}
  \end{center}
  \caption{The two bit RBM for modelling a single bit on at a time in a two bit pattern. The diagonal weights are negative and the non-diagonal weights are positive.}
  \label{F:Two-Bit-RBM}
\end{figure}

\subsubsection{Architecture and Parameters}

Being a trivial dimensionality, the RBMs weights were constructed by hand, meaning that only the ORBMs inference algorithm was being evaluated and not the training of the RBMs plugged into it. This network is picture in Figure \ref{F:Two-Bit-RBM}.

\subsubsection{Method}

This RBM was checked to ensure that it behaved in practice by ensuring it's reconstructions matched the input for a large frequency of reconstructions.
\begin{figure}[htb]
  \begin{center}
    \includegraphics[width=0.7\textwidth]{Assets/XOR-ORBM-Creation-Process.png}
  \end{center}
  \caption{The process used to create the ORBM for evalating composite XOR inputs.}
  \label{F:XOR-ORBM-Creation-Process-Diagram}
\end{figure}
In a similar way to the reconstructions, free-phase visible pattern samples can be taken from the model and evaluated. In the small dimensions the dreams of the RBM should match the training set. A bar graph of frequencies of dreams was created and the RBM behaves as expected, generating dream patterns that match the training set in the correct proportion. With a valid model established, the XOR RBM was duplicated and plugged into the ORBM structure as illustrated in Figure \ref{F:XOR-ORBM-Creation-Process-Diagram}.

The inference algorithm was run in the ORBM architecture for various visible inputs, giving two hidden vectors for the two representations $h^A$ and $h^B$. For each pair of hidden vectors, a reconstruction was created, the process illustrated in Figure
\begin{figure}[h]
  \begin{center}
    \includegraphics[width=0.5\textwidth]{Assets/XOR-2-Bit-Process-Diagram.png}
  \end{center}
  \caption{The process of generating reconstruction is shown in this diagram.}

  \label{F:Two-Bit-ORBM-Process-Diagram}
\end{figure}~\ref{F:Two-Bit-ORBM-Process-Diagram}. This process was repeated in a similar way to how the reconstructions were evaluated in the lone RBM, counting the frequency each reconstruction occurred over $1500$ runs.

\begin{table}[]
\centering
\begin{tabular}{|l|l|l|}
\hline
Visible Input & \multicolumn{2}{l|}{Expected Reconstructions} \\ \hline
$[1 , 1 ]$    & $[1, 0]$              & $[0,1]$               \\ \hline
$[1, 0 ]$     & $[1,0]$               & $[1, 0]$              \\ \hline
$[0, 1]$      & $[0,1]$               & $[0,1]$               \\ \hline
\end{tabular}
\caption{A Table showing the expected reconstructions from performing ORBM inference with various input patterns. The left and right hand column of the Expected Reconstructions colummn indicate the reconstructions from the left and right RBMs in the ORBM.}
\label{my-label}
\end{table}

\subsubsection{XOR ORBM Analysis}

The results of this process are shown in figure \ref{F:Two-Bit-RBM-Inference-Results-1}. The ORBM is able to separate the causes with both types of correction, as the model is being duplicated, it produces $[1,0]$ and $[0,1]$ approximately half the time and symmetrically $[0,1]\text{ }[1,0]$ the other half of the time. These reconstructions were compared to one of the RBMs trained to recognised a single pattern being on in two bits. As expected a machine that has been trained to recognise one bit, has no concept of two bits being on and hence the reconstructions show no mechanism for separating the sources. This is illustrated in the bottom right of Figure \ref{F:Two-Bit-RBM-Inference-Results-1}.

The results of repeating this process with the input $[1,0]$ yielded successful results. We would hope that ORBM architecture could also handle inference with just a single subject. The results of this are shown in the top right and bottom left of Figure \ref{F:Two-Bit-RBM-Inference-Results-1}.

The ORBM was able to extract the target patterns $[1,0]$ and $[0,1]$ given the input $[1,1]$. This was the case for both the Approximated and Full corrections, which gave confidence that the more computationally efficient Approximated correction could be relied on going forward --- as for larger datasets it is a lot faster in practice. The generative model also copes with the subject overlapping, which in the two bit case arised when $[1,0]$ is composed with $[1,0]$. In both the Approximated and Full corrections the highest occurring reconstruction is the target $[1,0]$, however there appears to be a lot less confidence.

\begin{landscape}
\begin{figure}
  \begin{center}
    \includegraphics[height=0.9\textheight]{Assets/results/xor-results}
  \end{center}
  \caption{A figure showing the result of generating 1000 reconstructions with an RBM and ORBM on various inputs.}
  \label{F:Two-Bit-RBM-Inference-Results-1}
\end{figure}
\end{landscape}

\section{$Y$ bit pattern, $X$ neighbouring bits on} %%%%%%%%%%%%%%%%%%%%%%%%%%

\subsubsection{Description}
A natural next step from a single bit on in a 2 bit pattern, is moving up to $X$  bits side by side on in a $Y$ bit pattern. In affect this is modelling a $X$ bit subject, in a $Y$ bit pattern.
For example if $Y = 4 $ and $ X = 2 $ then a valid inputs are the rows of the following table:
\begin{equation}\label{eq:Example-xy-dataset} dataset =
\begin{bmatrix}
  1 & 1 & 0 & 0 \\
  0 & 1 & 1 & 0 \\
  0 & 0 & 1 & 1
\end{bmatrix}
\end{equation}

This allows for some interesting cases, for instance using the same example as above of $Y = 4 $ and $ X = 2 $, we can examine how the ORBM handles separating interesting patterns. For instance where \emph{subjects} partially overlap such as $[1,1,1,0]$, which is a composition of $[1,1,0,0]$ and $[0,1,1,0]$. This evaluation will explore these interesting cases over a subset of the possible combinations of $Y$ and $X$, ensuring that the ORBM is able to reconstuct the combination of images correctly.

\subsubsection{Architecture and Parameters}
\begin{itemize}
  \item $|Y|$ Hidden units per RBM, any less and I was unable to train the RBM to make the target reconstructions or dreams.
  \item The RBM was trained with $1000$ epochs and a learning rate of $0.002$.
  \item A sample of 10,000 dreams were sampled from the RBMs, and then plotted on a bar graph. The frequency of produced dreams was ensured to be approximately equal and that the dreams should directly match the training set. This is feasible as the ground truth patterns are known.
\end{itemize}

\subsubsection{Method and Results}

For a subset of values of $y \in Y, x \in X | 2 < x < y < 10$ the following process was repeated:

\begin{enumerate}
  \item A single RBM was trained on all possible permutations of $X$ neighbouring bits being on in a $Y$ bit string (as seen in the Matrix~\ref{eq:Example-xy-dataset}).
  \item The trained RBM was duplicated and plugged into the ORBM architecture.
  \item For a subset of possible compositions of two patterns, generate reconstructions using the ORBM (and the approximate correction). Where the cases examined are interesting cases such as partial overlapping and completely separate subjects.
  \item Finally reconstructions are plotted on bar graphs ensuring they match the expected results.
\end{enumerate}

A subset of the larger (but still small) dimension task results are shown in Figure \ref{F:X-Bit-ORBM-Inference-Results-1}. These illustrate the more interesting cases and the ORBM correctly separates the sources in all of them. The top left graph in Figure \ref{F:X-Bit-ORBM-Inference-Results-1} extends the work in section \ref{S:XOR} by recognising a single bit in a 5 bit pattern and the ORBM is successful. The top right graph illustrates the case of a 1 bit overlap of data made up of 2 neighboring bits. The bottom left graph also exemplifies a 1 bit overlay but this time with a `wider` pattern of 3 bits. The bottom right graph shows the case where the two `subjects` are side by side, not overlapping. This is a disparity here that would likely be solved creating more reconstructions.

\begin{landscape}
\begin{figure}
  \begin{center}
    \includegraphics[height=0.9\textheight]{Assets/results/xy-bit-results}
  \end{center}
  \caption{A figure showing interesting cases of ORBM reconstructions in $Y$ bit pattern, $X$ neighbouring bits on.}

  \label{F:X-Bit-ORBM-Inference-Results-1}
\end{figure}
\end{landscape}

\section{2D Patterns in a small dimensional space}%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsubsection{Description}
This task continues to work with a single RBM being duplicated, instead increasing the dimensionality from $~10$ to $25$ in the form of a 5 by 5 pixel image. Then another similar model is introduced so the ORBM has to separate a 2 by 2 square and various sized rectangles.

\begin{figure}[htb]
  \begin{center}
    \includegraphics[width=0.3\textwidth]{Assets/results/sq-dataset.png}
  \end{center}
  \caption{A figure illustrating the dataset used for this task. 2 by 2 pixel squares in a 5 by 5 pixel image.}
  \label{F:Sq-Dataset}
\end{figure}

\subsubsection{Architecture and Parameters}
\begin{itemize}
  \item Uses a 25 hidden unit RBM trained on a dataset of every permutation of a 2 by 2 square in a 5 by 5 pixel image. This dataset is illustrated in Figure \ref{F:Sq-Dataset}.
  \item The trained RBMs reconstructions and dreams were visually inspected, as well as Hinton diagrams to ensure an effective model.
  \item When performing inference in the ORBM, 500 Gibbs iterations were used. In practice this number is quite large however as the dimensions are small it is not computational intractable, and this gives more confidence that the ORBM is performing to the best of its ability.
\end{itemize}

\subsubsection{Method and Results}

The method followed a similar process as previous evaluations: Generate the training data and training and verfiying the RBM to make sure it performs well.
Next the whole dataset was composited with every other item in that dataset, and ORBM reconstructions were then generated (using 500 Gibbs iterations when calculating the correction), as were RBM reconstructions.
A subset of compelling results from this process were extracted and are shown in Figure \ref{F:sq-orbm-results}. I only show a single RBM reconstruction here as the same model is being used for both subjects.

\subsubsection{Square results}
\begin{description}
  \item[Column 1] Shows two squares sitting side by side. As expected the RBM, only modeling a single square reconstructs a square in the middle of the two. The ORBM is able to successfully extract and reconstruct the separate squares.
  \item[Columns 2 and 3] Here we see a single pixel overlap, the ORBM successfully reconstructing the ground truth. The RBM, despite having identical weights to the RBM that is plugged into the ORBM there is no mechanism to separate the sources. The ORBM does not perform perfectly in column 3, in that one if it's reconstructions is correct but the other is noiser than the RBM.
  \item[Columns 4, 5 and 6] Much like column 1 we have disjoint subjects, the ORBM successfully separates them, however the RBM performs much, much worse.
\end{description}

This process was repeated except a different RBM was introduced, one that represents a rectangle instead of square. Plugging the original square model and the new rectangle into the ORBM architecture. The results for this aspect are shown in \ref{F:rect-orbm-results}.

\subsubsection{Rectangle results}
\begin{description}
  \item[Columns 1 and 2] These show two instances of the ORBM being able to separate a square and rectangle of different sizes.
  \item[Columns 3] This shows a confusing case where the square is completely occluded by the the larger square. The ORBM reconstructions look valid in that it reconstructs the correct shapes, unlike the RBM, however the placing of the 2 by 2 square is in fact incorrect.
  \item[Columns 4, 5 and 6] Here we see partially overlapping shapes of various sizes. The ORBM generates less noisy reconstructions compared to the RBM.
\end{description}

\begin{figure}[htb]
  \begin{center}
    \includegraphics[width=\textwidth]{Assets/results/sq-orbm-results.png}
  \end{center}
  \caption{Figure illustrating a subset of the the results from ORBM inference on 2 By 2 square images.}
  \label{F:sq-orbm-results}
\end{figure}

\begin{figure}[htb]
  \begin{center}
    \includegraphics[width=\textwidth]{Assets/results/rect-sq-orbm-results.png}
  \end{center}
  \caption{Figure illustrating a subset of the the results from ORBM inference on 2 by 2 squares combined with $x$ by $y$ pixel rectangles. Note that there is a different RBM (and corresponding ORBM) being used for different values of $x$ and $y$ in the figure.}
  \label{F:rect-orbm-results}
\end{figure}

  \section{MNIST Digits Mixing Time and Reconstructions}

  \subsubsection{Description}
  MNIST is a widely used dataset of handwritten digits (0 -- 9). This evaluation explored the non-trivial task of given two handwritten digits composited to form one image, how effectively can the ORBM separate the sources compared to the naive RBM?

  \subsubsection{Architecture and Parameters}

  \begin{itemize}
    \item MNIST Digit images are 28 by 28 pixel images, with pixel values between 0 -- 1.
    \item Ten RBMs each with 100 Hidden units trained on 500 examples of each digit respectively. Reconstructions and dreams of these RBMs were inspected by hand to ensure that they resembled the dataset.
  \end{itemize}

  \subsubsection{Method and Results}

  For every digit dataset (of size 500), each digit in each dataset was composed with every other digit in every other dataset. Given this set of composite datasets, the corresponding RBMs were plugged in the ORBM architecture and used to create reconstructions.

  As an MNIST image has 784 (28 by 28 pixels) features, more consideration is need for how many Gibbs iterations should be used to generate the hidden states ($h^A$ and $h^B$) given the input. By examining reconstructions at different points in the Gibbs chain we can get a sense of how quickly the chain is mixing. A subset of these chains are illustrated in Figure \ref{F:MNIST-Mixing-Time}.
  \begin{figure}[htb]
    \begin{center}
      \includegraphics[width=0.8\textwidth]{Assets/results/Mixing-Results.png}
    \end{center}
    \caption{A figure visualising how reconstructions change in the ORBM as Gibbs iterations are run for two compositions of digits three and two.}
    \label{F:MNIST-Mixing-Time}
  \end{figure}
  By visually inspecting the reconstructions and the associated hidden activations (the hidden activations are not pictured) at Gibbs iterations 1,2,5,10,50,100, and 500 it can be seen the Gibbs chain mixes very quickly. Viewing these reconstructions as animations it is easier to see how the reconstructions stabilise and this lead to the choice of using 100 Gibbs iterations, just to be ensure the chain is definitely mixed while not being such a long chain that it is intractable to run.

  This diagram also reveals an interesting case where the hidden activations have turned completely off. The reconstruction however appears grey with all values pixel being $0.5$. As mentioned in Section \ref{S:Biases}, the ORBM does not use a visible bias which would be responsible for making an all zero reconstruction given no activations in the hidden layer.

  Given the results of the exploration of the mixing time, 100 Gibbs iterations were used when generating the hidden states ($h^A$ and $h^B$) for a given input. The RBMs plugged into the ORBM were also used to create standard RBM reconstructions, to compare against the ORBM. Given the ORBMs reconstructions (two per image) and the RBM reconstructions (also two per image), two scores were applied to compare these reconstructions to the ground truth:
  \begin{description}
    \item[Cross Entropy] The cross entropy was calculated between the reconstruction and the ground truth.
    \item[Cosine Angle] The angle between the flattened reconstruction vectors was computed, then negated to give a `score`. The higher the score the smaller the angle between the reconstruction vector and the ground truth.
  \end{description}
  These scores can then be summed over each digit and over the entire dataset to find a single score for each digit composed with every other digit forming a 9 by 9 matrix. A cell of this matrix (say $j,i$) corresponds to the difference between the ORBM score and RBM scores for digits $j$ and $i$ composited together. This entire process was repeated 10 times gain certainty in the results --- given the stochasticity of the RBM and ORBM. This process is shown in Algorithm \ref{alg:scores}.

  \begin{algorithm}[!ht]
   \KwData{MNIST Digit datasets, each with 500 examples, 10 RBMs trained on MNIST data 0--9 respectively}
   \KwResult{Composite Datasets for every digit}

   \For {10 repetitions to gain confidence in results (via the ECS Grid)} {
     \For{All MNIST digits datasets}{
      \For{Every digit example in the MNIST digit}{
        composite the current digit dataset with every other dataset\;
        Generate reconstructions on that dataset using the ORBM, RBM\;
        Calculate the Cosine Angle score and Cross Entropy for both the RBM's and ORBM's reconstructions versus the ground truth\;
      }
      Sum the scores over every digit example\;
     }
     Tabulate the summed scores in a several matrices indexed by the digits being composited\;
   }
  \caption{The algorithm explaining how the scores matrices were computed.}\label{alg:scores}
  \end{algorithm}

  By finding the difference between the ORBMs reconstructions and the RBMs reconstruction we can create another matrix, in which a positive value represents a `win` for the ORBMs reconstructions and a negative value represents a `loss` (where the RBM outperformed the ORBM). These score difference matrices are seen in for the Cross Entropy and Cosine Angle scores in \ref{F:Cross-Entropy-MNIST} and \ref{F:Cosine-MNIST} respectively, where the colour encodes the score. For the Cosine score,  using the approximate correction, zero composed with every other digit yielded the best results for ORBM relative to the RBM, and nine the converse yielding particularly bad results (worse by a factor of 10 compared to zero). Given this, I plotted the RBMs Score versus the ORBM Score as a scatter plot, where each point corresponds to a score. This allows us to examine if the ORBM is performing worse as a whole, or if in some cases it is performing better than the RBM. These plots for zero and nine are shown in \ref{fig:mnist-worse-best-results}.

  Lastly, the top two scoring ORBM reconstructions are shown in Figure \ref{F:Best-Results-MNIST} for the composition of a four and a five image and a two and four image respectively. In the four composited with five input, the two closest five ORBM reconstruction compared to the ground truth is shown along with the reconstruction from the other model (RBM B) connected to the ORBM.
  In the two composited with the four image, the two highest scoring four ORBM reconstructions are shown a long with the corresponding RBM reconstructions.
  The opposite, worst scores are illustrated in \ref{F:Worst-Results-MNIST}

  I selected four composited with five and two composited with four as the four is a challenging digit in that there are strikingly different ways to draw a four. As a human looking at the composition inputs, it is not immediately clear what parts of the image are caused by the four, and which are caused by the five or two respectively.

  \begin{figure}[h]
  \centering
  \begin{subfigure}[t]{0.45\textwidth}
      \includegraphics[width=\textwidth]{Assets/Cross-Entropy-Score.png}
      \caption{The difference between the RBM and ORBM cross entropy score summed over every item in the composite dataset.}
      \label{F:Cross-Entropy-MNIST}
  \end{subfigure}
  ~ %add desired spacing between images, e. g. ~, \quad, \qquad, \hfill etc.
    %(or a blank line to force the subfigure onto a new line)
  \begin{subfigure}[t]{0.45\textwidth}
      \includegraphics[width=\textwidth]{Assets/Cosine-Score.png}
      \caption{The difference between the RBM and ORBM cosine score summed over every item in the composite dataset.}
      \label{F:Cosine-MNIST}
  \end{subfigure}
  \caption{Dataset-wide MNIST Score Results }\label{fig:mnist-dataset-wide-results}
\end{figure}

\begin{figure}[h]
    \centering
    \begin{subfigure}[t]{1\textwidth}
        \includegraphics[width=\textwidth]{Assets/b.png}
        \caption{The cosine score for all digits composited with a handwritten zero.  }
      \label{F:Cosine-0-x-scores}
    \end{subfigure}
    \begin{subfigure}[t]{1\textwidth}
        \includegraphics[width=\textwidth]{Assets/(9,X)-ReconstructionScores.png}
        \caption{The cosine score for all digits composited with a handwritten nine.  }
      \label{F:Cosine-9-x-scores}
    \end{subfigure}
    \caption{Cosine Score breakdown for the highest and lowest performing datasets, 0 and 9.}\label{fig:mnist-worse-best-results}
\end{figure}

\begin{figure}[htb]
  \begin{center}
    \includegraphics[width=0.9\textwidth]{Assets/results/orbm-Best-2-results.png}
  \end{center}
  \caption{The top two ORBM reconstruction results for two different compositions. The highest scoring fives form the basis for the left part of the diagram. The highest scoring fours form the basis for the right part of the diagram.}
  \label{F:Best-Results-MNIST}
\end{figure}

\begin{figure}[htb]
  \begin{center}
    \includegraphics[width=0.9\textwidth]{Assets/results/orbm-Worst-2-results.png}
  \end{center}
  \caption{The worst two ORBM reconstruction results for two different compositions. The highest scoring fives form the basis for the left part of the diagram. The highest scoring fours form the basis for the right part of the diagram.}
  \label{F:Worst-Results-MNIST}
\end{figure}

\subsection{MNIST Analysis}

It is clear that RBM has better scores than the ORBM when summed over the dataset, and surprising the Approximated correction results in better scores than the Full Correction calculation. For the dataset wide scores \ref{fig:mnist-dataset-wide-results} I would expect to see symmetry in that, for example four composited with five, should score the same as five composited with four.

\section{Evaluation Analysis}

It is clear that the ORBM outperforms the RBM in source separation in the smaller tasks, such as XOR. However, as the size of the problems increased I had less confidence until ultimately it performed worse by the scores defined in the MNIST digit dataset. This amounts to the inference algorithm performing worse in large dimensions, with harder tasks. It is not related to the mixing time as that was explored on the same task that the ORBM had the most trouble with. In fact in examining the mixing time it appears it takes very few Gibbs iterations to actually arrive and settle at the wrong answer.
Yet in examining the individual scores for the various compositions of the MNIST dataset, the ORBM is performing worse in the majority of cases with only a small subset of examples scoring better than the RBM acting alone. Looking at example reconstructions, I would not say that it is that clear cut that the ORBM is performing worse.

As possible explanation could be that by plugging separately trained RBMs, into the ORBM architecture means that there is no regularisation of weights between the two RBMs. The RBMs were trained independently until they produced accurate reconstructions and dreams that approximately matched items from the dataset, however the process was adhoc and not identical per model. The reason this could be an issue is that the correction adjusts the visible input to the other model by roughly the weight. If the range of weights between the models is drastically different then one model could ``overpower'' the other. This would explain the effect where the hidden representation generated is entirely zero (no activation) as the other RBM is ``taking responsibility'' for the entirety of the input.


\documentclass[10pt]{article}
\usepackage{bm}% bold math
\usepackage{amsmath}

\begin{document}

\subsection{Original NEB}

Nudged elastic band (NEB) approaches to locating transition states are efficient alternatives to evaluating the PES on a uniform grid over some coordinates of interest. The implementation in \emph{autodE} follows that in [\emph{J. Chem. Phys.}, 2000, {\bfseries{113}}, 9978]
\\\\
For an image $i$ in the nudged elastic band
\begin{equation}
\boldsymbol{\tau}_i =
\begin{cases}
\boldsymbol{\tau}_i^+ &\quad\text{if}\quad V_{i-1} < V_i < V_{i+1} \\
\boldsymbol{\tau}_i^- &\quad\text{if}\quad V_{i+1} < V_i < V_{i-1} \\
\boldsymbol{\tau}_i^+\Delta V_i^{max} + \boldsymbol{\tau}_i^-\Delta V_i^{min} &\quad\text{if}\quad V_{i-1} <  V_{i+1} \\
\boldsymbol{\tau}_i^+\Delta V_i^{min} + \boldsymbol{\tau}_i^-\Delta V_i^{max} &\quad\text{if}\quad V_{i+1} < V_{i-1} \\
\end{cases}
\end{equation}
where
\begin{equation}
\begin{aligned}
\boldsymbol{\tau}_i^+ &= \boldsymbol{x}_{i+1} - \boldsymbol{x}_i \\
\boldsymbol{\tau}_i^- &= \boldsymbol{x}_{i} - \boldsymbol{x}_{i-1}
\end{aligned}
\end{equation}
and
\begin{equation}
\begin{aligned}
\Delta V_i^{max} &= \max(|V_{i+1} - V_i|, |V_{i-1} - V_i|) \\
\Delta V_i^{min} &= \min(|V_{i+1} - V_i|, |V_{i-1} - V_i|)
\end{aligned}
\end{equation}
and $\boldsymbol{x}_i$ are the coordinates of image $i$. The spring force is
\begin{equation}
\boldsymbol{F}^s_i|_{\parallel} = (k_i|\boldsymbol{x}_{i+1} - \boldsymbol{x}_i| - k_{i-1}|\boldsymbol{x}_i - \boldsymbol{x}_{i-1}|) \hat{\boldsymbol{\tau}}_i
\end{equation}
and the total force on the image
\begin{equation}
\boldsymbol{F}_i = \boldsymbol{F}^s_i|_{\parallel} - \nabla V(\boldsymbol{x}_i)|_\perp
\end{equation}
where
\begin{equation}
\nabla V(\boldsymbol{x}_i)|_\perp = \nabla V(\boldsymbol{x}_i) - \nabla V(\boldsymbol{x}_i)\cdot \hat{\boldsymbol{\tau}}_i\hat{\boldsymbol{\tau}}_i
\end{equation}
and finally $\hat{\boldsymbol{\tau}} = \boldsymbol{\tau}_i/|\boldsymbol{\tau}_i|$.
\\\\
\subsection{CI-NEB}

The climbing image (CI) NEB implementation follows that in [\emph{J. Chem. Phys.}, 2000, {\bfseries{113}}, 9901] where after a few iterations the force on the maximum energy image ($m$) is given by

\begin{equation}
\boldsymbol{F}_{m} = -\nabla V(\boldsymbol{x}_m) + 2\nabla V(\boldsymbol{x}_m)\cdot \hat{\boldsymbol{\tau}}_i\hat{\boldsymbol{\tau}}_i
\end{equation}

which is the force due to the potential along the band being inverted.

\end{document}


\subsection{Type models}
\label{subsec:formalisations:ecore_formalisation:type_models}
This section provides the formal definition of type models, which are models that are based on the Ecore metamodel, of which a simplified version is given in \cref{fig:formalisations:ecore_formalisation:ecore}. A type model provides a set of definitions and constraints that describe a set of instance models, which may or may not be valid according to the type model. On the top level, it defines a set of \textit{classes}, \texttt{EClass}es, of which instances (\textit{objects}) may be used within the instance model. The classes contain a set of \textit{fields}, \texttt{EStructuralFeature}s, which are identified by a name which is unique within the class. Each of these \texttt{EStructuralFeature}s is typed and has a multiplicity. Class instances in the instance model may assign values to these fields (specific for that instance) which must adhere to both the type and multiplicity of the field. The type model also defines an \textit{inheritance} relation between these classes, modelled by \texttt{eSupertypes} in the Ecore metamodel, which allows classes to inherit from other classes, providing a specialisation of that class.

A type model also defines a set of \textit{enumerations}, \texttt{EEnum}s, and their values, \texttt{EEnumLiteral}s. Each enumeration defines a unique type with a fixed set of values. Furthermore, a set of \textit{constants} and their types define a symbolic typed value, which relates to a specific value in an instance model. A set of \textit{custom data types}, \texttt{EDataType}s, is also provided by the type model, which allows the representation of user-defined data types.

Finally, a set of \textit{properties} of the type model specifies the properties an instance model of this type model has to satisfy in order to be valid. These properties specify constraints on the values and structure of such an instance model.

The definition of a type model depends on the definition of various types. These types again depend on the definition of the type model. The solution to this cyclic dependency is the smallest solution to the set of equations given for the types and type model.

The suffix $Tm$ is used when the definition of something depends on any type model $Tm$, for example, $Class_{Tm}$.

\begin{defin}[Type model]
\label{defin:formalisations:ecore_formalisation:type_models:type_model}
A single type model $Tm$ is a 10-tuple, consisting of 8 sets and 2 functions, which is defined as:
\begin{equation*}
    Tm = \langle Class, Enum, UserDataType, Field, \mathrm{FieldSig}, EnumValue, Inh, Prop, Constant, \mathrm{ConstType} \rangle
\end{equation*}
with
\begin{itemize}
    \item $Class \subseteq Id$ is the set of classes (\texttt{EClass} objects) in $Tm$.
    \item $Enum \subseteq Id$ is the set of enumerations (\texttt{EEnum} objects) in $Tm$.
    \item $UserDataType \subseteq Id$ is the set of custom data types (\texttt{EDataType} objects) in $Tm$.
    \item $Field \subseteq (Class \times Name)$ is the set that maps a class to a set of field names (\texttt{EStructuralFeature} objects) in $Tm$.
    \item $\mathrm{FieldSig}: Field \Rightarrow (Type_{Tm} \times \mathbb{M})$ is the function that maps fields to their type (as defined in \cref{defin:formalisations:ecore_formalisation:type_models:types}) and multiplicity (as defined in \cref{defin:formalisations:global_definitions:multiplicity}).
    \item $EnumValue \subseteq Enum \times Name$ is the set of possible values (the \texttt{EEnumLiteral}s) for the enumerations in $Tm$.
    \item $Inh \subseteq Class \times Class$ is the inheritance relation between the classes in $Tm$.
    \item $Prop \subseteq Property_{Tm}$ is the set of properties that apply to $Tm$ (see definition \cref{defin:formalisations:ecore_formalisation:type_models:type_model_properties}).
    \item $Constant \subseteq Id$ is the set that contains all possible constants that may be used as a (symbolic) default value.
    \item $\mathrm{ConstType}: Constant \Rightarrow Type_{Tm}$ is the function that maps constants to their respective types.
\end{itemize}
where
\begin{itemize}
    \item $Class$, $DataType$ (\cref{defin:formalisations:ecore_formalisation:definitions:data_types}), $Enum$ and $UserDataType$ are pairwise disjoint.
    \item None of the elements in $Class \cup DataType \cup Enum \cup UserDataType$ may be in the namespace of another element in that set.
    \item $Inh$ is an asymmetric relation, of which the transitive closure is irreflexive.
\end{itemize}

\isabellelref{type_model}{Ecore.Type_Model}
\end{defin}

\begin{figure}[p]
    \centering
    \begin{subfigure}{\textwidth}
        \centering
        \includegraphics{images/03_formalisations/02_ecore_formalisation/type_model_example.pdf}
        \caption{Type model in Ecore notation}
    \end{subfigure}

    \begin{subfigure}{\textwidth}
        \centering
        \begin{align*}
            Class_{Tm} =\ & \{
                .\type{House},
                .\type{Person},
                .\type{Renter},
                .\type{Room}
            \}\\
            Enum_{Tm} =\ & \{
                .\type{PaymentInterval}
            \}\\
            UserDataType_{Tm} =\ & \emptyset\\
            Field_{Tm} =\ & \{
                ( .\type{House}, \type{name} ),
                ( .\type{House}, \type{rooms} ),\\&
                ( .\type{Person}, \type{age} ),
                ( .\type{Person}, \type{name} ),\\&
                ( .\type{Renter}, \type{payment\_interval} ),
                ( .\type{Renter}, \type{rents} ),\\&
                ( .\type{Room}, \type{number} ),
                ( .\type{Room}, \type{renter} )
            \}\\
            \mathrm{FieldSig}_{Tm} =\ & \Big\{
                \Big( \big( .\type{House}, \type{name} \big), \big( \type{string}, 1..1 \big) \Big),
                \Big( \big( .\type{House}, \type{rooms} \big), \big( [ \type{setof},  !.\type{Room} ], 1..\mstar \big) \Big),\\&
                \Big( \big( .\type{Person}, \type{age} \big), \big( \type{integer}, 1..1 \big) \Big),
                \Big( \big( .\type{Person}, \type{name} \big), \big( \type{string}, 1..1 \big) \Big),\\&
                \Big( \big( .\type{Renter}, \type{payment\_interval} \big), \big( .\type{PaymentInterval}, 1..1 \big) \Big),\\&
                \Big( \big( .\type{Renter}, \type{rents} \big), \big( [ \type{setof}, !.\type{Room} ], 0..\mstar \big) \Big),\\&
                \Big( \big( .\type{Room}, \type{number} \big), \big( \type{integer}, 1..1 \big) \Big),
                \Big( \big( .\type{Room}, \type{renter} \big), \big( !.\type{Renter}, 0..1 \big) \Big)
            \Big\}\\
            EnumValue_{Tm} =\ & \{
                ( .\type{PaymentInterval}, \type{MONTH} ),
                ( .\type{PaymentInterval}, \type{QUARTER} )
            \}\\
            Inh_{Tm} =\ & \{
                ( .\type{Renter}, .\type{Person} )
            \}\\
            Prop_{Tm} =\ & \{
                [ \type{abstract}, .\type{Person} ], \\&
                [ \type{identity}, \{( .\type{Person}, \type{age} ), ( .\type{Person}, \type{name} )\} ],
                [ \type{containment}, ( .\type{House}, \type{rooms} ) ],\\&
                [ \type{opposite}, ( .\type{Room}, \type{renter} ), ( .\type{Renter}, \type{rents} ) ],
                [ \type{opposite}, ( .\type{Renter}, \type{rents} ), ( .\type{Room}, \type{renter} ) ],\\&
                [ \type{defaultValue}, ( .\type{Renter}, \type{payment\_interval} ), .\type{Constant}.\type{PaymentInterval}.\type{Month} ]
            \}\\
            Constant_{Tm} =\ & \{
                .\type{Constant}.\type{PaymentInterval}.\type{Month}
            \}\\
            \mathrm{ConstType}_{Tm} =\ & \{
                ( .\type{Constant}.\type{PaymentInterval}.\type{Month}, .\type{PaymentInterval} )
            \}
        \end{align*}
        \caption{Formal definition of the type model}
    \end{subfigure}
    \caption{Example of a type model corresponding with \cref{defin:formalisations:ecore_formalisation:type_models:type_model}}
    \label{fig:formalisations:ecore_formalisation:type_models:type_model_example}
\end{figure}

An example type model is given in \cref{fig:formalisations:ecore_formalisation:type_models:type_model_example}. It shows 4 classes ($\type{House}$, $\type{Person}$, $\type{Renter}$ and $\type{Room}$) and a single enumeration ($\type{PaymentInterval}$). The $\type{Person}$ class has 2 fields, $\type{age}$ and $\type{name}$. The $\type{Renter}$ class has a field $\type{payment\_interval}$ which makes use of the $\type{PaymentInterval}$ enumeration. It also has a field $\type{rents}$ which defines a relation between $\type{Room}$ and $\type{Renter}$. The $\type{House}$ class has also 2 fields, a field $\type{name}$ and a field $\type{rooms}$ which is a containment relation between $\type{House}$ and $\type{Room}$. Moreover, we have the $\type{Room}$ class itself, which has 2 fields. One is called $\type{number}$ and the other one is called $\type{renter}$, which is the opposite relation between $\type{Room}$ and $\type{Renter}$. Finally, we see that $\type{Renter}$ inherits from $\type{Person}$.

The fields in a type model are always associated with a specific type, which defines the set of possible values that may be assigned in an instance model. The possible types are defined by the set of data types, classes, enumerations and user-defined data types. The set of types also consists of various aggregations of these types, namely containers. Containers provide types for multiple values of the same type, but of which the values may differ in number and order.

\begin{defin}[Types]
\label{defin:formalisations:ecore_formalisation:type_models:types}
Given any type model $Tm$, the set of types is defined as
\begin{equation*}
Type_{Tm} = DataType \cup ClassType_{Tm} \cup Enum_{Tm} \cup UserDataType_{Tm} \cup Container_{Tm}
\end{equation*}

The $ClassType_{Tm}$ set defines both a set of nullable and proper classes. Nullable classes are classes for which the $\type{nil}$ (see \cref{defin:formalisations:ecore_formalisation:definitions:nil}) value is valid, and proper classes are those classes for which the $\type{nil}$ value is not valid (hence both sets of classes are disjoint).

The $ClassType_{Tm}$ set is defined as
\begin{equation*}
ClassType_{Tm} = \{ \type{nullable}, \type{proper} \} \times Class_{Tm}
\end{equation*}

A container is a type that may contain multiple values in an instance. Containers define the type of values they contain, and the multiplicity of the container. They are defined by
\begin{equation*}
Container_{Tm} = \{ \type{bagof}, \type{setof}, \type{seqof}, \type{ordof} \} \times Type_{Tm}
\end{equation*}
For the interpretation of the values in $\{ \type{bagof}, \type{setof}, \type{seqof}, \type{ordof} \}$, see \cref{defin:formalisations:ecore_formalisation:instance_models:values}.

The set of types is recursively defined as the smallest solution of the equations for $Type_{Tm}$ and $Container_{Tm}$.

Tuples within $Type_{Tm}$ are written using square brackets, e.g. $[\type{bagof}, \type{int} ]$ or $[ \type{nullable}, C ]$. Furthermore, given a $C \in Class_{Tm}$, $?C$ is a short notation for the $\type{nullable}$ variant of $C$, $[ \type{nullable}, C ]$. In the same fashion, $!C$ is the short notation for the $\type{proper}$ variant of $C$, $[ \type{proper}, C ]$.

Finally, we define the function $\mathrm{uncontainer}\!: Container_{Tm} \Rightarrow Type_{Tm}$ which returns the type contained by a container.

\isabellelref{Type}{Ecore.Type_Model}
\end{defin}

In the example in \cref{fig:formalisations:ecore_formalisation:type_models:type_model_example}, the various fields make use of different types. The fields depicted as a relation between two classes are actually of a type based on the $Class_{Tm}$ set. For example, the $\type{rooms}$ field of class $\type{House}$ is typed by the $\type{Room}$ class. In this case, we assume that each $\type{Room}$ in a $\type{House}$ is unique. Thus the relationship is best typed by a $\type{setof}$ container. For a $\type{setof}$ container, the order does not matter, and each value should be unique. We also see the example of the usage of an enumeration, the $\type{payment\_interval}$ field on $\type{Renter}$ uses the $\type{PaymentInterval}$ enumeration. Finally, the $\type{Person}$ class shows two fields that are typed by some of the data types available, integer and string for the age and name fields respectively.

\begin{defin}[Field]
\label{defin:formalisations:ecore_formalisation:type_models:field}
Given any type model $Tm$, the $Field_{Tm}$ relation defines a binary relation between classes and fields.
In order to retrieve the set of fields for a given class (and the fields inherited from superclasses), the following function is defined:
\begin{equation*}
   \mathrm{fields}\!: Class_{Tm} \Rightarrow \mathcal{P}(Field_{Tm})
\end{equation*}
such that
\begin{equation*}
\mathrm{fields}_{Tm}(c) = \{f \in Field_{Tm} \mid f = ( c', n ) \land c \sqsubseteq_{Tm} c'\}
\end{equation*}

Given any type model $Tm$, the $\mathrm{FieldSig}_{Tm}$ function defines a mapping between fields and their signatures. The following functions are defined to retrieve various components of a field signature:
\begin{itemize}
    \item $\mathrm{class}\!: Field_{Tm} \Rightarrow Class_{Tm}$
    \item $\mathrm{type}\!: Field_{Tm} \Rightarrow Type_{Tm}$
    \item $\mathrm{lower}\!: Field_{Tm} \Rightarrow \mathbb{N}$
    \item $\mathrm{upper}\!: Field_{Tm} \Rightarrow \mathbb{N}^+ \cup {\mstar}$
\end{itemize}
These functions are defined as follows:
\begin{itemize}
    \item $\mathrm{class}_{Tm}(f) = class \quad \mathrm{iff} \quad f = ( class, name)$
    \item $\mathrm{type}_{Tm}(f) = type \quad \mathrm{iff} \quad \mathrm{FieldSig}_{Tm}(f) = ( type, ( lower, upper ) )$
    \item $\mathrm{lower}_{Tm}(f) = lower \quad \mathrm{iff} \quad \mathrm{FieldSig}_{Tm}(f) = ( type, ( lower, upper ) )$
    \item $\mathrm{upper}_{Tm}(f) = upper \quad \mathrm{iff} \quad \mathrm{FieldSig}_{Tm}(f) = ( type, ( lower, upper ) )$
\end{itemize}

Fields can be separated into relation and attribute sets, where attributes reference (containers of) data types, user data types and enumerations, and relations reference all other types. The sets are defined by
\begin{align*}
    Attr_{Tm} =&\, \{f \in Field_{Tm} \mid type(f) \in (DataType \cup Enum_{Tm} \cup UserDataType_{Tm})\,\vee\\&\quad type(f) \in \{ \type{setof}, \type{bagof}, \type{ordof}, \type{seqof} \} \times Attr_{Tm}\}\\
    Rel_{Tm} =&\, Field_{Tm} \setminus Attr_{Tm}
\end{align*}
The set of attributes is recursively defined as the smallest solution of the given set of equations for $DataType$, $Enum_{Tm}$, $UserDataType_{Tm}$ and $Attr_{Tm}$

\isabellelref{fields}{Ecore.Type_Model}
\end{defin}

Taking for example the field $\type{rents}$ from the $\type{Renter}$ class in the type model example in \cref{fig:formalisations:ecore_formalisation:type_models:type_model_example}, the following properties can be identified: The type refers to $\type{Room}$, which is an element of the $Class_{Tm}$ set. The
lower and upper values are $0$ and $\mstar$ respectively (which means a $\type{Renter}$ can rent an arbitrary number of rooms). Furthermore, the $\type{rents}$ field is an element of the $Rel_{Tm}$ set (it is a class container type) and part of the $fields_{Tm}(\type{Renter})$ set, which is $\{ \type{payment\_interval}, \type{rents} \}$.

The various types have an underlying subtype relation, which generalises inheritance. A subtype defines a specialisation of a supertype. Because of that, all values valid for the subtype are also valid for the supertype (see \cref{defin:formalisations:ecore_formalisation:instance_models:valid_type_values} for details).

\begin{defin}[Subtype relation]
\label{defin:formalisations:ecore_formalisation:type_models:subtype_relation}
Given any type model $Tm$, $\sqsubseteq_{Tm}\, \subseteq Type_{Tm} \times Type_{Tm}$ defines the subtype relation. It is a reflexive partial order relation, for which the following rules
can be defined (with $t_1, t_2, t_3 \in Type_{Tm}$ and $c_1, c_2 \in Class_{Tm}$):

Transitivity:
\begin{mathpar}
    \inferrule{t_1 \sqsubseteq_{Tm} t_2 \\ t_2 \sqsubseteq_{Tm} t_3}{t_1 \sqsubseteq_{Tm} t_3}
\end{mathpar}

Reflexivity:
\begin{mathpar}
    \inferrule{\ }{t_1 \sqsubseteq_{Tm} t_1}
\end{mathpar}

Generalization of inheritance:
\begin{mathpar}
    \inferrule{(c_1, c_2) \in Inh_{Tm}}{?c_1 \sqsubseteq_{Tm}\: ?c_2}
    \and
    \inferrule{(c_1, c_2) \in Inh_{Tm}}{!c_1 \sqsubseteq_{Tm}\: !c_2}
\end{mathpar}

Nullable/Proper classes:
\begin{mathpar}
    \inferrule{\ }{!c_1 \sqsubseteq_{Tm}\: ?c_1}
\end{mathpar}

\isabellelref{subtype}{Ecore.Type_Model}
\end{defin}

Thus, in the example, $[ \type{nullable}, \type{Renter} ] \sqsubseteq_{Tm} [ \type{nullable}, \type{Person} ]$ (since $(\type{Student}, \type{Person}) \in Inh_{Tm}$). Furthermore, it also holds that $[ \type{proper}, \type{Renter} ] \sqsubseteq_{Tm} [ \type{nullable}, \type{Renter} ]$, as a proper class is a subtype of a nullable class.

A type model may specify a set of properties, $Prop$, which an instance model has to satisfy in order to be valid. The following properties are defined:
\begin{itemize}
\item The $\type{abstract}$ property. This property, specified for a specific class in the type model, forbids the instantiation of that class in any instance model. As such, it is satisfied when no object exists in an instance model which is an instance of that class. Please note that this only holds for instances of that exact class. Subtyping may be allowed (under the condition that those classes are not $\type{abstract}$).

\item The $\type{containment}$ property. This property, specified for a relation, states that a single source object contains all objects that are the target of this relation. Objects are contained by at most one other object, and containment cycles are not allowed. When an object with contained objects is removed from an instance model, all contained objects are removed as well. The constraint is satisfied when an object is the target of no more than one containment relation, and there exists no cycle between containment relations.

\item The $\type{defaultValue}$ property. This property specifies a default value for a field which has not been assigned a value in an instance model. It specifies a constant for a field, which represents a value in an instance model. It is always satisfied and influences the behaviour of possible model transformations.

\item The $\type{identity}$ property. This property is specified for a class and a set of attributes. It is used to specify that the values for the set of attributes uniquely identify an object on instance model level. As such, it is satisfied when no two objects are both an instance of the class and have pairwise the same value for all the attributes.

\item The $\type{keyset}$ property. This property is specified for a set of attributes of a class and a relation towards that class. It ensures that each instance of that class within the given relation is uniquely identified by the values of the set of attributes. It is satisfied that two objects must be the same object if they are the target of the given relation, and they have pairwise-identical values for their attributes.

\item The $\type{opposite}$ property. This property specifies that two relations are the opposite of each other, which means that for each instance of the first relation, an instance of the second relation exists with a switched target and source. The property is satisfied when for each pair of objects, for each relation that exists between these objects, a reverse relation exists if both these relations are opposite.

\item The $\type{readonly}$ property. This property, specified for a field in the type model, forbids the assignment of a new value to that field in any instance model. This property only affects the possible transformations of an instance model and is always satisfied for any specific instance model.
\end{itemize}

\begin{defin}[Type model properties]
\label{defin:formalisations:ecore_formalisation:type_models:type_model_properties}
For a type model $Tm$ a set of properties $Property_{Tm}$ is defined which contains all the possible properties. This set is defined as

\begin{align*}
    Property_{Tm} =\ &
    \{[ \type{abstract}, c ] \mid c \in Class_{Tm} \}\ \cup \\&
    \{[ \type{containment}, r ] \mid r \in Rel_{Tm} \}\ \cup \\&
    \{[ \type{defaultValue}, f, v ] \mid f \subseteq Field_{Tm} \land v \in Constant_{Tm} \}\ \cup \\&
    \{[ \type{identity}, c, A ] \mid c \in Class_{Tm} \land A \subseteq Attr_{Tm} \}\ \cup \\&
    \{[ \type{keyset}, r, A ] \mid r \in Rel_{Tm} \land A \subseteq Attr_{Tm} \}\ \cup \\&
    \{[ \type{opposite}, r, r' ] \mid r, r' \subseteq Rel_{Tm} \land r \not= r'\}\ \cup \\&
    \{[ \type{readonly}, f ] \mid f \in Field_{Tm} \}
\end{align*}

where
\begin{itemize}
    \item $[ \type{defaultValue}, f, v ]$ is defined such that $\mathrm{ConstType}_{Tm}(v) \sqsubseteq_{Tm} \mathrm{type}_{Tm}(f)$.
    \item $[ \type{keyset}, r, A ]$ is defined such that $\mathrm{type}_{Tm}(r) \in (\{ \type{setof}, \type{ordof} \} \times ClassType_{Tm})$ with $\mathrm{type}_{Tm}(r) = [\type{setof}, c] \lor \mathrm{type}_{Tm}(r) = [ \type{ordof}, c ]$. Then also have that $\forall ( ac, an ) \in A\!:\: !c\sqsubseteq_{Tm}\,!ac$.
    \item $[ \type{opposite}, r, r' ]$ is defined such that when $r = ( c1, n1 ), r' = ( c2, n2 )$, then it should hold that $!c1 \sqsubseteq_{Tm} \mathrm{uncontainer}(\mathrm{type}_{Tm}(r'))$, $!c2 \sqsubseteq_{Tm} \mathrm{uncontainer}(\mathrm{type}_{Tm}(r))$, $\mathrm{type}_{Tm}(r) \not\in \{ \type{bagof}, \type{seqof} \} \times Type_{Tm}$ and finally $type_{Tm}(r') \not\in \{ \type{bagof}, \type{seqof} \} \times Type_{Tm}$ (containers must have unique values).
\end{itemize}

\isabellelref{Property}{Ecore.Type_Model}
\end{defin}

The example in \cref{fig:formalisations:ecore_formalisation:type_models:type_model_example} also shows a few properties:
\begin{itemize}
    \item The $\type{Person}$ class is declared abstract (indicated by the grey looking class layout and italic name)
    \item The $\type{age}$ and $\type{name}$ fields of a $\type{Person}$ are its identity (as indicated by the formal definition). Although it is highly unlikely that these details would be unique in the real world, they must be in our instance models.
    \item The $\type{rooms}$ relation of $\type{House}$ is a containment relation (shown by the filled diamond at the $\type{House}$ end of the containment relation).
    \item The $\type{rents}$ and $\type{renter}$ relations are opposites (as indicated by the formal definition).
    \item The $\type{payment\_interval}$ field has a default value $\type{MONTH}$ (as indicated with the field definition in the model).
\end{itemize}

With the given definitions, it is possible to define an inconsistent type model. Such a type model is correct according to the given definitions but does not specify any valid instance model using the definitions in \cref{subsec:formalisations:ecore_formalisation:instance_models}. Therefore, a definition is given for a consistent type model. A consistent type model enforces some constraints on multiplicities and properties within the type model to ensure the satisfiability of the definitions in \cref{subsec:formalisations:ecore_formalisation:instance_models}. Without these constraints, one or more of these definitions can never be satisfied at all. Please note that these constraints merely support the satisfiability of these definitions, it does not guarantee the existence of any meaningful instance model, as it might still be possible to define a `consistent' type model with conflicting multiplicities or properties.

\begin{table}[t]
    \centering
    \rowcolors{2}{gray!25}{white}
    \begin{tabular}{l|l}
        \rowcolor{gray!50}
        $Type_{Tm}$ & Multiplicity\\
        $\{ \type{proper} \} \times Class_{Tm}$ & $1..1$\\
        $\{ \type{nullable} \} \times Class_{Tm}$ & $0..1$\\
        $Container_{Tm}$ & $x..y \: (0 \leq x \leq y \land 1 \leq y)$\\
        $DataType$ & $1..1$\\
        $Enum_{Tm}$ & $1..1$\\
        $UserDataType_{Tm}$ & $1..1$
    \end{tabular}
    \caption{The allowed multiplicities for each type}
    \label{tab:formalisations:ecore_formalisation:type_models:possible_multiplicities}
\end{table}

\begin{defin}[Type model consistency]
\label{defin:formalisations:ecore_formalisation:type_models:type_model_consistency}
The multiplicities of the fields in $Field_{Tm}$ are consistent if it holds that:
\begin{align*}
    \mathrm{type}_{Tm}(f) \in DataType \cup Enum_{Tm} \cup UserDataType_{Tm} \cup (\type{proper} \times Class_{Tm}) \implies & \mathrm{lower}_{Tm}(f) = 1 \\
    \mathrm{type}_{Tm}(f) \in (\type{nullable} \times Class_{Tm}) \implies & \mathrm{lower}_{Tm}(f) = 0
\end{align*}
and
\begin{align*}
    \mathrm{type}_{Tm}(f) \not\in Container_{Tm} \implies & \mathrm{upper}_{Tm}(f) = 1
\end{align*}
as indicated by \cref{tab:formalisations:ecore_formalisation:type_models:possible_multiplicities}.

The properties in $Prop_{Tm}$ are consistent if the following holds:
\begin{itemize}
    \item $[ \type{containment}, r ] \in Prop_{Tm} \land [ \type{opposite}, r, r' ] \in Prop_{Tm} \Longrightarrow upper_{Tm}(r') = 1$ (opposite of containment relation must have upper bound of 1).
    \item $[ \type{defaultValue}, f, v ] \in Prop_{Tm} \land [ \type{defaultValue}, f, v' ] \in Prop_{Tm} \Longrightarrow v = v'$ (unique for f).
    \item $[ \type{identity}, c_1, A_1 ] \in Prop_{Tm} \land [ \type{identity}, c_2, A_2 ] \in Prop_{Tm}\: \land\: !c_1 \sqsubseteq_{Tm}\, !c_2 \Longrightarrow A_1 \subseteq A_2$ (classes may only have identities with attributes that are a subset of attributes part of the superclass' identity).
    \item $[ \type{keyset}, r, A ] \in Prop_{Tm} \land [ \type{keyset}, r, A' ] \in Prop_{Tm} \Longrightarrow A = A'$ (unique for $r$).
    \item $[ \type{opposite}, r, r' ] \in Prop_{Tm} \land [ \type{opposite}, r, r'' ] \in Prop_{Tm} \Longrightarrow r' = r''$ (unique for r).
    \item $[ \type{opposite}, r, r' ] \in Prop_{Tm} \Longleftrightarrow [ \type{opposite}, r', r ] \in Prop_{Tm}$ (symmetry).
\end{itemize}

Then a type model $Tm$ is consistent if and only if
\begin{itemize}
\item The multiplicities of all fields in $Field_{Tm}$ are consistent.
\item All properties in $Prop_{Tm}$ are consistent.
\end{itemize}

\isabellelref{type_model}{Ecore.Type_Model}
\end{defin}


% Generated by GrindEQ Word-to-LaTeX 2007
% LaTeX/AMS-LaTeX

\documentclass{article}
\usepackage[top=1in,right=1in,left=1in,bottom=1in]{geometry}
\pagestyle{empty}
%\usepackage{fullpage}
%\topmargin 0.0in
%\headheight 0.0in
%\pagestyle{empty}

%%% remove comment delimiter ('%') and specify encoding parameter if required,
%%% see TeX documentation for additional info (cp1252-Western,cp1251-Cyrillic)
\usepackage[cp1252]{inputenc}

%%% remove comment delimiter ('%') and select language if required
%\usepackage[english,spanish]{babel}

\usepackage{amssymb}
\usepackage{amsmath}
\usepackage[dvips]{graphicx}
%%% remove comment delimiter ('%') and specify parameters if required
%\usepackage[dvips]{graphics}

\begin{document}

\title{Extended real number system in measure theory}

\author{Satish Shirali\thanks{Email: satishshirali@usa.net, Address: House No.899, Sector 21, Panchkula, Haryana 134116, India}}

\date{}

\maketitle
\thispagestyle{empty}

\begin{abstract}
\noindent The extended real number system is usually defined by
appending two new elements and stating rules of addition and
multiplication for them. The associative and distributive laws are
then supposed to be verified case by case; however, the number of
cases to be verified is well over sixty. For the extended reals as
used in measure theory (product $0\cdot\infty$ is 0), we offer a
construction through equivalence classes, in which the number of
dissimilar cases does not exceed five at any
stage.
\end{abstract}

\vspace{1cm}

\noindent In any proof that requires consideration of separate
cases, usually the number of cases is small and it is quite clear
that all of them have been taken into account. However, when the
number of cases is large, it may not be so clear that none have
been left out. For example, verifying the associative law for a
binary operation described in tabular form on a set of $n$
elements is impractical when $n$ exceeds 4. Another such
instance is that of the associative and distributive laws in the
extended real number system.

The extended real number system $\tilde{{\bf {\mathbb R}}}$ is
usually defined as the union of ${\bf {\mathbb R}}$ with two
elements, written $\infty$ and $-\infty $, and endowed with the
structure described in (a)---(h) below, in addition to that
already available on its subset ${\bf {\mathbb R}}$:\\

(a) $-\infty <x<\infty$ for every $x\in\bf {\mathbb R}$;

(b) $x+\infty=\infty +x=\infty$ and $x+(-\infty)=(-\infty)+x=-\infty$ for every $x\in {\bf {\mathbb R}}$;

(c) $\infty+\infty=\infty$ and $(-\infty)+(-\infty)=-\infty$;

(d) $\infty\cdot\infty=(-\infty)\cdot(-\infty)=\infty$ and
 $(-\infty)\cdot\infty=\infty\cdot(-\infty)=-\infty$;

(e) $-(-\infty)=\infty$ and $-(\infty)=-\infty$;

(f) $x\cdot\infty=\infty\cdot x=\infty$ and $x\cdot(-\infty)=(-\infty)\cdot x=-\infty$

\indent \indent \indent for every positive $x\in\bf
{\mathbb R}$;

(g) $x\cdot(\infty)=(\infty)\cdot x=-\infty$ and $x\cdot(-\infty)=(-\infty)\cdot x=\infty$

\indent \indent \indent for every negative \textit{x} $\in$ ${\bf
{\mathbb R}}$;

(h) $(\pm\infty)\cdot 0=0\cdot(\pm\infty)=0$.\\

\noindent In contexts other than measure and integration, one may
wish to omit (h) and take the products occurring in it as
``undefined''. For instance, it is omitted in \cite[p.12] {rudin1}
with the consequence on p.314 that the Lebesgue integral of the
identically zero function on ${\bf {\mathbb R}}$ is left undefined
by (53), considering that (49) requires the function to be written
as zero times the characteristic function of ${\bf {\mathbb R}}$.
However, the same author includes (h) in \cite[p.19] {rudin2}.

Without (e), there would seem to be no basis for the common
practice of regarding $x-(-\infty)$ as meaning $x+\infty$ and
$x-(\infty)$ as meaning $x+(-\infty)$. We have therefore chosen to
state it explicitly although most authors prefer not to.

It is immediate from the properties (a)---(h) that addition and multiplication
in $\tilde{{\bf {\mathbb R}}}$ are commutative. However, the
associative law of addition and the distributive law, which
continue to be valid under the restriction that $\infty$ and
$-\infty $ do not both appear in any of the sums involved, are
supposed to be verified case by case. The associativity of
multiplication can be verified, again case by case, to be valid
without restriction.

The multiplication described by (a)---(h) is, in effect, a
binary operation on a set of five elements, namely,
positive real, negative real, 0, $\infty$  and $-\infty$ . In
checking associativity therefore, one would have to consider 125
triplets $(x,y,z)$; however, 27 of these involve only real numbers
and need not be checked. The remaining 98 can be reduced to 68 by
taking advantage of the obvious commutativity, but this is still an
uncomfortably large number of cases to handle.

Consequently, in any effort at a case-by-case verification of the
associative and distributive laws in the
extended real number system, it would be a legitimate concern
whether all cases have actually been taken into account or not.

We have avoided adding the requirement that $\frac{x}{\infty}$ = 0 for $x
\in\bf {\mathbb R}$ so as to keep clear of the consequence
that

\begin{center} 0 = 0$\cdot\infty$ =
$\frac{1}{\infty}\cdot\infty$ but $\frac{1\cdot\infty}{\infty}$ is
undefined.\end{center}

\noindent However, this observation raises a second concern, namely, whether (a)---(h) already contain a contradiction, even without this requirement.\\

With a view to addressing both concerns, we outline a method of
``constructing" $\tilde{{\bf {\mathbb R}}}$ from ${\bf {\mathbb
R}}$, in which we describe $\infty$ and $-\infty $ set
theoretically in terms of ${\bf {\mathbb R}}$ rather than pull them out
of the sky, and moreover, the associative and distributive laws
become transparent with just two cases each. The definitions of addition and multiplication in $\tilde{{\bf
{\mathbb R}}}$ undoubtedly call for separate cases to be
considered, but it is transparent that none are left out.\\

We begin by describing what the objects $\infty$ and
$-\infty $ are.

Let $\infty$ denote the class of real sequences ``diverging to $\infty$" in the usual sense (no circularity involved in this) and $-\infty $ denote the obvious analogous class. Furthermore, for each \textit{x} $\in$ ${\bf {\mathbb R}}$, let $\left[\kern-0.15em\left[x\right]\kern-0.15em\right]$ denote the class consisting of a single sequence, namely, the constant sequence with each term equal to \textit{x}. Set $\left[\kern-0.15em\left[{\bf {\mathbb R}}\right]\kern-0.15em\right]$ = \{$\left[\kern-0.15em\left[x\right]\kern-0.15em\right]$ : \textit{x} $\in$ ${\bf {\mathbb R}}$\} and $\tilde{{\bf {\mathbb R}}}$ = $\left[\kern-0.15em\left[{\bf {\mathbb R}}\right]\kern-0.15em\right]$$\cup $\{$-\infty $,$\infty$\}. Then each element of $\tilde{{\bf {\mathbb R}}}$ is a class of sequences and the classes are disjoint.

For $\alpha$,$\beta\in\tilde{{\bf {\mathbb R}}}$, define $\alpha<\beta$ to mean: for any sequences \{$a_{n}$\} $\in\alpha$ and \{$b_{n}$\} $\in\beta$, the inequality $a_{n}<b_{n}$ holds for all sufficiently large \textit{n}. Then it is easy verify that

\begin{equation} \label{ZEqnNum961558} \left[\kern-0.15em\left[x\right]\kern-0.15em\right]<\left[\kern-0.15em\left[y\right]\kern-0.15em\right]\Leftrightarrow x<y{\rm \; \; if\; }x,y\in {\bf {\mathbb R}} \end{equation}

\noindent Also, $-\infty<\alpha<\infty$ for all $\alpha\in\left[\kern-0.15em\left[{\bf {\mathbb R}}\right]\kern-0.15em\right]$, and $-\infty $ $<$ $\infty$. Thus (a) holds with \textit{x} replaced by $\left[\kern-0.15em\left[x\right]\kern-0.15em\right]$.

Suppose $\alpha$,$\beta\in\tilde{{\bf {\mathbb R}}}$, and $\alpha\neq-\infty\neq\beta$. It is easy to see that the following four cases are exhaustive:
\[{\rm (i)}\alpha ,\beta \in \left[\kern-0.15em\left[{\bf {\mathbb R}}\right]\kern-0.15em\right]{\rm \; \;  (ii)}\alpha \in \left[\kern-0.15em\left[{\bf {\mathbb R}}\right]\kern-0.15em\right]{\rm \; }{\rm a}{\rm n}{\rm d}{\rm \; }\beta =\infty {\rm \; \;  (iii)}\alpha =\infty {\rm \; }{\rm a}{\rm n}{\rm d}{\rm \; }\beta \in \left[\kern-0.15em\left[{\mathbb R}\right]\kern-0.15em\right]{\rm \; \;(}{\rm i}{\rm v}{\rm )}\alpha ,\beta =\infty .\]

\noindent It is equally straightforward to see in each of the four
cases that, for any sequences \{$a_{n}$\} $\in\alpha$ and
\{$b_{n}$\} $\in\beta$, the related sequence \{$a_{n}+b_{n}
$\} belongs to a unique $\gamma\in\tilde{{\bf {\mathbb
R}}}$. Therefore we may define $\alpha+\beta$ to be this unique
$\gamma\in\tilde{{\bf {\mathbb R}}}$.

In the course of arguing for the unique $\gamma$, it is also seen that

\[\left[\kern-0.15em\left[x\right]\kern-0.15em\right]+\infty =\infty +\left[\kern-0.15em\left[x\right]\kern-0.15em\right]=\infty {\rm \; \; if\; \; }x\in {\bf {\mathbb R}}{\rm ,}\]
\[\infty +\infty =\infty \]

\begin{flushleft}
\noindent and
\begin{equation} \label{ZEqnNum487027} \left[\kern-0.15em\left[x\right]\kern-0.15em\right]+\left[\kern-0.15em\left[y\right]\kern-0.15em\right]=\left[\kern-0.15em\left[x+y\right]\kern-0.15em\right]{\rm \; if\; }x,y\in {\bf {\mathbb R}} \end{equation}
\end{flushleft}

One can proceed analogously when $\alpha$,$\beta\in\tilde{{\bf {\mathbb R}}}$, and $\alpha\neq\infty\neq\beta$. All this establishes that $\alpha+\beta$ is uniquely
defined except when one of them is $\infty$ and the other is
$-\infty$ and that addition satisfies (c) as well as the
properties claimed for it in (b), but with $x$ replaced by
$\left[\kern-0.15em\left[x\right]\kern-0.15em\right]$.\\

Now consider $\alpha$,$\beta\in\tilde{{\bf {\mathbb R}}}$. When $\alpha$,$\beta\in\left[\kern-0.15em\left[{\bf {\mathbb R}}\right]\kern-0.15em\right]$, any sequences \{$a_{n} $\} $\in$ $\alpha$ and \{$b_{n} $\} $\in$ $\beta$ must be constant sequences and it is immediate that the related (constant) sequence \{$a_{n} b_{n} $\} belongs to a unique $\delta$ $\in$ $\left[\kern-0.15em\left[{\bf {\mathbb R}}\right]\kern-0.15em\right]$ $\subseteq$ $\tilde{{\bf {\mathbb R}}}$. When $\alpha$ = $\infty$, the following five cases for $\beta$ are exhaustive:

\[\left[\kern-0.15em\left[0\right]\kern-0.15em\right]<\beta \in \left[\kern-0.15em\left[{\bf {\mathbb R}}\right]\kern-0.15em\right],{\rm \; \; \; \; }\left[\kern-0.15em\left[0\right]\kern-0.15em\right]>\beta \in \left[\kern-0.15em\left[{\bf {\mathbb R}}\right]\kern-0.15em\right],{\rm \; \; \; \; }\left[\kern-0.15em\left[0\right]\kern-0.15em\right]=\beta ,{\rm \; \; \; \; }\beta =\infty ,{\rm \; \; \; \; }\beta =-\infty .\]

\noindent In each of the five cases, it is easy to arrive at the
conclusion that: for any sequences \{$a_{n} $\} $\in\alpha$ and
\{$b_{n} $\} $\in\beta$, the related sequence \{$a_{n} b_{n}
$\} belongs to a unique $\delta\in\tilde{{\bf {\mathbb
R}}}$. We note that it is essential here for $\beta$ =
$\left[\kern-0.15em\left[0\right]\kern-0.15em\right]$ to consist
of only the constant sequence \{0,0,\dots\}. Similarly when
$\alpha$ = $-\infty$. In view of the commutativity of
multiplication in ${\bf {\mathbb R}}$, the same conclusion can be
drawn for the ten cases when $\beta$ = $\pm\infty $. (It is
inessential to the argument that the actual number of distinct
cases is not 20 but 16, because the four cases when $\alpha$ =
$\pm\infty $ and $\beta$ = $\pm\infty $ will occur twice among
the 20.) Thus all cases have been covered and the aforementioned
conclusion holds for all $\alpha$,$\beta\in\tilde{{\bf
{\mathbb R}}}$. Therefore we may define $\alpha\beta$ to be this
unique $\delta\in\tilde{{\bf {\mathbb R}}}$.

In the course of arguing for the unique $\delta$, it is also seen that multiplication satisfies

\begin{equation} \label{ZEqnNum938796} \left[\kern-0.15em\left[x\right]\kern-0.15em\right]\left[\kern-0.15em\left[y\right]\kern-0.15em\right]=\left[\kern-0.15em\left[xy\right]\kern-0.15em\right]{\rm \; if\; }x,y\in {\bf {\mathbb R}} \end{equation}

\noindent as well as (d),(h), and that it further satisfies
(f),(g), with $x$ replaced by
$\left[\kern-0.15em\left[x\right]\kern-0.15em\right]$.\\

For any $\alpha\in\tilde{{\bf {\mathbb R}}}$, there is a
unique element $-\alpha\in\tilde{{\bf {\mathbb R}}}$ such
that

\[-\left[\kern-0.15em\left[\alpha\right]\kern-0.15em\right]=\left[\kern-0.15em\left[-\alpha\right]\kern-0.15em\right]{\rm \; if\; \; }\alpha\in {\bf {\mathbb R}}\]

\noindent and $-(-\infty)=\infty$, $-(\infty)=-\infty$. Indeed, $-\alpha$ is the unique element of $\tilde{{\bf {\mathbb R}}}$ such that whenever \{$a_{n}$\} $\in\alpha$, the sequence \{$-a_{n}$\} belongs to the class $-\alpha$. This proves (e).

In view of \eqref{ZEqnNum961558}, \eqref{ZEqnNum487027} and \eqref{ZEqnNum938796}, the bijection $x\rightarrow\left[\kern-0.15em\left[x\right]\kern-0.15em\right]$ is an isomorphism of ordered fields. Thus the subset $\left[\kern-0.15em\left[{\bf {\mathbb R}}\right]\kern-0.15em\right]$ of $\tilde{{\bf {\mathbb R}}}$ is an isomorphic image of ${\bf {\mathbb R}}$.
\\

Having completed the construction of a system satisfying (a)---(h)
and containing an isomorphic image of ${\bf {\mathbb R}}$, we now
turn our attention to the associative and distributive laws.

Suppose that either none among $\alpha$,$\beta$,$\gamma$ is
$\infty$ or that none is $-\infty$. Let \{$a_{n}$\} $\in\alpha$, \{$b_{n}$\} $\in\beta$ and \{$c_{n}$\} $\in\gamma$. Then $(\alpha+\beta)+\gamma$ is the unique class in
$\tilde{{\bf {\mathbb R}}}$ containing the sequence \{$(a_{n}+b_{n})+c_{n}$\}, while $\alpha+(\beta+\gamma)$ is the
unique class in $\tilde{{\bf {\mathbb R}}}$ containing the
sequence \{$a_{n}+(b_{n}+c_{n})$\}. By the associativity of
addition in ${\bf {\mathbb R}}$, it follows that the classes are
the same. Thus the equality

\[(\alpha+\beta)+\gamma =\alpha+(\beta+\gamma)\]

\noindent holds provided that

\[{\rm either\; none\; among\; }\alpha {\rm ,\; }\beta {\rm ,\; }\gamma {\rm \; is\; }\infty \]
\[{\rm or\; none\; among\; }\alpha {\rm ,\; }\beta {\rm ,\; }\gamma {\rm \; is\; }-\infty .\]

\noindent Similarly, the equality

\[\alpha(\beta+\gamma)=\alpha\beta+\alpha\gamma\]

\noindent holds provided that

\[{\rm either\; none\; among\; \; }\beta {\rm ,\; }\gamma ,{\rm \; }\alpha \beta {\rm ,\; }\alpha \gamma {\rm \; is\; }\infty \]
\[{\rm or\; none\; among\; \; }\beta {\rm ,\; }\gamma ,{\rm \; }\alpha \beta {\rm ,\; }\alpha \gamma {\rm \; is\; }-\infty .\]

\noindent In fact, both sides of the equality are the unique class
containing the sequence \{$a_{n}(b_{n}+c_{n})$\}, where
\{$a_{n}$\} $\in\alpha$, \{$b_{n}$\} $\in\beta$ and
\{$c_{n}$\} $\in\gamma$. It is left to the reader to formulate
the corresponding statement regarding $(\alpha\beta)\gamma$ =
$\alpha(\beta\gamma)$, which is valid without any restrictions
on $\alpha$,$\beta$,$\gamma$.

\paragraph{}\

We conclude with two remarks.\\

\indent 1. If
$\left[\kern-0.15em\left[x\right]\kern-0.15em\right]$ were
enlarged to include all real sequences converging to $x$,
then the properties (a)---(g) would follow in the same manner as
above, but $\pm\infty\cdot 0$ and $0\cdot (\pm\infty)$
would remain undefined.\\
\indent 2. If in the construction of $\mathbb{R}$ by Dedekind cuts
as in \cite [pp.17-21]{rudin1} or \cite [pp.47-52]{SV}, one
includes the empty set and $\mathbb{Q}$ as cuts, then one gets
$\tilde{{\bf {\mathbb R}}}$, with the empty set serving as
$-\infty$ and $\mathbb{Q}$ as $\infty$. The additional effort
involved in checking this is minimal. However, the sum
$-\infty+\infty$ needs to be specifically excluded in the general
definition of sum, because otherwise it works out to be $-\infty$.

\begin{thebibliography}{2}

\bibitem{rudin1} Rudin, W., Principles of Mathematical Analysis, 3rd ed., McGraw-Hill, New York,
1976

\bibitem{rudin2} Rudin, W., Real and Complex Analysis, McGraw-Hill, New York, 1966

\bibitem{SV} Shirali, S. and Vasudeva, H.L., Mathematical
Analysis, Alpha Science Publishers, Oxford, 2006.

\end{thebibliography}

\end{document}