\chapter{Chess-game analysis}

\section{The game of chess}

\textbf{Chess} is a \textit{two-player turn-based strategy game} played on a checkered board with bounded dimensions: \textit{64 squares arranged in an 8x8 grid}, where each player has a set of initial pieces arranged in a specific order aiming to conquer an specific opponent piece: \textit{The King}.

In \textbf{game-theory}, Chess is classified in the cluster of games with perfect information in which the players move alternately and the game is not subject to randomization.

The \textbf{history of chess} was firstly documented around 6th Century, although the earliest origins are ambiguous. It is believed that the game's predecessor was originated in India, from where the game spread to Persia. After the Arabic occupation, the game was spread through the Muslim world and to Southern Europe, where it evolved into the current form in the \textbf{15th Century} ~\cite{murray1913history}.

    \begin{figure}[H]
        \centering
        \includegraphics[width=0.6\textwidth]{chessmen}
        \caption{The Lewis chessmen are a group of distinctive 12th-century chess pieces, along with other game pieces, most of which are carved from walrus ivory. Present location: \textit{British Museum, London}. \textit{Image courtesy of Wikipedia Commons}.}
    \end{figure}

\section{Computing chess}

\subsection{Zermelo's theorem}

\begin{theorem}
Zermelo's theorem is a game-theory theorem regarding finite two-person games of perfect information in which the players move alternately and the game is not subject to randomization. It suggests that if the game cannot end in a draw, then one of the two players must have a winning strategy (\textit{i.e. force a win}).

An alternate statement is that for a game meeting all of these conditions except the condition that a draw is not possible, then either the first-player can force a win, or the second-player can force a win, or both players can force a draw. ~\cite{schwalbe2001zermelo}.
\end{theorem}

\begin{remark}
As the chess is a finite two-person games of perfect information in which the players move alternately and the game is not subject to randomization, Zermelo's Theorem can be applied for this game. It states that either White can force a win, or Black can force a win, or both sides can force at least a draw.
\end{remark}

With this background of theoretical work, we can state that there must be a perfect algorithm for chess, at least for one of the two players.

\begin{remark}
All endgames of 6 pieces or less have been perfectly solved.
\end{remark}

\begin{remark}
Previous results show that the game of Losing Chess is a win for White. ~\cite{watkins2017losing}. The "losing-winning" move is \textbf{e3} for White.
\end{remark}

\subsection{Chess complexity using Bachmann-Landau notations}

This subsection will present another example of inappropriate use of Bachmann-Landau asymptotic notations for algorithms that d\textit{o not generalize well}. As previously stated, a perfect algorithm for chess exists, even though the state space that it would have to search would be huge.

Due to finite-bounds of the game and the existence of the \textbf{50-move rule}, which allows either player to claim a draw if 50 or more moves take place without movement of a pawn or a piece-capture, based on FIDE-game rules, the longest chess game could be up to 4851 moves. A wide estimation would be counting the total number of possibilities for a the player to move one of (at most) 16 pieces: 8 pawns, each with at most 3 moves, 2 rocks each with at most 14 moves, 2 knights 8 each with at most, 2 bishops, each with at most 14 moves, 28 for a queen and 8 for a king, for a total of 132 possible moves. \textit{Definitely these are just hypothetical situation analyzing the worst-case scenario, as in real games the possibilities are far smaller.}

Hence, the \textit{total number of chess games} would be at most $132^{4851}$. (a more realistic estimation would be $10^{500}$)

As a finite game can be simulated in constant time, the above estimation, translated in Bachmann-Landau notations for complexity classes, this means that the perfect algorithm for chess should perform in $O(132^{4851})$. Using the properties of Big-O complexity class, we can state that this algorithm will perform in constant time, with $O(1)$ complexity as this number of total number of chess, regardless how big it is, is still a constant.

In this situation, the Bachmann-Landau asymptotic notations did not provide useful information and the reason is simple: these notations were developed for asymptotic-scaling problems and algorithms, w/o awareness of discrete values. \textit{Even though in most cases these notations were helpful, this is probably not the case in this scenario.}

\subsection{Previous work}
Claude Shannon had studied the implications of a brute force solution for solving chess back in the 1950 ~\cite{shannon1950xxii}, when he introduced the \textbf{Shannon number}, a conservative lower bound of the game-tree complexity of chess. The purpose was to validate that any perfect chess algorithms based on brute-force are impractical.

The Shannon number proposed back in 1950 was $10^{120}$, taking into consideration a typical game  of 80 moves at a rate of $10^3$ possibilities for each pair of white-black moves.

Previous work of Claude Shannon was building the foundation of information theory with a landmark paper (1948), \textit{"A Mathematical Theory of Communication"}.

Further work showed that, based on an average branching factor of 35 and an average game length of 80, the lower bound for the chess game-tree is around $10^{123}$. (Victor Allis ~\cite{allis1994searching})

\section{Chess in r-Complexity}
As we previously stated, the perfect algorithm for chess is part of the $O(1)$ complexity class, as its input values are finite-bounded. Thus, the associated r-Complexity class would be $O_{1}(c)$, where $c$ in a real finite constant. A human-driven calculus of r-Complexity is not feasible, as there are various run-time aspects that are difficult to be taken into consideration and an exact calculus would imply a even greater effort than solving straightforward the chess problem. Thus, we propose an automatic estimation for this algorithm, that has its Bachmann–Landau Complexity known.

The first step was acquiring data on few game-simulation. Using gym framework, we tracked the time-complexity for various number of episodes with different number of steps per each episodes.

    \begin{figure}[H]
        \centering
        \includegraphics[width=0.80\textwidth]{chesssim}
        \caption{The plot shows the total computing time based on the variation of parameters corresponding to the total number of games and the average length of a game. Results gathered on a 2.3 GHz Intel Core i5 processor using a serial implementation in Python and Gym framework. }
    \end{figure}

Using an average game length of 80, the chess-solving problem becomes a one-parameter problem that involves the total number of episodes to be generated. This value is lower-bounded by the value of $10^{123}$. A brute-force solution for this algorithm would act almost linearly in terms of number of episodes to be generated.

    \begin{figure}[H]
        \centering
        \includegraphics[width=0.6\textwidth]{chesslin}
        \caption{The relationship between the total time required to generate a specific number of games appears to be linear (actual results obtained for an average game length of 80)}
    \end{figure}

Of course, many optimization can reduce the total time by even two orders of magnitude. Regardless of the optimization process, for an input of $10^{123}$, the total estimated time using this algorithm would be $0.855 \cdot 10^{123}$ seconds and thus the r-Complexity would be $O_{1}(0.855 \cdot 10^{123} \cdot HZ)$, where $HZ \approx 2.3 \cdot 10^9$.

Such a huge time limit is a result of the greatness of the lower bound for chess. Recall that this is by over 40-orders of magnitude greater that the total estimated number of atoms in the universe.

\subsection{The dream of the perfect algorithm}
All means of computing in 2020 are at an enormous gap from what it would be needed in order to find the perfect algorithm of chess using brute-force solutions.

Based on the estimated r-Complexity (i.e. $O_{1}(0.855 \cdot 10^{123} \cdot HZ)$, where $HZ \approx 2.3 \cdot 10^9$) we present few scenarios describing what it would take to compute:
\begin{enumerate}[label=\roman*]
  \item \textbf{Scenario 1}

  Assume that each atom in the universe is the state-of-the-art computing core of a modern processor, that operates at a frequency of 5GHz. Assume that the perfect algorithm of chess defies Amdahl's Law by assuming a theoretical unbounded speedup in the latency of the execution. Assume we have 0 latency between inter-process communication. So far, we built an system consisting of $10^{80}$ (this is, the estimate the total number of fundamental particles in the observable universe) computing units operating at $HZ_0 \approx 5 \cdot 10^9$, with zero latency that needs to solve an algorithm with associated complexity of $O_{1}(0.855 \cdot 10^{123} \cdot 2.3 \cdot 10^9)$. That is, assuming perfect distribution and zero overhead, each unit would require approx $10^{42}$ seconds. This is far greater than any estimation of the universe lifespan.
  \item \textbf{Scenario 2}

  Moore's law might come to rescue the hope. Ignoring any physical consideration of the minimum MOSFET scaling process, one might assume that the law might scale indefinitely (even though even Gordon Moore himself foresaw that the rate of progress would eventually reach saturation).

Assume that, the number of transistors in an integrated circuit doubles about every two years and this results in doubling of the transistors implies a doubling in the computing power as well. (ignore the total amount of energy spent and all other considerations). Say that, if today a computing unit would solve the problem in $0.855 \cdot 10^{123}$ seconds, in two-year times, the new computing unit would solve the problem in $\dfrac{0.855 \cdot 10^{123}}{2}$.

Similarly, in four-year times, the new unit would solve the problem in $\dfrac{0.855 \cdot 10^{123}}{2^2}$ and in six-year times, it would solve the problem in $\dfrac{0.855 \cdot 10^{123}}{2^3}$. This decrease in time is logarithmic and, theoretical, it reaches after $2 \cdot log_{2}(0.855 \cdot 10^{123})$ years to a point in which the total time for solving chess would be just under 1 second.

That is, if Moore's law would scale indefinitely, after 816 years, we would be able to solve by brute-force, the game of chess. However, this would also mean that the system would require $2^{408}$ more transistors than the current number of transistors in modern computers (tens of billions), reaching a peak number of transistors of $10^{132}$.

Unless each fundamental particle in the observable universe could act as $10^{52}$ MOSFET-transistors, this scenario is impracticable.

  \item \textbf{Scenario 3}

  A new, groundbreaking technology appeared and computing is no longer an issue. The algorithm would still require to store at least $10^{123}$ games. Assume the most efficient compression, even though unfeasible, each unique position can be stored by only one brand new memory unit. This would mean that each atom in the universe should be able to store at least $10^{43}$ storing units. This appears to be pretty difficult.
\end{enumerate}

We could further extend our \textit{philosophical discussion} with many more scenarios, but the point is clear. \textbf{Perfectly solving} the game of chess is a problem \textit{far to complicated}. And yet, we, as humans, \textit{with limited computing power}, can naturally play the game of chess \textit{charmingly well}.


\chapter{IPv6}

\section{Representation}

IPv6 addresses are 128 bits in length and written as a string of 32 hexadecimal values. Every 4 bits is represented by a single hexadecimal digit. The preferred format for writing an IPv6 address is x:x:x:x:x:x:x:x, where each ``x'' is a single \emph{hextet}\footnote{four hexadecimal values}. For example,

\begin{verbatim}
2001:0DB8:0000:1111:0000:0000:0000:0200
\end{verbatim}

There are two rules to help reduce the number of digits needed to represent an IPv6 address.

\begin{itemize}
\item \textbf{Omit leading 0s:} Omit any leading 0s (zeros) in any hextet. This rule only applies to leading 0s, NOT to trailing 0s; otherwise, the address would be ambiguous. For example, the hextet \verb|0ABC| will become \verb|ABC|.

\begin{verbatim}
2001:0DB8:0000:1111:0000:0000:0000:0200
2001: DB8:   0:1111:   0:   0:   0: 200
\end{verbatim}

\item \textbf{Omit 0 segments:} Double colon (::) can replace any contiguous string of one or more hextets consisting of all 0s. The double colon (::) can only be used once within an address; otherwise, there would be more than one possible resulting address.

\begin{verbatim}
2001:0DB8:0000:1111:0000:0000:0000:0200
2001: DB8:   0:1111:   0:   0:   0: 200
2001: DB8:   0:1111::200
\end{verbatim}
\end{itemize}

\section{Types of IPv6 Addresses}

There are three types of IPv6 addresses: Unicast, Multicast, and Anycast. Unlike IPv4, IPv6 does not have a broadcast address. However, there is an IPv6 all-node multicast address that essentially gives the same result.

\subsection{Unicast IPv6}

An IPv6 unicast address uniquely identifies an interface on an IPv6-enabled device. There are three types of IPv6 unicast address: Global unicast, Link-local and Unique local unicast.

\paragraph{Global unicast:} A global unicast address  is a globally unique and Internet-routable address. The ICANN\footnote{Internet Committee for Assigned Names and Numbers} assigns IPv6 Global Unicast address to organization. A global unicast address has three parts: Global routing prefix, Subnet ID, Interface ID (Figure \ref{GUA}). The \textbf{global routing prefix} (first three hextets) is the network portion of the IPv6 address that is assigned by the ISP. The \textbf{Subnet ID} (fourth hextet) is used by an organization to identify subnets within its site. The \textbf{Interface ID} (last four hextets) is the host portion of the address.

\begin{figure}[hbtp]
\caption{Global routing prefix}\label{GUA}
\centering
\includegraphics[scale=0.6]{pictures/GUA.PNG}
\end{figure}

\paragraph{Link-local:} Link-local addresses are used to communicate with other devices on the same local link\footnote{With IPv6, the term link refers to a subnet.}. Packets with a source or destination link-local address cannot be routed beyond the link from which the packet originated. Their uniqueness must only be confirmed on that link. If a link-local address is not configured manually on an interface, the device will automatically create its own. IPv6 link-local addresses are in the \textbf{FE80::/10} range\footnote{The /10 indicates that the first 10 bits are 1111 1110 10xx xxxx. The first hextet has a range of 1111 1110 1000 0000 (FE80) to 1111 1110 1011 1111 (FEBF)}.

\paragraph{Dynamic Link-Local Addresses} A link-local address can be established dynamically or configured manually as a static link-local address. Operating systems will typically use either EUI-64 process or a randomly generated 64-bit number to dynamically assign link-local address. By default, Cisco routers use EUI-64 to generate the Interface ID for all link-local address on IPv6 interfaces. For serial interfaces, the router will use the MAC address of an Ethernet interface.

\paragraph{Static Link-Local Addresses} A drawback to using the dynamically assigned link-local address is its long interface ID, which makes it challenging to identify and remember assigned addresses. Configuring the link-local address manually provides the ability to create an address that is recognizable and easier to remember.

\begin{verbatim}
R1(config)# interface g0/0
R1(config-if)# ipv6 address fe80::1 link-local
\end{verbatim}

The link-local address in the above example is used to make it easily recognizable as belonging to router R1. The same IPv6 link-local address is configured on all of R1's interfaces. FE80::1 can be configured on each link because it only has to be unique on that link. Similar to R1, router R2 would be configured with FE80::2 as the IPv6 link-local address on all of its interfaces

\paragraph{Unique local unicast:}Unique local addresses are used for local addressing within a site or between a limited number of sites. These addresses should not be Internet-routable and should not be translated to a global IPv6 address. Unique local addresses can be used for devices that will never need or have access from another network. Unique local addresses are in the range of \textbf{FC00::/7 to FDFF::/7}.

\subsection{Multicast IPv6}

IPv6 multicast addresses have the prefix \textbf{FF00::/8}. Multicast addresses can only be destination addresses and not source addresses. There are two types of IPv6 multicast addresses: Assigned multicast address and Solicited node multicast address.

\paragraph{Assigned mulicast addresses} are reserved multicast addresses for predefined groups of devices. For example, \textbf{FF02::1} is the all-nodes multicast address, which has the same effect as broadcast IPv4 address. The all-routers multicast address \textbf{FF02::2} identifies a group of all IPv6 routers\footnote{A router with the ipv6 unicast-routing global configuration command executed} on the network.

\paragraph{A solicited-node multicast address} is mapped to a special Ethernet multicast address. This allows the Ethernet NIC to filter the frame by examining the destination MAC address.

\section{ICMPv6}

The informational and error messages found in ICMPv6 are very similar to the control and error messages implemented by ICMPv4. However, ICMPv6 has new features and improved functionality not found in ICMPv4. ICMPv6 includes four types of message: RS and RA message\footnote{Router Solicitation (RS) message, Router Advertisement (RA) message} (communication between a router and a device), NS and NA message\footnote{Neighbor Solicitation (NS) message, Neighbor Advertisement (NA) message} (communication between devices). Address resolution and DAD process use NA and NS message, while RS and RA message contribute to assigning IPv6 to devices.\\

\begin{figure}[hbtp]
\caption{Address Resolution}\label{AddressResolution}
\centering
\includegraphics[scale=1]{pictures/AddressResolution.PNG}
\end{figure}

\paragraph{Address resolution} acts like ARP of IPv4. It is used to determine the MAC address of a destination IPv6 address. A device will send an NS message to the solicited node address to ask for MAC address. The message will include the known (targeted) IPv6 address. The device that has the targeted IPv6 address will respond with an NA message containing its Ethernet MAC address. Figure \ref{AddressResolution} shows two PCs exchanging NS and NA messages.

\begin{figure}[hbtp]
\caption{DAD process}\label{DADprocess}
\centering
\includegraphics[scale=1]{pictures/DADprocess.PNG}
\end{figure}

\paragraph{DAD process} is a Duplicate Address Detection.  To check the uniqueness of an address, the device will send an NS message with its own IPv6 address as the targeted IPv6 address, shown in Figure \ref{DADprocess}. If another device on the network has this address, it will respond with an NA message. This NA message will notify the sending device that the address is in use. If a corresponding NA message is not returned within a certain period of time, the unicast address is unique and acceptable for use.

\section{EUI-64 Process}

When the RA message is either SLAAC or SLAAC with stateless DHCPv6, the client must generate its own Interface ID using EUI-64 Process or Randomly Generated. An EUI-64 Interface ID is represented in binary and is made up of three parts (Figure \ref{EUI64}):

\begin{itemize}
\item \textbf{24-bit OUI} from the client MAC address\footnote{Ethernet MAC addresses are made up of two parts: vendor code OUI assigned by IEEE and device identifier}, but the 7th bit (the Universally/Locally (U/L) bit) is reversed. This means that if the 7th bit is a 0, it becomes a 1, and vice versa.
\item The inserted 16-bit value \textbf{FFFE} (in hexadecimal).
\item \textbf{24-bit Device Identifier} from the client MAC address.
\end{itemize}

\begin{figure}[hbtp]
\caption{EUI-64 process}\label{EUI64}
\centering
\includegraphics[scale=1]{pictures/EUI64.PNG}
\end{figure}

The advantage of EUI-64 is the Ethernet MAC address can be used to determine the Interface ID. It also allows network administrators to easily track an IPv6 address to an end device using the unique MAC address. However, this has caused privacy concerns among many users. They are concerned that their packets can be traced to the actual physical computer. Due to these concerns, a randomly generated Interface ID may be used instead.

\section{IPv4 and IPv6 Coexistence}

Several techniques have been developed to accommodate a variety of transition IPv4-to-IPv6 scenarios:

\begin{itemize}
\item \textbf{Dual-stack:} A device interface is running both IPv4 and IPv6 protocols enabling it to communicate with either network.
\item \textbf{Tunneling:} The process of encapsulating an IPv6 packet inside an IPv4 packet. This allows the IPv6 packet to be transmitted over an IPv4-only network.
\item \textbf{Translation:} NAT64 allows IPv6-enabled devices to communicate with IPv4-enabled devices using a translation technique similar to NAT for IPv4. An IPv6 packet is translated to an IPv4 packet and vice versa.
\end{itemize}


\section{Metrics}
\label{chp:fundamentals:sec:metrics}

Usually different metrics are used to evaluate classification models.
This chapter defines required terms before the metrics are introduced in the following subsections.

When introducing metrics for predictions it is good practice to consider the prediction labels as \textit{positives} and \textit{negatives} respectively.
Then the correctly predicted positives are referred to as \acp{TP} and the incorrectly positive classified items as \acp{FP}.
The same scheme applies to the negatives and they are therefore distinguished into \acp{TN} and \acp{FN}. \parencite{Powers:2011}

In \cref{fig:metrics:tp_vis} an example algorithm retrieved three relevant items referred to as \acp{TP}.
The four items falsely classified as relevant are the \acp{FP}.
The missed relevant items are the \acp{FN}.
The algorithm falsely missed nine relevant items (\acp{FN}) in the example data of \cref{fig:metrics:tp_vis}.
The algorithm correctly did not select eleven irrelevant items (\acp{TN}).
We refer to the data shown in \cref{fig:metrics:tp_vis} when introducing the metrics in the following subsections.
\begin{figure}[htpb]
    \centering
    \def\svgwidth{\columnwidth}
    \input{figures/metrics/True_Positives.pdf_tex}
    \caption[Visualization of True Positives]{A visualization of \acp{TP}, \acp{FP}, \acp{TN} and \acp{FN}.}\label{fig:metrics:tp_vis}
\end{figure}

\input{chapters/02_fundamentals/sections/metrics/subsections/precision}
\input{chapters/02_fundamentals/sections/metrics/subsections/recall}
\input{chapters/02_fundamentals/sections/metrics/subsections/f1_score}
\input{chapters/02_fundamentals/sections/metrics/subsections/average_precision}


\chapter{The Enigma machine}
\label{chapter:enigma}

The Enigma machine is probably the most famous of all cryptographic
devices in history, due to the prominent role it played in
WWII~\cite{wiki:enigma}.\indEnigma The first Enigma machines were
available around 1920s, with various models in the market for
commercial use. When Germans used the Enigma during WWII, they were
using a particular model referred to as the {\em Wehrmacht Enigma}, a
fairly advanced model available at the time.

The most important role of Enigma\indEnigma is in its role in the use
of automated machines to aid in secret communication, or what is known
as \emph{mechanizing secrecy}.  One has to understand that computers
as we understand them today were not available when Enigma was in
operation. Thus, the Enigma employed a combination of mechanical
(keyboard, rotors, etc.)  and electrical parts (lamps, wirings, etc.)
to implement its functionality. However, our focus in this chapter
will not be on the mechanical aspects of Enigma at all. For a highly
readable account of that, we refer the reader to Singh's excellent
book on cryptography~\cite{Singh:1999:CBE}. Instead, we will model
Enigma in Cryptol in an algorithmic sense, implementing Enigma's
operations without any reference to the underlying mechanics. More
precisely, we will model an Enigma machine that has a plugboard, three
interchangeable scramblers, and a fixed reflector.

\todo[inline]{Add a photo or two of some Enigmas here.  Look into the
  WikiCommons.}

\todo[inline]{Provide an architectural diagram of this Cryptol
  construction somewhere reasonable and refer to it regularly to give
  the reader a better big-picture of how the spec hangs together
  vs.~the actual machine.}

%=====================================================================
% \section{The plugboard}
% \label{sec:enigma:plugboard}
\sectionWithAnswers{The plugboard}{sec:enigma:plugboard}

Enigma essentially implements a polyalphabetic substitution cipher
(\autoref{section:subst})\indPolyAlphSubst, consisting of a number
of rotating units that jumble up the alphabet.  The first component is
the so called plugboard (\textit{Steckerbrett} in
German)\indEnigmaPlugboard. In the original Enigma, the plugboard
provided a means of interchanging 6 pairs of letters. For instance,
the plugboard could be set-up so that pressing the {\tt B} key would
actually engage the {\tt Q} key, etc.  We will slightly generalize and
allow any number of pairings, as we are not limited by the
availability of cables or actual space to put them in a box! Viewed in
this sense, the plugboard is merely a permutation of the alphabet. In
Cryptol, we can represent the plugboard combination by a string of 26
characters, corresponding to the pairings for each letter in the
alphabet from {\tt A} to {\tt Z}:

\begin{code}
  type Permutation = String 26
  type Plugboard = Permutation
\end{code}
For instance, the plugboard matching the pairs {\tt A}-{\tt H}, {\tt
  C}-{\tt G}, {\tt Q}-{\tt X}, {\tt T}-{\tt V}, {\tt U}-{\tt Y}, {\tt
  W}-{\tt M}, and {\tt O}-{\tt L} can be created as follows:
\begin{code}
  plugboard : Plugboard
  plugboard = "HBGDEFCAIJKOWNLPXRSVYTMQUZ"
\end{code}
Note that if a letter is not paired through the plugboard, then it
goes untouched, i.e., it is paired with itself.

\begin{Exercise}\label{ex:enigma:1}
  Use Cryptol to verify that the above plugboard definition indeed
  implements the pairings we wanted.
\end{Exercise}
\begin{Answer}\ansref{ex:enigma:1}
We can simply ask Cryptol what the implied mappings are:
\begin{Verbatim}
  Cryptol> [ plugboard @ (c - 'A') | c <- "ACQTUWO" ]
  "HGXVYML"
\end{Verbatim}
Why do we subtract the {\tt 'A'} when indexing?
\end{Answer}

\note{In Enigma, the plugboard pairings are symmetric; if {\tt A} maps
  to {\tt H}, then {\tt H} must map to {\tt A}.}

%=====================================================================
% \section{Scrambler rotors}
% \label{sec:enigma:scramblerrotors}
\sectionWithAnswers{Scrambler rotors}{sec:enigma:scramblerrotors}

The next component of the Enigma are the rotors that scramble the
letters.  Rotors (\textit{walzen} in German)\indEnigmaRotor are
essentially permutations, with one little twist: as their name
implies, they rotate. This rotation ensures that the next character
the rotor will process will be encrypted using a different alphabet,
thus giving Enigma its polyalphabetic nature.\indPolyAlphSubst

The other trick employed by Enigma is how the rotations are done. In a
typical setup, the rotors are arranged so that the first rotor rotates
at every character, while the second rotates at every 26th, the third
at every 676th ($=26*26$), etc. In a sense, the rotors work like the
odometer in your car, one full rotation of the first rotor triggers
the second, whose one full rotation triggers the third, and so on. In
fact, more advanced models of Enigma allowed for two notches per
rotor, i.e., two distinct positions on the rotor that will allow the
next rotor in sequence to rotate itself. We will allow ourselves to
have any number of notches, by simply pairing each substituted letter
with a bit value saying whether it has an associated
notch:\footnote{The type definition for {\tt Char} was given in
  Example~\ref{section:subst}-\ref{ex:subst:1}.}

\begin{code}
  type Rotor = [26](Char, Bit)
\end{code}
The function {\tt mkRotor} will create a rotor for us from a given permutation of the letters and the notch
locations:\footnote{The function {\tt elem} was defined in \exerciseref{ex:recfun:4:1}.\indElem}
\begin{code}
  mkRotor : {n} (fin n) => (Permutation, String n) -> Rotor
  mkRotor (perm, notchLocations) = [ (p, elem (p, notchLocations))
                                   | p <- perm
                                   ]
\end{code}
\todo[inline]{A diagram here would be really useful, especially one
  that captures the location and use of notches and the state of these
  rotors before and after rotations.}
Let us create a couple of rotors with notches:
\begin{code}
  rotor1, rotor2, rotor3 : Rotor
  rotor1 = mkRotor ("RJICAWVQZODLUPYFEHXSMTKNGB", "IO")
  rotor2 = mkRotor ("DWYOLETKNVQPHURZJMSFIGXCBA", "B")
  rotor3 = mkRotor ("FGKMAJWUOVNRYIZETDPSHBLCQX", "CK")
\end{code}
For instance, {\tt rotor1} maps {\tt A} to {\tt R}, {\tt B} to {\tt J},
$\ldots$, and {\tt Z} to {\tt B} in its initial position. It will engage its
notch if one of the permuted letters {\tt I} or {\tt O} appear in its first
position.

\begin{Exercise}\label{ex:enigma:2}
  Write out the encrypted letters for the sequence of 5 {\tt C}'s for
  {\tt rotor1}, assuming it rotates in each step. At what points does
  it engage its own notch to signal the next rotor to rotate?
\end{Exercise}
\begin{Answer}\ansref{ex:enigma:2}
Recall that {\tt rotor1} was defined as:
\begin{Verbatim}
  rotor1 = mkRotor ("RJICAWVQZODLUPYFEHXSMTKNGB", "IO")
\end{Verbatim}
Here is a listing of the new mappings and the characters we will get
at the output for each successive {\tt C}:
\begin{Verbatim}
            starting map             output       notch engaged?
      RJICAWVQZODLUPYFEHXSMTKNGB       I              no
      JICAWVQZODLUPYFEHXSMTKNGBR       C              no
      ICAWVQZODLUPYFEHXSMTKNGBRJ       A              yes
      CAWVQZODLUPYFEHXSMTKNGBRJI       W              no
      AWVQZODLUPYFEHXSMTKNGBRJIC       V              no
\end{Verbatim}
Note how we get different letters as output, even though we are
providing the same input (all {\tt C}'s.) This is the essence of the
Enigma: the same input will not cause the same output necessarily,
making it a polyalphabetic substitution cipher.\indPolyAlphSubst
\end{Answer}

%=====================================================================
% \section{Connecting the rotors: notches in action}
% \label{sec:enigma:notches}
\sectionWithAnswers{Connecting the rotors: notches in action}{sec:enigma:notches}

\todo[inline]{A diagram here depicting rotor interchangeability and
  the relationship between \texttt{scramble} and rotors in the above
  figure.}

The original Enigma had three interchangeable rotors. The operator
chose the order they were placed in the machine. In our model, we will
allow for an arbitrary number of rotors. The tricky part of connecting
the rotors is ensuring that the rotations of each are done properly.

Let us start with a simpler problem.  If we are given a rotor and a
particular letter to encrypt, how can we compute the output letter and
the new rotor position?  First of all, we will need to know if the
rotor should rotate itself, that is if the notch between this rotor
and the previous one was activated. Also, we need to find out if the
act of rotation in this rotor is going to cause the next rotor to
rotate. We will model this action using the Cryptol function {\tt
  scramble}:
\begin{code}
  scramble : (Bit, Char, Rotor) -> (Bit, Char, Rotor)
\end{code}
The function {\tt scramble} takes a triple \texttt{(rotate, c, rotor)}:
\begin{itemize}
\item {\tt rotate}: if {\tt True}, this rotor will rotate after
  encryption. Indicates that the notch between this rotor and the
  previous one was engaged,
  \item {\tt c}: the character to encrypt, and
  \item {\tt rotor}: the current state of the rotor.
\end{itemize}
Similarly, the output will also be a triple:
\begin{itemize}
\item {\tt notch}: {\tt True} if the notch on this rotor engages,
  i.e., if the next rotor should rotate itself,
\item {\tt c'}: the result of encrypting (substituting) for {\tt c}
  with the current state of the rotor.
\item {\tt rotor'}: the new state of the rotor. If no rotation was
  done this will be the same as {\tt rotor}. Otherwise it will be the
  new substitution map obtained by rotating the old one to the left by
  one.
\end{itemize}
Coding {\tt scramble} is straightforward:
\begin{code}
  scramble (rotate, c, rotor) = (notch, c', rotor')
    where
      (c', _)    = rotor @ (c - 'A')
      (_, notch) = rotor @ 0
      rotor'     = if rotate then rotor <<< 1 else rotor
\end{code}
To determine {\tt c'}, we use the substitution map to find out what
this rotor maps the given character to, with respect to its current
state. Note how Cryptol's pattern matching notation\indPatMatch helps
with extraction of {\tt c'}, as we only need the character, not
whether there is a notch at that location.  (The underscore character
use, `\texttt{\_}',\indUnderscore means that we do not need the value
at the position, and hence we do not give it an explicit name.) To
determine if we have our notch engaged, all we need to do is to look
at the first elements notch value, using Cryptol's selection operator
({\tt @ 0}\indIndex), and we ignore the permutation value there this
time, again using pattern matching.  Finally, to determine {\tt
  rotor'} we merely rotate left by 1\indRotLeft if the {\tt rotate}
signal was received. Otherwise, we leave the {\tt rotor} unchanged.

\begin{Exercise}\label{ex:enigma:3}
  Redo \exerciseref{ex:enigma:2}, this time using Cryptol and the
  {\tt scramble} function.
\end{Exercise}
\begin{Answer}\ansref{ex:enigma:3}
  We can define the following value to simulate the operation of
  always telling {\tt scramble} to rotate the rotor and providing it
  with the input {\tt C}.
\begin{Verbatim}
 rotor1CCCCC = [(c1, n1), (c2, n2), (c3, n3), (c4, n4), (c5, n5)]
    where (n1, c1, r1) = scramble (True, 'C', rotor1)
          (n2, c2, r2) = scramble (True, 'C', r1)
          (n3, c3, r3) = scramble (True, 'C', r2)
          (n4, c4, r4) = scramble (True, 'C', r3)
          (n5, c5, r5) = scramble (True, 'C', r4)
\end{Verbatim}
\todo[inline]{Remind reader of simultaneity of \texttt{where}
  clauses.}  Note how we chained the output rotor values in the calls,
through the values {\tt r1}-{\tt r2}-{\tt r3} and {\tt r4}. We have:
\begin{Verbatim}
  Cryptol> rotor1CCCCC
  [(I, False), (C, False), (A, True), (W, False), (V, False)]
\end{Verbatim}
Note that we get precisely the same results from Cryptol as we
predicted in the previous exercise.
\end{Answer}

\note{The actual mechanics of the Enigma machine were slightly more
  complicated: due to the keyboard mechanism and the way notches were
  mechanically built, the first rotor was actually rotating before the
  encryption took place. Also, the middle rotor could double-step if
  it engages its notch right after the third rotor
  does~\cite{enigmaAnomaly}.

  We will take the simpler view here and assume that each key press
  causes an encryption to take place, {\em after} which the rotors do
  their rotation, getting ready for the next input. The mechanical
  details, while historically important, are not essential for our
  modeling purposes here. Also, the original Enigma had {\em rings}, a
  relatively insignificant part of the whole machine, that we ignore
  here.}

\paragraph*{Sequencing the rotors} Now that we have the rotors modeled,
the next task is to figure out how to connect them in a sequence. As
we mentioned, Enigma had 3 rotors originally (later versions allowing
4). The three rotors each had a single notch (later versions allowing
double notches).  Our model allows for arbitrary number of rotors and
arbitrary number of notches on each.  The question we now tackle is
the following: Given a sequence of rotors, how do we run them one
after the other? We are looking for a function with the following
signature:
\begin{code}
  joinRotors : {n} (fin n) => ([n]Rotor, Char) -> ([n]Rotor, Char)
\end{code}
That is, we receive {\tt n} rotors and the character to be encrypted,
and return the updated rotors (accounting for their rotations) and the
final character.  The implementation is an instance of the
fold\indFold pattern (\autoref{sec:recandrec}), using the {\tt
  scramble} function we have just defined:
\begin{code}
  joinRotors (rotors, inputChar) = (rotors', outputChar)
    where
      initRotor = mkRotor (['A' .. 'Z'], [])
      ncrs : [n+1](Bit, [8], Rotor)
      ncrs = [(True, inputChar, initRotor)]
                # [  scramble (notch, char, r)
                     | r <- rotors
                     | (notch, char, rotor') <- ncrs
                  ]
      rotors' = tail [ r | (_, _, r) <- ncrs ]
      (_, outputChar, _) = ncrs ! 0
\end{code}
The workhorse in {\tt joinRotors} is the definition of {\tt ncrs}, a
mnemonic for {\em notches-chars-rotors}. The idea is fairly simple.
We simply iterate over all the given rotors ({\tt r <- rotors}), and
{\tt scramble} the current character {\tt char}, using the rotor {\tt
  r} and the notch value {\tt notch}.  These values come from {\tt
  ncrs} itself, using the fold pattern\indFold encoded by the
comprehension\indComp.  The only question is what is the seed value
for this fold?

The seed used in {\tt ncrs} is {\tt (True, inputChar, initRotor)}. The
first component is {\tt True}, indicating that the very first rotor
should always rotate itself at every step. The second element is {\tt
  inputChar}, which is the input to the whole sequence of rotors. The
only mysterious element is the last one, which we have specified as
{\tt initRotor}.  This rotor is defined so that it simply maps the
letters to themselves with no notches on it, by a call to the {\tt
  mkRotor} function we have previously defined. This rotor is merely a
place holder to kick off the computation of {\tt ncrs}, it acts as the
identity element in a sequence of rotors.  To compute {\tt rotors'},
we merely project the third component of {\tt ncrs}, being careful
about skipping the first element using {\tt tail}\indTail.  Finally,
{\tt outputChar} is merely the output coming out of the final rotor,
extracted using {\tt !0}\indRIndex. Note how we use Cryptol's pattern
matching to get the second component out of the triple in the last
line.\indPatMatch

\begin{Exercise}\label{ex:enigma:4}
  Is the action of {\tt initRotor} ever used in the definition of {\tt
    joinRotors}?
\end{Exercise}
\begin{Answer}\ansref{ex:enigma:4}
  Not unless we receive an empty sequence of rotors, i.e., a call of
  the form: {\tt joinRotors ([], c)} for some character {\tt c}. In
  this case, it does make sense to return {\tt c} directly, which is
  what {\tt initRotor} will do. Note that unless we do receive an
  empty sequence of rotors, the value of {\tt initRotor} will not be
  used when computing the {\tt joinRotors} function.
\end{Answer}

\begin{Exercise}\label{ex:enigma:5}
What is the final character returned by the expression:
\begin{Verbatim}
  joinRotors ([rotor1 rotor2 rotor3], 'F')
\end{Verbatim}
Use paper and pencil to figure out the answer by tracing the execution
of {\tt joinRotors} before running it in Cryptol!
\end{Exercise}
\begin{Answer}\ansref{ex:enigma:5}
  The crucial part is the value of {\tt ncrs}. Let us write it out by
  substituting the values of {\tt rotors} and {\tt inputChar}:
\begin{Verbatim}
      ncrs = [(True, 'F', initRotor)]
               # [  scramble (notch, char, r)
                  | r <- [rotor1, rotor2, rotor3]
                  | (notch, char, rotor') <- ncrs
                  ]
\end{Verbatim}
Clearly, the first element of {\tt ncrs} will be:
\begin{Verbatim}
  (True, 'F', initRotor)
\end{Verbatim}
Therefore, the second element will be the result of the call:
\begin{Verbatim}
  scramble (True, 'F', rotor1)
\end{Verbatim}
Recall that {\tt rotor1} was defined as:
\begin{Verbatim}
  rotor1 = mkRotor ("RJICAWVQZODLUPYFEHXSMTKNGB", "IO")
\end{Verbatim}
What letter does {\tt rotor1} map {\tt F} to? Since {\tt F} is the 5th
character (counting from 0), {\tt rotor1} maps it to the 5th element
of its permutation, i.e., {\tt W}, remembering to count from 0!  The
topmost element in {\tt rotor1} is {\tt R}, which is not its
notch-list, hence it will {\em not} tell the next rotor to rotate. But
it will rotate itself, since it received the {\tt True} signal. Thus,
the second element of {\tt ncrs} will be:
\begin{Verbatim}
  (False, 'W', ...)
\end{Verbatim}
where we used {\tt ...} to denote the one left-rotation of {\tt
  rotor1}. (Note that we do not need to know the precise arrangement
of {\tt rotor1} now for the purposes of this exercise.) Now we move to
{\tt rotor2}, we have to compute the result of the call:
\begin{Verbatim}
  scramble (False, 'W', rotor2)
\end{Verbatim}
Recall that {\tt rotor2} was defined as:
\begin{Verbatim}
  rotor2 = mkRotor ("DWYOLETKNVQPHURZJMSFIGXCBA", "B")
\end{Verbatim}
So, it maps {\tt W} to {\tt X}. (The fourth letter from the end.)  It
will not rotate itself, and it will not tell {\tt rotor3} to rotate
itself either since the topmost element is {\tt D} in its current
configuration, and {\tt D} which is not in the notch-list {\tt
  "B"}. Thus, the final {\tt scramble} call will be:
\begin{Verbatim}
  scramble (False, 'X', rotor3)
\end{Verbatim}
where
\begin{Verbatim}
  rotor3 = mkRotor ("FGKMAJWUOVNRYIZETDPSHBLCQX", "CK")
\end{Verbatim}
It is easy to see that {\tt rotor3} will map {\tt X} to {\tt C}. Thus
the final value coming out of this expression must be {\tt C}. Indeed,
we have:\indTupleProj
\begin{Verbatim}
  Cryptol> project(2, 2, joinRotors ([rotor1 rotor2 rotor3], 'F'))
  C
\end{Verbatim}
Of course, Cryptol also keeps track of the new rotor positions as
well, which we have glossed over in this discussion.
\end{Answer}

%=====================================================================
% \section{The reflector}
% \label{sec:enigma:reflector}
\sectionWithAnswers{The reflector}{sec:enigma:reflector}

The final piece of the Enigma machine is the
reflector\indEnigmaReflector ({\em umkehrwalze} in German). The
reflector is another substitution map. Unlike the rotors, however, the
reflector did not rotate.  Its main function was ensuring that the
process of encryption was reversible: The reflector did one final
jumbling of the letters and then sent the signal back through the
rotors in the {\em reverse} order, thus completing the loop and
allowing the signal to reach back to the lamps that would light up.
For our purposes, it suffices to model it just like any other
permutation:
\begin{code}
  type Reflector = Permutation
\end{code}
Here is one example:
\begin{code}
  reflector : Reflector
  reflector = "FEIPBATSCYVUWZQDOXHGLKMRJN"
\end{code}
Like the plugboard, the reflector is symmetric: If it maps {\tt B} to
{\tt E}, it should map {\tt E} to {\tt B}, as in the above
example. Furthermore, the Enigma reflectors were designed so that they
never mapped any character to themselves, which is true for the above
permutation as well. Interestingly, this idea of a non-identity
reflector (i.e., never mapping any character to itself) turned out to
be a weakness in the design, which the allies exploited in breaking
the Enigma during WWII~\cite{Singh:1999:CBE}.

\begin{Exercise}\label{ex:enigma:6}
Write a function {\tt checkReflector} with the signature:
\begin{Verbatim}
  checkReflector : Reflector -> Bit
\end{Verbatim}
such that it returns {\tt True} if a given reflector is good (i.e.,
symmetric and non-self mapping) and {\tt False} otherwise. Check that
our definition of {\tt reflector} above is a good one. \lhint{Use the
  {\tt all} function you have defined in
  \exerciseref{ex:zero:1}.}
\end{Exercise}
\begin{Answer}\ansref{ex:enigma:6}
%% if this is {code} we have two all's
\begin{Verbatim}
  all : {n, a} (fin n) => (a -> Bit) -> [n]a -> Bit
  all f xs = [ f x | x <- xs ] == ~zero

  checkReflector refl = all check ['A' .. 'Z']
    where check c = (c != m) && (c == c')
             where   m  = refl @ (c - 'A')
                     c' = refl @ (m - 'A')
\end{Verbatim}
For each character in the alphabet, we first figure out what it maps
to using the reflector, named {\tt m} above. We also find out what
{\tt m} gets mapped to, named {\tt c'} above. To be a valid reflector
it must hold that {\tt c} is not {\tt m} (no character maps to
itself), and {\tt c} must be {\tt c'}. We have:
\begin{Verbatim}
  Cryptol> checkReflector reflector
  True
\end{Verbatim}
Note how we used {\tt all}\indAll to make sure {\tt check} holds for
all the elements of the alphabet.
\end{Answer}

%=====================================================================
% \section{Putting the pieces together}
% \label{sec:enigma:puttingittogether}
\sectionWithAnswers{Putting the pieces together}{sec:enigma:puttingittogether}

We now have all the components of the Enigma: the plugboard, rotors,
and the reflector.  The final task is to implement the full loop. The
Enigma ran all the rotors in sequence, then passed the signal through
the reflector, and ran the rotors in reverse one more time before
delivering the signal to the lamps.

Before proceeding, we will define the following two helper functions:
\begin{code}
  substFwd, substBwd : (Permutation, Char) -> Char
  substFwd (perm, c) = perm @ (c - 'A')
  substBwd (perm, c) = invSubst (perm, c)
\end{code}
(You have defined the {\tt invSubst} function in
\exerciseref{ex:subst:1}.) The {\tt substFwd}
function simply returns the character that the given permutation,
whether from the plugboard, a rotor, or the reflector. Conversely,
{\tt substBwd} returns the character that the given permutation maps
{\em from}, i.e., the character that will be mapped to {\tt c} using
the permutation.

\begin{Exercise}\label{ex:enigma:7}
  Using Cryptol, verify that {\tt substFwd} and {\tt substBwd} return
  the same elements for each letter in the alphabet for {\tt rotor1}.
\end{Exercise}
\begin{Answer}\ansref{ex:enigma:7}
  We can define the following helper function, using the function {\tt
    all} you have defined in
  \exerciseref{ex:zero:1}:\indAll
\begin{code}
  checkPermutation : Permutation -> Bit
  checkPermutation perm = all check  ['A' .. 'Z']
    where check  c = (c == substBwd(perm, substFwd (perm, c)))
                  && (c == substFwd(perm, substBwd (perm, c)))
\end{code}
Note that we have to check both ways (first {\tt substFwd} then {\tt
  substBwd}, and also the other way around) in case the substitution
is badly formed, for instance if it is mapping the same character
twice. We have:
\begin{Verbatim}
  Cryptol> checkPermutation [ c | (c, _) <- rotor1 ]
  True
\end{Verbatim}
For a bad permutation we would get {\tt False}:
\begin{Verbatim}
  Cryptol> checkPermutation (['A' .. 'Y'] # ['A'])
  False
\end{Verbatim}
\end{Answer}

\begin{Exercise}\label{ex:enigma:8}
  Show that {\tt substFwd} and {\tt substBwd} are exactly the same
  operations for the reflector. Why?
\end{Exercise}
\begin{Answer}\ansref{ex:enigma:8}
  Since the reflector is symmetric, substituting backwards or forwards
  does not matter. We can verify this with the following helper
  function:\indAll
\begin{code}
  all : {a, b} (fin b) => (a -> Bit) -> [b]a -> Bit
  all fn xs = folds ! 0 where
    folds = [True] # [ fn x && p | x <- xs
                                 | p <- folds]
  checkReflectorFwdBwd : Reflector -> Bit
  checkReflectorFwdBwd refl = all check ['A' .. 'Z']
    where check c = substFwd (refl, c) == substBwd (refl, c)
\end{code}
We have:
\begin{Verbatim}
  Cryptol> checkReflectorFwdBwd reflector
  True
\end{Verbatim}
\end{Answer}

\paragraph*{The route back} One crucial part of the Enigma is the
running of the rotors in reverse after the reflector. Note that this
operation ignores the notches, i.e., the rotors do not turn while the
signal is passing the second time through the rotors. (In a sense, the
rotations happen after the signal completes its full loop, getting to
the reflector and back.)  Consequently, it is much easer to code as
well (compare this code to {\tt joinRotors}, defined in
\autoref{sec:enigma:notches}):

\begin{code}
  backSignal : {n} (fin n) => ([n]Rotor, Char) -> Char
  backSignal (rotors, inputChar) = cs ! 0
    where
      cs = [inputChar] # [  substBwd ([ p | (p, _) <- r ], c)
                         | r <- reverse rotors
                         | c <- cs
                         ]
\end{code}
Note that we explicitly reverse the rotors in the definition of {\tt
  cs}.\indReverse (The definition of {\tt cs} is another typical
example of a fold. See page~\pageref{par:fold}.)\indFold

Given all this machinery, coding the entire Enigma loop is fairly
straightforward:
\begin{code}
  //enigmaLoop : {n} (fin n) => (Plugboard, [n]Rotor, Reflector, Char)
  //                         -> ([n]Rotor, Char)
  enigmaLoop (pboard, rotors, refl, c0) = (rotors', c5)
    where
      // 1. First run through the plugboard
      c1 = substFwd (pboard, c0)
      // 2. Now run all the rotors forward
      (rotors', c2) = joinRotors (rotors, c1)
      // 3. Pass through the reflector
      c3 = substFwd (refl, c2)
      // 4. Run the rotors backward
      c4 = backSignal(rotors, c3)
      // 5. Finally, back through the plugboard
      c5 = substBwd (pboard, c4)
\end{code}

%=====================================================================
\section{The state of the machine}
\label{sec:state-machine}

We are almost ready to construct our own Enigma machine in
Cryptol. Before doing so, we will take a moment to represent the state
of the Enigma machine as a Cryptol record\indTheRecordType, which will
simplify our final construction. At any stage, the state of an Enigma
machine is given by the status of its rotors. We will use the
following record to represent this state, for an Enigma machine
containing \texttt{n} rotors:
\begin{code}
  type Enigma n = { plugboard : Plugboard,
                    rotors    : [n]Rotor,
                    reflector : Reflector
                  }
\end{code}
To initialize an Enigma machine, the operator provides the plugboard
settings, rotors, the reflector. Furthermore, the operator also gives
the initial positions for the rotors.  Rotors can be initially rotated
to any position before put together into the machine. We can capture
this operation with the function {\tt mkEnigma}:
\begin{code}
  mkEnigma : {n} (Plugboard, [n]Rotor, Reflector, [n]Char)
                 -> Enigma n
  mkEnigma (pboard, rs, refl, startingPositions) =
      { plugboard  = pboard,
        rotors     = [ r <<< (s - 'A')
                     | r <- rs
                     | s <- startingPositions
                     ],
        reflector  = refl
      }
\end{code}
Note how we rotate each given rotor to the left by the amount given by
its starting position.

\todo[inline]{Connect ``left'' with up/down in the earlier
  illustrations.}

Given this definition, let us construct an Enigma machine out of the
components we have created so far, using the starting positions {\tt
  GCR} for the rotors respectively:\label{def:modelEnigma}
\begin{code}
  modelEnigma : Enigma 3
  modelEnigma = mkEnigma (plugboard, [rotor1, rotor2, rotor3],
                          reflector, "GCR")
\end{code}
We now have an operational Enigma machine coded up in Cryptol!

%=====================================================================
% \section{Encryption and decryption}
% \label{enigma:encdec}
\sectionWithAnswers{Encryption and decryption}{enigma:encdec}

Equipped with all the machinery we now have, coding Enigma encryption
is fairly straightforward:
\begin{code}
  enigma : {n, m} (fin n, fin m) => (Enigma n, String m) -> String m
  enigma (m, pt) = tail [ c | (_, c) <- rcs ]
    where rcs = [(m.rotors, '*')] #
                [ enigmaLoop (m.plugboard, r, m.reflector, c)
                | c      <- pt
                | (r, _) <- rcs
                ]
\end{code}
The function {\tt enigma} takes a machine with {\tt n} rotors and a
plaintext of {\tt m} characters, returning a ciphertext of {\tt m}
characters back.  It is yet another application of the fold pattern,
where we start with the initial set of rotors and the placeholder
character {\tt *} (which could be anything) to seed the fold.\indFold
Note how the change in rotors is reflected in each iteration of the
fold, through the {\tt enigmaLoop} function. At the end, we simply
drop the rotors from {\tt rcs}, and take the {\tt tail}\indTail to
skip over the seed character {\tt *}.

Here is our Enigma in operation:
\begin{Verbatim}
  Cryptol> :set ascii=on
  Cryptol> enigma (modelEnigma, "ENIGMAWASAREALLYCOOLMACHINE")
  "UPEKTBSDROBVTUJGNCEHHGBXGTF"
\end{Verbatim}

\paragraph*{Decryption} As we mentioned before, Enigma was a
self-decrypting machine, that is, encryption and decryption are
precisely the same operations. Thus, we can define:
\begin{code}
  dEnigma : {n, m} (fin n, fin m) => (Enigma n, String m) -> String m
  dEnigma = enigma
\end{code}
And decrypt our above message back:
\begin{Verbatim}
  Cryptol> dEnigma (modelEnigma, "UPEKTBSDROBVTUJGNCEHHGBXGTF")
  "ENIGMAWASAREALLYCOOLMACHINE"
\end{Verbatim}
We have successfully performed our first Enigma encryption!

\begin{Exercise}\label{ex:enigma:9}
  Different models of Enigma came with different sets of rotors. You
  can find various rotor configurations on the
  web~\cite{wiki:enigmarotors}.  Create models of these rotors in
  Cryptol, and run sample encryptions through them.
\end{Exercise}

\begin{Exercise}\label{ex:enigma:10}
  As we have mentioned before, Enigma implements a polyalphabetic
  substitution cipher\indPolyAlphSubst, where the same letter gets
  mapped to different letters during encryption. The
  period\indSubstPeriod of a cipher is the number of characters before
  the encryption repeats itself, mapping the same sequence of letters
  in the plaintext to the to the same sequence of letters in the
  ciphertext. What is the period of an Enigma machine with $n$ rotors?
\end{Exercise}
\begin{Answer}\ansref{ex:enigma:10}
  Enigma will start repeating once the rotors go back to their
  original position.  With $n$ rotors, this will take $26^n$
  characters. In the case of the traditional 3-rotor Enigma this
  amounts to $26^3 = 17576$ characters. Note that we are assuming an
  ideal Enigma here with no double-stepping~\cite{enigmaAnomaly}.
\end{Answer}

\begin{Exercise}\label{ex:enigma:11}
  Construct a string of the form {\tt CRYPTOLXXX...XCRYPTOL}, where
  ...'s are filled with enough number of {\tt X}'s such that
  encrypting it with our {\tt modelEnigma} machine will map the
  instances of ``{\tt CRYPTOL}'' to the same ciphertext. How many {\tt
    X}'s do you need? What is the corresponding ciphertext for ``{\tt
    CRYPTOL}'' in this encryption?
\end{Exercise}
\begin{Answer}\ansref{ex:enigma:11}
  Since the period\indSubstPeriod for the 3-rotor Enigma is 17576 (see
  the previous exercise), we need to make sure two instances of {\tt
    CRYPTOL} are 17576 characters apart. Since {\tt CRYPTOL} has 7
  characters, we should have 17569 X's. The following Cryptol
  definition would return the relevant pieces:
\begin{code}
  enigmaCryptol = (take`{7} ct, drop`{17576} ct)
    where   str = "CRYPTOL" # [ 'X' | _ <- [1 .. 17569] ]
                  # "CRYPTOL"
            ct  = dEnigma(modelEnigma, str)
\end{code}
We have:
\begin{Verbatim}
  Cryptol> enigmaCryptol
  ("KGSHMPK", "KGSHMPK")
\end{Verbatim}
As predicted, both instances of {\tt CRYPTOL} get encrypted as {\tt
  KGSHMPK}.
\end{Answer}

\paragraph*{The code} You can see all the Cryptol code for our Enigma
simulator in Appendix~\ref{app:enigma}.

\commentout{
\begin{code}
  invSubst : (Permutation, Char) -> Char
  invSubst (key, c) = candidates ! 0
      where candidates = [0] # [ if c == k then a else p
                               | k <- key
                               | a <- ['A' .. 'Z']
                               | p <- candidates
                               ]
  elem : {a, b} (fin 0, fin a, Cmp b) => (b, [a]b) -> Bit
  elem (x, xs) = matches ! 0
      where matches = [False] # [ m || (x == e)  | e <- xs
                                                 | m <- matches
                                ]
  sanityCheck = enigma  (modelEnigma, "ENIGMAWASAREALLYCOOLMACHINE") == "UPEKTBSDROBVTUJGNCEHHGBXGTF"
\end{code}
}

%%% Local Variables:
%%% mode: latex
%%% TeX-master: "../main/Cryptol"
%%% End:


\subsection{gammapy.modeling}
\label{ssec:gammapy-modeling}
\todo{Quentin Remy}
Models and fitting

\begin{figure}
	\import{code-examples/generated/}{gp_models}
	\caption{Using gammapy.modeling.models}
	\label{fig*:minted:gp_models}
\end{figure}


\section{Determinize}
\label{App:DeterminizeAlgorithm}

We found the explanations of how to determinize NWAs that are given
in~\cite{DLT:AM2006,JACM:AM2009} to be confusing (and contradictory between
the two accounts), and so we reformulated it using relational
operations.

We use the following notation in the determinize algorithm: \\
\begin{quote}
\begin{tabular}{ll}
  $(Q, \Sigma, \delta, Q_0, Q_f)$\hspace{1em}
                                     & The components of the input automaton \texttt{nwa} \\
  $\delta_i|_\sigma$                 & The binary relation $\{(p,q) | (p, \sigma, q) \in\delta_i\}$ \\
  $\delta_c|_\sigma$                 & The binary relation $\{(p,q) | (p, \sigma, q) \in\delta_c\}$ \\
  $\delta_r|_\sigma$                 & The binary relation $\{(p,q) | \exists c. (p, c, \sigma, q) \in\delta_r\}$ \\
  $R \circ S$                        & Relational composition of the binary relations $R$ and $S$ \\
  $R^*$                              & Transitive closure of the binary relation $R$ \\
  $Q^{new}, \delta^{new}$            & Components of the determinized NWA \\
\end{tabular}
\end{quote}
We use the following auxiliary function to compute the target of
a return transition:
\begin{eqnarray*}
  \textrm{Merge}(R^{exit}, R^{call}, \delta) = \{(q, q') & |& \exists q_1, q_2.\,(q, q_1) \in R^{call} \\
                                                         &&  \phantom{\exists q_1, q_2.\,}\textrm{and}\ (q_1, q_2) \in R^{exit} \\
                                                         &&  \phantom{\exists q_1, q_2.\,}\textrm{and}\ (q_2, q_1, q') \in \delta\}
\end{eqnarray*}

Each state $R$ in the determinized automaton is a binary relation on states
in the original. In a standard determinized FA, a state $\{q_0, q_1,
\cdots, q_n\}$ means the automaton can be in state $q_0$ of the original FA, or in
state $q_1$ of the original, etc. For NWAs, a state $\{(p_0, q_0), (p_1,
q_1), \cdots, (p_n, q_n)\}$ means that the NWA is one of the states $\{q_0,
q_1, \cdots, q_n\}$, but the relation carries around extra meaning.

If a state in the determinized automaton contains a pair $(p,q)$, then this
means the input automaton can begin in the state $p$, immediately perform a call
transition, follow a path with balanced calls and returns, and finally arrive
in state $q$. In such a configuration, if the input automaton then reads a
return symbol, $q$ is the exit site and $p$ is the call predecessor. These
two pieces of information are exactly what the automaton needs to decide what
return transitions it can take. The call predecessor $p$ needs to be stored
explicitly because it is possible to arrive at the same state $q$ with
different call predecessors.

At the start of the run, and any time the automaton has not read any pending
calls, the first component of each pair in the current state will be some $q
\in Q_0$; this is because the initial states act as call predecessors in that
situation.

\newcommand{\WL}{\textit{WL}}

\newpage
\begin{algorithm}[H]
  \hrule
  \DontPrintSemicolon
  \SetAlgorithmName{Listing}{listing}{listing}
  \SetKw{Int}{int}
  \SetKw{Boolean}{bool}
  \SetKwBlock{DetDef}{determinize(NWA nwa)}{end}
  \SetKwFunction{Merge}{Merge}

  \DetDef{
    $Close$ = $(\delta_i |_\epsilon)^*$\;
    $R_0$ = $Q_0 \times Q_0 \circ Close$\;
    $Q^{new}$ = $\{R_0\}$\;
    Insert $R_0$ in \WL\;
    \While{$\WL \neq \varnothing$}{
      select and remove a relation $R$ from \WL\;
      \tcp{Note that $R$ is a state in $Q^{new}$}
      mark $R$\;
      \For{$\sigma\in\Sigma$}{
        \tcp{Compute internal transitions}
        $R^i$ = $R \circ \delta_i|_\sigma \circ Close$\;
        $Q^{new}$ = $Q^{new} \cup \{R^i\}$\;
        Insert $R \overset{\sigma}{\rightarrow} R^i$ into $\delta_i^{new}$\;
        \If{$R^i$ unmarked}{
          $WL$ = $WL \cup \{R^i\}$\;
        }
        \BlankLine
        \tcp{Compute call transitions}
        $R^c$ = $Close \circ \delta_c|_\sigma \circ Close$\;
        $Q^{new}$ = $Q^{new} \cup \{R^c\}$\;
        Insert $R \overset{\sigma}{\rightarrow} R^c$ into $\delta_c^{new}$\;
        \If{$R^c$ unmarked}{
          $WL$ = $WL \cup \{R^c\}$\;
        }
        \BlankLine
        \tcp{Compute return transitions where $R$ appears as the exit node}
        \For{$R^{call} \in Q^{new}$}{
          $R^r$ = $\Merge(R, R^{call}, \delta_r|_\sigma) \circ Close$\;
          $Q^{new}$ = $Q^{new} \cup \{R^r\}$\;
          Insert $(R, R^{call}, \sigma, R^r)$ into $\delta_r^{new}$\;
          \If{$R^r$ unmarked}{
            $WL$ = $WL \cup \{R^r\}$\;
          }
        }
        \BlankLine
        \tcp{Compute return transitions with $R$ as the call predecessor}
        \For{$R^{exit} \in Q^{new}$}{
          $R^r$ = $\Merge(R^{exit}, R, \delta_r|_\sigma) \circ Close$\;
          $Q^{new}$ = $Q^{new} \cup \{R^r\}$\;
          Insert $(R^{exit}, R, \sigma, R^r)$ into $\delta_r^{new}$\;
          \If{$R^r$ unmarked}{
            $WL$ = $WL \cup \{R^r\}$\;
          }
        }
      }
    }
    \tcp{end worklist while loop}
    $Q_f^{new}$ = $\{R \in Q^{new} |\ \textrm{there is}\ (p,q) \in R
                                      \ \textrm{with}\ q \in Q_f\}$\;
    \Return{$(Q^{new}, \Sigma, \delta^{new}, \{R_0\}, Q_f^{new})$}\;
  }
  \hrule
\end{algorithm}


\documentclass[11pt, a4paper]{article}

\title{Dynamic Rate Control for Retro Game Emulators}
\author{Hans-Kristian Arntzen}

\usepackage{amsmath}
\usepackage{float}
\usepackage{graphicx}

\begin{document}
\maketitle

\begin{abstract}
This article describes a method for game emulator frontends
to synchronize both audio and video output at the same time, even
when the emulating system has a different refresh rate and audio sampling rate
than the gaming system that is being emulated.

The method works by dynamically adjusting audio resampling ratios in such ways that
ideally, the audio buffer is never underrun nor overrun, thus avoiding blocking on audio.
This in turn allows vertical synchronization for video.

The audio pitch is adjusted when adjusting audio resampling ratios,
but in practice so little, that it is inaudible to the human ear.
\end{abstract}

\section{Background}

Retro game consoles are highly synchronous. Their audio output rates are linked directly
to video refresh rates. Every video frame, the audio chip generates on average a fixed amount of audio samples. Before continuing to emulate the next frame, the generated audio samples must be pushed
to an audio buffer of fixed size.

If there is not enough space in the audio buffer, the emulator must wait (block) for the buffer to become ready for writing. This is a non-ideal situation as while the emulator is blocking on audio, a vertical refresh might be missed entirely, thus creating stuttering video.

\subsection{The ideal synchronization}
For an emulator of a retro game system, a key factor in smooth video is vertical refresh synchronization (VSync), where each frame of the game maps to a single frame on the monitor.
Audio must also be pushed to the speakers without any audio dropouts.
This double synchronization requirement poses a problem as any form of synchronization to one modality
will negatively affect the other.

This is a real problem as an emulator has no way of guaranteeing perfectly equal
video refresh rates and audio sampling rates as the original system.

On conventional computer hardware, there is no perfect way of knowing
the real monitor refresh rates and audio sampling rates either due to
tolerances on oscillators.

\subsection{Scope of method}
As this method aims to implement a method for synchronization when VSync is used,
this method is only useful when game frame rate is close to monitor frame rate.
If this is not the case, other methods should be employed.

\section{Method}
This method assumes that audio from the emulator is output at regular intervals, e.g.
every video frame. The method also assumes that audio is resampled from
the game system sampling rate to the sound cards sampling rate.
The resampling ratio will be dynamically adjusted every time audio is resampled and subsequently pushed to the audio buffer.

\subsection{Definitions}
\begin{itemize}
\item[$f_v$] Emulated game system frame rate (FPS)
\item[$f_a$] Emulated game system sampling rate (Hz)
\item[$r$] Emulated game system samples per frame $f_a / f_v$
\item[$m_a$] Emulator system sampling rate
\item[$m_v$] Emulator system monitor refresh rate
\item[$m_a^{'}$] Estimated emulator system sampling rate
\item[$m_v^{'}$] Estimated emulator system monitor refresh rate
\item[$R$] Emulator system samples per frame $m_a / m_v$
\item[$R^{'}$] Estimated emulator system samples per frame $m_a^{'} / m_v^{'}$
\item[$A_b$] Current amount of samples in the audio buffer
\item[$A_B$] Capacity (in samples) of the audio buffer
\item[$d$] Allowed deviation in audio pitch
\end{itemize}

\subsection{Resampling audio}
Every time the game system outputs audio, it is resampled with some ratio.
It is here assumed that the game system outputs a video frame worth of audio at a time.
While the formulae are invariant to how often audio is written to audio buffers, this assumption
is made for simplicity.

The correct resampling ratio is estimated to be $R^{'} / r$,
thus pushing $R^{'}$ samples of audio per frame on average.
In the duration of a frame, on average, $R$ audio frames will have been played to the speakers
and thus removed from the buffer.

\begin{equation}
\Delta A_b = R^{'} - R
\end{equation}

We see that unless $\Delta A_b = 0$, it is inevitable that the audio will either underrun ($A_b \leq 0$),
or block due to buffer being full ($A_b \geq A_B$).
Both these situations are not acceptable as underruns would cause audible audio dropouts,
and blocking would block the emulator from emulating more frames, and thus greatly increasing the chance of missing a VBlank, which is not acceptable as well. Blocking however, is far more preferable than underrunning.

As with any estimator, it is impossible to guarantee that $R^{'}$ can be perfectly estimated.
Therefore, it is impossible to guarantee that underrun nor blocking occurs.

\subsection{Dynamic rate control}
The proposed method will dynamically adjust the resampling ratio $R^{'} / r$.
Changing this ratio will adjust audio pitch as well. To ensure that these adjustments are not audible to the human ear, the range of adjustment will be limited by $d$.

Using $d$, the maximum pushed samples will be $R^{'} \left(1 + d\right)$,
and similarly, minimum will be $R^{'} \left(1 - d\right)$.
$d$ must be chosen so that $R$ falls between minimum or maximum. This depends on the confidence of the estimate $R^{'}$.

The revised update formula will look like this:

\begin{equation} \label{eq:update}
\Delta A_b = \left[ 1 + \left(\frac{A_B - 2A_b}{A_B}\right) d \right] R^{'} - R
\end{equation}

The formula will decrease resampling ratio if audio buffer is over half full, and similarly increase
resampling ratio if buffer is below half full.

\subsection{Stability}

To ensure that the method is stable, i.e. that $A_b$ will converge to a certain value,
we assume a continuous model for pushing audio.

\begin{equation}
\frac{\delta A_b}{\delta f} = \left[ 1 + \left(\frac{A_B - 2A_b}{A_B}\right) d \right] R^{'} - R
\end{equation}
\begin{equation} \label{eq:ab-diff}
\frac{\delta A_b}{\delta f} + \frac{2dR^{'}}{A_B}A_b = R^{'} \left(1 + d\right) - R
\end{equation}

The differential equation in \eqref{eq:ab-diff} can be solved as

\begin{equation}
A_b = A_B \frac{R^{'}\left(1 + d\right) - R}{2dR^{'}} + C_0\exp \left(-\frac{2dR^{'}}{A_B} f\right)
\end{equation}

Given time ($f \rightarrow \infty$), this expression converges to

\begin{equation}
A_{b,c} = A_B \frac{R^{'}\left(1 + d\right) - R}{2dR^{'}}
\end{equation}

If $R^{'}$ is the ideal estimate, $R^{'} = R$, the expression converges to

\begin{equation}
A_{b,c} = A_B / 2
\end{equation}
which is the best case, as having a half full buffer means most possible wiggle room for jitter.

\subsection{Updating ratio estimate $R^{'}$}
After time, it is assumed that $A_b$ will converge to $A_{b,c}$.
Due to jitter, and various non-ideal behavior, only an estimate of $A_{b,c}$, $\hat{A_{b,c}} = \bar{A_b}$ can be obtained.

\begin{equation}
\frac{\hat{R^{'}}}{R} = \frac{A_B}{\left(1 + d\right) A_B - 2d\hat{A_{b,c}}}
\end{equation}

The ratio estimate $R^{'}$ can thus be re-estimated accordingly. This method of re-estimating the ratio might however not be the best. Directly estimating $m_a^{'}$ and $m_v^{'}$ should yield more confident results, but this is outside the scope of this article.

\section{Results}

A synthetic test was carried out to test how the method would react to a common scenario for this method. An emulation of Super Nintendo Entertainment System (SNES) was matched to an emulating system.
To test effects of jitter, the frame time was assumed to follow a normal distribution.
Thus, $R$ in \eqref{eq:update} followed a normal distribution.

\begin{table}[H]
\centering
\caption{Timings}
\begin{tabular}{|c|c|c|}
	\hline
	System & FPS (Hz) & Sample rate (Hz)\\\hline
	SNES & 60.0988 & 32040.5\\\hline
	Emulating system & 59.88 & 48000.15\\\hline
	Estimated system & 59.95 & 48000.0\\\hline
\end{tabular}
\end{table}

\begin{table}[H]
\centering
\caption{Test parameters}
\begin{tabular}{|c|c|}
	\hline
	$d$ & $0.005$\\\hline
	Frame time deviation & $2 \%$\\\hline
\end{tabular}
\end{table}

\begin{figure}[H]
\centering
\includegraphics[width=12cm]{ratecontrol-data.pdf}
\caption{Results with 2\% standard deviation on frame time}
\end{figure}

The results are shown for audio buffer size over time and the pitch modulation for every simulated frame. Audio pitch modulation deviation was estimated to $0.062\%$, significantly lower than the $d$ value, which allowed for a maximum deviation of $0.5\%$.

The audio buffer is never filled nor underrun, which would allow every single VBlank to be met, while maintaining audio sync.

\section{Discussion}

\subsection{Effect of $d$}
Ideally, $d$ should be as low as possible to avoid large deviations in pitch, but at the same time, a too low value for $d$ will not be able to compensate for the difference between $R^{'}$ and $R$.
From testing in the emulator frontend RetroArch\footnote{https://github.com/Themaister/RetroArch}, a factor of $d \geq 0.002, d \leq 0.005$ has been found to give satisfactory results.

This method does not propose a method of determining the best $d$ factor.

\subsection{Audibility}
As audio pitch is altered, there is a question of audibility. Given a small enough $d$, it's
clear that the effect would be completely inaudible as all oscillators in a DAC have tolerances and jitter to some degree. It is also reasonable to believe that some persons are able to notice a smaller $d$ than others.

Some testing must be carried out to find a $d$ that is inaudible in subjective tests.

\section{Conclusion}
This method shows that it is possible to obtain synchronization to both VBlank and audio without having a perfect estimate of the emulating systems frequencies. As long as the estimates are reasonable close to the real values, the dynamic rate control method proposed here is able to smooth out the differences.

\end{document}


\subsection{Parallel lines and planes}

\subsubsection{Parallel lines}

If we have two lines:

\subsubsection{Parallel planes}


\section{Generalised Least Squares (GLS)}


In this section we discuss games and their complexity through a case study. We consider a sample which fits within the space constraints of a paper, which at the same time shows the complex interactions that are typical for games.

\subsection{Running example}
The running example we use is a patrol moving through checkpoints. The state of the patrol is made up by the position of the patrol \texttt{P}, and its velocity \texttt{V}.
\begin{lstlisting}
P is a 2D Vector
V is a 2D Vector
Checkpoints is a list of 2D Vectors
\end{lstlisting}
The logic of the game is given using a pseudo language:
\begin{lstlisting}
P is integrated by V over dt
V points towards the next checkpoint until
  the checkpoint is reached, then becomes
  zero for ten seconds (the patrol is idle)
\end{lstlisting}

A game is said to run as a sequence of time slices, called ``frames.'' A typical game runs at 30 to 60 frames per second. The pseudo code above describes the logic of the patrol, which runs every frame. The logic shows a typical dynamic present in any game, which is made up by continuous components (the update of \texttt{P} in our case) and discrete components (the update of \texttt{V}). As a result, \texttt{P} changes every frame, while \texttt{V} only changes upon reaching a checkpoint.

\subsection{Common issues}
Dynamics such as the one described above are built in games either with engines or by hand.
\paragraph{Engines} An engine is a library built to offer solutions for specific tasks (such as graphics and physics control) in order to speed up the development process, by promoting code reuse and reducing mistakes. Examples of commonly used engines are: MissionMaker \cite{MissionMaker} and GameMaker \cite{GameMaker}. By hiding complexity inside libraries and editors, developers only need to adapt their design to the engine. While popular, engines tend to have significant issues:
\begin{itemize}
\item Engines are often difficult, or even impossible, to expand and to adapt to the needs of the developer using them; this limits developers because some aspects of design might need to be adapted or left out due to of lack of specific support by the engine;
\item Engines are often closed libraries. Even though engines are internally optimized, the possibilities for global optimization that take into account the game structure are very limited;
\item Expertise is needed to master an engine. Since most (if not all) engines are highly complex to use, a significant effort of the developers is spent on learning the intricacies of the engine.
\end{itemize}
In general, a good engine offers good performance and a reduced possibility to make mistakes, but at the same time limits developers to the engine features and asks them to master most features before using the full capabilities of the engine.

\paragraph{Hand made implementations} A hand made implementation is used when developers are looking for specific behaviors, want to have more control on the game implementation, or when the support of the underlying platform is poor.
Hand made implementations raise important issues to be considered before starting a new project:
\begin{itemize}
\item Games tend to be very large applications. As size increases, the number of interactions increases as well, together with the possibility to make mistakes;
\item Optimization (when done by hand) adds complexity, because it requires supplementary data structures and may change the implementation of the game interaction. Optimization may also lead to (\textit{i}) implementation issues (for instance some optimization may work only on specific architectures), and (\textit{ii}) maintainability issues (any change in the game design should keep into account its repercussions on the implementation).
\end{itemize}

We now present an example of hand-made implementation of the patrolling dynamics following the style of \cite{millington2009artificial}:
\begin{lstlisting}
class Patrol:
  enum State:
   MOVING
   STOP

  public P, V, Checkpoints
  private myState, currentCheckpoint, timeLeft

  def loop(dt):
   P = P + V * dt
   if myState == MOVING:
     if P == Checkpoints[currentCheckpoint]:
       myState = STOP
       V = Vector2.Zero
       timeLeft = 10
   elif myState == STOP:
     if timeLeft < 0:
       currentCheckpoint += 1
       currentCheckpoint %= Checkpoints.length
       myState = MOVING
       V = Normalize(
            Checkpoints[currentCheckpoint] - P))
     else
       timeLeft -= dt
\end{lstlisting}
The \texttt{loop} function implements the patrolling behavior. It takes one argument \texttt{dt} which represents the delta time elapsed since the last frame. The very first line of the \texttt{loop} body implements the position update behavior. The velocity behavior depends on whether the patrol is moving or idle. While moving, we stop the patrol as soon as he reaches the checkpoint, and set the wait timer to 10 seconds. If the patrol is idle and the countdown is elapsed, the next checkpoint is selected. At this point the patrol points toward the new checkpoint and starts moving again.

% In general, solutions made by hand are desirable when building anything that is not readily supported by existing libraries or engines.

\subsection{Discussion}
The patrolling sample illustrates a common division between design and implementation in games. Deceptively simple problem descriptions turn out to require surprisingly articulated implementations. Complexity mainly originates from the explicit definition and management of a series of \textit{spurious variables} that are needed to program the logical flow of the problem but which do not come up in the design. In our case study, the spurious variables are \texttt{myState} (together with the definition of the state structure) and \texttt{timeLeft}.

A language suited for game development by persons for whom game development is not their main job, has two main requirements:
\begin{itemize}
\item \textit{Performance}: games are highly interactive applications which tend to be filled with many dynamic elements; if the language in which they are built does not guarantee high performance, the player experience will suffer;
\item \textit{Simplicity}: the language should be easy to understand and easy to express game functionality in; if the language is not simple in these respects, it requires an amount of training that is not within reach of those who are not game developers by profession.
\end{itemize}

Below we introduce a game-centered programming language and show how to rebuild the sample above with fewer spurious constructs, in a way that is closer to a higher-level, readable description.


\chapter{Parametric and Line Spectra}

\input{report/parametric-and-line-spectra/correlation-estimation/index.tex}

\input{report/parametric-and-line-spectra/spectrum-of-autoregressive-processes/index.tex}

\input{report/parametric-and-line-spectra/principal-component-analysis/index.tex}

\input{report/parametric-and-line-spectra/real-world-signals_respiratory-sinus-arrhythmia-from-RR-Intervals/index.tex}


\documentclass[a4paper]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{imakeidx}
\usepackage[hidelinks]{hyperref}
%% A screen friendly geometry:
\usepackage[paper=a5paper,scale=0.9]{geometry}
%% PPL Setup

\newcommand{\assign}{\mathrel{\mathop:}=}
\newcommand{\concat}{\mathrel{+\!+}}

\newcommand{\f}[1]{\mathsf{#1}}
\newcommand{\true}{\top}
\newcommand{\false}{\bot}
\newcommand{\imp}{\rightarrow}
\newcommand{\revimp}{\leftarrow}
\newcommand{\equi}{\leftrightarrow}
\newcommand{\entails}{\models}
\newcommand{\eqdef}{\;
\raisebox{-0.1ex}[0mm]{$ \stackrel{\raisebox{-0.2ex}{\tiny
\textnormal{def}}}{=} $}\; }
\newcommand{\iffdef}{\n{iff}_{\mbox{\scriptsize \textnormal{def}}}}

\newcommand{\pplmacro}[1]{\mathit{#1}}
\newcommand{\ppldefmacro}[1]{\mathit{#1}}
\newcommand{\pplparam}[1]{\mathit{#1}}
\newcommand{\pplparamidx}[2]{\mathit{#1}_{#2}}
\newcommand{\pplparamplain}[1]{#1}
\newcommand{\pplparamplainidx}[2]{#1_{#2}}
\newcommand{\pplparamsup}[2]{\mathit{#1}^{#2}}
\newcommand{\pplparamsupidx}[3]{\mathit{#1}^{#2}_{#3}}
\newcommand{\pplparamplainsup}[2]{#1^{#2}}
\newcommand{\pplparamplainsupidx}[3]{#1^{#2}_{#3}}
\newcommand{\pplparamnum}[1]{\mathit{X}_{#1}}

%%
%% We use @startsection just to obtain reduced vertical spacing above
%% macro headers which are immediately after other headers, e.g. of sections
%%
\makeatletter%
\newcounter{entry}%
\newcommand{\entrymark}[1]{}%
\newcommand\entryhead{%
\@startsection{entry}{10}{\z@}{12pt plus 2pt minus 2pt}{0pt}{}}%
\makeatother

\newcommand{\pplkbBefore}
{\entryhead*{}%
\setlength{\arraycolsep}{0pt}%
\pagebreak[0]%
\begin{samepage}%
\noindent%
\rule[0.5pt]{\textwidth}{2pt}\\%
\noindent}

% \newcommand{\pplkbDefType}[1]{\hspace{\fill}{{[}#1{]}\\}}

\newcommand{\pplkbBetween}
{\setlength{\arraycolsep}{3pt}%
\\\rule[3pt]{\textwidth}{1pt}%
\par\nopagebreak\noindent Defined as\begin{center}}

\newcommand{\pplkbAfter}{\end{center}\end{samepage}\noindent}

\newcommand{\pplkbBodyBefore}{\par\noindent where\begin{center}}
\newcommand{\pplkbBodyAfter}{\end{center}}

\newcommand{\pplkbFreePredicates}[1]{\f{free\_predicates}(#1)}
% \newcommand{\pplkbRenameFreeOccurrences}[3]{\f{rename\_free\_occurrences}(#1,#2,#3)}

\newcommand{\pplIsValid}[1]{\noindent This formula is valid: $#1$\par}
\newcommand{\pplIsNotValid}[1]{\noindent This formula is not valid: $#1$\par}
\newcommand{\pplFailedToValidate}[1]{\noindent Failed to validate this formula: $#1$\par}

\newcounter{def}

\makeindex

\begin{document}
%
% Doc at position 0
%
\title{Axiomatizations of Orderings}
\date{Revision: August 24, 2018; Rendered: \today}
\maketitle

\noindent Formalized with the
\href{http://cs.christophwernhard.com/pie/}{\textit{PIE}} system.
%
% Doc at position 492
%
\section{General Properties of Binary Relations}
%
% Statement at position 549
%
\pplkbBefore
\index{is_reflexive(P)@$\ppldefmacro{is\_reflexive}(\pplparamplain{P})$}$\begin{array}{lllll}
\ppldefmacro{is\_reflexive}(\pplparamplain{P})
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\forall \mathit{x} \, \pplparamplain{P}\mathit{x}\mathit{x}.
\end{array}
$\pplkbAfter
%
% Statement at position 605
%
\pplkbBefore
\index{is_irreflexive(P)@$\ppldefmacro{is\_irreflexive}(\pplparamplain{P})$}$\begin{array}{lllll}
\ppldefmacro{is\_irreflexive}(\pplparamplain{P})
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\forall \mathit{x} \, \lnot  \pplparamplain{P}\mathit{x}\mathit{x}.
\end{array}
$\pplkbAfter
%
% Statement at position 664
%
\pplkbBefore
\index{is_symmetric(P)@$\ppldefmacro{is\_symmetric}(\pplparamplain{P})$}$\begin{array}{lllll}
\ppldefmacro{is\_symmetric}(\pplparamplain{P})
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\forall \mathit{x}\mathit{y} \, (\pplparamplain{P}\mathit{x}\mathit{y} \imp  \pplparamplain{P}\mathit{y}\mathit{x}).
\end{array}
$\pplkbAfter
%
% Statement at position 730
%
\pplkbBefore
\index{is_asymmetric(P)@$\ppldefmacro{is\_asymmetric}(\pplparamplain{P})$}$\begin{array}{lllll}
\ppldefmacro{is\_asymmetric}(\pplparamplain{P})
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\forall \mathit{x}\mathit{y} \, (\pplparamplain{P}\mathit{x}\mathit{y} \imp  \lnot  \pplparamplain{P}\mathit{y}\mathit{x}).
\end{array}
$\pplkbAfter
%
% Statement at position 798
%
\pplkbBefore
\index{is_antisymmetric(P)@$\ppldefmacro{is\_antisymmetric}(\pplparamplain{P})$}$\begin{array}{lllll}
\ppldefmacro{is\_antisymmetric}(\pplparamplain{P})
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\forall \mathit{x}\mathit{y} \, (\pplparamplain{P}\mathit{x}\mathit{y} \land  \pplparamplain{P}\mathit{y}\mathit{x} \imp  \mathit{x}=\mathit{y}).
\end{array}
$\pplkbAfter
%
% Statement at position 873
%
\pplkbBefore
\index{is_total(P)@$\ppldefmacro{is\_total}(\pplparamplain{P})$}$\begin{array}{lllll}
\ppldefmacro{is\_total}(\pplparamplain{P})
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\forall \mathit{x}\mathit{y} \, (\pplparamplain{P}\mathit{x}\mathit{y} \lor  \pplparamplain{P}\mathit{y}\mathit{x}).
\end{array}
$\pplkbAfter
%
% Statement at position 934
%
\pplkbBefore
\index{is_transitive(P)@$\ppldefmacro{is\_transitive}(\pplparamplain{P})$}$\begin{array}{lllll}
\ppldefmacro{is\_transitive}(\pplparamplain{P})
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\forall \mathit{x}\mathit{y}\mathit{z} \, (\pplparamplain{P}\mathit{x}\mathit{y} \land  \pplparamplain{P}\mathit{y}\mathit{z} &&&&\; \imp \\
\hphantom{\forall \mathit{x}\mathit{y}\mathit{z} \, (} \pplparamplain{P}\mathit{x}\mathit{z}).
\end{array}
$\pplkbAfter
%
% Statement at position 1007
%
\pplkbBefore
\index{is_trichotomous(P)@$\ppldefmacro{is\_trichotomous}(\pplparamplain{P})$}$\begin{array}{lllll}
\ppldefmacro{is\_trichotomous}(\pplparamplain{P})
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\forall \mathit{x}\mathit{y} \, ((\pplparamplain{P}\mathit{x}\mathit{y} \land  \lnot  \pplparamplain{P}\mathit{y}\mathit{x} \land  \mathit{x}\neq \mathit{y}) &&&&\; \lor \\
\hphantom{\forall \mathit{x}\mathit{y} \, (} (\lnot  \pplparamplain{P}\mathit{x}\mathit{y} \land  \pplparamplain{P}\mathit{y}\mathit{x} \land  \mathit{x}\neq \mathit{y}) &&&&\; \lor \\
\hphantom{\forall \mathit{x}\mathit{y} \, (} (\lnot  \pplparamplain{P}\mathit{x}\mathit{y} \land  \lnot  \pplparamplain{P}\mathit{y}\mathit{x} \land  \mathit{x}=\mathit{y})).
\end{array}
$\pplkbAfter
%
% Statement at position 1133
%
\pplkbBefore
\index{is_connected(P)@$\ppldefmacro{is\_connected}(\pplparamplain{P})$}$\begin{array}{lllll}
\ppldefmacro{is\_connected}(\pplparamplain{P})
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\forall \mathit{x}\mathit{y} \, (\pplparamplain{P}\mathit{x}\mathit{y} \lor  \pplparamplain{P}\mathit{y}\mathit{x} \lor  \mathit{x}=\mathit{y}).
\end{array}
$\pplkbAfter
%
% Doc at position 1204
%
\section{Orderings of Binary Relations}
%
% Statement at position 1252
%
\pplkbBefore
\index{is_total_order(P)@$\ppldefmacro{is\_total\_order}(\pplparamplain{P})$}$\begin{array}{lllll}
\ppldefmacro{is\_total\_order}(\pplparamplain{P})
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\pplmacro{is\_antisymmetric}(\pplparamplain{P}) \land  \pplmacro{is\_transitive}(\pplparamplain{P}) \land  \pplmacro{is\_total}(\pplparamplain{P}).
\end{array}
$\pplkbAfter
%
% Statement at position 1333
%
\pplkbBefore
\index{is_strict_total_order(P)@$\ppldefmacro{is\_strict\_total\_order}(\pplparamplain{P})$}$\begin{array}{lllll}
\ppldefmacro{is\_strict\_total\_order}(\pplparamplain{P})
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\pplmacro{is\_irreflexive}(\pplparamplain{P}) \land  \pplmacro{is\_transitive}(\pplparamplain{P}) \land  \pplmacro{is\_connected}(\pplparamplain{P}).
\end{array}
$\pplkbAfter
%
% Statement at position 1424
%
\pplkbBefore
\index{is_strict_total_order_v2(P)@$\ppldefmacro{is\_strict\_total\_order\_v_{2}}(\pplparamplain{P})$}$\begin{array}{lllll}
\ppldefmacro{is\_strict\_total\_order\_v_{2}}(\pplparamplain{P})
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\pplmacro{is\_transitive}(\pplparamplain{P}) \land  \pplmacro{is\_trichotomous}(\pplparamplain{P}).
\end{array}
$\pplkbAfter
%
% Statement at position 1501
%
\pplkbBefore
\index{is_partial_order(P)@$\ppldefmacro{is\_partial\_order}(\pplparamplain{P})$}$\begin{array}{lllll}
\ppldefmacro{is\_partial\_order}(\pplparamplain{P})
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\pplmacro{is\_antisymmetric}(\pplparamplain{P}) \land  \pplmacro{is\_transitive}(\pplparamplain{P}) \land  \pplmacro{is\_reflexive}(\pplparamplain{P}).
\end{array}
$\pplkbAfter
%
% Statement at position 1588
%
\pplkbBefore
\index{is_strict_partial_order(P)@$\ppldefmacro{is\_strict\_partial\_order}(\pplparamplain{P})$}$\begin{array}{lllll}
\ppldefmacro{is\_strict\_partial\_order}(\pplparamplain{P})
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\pplmacro{is\_irreflexive}(\pplparamplain{P}) \land  \pplmacro{is\_transitive}(\pplparamplain{P}).
\end{array}
$\pplkbAfter
%
% Doc at position 1663
%
Some properties of orderings, for testing with theorem provers.  Not all these
problems are for all provers as easy as they seem -- see comments in the
source.
%
% Statement at position 2068
%
\pplkbBefore
\index{test_orderings_1@$\ppldefmacro{test\_orderings_{1}}$}$\begin{array}{lllll}
\ppldefmacro{test\_orderings_{1}}
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\pplmacro{is\_asymmetric}(\mathsf{p}) \equi  \pplmacro{is\_antisymmetric}(\mathsf{p}) \land  \pplmacro{is\_irreflexive}(\mathsf{p}).
\end{array}
$\pplkbAfter
%
% Statement at position 2157
%
\pplkbBefore
\index{test_orderings_2@$\ppldefmacro{test\_orderings_{2}}$}$\begin{array}{lllll}
\ppldefmacro{test\_orderings_{2}}
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\pplmacro{is\_transitive}(\mathsf{p}) \imp  (\pplmacro{is\_asymmetric}(\mathsf{p}) \equi  \pplmacro{is\_irreflexive}(\mathsf{p})).
\end{array}
$\pplkbAfter
%
% Statement at position 2245
%
\pplkbBefore
\index{test_orderings_3@$\ppldefmacro{test\_orderings_{3}}$}$\begin{array}{lllll}
\ppldefmacro{test\_orderings_{3}}
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\pplmacro{is\_irreflexive}(\mathsf{p}) \land  \pplmacro{is\_transitive}(\mathsf{p}) &&&&\; \imp \\
(\pplmacro{is\_connected}(\mathsf{p}) \equi  \pplmacro{is\_trichotomous}(\mathsf{p})).
\end{array}
$\pplkbAfter
%
% Statement at position 2352
%
\pplkbBefore
\index{test_orderings_4@$\ppldefmacro{test\_orderings_{4}}$}$\begin{array}{lllll}
\ppldefmacro{test\_orderings_{4}}
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\pplmacro{is\_strict\_total\_order\_v_{2}}(\mathsf{p}) \revimp  \pplmacro{is\_strict\_total\_order}(\mathsf{p}).
\end{array}
$\pplkbAfter
%
% Statement at position 2485
%
\pplkbBefore
\index{test_orderings_5@$\ppldefmacro{test\_orderings_{5}}$}$\begin{array}{lllll}
\ppldefmacro{test\_orderings_{5}}
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\pplmacro{is\_strict\_total\_order\_v_{2}}(\mathsf{p}) \imp  \pplmacro{is\_strict\_total\_order}(\mathsf{p}).
\end{array}
$\pplkbAfter
%
% Statement at position 2672
%
\pplkbBefore
\index{test_orderings_6@$\ppldefmacro{test\_orderings_{6}}$}$\begin{array}{lllll}
\ppldefmacro{test\_orderings_{6}}
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\pplmacro{is\_strict\_total\_order\_v_{2}}(\mathsf{p}) \equi  \pplmacro{is\_strict\_total\_order}(\mathsf{p}).
\end{array}
$\pplkbAfter
%
% Statement at position 2756
%
\pplkbBefore
\index{test_orderings_7@$\ppldefmacro{test\_orderings_{7}}$}$\begin{array}{lllll}
\ppldefmacro{test\_orderings_{7}}
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\pplmacro{is\_total\_order}(\mathsf{p}) \imp  \pplmacro{is\_partial\_order}(\mathsf{p}).
\end{array}
$\pplkbAfter
%
% Statement at position 2824
%
\pplkbBefore
\index{test_orderings_8@$\ppldefmacro{test\_orderings_{8}}$}$\begin{array}{lllll}
\ppldefmacro{test\_orderings_{8}}
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\pplmacro{is\_strict\_total\_order}(\mathsf{p}) \imp  \pplmacro{is\_strict\_partial\_order}(\mathsf{p}).
\end{array}
$\pplkbAfter
%
% Statement at position 2906
%
\pplkbBefore
\index{test_orderings_9@$\ppldefmacro{test\_orderings_{9}}$}$\begin{array}{lllll}
\ppldefmacro{test\_orderings_{9}}
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\pplmacro{is\_strict\_partial\_order}(\mathsf{p}) \imp  \lnot  \pplmacro{is\_partial\_order}(\mathsf{p}).
\end{array}
$\pplkbAfter
%
% Statement at position 2984
%
\pplkbBefore
\index{test_orderings_10@$\ppldefmacro{test\_orderings_{10}}$}$\begin{array}{lllll}
\ppldefmacro{test\_orderings_{10}}
\end{array}
$\pplkbBetween
$\begin{array}{lllll}
\pplmacro{is\_strict\_total\_order}(\mathsf{p}) \imp  \lnot  \pplmacro{is\_total\_order}(\mathsf{p}).
\end{array}
$\pplkbAfter
\printindex
\end{document}


\chapter{Problem Formulation}
\label{chapter:problemformulation}

\textcolor{red}{\textbf{This part is incomplete, I am now writing the strategy part}}\newline
We formulate the problem in following way

\section{Runtime Exceptions}
\label{subsec:excep}

\begin{figure}[htb]
\centering
\includegraphics[width=0.65\textwidth]{images/ArrayIndex.pdf}
\caption{array index out of bound formulated as FSM }
\label{fig:array}
\end{figure}

We can visualize all runtime exceptions as finite state machine (FSM). When a
program violates such sequence, it throws runtime exception.
In Figure~\ref{fig:array}, array index out of bound (java.lang.
ArrayIndexOutOfBoundException) exception is described as a FSM.
Here, a program will be in safe bound as long as the $array\_index \geq 0$ or
$array\_index \leq max\_array\_size - 1$