%!TEX root = da2020-12.tex

\Chapter{12}{Conclusions}

\noindent
We have reached the end of this course. In this chapter we will review what we have learned, and we will also have a brief look at what else is there in the field of distributed algorithms. The exercises of this chapter form a small research project related to the distributed complexity of locally verifiable problems.

\section{What Have We Learned?}

By now, you have learned a new mindset\mydash an entirely new way to think about computation. You can reason about distributed systems, which requires you to take into account many challenges that we do not encounter in basic courses on algorithms and data structures:
\begin{itemize}
    \item Dealing with \emph{unknown systems}: you can design algorithms that work correctly in any computer network, no matter how the computers are connected together, no matter how we choose the port numbers, and no matter how we choose the unique identifiers.
    \item Dealing with \emph{partial information}: you can solve graph problems in sublinear time, so that each node only sees a small part of the network, and nevertheless the nodes produce outputs that are globally consistent.
    \item Dealing with \emph{parallelism}: you can design highly parallelized algorithms, in which several nodes take steps simultaneously.
\end{itemize}
These skills are in no way specific to distributed algorithms\mydash they play a key role also in many other areas of modern computer science. For example, dealing with unknown systems is necessary if we want to design \emph{fault-tolerant} algorithms, dealing with partial information is the key element in e.g.\ \emph{online algorithms} and \emph{streaming algorithms}, and parallelism is the cornerstone of any algorithm that makes the most out of modern \emph{multicore CPUs}, \emph{GPUs}, and \emph{computing clusters}.

\section{What Else Exists?}

Distributed computing is a vast topic and so far we have merely scratched the surface. This course has focused on what is often known as \emph{distributed graph algorithms} or \emph{network algorithms}, and we have only focused on the most basic models of distributed graph algorithms. There are many questions related to distributed computing that we have not addressed at all; here are a few examples.

\subsection{Distance vs.\ Bandwidth vs.\ Local Memory}

Often we would like to understand computation in two different kinds of distributed systems:
\begin{enumerate}
  \item \emph{Geographically distributed networks}, e.g.\ the Internet. A key challenge is large distances and communication latency: some parts of the input are physically far away from you, so in a fast algorithm you have to act based on the information that is available in your local neighborhood.
  \item \emph{Big data systems}, e.g.\ data processing in large data centers. Typically all input data is nearby (e.g.\ in the same local-area network). However, this does not make problems trivial to solve fast: individual computers have a limited \emph{bandwidth} and limited amount of \emph{local memory}.
\end{enumerate}
The $\LOCAL$ model is well-suited for understanding computation in networks, but it does not make much sense in the study of big data systems: if all information is available within one hop, then in $\LOCAL$ model it would imply that everything can be solved in one communication round!

\paragraph{Congested Clique Model.}

Many other models have been developed to study big data systems. From our perspective, perhaps the easiest to understand is the \emph{congested clique} model \cite{Lotker2005,Lenzen2013,Dolev2012}. In brief, the model is defined as follows:
\begin{itemize}
  \item We work in the $\CONGEST$ model, as defined in Chapter~\chapterref{5}.
  \item We assume that the underlying graph $G$ is the complete graph on $n$ nodes, i.e., an $n$-clique. That is, every node is within one hop from everyone else.
\end{itemize}
Here it would not make much sense to study graph problems related to $G$ itself, as the graph is fixed. However, here each node $v$ gets some local input $f(v)$, and it has to produce some local output $g(v)$. The local inputs may encode e.g.\ some input graph $H \ne G$ (for example, $f(v)$ indicates which nodes are adjacent to $v$ in $H$), but here it makes also perfect sense to study other computational problem that are not related to graphs. Consider, for example, the task of computing the matrix product $X = AB$ of two $n \times n$ matrices $A$ and $B$. Here we may assume that initially each node knows one column of $A$ and one column of $B$, and when the algorithms stops, each node has to hold one column of $X$.

\paragraph{Other Big Data Models.}

There are many other models of big data algorithms that have similar definitions\mydash{}all input data is nearby, but communication bandwidth and/or local memory is bounded; examples include:
\begin{itemize}[noitemsep]
  \item \emph{BSP model} (bulk-synchronous parallel)~\cite{Valiant1990},
  \item \emph{MPC model} (massively parallel computation)~\cite{Karloff2010}, and
  \item \emph{$k$-machine model}~\cite{Klauck2015}.
\end{itemize}
Note that when we limit the amount of local memory, we also implicitly limit communication bandwidth (you can only send what you have in your memory). Conversely, if you have limited communication bandwidth and a fast algorithm, you do not have time to accumulate a large amount of data in your local memory, even if it was unbounded. Hence all of these model and their variants often lead to similar algorithm design challenges.

\subsection{Asynchronous and Fault-Tolerant Algorithms}

So far in this course we have assumed that all nodes start at the same time, computation proceeds in a synchronous manner, and all nodes always work correctly.

\paragraph{Synchronization.}

If we do not have any failures, it turns out we can easily adapt all of the algorithms that we have covered in this course also to asynchronous settings. Here is an example of a very simple solution, known as the \emph{$\alpha$-synchronizer} \cite{Awerbuch1985}: all messages contain a piece of information indicating ``this is my message for round $i$'', and each node first waits until it has received all messages for round $i$ from its neighbors before it processes the messages and switches to round $i+1$.

\paragraph{Crash Faults and Byzantine Faults.}

Synchronizers no longer work if nodes can fail. If we do not have any bounds on the relative speeds of the communication channels, it becomes impossible to distinguish between e.g.\ a node behind a very slow link and a node that has \emph{crashed}.

Failures are challenging even if we work in a synchronous setting. In a synchronous setting it is easy to tell if a nodes has crashed, but if some nodes can misbehave in an arbitrary manner, many seemingly simple tasks become very difficult to solve. The term \emph{Byzantine failure} is commonly used to refer to a node that may misbehave in an arbitrary manner, and in the quiz (Section~\ref{sec:quiz12}) we will explore some challenges of solving the \emph{consensus problem} in networks with Byzantine nodes.

\paragraph{Self-Stabilization.}

Another challenge is related to consistent initialization. In our model of computing, we have assumed that all nodes are initialized by using the $\Init_{A,d}$ function. However, it would be great to have algorithms that converge to a correct output even if the initial states of the nodes may have been corrupted in an arbitrary manner. Such algorithms are called \emph{self-stabilizing} algorithms \cite{Dolev2000}.

If we have a deterministic $T$-time algorithms $A$ designed in the $\LOCAL$ model, it can be turned into a self-stabilizing algorithm in a mechanical manner \cite{lenzen09local-self-stab}: all nodes keep track of $T$ possible states, indicating ``what would be my state if now was round $i$'', they send vectors of $T$ messages, indicating ``what would be my message for round $i$'', and they repeatedly update their states according to the messages that they receive from their neighbors. However, if we tried to do something similar for a randomized algorithm, it would no longer converge to a fixed output\mydash{}there are problems that are easy to solve with randomized Monte Carlo $\LOCAL$ algorithms, but difficult to solve with self-stabilizing algorithms.

\subsection{Other Directions}

\paragraph{Shared Memory.}

Our models of computing can be seen as a \emph{message-passing system}: nodes send messages (data packets) to each other. A commonly studied alternative is a system with \emph{shared memory}: each node has a shared register, and the nodes can communicate with each other by reading and writing the shared registers.

\paragraph{Physical Models.}

Our models of computing are a good match with systems in which computers are connected to each other by physical wires. If we connect the nodes by wireless links, the \emph{physical properties of radio waves} (e.g., reflection, refraction, multipath propagation, attenuation, interference, and noise) give rise to new models and new algorithmic challenges. The \emph{physical locations} of the nodes as well as the properties of the environment become relevant.

\paragraph{Robot Navigation.}

In our model, the nodes are active computational entities, and they cannot move around in the network\mydash they can only send information around in the network. Another possibility is to study computation with autonomous agents (``robots'') that can move around in the network. Typically, the nodes are passive entities (corresponding to possible physical locations), and the robots can communicate with each other by e.g.\ leaving some tokens in the nodes.

\paragraph{Nondeterministic Algorithms.}

Just like we can study nondeterministic Turing machines, we can study nondeterministic distributed algorithms. In this setting, it is sufficient that there exists a \emph{certificate} that can be verified efficiently in a distributed setting; we do not need to construct the certificate efficiently. Locally verifiable problems that we have studied in this course are examples of problems that are easy to solve with nondeterministic algorithms.

\paragraph{Complexity Measures.}

For us the main complexity measure has been the number of synchronous communication rounds. Many other possibilities exist: e.g., how many messages do we need to send in total?

\paragraph{Practical Aspects of Networking.}

This course has focused on the theory of distributed algorithms. There is of course also the practical side: We need physical computers to run our algorithms, and we need networking hardware to transmit information between computers. We need modulation techniques, communication protocols, and standardization to make things work together, and good software engineering practices, programming languages, and reusable libraries to keep the task of implementing algorithms manageable. In the real world, we will also need to worry about privacy and security. There is plenty of room for research in computer science, telecommunications engineering, and electrical engineering in all of these areas.

\subsection{Research in Distributed Algorithms}

There are two main conferences related to the theory of distributed computing:
\begin{itemize}
    \item PODC, the ACM Symposium on Principles of Distributed Computing:
    \url{https://www.podc.org/}
    \item DISC, the International Symposium on Distributed Computing:
    \url{http://www.disc-conference.org/}
\end{itemize}
The proceedings of the recent editions of these conferences provide a good overview of the state-of-the-art of this research area.

\section{Quiz}\label{sec:quiz12}

In the \emph{binary consensus problem} the task is this: Each node gets 0 or 1 as input, and each node has to produce 0 or 1 as output. All outputs must be the same: you either have to produce all-0 or all-1 as output. Moreover, if the input is all-0, your output has to be all-0, and if the input is all-1, your output has to be all-1. For mixed inputs either output is fine.

Your network is a complete graph on 5 nodes; we work in the usual $\LOCAL$ model. You are using the following 1-round algorithm:
\begin{itemize}
  \item Each node sends its input to all other nodes. This way each node knows all inputs.
  \item Each node applies the majority rule: if at least 3 of the 5 inputs are 1s, output 1, otherwise output 0.
\end{itemize}

This algorithm clearly solves consensus if all nodes correctly follow this algorithm. Now assume that node 5 is controlled by a \emph{Byzantine adversary}, while nodes 1--4 correctly follow this algorithm. Show that now this algorithm \emph{fails} to solve consensus among the correct nodes 1--4, i.e., there is some input so that the adversary can force nodes 1--4 to produce \emph{inconsistent} outputs (at least one of them will output 0 and at least one of them will output 1).

Your answer should give the inputs of nodes 1--4 (4 bits), the messages sent by node 5 to nodes 1--4 (4 bits), and the outputs of nodes 1--4 (4 bits). An answer with these three bit strings is sufficient.

\section{Exercises}

In Exercises \ref{ex:cycle-trivial}--\ref{ex:cycle-speedup} we use the tools that we have learned in this course to study \emph{locally verifiable problems} in cycles in the $\LOCAL$ model (both deterministic and randomized). For the purposes of these exercises, we use the following definitions:

A locally verifiable problem $\Pi = (\Sigma, \collC)$ consists of a finite alphabet $\Sigma$ and a set $\collC$ of allowed \emph{configurations} $(x,y,z) \colon x,y,z \in \Sigma$. An assignment $\varphi \colon V \to \Sigma$ is a \emph{solution} to $\Pi$ if and only if for each node $u$ and its two neighbors $v, w$ it holds that
\[
  \bigl(\varphi(v), \varphi(u), \varphi(w)\bigr) \in \collC\ \ \text{or}\ \ \bigl(\varphi(w), \varphi(u), \varphi(v)\bigr) \in \collC.
\]
Put otherwise, if we look at any three consecutive labels $x,y,z$ in the cycle, either $(x,y,z)$ or $(z,y,x)$ has to be an allowed configuration.

You can assume in Exercises \ref{ex:cycle-trivial}--\ref{ex:cycle-speedup} that the value of $n$ is known (but please then make the same assumption consistently throughout the exercises, both for positive and negative results).

\begin{ex}[trivial and non-trivial problems] \label{ex:cycle-trivial}
  We say that a locally verifiable problem $\Pi_0 = (\Sigma_0, \collC_0)$ is \emph{trivial}, if $(x,x,x) \in \collC_0$ for some $x \in \Sigma_0$.
  We define that \emph{weak $c$-coloring} is the problem $\Pi_1 = (\Sigma_1, \collC_1)$ with
  \begin{align*}
    \Sigma_1 &= \{1,2,\dots,c\}, \\
    \collC_1 &= \bigl\{ (x_1, x_2, x_3) \bigm| x_1 \neq x_2 \text{ or } x_3 \neq x_2 \bigr\}.
  \end{align*}
  That is, each node must have at least one neighbor with a different color.
  \begin{subex}
    \item Show that if a problem is trivial, then it can be solved in constant time.
    \item Show that if a problem is not trivial, then it is at least as hard as weak $c$-coloring for some $c$.
    \hint{Show that if a problem is not trivial, then each configuration must use a distinct adjacent label.}
  \end{subex}
\end{ex}

\begin{ex}[hardness of weak coloring] Consider the weak $c$-coloring problem, as defined in Exercise~\ref{ex:cycle-trivial}.
  \begin{subex}
    \item Show that weak 2-coloring can be solved in cycles in $O(\log^* n)$ rounds.
    \item \label{item:weak-c-col} Show that weak $c$-coloring, for any $c = O(1)$, requires $\Omega(\log^* n)$ rounds in cycles. \hint{Give an algorithm for turning a weak $c$-coloring into a 3-coloring in $O(c)$ rounds.}
  \end{subex}
   What does this imply about the possible complexities of locally verifiable problems in cycles?
\end{ex}

\begin{ex}[randomized constant time]
  Show that if a locally verifiable problem $\Pi$ can be solved in constant time in cycles with a randomized $\LOCAL$-algorithm, then it can be solved in constant time with a deterministic $\LOCAL$-algorithm.
  \hint{Use an argument to boost the failure probability of a constant-time randomized algorithm. A constant-time algorithm cannot depend on the size of the input. Consider a network $N$ such that a randomized algorithm succeeds with probability $p < 1$. Boost this by considering the same algorithm on network $N'$ that consists of many copies of $N$.}
\end{ex}

\begin{ex}[deterministic speed up]\label{ex:cycle-speedup}
  Assume that there is a deterministic algorithm $A$ for solving problem $\Pi$ in cycles with a running time $T(n) = o(n)$. Show that there exists a deterministic algorithm $A'$ for solving $\Pi$ in $O(\log^* n)$ rounds.

  What does this imply about the possible complexities of locally verifiable problems in cycles?
  \hint{Use a similar argument as in Exercise~11.4. In this case we want a speedup simulation in the $\LOCAL$ model, so we also need to simulate the identifiers. Color the network so that the colors look locally like unique identifiers. Then simulate algorithm $A$ using the colors instead of real identifiers.

  Since $A$ runs in time $o(n)$, we can find a \emph{constant} $n_0$ such that $T(n_0) \ll n_0$. On any network with $n > n_0$ nodes, find a coloring with $n_0$-colors such that two nodes with the same color have distance at least $2T(n_0)+3$. Show that this can be done in $O(\log^* n)$ rounds. Then run $A$ on $N$, using the coloring instead of unique identifiers. Show that this simulation can be done in constant time. Show that this simulation is correct in every 1-neighborhood.}
\end{ex}

\begin{exss}
  Prove or disprove: vertex coloring with $\Delta+1$ colors in graphs of maximum degree $\Delta$ can be solved in $O(\log \Delta + \log^* n)$ rounds in the $\LOCAL$ model.
  \hint{This is an open research question.}
\end{exss}

\section{Bibliographic Notes}

The exercises in this chapter are inspired by Chang and Pettie \cite{Chang2019}.


%\miabs
%\vspace{4cm}
\section*{Abstract}
Public regulatory agencies have traditionally granted access to radio-electric spectrum through fixed, long term licenses for large geographical areas.
The increasing demand of wireless communication has led to an almost fully assigned spectrum.
However, it is sparsely and unevenly used.
A dramatic improvement on spectrum usage efficiency is possible through the operation of cognitive radios, capable of gathering information about their surrounding spectrum environment and adapting their transmission parameters accordingly.
Cognitive radios allow unlicensed users to dynamically exploit unused fragments of spectrum.
% Dynamic spectrum access parece ser el termino mas aceptado para describir a todos los mecanismos de coexistencia
Our main concern in this work is protecting licensed users from interferences caused by unlicensed users' transmissions, and creating incentives for the licensed networks to implement mechanisms easing the coexistence with unlicensed users.
Another important guideline of our work is the focus on low-complexity algorithms that can operate at the small time-scale of the spectrum opportunities. %Este claim es dificil de soportar, porque no tenemos estudios serios de computational overhead de ningun algoritmo.
This thesis emphasizes the use of mathematical tools such as stochastic modeling, dynamic programming, reinforcement learning, among others, in the development of mechanisms for dynamic spectrum access.
The first part of this thesis focuses on Opportunistic Spectrum Access (OSA), proposing schemes that simultaneously increase spectrum efficiency and improve the protection of primary users.
The developed mechanisms do not require direct signaling between the primary and the secondary devices.
In the second part, we focus on incentives, by developing two frameworks for spectrum trading, in which the licensed users can lease unused bandwidth to unlicensed ones, in exchange of money and relay services, respectively. We also include an extensive survey on the topic, unique in its scope.


    \filetitle{=\#}{Mark an equation for exact non-linear simulation}{modellang/exactnonlin}

	\paragraph{Syntax}\label{syntax}

\begin{verbatim}
LHS =# RHS;
\end{verbatim}

\paragraph{Description}\label{description}

Equations that have the equal sign marked with an \texttt{\#} can be
simulated in an exact non-linear mode.

Why is it the channels sign, \texttt{\#}, that is used to mark the
equations for exact non-linear simulations? Because if you associate
your model file extension with the Matlab editor, the channel signs are
displayed red making it easier to spot them.


\section{Binary positive and non negative integers : NArith}\label{NArith}

Here are defined various arithmetical notions and their properties,
similar to those of {\tt Arith}.


\chapter{Radical and Polynomial Operations}

\section{Unit 1}


\chapter{Conclusion}

This chapter evaluates parts of the methodology and findings of the project.
With specific reference to individual components, it examines what should have been done differently.
It closes with a presentation of suitable directions for future work,
especially regarding research questions thrown up and still unanswered by the present work.

\subsection{Evaluation}
\subsubsection{Interpreter}
We often treat terms generically: we are not specifically interested in the form of the term.
For example the $M$ and $N$ in the term $M[N/x]$ are generic.
Generic terms like this were used extensively in the soundness and completeness proofs for the \lmu\ translation.
A minor extension to the interpreter would be to extend it with the constants.
Like a value, the evaluation of a constant would leave the constant the same.
This extension would allow the expression of these generic terms.
In this way, the output of the interpreter could have been used to produce proofs without requiring amendments.
Additionally,
the interpreter could have output \LaTeX\ by writing an appropriate function of type \mono{State -> String} to pass into the evaluation engine.

\subsubsection{Choice of Calculus}
CDC was not the correct choice of calculus to facilitate a translation from \ltry\ to Haskell.
It was chosen because it easily facilitated a translation to Haskell:
the syntax of CDC was intentionally close to Haskell
and a CDC library had been implemented in Haskell by the authors of the calculus.
However there is an impedance mismatch between CDC and \lmu.
The translation does not use most of the expressive power of CDC.
For example,
CDC is capable of generating multiple prompts of different names.
Only a single prompt is used by the translation of the \lmu-calculus.
We do not need a continuation stack or multiple named prompts, we just need a single delimiter.
We could get away with a map from prompts to contexts in place of a stack.
This would have greatly simplified the translation although it would also require reimplementing the CDC operators.
We believe this would be useful to develop in follow up work.

\subsubsection{Direct Translation}
There is possible a more direct translation of \ltry\ to CDC that is not mediated by a translation to \lmu.
More importantly, there is likely to be a more direct implementation of \ltry\ to Haskell.
By translating through two other calculi, we have left this possibility unexamined.
Although we still would want a direct implementation of \ltry\ in Haskell that does not use CDC,
we have demonstrated that an implementation is possible and laid down the ground work for this to be done.

%\subsubsection{Types}
%We did not investigate whether types were preserved by the translation.
%
%The typing of CDC terms is left to Haskell.
%A formal treatment would have been better.

\subsubsection{Translation and Soundness}
The embedding of the \lmu-calculus in CDC is not as close to the \lmu-calculus as it could be.
There are some reduction steps in the destination language that are not reflected by the source language.
Specifically, the soundness property we proved was
\[
  M \to_{`m} N \Rightarrow \exists P. \tr{M} \to^{*} P \land \tr{N} \to^{*} P
\]
This says that the translation of $M$ and the translation of the $`m$-reduction of $M$ reduce to the same term.
By defining the substitition of terms explicitly, as in \cite{Bakel14}, we may have proved
\[
  M \to_{`m}^{*} N \Rightarrow \tr{M} \to^{*} \tr{N}
\]
This says that the translation of $M$ reduces to the translation of $N$.
With this property, the correspondence between the source language and the target language would have be closer.

\subsection{Conclusion}
We defined an interpreter for CDC which we used to experiment with translations from the \lmu-calculus.
The output of the interpreter was transliterated into derivations that we used to prove the soundness and completeness of our translation.
Using this translation, along with van Bakel's \ltry-to-\lmu\ translation, we defined a translation from \ltry\ to CDC.
This was used as the basis for some proof-of-concept \ltry\ implementations in Haskell.
This project presents a clear demonstration that named exceptions, as introduced by the \ltry-calculus, are implementable in Haskell.
Apart from a minor syntactic extension,
the implementation would not require any machinery currently unavailable to Haskell.

\subsubsection{Future Work}
Finally, we present a list of suitable directions for future work.
\begin{itemize}
  \item \emph{Type preservation} -- Both \ltry\ and \lmu\ have type assignment systems. We did not explore whether the types are preserved under the translations we defined. Doing this is will give additional insight into how the \ltry\ calculus relates to delimited continuations and how it can be implemented in Haskell without using CDC.
  \item \emph{Haskell extension} -- Proof-of-concept Haskell libraries are presented and a language extension is proposed but the language extension is not implemented. Given the state of the present work, this will be trivial. By exposing the functionality in a language pragma, we will extend the parser with additional grammar rules.
  \item \emph{Reimplement CDC without stack} -- The implementation of \lmu\ in CDC only ever uses a single prompt: CDC is overengineered for the purposes of a \lmu-translation. We will rewrite CDC to replace the context and prompt stack with a mapping from prompts to contexts. Using this, a simpler translation of \lmu\ to CDC should be found.
  \item \emph{Translate \ltry\ directly into Haskell} -- The current methodology helped expand our understanding of the relation of \ltry\ to Haskell. Using this, we can write a direct implementation of \ltry\ into Haskell that bypasses CDC entirely.
\end{itemize}


\chapter{Variables and Constants}  % 5
\label{sec_variables}

\section{Declaration and Specification of Variables and Constants}  % 5.1

Upon its execution, a PEARL program uses and modifies integers, floating
point numbers, bit strings, character strings, times and durations.
These data occur in form of constants or as values of variables.
Constants are identified by their notations and keep their values during
the entire program execution. Variables denote data (their values) which
can change during the program execution.

Generally, the value range of a variable is limited to a single kind of data,
e.g. bit strings, which determines the type of the variable (Bit string
variables have only bit strings as values, e.g.). This type has to be
defined with its identifier, when declaring or specifying a
variable.

Example:

\begin{lstlisting}
/* declaration of a variable switch of type bit string of length 1 */
DECLARE switch BIT;

/* specification of a global variable status of type bit string
of length 16 */
SPECIFY status BIT(16) GLOBAL(otherModule);
\end{lstlisting}

A variable denotes {\it one} data element, e.g. {\it one} integer, {\it
one} bit string, etc.; in the following, such scalar variables are
treated. The possibilities to summarise scalar variables to arrays and
structures are described in \ref{sec_array} and \ref{sec_struct}.

When declaring a variable, its type has to be given in a type attribute;
if different variables with the same type attribute are to be declared,
this can take place in form of a list in a declaration, e.g., by

\kw{DECLARE} \code{(x,y,z)} \kw{FLOAT};

the three variables \code{x}, \code{y}, and \code{z} are
 declared with the type attribute
\code{FLOAT}.  For simpler notation, different declarations may be formulated
in a declaration by separating them by commas:

\begin{lstlisting}
DECLARE x FLOAT,
        i FIXED;
\end{lstlisting}

Summarised, scalar variables can be declared as follows:

\begin{grammarframe}
\input{ScalarVariableDeclaration.bnf}
\index{DCL@\textbf{DCL}!Scalar Variable}

\input{ScalarDeclareDataSentence.bnf}

%%%IdentifierDenotation ::=\\
%%%\x Identifier $\mid$ (Identifier [ , Identifier ] $^{...}$ )

\input{TypeAttribute.bnf}

\input{SimpleType.bnf}
\end{grammarframe}

The general form of specifying scalar variables reads as follows:

\begin{grammarframe}
\input{ScalarVariableSpecification.bnf}
\index{SPC@\textbf{SPC}!Scalar Variable}

\input{VariableDenotationS.bnf}
\end{grammarframe}

Allocation protection and initialisation attribute are described in
\ref{sec_inv},
identification and global attributes were already defined
in \ref{sec_dcl_and_spc} and \ref{sec_references_module}.

Subsequently, the different type possibilities are presented; variables
of type Sema, Bolt, Interrupt or Signal are considered in
\ref{sec_task_sync}, \ref{sec_interrupts} and
\ref{sec_input_output}.

\section{Integers (FIXED)}   % 5.2
\label{sec_type_fixed}
\index{FIXED@\textbf{FIXED}}

Integers can be written in decimal or dual representation. The decimal
representation of an integer consists of a sequence of decimal digits. The dual
representation consists of a sequence of the digits 0 and 1, terminated
with character B.

Examples:

\begin{tabular}{rrr}
integer & decimal pres. & dual pres. \\
      6 &             6 &     110B \\
    123 &           123 & 1111011B
\end{tabular}

Furthermore, the precision of the representation can be defined for a
numerical constant by noting the number of bit positions, in which it
shall be represented computer internally without signs, in brackets behind
the numerical constant.

Example: \code{123(31)} \x Integer 123 is presented in 31 bit positions.

If no precision is given for a constant,
the precision is derived from the %%%%constants.
corresponding \code{LENGTH} specification.

Variables for integers are declared with the type attribute \code{FIXED}.
\begin{grammarframe}
\input{TypeFixed.bnf}
\input{Precision.bnf}
\end{grammarframe}

The precision gives the number of bit positions in which the
corresponding value of the variable (without signs) is represented. If
the precision declaration is lacking, the precision defined in a length
specification (see \ref{sec_length}) is inserted.
%%% \removedtext{Usual precisions are 15 or 31.}

%%%\begin{added}
\OpenPEARL{} assumes that \code{FIXED} values are stored in
the two's-complement representation.
The lengths from 0 to 63 are supported.
All operations are monitored for successful operation.
In case of a range violations the signal \code{FixedRangeSignal} is induced.
In case of divide by zero or reminder by zero the signal
\code{FixedDivideByZeroSignal}
is induced.
%%%\end{added}

Example:

\begin{lstlisting}
DCL counter FIXED(31),
    (i,j,k) FIXED;
...
i := 2;
\end{lstlisting}

\section{Floating Point Numbers (FLOAT)}  % 5.3
\label{sec_type_float}
\index{FLOAT@\textbf{FLOAT}}

Constants for floating point numbers can be represented as a sequence of
\begin{enumerate}
\item a point, an integer and possibly an exponent to the basis 10,
where an exponent consists of a sequence of the character E, possibly a
plus or minus sign, and an integer

\begin{tabbing}
Example: \= .123E-1 xx \=  \kill
Example: \> .123 \> (corresponds to 0.123)\\
 \> .123E2 \> (corresponds to 12.3)\\
 \> .123E-1 \> (corresponds to 0.0123)
\end{tabbing}

\item an integer followed by a sequence given in 1.

Example: 3.123E2 (corresponds to 312.3)

\item an integer, a point, and possibly an exponent

Example: 3. (corresponds to 3.0)

\item an integer and an exponent

Example: 3E-2 (corresponds to 0.03)
\end{enumerate}

Analogously to integers, even constants for floating point numbers can
be defined with precision.

Variables of type floating point number (with integers or floating point
numbers as values) are declared with type attribute \code{FLOAT}.

%%% TypeFloatingPointNumber renamed into TypeFloat
\begin{grammarframe}
\input{TypeFloat.bnf}
\end{grammarframe}

%%%The statements of 5.2 are valid;

%%%\removedtext{usual precisions are here 23 and 53, respectively.}
%%%\begin{added}
\OpenPEARL{} supports the lengths 23 and 52 according the IEEE-754
standard.
All operations are monitored for successful operation.
In case of range violations or
divide by zero the result is set to INF (infinity) and
\code{FloatIsINFSignal} is induced.
In case of operations leading to NaN (not a number) the signal
\code{FloatIsNaNSignal} is induced.
The default preset value of \code{FLOAT} values is NaN, which will produce
the \code{FloatIsNaNSignal} when used without prior assignment.

The precision for float literals is derived in the priority from:
\begin{enumerate}
\item the given precision like 1.0(52)
\item the \code{LENGTH} statement
\item the default value is given in table \ref{tab_default_length}
\end{enumerate}
%%%\end{added}

Example:

\begin{lstlisting}
DCL (x,y,z) ,
     koeff FLOAT(52);
...
x:=3.5; y:=1; koeff:=3.14E-10;
\end{lstlisting}

\section{Bit Strings (BIT)}  % 5.4
\label{sec_bit_strings}
\index{BIT@\textbf{BIT}}

A bit string constant can be given in binary form (\code{B1}), in form of
tetrades (\code{B2}), octades (\code{B3}), or in hexadecimal form (\code{B4}).

The form Bi (i=1,...,4) consists of an apostrophe, a sequence of
\begin{itemize}
\item digits 0 and 1 in case \code{B1}
\item digits 0 to 3 in case \code{B2}
\item digits 0 to 7 in case \code{B3}
\item digits 0 to 9 and letters A to F in case \code{B4}
\end{itemize}
followed by an apostrophe and the corresponding attribute \code{B1} or
\code{B2} or \code{B3} or \code{B4}.

Example:

\begin{tabular}{rl}
\code{'110010100111'B1} & corresponds to\\
      \code{'302213'B2} & corresponds to\\
        \code{'6247'B3} & corresponds to\\
         \code{'CA7'B4} & \\
\end{tabular}

Instead of \code{B1}, \code{B} can be written in a shorter way.
 The following tables
show the assignment between the binary form and the other forms:

\begin{tabular}{cc@{\hspace{2cm}}cc@{\hspace{2cm}}cc@{\hspace{1cm}}cc}

B2 & B1 & B3 & B1  & B4 & B1   & B4  & B1\\
0  & 00 & 0  & 000 & 0  & 0000 & 8 & 1000 \\
1  & 01 & 1  & 001 & 1  & 0001 & 9 & 1001 \\
2  & 10 & 2  & 010 & 2  & 0010 & A & 1010 \\
3  & 11 & 3  & 011 & 3  & 0011 & B & 1011 \\
   &    & 4  & 100 & 4  & 0100 & C & 1100 \\
   &    & 5  & 101 & 5  & 0101 & D & 1101 \\
   &    & 6  & 110 & 6  & 0110 & E & 1110 \\
   &    & 7  & 111 & 7  & 0111 & F & 1111 \\
\end{tabular}

Variables for bit strings are to be declared with type attribute \code{BIT}.

\begin{grammarframe}
\input{TypeBitString.bnf}

%%% rename length --> LengthOfString
\input{LengthOfString.bnf}
\end{grammarframe}

Length gives the number of elements of the bit string. If the length
option is lacking, it had either to be defined in a length
definition (see \ref{sec_length}), or 1 is assumed as length.

Example:

\begin{lstlisting}
DCL xCoord BIT(2),
    yCoord BIT(8);
...
xCoord:='01'B;
yCoord:= 'A9'B4;
\end{lstlisting}

The addressing of parts of bit strings is treated in
\ref{sec_expressions}, Expressions.

%%%\begin{added}
\OpenPEARL{} supports all lengths from 1 to 64.
In case of selecting a slice which is not part of the bit string, the
signal \code{BitIndexOutOfRangeSignal} is induced.
%%%\end{added}

\section{Character Strings (CHARACTER)}  % 5.5
\label{sec_char_strings}
\index{CHAR@\textbf{CHAR}}
\index{CHARACTER@\textbf{CHARACTER}|see {CHAR}}

A character string constant consists of an apostrophe, a sequence of any
characters (besides of apostrophe) and an apostrophe.

Example: \code{'fault no.: '}

If, however, the character string has to contain an apostrophe, it has
to be represented by two subsequent apostrophes.

Example: \code{'fault''no.: '}

Control characters can be inserted into character string constants with
the help of the switch symbols \code{'\textbackslash} and
\code{\textbackslash'}.
 The control characters are given as pairs of sedecimal digits.

Examples:

\begin{lstlisting}[emphstyle=\ttfamily]
'This string '\ 0D 0A \' contains two control characters'
''\1B\' control character at the start of the string'
'control character at the end of the string'\00\''
''\00\'' /* string consisting of one single control character */
\end{lstlisting}

Example: Note that '20'B4 is the code of the space character

\begin{lstlisting}
'By changing over to the control character sequence'\20
\' very long character string constants'\20
\' can be created (independently from the used editor).'
\end{lstlisting}

Variables for character strings are declared by the type attribute
\code{CHARACTER}.

\begin{grammarframe}
\input{TypeCharacterString.bnf}
\end{grammarframe}

Length gives the number of characters. If no length is indicated, it had
either to be defined in a length specification (see \ref{sec_length}) or length 1 is
assumed.

Examples:

\begin{lstlisting}
DCL articleIdentificator CHAR(6);
...
articleIdentificator:='BCD/27';
\end{lstlisting}

The addressing of parts of character strings is treated in
 \ref{sec_expressions}, Expressions.

%%%\begin{added}
\OpenPEARL{} supports all lengths from 1 to 32767.
All operations are monitored:
In case defining a \code{CHAR} variable with more than 32767 elements the
\code{CharacterTooLongSignal} is induced.
In case of selecting a slice which is not part of the \code{CHAR} variable the
\code{CharacterIndexOutOfRangeSignal} is induced.
%%%\end{added}

\section{The Length Definition}   % 5.6
\label{sec_length}
\index{LENGTH@\textbf{LENGTH}}

With the length definition, the precisions and lengths for such
number and string objects are defined, whose precisions and lengths are
not determined by notation (for constants) or declaration (for
variables).

\begin{grammarframe}
\input{LengthDefinition.bnf}
\end{grammarframe}

Example:

\begin{lstlisting}
PROBLEM;
   LENGTH FIXED(15);
   LENGTH FLOAT(52);
   DCL a  FIXED,       /* A is of type FIXED(15) */
       x  FLOAT,       /* X is of type FLOAT(52) */
       y  FLOAT(23);   /* Y is of type FLOAT(23) */
    ...
\end{lstlisting}

For a length definition, the same validity rules are valid as for
variable declarations (see 4.3, Block Structure).

%%%%% added
The default length for the data types is shown in table \ref{tab_default_length}.

\begin{table}[bpht]
\begin{center}
\begin{tabular}{|l|r|}
\hline
Type & default length \\
\hline
\code{FIXED} & 31 \\
\hline
\code{FLOAT} & 23 \\
\hline
\code{CHAR} & 1 \\
\hline
\code{BIT} & 1 \\
\hline
\end{tabular}
\end{center}
\caption{Default length of the data types in OpenPEARL}
\label{tab_default_length}
\end{table}

\section{Times (CLOCK)}   % 5.7
\label{sec_type_clock}
\index{CLOCK@\textbf{CLOCK}}

A time constant consists of a positive integer to state the hour, an
integer between 0 and 59 for the minute, and a floating point number
between 0 and 59.999... for the second --- separated by a colon, each.
The hour is interpreted modulo 24.

Example:

\begin{tabbing}
\code{11:30:00} \x \= means 11.30\\
\code{15:45:3.5}   \> means 15.45 and 3.5 seconds\\
\code{25:00:00}    \> means 1.00
\end{tabbing}

Variables for times are declared with type attribute \code{CLOCK}.

\begin{grammarframe}
\input{TypeClock.bnf}
\end{grammarframe}

Example:

\begin{lstlisting}
DCL time CLOCK;
...
time:=12:30:00;
\end{lstlisting}

%%%\begin{added}
\OpenPEARL{} provides a resolution for \code{CLOCK} values of $1\mu s$
\index{CLOCK@\textbf{CLOCK}!Resolution}
%%%\end{added}

\section{Durations (DURATION)}   % 5.8
\label{sec_type_duration}
\index{DURATION@\textbf{DURATION}|see {DUR}}
\index{DUR@\textbf{DUR}}
\index{DUR@\textbf{DUR}!\textbf{HRS}}
\index{DUR@\textbf{DUR}!\textbf{MIN}}
\index{DUR@\textbf{DUR}!\textbf{SEC}}
\index{HRS@\textbf{HRS}}
\index{MIN@\textbf{MIN}}
\index{SEC@\textbf{SEC}}

A duration constant is composed of stating an hour, a minute, and a
second, however, single pieces of specifications may be lacking. An hour
is given by an integer and the character sequence \code{HRS}, a minute by an
integer and the character sequence \code{MIN}, a second by a floating point
number and the character sequence \code{SEC}.

Examples:

\begin{tabbing}
\code{5} \kw{MIN} \code{30} \kw{SEC} \= means 5 minutes and 30 seconds \\
\code{.05} \kw{SEC}            \> means 50 milliseconds \\
\code{5} \kw{HRS} \code{10} \kw{SEC} \> means 5 hours and 10 seconds
\end{tabbing}

The integers and floating point numbers in time constants must not
contain precision specifications.

Variables for durations have to be declared with the type attribute
\code{DURATION} or \code{DUR}.

\begin{grammarframe}
\input{TypeDuration.bnf}
\end{grammarframe}

Example:

\begin{lstlisting}
DCL delay DUR;
...
delay:=0.1 SEC;
\end{lstlisting}

%%%\begin{added}
\OpenPEARL{} provides a resolution for \code{DURATION} values of $1\mu s$
\index{DUR@\textbf{DUR}!Resolution}
and
a range of $\approx \pm 100 days$ \index{DUR@\textbf{DUR}!Range}.
In case of an arithmetic overflow in calculations with durations, the
\code{DurationValueSignal} is induced.
In case of division by a duration or numeric value of zero,
the \code{DurationDivideByZeroSignal} is induced.
%%%\end{added}

\section{References (REF)}  % 5.9
\label{sec_references}
\index{REF@\textbf{REF}}

For the indirect addressing, so-called reference variables (pointer
variables, pointers) are provided in PEARL. Reference variables have the
names of variables as values (they point at variables). Analogously to
the variables introduced up to now, the value range of a reference
variable is limited to a type of variables given when declaring the
reference variables (see, however, \ref{sec_struct}, Interference of Data
Structures).

The value of a reference variable, the referenced variable, is referred
to with the help of the monadic operator \code{CONT} (``content''); this
process is called ``dereferentiation''.

Examples:

\begin{lstlisting}
DCL (k,l) FIXED,
    x  FLOAT
    (rk1,rk2) REF FIXED,  /* fixed reference variable */
    rx  REF FLOAT;        /* float reference variable */
rk1:=k;                   /* rk1 points at k */
rk1:=l;                   /* rk1 points at l */
rk2:=rk1;                 /* rk2 points at l, pointer assignment */
rx:=x;                    /* rx points at x */
rx:=k;                    /* wrong, type unequal */
rx:=rk1;                  /* wrong, type unequal */
l:=2;
k:=CONT rk1;              /* k obtains value 2 */
rk2:=3;                   /* wrong, 3 is no variable */
CONT rk2:=3;              /* l obtains value 3 */
CONT rk2:=k;              /* l obtains value 2 */
\end{lstlisting}

Instead of \code{k:=CONT rk1}, \code{k:=rk1}
 can be written in a simpler way; i.e.,
operator \code{CONT} may be omitted on the right side of an assignment
(``implicit dereferentiation'').

In general, it holds:

%%%\begin{front}
%%%TypeReference ::=\\
%%%\x {\bf REF} [ VirtDimensionList ] [ AssignmentProtection ]\\
%%%\x \{ SimpleType $\mid$ Identifier\S ForType $\mid$ TypeStructure $\mid$\\
%%%\x \x TypeDation $\mid$ {\bf SEMA $\mid$ BOLT $\mid$ INTERRUPT $\mid$ IRPT $\mid$ SIGNAL $\mid$} \\
%%%\x \x TypeProcedure $\mid$ {\bf TASK} $\mid$ TypeVOID $\mid$ {\bf CHAR}()\\
%%%\x \}
%%%
%%%VirtDimensionList ::=\\
%%%\x ( [ , $^{...}$ ] )
%%%
%%%Dereferentiation ::=\\
%%%\x {\bf CONT} Name\S ReferenceVariable
%%%
%%%\end{front}
\begin{grammarframe}
\input{TypeReference.bnf}
\input{VirtualDimensionList.bnf}
\input{Dereferentiation.bnf}
\index{CONT@\textbf{CONT}}
\end{grammarframe}

%%%\begin{added}
The lifetime of the referenced object must be longer or equal as
the lifetime of the reference object.
%%%\end{added}

The definition of the language form \hlink{TypeReference} shows, which type a
variable may have, at which a reference variable shall point.
Particularly, reference variables may also point at arrays and
structures (cf. \ref{sec_array} and \ref{sec_struct}).
 The number n of commas in the virtual
dimension list states that the referenced variable is an (n + 1)
dimensional array. On the other hand, reference variables must not point
at reference variables; referenced arrays and structures, however, may
possess reference variables as elements and components. This can be
used, e.g., to interlink structures, or to build up lists in general.
Section \ref{sec_type}, Type Definition, gives an example for that.

\hlink{TypeStructure} and \hlink{TypeDation} are defined in \ref{sec_type} and
\ref{sec_dation_problem_part}, \hlink{TypeProcedure} and
\code{TASK} in \ref{sec_ref_proc} and \ref{sec_ref_task},
%%% TypeVOID
 and \code{REF CHAR()} in
%%%\ref{sec_type_void} and
 \ref{sec_ref_char}.

If a reference variable R points at an array F with elements F
(i,j,k,...) or at a structure S with components S.Ki, the elements of F
or the components of S are addressed (taking R as starting-point) with R
(i,j,k,...) or R.Ki without using \code{CONT}.

Furthermore, a reference variable is dereferentiated implicitly,
\begin{itemize}
\item if it is the actual parameter of a procedure call, and if the
formal parameter belonging to it is no reference variable.
\item if it is used as operand of a dyadic operator, as far as the
latter is not defined for values of reference variables like \code{IS} (see
below).
\end{itemize}

Example:

\begin{lstlisting}
DCL rk REF FIXED,
    k  FIXED;
 ...
rk:=k; k:=2;
k:=rk+1;        /* equivalent     k:=k+1; */
\end{lstlisting}

E.g., to mark the end of a %%%%string,
linked list a reference variable \code{NIL} (zero
pointer) is provided, possessing a certain, constant value.

To compare the values of reference variables, the dyadic operators \code{IS}
 or
\code{ISNT} can be used; \code{IS} (\code{ISNT}) provides the result
 \code{'1'B} (\code{'0'B}), if both the
given reference variables points to the same (different) object(s),
otherwise it provides the result \code{'0'B} (\code{'1'B}).

Example:

\begin{lstlisting}
                ! TypeOrder is an application specific TYPE
DCL nextOrder REF TypeOrder;
...
IF nextOrder IS NIL THEN
 ...
FIN;
\end{lstlisting}

\subsection{Variable Character String Pointers (REF CHAR())}  % 5.9.1
\label{sec_ref_char}
\index{REF CHAR@\textbf{REF CHAR}}

Variably long character strings can easily be processed with special
pointer objects, so-called variable character string pointers.

Example: Declarations of variable character string pointers

\begin{lstlisting}
DCL strPtr REF CHAR();                 /* pointer declaration */
SPC print f PROC (REF CHAR()) GLOBAL;  /* pointer as parameter */
\end{lstlisting}

A pointer of type \code{REF CHAR ()} contains, besides of the address of a
character string, two counters storing the maximum length and the
actually used length of the referenced character string variable. When
assigning the address of a character string variable to a variable
character string pointer, both counters are initialised with the length
of the referenced character string variable.

Example: Initalisation of a variable character string pointer

\begin{lstlisting}
DCL s1      CHAR(20);
DCL s2      CHAR(100);
DCL strPtr REF CHAR}();
strPtr:=s1;               /* adr=s1, length=20, max=20 */
strPtr:=s2;               /* adr=s2, length=100, max=100 */
\end{lstlisting}

Thus, the variable pointer differs at first not from a character string
pointer with constant length. When assigning to the character string
variable via this pointer, the length of the assigned character string,
however, is stored in the counter for the actual length, and the
otherwise usual filling of the character string with blanks up to the
maximum length is omitted.

Example: Assignment to the referenced variable

\begin{lstlisting}
strPtr:=s1;                    /* adr=s1, length=20, max=20 */
CONT strPtr:='OpenPEARL';      /* adr=s1, length=9, max=20 */

strPtr:=s2;                    /* adr=s2, length=100, max=100 */
CONT strPtr:='HS Furtwangen';  /* adr=s2, length=13, max=100 */
\end{lstlisting}

For the subsequent accesses to the character string via this pointer,
only the actual length is used.

Example:

\begin{lstlisting}
DCL s1 CHAR(20);
DCL s2 CHAR(100);            /* filler */
DCL strPtr REF CHAR();       /* variable pointer */

strPtr:=s2:                  /* adr=s2, length=100, max=100 */
CONT strPtr:='D78120 ' CAT 'Furtwangen';  /* adr=s2, length=17,
                                              max=100 */
s1 := CONT strPtr;
\end{lstlisting}

After this assignment, the variable \code{s2} contains the characters
\code{'D78120 Furtwangen'} in the first 17 positions, the other characters
were not changed by the assignment. The length index of \code{'strPtr'} was
set to the actual length 17.

For the  assignment to \code{s1}, \code{CONT strPtr} generates
 the character string
value \code{'D78120 Furtwangen'} (with type \code{CHAR(17)}).
 Due to the assignment
rules of PEARL, the character string is extended by three blanks, before
this value is assigned to variable \code{s1} (with type \code{CHAR(20)}).

Variable character string pointers turn out particularly useful as
formal parameters of procedures. Apart from the address of a character
string variable, the compiler passes its actual length at the call
position.  Thus, e.g. an error routine can give out error texts of
different length.

Example: Character string pointer as parameters

\begin{lstlisting}
SPC printError PROC (REF CHAR()) GLOBAL};
DCL s1 CHAR(20)  INIT('...');
DCL s2 CHAR(100) INIT('...');

...
CALL printError (s1);
CALL printError (s2);
\end{lstlisting}

Even character string constants may be passed, if the formal parameter
was defined with type \code{REF INV CHAR()}.

Example:

\begin{lstlisting}
SPC printMessage PROC (REF INV CHAR()) GLOBAL;

...
CALL printMessage ('text 1');
CALL printMessage ('longer text 2');
\end{lstlisting}

A variable character string pointer can be used in all expressions
analogously to constant character string pointers. The length check
belonging to the type check takes first place at run time.

A variable character string pointer is not allowed as result value of a
function. Type \code{CHAR()} may only be used in combination with \code{REF},
i.e., parameter type \code{CHAR() IDENT} is not allowed.

\section{Arrays}   % 5.10
\label{sec_array}

If possible, objects of the same kind are summarised in
one identifier, and the various objects are addressed with indices.

%%%\begin{added}
The value of all indices must be within the range, otherwise
an IndexOutOfRangeSignal is induced.
Each index value must fit into \code{FIXED(31)}.
%%%\end{added}

Example:

An embedded controller controls three devices G(1), G(2), and G(3). For
the output of the bit string '0001'B to the controller, G(1) shall be
switched on, device G(2) for '0010'B, and device G(3) for '0100'B. Here it
suggests itself to summarise the three switch-on signals under one
identifier, e.g., \code{switchOn}, and to address them with indices:

\begin{lstlisting}
DCL switchOn(1:3) BIT(4),
    i             FIXED;
...
switchOn(1):='0001'B;
switchOn(2):='0010'B;
switchOn(3):='0100'B;
...
/* taking over value of i (index of the device to be switched on)
   from another program part the indicated device may be switched
   on via the usage of switchOn(i) */
\end{lstlisting}

In general, scalar variables
%%%\begin{added}
 or structs
%%%\end{added}
of the same type can be combined into
n-dimensional arrays (n=1,2,3,...).

When declaring the array, an identifier is assigned to it; the various
array elements (scalar variables) are addressed under this identifier
and the definition of their positions within the array (the index).

Thus, with the help of

\kw{DCL} \code{koeff(1:2, 0:3)} \kw{FIXED};

a 2-dimensional array is declared, where the first dimension has the
lower boundary 1 and the upper boundary 2, i.e., length 2, whereas the
second dimension has the lower boundary 0 and the upper boundary 3,
i.e., length 4.  This means that \code{koeff} consists of the 8 scalar fixed
variables

\code{koeff(1,0)} \x \code{koeff(1,1)} \x
    \code{koeff(1,2)} \x \code{koeff(1,3)} \\
\code{koeff(2.0)} \x \code{koeff(2,1)} \x
    \code{koeff(2,2)} \x \code{koeff(2,3)}

The general form of a array declaration reads as follows:

\begin{grammarframe}
\input{ArrayDeclaration.bnf}
\index{DCL@\textbf{DCL}!Array}
\input{ArrayDenotation.bnf}
\input{TypeAttributeForArray.bnf}
\input{DimensionAttribute.bnf}
\input{DimensionBoundaries.bnf}
\end{grammarframe}

Thus, even negative integers are allowed as dimension boundary. The
upper boundary of a dimension, however, has always to be greater or
equal its lower boundary.

If the lower boundary is not given, value 1 is assumed for it.
%%%\begin{removed}
%%% By a named constant, a variable of type FIXED(15)
%%% is understood, declared with assignment protection (INV)
%%% and initial value (INIT).
%%%\end{removed}
%%%For details about named constants see chapter \ref{sec_named_constants}.

Examples:

\begin{lstlisting}
DCL switchOn(3)   BIT(4),
    koeff(2, 0:3) FIXED,
    message(20)   CHAR(12);
\end{lstlisting}

The one-dimensional array message contains e.g. 20 error texts, so that,
in the case of error \code{i}, a program can pass the \code{message(i)}
 to a console
(i=1,...,20).

Arrays can also be declared mixed with scalar variables in a declaration,
e.g.:

\begin{lstlisting}
DCL numberOfMessages  INV FIXED(15)  INIT(20);
 ...

DCL message (numberOfMessages) CHAR(12),
    (i,j,k)                    FIXED,
    (switchOn, switchOff)(3)   BIT(4);
\end{lstlisting}

The general specification form of an array reads:

\begin{grammarframe}
\input{ArraySpecification.bnf}
\index{SPC@\textbf{SPC}!Array}
\input{ArrayDenotationS.bnf}
\input{VirtualDimensionList.bnf}
\end{grammarframe}

The number n of commas in the virtual dimension attribute informs that
the specified array has n+1 dimensions.

In section \ref{sec_data_types_usability} of the appendix it is described
 in tabular form, which objects may be combined to arrays.

\section{Structures}   % 5.11
\label{sec_struct}
\index{STRUCT@\textbf{STRUCT}}

Arrays allow to combine scalar variables of the {\it same} type under
one identifier; the various variables are addressed by this identifier
and their indices.

For many automation problems, especially for those with dispositive
character, however, data structures have to be described, whose
components have {\it different} types.

Example:

The contributions for the TV news of one day are stored on magnetic
tapes (VTR); the contribution sequence of a certain news broadcast of
that day is composed by the editors with the help of a computer
controlling the corresponding VTR. For this, a data set is necessary for
each contribution with, e.g. the following structure:

\begin{itemize}
\item identity label of the contribution
\item archive number
\item notes whether the contribution already was broadcast in the first,
second or third news broadcast of that day
\item initial position of the contribution on the tape
\item end position of the contribution on the tape
\item notes whether original sound is available
\item length of the text to be stored, if needed
\item a text to be stored, if needed
\end{itemize}

Such data structures can be described in a problem oriented way as
structures; the above structure  \code{contribution}, e.g., is declared as
follows:

\begin{lstlisting}
DCL contribution STRUCT
       [ (identNo, archive) FIXED,
         alreadyBroadcast(3) BIT(1),
         (start, end) FIXED,
         originalSound BIT(1),
         textLength FIXED,
         text CHAR(200)
       ];
\end{lstlisting}

%%%\begin{removed}
%%%(A structure is encapsulated in square brackets; they are printed boldly in
%%%the text to distinguish them from the meta-linguistic characters ``[''
%%%and ``]''. When writing down the program, only square brackets or their
%%%substitutional symbols ``(/'' and ``/)'' are used.)
%%%\end{removed}

In contrast to array elements, the components of a structure are not
addressed via the joint identifier and an index, but via the joint
identifier and the identifier denoted in their declaration, where both
identifiers are separated by a full-stop.

Example:

By the statement

\code{contribution.start := 1027;}

value 1027 is assigned to the component \code{Start} of structure
\code{Contribution}.

As the declaration of contribution shows, components of structures may be
arrays; as usual, the array elements are then addressed with their
indexed identifier preceded by the structure identifier, such as in the
form

\kw{IF} \code{contribution.alreadyBroadcast(i)} \kw{THEN}...\kw{FIN}\code{;}

A structure component, however, can also be a structure itself, so that not only
linear, but also hierarchical data structures can be modeled.

Example:

A staff file shall contain descriptions of the staff members; these
descriptions each have the structure shown in Figure~\ref{mitarbeiter}.
\newpage

\begin{figure}
\setlength{\unitlength}{0.00087500in}%
\begin{picture}(4377,2735)(46,-2103)
\thicklines
\put(676,-736){\line( 1, 0){900}}
\put(1351,389){\line( 0,-1){2475}}
\put(1351,-2086){\line( 1, 0){225}}
\put(1351,-1636){\line( 1, 0){225}}
\put(1351,389){\line( 1, 0){225}}
\put(2386,389){\line( 1, 0){765}}
\put(3376,614){\line(-1, 0){225}}
\put(3151,614){\line( 0,-1){450}}
\put(3151,164){\line( 1, 0){225}}
\put(2566,-736){\line( 1, 0){810}}
\put(3376,-286){\line(-1, 0){225}}
\put(3151,-286){\line( 0,-1){900}}
\put(3151,-1186){\line( 1, 0){225}}
\put( 46,-826){\makebox(0,0)[lb]{\smash{\SetFigFont{12}{14.4}{rm}Person}}}
\put(1711,-826){\makebox(0,0)[lb]{\smash{\SetFigFont{12}{14.4}{rm}Address}}}
\put(1711,-1726){\makebox(0,0)[lb]{\smash{\SetFigFont{12}{14.4}{rm}Sex}}}
\put(3466,524){\makebox(0,0)[lb]{\smash{\SetFigFont{12}{14.4}{rm}FirstName}}}
\put(3466,
74){\makebox(0,0)[lb]{\smash{\SetFigFont{12}{14.4}{rm}SecondName}}}
\put(3511,-376){\makebox(0,0)[lb]{\smash{\SetFigFont{12}{14.4}{rm}Street}}}
\put(3466,-826){\makebox(0,0)[lb]{\smash{\SetFigFont{12}{14.4}{rm}PostCode}}}
\put(3511,-1276){\makebox(0,0)[lb]{\smash{\SetFigFont{12}{14.4}{rm}Town}}}
\put(1666,-2076){\makebox(0,0)[lb]{\smash{\SetFigFont{12}{14.4}{rm}\ldots}}}
\put(1711,299){\makebox(0,0)[lb]{\smash{\SetFigFont{12}{14.4}{rm}Name}}}
\end{picture}
\caption{\label{mitarbeiter}}
\end{figure}

The components Name and Address are structures themselves, namely
substructures of the main structure \code{person}
 which can be declared as follows:

\begin{lstlisting}
DCL person STRUCT
       [ name STRUCT
            [ firstName  CHAR(10),
              secondName CHAR(15),
            ],
         address STRUCT
            [ street   CHAR(15),
              areaCode FIXED,
              town     CHAR(15)
            ],
         sex CHAR(1)
         ...
       ];
...
\end{lstlisting}

Therefore, substructures can be addressed via their identifier and the
preceding identifiers of the respective higher level structures.

The type of a structure is determined by the arrangement of its components
and their types. Structures of the same type can be combined into arrays:

\kw{DCL} \code{contribution(20)} \kw{STRUCT}...\code{;}  /* see above */

Thus, any component of a structure is generally addressed with its (if
needed, indexed) identifier and the (if needed, indexed) identifiers of
all higher level structures, where the names are separated by a full-stop,
each.

Example:

\begin{lstlisting}
person.name.firstName := 'OTTO';
IF contribution(i).alreadyBroadcast(j) THEN...FIN;
\end{lstlisting}

The general form of the structure declaration reads:

\begin{grammarframe}
\input{StructureDeclaration.bnf}
\index{DCL@\textbf{DCL}!Structure}
\input{StructureDenotation.bnf}

\input{TypeStructure.bnf}

\input{StructureComponent.bnf}

\input{TypeAttributeInStructureComponent.bnf}
\end{grammarframe}

The general form of the structure specification reads:

\begin{grammarframe}
\input{StructureSpecification.bnf}
\index{SPC@\textbf{SPC}!Structure}
\input{StructureDenotationS.bnf}
\end{grammarframe}

\section{Type Definition (TYPE)} % 5.12
\label{sec_type}
\index{TYPE@\textbf{TYPE}}

A certain structure, e.g., can occur as parameter, as substructure in other
structures, or as type of the transmission data of a data station.  Each
time, the type of this structure must be stated, which might cause
extensive writing effort for complex structures. For that reason, and to
increase the readability of the program, the type of a structure can be
defined as new data type under a freely selectable identifier, and used
under this identifier, e.g., to declare variables of this data type.

Example:
%%%\begin{enumerate}
%%%\item
\begin{lstlisting}
PROBLEM;
  ...
  TYPE Message STRUCT
         [ (identNo, archive) FIXED,
           alreadyBroadcast(3) BIT(1),
           (start, end) FIXED,
           originalSound BIT(1),
           textLength FIXED,
           text CHAR(200)
         ];

   DCL contentVTR DATION INOUT Message ...;

coord: TASK;
   DCL contribution Message;
   ...
   READ contribution FROM contentVTR;
   ...
END; ! coord
...
\end{lstlisting}
%%%\item A task controls certain devices; it receives the control orders
%%%from another task. Since occasionally more than one order can be
%%%existing and the orders can be of different urgency, they are buffered
%%%in form of a queue. Let the structure of the orders be of the (re-defined)
%%%type OrderType; let this even contain the urgency criteria for
%%%arranging new orders. The reference variables Next\_Order and Free,
%%%respectively, as shown in Figure~\ref{kette}, point at the order to be treated next or the next free position
%%%in the queue order string, respectively; starting with Free, let the free
%%%positions be interlinked as well. Let the queue be not longer than 10
%%%elements.
%%%
%%%
%%%\begin{figure}
%%%\setlength{\unitlength}{0.0007500in}%
%%%\begin{picture}(7539,2889)(124,-2110)
%%%\thicklines
%%%\put(451,-1411){\framebox(1035,1350){}}
%%%\put(2071,-1411){\framebox(1035,1350){}}
%%%\put(3646,-1411){\framebox(1035,1350){}}
%%%\put(6121,-1411){\framebox(1035,1350){}}
%%%\thinlines
%%%\put(451,-961){\line( 1, 0){1035}}
%%%\put(946,-1276){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}Succ}}}
%%%\put(901,-421){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}Order}}}
%%%\put(901,-781){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}\ldots}}}
%%%\put(2071,-961){\line( 1, 0){1035}}
%%%\put(2566,-1276){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}Succ}}}
%%%\put(2521,-421){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}Order}}}
%%%\put(2521,-781){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}\ldots }}}
%%%\put(3646,-961){\line( 1, 0){1035}}
%%%\put(4141,-1276){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}Succ}}}
%%%\put(4096,-421){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}Order}}}
%%%\put(4096,-781){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}\ldots }}}
%%%\put(6121,-961){\line( 1, 0){1035}}
%%%\put(6616,-1276){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}Succ}}}
%%%\put(6571,-421){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}Order}}}
%%%\put(6571,-781){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}\ldots }}}
%%%\put(4681,-1186){\line( 1, 0){270}}
%%%\put(4951,-1186){\line( 0,-1){450}}
%%%\put(4951,-1636){\line(-1, 0){4815}}
%%%\put(136,-1636){\line( 0, 1){1260}}
%%%\put(136,-376){\vector( 1, 0){315}}
%%%\put(3106,-1186){\line( 1, 0){270}}
%%%\put(3376,-1186){\line( 0, 1){1575}}
%%%\put(3376,389){\line( 1, 0){2250}}
%%%\put(5626,389){\line( 0,-1){765}}
%%%\put(5626,-376){\line( 1, 0){495}}
%%%\put(1486,-1186){\line( 1, 0){315}}
%%%\put(1801,-1186){\line( 0,-1){675}}
%%%\put(1801,-1861){\vector( 1, 0){450}}
%%%\put(2566,614){\vector( 0,-1){675}}
%%%\put(4186,614){\line( 0,-1){180}}
%%%\put(4186,344){\vector( 0,-1){405}}
%%%\put(7156,-1186){\line( 1, 0){495}}
%%%\put(7651,-1186){\line( 0, 1){1575}}
%%%\put(7651,389){\vector(-1, 0){450}}
%%%\put(2566,659){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}Next\_Order}}}
%%%\put(4186,659){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}Free}}}
%%%\put(2476,-1861){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}\ldots }}}
%%%\put(5401,-736){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}\ldots }}}
%%%\put(7021,389){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}\ldots }}}
%%%\put(946,-2086){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}1}}}
%%%\put(2521,-2086){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}2}}}
%%%\put(4141,-2086){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}3}}}
%%%\put(6616,-2086){\makebox(0,0)[b]{\smash{\SetFigFont{10}{12.0}{rm}10}}}
%%%\end{picture}
%%%\caption{}
%%%\label{kette}
%%%\end{figure}
%%%
%%%
%%%The order string can be declared as follows:
%%%
%%%\begin{tabbing}
%%%{\bf TYPE} \= \x \= \x \= \kill
%%%... \> \> \> \\
%%%{\bf TYPE} \> StringElement {\bf STRUCT} \> \> \\
%%%           \>   \> {\bf [} \> Order  OrderType,\\
%%%           \>   \>         \> ...,\\
%%%           \>   \> {\bf ]};\\
%%%{\bf DCL}  \> OrderString (10) StringElement, \> \> \\
%%%           \> (Next\_Order, Free) {\bf REF} StringElement;\\
%%%... \> \> \>
%%%\end{tabbing}
%%%
%%%After initialising and arranging various orders, a finished order can be
%%%removed from the queue as follows (let Help be a variable of type REF
%%%string element):
%%%
%%%...\\
%%%Help := Next\_Order;
%%%Next\_Order := Next\_Order.Succ;\\
%%%Help.Succ := Free\\
%%%Free := Help\\
%%%...
%%%
%%%These statements are also further examples for implicit
%%%dereferentiation. The order string can be initialised as follows:
%%%
%%%{\bf FOR} i {\bf TO} 9\\
%%%\x {\bf REPEAT} \\
%%%\x \x OrderString(i).Succ:=OrderString(i+1);\\
%%%\x {\bf END};\\
%%%OrderString(10).Succ:={\bf NIL};
%%%\end{enumerate}
%%%
Generally, a new data type is defined as follows:

\begin{grammarframe}
\input{TypeDefinition.bnf}
\end{grammarframe}

The definition of a new data type has to take place before its use.
Besides, data types defined at module level, can be used in all tasks
and procedures of the module; the usability of locally defined data
types depends on the rules of the block structure.

In contrast to global objects, re-defined data types can only be used
in the module where they are defined. Thus, type definitions for
global objects have to be repeated in all used modules.

\begin{minipage}{\linewidth}
Example:
\begin{multicols}{2}
\begin{lstlisting}
MODULE (ModuleA);
PROBLEM;

TYPE MyType STRUCT [...];
...
DCL x MyType GLOBAL;
...
MODEND;
\end{lstlisting}
\columnbreak
\begin{lstlisting}
MODULE (ModuleB);
PROBLEM;

TYPE MyType STRUCT [...];
...
SPC x MyType GLOBAL(ModuleA);
...
MODEND;
\end{lstlisting}
\end{multicols}
\end{minipage}

For clear readablility it is recommended to start type names with a
upper case letter followed be lower case letters.

\section{The Initialisation Attribute (INITIAL)}   % 5.13
\label{sec_init}
\index{INIT@\textbf{INIT}}
\index{INITIAL@\textbf{INITIAL}|see {INIT}}

The initialisation attribute allows to assign initial values to
variables upon their declaration. For variables with assignment
protection (see \ref{sec_inv}), this is the only possibility of allocating
values. The initialisation attribute is given as last attribute of the
respective declaration:

\begin{grammarframe}
\input{InitialisationAttribute.bnf}
\input{InitElement.bnf}
\input{Constant.bnf}
\end{grammarframe}

The type of the given init element has to be compatible with the type of
the declared variable in accordance with the rules for assignment (cf.
\ref{sec_assignments}):

Example:

\begin{lstlisting}
...
DCL numberOfDevices  FIXED INIT(12),
    (lowerLimit, upperLimit) FIXED INIT(2,15);
...
   FOR i  FROM 1 TO numberOfDevices
   ...
\end{lstlisting}

Here, the variables \code{numberOfDevices}, \code{lowerLimit}
and \code{upperLimit}
 have the values \code{12}, \code{2} and \code{15},
 i.e., the elements of a declared constant list are assigned in
the sequence of writing down the declared identifier list.

Arrays and structures can also be initialised at the position of
declaration. For all structure components, one initial value has to be
given, each. For arrays, the initialisation list may be shorter than the
number of array elements. In this case, the last initial value for the
remaining elements is used repeatedly.
%%%%% added
Multidimensional arrays are initialized in the same sequence as in the
programming language C. The last index runs first.
\code{koeff(1,2)} will be initialized with \code{12} in the following example.
%%%%% end added

Example:

\begin{lstlisting}
...
 DCL address STRUCT
       [ araaCode    FIXED,
         town        CHAR(20),
         street      CHAR(20),
         houseNumber FIXED
       ] INIT (78120, 'Furtwangen', 'Robert Gerwig Platz', 1);

DCL colours(3)       CHAR(7) INIT ('black  ', 'white  ', 'red    ');
DCL allSixes(6)      FIXED   INIT(6);
DCL  koeff(1:2, 0:3) FIXED   INIT(10,11,12,13,20,21,22,23);
...
\end{lstlisting}

The initialisation list can, besides constants, even contain identifiers
of named constants as well as expressions calculable by the compiler
(cf. \ref{sec_named_const} and \ref{sec_const_expression}).

\section{Assignment Protection (INV)}    % 5.14
\label{sec_inv}
\index{INV@\textbf{INV}}

Variables can be declared with an assignment protection,i.e. the attribute
\code{INV} (from ``invariant''), in order to forbid --- apart from
initialisation --- assignments to these variables. The attribute \code{INV} is
noted immediately before the type attribute.

Example:

\begin{lstlisting}
...
DCL Pi INV FLOAT INIT(3.141);

Pi := 3;  /* results in error message of the compiler */
\end{lstlisting}

An assignment protection which once is associated with an object in its
declaration cannot be revoked; thus it must be considered in
specifications of this object, but also when transmitting it as actual
procedure parameter or when using it as value of reference variables. On
the other hand, in one of this ways an assignment protection may arise
which was not associated in the declaration.

Example:

\begin{lstlisting}
...
p: PROC(a (,) INV FIXED IDENT, x FLOAT IDENT);
    /* procedure body */
END; ! p

DCL tab(10,20) FIXED,
    pi  INV FLOAT INITIAL(3.141),
    r1 REF FLOAT,
    r2 REF INV FIXED;
...
SPC aliasForPi FLOAT IDENT (pi);  /* wrong */
...
CALL p (tab, pi);         /* wrong */
r1:=pi;                   /* wrong */
r2:=tab(5,7);             /* ok    */
\end{lstlisting}

The specification of \code{aliasForPi} is wrong, because assignments to
 \code{aliasForPi} are allowed,
and thus the assignment protection of \code{pi} is circumvented.

The call of \code{p} is wrong, because the formal parameter \code{x}
belonging to \code{pi}
is specified without assignment protection, and thus a (forbidden) value
change of \code{pi} could happen in the body of \code{p}
via an assignment to \code{x}.

In contrast, in the same call, the parameter transmission from \code{tab}
 to \code{a}
is correct, because only an assignment protection for \code{tab} arises which
was not introduced yet.

The assignment \code{r1:=pi} is not permitted, because otherwise the assignment
protection for \code{pi} via (allowed) assignments to \code{CONT r1}
 could be revoked.
The assignment \code{r2:=tab(5,7)}, however, is permitted; a value modification
of the tabular element via \code{CONT} is not possible.

\subsection{Named Constants (INV Constants)}   % 5.14.1
\label{sec_named_const}
\index{INV@\textbf{INV}!Named Constant}

The compiler treats objects of type \code{FIXED}, \code{BIT},
 \code{CHAR(1)}, \code{CLOCK} and
\code{DURATION} declared with attribute \code{INV}
 as (named) constants. The names of
these objects may be used after their declaration (with initialisation)
for declaring and initialising further objects. For this, they may be
applied as dimension boundary denotation in array declarations as well
as in initialisation lists.

\begin{minipage}{\linewidth}
Example:

A surveillance program shall be adapted for various projects with
different numbers of embedded controllers. The number of message
buffers and synchronising variables belonging to them
(cf. \ref{sec_task_sync}) can be
adapted easily by changing the constant \code{numberControls}:

\begin{lstlisting}
...
DCL numberControls INV FIXED INIT(11);

DCL messageBuffer (numberControls) CHAR(100);
DCL BufferAccess (numberControls)  BOLT;
...
\end{lstlisting}
\end{minipage}

For a further project with another number of controls, only the named
constant NumberControls has to be adapted to the actual conditions. The
memory areas dependent on that are adapted by the compiler.

Since the compiler does not generate any run time objects for named
objects, they may not be assigned to a reference variable. Likewise,
they cannot be used as actual parameters of a procedure, if the formal
parameter was specified with the  \code{IDENTICAL} attribute or as reference
variable (cf. \ref{sec_proc_dcl}).

\subsection{Constant Expressions (of Type FIXED)}   % 5.14.2
\label{sec_const_expression}

In all positions where the compiler expects constants, also constant
expressions may occur. These expressions may only contain constants
(also named constants) as operands. They are evaluated by the compiler,
and the results are inserted in the respective positions.

\begin{grammarframe}
\input{ConstantExpression.bnf}
\input{ConstantFIXEDExpression.bnf}
\input{Term.bnf}
\input{Factor.bnf}
\end{grammarframe}

Constant expressions of type \code{FIXED} can, e.g., be applied in the
following positions:
\begin{itemize}
\item denotation of dimension boundaries in array declarations,
\item precision declaration (for \code{FIXED} and \code{FLOAT} variables),
\item length definition (for \code{CHAR} and \code{BIT} variables),
\item in initialisation lists (also for \code{PRESET}),
\item priority definition in task declarations and task statements
\item in the constant lists of the \code{CASE} statement
\item on the right side of an assignment
\end{itemize}

Often, several objects of a program (variables, constants) are dependent
from one another. If this dependence can be described by a simple
formula, a program can probably be configured by just adapting few
constants.

Example:

A warning shall be given, if a buffer system is filled up to the last 10
\%:

\begin{lstlisting}
...
DCL maxBuffer      INV FIXED INIT(1000);
DCL warnBoundary   INV FIXED INIT(maxBuffer - maxBuffer // 10);
DCL buffer (maxBuffer) FIXED;
DCL actualBufferIndex  FIXED INIT(1);
...
actualBufferIndex := actualBufferIndex+1;
IF actualBufferIndex > warnBoundary
THEN
   /* output of warning */
FIN;
...
\end{lstlisting}


\documentclass[a4paper]{article}
\usepackage{alltt,amsmath,pifont}
\usepackage{amssymb,multicol}
\usepackage{subfigure,epsfig,wrapfig}

% For Algorithms
%\usepackage{algorithmicx}
\usepackage{algpseudocode}
%\usepackage{algpascal}
%\usepackage{algc}
\usepackage[ruled]{algorithm}

% page layout
\evensidemargin=0.0in
\oddsidemargin=0.0in
\setlength{\textheight}{220mm}
\setlength{\textwidth}{160mm}
\setlength{\columnsep}{6.5mm}
\setlength{\hoffset}{0.0mm}
\addtolength{\voffset}{-5.0mm}

% shortcuts
\newcommand{\bs}[1]{\boldsymbol{#1}}				% boldsymbol
\newcommand{\pc}{\mbox{${\boldsymbol Q}_{\hat K}$}}	% preconditioner

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

\begin{document}
%\alglanguage{pseudocode}

\begin{center}
{\bf \LARGE{An Iterative Saddle Point Solver for Symmetric Problems}}\\
\vspace{4.0mm}
{\Large David A. May } \\
{\small Louis Moresi}\\
\vspace{4.0mm}
{\large School of Mathematical Sciences\\
Monash University } \\
\vspace{2.0mm}
{\it Last revised on Jan 20, 2006} \\
\end{center}

\section{Introduction}
Written in block matrix form, we seek to solve
\begin{equation}
\left( \begin{array}{cc}
 {\boldsymbol K}   & {\boldsymbol G} \\
 {\boldsymbol D}     & {\boldsymbol M}
\end{array} \right)
\left( \begin{array}{c}
{\boldsymbol u} \\
{\boldsymbol q}
\end{array} \right)
= \left( \begin{array}{c}
{\boldsymbol f} \\
{\boldsymbol h}
\end{array} \right),
\label{saddle}
\end{equation}
%%
where ${\boldsymbol K}$ is symmetric and positive definite. Systems such as \eqref{saddle} arise in the discretisation of the Stokes equations. In the context of fluid dynamics  ${\boldsymbol K}$ is the discrete stress tensor, ${\boldsymbol u} = ( u_0, v_0, w_0, u_1, v_1, w_1, \dots )^T $ is the vector discrete velocities and ${\boldsymbol q} = (q_0, q_1, \dots)^T$ contains the discrete pressure-like unknowns. ${\boldsymbol G} = \left(  G_x, G_y, G_z  \right)^T $ is the discrete gradient operator and ${\boldsymbol D} = \left(  D_x , D_y , D_z  \right)$ is the discrete divergence operator. In the problem we consider, $ {\boldsymbol D} =  {\boldsymbol G}^T$.
Furthermore, the matrix ${\boldsymbol M}$ can also be identically equal to the zero matrix. The algorithms we consider are valid should ${\boldsymbol M}={\boldsymbol 0}$. Standard mixed Galerkin finite element formulations of the Stokes equation generate a symmetric, positive definite ${\boldsymbol K}$. An aside regarding our choice of terminology: in the case where ${\boldsymbol M}={\boldsymbol 0}$, ${\boldsymbol q}$ corresponds to the pressure, but in the general (compressible) formulation the pressure consists of ${\boldsymbol q}$ plus a contribution from the (non-zero trace of the) strain-rate tensor.

\section{Conjugate Gradient Solver}

Much attention has been focused on the solution of \eqref{saddle} when ${\boldsymbol K}$ is symmetric. \cite{atanga} \cite{ramage} \cite{moresi} In this case, the proposed solution consists of a two-level pressure corrected Uzawa scheme. The method decouples the variables ${\boldsymbol u}$ and ${\boldsymbol q}$ by re-writing \eqref{saddle} as
\begin{equation}
	\left( {\boldsymbol G^T} {\boldsymbol K}^{-1} {\boldsymbol G} - {\boldsymbol M} \right) {\boldsymbol q}  =
	{\boldsymbol G^T} {\boldsymbol K}^{-1} {\boldsymbol f} - {\boldsymbol h}
\label{decouple1}
\end{equation}
which we represent by
\begin{equation}
\widehat{{\boldsymbol K}} {\boldsymbol  q}  = \widehat{ {\boldsymbol  f}}.
\label{decouple2}
\end{equation}
and then a standard preconditioned conjugate gradient algorithm is applied to this transformed problem. It should be noted that the algorithm is constructed in a manner which avoids the need to explicitly calculate ${\boldsymbol K}^{-1}$. This algorithm is described below.

\newpage

\section{Uzawa based PCG}
The following algorithm derives from the standard preconditioned conjugate gradient (PCG) scheme. The solution utilises a preconditioner $\pc \approx \widehat{\boldsymbol K}$ to solve \eqref{decouple2} and requires that an initial guess for $q_0$ be provided. The guess can always be $\boldsymbol q_0 = 0$ or it can come from the previous timestep . A maximum number of allowable iterations $k_{\textrm{Max}}$ is placed on the iterative scheme and a convergence tolerance of $\epsilon << 1$ is set.

\begin{algorithm}
\caption{Preconditioned Conjugate Gradient Based Uzawa Scheme. Assume that  ${\boldsymbol q}_0$ is the pressure solution from the previous timestep or
the zero vector if this is the first time. \label{PCG_alg}}
\begin{algorithmic}[1]
%	\State ${\boldsymbol q}_0 = {\boldsymbol 0}$		% initialise vector
	\State ${\boldsymbol u}_0 = {\boldsymbol K}^{-1} \left( {\boldsymbol f} - {\boldsymbol G}{\boldsymbol q}_0 \right)$
	\Comment{solve for initial velocity}
	%
	\State ${\boldsymbol r}_0 = { \boldsymbol G}^T {\boldsymbol u}_0 + {\boldsymbol M}{\boldsymbol q}_0 - {\boldsymbol h}$  	% calculate initial residual
	\Comment{calculate the residual}
	%
	\State $k=1$
	\Comment{initialise iteration counter}
	\For{$k=1,2, \dots$}
		\State $\pc {\boldsymbol  z}_{k-1} = {\boldsymbol r}_{k-1}$
		\Comment{solve for ${\boldsymbol z}_{k-1}$}
		\If{$k=1$}
			\State ${\boldsymbol s}_1 = {\boldsymbol z}_0$
			\Comment{set the initial pressure search direction}
		\Else{ }
			\State $\beta = \dfrac{{\boldsymbol z}_{k-1}^T {\boldsymbol r}_{k-1}}{{\boldsymbol z}_{k-2}^T {\boldsymbol r}_{k-2}}$
			\State ${\boldsymbol s}_k ={\boldsymbol  r}_{k-1} + \beta {\boldsymbol s}_{k-1}$
			\Comment{set the pressure search direction}
		\EndIf
		\State ${\boldsymbol u}^* = {\boldsymbol K} ^{-1}{\boldsymbol G}{\boldsymbol s}_k$ \label{u_star}
		\Comment{solve for the velocity search direction ${\boldsymbol u}^*$}
		%
		\State Note that: ${\boldsymbol G}^T {\boldsymbol u}^* = {\boldsymbol G}^T {\boldsymbol K}^{-1} {\boldsymbol G} {\boldsymbol s}_k$
		%\Comment{Form $\widehat{\bs K} \bs s_k$}
		%
		\State $\alpha:
			= \dfrac{   {\boldsymbol  z}_{k-1}^T  {\boldsymbol r}_{k-1}    } {   {\boldsymbol  s}_{k}^T \widehat{\bs K} \bs s_k }
			=\dfrac{   {\boldsymbol  z}_{k-1}^T  {\boldsymbol r}_{k-1}    } {   {\boldsymbol  s}_{k}^T    \left(   {\boldsymbol G}^T {\boldsymbol u}^* - {\boldsymbol M} {\boldsymbol s}_{k}    \right) }$
		\Comment{set step length}
		%
		\State ${\boldsymbol q}_k = {\boldsymbol q}_{k-1} + \alpha {\boldsymbol s}_k$ \label{q_update}
		\Comment{update pressure}
		%
		\State ${\boldsymbol u}_k = {\boldsymbol u}_{k-1} - \alpha {\boldsymbol u}^*$ \label{v_update}
		\Comment{update velocity}
		%
		\State ${\boldsymbol r}_k = {\boldsymbol r}_{k-1} - \alpha \left( {\boldsymbol G}^T{\boldsymbol u}^* - {\boldsymbol M}{\boldsymbol s}_k   \right)$ \label{formal_residual}
		\Comment{update residual}
		%
		\State $k = k +1$
		\State Check for convergence. Continue if necessary.
	\EndFor
\end{algorithmic}
\end{algorithm}

\section{Notes}
\begin{itemize}
	\item The solution of ``inner'' systems like ${\boldsymbol K} u^* = {\boldsymbol G} \bar q$ and ${\boldsymbol K} v^* = {\boldsymbol G} \bar a$ need to be obtained to the full accuracy required for the ``outer'' system. This means that the efficiency of this inner solver is critical to the time scaling behaviour of the algorithm as a whole and warrants proper attention.
%%
The vectors $u^*$ and $v^*$
%% and those with overbars %% aren't any ??!
are auxillary variables which are reused during each iteration cycle. The history of these vectors' values from the previous iterations is not required. Vectors which are required in later iterations have a subscript $k$.
	\item The formal residual $\bs r_{k}$ (line \ref{formal_residual}) is equivalent to the residual $\bs r_{k} = \widehat{\bs f} - \widehat{\bs K} \bs q_{k}$.   %% Templates, pg. 15. ??
	\item The term $\alpha {\bs s}_k$ in line \ref{q_update} is a pressure correction, $\Delta \bs q$. The velocity update (line \ref{v_update}) comes from considering the change in solution between the momentum equation at iterations
	$k$ and $k-1$. If we subtract the momentum equations at we get
	\begin{align}
		&\bs K \bs u_k + \bs G \bs q_k - \bs K \bs u_{k-1} + \bs G \bs q_{k-1} = \bs f_k - \bs f_{k-1}	\\
		&\bs K \left( \bs u_k - \bs u_{k-1} \right) + \bs G \left( \bs q_k - \bs q_{k-1} \right) = 0
	\end{align}
	thus
	$$
		\bs u_k = \bs u_{k-1} - \bs K^{-1} \bs G \Delta \bs q.
	$$
	In the update of the velocity, we use $\alpha {\boldsymbol u}^*$ as the velocity increment as we have that ${\boldsymbol u}^* = {\boldsymbol K} ^{-1}{\boldsymbol G}{\boldsymbol s}_k$ from line \ref{u_star}.
\end{itemize}

\subsection{Preconditioner}
In the above, $\pc$ is the preconditioning matrix. In its simplest form we could set the preconditioner to be the identity matrix
\begin{equation*}
	\pc = {\boldsymbol I }.
\end{equation*}
With this preconditioner the algorithm reverts back to the standard conjugate gradient algorithm.

The preconditioner which we use is given by
\begin{equation}
	\pc
		=  {\boldsymbol G}^T \medspace \left[ \text{diag} ( {\boldsymbol K}) \right]^{-1}  \medspace  {\boldsymbol G}
		\approx  \widehat{  {\boldsymbol  K }  }
	\label{pc1}
\end{equation}
a simpler version might be to use only the diagonal part of the above result. Thus
\begin{equation}
 \pc  =   \text{diag}\left(
  	{\boldsymbol G}^T \medspace \left[ \text{diag} ( {\boldsymbol K}) \right]^{-1}  \medspace  {\boldsymbol G} - \bs M
	\right)
\label{pc2}
\end{equation}

In the case of the finite element method, if the pressure space is discontinuous, then the preconditioners above can
be constructed element-by-element. Thus
\begin{equation}
	 \pc =  \mathop{      \text{ {\huge A} }       }_{e=1}^{n_e}   \left( \bs Q ^e \right)
\end{equation}
where $\bs Q^e$ is
\begin{equation}
	\bs Q^e
	= ( {\boldsymbol g^e})^T \medspace \left[ \text{diag} ( {\boldsymbol k^e}) \right]^{-1}  \medspace  {\boldsymbol g^e}
\end{equation}
To make $\pc$ trival to invert, we could make the element preconditioner $\bs Q^e$
\begin{equation}
	\bs Q^e
	= \text{diag} \left[ ( {\boldsymbol g^e})^T \medspace \left[ \text{diag} ( {\boldsymbol k^e}) \right]^{-1}  \medspace  {\boldsymbol g^e}  \right]
\end{equation}
to make $\pc$ diagonal.

It should be noted the following element-by-element variations of the preconditioner will not work. Those which involve computing
either the inverse or ``lumped'' form of ${\boldsymbol k^e}$. This is entirely due to the nature of the finite element method. The
individual element stiffness matrices are ill posed without the presence of the boundary conditions. Removal of the degrees of freedoms
which have boundary conditions applied could alleviate this problem (yet to be tried). It should also be pointed out that the
preconditioners \eqref{pc1} and \eqref{pc2} are equivalent when the billinear-constant velcoity pressure shape function combination is used.
This is a result of $ {\boldsymbol g^e}$ being a vector since each element $e$ has only one pressure degree of freedom which is not coupled to another pressure
degrees of freedom.

%-------------------------------------------------
%-------------------------------------------------
%     REFERNCES
%-------------------------------------------------
%-------------------------------------------------

\begin{thebibliography}{5000}
\bibitem{atanga} Atanga J. \& Silvester D., {\it Iterative methods for stabilized mixed velocity-pressure finite elements.},
	Int. J. Num. Meth. Fluids. {\bf 14}, (1992), pp 71-81.
\bibitem{ramage} Ramage A. \& Wathen J., {\it Iterative solution techniques for the stokes and navier-stokes equations.},
	Int. J. Num. Meth. Fluids. {\bf 19}, (1994), pp 67-83.
\bibitem{moresi} Moresi L. \& Solomatov V.S., {\it Numerical investigations of 2D convection in a fluid with extremely large viscosity variations.},
	Phys. Fluids. {\bf 7}, (1995), pp 2154-2162.
\end{thebibliography}

\end{document}


\subsection{Numeric strings}
\label{subsec:pd:numericstrings}

% ----------------------- paths to graphics ------------------------

\graphicspath{{5_automatic_learning/pattern_detection/images/}}

% ----------------------- contents from here ------------------------
%

This pattern detector searches for numbers stored in string columns. Once found, it changes the column data type to a numeric one, while also preserving the string format of the numbers in additional columns. The purpose is to optimize the data type and create opportunities for numeric compression schemes. An additional purpose is to enable the push-down of numeric range predicates in data scans during query evaluation (the implementation and evaluation of all execution-related matters was kept out of scope for this thesis). The \textit{select\_column} method only returns \textit{True} for \verb|VARCHAR| columns. This is a single-column pattern detector and columns are evaluated independently. The next paragraphs describe the pattern detection process for a single column.

The \textit{scanning} phase checks for each value (\(v_{string}\)) whether it can be parsed as a number (\(v_{numeric}\)). If \textit{True}, it extracts the format information and checks whether the original string value can be reconstructed. The \textit{evaluation} phase chooses an appropriate numeric data type (e.g. \verb|DECIMAL(p,s)|) based on the type and range of the values selected in the \textit{scanning} phase. More details about the format preserving and data type inference processes are presented in the following paragraphs.

\textbf{Format preserving.} While analyzing the Public BI benchmark we noticed that the majority of string values \(v_{string}\) with a different format than their numeric representation \(v_{numeric}\) contain leading or trailing characters (e.g. zeros, whitespace). Therefore, we based our format preserving technique on 3 components---\textit{prefix}, \(v_{numeric}\), \textit{suffix}---as follows:\\
Step-1: cast \(v_{string}\) to number to obtain \(v_{numeric}\)\\
Step-2: check whether \(abs(v_{numeric})\) is a substring of \(v_{string}\). If \textit{False}, the format cannot be preserved. Otherwise, \(v_{string}\) has the following format:
\verb|${|\textit{prefix}\verb|}|\(abs(v_{numeric})\)\verb|${|\textit{suffix}\verb|}|,
where \textit{prefix} and \textit{suffix} can be any strings, including the empty string.\\
Step-3: extract the \textit{prefix} and \textit{suffix} and store them as format information together with \(v_{numeric}\).

\(v_{string}\) can be now reconstructed by concatenating the \textit{prefix}, \(v_{numeric}\) and \textit{suffix} values. Table~\ref{tab:pd:numericstring:formatexamples} illustrates a few examples that the format preserving technique covers (\verb|"_"| characters represent spaces).

\input{5_automatic_learning/pattern_detection/numeric_strings-table_1}

We currently do not yet support---and consider exceptions---the following: 1) numbers in scientific notation; 2) other notations or abbreviations (e.g. \verb|.12| instead of \verb|0.12|, \verb|1_000_000| instead of \verb|1000000|, etc.).

\textbf{Data type inference.} The purpose of this pattern detector is to store the numeric string values in a numeric column, which requires a numeric data type. We chose two data types that can be used to represent all numbers: \verb|DECIMAL(p,s)| and \verb|DOUBLE|. During the \textit{scanning} phase all \(v_{numeric}\) values are interpreted as decimals. The maximum number of digits before and after the decimal point---\(\mathit{integer}_{dmax}\) and \(\mathit{fractional}_{dmax}\)---are determined.  In the \textit{evaluation} phase, the parameters \textit{p} (precision) and \textit{s} (scale) of the \verb|DECIMAL(p,s)| data type are computed as follows:
\begin{equation}
\label{eq:pd:numericstrings:precisionscale}
\begin{array}{ll}
    p &= \mathit{integer}_{dmax} + \mathit{fractional}_{dmax}\\
    s &= \mathit{fractional}_{dmax}
\end{array}
\end{equation}
The final datatype of the numeric column is determined as follows:
\begin{equation}
\label{eq:pd:numericstrings:datatype}
\mathit{datatype} =
\left\{
\begin{array}{ll}
    \verb|DECIMAL(p,s)| & \mbox{if } p \leq p_{max}\\
    \verb|DOUBLE| & \mbox{else}
\end{array}
\right.
\end{equation}
where:
\begin{itemize}
    \item[] \(p_{max}\) = maximum decimal precision supported by the system
\end{itemize}
The maximum precision value is configurable and necessary as database systems enforce it---MonetDB: \(p_{max}=38\) \cite{monetdbdatatypes}, VectorWise: \(p_{max}=39\) \cite{vectorwisedecimal}.

A string value \(v_{string}\) is considered an exception if any of the following conditions is not satisfied:\\
1) \(v_{string}\) cannot be parsed as a numeric value \(v_{numeric}\)\\
2) \(v_{string}\) cannot be reconstructed from its numeric value \(v_{numeric}\) and format information\\
3) \(v_{numeric}\) exceeds the numeric data type selected in the \textit{evaluation} phase

There is no strict filtering condition that determines whether a column fits this pattern or not. The pattern detector outputs a result for all columns with \textit{coverage} grater than \(0\), leaving the responsibility of choosing which columns to compress with this scheme to the compression learning algorithm. The \textit{evaluation result} is composed of the \textit{coverage} and \textit{row\_mask}---as defined in \ref{subsec:genericpd}~\nameref{subsec:genericpd}. No additional metadata is necessary for the compression and decompression processes.

The \textit{expression nodes} for the \nameref{subsec:pd:numericstrings} pattern are illustrated in the Figure~\ref{fig:pd:numericstrings:exprnode}.

\begin{figure}[h]
  \centering
  \begin{subfigure}[t]{0.49\linewidth}
    \centering
    \includegraphics[width=1\linewidth]{expression_node-nas-compression_3.pdf}
    \caption[b]{compression}
    \label{fig:pd:numericstrings:exprnode:compression}
  \end{subfigure}
%   \hspace{1em}
  \begin{subfigure}[t]{0.49\linewidth}
    \centering
    \includegraphics[width=1\linewidth]{expression_node-nas-decompression_3.pdf}
    \caption[b]{decompression}
    \label{fig:pd:numericstrings:exprnode:decompression}
  \end{subfigure}
  \caption{Numeric strings expression nodes}
  \label{fig:pd:numericstrings:exprnode}
\end{figure}

The \textit{compression node} takes as input the \textit{string} column and generates three output columns: one for storing the numeric values and the other two for storing the format information as \textit{prefix} and \textit{suffix}. The \textit{decompression node} takes as input the \textit{numeric}, \textit{prefix} and \textit{suffix} columns and reconstructs the original string column.

The compression operator \(cast_{numeric}\) takes as input \(v_{string}\) and tries to represent it as the 3 components---\textit{prefix}, \(v_{numeric}\) and \textit{suffix}---as described above. It then checks whether \(v_{numeric}\) fits in the inferred data type of the numeric column. If everything succeeds it returns the 3 values, else it raises an \textit{OperatorException} indicating that \(v_{string}\) should be added to the exception column. The decompression operator \(concat\) reconstructs \(v_{string}\) by concatenating \textit{prefix}, \(abs(v_{numeric})\) and \textit{suffix}. The two operators do not require any metadata, except for the numeric column data type.

There are three main benefits brought by this representation scheme: 1) using an optimal numeric data type instead of \verb|VARCHAR|, leading to smaller size on disk; 2) creating opportunities to further compress the numeric column with numeric compression schemes; 3) creating push-down opportunities for numeric predicates (e.g. for the query \texttt{SELECT * FROM t WHERE (CAST c AS INT) < 42} it allows push-down on the physical numeric column, even if \verb|c| is \verb|VARCHAR|; this example may look contrived, but in the case of dates stored as strings it is very common). Moreover, we noticed that in practice the \textit{prefix} and \textit{suffix} columns get further compressed as \nameref{subsec:pd:constant} or with \nameref{subsec:pd:dict} encoding.

% ---------------------------------------------------------------------------
% ----------------------- end of thesis sub-document ------------------------
% ---------------------------------------------------------------------------