\pdfoutput=1 % only if pdf/png/jpg images are used
\documentclass{JINST}

\title{New Approaches to Uniform Boosting}

\author{
Aleksandar Bukva,
Vladimir Gligorov$^d$,
Alex Rogozhnikov$^{a,b}$\thanks{Corresponding author.}~ ,
Andrey Ustuzhanin$^b$ and
Mike Williams$^c$\\
\llap{$^a$}Lomonosov Moscow State University, Moscow, Russia\\
\llap{$^b$}Yandex LLC, Moscow, Russia\\
\llap{$^c$}Massachusetts Institute of Technology, Cambridge, MA, United States \\
\llap{$^d$}Organisation Europ\'eenne pour la Recherche Nucl\'eaire (CERN), Geneva, Switzerland  \\
E-mail: \email{alex.rogozhnikov@yandex.ru}}

\abstract{
% Abstract must be short enough to appear in this page together with title, authors, their addresses and keywords.
The use of multivariate classifiers has become commonplace in particle physics.
Typically, a series of classifiers is trained rather than just one to enhance the performance; this is known as boosting.

In some applications of high energy physics (i.e., amplitude analyses)
classifiers should not only optimize some integrated figure of merit, but produce a uniform selection efficiency in a space of selected physical variables.
Recently uBoost technique of boosting was proposed which addresses this issue.

In this paper we introduce several approaches to measure the uniformity of efficiency and propose new boosting techniques.
}

% AMS packages:
\usepackage{amsmath, amsthm, amsfonts}

% Theorems
%-----------------------------------------------------------------

\newtheorem{thm}{Theorem}[section]
\newtheorem{cor}[thm]{Corollary}
\newtheorem{lem}[thm]{Lemma}
\newtheorem{prop}[thm]{Proposition}
\theoremstyle{definition}
\newtheorem{defn}[thm]{Definition}
\theoremstyle{remark}
\newtheorem{rem}[thm]{Remark}

\def\RR{\mathbb{R}}
\def\ZZ{\mathbb{Z}}
\newcommand{\abs}[1]{\left\vert#1\right\vert}
\newcommand{\sgn}{\operatorname{sgn}}

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

\begin{document}
\maketitle

\section{Introduction}

Methods of machine learning are playing a important role in particles physics nowadays, in particular, multivariate analysis (MVA).
Different classifiers like boosted decision trees (BDTs) and artificial neural networks (ANNs) are often used as an important step in analysis selection criteria.

BDTs are now even used in software triggers [link]. The main point of boosting technique is training many simple classifiers and building a composition of their outputs.
Classifiers are trained one-after-another, their inputs are augmented in such a way that new classifier should target more at those events which were poorly classified by previous ones. The resulting classifier obtained by combining them often much more powerful, than individual ones.

In practice, however, there are some restrictions that trained classifier should meet (apart from having good classification quality, which is usually measured by some integrated FOM). For example, in an amplitude analysis obtaining a uniform efficiency in a multivariate space of physics variates, i.e., variates that are of physical interest, is often times more important than any integrated FOM based on the total amount of signal and background. Such analyses often have many variates in which a uniform efficiency is desired. A uniform efficiency reduces systematic uncertainties and helps maintain sensitivity to all hypotheses being tested.

The one approach that was already proposed is uBoost (uniform BOOSTing) --- a modification of AdaBoost algorithm [link]

Why do we need such algorithms:

\begin{enumerate}
	\item The result of classification is stable to check different hypotheses
	\item To get unbiased distribution of signal, this enables us to compute real mass of particle
	\item Not to get fake peak, thus not get a false discovery
\end{enumerate}

The features, along which we want the prediction to be flat, will be referred to as
\textit{uniform variables}. In high energy physics these are usually masses.

\section{Uniformity Measurement}

In this section we come up with some approaches on how to measure uniformity of prediction. The typical way of 'checking' uniformity of prediction used by physicists
is fitting the distribution of the events that were classified as signal (or background) over the mass (or some other variable).

This approach is hardly formalizable, and not automatable --- each time you should assume some kind of distribution.
Ideally we want to have some easy-to-use out-of-the-box metrics like FOMs in machine learning (like area under the ROC, f1 or ).

\subsection{Ideal uniformity}

We start from the simplest case --- when we are fully satisfied by predictions of our classifier. Remember that output of
classification is probabilities of each event being a signal and background event, only after we select some cut on probability we get classification.

Ideal uniformity of signal prediction means that whichever cut we select, the efficiency (part of signal event that passed the cut) doesn't depend on uniform variables:
in every region of uniform variables space the part of signal events that passed the cut is the same.

In practice, of course, this never happens.

There is uniformity of predictions on signal and uniformity of efficiency on background, which can be defined one from another by swapping classes.
In what follows in this section we are writing about the efficiency on signal events.

A good example of classifier that has close to ideal uniformity is classifier which returns a random probability in [0, 1] range. What a pity: in practice it's absolutely useless.

% The most significant drawback of the upcoming metrics is they are ill-defined if there are not too many events of the named class.

\subsection{Some Restrictions on Uniformity Metrics}

There are some additional conditions which we expect metric to meet:
\begin{enumerate}
\item
shouldn't depend much on the number of events (i.e., if we randomly select half of the events, the metrics should roughly be the same)
\item
shouldn't depend on the weights renormalization: if we multiply all the weight by some arbitrary number, it shouldn't change at all.
\item
depends only on the order of predictions, not the exact values of probabilities.
This is because we care about which events pass the cut and which don't, not about the exact values of predictions.

Example: correlation of prediction and mass doesn't satisfy this restriction.
\item
parameter stability: if it uses bins, changing the number of bins shouldn't affect the metrics value much, if it uses $k$-nearest neighbors, it should be stable to small deviations of $k$.
\end{enumerate}

\subsection{Standard Deviation of Efficiency on Bins (SDE)}

\def\bineff{\text{eff}_\text{bin}}
\def\binweight{\text{weight}_\text{bin}}
\def\globaleff{\text{eff}}
\def\SDE{\text{SDE}}
\def\bin{\text{bin}}

Let's split the space of uniform features into bins, the uniformity in these terms is following: when we select some probability cut,
the part of signal events that passes the cut is equal in all bins. Assume we selected some cut, then we have global efficiency
\[
	\globaleff = \dfrac{
		\text{total weight of signal events that passed the cut}}
		{\text{total weight of signal events}}
\]

Efficiency in every bin is defined respectively,
\[
	\bineff = \dfrac{
		\text{weight of signal events in bin that passed the cut}}
		{\text{weight of signal events in this bin}}
\]

So, basically, what we want to have in our dreams:
\[
	\bineff = \text{global efficiency} \qquad \forall \; \text{bin}
\]

To measure how far we are from ideal situation we use standard deviation:
\[
	\sqrt{\sum_{\bin} \left( \bineff - \globaleff \right)^2  }
\]

What is bad in this formula that every bin has some impact in the result, which does not depend on how many events are there, so metrics becomes very unstable to deviations in bins with only few events. To cure this, we add weights to the bins (note that $\sum_\bin \binweight = 1$):
\[
	\binweight = \dfrac{\text{total weight of signal events in bin}}
		{\text{total weight of signal events}},
\]
so we have SDE formula:
\[
	\SDE(\globaleff) =
	\sqrt{\sum_{\bin} \binweight \times \left(\bineff - \globaleff \right)^2}.
\]
In fact, the expression depends on the cut, but for cuts which produce equal efficiency, this is

Finally we note that the weighted average of $\bineff$ is $\globaleff$:
\[
	\globaleff = < \bineff > =  \sum_{\bin} \binweight \times \bineff,
\]
and this is why the introduced metrics was named SDE --- this is a weighted standard deviations of array of bin efficiencies.

But this is how we measure the non-uniformity for only one fixed cut, to measure the overall non-flatness, we take several global efficiencies (for instance, [0.5, 0.6, 0.7, 0.8, 0.9], because in practice usually we are interested in cuts with high global efficiency) and use
\[
	\SDE^2  =  \frac{1}{k}
	\sum_{\globaleff \in [\globaleff_1 \dots \globaleff_k] }
		\text{SDE}^2(\globaleff)
\]

Some other power $p \neq 2$ can be used as well, but $p=2$ is considered as the default value:
\[
	\SDE^p(\globaleff) =
	\sum_{\bin} \binweight \times \abs{\bineff - \globaleff}^p,
\qquad
	\SDE^p  =  \frac{1}{k}
	\sum_{\globaleff \in [\globaleff_1 \dots \globaleff_k] }
		\text{SDE}^p(\globaleff).
\]

\subsection{Theil Index of Efficiency}
\def\theil{\text{Theil}}

One more measure uses Theil Index frequently used to measure economic inequality:
\[
	\theil = \frac{1}{N} \sum_i \frac{x_i}{<x>} \ln{\frac{x_i}{<x>}},
		\qquad <x> = \frac{1}{N} \sum_i x_i
\]
In our case we have to alter formula a bit to take into account that different bins have different impact, thus the formula turns into
\[
	\theil(\globaleff) = \sum_\bin \binweight \; \frac{\bineff}{\globaleff} \; \ln{\frac{\bineff}{\globaleff}}
\]

TODO how to combine Theil for different global efficiencies?
\[
	\theil = ??? \text{from} \theil(\globaleff)
\]

\subsection{Distribution Similarity Approach}
\label{sec:similarity}

Let's start from reformulation of what is uniform predictions in signal. First we split all signal events into some bins in uniform variables. There is some empirical distribution $F_\bin$ of predictions in each bin. Ideal uniformity means that all the distributions $F_\bin$ are equal and hence equal to the global distribution $F(x)$.

To 'measure' non-flatness we can use some distribution distance, like Kolmogorov-Smirnov:
\[
	 \sum_{\bin} \binweight \max_x \abs{F_{\bin}(x) - F(x)},
\]
but Cram\'er--von Mises similarity is more informative (usually $p=2$ is used):
\[
	 \sum_{\bin} \binweight \int \abs{F_{\bin}(x) - F(x)}^p dF(x),
\]

The good point is we don't need to select some global efficiencies like in the other metrics.

\subsection{Connection Between SDE and Distance Similarity Approach}

SDE and DSA based on Cram\'er--von Mises similarity can be shown to have connection.
Let's consider the SDE with global efficiencies $= [1/N, 2/N, \dots, N/N]$. In the limit $N \to \infty$
\[
	\lim_{N \to \infty} \SDE^2 =
	\lim_{N \to \infty} \frac{1}{N} \sum_{\globaleff}\SDE^2(\globaleff) =
	\int_0^1 \SDE^2(\globaleff) d\, \globaleff =
	\int_0^1 \sum_{\bin} \binweight \abs{\bineff - \globaleff}^2 d\, \globaleff
\]

From the other side, we can write the expression for similarity-based measure (for $p=2$)
\[
	\sum_{\bin} \binweight \int \abs{F_\text{bin}(x) - F(x)}^2 dF(x) =
	\int \sum_{\bin} \binweight \abs{F_\text{bin}(x) - F(x)}^2 dF(x)
\] The hard thing now is to believe this is literally the same and these two expressions are equal.

\subsection{Knn-based modifications}

\def\knni{\text{knn}(i)}
\def\effknni{\text{eff}_{\knni}}
\def\weightknni{\text{weight}_{\knni}}
\def\Fknn{F_{\knni}}

\def\knnSDE{\text{knnSDE}}

Though operating with bins is usually both simple and very efficient,
in many cases it is hard to find optimal size of bins in the space of uniform variables (specifically in the case of more than two dimensions).
One more situation when bins-based approach fails, is when we have too few events to obtain a good statistics at least in several bins.

In these cases we can switch to $k$-nearest neighbors: for each signal event we find $k$ nearest signal events (including the event itself) in the space of uniform variables. Now we can compute the efficiency $\effknni$, empirical distribution $\Fknn$ of nearest neighbors.
The weights for $\knni$ are proportional to the total weight of events in $\knni$:
\[
	\weightknni = \alpha \sum_{j \in \knni} w_j, \qquad \alpha^{-1} = \sum_i \sum_{j \in \knni} w_j,
\]
so again weights are normed to 1: $\sum_{i} \knni = 1$.

Now we are ready to write knn version of SDE:
\[
	\knnSDE^2(\globaleff)
		= \sum_{i \in \text{events}} \weightknni \abs{\effknni - \globaleff}^2
\]
\[
	\knnSDE^2 = \sum_{\globaleff \in [\globaleff_1, \dots \globaleff_k]}
		\knnSDE^2(\globaleff),
\]
knn version of Theil index of Efficiency
\[
	\text{knnTheil}(\globaleff) = \sum_{i \in \text{events}} \weightknni \; \frac{\effknni}{\globaleff} \; \ln{\frac{\effknni}{\globaleff}}
\]
\[
	\text{knnTheil} = ??? \text{knnTheil}(\globaleff)
\]
and knn version of similarity-based measure:

\[
	 \sum_{i \in \text{events}} \weightknni \int \abs{\Fknn(x) - F(x)}^p dF(x),
\]

$K$-nearest neighbors approach suffers from the other drawback: the impact of different events has very little connection with the weights, because some events are met in knn of other events much more frequently while the other.
This effect can be suppressed by dividing initial weight of the event by the number of times it is met in knn.

\subsection{Advantages and Disadvantages of Different Metrics}

... TODO, here some plots with comparison, maybe timings ...

\section{Approaches Proposed}

\subsection{Mean Ada Boost}

This is a modification of AdaBoost algorithm. In AdaBoost one multiplies weights in such a way:
\[
	w_i = w_i \times \exp[-y_i \, \text{score}_i],
\]
to enlarge the weights of poorly classified events ($y_i$ is $+1$ for signal and $-1$ for background).

But now we use the mean of prediction of $k$ nearest neighbors (of the same class)
\[
	w_i = w_i \times \exp[-y_i \, \dfrac{1}{k} \sum_{j \in \knni} \text{score}_j]
\]
Thus boosting focuses not on the events that were poorly classified, but on the regions with poor classification.

\subsection{Gradient Boosting with AdaLoss Modification (knn-Ada)}

\def\score{\text{score}}
\def\knn{\text{knn}}
\def\FL{\text{FL}}

Gradient boosting on trees is widely used algorithm[link], it's built upon decision tree regressors with usage of some loss function.

Let's start with examples. One of the popular losses used is AdaLoss:
\[
	\sum_{i \in \text{events}} w_i \times \exp [- \score_i \, y_i]
\]
where $y_i$ is either +1 (for signal events) or -1 (for background events). Good classification supposes that signal events should have large positive scores, while background ones should have large negative.

The predictions of separate regressors are simply summed up to form a score:
\[
	\score_i = \sum_{r \in \text{regressors}} \text{pred}_r(i),
\]
which can be 'translated' into probabilities by logistic function.

So the goal of algorithm is now to minimize the loss function. At each stage it trains one more regressor, which should decrease the value of loss, the most vivid way is to train it on negative gradient of loss. In the case of AdaLoss this can be done pretty easy:
\[
	-\dfrac{\partial \, \text{AdaLoss}}{\partial \, \score_i} = w_i \, y_i \exp[- \score_i \, y_i],
\]
so it is positive for signal events, negative for background events and has larger modulus for the events which are poorly classified.

After a new tree was built, it's output is altered: for each leaf we can compute such a value, that the result will give the smallest possible value for loss.

...computation of optimal value goes here...

This loss function can be easily modified to take in account not only the score for individual elements, but also 'finds' regions with lower-than-average quality.

\[
	\text{knnAdaLoss} = \sum_{i \in events} \exp[-y_i \times \sum_{j \in \text{knn}(i)} \score_j],
\]
where the index $j$ goes over the $k$ nearest neighbors of $i$th event, which belongs to the same class (signal or background).

We can introduce a supplementary sparse matrix $A \in \RR^{N \times N}$ ($N$ is number of events), which is defined as
\[
a_{ij} = \begin{cases}
1, & j \in \knn(i), \text{ events $i$ and $j$ belong to the same class} \\
0, & \text{otherwise},
\end{cases}
\] so the loss can be written as
\[
	\text{knnAdaLoss} = \sum_i \exp [- y_i \sum_j a_{ij} \, \score_j ],
\]
it's negative gradient is easily computed:
\[
	-\dfrac{\partial \, \text{knnAdaLoss}} {\partial \, \score_k} =
	 y_k \, \sum_i a_{ik} \exp [- y_i \sum_j a_{ij} \, \score_j ],
\]
from this we can see that new algorithm will pay more attention to the events, which has poorly classified neighbors (and neighbors of neighbors). The named loss targets to obtain uniformity in both signal and background.

And the post-correction can be handled by using second-order Newton-Raphson optimization step

... TODO computation of optimal value goes here ...

One can note, that the matrix $A$ doesn't need to be necessarily square. One can introduce $M$ groups of events (which may intersect), each group consists of several events with close uniform variables (and close events). Then one introduces $A \in \RR^{M \times N}$:
\[
	a_{mj} = \begin{cases}
		1, & \text{event $j$ is in group $m$} \\
		0, & \text{otherwise}
	\end{cases}
\]

In particular, if we take $A$ to be identity matrix: $A = I$ (each event to be in it's own group), knnAdaLoss turns into a simple AdaLoss.

\subsection{Gradient Boosting with Flatness Loss (FL)}

Let's use the metrics introduces in the section \ref{sec:similarity}:
\[
	\sum_{\bin} \binweight \int \abs{F_{\bin}(x) - F(x)}^p dF(x),
\]
which is good as a measure, but due to the non-smoothness of $F(x)$ it's
gradient is singular, so we use instead
\[
	\FL = \sum_{\bin} \binweight \int \abs{F_{\bin}(x) - F(x)}^p dx.
\]

So, the derivative looks like:
\[
	\dfrac{\partial} {\partial \, \score_i} \FL
	= \sum_{\bin} \binweight \frac{\partial }{ \partial \, \score_i}
			\int \abs{F_\bin(x) - F(x)}^p dx
\]
Let $\bin(i)$ be a bin to which event $i$ belongs, then we can compute:
\def\binIweight{\text{weight}_\text{\bin(i)}}

% TODO sign

\begin{multline*}
	- \dfrac{\partial} {\partial \, \score_i} \FL =
		- \binIweight
		\frac{\partial }{ \partial \, \score_i}
			\int \abs{F_{\bin(i)}(x) - F(x)}^p dx \cong \\
	\cong \binIweight \, p \,  \abs{F_{\bin(i)}(x) - F(x)}^{p-1}
		\sgn[F_{\bin(i)}(x) - F(x)]
		\dfrac{w_i}{\binIweight}
		\Bigg|_{x=\score_i} = \\
	=
		w_i \, p \,  \abs{F_{\bin(i)}(x) - F(x)}^{p-1}
		\sgn[F_{\bin(i)}(x) - F(x)]
		\Bigg|_{x=\score_i}
\end{multline*}

TODO give explanations here

The next thing we need to point is FL doesn't take into account the quality of predictions. So what we use in practice is linear combination of FlatnessLoss and AdaLoss:
\[
	\text{loss} = \FL + \alpha \, \text{AdaLoss}
\]

First one penalizes the non-uniformity, second one --- poor predictions.

\section{Dataset}

Here should be some description of $D \to hhh$ sample.

\section{Plots}

\section{Timings}

The main drawback of uBoost technique is it's high computational complexity:
while simple AdaBoost trains $M$ trees, uBoost builds $100 \times M$ trees (contribution of other operations usually can be neglected).

Presented in this paper classifiers are building $M$ trees, though there is more complicated boosting, it takes at each iteration ($k$ is number of neighbors, $N$ is number of events in training sample)

\begin{itemize}
	\item meanAdaBoost: $O(k \times N)$
	\item knnAdaLoss: $O(k \times N)$, for the arbitrary matrix $A$ it is
	$O( \text{\#nonzero elements in the matrix})$
	\item FlatnessLoss: $O(N \ln N)$
\end{itemize}

\section{Summary}

\section{Source code}

The link on the repository ans links to final notebooks with results in the article.

\acknowledgments

\begin{thebibliography}{9}

\bibitem{bib1}
Authors,
\emph{Title},
\emph{J. Ref.} \textbf{vol} (year) page.

\bibitem{bib2}
A. Pietropaolo et al., \emph{DINS measurements on VESUVIO in the
    resonance detector configuration: proton mean kinetic energy in
    water}, \jinst{1}{2006}{P04001}.

\bibitem{bib3}
A.I. Harris,
\emph{Spectroscopy with multichannel correlation radiometers},
\href{http://dx.doi.org/10.1063/1.1898643}
{\emph{Rev.\ Sci.\ Instrum.} {\bf 76} (2005) 054503}
[\astroph{0504449}].

\bibitem{bib4}
G.F. Knoll, \emph{Radiation detection and measurements}, John Wiley
    and Sons, Inc., New York 2000.

\bibitem{bib5}
V. Dangendorf, \emph{Time-resolved fast-neutron imaging with a
pulse-counting image intensifier}, in proceedings of
\emph{International workshop on fast neutron detectors and
applications}, April, 3--6, 2006 University of Cape Town, South Africa
\pos{PoS(FNDA2006)008}.

\end{thebibliography}

\end{document}


\subsection{Combining type models}
\label{subsec:transformation_framework:type_models_and_type_graphs:combining_type_models}

The structure of \cref{fig:transformation_framework:type_models_and_type_graphs:structure_type_models_graphs} shows that the type models $Tm_A$ and $Tm_B$ are combined into one type model $Tm_{AB}$. This section provides the definition of this combination and its corresponding theorems. Please note that the definitions presented here are as generic as possible, and do not actively take into account that $Tm_{A}$ and $Tm_{B}$ are mostly distinct. This bit of information is added later as part of a theorem and proof.

\begin{defin}[Combination function on type models]
\label{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:combine}
$\mathrm{combine}$ is a binary function on two type models which combines two type models into one type model. It is defined as follows:
\begin{align*}
\mathrm{combine}(Tm_A, Tm_B) = \langle&
Class = Class_{Tm_A} \cup Class_{Tm_B} \\&
Enum = Enum_{Tm_A} \cup Enum_{Tm_B} \\&
UserDataType = UserDataType_{Tm_A} \cup UserDataType_{Tm_B} \\&
Field = Field_{Tm_A} \cup Field_{Tm_B} \\&
\mathrm{FieldSig} = \mathrm{fieldsig\_\!combine}(Tm_A, Tm_B) \\&
EnumValue = EnumValue_{Tm_A} \cup EnumValue_{Tm_B} \\&
Inh = Inh_{Tm_A} \cup Inh_{Tm_B} \\&
Prop = \mathrm{prop\_\!combine}(Tm_A, Tm_B) \\&
Constant = Constant_{Tm_A} \cup Constant_{Tm_B} \\&
\mathrm{ConstType} = \mathrm{consttype\_\!combine}(Tm_A, Tm_B)\rangle
\end{align*}

In which $\mathrm{fieldsig\_\!combine}$ is given as part of \cref{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:fieldsig_combine}, $\mathrm{prop\_\!combine}$ as part of \cref{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:prop_combine} and $\mathrm{consttype\_\!combine}$ as part of \cref{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:consttype_combine}.
\isabellelref{tmod_combine}{Ecore.Type_Model_Combination}
\end{defin}

The combination of two type models is rather simple in its definition, at least for all the sets defined as part of a type model. Intuitively, the definition makes sense. To combine two type models, we need the types from both type models, so we merge the classes, enumerations types, enumeration values and user-defined data types. The constants should also be preserved, so these are merged too. To preserve all attributes and relations, we merge the set of fields and the inheritance relation as well.

Merging the different functions is done by using a new function. First, the combination of field signatures will be discussed.

\begin{defin}[Combination function for field signatures]
\label{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:fieldsig_combine}
$\mathrm{fieldsig\_\!combine}$ is a partial function on two type models which returns a new function $Field_{Tm_{AB}} \Rightarrow (Type_{Tm_{AB}} \times \mathbb{M})$. It is defined as follows:
\begin{multline*}
    \mathrm{fieldsig\_\!combine}(Tm_{A}, Tm_{B}, f) = \\
        \begin{cases}
        s & \mathrm{if } f \in Field_{Tm_A} \cap Field_{Tm_B} \land \mathrm{type}_{Tm_A}(f) = \mathrm{type}_{Tm_B}(f) \\
        \mathrm{FieldSig}_{Tm_A}(f) & \mathrm{if } f \in Field_{Tm_A} \setminus Field_{Tm_B} \\
        \mathrm{FieldSig}_{Tm_B}(f) & \mathrm{if } f \in Field_{Tm_B} \setminus Field_{Tm_A}
    \end{cases}
\end{multline*}
where
\begin{equation*}
\begin{split}
    s = \bigg(\mathrm{type}_{Tm_A}(f), \Big(\max\left(\mathrm{lower}(\mathrm{FieldSig}_{Tm_A}(f)), \mathrm{lower}(\mathrm{FieldSig}_{Tm_B}(f))\right) ..\\ \min\left(\mathrm{upper}(\mathrm{FieldSig}_{Tm_A}(f)), \mathrm{upper}(\mathrm{FieldSig}_{Tm_B}(f))\right)\Big)\bigg)
\end{split}
\end{equation*}
\isabellelref{tmod_combine_fieldsig}{Ecore.Type_Model_Combination}
\end{defin}

Although the above definition looks quite complex, the intuition behind it is straightforward. For a field that only occurs in type model $Tm_A$, the field signature over from $Tm_A$ is copied. For a field that only occurs in $Tm_B$, the field signature from $Tm_B$ is copied. In the case that a field occurs in both $Tm_A$ and $Tm_B$, it should be the case that the type of the fields is the same. If this is indeed the case, the field type is copied, and a new multiplicity is created. This multiplicity takes the maximum of the lower bounds of the field in $Tm_A$ and $Tm_B$ as new lower bound, and the minimum of the upper bounds of the field in $Tm_A$ and $Tm_B$ as new upper bound.

\begin{figure}
    \centering
    \begin{subfigure}{0.45\textwidth}
        \centering
        \includegraphics{images/04_transformation_framework/type_models_combination/fieldsig_combine_tmod1.pdf}
        \caption{First type model $Tm_A$}
        \label{fig:transformation_framework:type_models_and_type_graphs:combining_type_models:fieldsig_combine_tmod1}
    \end{subfigure}
    \begin{subfigure}{0.45\textwidth}
        \centering
        \includegraphics{images/04_transformation_framework/type_models_combination/fieldsig_combine_tmod2.pdf}
        \caption{Second type model $Tm_A$}
        \label{fig:transformation_framework:type_models_and_type_graphs:combining_type_models:fieldsig_combine_tmod2}
    \end{subfigure}
    \par\medskip
    \begin{subfigure}{\textwidth}
        \centering
        \includegraphics{images/04_transformation_framework/type_models_combination/fieldsig_combine_tmod12.pdf}
        \caption{Combined type model $Tm_{AB}$}
        \label{fig:transformation_framework:type_models_and_type_graphs:combining_type_models:fieldsig_combine_tmod12}
    \end{subfigure}
    \caption{Combination of field signatures when field is present in both type models}
    \label{fig:transformation_framework:type_models_and_type_graphs:combining_type_models:fieldsig_combine}
\end{figure}

An example of the combination of two field signatures in the case of a field being present in both $Tm_A$ and $Tm_B$ is given in \cref{fig:transformation_framework:type_models_and_type_graphs:combining_type_models:fieldsig_combine}. It is possible to combine the field $\type{x}$, since in both $Tm_A$ and $Tm_B$ field $\type{x}$ references class type $\type{B}$. The multiplicity for both field signatures is different and is combined as defined. The maximum of the lower bounds is taken, which results in $\max(3, 1) = 3$. Furthermore, the minimum of the upper bounds is taken, which results in $\min(6, 4) = 4$. Therefore the multiplicity of $\type{x}$ in $Tm_{AB}$ will become $3..4$.

Besides a function for field signatures, a type model also defines a function for constant types. The combination of constant types is discussed in the next definition.

\begin{defin}[Combination function for constant types]
\label{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:consttype_combine}
$\mathrm{consttype\_\!combine}$ is a partial function on two type models which returns a new function \\$Constant_{Tm_{AB}} \Rightarrow Type_{Tm_{AB}}$. It is defined as follows:
\begin{multline*}
    \mathrm{consttype\_\!combine}(Tm_{A}, Tm_{B}, c) = \\
        \begin{cases}
        \mathrm{ConstType}_{Tm_A}(c) & \mathrm{if}\ c \in Constant_{Tm_A} \cap Constant_{Tm_B} \land \mathrm{ConstType}_{Tm_A}(c) = \mathrm{ConstType}_{Tm_B}(c) \\
        \mathrm{ConstType}_{Tm_A}(c) & \mathrm{if}\ c \in Constant_{Tm_A} \setminus Constant_{Tm_B} \\
        \mathrm{ConstType}_{Tm_B}(c) & \mathrm{if}\ c \in Constant_{Tm_B} \setminus Constant_{Tm_A}
    \end{cases}
\end{multline*}
\isabellelref{tmod_combine_const_type}{Ecore.Type_Model_Combination}
\end{defin}

The definition of the combination of constant types is similar to the combination of field signatures. The combination of constant types is less complicated because there is no notion of multiplicities involved. By definition, if a constant only occurs in $Tm_{A}$, the constant type of $Tm_{A}$ is copied. For constants that only occur in $Tm_{B}$, the constant type of $Tm_{B}$ is copied. In case that a constant occurs in both $Tm_{A}$ and $Tm_{B}$, the constant is copied if the constant types for that constant are the same in both $Tm_{A}$ and $Tm_{B}$.

The last definition that remains to be given is the definition of combining the set of properties. The set of properties cannot be united by merely taking the union of $Prop_{Tm_A}$ and $Prop_{Tm_B}$ since this might invalidate the satisfaction of these properties on the level of an instance graph. Instead, the inductive set $\mathrm{prop\_\!combine}$ is defined to specify under which circumstances a property can be combined.

\begin{defin}[Combination of model properties]
\label{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:prop_combine}
$\mathrm{prop\_\!combine}(Tm_A, Tm_B)$ is defined as a subset of $Prop_{Tm_A} \cup Prop_{Tm_B}$. The contents of the set are then defined as follows:

For $\type{abstract}$ properties:
\begin{mathpar}
    \inferrule{[ \type{abstract}, c ] \in Prop_{Tm_A} \\ c \not\in Class_{Tm_B}}{[ \type{abstract}, c ] \in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
    \and
    \inferrule{[ \type{abstract}, c ] \in Prop_{Tm_B} \\ c \not\in Class_{Tm_A}}{[ \type{abstract}, c ] \in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
    \and
    \inferrule{[ \type{abstract}, c ] \in Prop_{Tm_A} \\ [ \type{abstract}, c ] \in Prop_{Tm_B}}{[ \type{abstract}, c ] \in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
\end{mathpar}

For $\type{containment}$ properties:
\begin{mathpar}
    \inferrule{[ \type{containment}, r ]\in Prop_{Tm_A}}{[ \type{containment}, r ]\in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
    \and
    \inferrule{[ \type{containment}, r ]\in Prop_{Tm_B}}{[ \type{containment}, r ]\in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
\end{mathpar}

For $\type{defaultValue}$ properties:
\begin{mathpar}
    \inferrule{[ \type{defaultValue}, f, v ]\in Prop_{Tm_A} \\ f \not\in Field_{Tm_B}}{[ \type{defaultValue}, f, v ]\in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
    \and
    \inferrule{[ \type{defaultValue}, f, v ]\in Prop_{Tm_B} \\ f \not\in Field_{Tm_A}}{[ \type{defaultValue}, f, v ]\in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
    \and
    \inferrule{[ \type{defaultValue}, f, v ]\in Prop_{Tm_A} \\ [ \type{defaultValue}, f, v ]\in Prop_{Tm_B}}{[ \type{defaultValue}, f, v ]\in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
\end{mathpar}

For $\type{identity}$ properties:
\begin{mathpar}
    \inferrule{[ \type{identity}, c, A ]\in Prop_{Tm_A} \\ c \not\in Class_{Tm_B}}{[ \type{identity}, c, A ]\in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
    \and
    \inferrule{[ \type{identity}, c, A ]\in Prop_{Tm_B} \\ c \not\in Class_{Tm_A}}{[ \type{identity}, c, A ]\in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
    \and
    \inferrule{[ \type{identity}, c, A ]\in Prop_{Tm_A} \\ [ \type{identity}, c, A ]\in Prop_{Tm_B}}{[ \type{identity}, c, A ]\in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
\end{mathpar}

For $\type{keyset}$ properties:
\begin{mathpar}
    \inferrule{[ \type{keyset}, r, A ]\in Prop_{Tm_A} \\ r \not\in Field_{Tm_B}}{[ \type{keyset}, r, A ]\in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
    \and
    \inferrule{[ \type{keyset}, r, A ]\in Prop_{Tm_B} \\ r \not\in Field_{Tm_A}}{[ \type{keyset}, r, A ]\in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
    \and
    \inferrule{[ \type{keyset}, r, A ]\in Prop_{Tm_A} \\ [ \type{keyset}, r, A ]\in Prop_{Tm_B}}{[ \type{keyset}, r, A ]\in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
\end{mathpar}

For $\type{opposite}$ properties:
\begin{mathpar}
    \inferrule{[ \type{opposite}, r1, r2 ]\in Prop_{Tm_A} \\ r1 \not\in Field_{Tm_B} \\ r2 \not\in Field_{Tm_B}}{[ \type{opposite}, r1, r2 ]\in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
    \and
    \inferrule{[ \type{opposite}, r1, r2 ]\in Prop_{Tm_B} \\ r1 \not\in Field_{Tm_A} \\ r2 \not\in Field_{Tm_A}}{[ \type{opposite}, r1, r2 ]\in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
    \and
    \inferrule{[ \type{opposite}, r1, r2 ]\in Prop_{Tm_A} \\ [ \type{opposite}, r1, r2 ]\in Prop_{Tm_B}}{[ \type{opposite}, r1, r2 ]\in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
\end{mathpar}

For $\type{readonly}$ properties:
\begin{mathpar}
    \inferrule{[ \type{readonly}, f ] \in Prop_{Tm_A} \\ f \not\in Field_{Tm_B}}{[ \type{readonly}, f ] \in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
    \and
    \inferrule{[ \type{readonly}, f ] \in Prop_{Tm_B} \\ f \not\in Field_{Tm_A}}{[ \type{readonly}, f ] \in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
    \and
    \inferrule{[ \type{readonly}, f ] \in Prop_{Tm_A} \\ [ \type{readonly}, f ] \in Prop_{Tm_B}}{[ \type{readonly}, f ] \in \mathrm{prop\_\!combine}(Tm_A, Tm_B)}
\end{mathpar}
\isabellelref{tmod_combine_prop}{Ecore.Type_Model_Combination}
\end{defin}

As can be seen from the definition of $\mathrm{prop\_\!combine}(Tm_A, Tm_B)$, properties are only copied under specific circumstances. For $\type{abstract}$ properties, it holds that a class is only abstract in the combination of $Tm_A$ and $Tm_B$ if the class is abstract in both $Tm_A$ and $Tm_B$ or if the class is abstract in one of them, and the class does not occur in the other. Intuitively, this makes sense for correctness. If a class is abstract in both type models, there will not be instances of that class in any of the combined instance models type by those type models. The same holds if the class only occurs in one of the type models, as an instance model cannot contain an instance of a class that is not present in its type model.

For the containment property, it holds that the containment property is always copied over. There are no other conditions here. If there is a containment property in $Prop_{Tm_A} \cup Prop_{Tm_B}$ it will also be in the combination of $Tm_A$ and $Tm_B$.

A default value property is copied over from one of the type models if the other type model does not have the corresponding field defined. Furthermore, a default value may be in the combination of properties of $Tm_A$ and $Tm_B$ if the field occurs in both, and both have the same constant set as the default value for the field. Intuitively, this last requirement makes sense. If we set a default value for a field within a type model, it should not change after combining the type model with another type model, as instance models might depend on the default value set for that field.

Identity properties follow a similar pattern to default value properties. An identity is copied over from one of the type models if the corresponding class is not defined in the other type model. Furthermore, an identity can be preserved if it is set for the same class and attributes in both type models. Again, intuitively, this is the desired solution. If a type model has a class of which a set of attributes can uniquely define the instances, then this should also be the case after the combination with another type model. Merging two sets of attributes might have preserved the identity property as well, but this would be a questionable decision from a practical standpoint, as this means that the identity of instances changes, which makes no sense in real-world scenarios.

The argumentation for identity properties also holds for keyset properties. Therefore these follow a similar pattern, in which the keyset properties of a type model are only copied if the corresponding field does not occur in the other type model, or if the keyset property for a field occurs with the same attributes in both type models.

The opposite property is preserved if it occurs in a type model, but the other type model does not define both of the corresponding fields. Alternatively, the property is preserved if it occurs in both type models with the same fields. All different ways to combine an opposite property would result in an invalid type model according to \cref{defin:formalisations:ecore_formalisation:type_models:type_model_consistency}, which is undesired.

The read-only properties follow a similar pattern to the abstract properties. If a field is read-only in both type models, then it is read-only in the combination. Furthermore, if a field is read-only in one of the type models and the field is not defined in the other type model, then the read-only property can be copied too.

\begin{figure}
    \centering
    \begin{subfigure}{\textwidth}
        \centering
        \includegraphics{images/04_transformation_framework/type_models_combination/chat_partial2.pdf}
        \caption{The chat application model $Tm_{Chat}$}
        \label{fig:transformation_framework:type_models_and_type_graphs:combining_type_models:combine_example_tmod1}
    \end{subfigure}
    \par\medskip
    \begin{subfigure}{\textwidth}
        \centering
        \includegraphics{images/04_transformation_framework/type_models_combination/chat_partial1.pdf}
        \caption{The contact extension model $Tm_{Extension}$}
        \label{fig:transformation_framework:type_models_and_type_graphs:combining_type_models:combine_example_tmod2}
    \end{subfigure}
    \par\medskip
    \begin{subfigure}{\textwidth}
        \centering
        \includegraphics{images/04_transformation_framework/type_models_combination/chat_combined.pdf}
        \caption{The extended chat application model $Tm_{ChatExt}$}
        \label{fig:transformation_framework:type_models_and_type_graphs:combining_type_models:combine_example_tmod12}
    \end{subfigure}
    \caption{Example of the combination of type models}
    \label{fig:transformation_framework:type_models_and_type_graphs:combining_type_models:combine_example}
\end{figure}

With all definitions in place, it is possible to provide a larger example. Suppose the model of a multi-protocol chat application. It consists of $\type{Thread}$s of $\type{Message}$s. Since the application is multi-protocol, each $\type{Thread}$ can use one of the supported $\type{Protocol}$s. The formal definition of the model of such an application could be as follows:

\begin{align*}
Tm_{Chat} =\ &\langle&
Class =\ &\{ \type{.Message}, \type{.Thread} \} \\&&
Enum =\ &\{ \type{.Protocol} \} \\&&
UserDataType =\ &\{\} \\&&
Field =\ &\{
( \type{.Message}, \type{text} ),
( \type{.Thread}, \type{id} ),
( \type{.Thread}, \type{messages} ),
( \type{.Thread}, \type{proto} )\} \\&&
\mathrm{FieldSig} =\ &\big\{
\big( ( \type{.Message}, \type{text} ), ( \type{string}, 1..1 ) \big), \big( ( \type{.Thread}, \type{id} ), ( \type{string}, 1..1 ) \big),\\&&&
\big( ( \type{.Thread}, \type{messages} ), ( [ \type{seqof}, !\type{.Message} ], 0..\mstar ) \big),\\&&&
\big( ( \type{.Thread}, \type{proto} ), ( \type{.Protocol}, 1..1 ) \big) \big)
\big\} \\&&
EnumValue =\ &\{
( \type{.Protocol}, \type{IRC} ),
( \type{.Protocol}, \type{MTPROTO} ),
( \type{.Protocol}, \type{BLUB\!-\!E} )\} \\&&
Inh =\ &\{\} \\&&
Prop =\ &\big\{
\big( \type{identity}, \type{.Message}, \{( \type{.Thread}, \type{id} )\} \big)
\big\} \\&&
Constant =\ &\{\} \\&&
\mathrm{ConstType} =\ &\{\}
\\&\rangle
\end{align*}

An visual representation of $Tm_{Chat}$ is included as  \cref{fig:transformation_framework:type_models_and_type_graphs:combining_type_models:combine_example_tmod1}. Now, assume a model that represents an extension to this application, adding support for $\type{Contact}$s. Each thread can belong to a $\type{Contact}$. A $\type{Contact}$ has a name and some identifier that is protocol specific. For that identifier, the user-defined data type $\type{ProtocolSpecificId}$ is introduced. This extension could formally be defined as:

\begin{align*}
Tm_{Extension} =\ &\langle&
Class =\ &\{ \type{.Contact}, \type{.Thread} \} \\&&
Enum =\ &\{\} \\&&
UserDataType =\ &\{ \type{.ProtocolSpecificId} \} \\&&
Field =\ &\{
( \type{.Contact}, \type{name} ),
( \type{.Contact}, \type{id} ),
( \type{.Thread}, \type{contact} )\} \\&&
\mathrm{FieldSig} =\ &\big\{
\big( ( \type{.Contact}, \type{name} ), ( \type{string}, 1..1 ) \big),\\&&& \big( ( \type{.Contact}, \type{id} ), ( \type{.ProtocolSpecificId}, 1..1 ) \big),\\&&&
\big( ( \type{.Thread}, \type{contact} ), ( ?\type{.Contact}, 0..1 ) \big) \big)
\big\} \\&&
EnumValue =\ &\{\} \\&&
Inh =\ &\{\} \\&&
Prop =\ &\big\{
\big( \type{identity}, \type{.Contact}, \{( \type{.Contact}, \type{id} )\} \big)
\big\} \\&&
Constant =\ &\{\} \\&&
\mathrm{ConstType} =\ &\{\}
\\&\rangle
\end{align*}

The visual representation of the extension is included as \cref{fig:transformation_framework:type_models_and_type_graphs:combining_type_models:combine_example_tmod2}. Now, using \cref{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:combine}, it is possible to combine these models into one model. This will yield the following model:

\begin{align*}
Tm_{ChatExt} =\ &\langle&
Class =\ &\{ \type{.Contact}, \type{.Message}, \type{.Thread} \} \\&&
Enum =\ &\{ \type{.Protocol} \} \\&&
UserDataType =\ &\{ \type{.ProtocolSpecificId} \} \\&&
Field =\ &\{
( \type{.Contact}, \type{name} ),
( \type{.Contact}, \type{id} ),
( \type{.Message}, \type{text} ),\\&&&
( \type{.Thread}, \type{contact} ),
( \type{.Thread}, \type{id} ),
( \type{.Thread}, \type{messages} ),\\&&&
( \type{.Thread}, \type{proto} )\} \\&&
\mathrm{FieldSig} =\ &\big\{
\big( ( \type{.Contact}, \type{name} ), ( \type{string}, 1..1 ) \big),\\&&& \big( ( \type{.Contact}, \type{id} ), ( \type{.ProtocolSpecificId}, 1..1 ) \big),\\&&&
\big( ( \type{.Message}, \type{text} ), ( \type{string}, 1..1 ) \big),\\&&&
\big( ( \type{.Thread}, \type{contact} ), ( ?\type{.Contact}, 0..1 ) \big) \big),\\&&&
\big( ( \type{.Thread}, \type{id} ), ( \type{string}, 1..1 ) \big),\\&&&
\big( ( \type{.Thread}, \type{messages} ), ( [ \type{seqof}, !\type{.Message} ], 0..\mstar ) \big),\\&&&
\big( ( \type{.Thread}, \type{proto} ), ( \type{.Protocol}, 1..1 ) \big) \big)
\big\} \\&&
EnumValue =\ &\{
( \type{.Protocol}, \type{IRC} ),
( \type{.Protocol}, \type{MTPROTO} ),
( \type{.Protocol}, \type{BLUB\!-\!E} )\} \\&&
Inh =\ &\{\} \\&&
Prop =\ &\big\{
\big( \type{identity}, \type{.Contact}, \{( \type{.Contact}, \type{id} )\} \big),\\&&&
\big( \type{identity}, \type{.Message}, \{( \type{.Thread}, \type{id} )\} \big)
\big\} \\&&
Constant =\ &\{\} \\&&
\mathrm{ConstType} =\ &\{\}
\\&\rangle
\end{align*}

A visual representation of this combined model is included as \cref{fig:transformation_framework:type_models_and_type_graphs:combining_type_models:combine_example_tmod12}. The example perfectly shows why the combination of type models is useful: It allows for building larger models out of smaller building blocks. This is the exact goal of this definition within the transformation framework.

Although the definitions of the combination of type models are given, no mathematical properties or theorems are defined yet. Some mathematical properties hold for the combination of type models, that will be presented in the following theorems.

\begin{thm}[Commutativity of the combination of type models]
\label{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:tmod_combine_commute}
Assume that $Tm_A$ and $Tm_B$ are type models, then the $\mathrm{combine}$ function is commutative:
\begin{equation*}
    \mathrm{combine}(Tm_A, Tm_B) = \mathrm{combine}(Tm_B, Tm_A)
\end{equation*}
\isabellelref{tmod_combine_commute}{Ecore.Type_Model_Combination}
\end{thm}

\begin{thm}[Associativity of the combination of type models]
\label{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:tmod_combine_assoc}
Assume that $Tm_A$, $Tm_B$ and $Tm_C$ are type models, then the $\mathrm{combine}$ function is associative:
\begin{equation*}
    \mathrm{combine}(\mathrm{combine}(Tm_A, Tm_B), Tm_C) = \mathrm{combine}(Tm_A, \mathrm{combine}(Tm_B, Tm_C))
\end{equation*}
\isabellelref{tmod_combine_assoc}{Ecore.Type_Model_Combination}
\end{thm}

\begin{thm}[Idempotence of the combination of type models]
\label{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:tmod_combine_idemp}
Assume that $Tm_A$ is a type model and that it is consistent in the sense of \cref{defin:formalisations:ecore_formalisation:type_models:type_model_consistency}. Then the following property holds:
\begin{equation*}
    \mathrm{combine}(Tm_A, Tm_A) = Tm_A
\end{equation*}
\isabellelref{tmod_combine_idemp_alt}{Ecore.Type_Model_Combination}
\end{thm}

These properties follow directly from \cref{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:combine}, but the corresponding proofs will not be included here. It should be noted that these properties are indeed proven correct as part of this thesis, and the corresponding proofs are validated within Isabelle.

Besides these properties, the combination of type models also has an identity element. The empty type model represents this identity element, but it needs to be defined first:

\begin{defin}[Empty type model]
\label{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:empty_type_model}
Let $Tm_{\epsilon}$ be the empty type model. $Tm_{\epsilon}$ is defined as:
\begin{align*}
Tm_{\epsilon} = \langle&
Class = \{\} \\&
Enum = \{\} \\&
UserDataType = \{\} \\&
Field = \{\} \\&
\mathrm{FieldSig} = undefined \\&
EnumValue = \{\} \\&
Inh = \{\} \\&
Prop = \{\} \\&
Constant = \{\} \\&
\mathrm{ConstType} = undefined\rangle
\end{align*}
\end{defin}

\begin{thm}[Correctness of the empty type model]
\label{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:tmod_empty_correct}
The empty type model, $Tm_{\epsilon}$, is consistent with respect to
\cref{defin:formalisations:ecore_formalisation:type_models:type_model_consistency}.
\isabellelref{tmod_empty_correct}{Ecore.Type_Model}
\end{thm}

The proof for the correctness of the empty type model is trivial. Still, a validated version of this proof can be found within the Isabelle theories of this thesis.

As mentioned earlier, the empty type model acts as an identity element when combining two type models. The following theorem specifies this behaviour.

\begin{thm}[Identity of the combination of type models]
\label{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:tmod_combine_identity}
Assume that $Tm_A$ is a type model and that it is consistent in the sense of \cref{defin:formalisations:ecore_formalisation:type_models:type_model_consistency}. Then $Tm_{\epsilon}$ acts as an identity element in the combination function:
\begin{equation*}
    \mathrm{combine}(Tm_{\epsilon}, Tm_A) = Tm_A
\end{equation*}
\isabellelref{tmod_combine_identity_alt}{Ecore.Type_Model_Combination}
\end{thm}

Once more, the proof of this theorem follows directly from the definition. Therefore, the corresponding proof will not be included here, but a validated version can be found within the Isabelle theories of this thesis.

A final desired property for the combination of type models is a correctness property. \cref{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:tmod_combine_correct} defines the theorem under which the combination of type models is a consistent type model. Please note that this theorem is a generic theorem, which does not take into account that the type models are mostly distinct.

\begin{thm}[Consistency of the combination of type models]
\label{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:tmod_combine_correct}
Assume that $Tm_A$ and $Tm_B$ are consistent type models in the sense of \cref{defin:formalisations:ecore_formalisation:type_models:type_model_consistency}. Furthermore, assume the following properties:
\begin{itemize}
    \item For all shared fields, the type is the same in both type models: $\forall f \in Field_{Tm_A} \cap Field_{Tm_B}\!: \mathrm{type}_{Tm_A}(f) = \mathrm{type}_{Tm_B}(f)$
    \item For all shared fields, the combination of the multiplicities is a valid multiplicity: $\forall f \in Field_{Tm_A} \cap Field_{Tm_B}\!: \max\big(\mathrm{lower}(\mathrm{FieldSig}_{Tm_A}(f)), \mathrm{lower}(\mathrm{FieldSig}_{Tm_B}(f))\big) .. \min\big(\mathrm{upper}(\mathrm{FieldSig}_{Tm_A}(f)),$\\ $\mathrm{upper}(\mathrm{FieldSig}_{Tm_B}(f))\big) \in \mathbb{M}$
    \item For all shared constants, the constant type is the same in both models: $\forall f \in Constant_{Tm_A} \cap Constant_{Tm_B}\!: \mathrm{ConstType}_{Tm_A}(f) = \mathrm{ConstType}_{Tm_B}(f)$
    \item Identifiers used for a class in $Tm_A$ cannot be used for an enumeration type or user-defined data type in $Tm_B$: $\forall c \in Class_{Tm_A}\!: c \not\in Enum_{Tm_B} \land c \not\in UserDataType_{Tm_B}$.
    \item Identifiers used for a class in $Tm_B$ cannot be used for an enumeration type or user-defined data type in $Tm_A$: $\forall c \in Class_{Tm_B}\!: c \not\in Enum_{Tm_A} \land c \not\in UserDataType_{Tm_A}$.
    \item Identifiers used for an enumeration type in $Tm_A$ cannot be used for a class or user-defined data type in $Tm_B$: $\forall c \in Enum_{Tm_A}\!: c \not\in Class_{Tm_B} \land c \not\in UserDataType_{Tm_B}$.
    \item Identifiers used for an enumeration type in $Tm_B$ cannot be used for a class or user-defined data type in $Tm_A$: $\forall c \in Enum_{Tm_B}\!: c \not\in Class_{Tm_A} \land c \not\in UserDataType_{Tm_A}$.
    \item Identifiers from $Tm_A$ may not be in the namespace of an identifier in $Tm_B$: $\forall x \in Class_{Tm_A} \cup Enum_{Tm_A} \cup UserDataType_{Tm_A}; y \in Class_{Tm_B} \cup Enum_{Tm_B} \cup UserDataType_{Tm_B}\!:$\\$x \text{ not in the namespace of } y$
    \item Identifiers from $Tm_B$ may not be in the namespace of an identifier in $Tm_A$: $\forall x \in Class_{Tm_B} \cup Enum_{Tm_B} \cup UserDataType_{Tm_B}; y \in Class_{Tm_A} \cup Enum_{Tm_A} \cup UserDataType_{Tm_A}\!:$\\$x \text{ not in the namespace of } y$
    \item The transitive closure of the inheritance relation is irreflexive: $(Inh_{Tm_A} \cup Inh_{Tm_B})^+$ is irreflexive
    \item For any superclass with an identity, the identity of the subclasses must be a superset of the identity of the superclass: $\forall c_1\ c_2\ A_1\ A_2\!: [ \type{identity}, c_1, A_1 ] \in \mathrm{prop\_\!combine}(Tm_A, Tm_B) \land [ \type{identity}, c_2, A_2 ] \in \mathrm{prop\_\!combine}(Tm_A, Tm_B) \land c_1 \neq c_2\ \land\ !c_1 \not\sqsubseteq_{Tm_A}\ !c_2\ \land\ !c_1 \not\sqsubseteq_{Tm_B}\ !c_2\ \land\ !c_1 \sqsubseteq_{\mathrm{combine}(Tm_A, Tm_B)}\ !c_2 \implies A \subseteq B$
    \item For all shared fields, if $Tm_{A}$ defines a default value, $Tm_{B}$ should define the same default value, and vice versa: $\forall f \in Field_{Tm_A} \cap Field_{Tm_B}\!: [ \type{defaultValue}, f, v ] \in Prop_{Tm_A} \Longleftrightarrow [ \type{defaultValue}, f, v ] \in Prop_{Tm_B}$.
    \item For all shared classes, if $Tm_{A}$ defines a identity, $Tm_{B}$ should define the same identity, and vice versa: $\forall c \in Class_{Tm_A} \cap Class_{Tm_B}\!: [ \type{identity}, c, A ] \in Prop_{Tm_A} \Longleftrightarrow [ \type{identity}, c, A ] \in Prop_{Tm_B}$.
    \item For all shared fields, if $Tm_{A}$ defines a keyset, $Tm_{B}$ should define the same keyset, and vice versa: $\forall r \in Field_{Tm_A} \cap Field_{Tm_B}\!: [ \type{keyset}, r, A ] \in Prop_{Tm_A} \Longleftrightarrow [ \type{keyset}, r, A ] \in Prop_{Tm_B}$.
    \item For all shared fields, if $Tm_{A}$ defines an opposite property, $Tm_{B}$ should define the same opposite property, and vice versa: $\forall r \in Field_{Tm_A} \cap Field_{Tm_B}\!: [ \type{opposite}, r, r' ] \in Prop_{Tm_A} \Longleftrightarrow [ \type{opposite}, r, r' ] \in Prop_{Tm_B}$
\end{itemize}

Then $\mathrm{combine}(Tm_A, Tm_B)$ is a consistent type model in the sense of \cref{defin:formalisations:ecore_formalisation:type_models:type_model_consistency}
\isabellelref{tmod_combine_correct}{Ecore.Type_Model_Combination}
\end{thm}

\begin{proof}
To proof that $\mathrm{combine}(Tm_A, Tm_B)$ is a consistent type model, it needs to be shown that\\ $\mathrm{combine}(Tm_A, Tm_B)$ gives rise to a valid structure for a type model and that \cref{defin:formalisations:ecore_formalisation:type_models:type_model_consistency} holds. For readability, define $Tm_{AB}$ to be $\mathrm{combine}(Tm_A, Tm_B)$.

\emph{Structural properties}
\begin{itemize}
    \item All elements of $Class_{Tm_{AB}}$ are elements of $Id$.

    Follows from $Class_{Tm_A} \subseteq Id$ and $Class_{Tm_B} \subseteq Id$.

    \item All elements of $Enum_{Tm_{AB}}$ are elements of $Id$.

    Follows from $Enum_{Tm_A} \subseteq Id$ and $Enum_{Tm_B} \subseteq Id$.

    \item All elements of $UserDataType_{Tm_{AB}}$ are elements of $Id$.

    Follows from $UserDataType_{Tm_A} \subseteq Id$ and $UserDataType_{Tm_B} \subseteq Id$.

    \item All elements of $Field_{Tm_{AB}}$ are elements of $(Class_{Tm_{AB}} \times Name)$.

    Follows from $Field_{Tm_A} \subseteq (Class_{Tm_A} \times Name)$ and $Field_{Tm_B} \subseteq (Class_{Tm_B} \times Name)$. To complete the proof, use $Class_{Tm_{AB}} = Class_{Tm_A} \cup Class_{Tm_B}$.

    \item For each field $f$, $\mathrm{FieldSig}_{Tm_{AB}}(f)$ must be an element of $(Type_{Tm_{AB}} \times \mathbb{M})$.

    First, note that $Type_{Tm_{AB}} = Type_{Tm_A} \cup Type_{Tm_B}$\\(see \isabelleref{tmod_combine_type}{Ecore.Type_Model_Combination}).

    If $f \in Field_{Tm_A} \setminus Field_{Tm_B}$, then $\mathrm{FieldSig}_{Tm_{AB}}(f) \in (Type_{Tm_{AB}} \times \mathbb{M})$.

    Similarly, if $f \in Field_{Tm_B} \setminus Field_{Tm_A}$, then $\mathrm{FieldSig}_{Tm_{AB}}(f) \in (Type_{Tm_{AB}} \times \mathbb{M})$.

    If $f \in Field_{Tm_A} \cap Field_{Tm_B}$, then $\mathrm{type}_{Tm_A}(f) = \mathrm{type}_{Tm_B}(f)$ by assumption. Also, the combined multiplicity is correct by assumption. Therefore $\mathrm{FieldSig}_{Tm_{AB}}(f) \in (Type_{Tm_{AB}} \times \mathbb{M})$.

    \item All elements of $EnumValue_{Tm_{AB}}$ are elements of $(Enum_{Tm_{AB}} \times Name)$.

    Follows from $EnumValue_{Tm_A} \subseteq (Enum_{Tm_A} \times Name)$ and $EnumValue_{Tm_B} \subseteq (Enum_{Tm_B} \times Name)$. To complete the proof, use $Enum_{Tm_{AB}} = Enum_{Tm_A} \cup Enum_{Tm_B}$.

    \item All elements of $Inh_{Tm_{AB}}$ are elements of $(Class_{Tm_{AB}} \times Class_{Tm_{AB}})$.

    Follows from $Inh_{Tm_A} \subseteq (Class_{Tm_A} \times Class_{Tm_A})$ and $Inh_{Tm_B} \subseteq (Class_{Tm_B} \times Class_{Tm_B})$. Furthermore, $Class_{Tm_{AB}} = Class_{Tm_A} \cup Class_{Tm_B}$.

    \item All elements of $Prop_{Tm_{AB}}$ are elements of $Property_{Tm_{AB}}$.

    Make a case distinction for the different possible properties.
    \begin{itemize}
        \item For $[ \type{abstract}, c ] \in Prop_{Tm_{AB}}$, use the fact that $c \in Class_{Tm_A} \cup Class_{Tm_B}$. Therefore, $[ \type{abstract}, c ] \in Property_{Tm_{AB}}$.

        \item For $[ \type{containment}, r ] \in Prop_{Tm_{AB}}$, use the fact that $Rel_{Tm_{AB}} = Rel_{Tm_A} \cup Rel_{Tm_B}$ (see \isabelleref{tmod_combine_rel}{Ecore.Type_Model_Combination}). Then have $[ \type{containment}, r ] \in Property_{Tm_{AB}}$.

        \item For $[ \type{defaultValue}, f, v ] \in Prop_{Tm_{AB}}$, use the fact that $f \in Field_{Tm_A} \cup Field_{Tm_B}$ and $v \in Constant_{Tm_A} \cup Constant_{Tm_B}$. Using a case disinction on the combination of properties, it is possible to show that $\mathrm{ConstType}_{Tm_{AB}}(v) \sqsubseteq_{Tm_{AB}} \mathrm{type}_{Tm_{AB}}(f)$. Therefore, $[ \type{defaultValue}, f, v ] \in Property_{Tm_{AB}}$.

        \item For $[ \type{identity}, c, A ] \in Prop_{Tm_{AB}}$, use the fact that $c \in Class_{Tm_A} \cup Class_{Tm_B}$ and $A \subseteq fields_{Tm_A} \lor A \subseteq fields_{Tm_B}$. Then have that $A \subseteq fields_{Tm_{AB}}$ Therefore, $[ \type{identity}, c, A ] \in Property_{Tm_{AB}}$.

        \item For $[ \type{keyset}, r, A ] \in Prop_{Tm_{AB}}$, use the fact that $Rel_{Tm_{AB}} = Rel_{Tm_A} \cup Rel_{Tm_B}$ (see \isabelleref{tmod_combine_rel}{Ecore.Type_Model_Combination}) to show $r \in Rel_{Tm_{AB}}$. Also use the fact that $Attr_{Tm_{AB}} = Attr_{Tm_A} \cup Attr_{Tm_B}$ to show $A \subseteq Attr_{Tm_{AB}}$ (see \isabelleref{tmod_combine_attr}{Ecore.Type_Model_Combination}). Because types are preserved after combining, it is possible to show that $\forall f \in A\!: \mathrm{uncontainer}(\mathrm{type}_{Tm_{AB}}(r)) \sqsubseteq_{Tm_{AB}} \mathrm{class}_{Tm_{AB}}(f)$. Furthermore, $\mathrm{type}_{Tm_{AB}}(r) \in (\{ \type{setof}, \type{ordof} \} \times ClassType_{Tm_{AB}})$. Therefore, $[ \type{keyset}, r, A ] \in Property_{Tm_{AB}}$.

        \item For $[ \type{opposite}, r, r' ] \in Prop_{Tm_{AB}}$, use the fact that $Rel_{Tm_{AB}} = Rel_{Tm_A} \cup Rel_{Tm_B}$ (see \isabelleref{tmod_combine_rel}{Ecore.Type_Model_Combination}) to show $r \in Rel_{Tm_{AB}}$ and $r' \in Rel_{Tm_{AB}}$. Because types are preserved after combining, it is possible to show that $!c1 \sqsubseteq_{Tm_{AB}} \mathrm{uncontainer}(\mathrm{type}_{Tm_{AB}}(r'))$, $!c2 \sqsubseteq_{Tm_{AB}} \mathrm{uncontainer}(\mathrm{type}_{Tm_{AB}}(r))$,\\ $\mathrm{type}_{Tm_{AB}}(r) \not\in \{ \type{bagof}, \type{seqof} \} \times Type_{Tm_{AB}}$ and finally $type_{Tm_{AB}}(r') \not\in \{ \type{bagof}, \type{seqof} \} \times Type_{Tm_{AB}}$. Therefore, $[ \type{opposite}, r, r' ] \in Property_{Tm_{AB}}$.

        \item For $[ \type{readonly}, f ] \in Prop_{Tm_{AB}}$, use the fact that $f \in Field_{Tm_A} \cup Field_{Tm_B}$. Therefore, $[ \type{readonly}, f ] \in Property_{Tm_{AB}}$.
    \end{itemize}

    \item All elements of $Constant_{Tm_{AB}}$ are elements of $Id$.

    Follows from $Constant_{Tm_A} \subseteq Id$ and $Constant_{Tm_B} \subseteq Id$.

    \item For each constant $c$, $\mathrm{ConstType}_{Tm_{AB}}(c)$ must be an element of $Type_{Tm_{AB}}$.

    First, note that $Type_{Tm_{AB}} = Type_{Tm_A} \cup Type_{Tm_B}$\\(see \isabelleref{tmod_combine_type}{Ecore.Type_Model_Combination}).

    If $c \in Constant_{Tm_A} \setminus Constant_{Tm_B}$, then $\mathrm{ConstType}_{Tm_{AB}}(f) \in Type_{Tm_{AB}}$.

    Similarly, if $c \in Constant_{Tm_B} \setminus Constant_{Tm_A}$, then $\mathrm{ConstType}_{Tm_{AB}}(c) \in Type_{Tm_{AB}}$.

    If $c \in Constant_{Tm_A} \cap Constant_{Tm_B}$, then $\mathrm{ConstType}_{Tm_A}(c) = \mathrm{ConstType}_{Tm_B}(c)$ by assumption. Therefore $\mathrm{ConstType}_{Tm_{AB}}(c) \in Type_{Tm_{AB}}$.

    \item $Class_{Tm_{AB}}$, $DataType$, $Enum_{Tm_{AB}}$ and $UserDataType_{Tm_{AB}}$ are pairwise disjoint.

    Notice that $Class_{Tm_{A}}$, $DataType$, $Enum_{Tm_{A}}$, $UserDataType_{Tm_{A}}$ are pairwise disjoint. Also, $Class_{Tm_{B}}$, $DataType$, $Enum_{Tm_{B}}$, $UserDataType_{Tm_{B}}$ are pairwise disjoint.

    Use that $Class_{Tm_{AB}} = Class_{Tm_{A}} \cup Class_{Tm_{B}}$, $Enum_{Tm_{AB}} = Enum_{Tm_{A}} \cup Enum_{Tm_{B}}$ and\\ $UserDataType_{Tm_{AB}} = UserDataType_{Tm_{A}} \cup UserDataType_{Tm_{B}}$. Use this to split the possible cases.

    Only the case where one element is from $Class_{Tm_{A}} \cup Enum_{Tm_{A}} \cup UserDataType_{Tm_{A}}$ and one element is from $Class_{Tm_{B}} \cup Enum_{Tm_{B}} \cup UserDataType_{Tm_{B}}$ cannot be proven directly. For this case, the proof follows from the assumptions.

    \item None of the elements in $Class_{Tm_{AB}}$, $DataType$, $Enum_{Tm_{AB}}$ and $UserDataType_{Tm_{AB}}$ may be in the namespace of another element in that set.

    Use that $Class_{Tm_{AB}} = Class_{Tm_{A}} \cup Class_{Tm_{B}}$, $Enum_{Tm_{AB}} = Enum_{Tm_{A}} \cup Enum_{Tm_{B}}$ and\\ $UserDataType_{Tm_{AB}} = UserDataType_{Tm_{A}} \cup UserDataType_{Tm_{B}}$. Use this to split the possible cases.

    It is not possible to directly proof the cases where the identifier comes from $Class_{Tm_{A}} \cup Enum_{Tm_{A}} \cup UserDataType_{Tm_{A}}$ and the namespace comes from $Class_{Tm_{B}} \cup Enum_{Tm_{B}} \cup UserDataType_{Tm_{B}}$. Furthermore, it is also not possible for the cases where the identifier comes from $Class_{Tm_{B}} \cup Enum_{Tm_{B}} \cup UserDataType_{Tm_{B}}$ and the namespace comes from\\ $Class_{Tm_{A}} \cup Enum_{Tm_{A}} \cup UserDataType_{Tm_{A}}$. For these cases, the proof follows from the assumptions.

    \item $Inh_{Tm_{AB}}$ is an asymmetric relation, of which the transitive closure is irreflexive.

    The transitive closure of $Inh_{Tm_{AB}}$ is irreflexive by assumption. Then show that $Inh_{Tm_{AB}}$ is an asymmetric relation using the assumption that the transitive closure of $Inh_{Tm_{AB}}$ is irreflexive.
\end{itemize}

\emph{Consistency properties}
\begin{itemize}
    \item For all $\mathrm{type}_{Tm_{AB}}(f) \in DataType \cup Enum_{Tm_{AB}} \cup UserDataType_{Tm_{AB}} \cup (\type{proper} \times Class_{Tm_{AB}})$, it holds that $\mathrm{lower}_{Tm_{AB}}(f) = 1$.

    Use the fact that $\mathrm{type}_{Tm_{AB}}(f) = \mathrm{type}_{Tm_{A}}(f)$ or $\mathrm{type}_{Tm_{AB}}(f) = \mathrm{type}_{Tm_{B}}(f)$.

    If $\mathrm{type}_{Tm_{AB}}(f) = \mathrm{type}_{Tm_{A}}(f)$, then $\mathrm{type}_{Tm_{AB}}(f) \in DataType \cup Enum_{Tm_{AB}} \cup UserDataType_{Tm_{AB}} \cup (\type{proper} \times Class_{Tm_{AB}})$ only when $\mathrm{type}_{Tm_{A}}(f) \in DataType \cup Enum_{Tm_{A}} \cup UserDataType_{Tm_{A}} \cup (\type{proper} \times Class_{Tm_{A}})$.

    Then if $\mathrm{type}_{Tm_{A}}(f) \in DataType \cup Enum_{Tm_{A}} \cup UserDataType_{Tm_{A}} \cup (\type{proper} \times Class_{Tm_{A}})$, then $\mathrm{lower}_{Tm_{A}}(f) = 1$. As a consequence, it must be that $\mathrm{lower}_{Tm_{AB}}(f) = 1$.

    If $\mathrm{type}_{Tm_{AB}}(f) = \mathrm{type}_{Tm_{B}}(f)$, then $\mathrm{type}_{Tm_{AB}}(f) \in DataType \cup Enum_{Tm_{AB}} \cup UserDataType_{Tm_{AB}} \cup (\type{proper} \times Class_{Tm_{AB}})$ only when $\mathrm{type}_{Tm_{B}}(f) \in DataType \cup Enum_{Tm_{B}} \cup UserDataType_{Tm_{B}} \cup (\type{proper} \times Class_{Tm_{B}})$.

    Then if $\mathrm{type}_{Tm_{B}}(f) \in DataType \cup Enum_{Tm_{B}} \cup UserDataType_{Tm_{B}} \cup (\type{proper} \times Class_{Tm_{B}})$, then $\mathrm{lower}_{Tm_{B}}(f) = 1$. As a consequence, it must be that $\mathrm{lower}_{Tm_{AB}}(f) = 1$.

    \item For all $\mathrm{type}_{Tm_{AB}}(f) \in (\type{nullable} \times Class_{Tm_{AB}})$, it holds that $\mathrm{lower}_{Tm_{AB}}(f) = 0$.

    Use the fact that $\mathrm{type}_{Tm_{AB}}(f) = \mathrm{type}_{Tm_{A}}(f)$ or $\mathrm{type}_{Tm_{AB}}(f) = \mathrm{type}_{Tm_{B}}(f)$.

    If $\mathrm{type}_{Tm_{AB}}(f) = \mathrm{type}_{Tm_{A}}(f)$, then $\mathrm{type}_{Tm_{AB}}(f) \in (\type{nullable} \times Class_{Tm_{AB}})$ only when $\mathrm{type}_{Tm_{A}}(f) \in (\type{nullable} \times Class_{Tm_{A}})$.

    Then if $\mathrm{type}_{Tm_{A}}(f) \in (\type{nullable} \times Class_{Tm_{A}})$, then $\mathrm{lower}_{Tm_{A}}(f) = 0$. As a consequence, it must be that $\mathrm{lower}_{Tm_{AB}}(f) = 0$.

    If $\mathrm{type}_{Tm_{AB}}(f) = \mathrm{type}_{Tm_{B}}(f)$, then $\mathrm{type}_{Tm_{AB}}(f) \in (\type{nullable} \times Class_{Tm_{AB}})$ only when $\mathrm{type}_{Tm_{B}}(f) \in (\type{nullable} \times Class_{Tm_{B}})$.

    Then if $\mathrm{type}_{Tm_{B}}(f) \in (\type{nullable} \times Class_{Tm_{AB}})$, then $\mathrm{lower}_{Tm_{B}}(f) = 0$. As a consequence, it must be that $\mathrm{lower}_{Tm_{AB}}(f) = 0$.

    \item For all $\mathrm{type}_{Tm_{AB}}(f) \not\in Container_{Tm_{AB}}$, it holds that $\mathrm{upper}_{Tm_{AB}}(f) = 1$.

    Use the fact that $\mathrm{type}_{Tm_{AB}}(f) = \mathrm{type}_{Tm_{A}}(f)$ or $\mathrm{type}_{Tm_{AB}}(f) = \mathrm{type}_{Tm_{B}}(f)$.

    If $\mathrm{type}_{Tm_{AB}}(f) = \mathrm{type}_{Tm_{A}}(f)$, then $\mathrm{type}_{Tm_{AB}}(f) \not\in Container_{Tm_{AB}}$ only when $\mathrm{type}_{Tm_{A}}(f) \not\in Container_{Tm_{A}}$.

    Then if $\mathrm{type}_{Tm_{A}}(f) \not\in Container_{Tm_{A}}$, then $\mathrm{upper}_{Tm_{A}}(f) = 1$. As a consequence, must also be $\mathrm{upper}_{Tm_{AB}}(f) = 1$.

    If $\mathrm{type}_{Tm_{AB}}(f) = \mathrm{type}_{Tm_{B}}(f)$, then $\mathrm{type}_{Tm_{AB}}(f) \not\in Container_{Tm_{AB}}$ only when $\mathrm{type}_{Tm_{B}}(f) \not\in Container_{Tm_{B}}$.

    Then if $\mathrm{type}_{Tm_{B}}(f) \not\in Container_{Tm_{B}}$, then $\mathrm{upper}_{Tm_{B}}(f) = 1$. As a consequence, must also be $\mathrm{upper}_{Tm_{AB}}(f) = 1$.

    \item $[ \type{containment}, r ] \in Prop_{Tm_{AB}} \land [ \type{opposite}, r, r' ] \in Prop_{Tm_{AB}} \Longrightarrow upper_{Tm_{AB}}(r') = 1$.

    Use the fact that $[ \type{containment}, r ] \in Prop_{Tm_{AB}}$ means that $[ \type{containment}, r ] \in Prop_{Tm_{A}}$ or $[ \type{containment}, r ] \in Prop_{Tm_{B}}$

    Also use the fact that $[ \type{opposite}, r, r' ] \in Prop_{Tm_{AB}}$ means that $[ \type{opposite}, r, r' ] \in Prop_{Tm_{A}} \setminus Prop_{Tm_{B}}$, $[ \type{opposite}, r, r' ] \in Prop_{Tm_{B}} \setminus Prop_{Tm_{A}}$ or $\type{opposite}, r, r' ] \in Prop_{Tm_{A}} \cap Prop_{Tm_{B}}$.

    Based on these two facts, make a case distinction of all 6 possible cases. The case where $[ \type{opposite}, r, r' ] \in Prop_{Tm_{A}} \setminus Prop_{Tm_{B}}$ and $[ \type{containment}, r ] \in Prop_{Tm_{B}}$ is invalid, since $r$ cannot be part of $Field_{Tm_B}$ by definition of the combination of properties. Similarly, the case  $[ \type{opposite}, r, r' ] \in Prop_{Tm_{B}} \setminus Prop_{Tm_{A}}$ and $[ \type{containment}, r ] \in Prop_{Tm_{A}}$ is also invalid.

    For the other cases, at least $\mathrm{upper}_{Tm_{A}}(r') = 1$ or $\mathrm{upper}_{Tm_{B}}(r') = 1$. The upper bound of $r$ in the other type model may be larger than $1$. By the definition of the combination of field signatures, $\mathrm{upper}_{Tm_{AB}}(r') = 1$.

    \item $[ \type{defaultValue}, f, v ] \in Prop_{Tm_{AB}} \land [ \type{defaultValue}, f, v' ] \in Prop_{Tm_{AB}} \Longrightarrow v = v'$.

    Use the fact that $[ \type{defaultValue}, f, v ] \in Prop_{Tm_{AB}}$ means that $[ \type{defaultValue}, f, v ] \in Prop_{Tm_{A}} \setminus Prop_{Tm_{B}}$, $[ \type{defaultValue}, f, v ] \in Prop_{Tm_{B}} \setminus Prop_{Tm_{A}}$ or $[ \type{defaultValue}, f, v ] \in Prop_{Tm_{A}} \cap Prop_{Tm_{B}}$.

    Also use the similar fact for $[ \type{defaultValue}, f, v' ] \in Prop_{Tm_{AB}}$.

    Now make a case distinction based on these facts. The case where $[ \type{defaultValue}, f, v ] \in Prop_{Tm_{A}} \setminus Prop_{Tm_{B}}$ and $[ \type{defaultValue}, f, v' ] \in Prop_{Tm_{B}} \setminus Prop_{Tm_{A}}$ is invalid, since $f$ cannot be part of $Field_{Tm_B}$ by definition of the combination of properties. Similarly, the case $[ \type{defaultValue}, f, v ] \in Prop_{Tm_{B}} \setminus Prop_{Tm_{A}}$ and $[ \type{defaultValue}, f, v' ] \in Prop_{Tm_{A}} \setminus Prop_{Tm_{B}}$ is also invalid.

    In all other cases, use the fact that $v = v'$ in both $Tm_{A}$ and $Tm_{B}$ to show that $v = v'$ in $Tm_{AB}$.

    \item $[ \type{identity}, c_1, A_1 ] \in Prop_{Tm_{AB}} \land [ \type{identity}, c_2, A_2 ] \in Prop_{Tm_{AB}}\: \land\: !c_1 \sqsubseteq_{Tm_{AB}}\, !c_2 \Longrightarrow A_1 \subseteq A_2$.

    First establish that $!c_1 \sqsubseteq_{Tm_A}\ !c_2$, $!c_1 \sqsubseteq_{Tm_B}\ !c_2$ or $!c_1 \not\sqsubseteq_{Tm_A}\ !c_2\ \land\ !c_1 \not\sqsubseteq_{Tm_B}\ !c_2$.

    Then use the fact that $[ \type{identity}, c_1, A_1 ] \in Prop_{Tm_{AB}}$ means that $[ \type{identity}, c_1, A_1 ] \in Prop_{Tm_{A}} \setminus Prop_{Tm_{B}}$, $[ \type{identity}, c_1, A_1 ] \in Prop_{Tm_{B}} \setminus Prop_{Tm_{A}}$ or $[ \type{identity}, c_1, A_1 ] \in Prop_{Tm_{A}} \cap Prop_{Tm_{B}}$.

    Also use the similar fact for $[ \type{identity}, c_2, A_2 ] \in Prop_{Tm_{AB}}$.

    Make a case distinction using the facts above. The case where $!c_1 \sqsubseteq_{Tm_A}\ !c_2$, $[ \type{identity}, c_1, A_1 ] \in Prop_{Tm_{A}} \setminus Prop_{Tm_{B}}$ and $[ \type{identity}, c_2, A_2 ] \in Prop_{Tm_{B}} \setminus Prop_{Tm_{A}}$ is invalid, since $c_2$ must be part of $Class_{Tm_A}$ to have $!c_1 \sqsubseteq_{Tm_A}\ !c_2$. Similarly, the case $!c_1 \sqsubseteq_{Tm_B}\ !c_2$, $[ \type{identity}, c_1, A_1 ] \in Prop_{Tm_{B}} \setminus Prop_{Tm_{A}}$ and $[ \type{identity}, c_2, A_2 ] \in Prop_{Tm_{A}} \setminus Prop_{Tm_{B}}$ is also invalid.

    Furthermore, the case where $!c_1 \sqsubseteq_{Tm_A}\ !c_2$ and $[ \type{identity}, c_1, A_1 ] \in Prop_{Tm_{B}} \setminus Prop_{Tm_{A}}$ is invalid, as well as $!c_1 \sqsubseteq_{Tm_B}\ !c_2$ and $[ \type{identity}, c_1, A_1 ] \in Prop_{Tm_{A}} \setminus Prop_{Tm_{B}}$

    Then solve the proof for all cases where $!c_1 \sqsubseteq_{Tm_A}\ !c_2$ or $!c_1 \sqsubseteq_{Tm_B}\ !c_2$. In the cases where $!c_1 \sqsubseteq_{Tm_B}\ !c_2$ or $!c_1 \not\sqsubseteq_{Tm_A}\ !c_2\ \land\ !c_1 \not\sqsubseteq_{Tm_B}\ !c_2$, distinguish once more two cases: $c1 = c2$ and $c1 \neq c2$.

    In case that $c1 = c2$, show that when $!c_1 \sqsubseteq_{Tm_A}\ !c_2$ or $!c_1 \sqsubseteq_{Tm_B}\ !c_2$, it cannot be the case that $!c_1 \sqsubseteq_{Tm_{AB}}\, !c_2$ because of the reflexitivity of the subtype relation.

    Finally, if $c1 \neq c2$, the proof is given by assumption.

    \item $[ \type{keyset}, r, A ] \in Prop_{Tm_{AB}} \land [ \type{keyset}, r, A' ] \in Prop_{Tm_{AB}} \Longrightarrow A = A'$.

    Use the fact that $[ \type{keyset}, r, A ] \in Prop_{Tm_{AB}}$ means that $[ \type{keyset}, r, A ] \in Prop_{Tm_{A}} \setminus Prop_{Tm_{B}}$, $[ \type{keyset}, r, A ] \in Prop_{Tm_{B}} \setminus Prop_{Tm_{A}}$ or $[ \type{keyset}, r, A ] \in Prop_{Tm_{A}} \cap Prop_{Tm_{B}}$.

    Also use the similar fact for $[ \type{keyset}, r, A' ] \in Prop_{Tm_{AB}}$.

    Now make a case distinction based on these facts. The case where $[ \type{keyset}, r, A ] \in Prop_{Tm_{A}} \setminus Prop_{Tm_{B}}$ and $[ \type{keyset}, r, A' ] \in Prop_{Tm_{B}} \setminus Prop_{Tm_{A}}$ is invalid, since $r$ cannot be part of $Field_{Tm_B}$ by definition of the combination of properties. Similarly, the case $[ \type{keyset}, r, A ] \in Prop_{Tm_{B}} \setminus Prop_{Tm_{A}}$ and $[ \type{keyset}, r, A' ] \in Prop_{Tm_{A}} \setminus Prop_{Tm_{B}}$ is also invalid.

    In all other cases, use the fact that $A = A'$ in both $Tm_{A}$ and $Tm_{B}$ to show that $A = A'$ in $Tm_{AB}$.

    \item $[ \type{opposite}, r, r' ] \in Prop_{Tm_{AB}} \land [ \type{opposite}, r, r'' ] \in Prop_{Tm_{AB}} \Longrightarrow r' = r''$.

    Use the fact that $[ \type{opposite}, r, r' ] \in Prop_{Tm_{AB}}$ means that $[ \type{opposite}, r, r' ] \in Prop_{Tm_{A}} \setminus Prop_{Tm_{B}}$, $[ \type{opposite}, r, r' ] \in Prop_{Tm_{B}} \setminus Prop_{Tm_{A}}$ or $[ \type{opposite}, r, r' ] \in Prop_{Tm_{A}} \cap Prop_{Tm_{B}}$.

    Also use the similar fact for $[ \type{opposite}, r, r'' ] \in Prop_{Tm_{AB}}$.

    Now make a case distinction based on these facts. The case where $[ \type{opposite}, r, r' ] \in Prop_{Tm_{A}} \setminus Prop_{Tm_{B}}$ and $[ \type{opposite}, r, r'' ] \in Prop_{Tm_{B}} \setminus Prop_{Tm_{A}}$ is invalid, since $r$ cannot be part of $Field_{Tm_B}$ by definition of the combination of properties. Similarly, the case $[ \type{opposite}, r, r' ] \in Prop_{Tm_{B}} \setminus Prop_{Tm_{A}}$ and $[ \type{opposite}, r, r'' ] \in Prop_{Tm_{A}} \setminus Prop_{Tm_{B}}$ is also invalid.

    In all other cases, use the fact that $r' = r''$ in both $Tm_{A}$ and $Tm_{B}$ to show that $r' = r''$ in $Tm_{AB}$.

    \item $[ \type{opposite}, r, r' ] \in Prop_{Tm_{AB}} \Longleftrightarrow [ \type{opposite}, r', r ] \in Prop_{Tm_{AB}}$.

    Use the fact that $[ \type{opposite}, r, r' ] \in Prop_{Tm_{AB}}$ means that $[ \type{opposite}, r, r' ] \in Prop_{Tm_{A}} \setminus Prop_{Tm_{B}}$, $[ \type{opposite}, r, r' ] \in Prop_{Tm_{B}} \setminus Prop_{Tm_{A}}$ or $[ \type{opposite}, r, r' ] \in Prop_{Tm_{A}} \cap Prop_{Tm_{B}}$.

    Show that if $[ \type{opposite}, r, r' ] \in Prop_{Tm_{A}} \setminus Prop_{Tm_{B}}$, then $[ \type{opposite}, r', r ] \in Prop_{Tm_{A}} \setminus Prop_{Tm_{B}}$. And therefore, $[ \type{opposite}, r', r ] \in Prop_{Tm_{AB}}$.

    Also show that if $[ \type{opposite}, r, r' ] \in Prop_{Tm_{B}} \setminus Prop_{Tm_{A}}$, then $[ \type{opposite}, r', r ] \in Prop_{Tm_{B}} \setminus Prop_{Tm_{A}}$. And therefore, $[ \type{opposite}, r', r ] \in Prop_{Tm_{AB}}$.

    Finally, show that if $[ \type{opposite}, r, r' ] \in Prop_{Tm_{A}} \cap Prop_{Tm_{B}}$, then $[ \type{opposite}, r', r ] \in Prop_{Tm_{A}} \cap Prop_{Tm_{B}}$. And therefore, $[ \type{opposite}, r', r ] \in Prop_{Tm_{AB}}$.s
\end{itemize}

The proofs of all these individual properties complete the entire proof.
\end{proof}

As explained before, \cref{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:tmod_combine_correct} does not take into account that the type models are supposed to be distinct except for a set of types. The following lemma is an alternation of the previous theorem, which takes this into account.

\begin{lem}[Consistency of the combination (mostly) distinct of type models]
\label{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:tmod_combine_merge_correct}
Assume that $Tm_A$ and $Tm_B$ are consistent type models in the sense of \cref{defin:formalisations:ecore_formalisation:type_models:type_model_consistency}. Also, ensure that the type models are fully distinct except for a set of types $T$. Furthermore, assume the following properties:
\begin{itemize}
    \item Identifiers used for a class in $Tm_A$ cannot be used for an enumeration type or user-defined data type in $Tm_B$: $\forall c \in Class_{Tm_A}\!: c \not\in Enum_{Tm_B} \land c \not\in UserDataType_{Tm_B}$.
    \item Identifiers used for a class in $Tm_B$ cannot be used for an enumeration type or user-defined data type in $Tm_A$: $\forall c \in Class_{Tm_B}\!: c \not\in Enum_{Tm_A} \land c \not\in UserDataType_{Tm_A}$.
    \item Identifiers used for an enumeration type in $Tm_A$ cannot be used for a class or user-defined data type in $Tm_B$: $\forall c \in Enum_{Tm_A}\!: c \not\in Class_{Tm_B} \land c \not\in UserDataType_{Tm_B}$.
    \item Identifiers used for an enumeration type in $Tm_B$ cannot be used for a class or user-defined data type in $Tm_A$: $\forall c \in Enum_{Tm_B}\!: c \not\in Class_{Tm_A} \land c \not\in UserDataType_{Tm_A}$.
    \item Identifiers from $Tm_A$ may not be in the namespace of an identifier in $Tm_B$: $\forall x \in Class_{Tm_A} \cup Enum_{Tm_A} \cup UserDataType_{Tm_A}; y \in Class_{Tm_B} \cup Enum_{Tm_B} \cup UserDataType_{Tm_B}\!:$\\$x \text{ not in the namespace of } y$
    \item Identifiers from $Tm_B$ may not be in the namespace of an identifier in $Tm_A$: $\forall x \in Class_{Tm_B} \cup Enum_{Tm_B} \cup UserDataType_{Tm_B}; y \in Class_{Tm_A} \cup Enum_{Tm_A} \cup UserDataType_{Tm_A}\!:$\\$x \text{ not in the namespace of } y$
    \item The transitive closure of the inheritance relation is irreflexive: $(Inh_{Tm_A} \cup Inh_{Tm_B})^+$ is irreflexive
    \item For any superclass with an identity, the identity of the subclasses must be a superset of the identity of the superclass: $\forall c_1\ c_2\ A_1\ A_2\!: [ \type{identity}, c_1, A_1 ] \in \mathrm{prop\_\!combine}(Tm_A, Tm_B) \land [ \type{identity}, c_2, A_2 ] \in \mathrm{prop\_\!combine}(Tm_A, Tm_B) \land c_1 \neq c_2\ \land\ !c_1 \not\sqsubseteq_{Tm_A}\ !c_2\ \land\ !c_1 \not\sqsubseteq_{Tm_B}\ !c_2\ \land\ !c_1 \sqsubseteq_{\mathrm{combine}(Tm_A, Tm_B)}\ !c_2 \implies A \subseteq B$
    \item For all shared classes, if $Tm_{A}$ defines a identity, $Tm_{B}$ should define the same identity, and vice versa: $\forall c \in Class_{Tm_A} \cap Class_{Tm_B}\!: [ \type{identity}, c, A ] \in Prop_{Tm_A} \Longleftrightarrow [ \type{identity}, c, A ] \in Prop_{Tm_B}$.
\end{itemize}

Then $\mathrm{combine}(Tm_A, Tm_B)$ is a consistent type model in the sense of \cref{defin:formalisations:ecore_formalisation:type_models:type_model_consistency}.
\isabellelref{tmod_combine_merge_correct}{Ecore.Type_Model_Combination}
\end{lem}

\begin{proof}
Use \cref{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:tmod_combine_correct} to show that $\mathrm{combine}(Tm_A, Tm_B)$ is a consistent type model. Use the assumptions given. Some assumptions of \cref{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:tmod_combine_correct} become irrelevant because $Tm_A$ and $Tm_B$ are mostly distinct.
\end{proof}

Finally, the concept of compatibility between two type models is defined.

\begin{defin}[Compatibility of type models]
\label{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:compatibility}
Assume type models $Tm_A$ and $Tm_B$. We say that $Tm_A$ is compatible with $Tm_B$ if $\mathrm{combine}(Tm_A, Tm_B)$ is a consistent type model in the sense of \cref{defin:formalisations:ecore_formalisation:type_models:type_model_consistency}.
\end{defin}

The notion of compatibility will be used later as a way to denote type models that can be combined with other type models without loss of consistency.


\documentclass{article}
\usepackage{program}
\setlength{\parskip}{1ex}

% Number algorithms separately:
%\newtheorem{algorithm}{Algorithm}

% Number algorithms within sections:
\newtheorem{algorithm}{Algorithm}[section]

% For "floating" algorithms, use:
% \begin{figure}
% \begin{program}
% ...
% \end{program}
% \end{figure}

\begin{document}
\title{A demonstration of the {\tt program} environment}
\author{Martin Ward\\
Centre for Software Maintenance\\
University of Durham}
\maketitle

\tableofcontents

\section{Example with |first_set| and $|first_set|$.}

The {\tt program} style defines two environments, {\tt program} and {\tt
programbox} for typesetting programs and algorithms. Within the program
environment:
\begin{enumerate}
	\item Newlines are significant;
	\item Each line is in math mode, so for example spaces in the input
file are not significant;
	\item The command \verb:\\: within a line causes an extra
linebreak in the output;
	\item The indentation of each line is calculated automatically;
	\item To cause extra indentation, use the commands \verb:\tab: to
set a new tab, and \verb:\untab: to remove it (see the examples below);
	\item Vertical bars are used to delimit long variable names with
underscores (and other unusual characters).
\end{enumerate}

Here is a small program:
\( |first_set|:= \set{x | x^2 + y_1 > 0 } \)
It shows how to typeset mathematics as part of a program. Since each line is
typeset in maths mode, all spacing is done automatically. The set brackets
expand automatically, for example in this program (which also demonstrates the
\verb:\tab: and \verb:\untab: commands):
\begin{program}
t := \set{x | \displaystyle\frac{x}{y} = z};
t := t \setminus u;
z := a \tab {} + b + c + d
	    {} + e + f + g
	    {} + h + i + j; \untab
\IF x = 0 \THEN y :=0 \FI
\end{program}

You can use |variable_names| in text or math mode: $|variable_name|^2 = 2$.
Names can have |odd_characters:!@#$%^&*:;_like_this!|.

Note that \verb:\(: and \verb:\): are redefined to typeset a program in
a minipage. (This is useful in running text, or to keep a short program all on
one page). There is some notation for sequences: \( \seq{x_1,x_2,\dots,x_n} \)
and for universal and existential quantifiers: $ \Forall x. \Exists y. y>x $
(yes, I use these in my programs!)

I often use bold letters to represent program fragments, formulas etc. so
I have set up commands \S{}, \R{} etc. for the most common ones. The
commands have one argument (a subscript, eg \S1, \S2, \S{23}) or a
sequence of ``prime'' characters: \S', \S''''' etc. If you want both a
subscript and one or more primes, then you must use maths mode, eg $\S2'$
Consider the difference between typing \verb:``\S2'': which gives ``\S2'' and
\verb:``$\S2''$'': which gives ``$\S2''$''. Outside maths mode, \verb:\S:
assumes any primes after a subscript are either closing quotes or apostrophes.

Here are two program examples with different indentation styles. Note that
all indentation is calculated automatically in either style:

\noindent
% programbox keeps the program on one page - like parbox
\begin{programbox}
\IF \T1
    \THEN \IF \T2
	      \THEN \IF \T3
			\THEN \S4
			\ELSE \S3
		    \FI
	      \ELSE \S2
	  \FI
    \ELSE \S1
\FI;
% Blank lines are ignored, so you need a ~ on the line
% to get a blank line in the output:
~
\IF \T1 \THEN \IF \T2 \THEN \IF \T3 \THEN \S4
				    \ELSE \S3 \FI
		      \ELSE \S2 \FI
	\ELSE \S1 \FI;
\end{programbox}

Note that \keyword{then} and \keyword{else} should be at the {\em start} of
a line (as in the examples above), not at the end. This is so that you can
line them up in short \keyword{if} statements, for example:
\begin{program}
\IF x=1 \THEN |a_long_procedure_name|(|arg1|, |arg2|, \dots)
	\ELSE |another_long_procedure_name|(|arg1|, |arg2|, \dots) \FI
\end{program}
If the test is long, then you probably want an extra linebreak:
\begin{program}
\IF |a_long_boolean_function_name?|(|arg1|, |arg2|, \dots)
   \THEN |a_long_procedure_name|(|arg1|, |arg2|, \dots)
   \ELSE |another_long_procedure_name|(|arg1|, |arg2|, \dots) \FI
\end{program}
Compare this with the following (which has linebreaks in the ``wrong'' places):
\begin{program}
\IF |a_long_boolean_function_name?|(|arg1|, |arg2|, \dots) \THEN
  |a_long_procedure_name|(|arg1|, |arg2|, \dots)
	\ELSE
  |another_long_procedure_name|(|arg1|, |arg2|, \dots) \FI
\end{program}

Just to show that {\tt\origbar} still works normally to indicate the
placing of vertical lines) in the preamble of a tabular
(or array) environment:

\begin{tabular}{|r|l|} \hline
\bf Statement & \bf Conditions  \\
\hline
\S1     & \B1 \\
\S2     & \B2 \\
\hline
\end{tabular}

\section{Procedures and Functions}

Turning on line numbering here. Also using the algoritm enviroment to number
the algorithms within the sections.
\NumberProgramstrue
\begin{algorithm}
\begin{program}
\label{one}%
\mbox{A fast exponentiation function:} \\ % You can use \mbox for comments
\BEGIN %
  \FOR i:=1 \TO 10 \STEP 1 \DO
     |print|(|expt|(2,i)); \\ |newline|() \OD
\WHERE
\FUNCT |expt|(x,n) \BODY
	  \EXP z:=1;
	       \WHILE n \ne 0 \DO
		  \WHILE |even|(n) \DO
		     n:=n/2; x:=x*x \OD; \label{foo}
		  n:=n-1; z:=z*x \OD;
	       z \ENDEXP \ENDFUNCT
\END\label{last}
\end{program}
\end{algorithm}
First line is line~\ref{one}, last is line~\ref{last}.
Line~\ref{foo} is what makes this function fast!

\begin{algorithm}
\begin{program}
\mbox{A fast exponentiation procedure:}
\BEGIN %
  \FOR i:=1 \TO 10 \STEP 1 \DO
     |expt|(2,i); \\ |newline|() \OD %
\rcomment{This text will be set flush to the right margin}
\WHERE
\PROC |expt|(x,n) \BODY
	  z:=1;
	  \DO \IF n=0 \THEN \EXIT \FI;
	     \DO \IF |odd|(n) \THEN \EXIT \FI;
\COMMENT{This is a comment statement};
		n:=n/2; x:=x*x \OD;
	     \{ n>0 \};
	     n:=n-1; z:=z*x \OD;
	  |print|(z) \ENDPROC
\END
\end{program}
\end{algorithm}

\noindent An action system equivalent to a \keyword{while} loop:
\[
\( \ACTIONS A:
	A \EQ \IF \B{} \THEN \S{}; \CALL A
		       \ELSE \CALL Z \FI \QE
   \ENDACTIONS \)
\EQT
\( \WHILE \B{} \DO \S{} \OD \)
\]
Note the use of \verb:\(: and \verb:\): to enclose the two program boxes.
Turning off line numbers here.
\NumberProgramsfalse

\noindent Dijkstra conditionals and loops:
\begin{program}
\IF x = 1 \AR y:=y+1
\BAR x = 2 \AR y:=y^2
\utdots
\BAR x = n \AR y:=\displaystyle\sum_{i=1}^n y_i \FI

\DO 2 \origbar x \AND x>0 \AR x:= x/2
\BAR \NOT 2 \origbar x    \AR x:= \modbar{x+3} \OD
\end{program}

\noindent Loops with multiple \keyword{exit}s:
\begin{program}
\DO \DO \IF \B1 \THEN \EXIT \FI;
	\S1;
	\IF \B2 \THEN \EXIT(2) \FI \OD;
    \IF \B1 \THEN \EXIT \FI \OD
\end{program}

\noindent I hope you get the idea!

\section{A Reverse Engineering Example}

Here's the original program:
\begin{algorithm}
\begin{program}
 \VAR \seq{m := 0, p := 0, |last| := `` ''};
 \ACTIONS |prog|:
|prog| \ACTIONEQ %
    \seq{|line| := `` '', m := 0, i := 1};
    \CALL |inhere| \ENDACTION
l \ACTIONEQ %
    i := i+1;
    \IF (i=(n+1)) \THEN \CALL |alldone| \FI ;
    m := 1;
    \IF |item|[i] \neq |last|
	\THEN |write|(|line|); |line| := `` ''; m := 0;
	      \CALL |inhere| \FI ;
    \CALL |more| \ENDACTION
|inhere| \ACTIONEQ %
    p := |number|[i]; |line| := |item|[i];
    |line| := |line| \concat `` '' \concat p;
    \CALL |more| \ENDACTION
|more| \ACTIONEQ %
    \IF (m=1) \THEN p := |number|[i];
    |line| := |line| \concat ``, '' \concat p \FI ;
    |last| := |item|[i];
    \CALL l  \ENDACTION
|alldone| \ACTIONEQ |write|(|line|); \CALL Z \ENDACTION \ENDACTIONS \END
\end{program}
\end{algorithm}

And here's the transformed and corrected version:
\begin{algorithm}
\begin{program}
\seq{|line| := `` '', i := 1};
\WHILE i \neq n+1 \DO
  |line| := |item|[i] \concat `` '' \concat |number|[i];
  i := i+1;
  \WHILE i \neq n+1 \AND |item|[i] = |item|[i-1] \DO
    |line| := |line| \concat ``, '' \concat |number|[i]);
    i := i+1 \OD ;
  |write|(|line|) \OD
\end{program}
\end{algorithm}

These are the same programs in a sans-serif style, using the command
\verb:\sfvariables::
\sfvariables
\begin{program}
 \VAR \seq{m := 0, p := 0, |last| := `` ''};
 \ACTIONS |prog|:
|prog| \ACTIONEQ %
    \seq{|line| := `` '', m := 0, i := 1};
    \CALL |inhere| \ENDACTION
l \ACTIONEQ %
    i := i+1;
    \IF (i=(n+1)) \THEN \CALL |alldone| \FI ;
    m := 1;
    \IF |item|[i] \neq |last|
	\THEN |write|(|line|); |line| := `` ''; m := 0;
	      \CALL |inhere| \FI ;
    \CALL |more| \ENDACTION
|inhere| \ACTIONEQ %
    p := |number|[i]; |line| := |item|[i];
    |line| := |line| \concat `` '' \concat p;
    \CALL |more| \ENDACTION
|more| \ACTIONEQ %
    \IF (m=1) \THEN p := |number|[i];
    |line| := |line| \concat ``, '' \concat p \FI ;
    |last| := |item|[i];
    \CALL l  \ENDACTION
|alldone| \ACTIONEQ |write|(|line|); \CALL Z \ENDACTION \ENDACTIONS \END
\end{program}

\begin{program}
\seq{|line|:=`` '', i:=1};
\WHILE i \neq n+1 \DO
  |line| := |item|[i] \concat `` '' \concat |number|[i];
  i := i+1;
  \WHILE i \neq n+1 \AND |item|[i] = |item|[i-1] \DO
    |line| := |line| \concat ``, '' \concat |number|[i]);
    i := i+1 \OD ;
  |write|(|line|) \OD
\end{program}

\end{document}


\begin{appendices}

\section{\sne~magnitude}

\begin{figure}[htbp]
\begin{center}
  \includegraphics[width=0.9\textwidth]{LC_faint.png}
 \caption{Magnitude as a function of time and redshift for a faint type Ia supernovae and for $g$ (top), $r$ (middle) and $i$ (bottom) bands.}\label{fig:lcfaint}
\end{center}
\end{figure}

\begin{figure}[htbp]
\begin{center}
  \includegraphics[width=0.9\textwidth]{LC_medium.png}
 \caption{Magnitude as a function of time and redshift for a medium type Ia supernovae and for $g$ (top), $r$ (middle) and $i$ (bottom) bands.}\label{fig:lcmedium}
\end{center}
\end{figure}

\begin{figure}[htbp]
\begin{center}
  \includegraphics[width=0.9\textwidth]{LC_bright.png}
 \caption{Magnitude as a function of time and redshift for a bright type Ia supernovae and for $g$ (top), $r$ (middle) and $i$ (bottom) bands.}\label{fig:lcbright}
\end{center}
\end{figure}

\section{Illustration of the method}
\begin{figure}[htbp]
\begin{center}
  \includegraphics[width=0.8\textwidth]{procedure.png}
 \caption{Illustration of the method used to estimate saturation effects. To each LC simulated point (first row) corresponds a seeing (second row) from which a factor corresponding to the highest fraction of energy deposited in a pixel is estimated (third row). We multiply this factor by the exposure time (here 15s) and the flux to estimate (fourth row) the highest signal deposited (in pe) in a pixel.  LC points corresponding to saturation are removed if their fluxes are greater or equal the ccd full well ((red dotted line; 90 kpe).}\label{fig:method}
\end{center}
\end{figure}

\section{Saturation effects on flux distribution}

\begin{figure}[htbp]
\begin{center}
  \includegraphics[width=0.9\textwidth]{Flux_faint.png}
 \caption{Saturation effect on flux distribution for a faint \sne. Flux fraction variations as a function of the redshift are given for $gri$ bands and four (exposure time, full well) configurations: (15s, 90k \pe) (top left),  (15s, 120k \pe) (top right), (30s, 90k \pe) (bottom left),  (30s, 120k \pe) (bottom right). All LC points have been considered to draw full lines. Dotted lines correspond to the case where saturated fluxes have been removed in the estimation (median values).}\label{fig:fluxfaint}
\end{center}
\end{figure}

\begin{figure}[htbp]
\begin{center}
  \includegraphics[width=0.9\textwidth]{Flux_bright.png}
  \caption{Saturation effect on flux distribution for a bright \sne. Flux fraction variations as a function of the redshift are given for $gri$ bands and four (exposure time, full well) configurations: (15s, 90k \pe) (top left),  (15s, 120k \pe) (top right), (30s, 90k \pe) (bottom left),  (30s, 120k \pe) (bottom right). All LC points have been considered to draw full lines. Dotted lines correspond to the case where saturated fluxes have been removed in the estimation (median values).}\label{fig:fluxbright}

\end{center}
\end{figure}
\newpage
\section{Saturation effects on Signal-to-Noise Ratio}

\begin{figure}[htbp]
\begin{center}
  \includegraphics[width=0.9\textwidth]{SNR_faint.png}
 \caption{Saturation effect on Signal-to-Noise Ratio for a faint \sne. SNR (normalized to SNR values estimated without saturation included) variations as a function of the redshift are given for $gri$ bands and four (exposure time, full well) configurations: (15s, 90k \pe) (top left),  (15s, 120k \pe) (top right), (30s, 90k \pe) (bottom left),  (30s, 120k \pe) (bottom right),}\label{fig:snrfaint}
\end{center}
\end{figure}

\begin{figure}[htbp]
\begin{center}
  \includegraphics[width=0.9\textwidth]{SNR_bright.png}
 \caption{Saturation effect on Signal-to-Noise Ratio for a bright \sne. SNR (normalized to SNR values estimated without saturation included) variations as a function of the redshift are given for $gri$ bands and four (exposure time, full well) configurations: (15s, 90k \pe) (top left),  (15s, 120k \pe) (top right), (30s, 90k \pe) (bottom left),  (30s, 120k \pe) (bottom right),}\label{fig:snrbright}
\end{center}
\end{figure}
\newpage
\section{Saturation effects on \colorerr}

\begin{figure}[htbp]
\begin{center}
  \includegraphics[width=0.9\textwidth]{sigmac_faint.png}
 \caption{Saturation effect on \colorerr~for a faint \sne. \colorerr~variations as a function of the redshift are given for $gri$ bands and four (exposure time, full well) configurations: (15s, 90k \pe) (top left),  (15s, 120k \pe) (top right), (30s, 90k \pe) (bottom left),  (30s, 120k \pe) (bottom right). Dotted lines correspond to median values if LC saturated points are removed from \colorerr~estimation. Full lines correspond to the case where all LC points are considered (median values).}\label{fig:sigmafaint}
\end{center}
\end{figure}

\begin{figure}[htbp]
\begin{center}
  \includegraphics[width=0.9\textwidth]{sigmac_bright.png}
 \caption{Saturation effect on \colorerr~for a bright \sne. \colorerr~variations as a function of the redshift are given for $gri$ bands and four (exposure time, full well) configurations: (15s, 90k \pe) (top left),  (15s, 120k \pe) (top right), (30s, 90k \pe) (bottom left),  (30s, 120k \pe) (bottom right). Dotted lines correspond to median values if LC saturated points are removed from \colorerr~estimation. Full lines correspond to the case where all LC points are considered (median values).}\label{fig:sigmabright}
\end{center}
\end{figure}

\end{appendices}


%!TEX root = fastZKP.tex
\section{Preliminaries}
\label{sec::prelim}

\subsection{Notation}

In this paper, we use $\lambda$ to denote the security parameter, and $\neg(\lambda)$ to denote the negligible function in $\lambda$. ``PPT" stands for probabilistic polynomial time. We use $f(),h()$ for polynomials, $x,y,z$ for vectors of variables and $g,u,v$ for vectors of values. $x_i$ denotes the $i$-th variable in $x$. We use bold letters such as $\textbf{A}$ to represent arrays. For a multivariate polynomial $f$, its "variable-degree" is the maximum degree of $f$ in any of its variables.

\paragraph{Bilinear pairings.} Let $\mathbb{G}, \mathbb{G}_T$ be two groups of prime order $p$ and let $g\in\mathbb{G}$ be a generator. $e: \mathbb{G}\times\mathbb{G}\rightarrow\mathbb{G}_T$ denotes a bilinear map and we use $\mathsf{bp}=(p,\mathbb{G},\mathbb{G}_T,e,g)\leftarrow\mathsf{BilGen}(1^\lambda)$ for the generation of parameters for the bilinear map. Our scheme relies on the $q$-Strong Bilinear Diffie-Hellman ($q$-SBDH) assumption and an extended version of the Power Knowledge of Exponent (PKE) assumption. We present the assumptions formally in Appendix~\ref{app:assume}.

\subsection{Interactive Proofs and Zero-knowledge Arguments}

\paragraph{Interactive proofs.} An interactive proof allows a prover $\P$ to convince a verifier $\V$ the validity of some statement. The interactive proof runs in several rounds, allowing $\V$ to ask questions in each round based on $\P$'s answers of previous rounds. We phrase this in terms of $\P$ trying to convince $\V$ that $f(x)=1$. The proof system is interesting only when the running time of $\V$ is less than the time of directly computing the function $f$. We formalize interactive proofs in the following:
\begin{definition}\label{def:ip}
	Let $f$ be a Boolean function. A pair of interactive machines $\langle\mathcal{P}, \mathcal{V}\rangle$ is an interactive proof for $f$ with soundness $\epsilon$ if the following holds:
	\begin{itemize}
		\item {\bf Completeness.} For every $x$ such that $f(x) = 1$ it holds that $\Pr[\langle\mathcal{P}, \mathcal{V}\rangle(x)=accept]=1$.
		\item {\bf $\epsilon$-Soundness.} For any $x$ with $f(x) \neq 1$ and any $\mathcal{P}^*$ it holds that $\Pr[\langle\mathcal{P^*},\mathcal{V}\rangle=accept] \le \epsilon$
	\end{itemize}
\end{definition}

\paragraph{Zero-knowledge arguments.} An argument system for an NP relationship $R$ is a protocol between a computationally-bounded prover $\P$ and a verifier $\V$. At the end of the protocol, $\V$ is convinced by $\P$ that there exists a witness $w$ such that $(x; w) \in R$ for some input $x$. We focus on arguments of knowledge which have the stronger property that if the prover convinces the verifier of the statement validity, then the prover must know $w$. We use $\mathcal{G}$ to represent the generation phase of the public key $\pk$ and the verification key $\vk$. Formally, consider the definition below, where we assume $R$ is known to $\P$ and $\V$.

\begin{definition}\label{def::zkp}

	Let $R$ be an NP relation. A tuple of algorithm $(\mathcal{G}, \mathcal{P}, \mathcal{V})$ is a zero-knowledge argument for $R$ if the following holds.

	\begin{itemize}

		\item \textbf{Correctness}. For every $(\pk, \vk)$ output by $\mathcal{G}(1^\lambda)$ and $(x, w) \in R$,
		$$\langle \P(\pk, w), \V(\vk) \rangle(x) = \accept$$
		%\babis{should not $R$ be given as input to prover and verifier?}
		\item \textbf{Soundness}. For any PPT prover $\P$, there exists a PPT extractor $\varepsilon$ such that for every $(\pk, \vk)$ output by $\mathcal{G}(1^\lambda)$ and any $x$, it holds that

		$$\Pr[\langle\P(\pk), \V(\vk) \rangle(x) = \accept \wedge (x, w) \notin R | w \leftarrow \varepsilon(\pk, x)] \leq \neg(\lambda)$$
		%\babis{should not $\mathcal{G}$ appear somewhere in the soundnesss definition here?}
		\item \textbf{Zero knowledge}. There exists a PPT simulator $\S$ such that for any PPT adversary $\A$, auxiliary input $z \in \{0, 1\}^{\mathsf{poly}(\lambda)}$, $(x;w)\in R$, it holds that\\
		%{\footnotesize
		$\Pr\left[\langle\P(\pk,w),\A\rangle=\accept: (\pk,\vk)\leftarrow\mathcal{G}(1^\lambda); (x,w)\leftarrow\A(z,\pk,\vk) \right] = $\\
		$\Pr\left[\langle\S(\mathsf{trap}, z, \pk),\A\rangle=\accept:(\pk,\vk,\mathsf{trap})\leftarrow\S(1^\lambda); (x,w)\leftarrow\A(z,\pk,\vk)\right]$\\
		%}
%\babis{small fontsize looks ugly...}
		%where $=$ means perfect zero knowledge \babis{this is weird. = means = probabilities. What you probably want to say is that when the probabilities are equal then the protocol is perfect zero-knowledge}.

	\end{itemize}
	We say that $(\mathcal{G},\P,\V)$ is a \textbf{succinct} argument system if the
	running time of $\V$ and the total communication between $\P$ and $\V$ (proof size) are $\mathsf{poly}(\lambda,|x|,\log|w|)$.
\end{definition}

\input{CMT}
\input{zkvpd}


\documentclass[12pt]{cdblatex}
\usepackage{fancyhdr}
\usepackage{footer}

\begin{document}

% ============================================================================================
\section*{Example 14 The Weyl tensor is conformally invariant}

\CdbSetup{action=hide}

\begin{cadabra}
   {a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,u,v,w#}::Indices (position=independent).

   \partial{#}::PartialDerivative.

   g_{a b}::Metric.
   g^{a b}::InverseMetric.
   g_{a}^{b}::KroneckerDelta.

   def check (objA,objB):

       tmp := @(objA) - @(objB).

       distribute     (tmp)
       sort_product   (tmp)
       rename_dummies (tmp)
       canonicalise   (tmp)

       return tmp

   import cdblib

   # ---------------------------------------------
   check000A = cdblib.get ('check000','expected/example-14.json')
   check001A = cdblib.get ('check001','expected/example-14.json')

   # ---------------------------------------------
   check000B = cdblib.get ('check000','output/example-14.json')
   check001B = cdblib.get ('check001','output/example-14.json')

   # ---------------------------------------------
   diff000 = check (check000A,check000B)   # cdb (ex-14.diff000,diff000)
   diff001 = check (check001A,check001B)   # cdb (ex-14.diff001,diff001)

\end{cadabra}

% \clearpage

\begin{dgroup*}
   \Dmath*{\cdb*{ex-14.diff000}}
   \Dmath*{\cdb*{ex-14.diff001}}
\end{dgroup*}

\end{document}