\documentclass[11pt,a4paper]{article}
\usepackage[english]{babel}
\usepackage[utf8]{inputenc}
\usepackage{amsmath}
\usepackage{fourier}
\usepackage{yfonts}
\usepackage[hmargin=3cm,vmargin=2.4cm]{geometry}
\usepackage[colorlinks=true]{hyperref}
\usepackage{fancyhdr}

\pagestyle{fancy}
\fancyhead{}
\fancyhead[L]{\href{https://www-ljk.imag.fr/membres/Pierre.Karpman/cry\_eng2017\_td\_hf.pdf}{https://www-ljk.imag.fr/membres/Pierre.Karpman/cry\_eng2017\_td\_hf.pdf}}

\DeclareMathOperator\hash{\mathcal{H}}
\DeclareMathOperator\E{\mathcal{E}}
\DeclareMathOperator\comp{\textswab{f}}
\DeclareMathOperator\cat{\mathrm{CAT}}
\DeclareMathOperator\pmm{\mathrm{PM}}
\DeclareMathOperator\smm{\mathrm{SM}}
\DeclareMathOperator\sand{\mathrm{SANDWICH}}

\title{Crypto Engineering (GBX9SY03)\\
TD Hash functions}
\date{2017-10-18}

\begin{document}

\maketitle{}

\subsection*{Exercise 1: Multicollisions for Merkle-Damg\aa rd hash functions}
In 2004, Joux showed a simple attack illustrating the fact that Merkle-Damg\aa rd hash functions were not ``ideal''. This attack consists in computing a collision on many
(more than two) messages, i.e. finding $m_0$, $m_1$, $\ldots$, $m_q$ that all have the same hash, more efficiently than what is possible for a random oracle.\\
\emph{In this exercice, we can safely ignore padding issues.}

\paragraph{Q. 1:} We assume that the expected number of collisions in the elements of two lists $L_0$ and $L_1$ of random $n$-bit elements is $\approx \#L_0\times\#L_1/2^n$.
Let $\hash : \{0,1\}^* \rightarrow \{0,1\}^n$ be a random oracle; what is the expected complexity of finding an $r$-collision for $\hash$?\\
{\footnotesize Hint: try to find the optimal balance in the list sizes for the case $r = 3$, and generalize the formula.}

\paragraph{Q. 2:}  Recall the structure of a Merkle-Damg\aa rd hash function
$\hash : \{0,1\}^* \rightarrow \{0,1\}^n$ based on a compression function $\comp : \{0,1\}^n \times \{0,1\}^b \rightarrow \{0,1\}^n$.
Let $m$, $m'$ be two messages such that $|m| = |m'| = b$.
Explicit the relation between $\hash(m)$, $\hash(m||m')$ and $\comp$.

\paragraph{Q. 3} Take $\hash$ as in Q.~2. Let $m_0$ and $m'_0$ be two one-block messages colliding through $\hash$ (i.e. $h_0 :=
\hash(m_0) = \comp(\text{IV}, m_0) = \hash(m'_0) = \comp(\text{IV}, m'_0)$). Assuming $\comp$ is ideal, how efficiently can you compute a collision
($m_1$, $m'_1$) for $\comp(h_0, \cdot)$? Once you know such a collision, how many messages colliding with $\hash(m_0||m_1)$ can you easily (i.e. in
constant time) create? Conclude about the cost of
computing a $2^r$-collision for $\hash$ and why Merkle-Damg\aa rd hash functions are not ideal.

\paragraph{Q. 4} The \emph{concatenation combiner} is a simple construction taking two hash functions $\hash_1$ and $\hash_2$ and defined as
$\cat_{\hash_1,\hash_2}(m) := \hash_1(m)||\hash_2(m)$. Assuming $\hash_1$ and $\hash_2$ have an output size of $n$ bits and follow the Merkle-Damg\aa rd construction,
how efficiently can you compute a collision for $\cat_{\hash_1, \hash_2}$? Is it possible to significantly improve the collision-resistance of SHA-1 by using
$\cat_{\text{SHA-1}, \text{MD5}}$?

\subsection*{Exercise 2: Davies-Meyer fixed-points}
In this exercise, we will see one reason why \emph{Merkle-Damg\aa rd strengthening} (adding the length of a message in its padding) is necessary
in some practical constructions.

\paragraph{Q. 1} Recall the ``Davies-Meyer'' construction of a compression function $\comp$ from a block cipher~$\E$.

\paragraph{Q. 2} Considering the feed-forward structure of Davies-Meyer, under what conditions would you obtain a fixed-point for such a compression function?

\paragraph{Q. 3} Show how to compute the (unique) fixed-point of $\comp(\cdot,m)$ for a fixed $m$. Given $h$, is it easy to find $m$ such that it is a fixed-point,
if $\E$ is an ideal block cipher?

\paragraph{Q. 4} A \emph{semi-freestart collision attack} for a Merkle-Damg\aa rd hash function $\hash$ is a triple $(h, m, m')$ s.t. $\hash_h(m) = \hash_h(m')$,
where $\hash_h$ denotes the function $\hash$ with its original IV replaced by $h$.
Show how to use a fixed-point to efficiently mount such an attack for Davies-Meyer + Merkle-Damg\aa rd, when strengthening is not used.

\paragraph{Note:} Fixed-points of the compression function can be useful to create the \emph{expandable messages} used in second preimage attacks on Merkle-Damg\aa rd.

\subsection*{Exercise 3: Meet-in-the-middle preimage attack on BRSS/PGV-13 + MD}
BRSS/PGV-13 is an alternative to Davies-Meyer, defined as $\comp(h,m) = \E(m,h) \oplus c$ for a cipher $\E$ and with $c$ a constant.
It can be shown in the ideal cipher model that
a Merkle-Damg\aa rd function with such a compression function is secure up to the birthday bound for both collision \emph{and} preimage attacks (Black \& al., 2010).

\paragraph{Q. 1} If $\E$ is ideal, what is the complexity, given $h$ and $t$, of finding $m$ such that $\comp(h, m) = t$? Conclude about the preimage security
of $\comp$ itself.

\paragraph{Q. 2} Show how to compute a two-block preimage for $\hash$ with the above compression function, using a
meet-in-the-middle attack, and roughly evaluate its complexity (both time and memory).

\paragraph{Q. 3} Give a rough explanation of how the attack of Q.~2 is prevented when using a Davies-Meyer compression function.

\subsection*{Exercise 4: Hash-based message-authentication codes}

\paragraph{Q. 1} Recall the definition of a message-authentication code (MAC), existential forgery, and universal forgery.

\paragraph{Q. 2} Let us first assume that $\hash$ is a random oracle. Explain (roughly) why the ``prefix-MAC'' construction
$\pmm_{\hash}(k, m) := \hash(k||m)$ is secure? Is there a difference with the ``suffix-MAC'' variant $\smm_{\hash}(k, m) := \hash(m||k)$?

\paragraph{Q. 3} Now assume that $\hash$ is a Merkle-Damg\aa rd hash function. Suppose I know $m$ and its tag $t := \pmm_{\hash}(k, m)$,
and that the size of $k$ is known. How easily can I compute another message and its corresponding tag under $\pmm_{\hash}(k, \cdot)$? Is this
MAC secure against existential forgery?

\paragraph{Q. 4} Still assuming that $\hash$ is a Merkle-Damg\aa rd function, show how collisions on $\hash$ lead to an existential forgery attack
of $\smm_{\hash}$. What is the expected complexity of this attack for an otherwise secure $\hash$? Is this better than what you would expect for a ``good'' MAC?

\paragraph{Q. 5} Is it reasonable to instantiate prefix/suffix-MAC with SHA-3? With SHA-256? With SHA-512/256?

\paragraph{Note:} It can be proven (Yasuda, 2007) that, using appropriate padding rules, the ``Sandwich-MAC'' construction $\sand_{\hash}(k,m) := \hash(k||p||m||p'||k)$
(where $p$ and $p'$ denote padding) is secure, without requiring $\hash$ to be a random oracle (in particular, it can be built with a Merkle-Damg\aa rd construction).

\end{document}


\documentclass[a4paper]{letter}
\usepackage{hyperref}
\usepackage{color}

\title{Tutorial in Computational Science using Visual Python}

\begin{document}
\definecolor{code}{cmyk}{1,0,1 ,.5}

\section{Introduction to Visual python: Simple motion}
The first section of the tutorial introduces you to programming in visual python by stepping
through a program to display a ball bouncing around inside a box.
This program will later be a modified to become a simulation of an ideal gas.
\subsection{Your First Program}
Start IDLE by clicking on the snake icon on the panel at the bottom of your desktop.
A window labeled 'Untitled' should appear.
This is the window in which you will type your program.
Type the following statements
(You can select the text below and then paste it into IDLE using the middle mouse button.):
{\color{code}
\begin{verbatim}
from visual import * # This instructs Python to use the Visual graphics module

wallR = box(pos=vector(6,0,0),size=vector(0.2,4,4),color=color.green)
#opens a window for displaying graphics and creates a thin green slab
#in it which we can refer to later as wallR
ball = sphere(pos=vector(-5,0,0), radius=0.5, color=color.red)
#creates a red sphere and names it ball
\end{verbatim}}
IDLE will colour different sections of the program to make it easier to read.
For example comment lines, which begin with the \# symbol are red.
The functions {\color{code}sphere} and {\color{code}box} are 'constructors' for 3D objects.
The position of an object's centre is specified in three dimensions
using a vector.

Save your program as 'firstprogram.py' by choosing 'save as' from the file menu.

\subsection{Running the Program}
Now run your program by choosing 'Run program' from the 'Run' menu.
When you run the program, two new windows appear.
There is a window titled 'VPython,' in which you should see a red sphere,
and a window titled 'Output'.

In the VPython window, hold down the middle mouse button and move the mouse.
You should see that you are able to zoom into and out of the scene.
Now try holding down the right mouse button .
You should find that you are able to rotate your view of the scene.

You can stop the program by choosing 'Stop program' from the run menu.

\subsection{Objects and attributes}
Sphere and box are types of objects that visual python recognises and displays.
They have some attributes associated with them (such as
position({\color{code}pos}), colour({\color{code}color}) and
{\color{code}radius}) which can be set when you first define and name the object,
otherwise the default values will be used.

You can change the radius attribute of {\color{code}ball} after it has been constructed
with the statement:
{\color{code}\begin{verbatim}
ball.radius=0.5
\end{verbatim}}
You can also add any new attributes you want to associate with the object, eg:
{\color{code}\begin{verbatim}
ball.velocity=vector(2,.1,0)
\end{verbatim}}

\subsection{Moving Objects}
To move objects you will need a program loop that repeatedly updates the position.
This can be done with a while loop that repeats the indented lines of code following
the while statement, as long as the while condition remains true.

Add the following while loop to the bottom of your program to make the ball move according to the velocity you gave it earlier:
{\color{code}\begin{verbatim}
timestep=0.05
ball.velocity=vector(2,.1,0)
while (1==1):
    rate(20)
    ball.pos=ball.pos + ball.velocity*timestep
\end{verbatim}}
In Python {\small\color{code}==} stands for 'is equal to'
so the statement {\small\color{code}1==1} always has a value of true,
 and code inside the while loop will repeat forever.
The symbol {\small\color{code}=} is used for assignment, to set a new value for a variable.

In the above example the value of {\color{code}ball.pos + ball.velocity*timestep}
is calculated and then assigned as the new value for ball.pos.
Python knows how to add vectors and how to multiply them by a scalar so you don't have
to specify this element by element.

The rate statement specifies how many times each second the loop will be executed.
It allows you to control the animation speed so that the ball moves at the same speed
on faster computers.

Run your program by choosing 'Run program' from the 'Run' menu.
You should observe that the ball moves to the right.
You can change how fast either by changing the rate or the timestep.

\subsection{Making the ball bounce: Logical tests}
To make the ball bounce off the wall, we need to detect a collision between the ball and the wall.
A simple approach is to compare the x coordinate of the ball to the x coordinate of the wall,
and reverse the x component of the ball's velocity if the ball has moved too far to the right.
The components of vectors are attributes which can be referred to individually as .x, .y and .z.
The logical test we would use to detect a collision and reverse the velocity might look like:
{\color{code}\begin{verbatim}
if ball.x > wallR.x:
    ball.velocity.x = -ball.velocity.x
\end{verbatim}}
The indented line after the if statement will be executed only if the
logical test in the previous line gives 'true' for the comparison.
If the result of the logical test is false
(that is, if the x coordinate of the ball is not greater than the x coordinate of the wall),
the indented line will be skipped.
Since we want this logical test to be performed every time the ball is moved,
we need to indent both of these lines so they are inside the while loop.
Your program should now look like this:
{\color{code}\begin{verbatim}
from visual import *

# create wall
wallR = box(pos=vector(6,0,0), size=vector(0.2,4,4), color=color.green)
#create a ball and define its velocity
ball = sphere(pos=vector(-5,0,0), radius=0.5, color=color.red)
ball.velocity = vector(2,.1,0)
# set the timestep between position updates
timestep = 0.05
while (1==1):
#the code within this while loop will be repeated 100 times per second
    rate(100)
    ball.pos = ball.pos + ball.velocity*timestep #move ball
    if ball.pos.x > wallR.pos.x: #check for collision with wall
        ball.velocity.x = -ball.velocity.x #reflect velocity at collision
\end{verbatim}}
Run your program.
You should observe that the ball moves to the right, bounces off the wall,
and then moves to the left, continuing off into space.
Note that our test is not very sophisticated.
{\color{code}ball.x} is at the center of the ball
and wallR.x is at the center of the wall so the ball penetrates the wall before it bounces.

Adjust the position test so that the ball bounces when the edge of the balls reaches
the edge of the wall (ie when {\color{code}ball.x + ball.radius == wallR.x-wallR.size.x/2}).
For a more realistic bounce you should reflect the position of the ball as well as its velocity.
You can add another wall at the left side of the display, and make the ball bounce off that wall also.

Your program should now look something like the following:
{\color{code}\begin{verbatim}
from visual import *
# create walls
wallR = box(pos=vector(6,0,0), size=vector(0.2,4,4), color=color.green)
wallL = box(pos=vector(-6,0,0), size=vector(0.2,4,4), color=color.green)
# create a ball and define its velocity
ball = sphere(pos=vector(-5,0,0), radius=0.5, color=color.red)
ball.velocity = vector(2,.1,0)
# set the maximum and minimum position for the centre of the ball
max_xpos=wallR.pos.x-ball.radius-wallR.size.x/2
min_xpos=wallL.pos.x+ball.radius+wallL.size.x/2
# set the timestep between position updates
timestep = 0.05

while (1==1):
#the code within this while loop will be repeated 100 times per second
    rate(100)
    ball.pos = ball.pos + ball.velocity*timestep #move ball
    if ball.x > max_xpos: #check for collision with right wall
        ball.velocity.x = -ball.velocity.x #reflect velocity
        ball.pos.x=2*max_xpos-ball.pos.x #reflect position
    if ball.x < min_xpos: #check for collision with left wall
        ball.velocity.x = -ball.velocity.x #reflect velocity
        ball.pos.x=2*min_xpos-ball.pos.x #reflect position
\end{verbatim}}
This program makes a ball bounce backward and forward between two parallel walls.
The ball continues to bounce even when it has  passed the top of the walls.

You should be able to add and extend walls now so that the ball bounces inside a box.
You will want to have an invisible front wall so that you can see inside.
Play around with different starting positions and velocities for the ball,
and sizes for the ball and box.

If you have trouble, or are short of time you can copy the example solution from the link below.
The next section is based on the solution to this exercise.
%Example solution \href{bounce2.py}{bounce2.py}
%\href{bounce2.html}{( html format )}
\href{bounce2.html}{ Example Solution }

\section{Simulating particle motion in a gas}
In this section you will extend the bouncing ball program so that it simulates the motion
of atoms in a gas.
There will need to be many atoms in the box and they should bounce off each other as well
 as off the sides of the box.
We will need to set the initial distribution of atom positions and velocities,
but these distributions may evolve as the simulation progresses.

\subsection{Random numbers}
You can make the velocity of the ball different each time the program is run
by using a random number generator.
The random number generator is not part of standard python and needs to be
imported from the random module.
The random module contains random number generator for several different distributions.
You can import just a uniform distribution random number generator by inserting a line at
the beginning of the program (following the line {\color{code}from visual import *}):
{\color{code}\begin{verbatim}
from random import uniform
\end{verbatim}}
The function {\color{code}uniform(-1,1)} will give a random number between -1 and 1.
You can set a random ball velocity  by replacing the line setting the ball's velocity with:
{\color{code}\begin{verbatim}
maxv=2.
ball.velocity=maxv*vector(uniform(-1,1),uniform(-1,1),uniform(-1,1))
\end{verbatim}}
\subsection{Multiple balls: Using lists}
To simulate a gas we will need many particles inside the box.
One easy way of dealing with many particles is to put them into a list.

Replace the section of code in which you created the ball
and gave it velocity with the following code
(it should be after the section defining the walls):
{\color{code}\begin{verbatim}
side=wallR.pos.x
ballradius=0.4
thk=wallR.size.x
maxpos=side-thk/2-ballradius
maxv=2.0

ball1=sphere(color=color.green,radius=ballradius)
ball1.pos=maxpos*vector(uniform(-1,1),uniform(-1,1),uniform(-1,1))
ball1.velocity=maxv*vector(uniform(-1,1),uniform(-1,1),uniform(-1,1))

ball2=sphere(color=color.green,radius=ballradius)
ball2.pos=maxpos*vector(uniform(-1,1),uniform(-1,1),uniform(-1,1))
ball2.velocity=maxv*vector(uniform(-1,1),uniform(-1,1),uniform(-1,1))

ball3=sphere(color=color.green,radius=ballradius)
ball3.pos=maxpos*vector(uniform(-1,1),uniform(-1,1),uniform(-1,1))
ball3.velocity=maxv*vector(uniform(-1,1),uniform(-1,1),uniform(-1,1))

balls=[ball1,ball2,ball3]
\end{verbatim}}

This gives a list containing three balls. Any type of object can go into a list.
In fact a list can be made up of several different types of object.
If you run the code now you will see three balls within the box but the section
of code to move the ball no longer works.

To move all the balls in a list you use a {\color{code}for} loop.
In python a {\color{code}for} loop cycles through the elements of a list.
The loop to move all the balls in the list would look like:
{\color{code}\begin{verbatim}
while (1==1):
    for ball in balls:
        ball.pos = ball.pos + ball.velocity*timestep
        if ball.pos.x > maxpos:
            ball.velocity.x = -ball.velocity.x
            ball.pos.x=2*maxpos-ball.pos.x
                                   . . .
\end{verbatim}}
The code within the for loop is indented by two levels
since it is also inside the while loop (with code inside the if indented an additional level).
You can indent a whole section by selecting it and then choosing 'indent section'
from the format menu.
(Try running the program now to see three balls bouncing within your box)

A for loop can also be used to set up the list of balls more efficiently.
To add each ball to the list {\color{code}balls} use {\color{code}balls.append(ball)}.
The construction of a for loop in python is slightly different from many
other programming languages which cycle through a set of numbers.
To get the more usual counted for loop you use {\color{code}range} to create a
list of integers between 0 and {\color{code}no\_particles-1}.

Relplace the part of the code which created a list of three balls with this for loop
which creates a list of ten balls.
The for loop which moves the balls in the list should still work perfectly.
{\color{code}\begin{verbatim}
no_particles=10
side=wallR.pos.x
ballradius=0.4
thk=wallR.size.x
maxpos=side-thk/2-ballradius
maxv=2.0
balls=[]
for i in range(no_particles):
    ball=sphere(color=color.green,radius=ballradius)
    ball.pos=maxpos*vector(uniform(-1,1),uniform(-1,1),uniform(-1,1))
    ball.velocity=maxv*vector(uniform(-1,1),uniform(-1,1),uniform(-1,1))
    balls.append(ball)
\end{verbatim}}

\subsection{Particle interactions}
You should now have a program that shows many particles bouncing around inside a box.
At the moment the balls are simply passing through each other
(make the ball radius large to see this more clearly).
For this to be a realistic model of a gas the particles need to interact in some fashion.

Different 'interaction potentials' could be used depending on the type of molecule making up
the gas.
For an ideal gas an appropriate interaction is 'hard sphere collisions'
--- the balls bounce off each other the same way they bounce off the walls.

\subsubsection{Detecting a collision}
At each time step we need to check whether any particles have collided.
For each pair of particles we need to check whether the distance between
them is less than the sum of their radii.
For example add the following lines to the end of your program,
after you have updated the position of all the particles.
The indentation should place it within the while loop but outside the other for loop.
{\color{code}\begin{verbatim}
    for ball in balls:
        for otherball in balls:
            if not ball == otherball:
                distance=mag(otherball.pos-ball.pos)
                if distance<(ball.radius+otherball.radius):
                    print 'collision' , distance
\end{verbatim}}
{\color{code}mag} is a function that returns the size (magnitude) of a vector.

Run your program.
Notice that every time a pair of balls collide in the display window the word 'collision'
is printed twice to the output window.
This is because the loop goes through every pair of balls twice.
To check each pair only once the second loop should only check against balls with
higher index than the first. To do this replace the collision detection code with:
{\color{code}\begin{verbatim}
    for i in range(no_particles):
        for j in range(i+1,no_particles):
            distance=mag(balls[i].pos-balls[j].pos)
            if distance<(balls[i].radius+balls[j].radius):
                print 'collision', distance
\end{verbatim}}
Now when you run the program, 'collision' should be written once for each collision.

\subsubsection{Exchanging momentum: more vector calculations}
When two objects collide elastically (without losing energy) in one dimension they swap momentum.
If their masses are equal this means they should swap velocity.
Since we are modelling the interaction between particles as hard spheres,
with no friction, the force at impact is only along the line joining the centres of the balls.
The balls exchange momentum in this direction,
leaving the perpendicular velocity components unchanged.
The result is similar to the way billiard balls collide.
The section of code that detects a collision and swaps the velocity component of the two balls
in the collision direction looks like:
{\color{code}\begin{verbatim}
    for i in arange(no_particles):
        for j in arange(i+1,no_particles):
            distance=mag(balls[i].pos-balls[j].pos)
            if distance<(balls[i].radius+balls[j].radius):
                direction=norm(balls[j].pos-balls[i].pos)
                vi=dot(balls[i].velocity,direction)
                vj=dot(balls[j].velocity,direction)
                exchange=vj-vi
                balls[i].velocity=balls[i].velocity+exchange*direction
                balls[j].velocity=balls[j].velocity-exchange*direction
\end{verbatim}}
The function {\color{code}norm} returns a vector with the same direction as the input
but with its magnitude normalised to one.
The function {\color{code}dot} returns the dot product of the two input vectors,
in this case the component of the ball's velocity that is in the collision direction.

You should now have a program that shows ten spheres bouncing around inside a box
and bouncing off each other.
You might find that balls occasionally get stuck together,
particularly if three or more balls collide at the same time.
This problem is reduced by making the time step smaller.
We can also make the collisions more accurate, and stop balls sticking together,
by adjusting the position of the balls after a collision, in much the same way we did
for collisions with the sides of the box.
{\color{code}\begin{verbatim}
                overlap=2*ballradius-distance
                balls[i].pos=balls[i].pos - overlap*direction
                balls[j].pos=balls[j].pos + overlap*direction
\end{verbatim}}
%An example solution is at \href{manybounce1.py}{manybounce1.py}
% \href{manybounce1.html}{(html version)}
\href{manybounce1.html}{Example solution}

\subsection{Program speed}
The program you have written shows a simple model of the behaviour of particles within a gas.
Play around with changing the number and size of particles and their average velocities.
As you add more particles the speed of the program slows down significantly.
Doubling the number of particles may increase the time to run the program by four times.
This is because the number of steps to check for collisions increases as the square of the
number of particles.
Many computational science models which are based on interacting particles have this $N^2$ speed dependence.
Models with large numbers of particles need high speed computers and efficient programs.

Increasing the speed of a simulation program can make up a large part of the work of a
computational scientist.
Tactics for improving the efficiency of a program include:
\begin{itemize}
\item{removing unneccessary calculations (eg the calculation of the distance between particles involves calculating a square root whch is quite slow. The comparison of particle separation for detecting collisions could be made just as easily with the square of the distance which is much quicker to calculate.)}
\item{Saving results of calculations instead of repeating them. }
\item{Using more efficient data constructions (eg the elements of lists in python are not necessarily all the same data type. This makes them flexible for many different programming tasks but the program takes longer to access this data. Python arrays have each element the same data type and are faster to work with.) }
\item{Improved mathematical algorithms which allow larger step sizes for the same accuracy.}
\item{Minimise the number of particles needed by the model}
\item{Include only the most important interactions.}
\end{itemize}

%\href{quickbounce1.py}{quickbounce1.py} is a faster version of the above example program.
\href{quickbounce1.html}{Here} is a faster version of the ideal gas simulation program.

\subsection{Extracting useful information}
The visualisation of a model can be useful in itself to get insight into its behaviour.
But the program might be more useful as a computational science 'experiment' if we
could extract from it predictions of gas behaviour that could be measured in a
physical experiment or were relevant in some real world application.
Alternatively we could use the results to confirm some theory about ideal gasses.

To do either of these we need to extract the sort of information that can normally
be measured since you don't get to watch the particles of a real gas bouncing around.

Examples of some measurements we could extract from our simulation:
\begin{itemize}
\item{measure how the pressure on the walls varies with gas temperature and density}
\item{distribution of particle velocities}
\item{collision frequency}
\end{itemize}
\section{Velocity distribution: using graphs}
We gave our particles a uniform inititial velocity distribution for each direction.
A statistical analysis suggests that the 'most likely' velocity distribution for each
component will have more low energy particles and a long tail of high energy particles.
Does our gas evolve to this 'most likely' velocity distribution.

\subsection{Graphing in visual python}
We will need the graphing functions contained in the visual.graph module, so insert a line
at the beginning of your program
{\color{code}\begin{verbatim}
from visual.graph import *
\end{verbatim}}
Several types of graph are available.
We will use a histogram that displays how many particles fit into each velocity range.
This graph is set up before the main while loop with:
{\color{code}\begin{verbatim}
graphwindow=gdisplay(xtitle='v_x',ytitle='N',ymax=no_particles/2)
velocity_dist=ghistogram(bins=arange(0,2*maxv,maxv/5))
\end{verbatim}}
velocity\_dist defines a histogram with a set of ten velocity 'bins' into which the list of
particle velocities will be sorted.
You might want to adjust the number of bins depending on the number of particles in your gas.
The graph will be displayed in a new graphing window.

To plot the distribution of particle speeds in the x direction you would form a list and use
this list as data for the histogram
{\color{code}\begin{verbatim}
vlist=[]
for ball in balls:
        vlist.append(abs(ball.velocity.x))
velocity_dist.plot(data=vlist)
\end{verbatim}}
You can put these lines within the while loop and see the velocity distribution evolve.
Unless you have many particles in your gas the velocity distribution will jump around alot.
You can reduce this problem by averaging the distribution over time using:
{\color{code}\begin{verbatim}
velocity_dist=ghistogram(bins=arange(0,2*maxv,maxv/5),accumulate=1,average=1)
\end{verbatim}}
(You may find that displaying the graph slows down the simulation considerably.
If this is a problem, turn your while loop into a for loop so that it runs for a limited time
and put all the graphing parts of the program after the loop finishes.)

If you are using the quick version of the code the velocity is stored as in varray,
which can be fed directly to the histogram as:
{\color{code}\begin{verbatim}
     velocity_dist.plot(data=varray[:,0])
\end{verbatim}}
\subsection{Compare with expected result}
The expected 'most likely' velocity distribution can be plotted for comparison as a curve set
up with:
{\color{code}\begin{verbatim}
expected_distribution=gcurve(color=color.green)
\end{verbatim}}
and then plotted point by point with:
{\color{code}\begin{verbatim}
for vx in arange(0,2*maxv,maxv/20):
        expected_distribution.plot(pos=(vx,.3*no_particles*exp(-vx**2/maxv**2*3/2)))
\end{verbatim}}
(plot only once - so just before while loop. You may need to rescale this graph if you
used a different number of velocity bins)

% An example of graphing with the quick program is
%\href{quickbouncevdist.py}{quickbouncevdist.py}
\href{quickbouncevdist.html}{Here} is an example of graphing with the quick program.
%An example of graphing with the slower program is
%\href{manybouncevdist.py}{manybouncevdist.py}
\href{manybouncevdist.html}{Here} is an example of graphing with the slower program.

Some questions that you could use this program to investigate:
\begin{itemize}
\item {Is the initial velocity distribution different from the final velocity distribution?}
\item{Does the final velocity distribution match the expected result?}
\item{Does changing the initial velocity distribution effect the final distribution?}
\item{Consider the ways this simulation is different from a real gas.
What changes might you need to make to model a real gas more closely?
How might this effect the behaviour of the simulation?}
\end{itemize}
\section{More complicated simulations}
You could extend this simulation to investigate more complex situations.
\begin{itemize}
\item{Mixing of two ideal gasses (diffusion)(eg look at \href{quicktwogas.html}{quicktwogas})}
\item{Heat conduction}
\item{Other interaction potentials including some attraction may give phase change to
solid or liquid phases}
\item{Include effects of earth's gravity to get height variations in pressure and
temperature - or better simulation of liquid/gas interface}
\item{Velocity distribution when a gas includes molecules of different masses}
\item{Movable or elastic walls (eg look at \href{quickbounce2.html}{quickbounce2})}
\end{itemize}
%\section{Other situations that can be modelled using similar techniques}
%The technique of following individual particles, calculating their accelerations
%due to their position and the position of other particles around them can be used
%to simulate a wide variety of situations.
%\begin{itemize}
%\item{Molecular dynamics and computational chemistry can determine the
%shape of molecules, their resonant frequencies and their potential reactions.
%The most difficult part is to determine the interaction potentials which can depend on
%relative positions of more than two particles, and also on angles between them.}
%\item{Gravitational interactions determine the orbits of planets in the solar system.
%Precise calculations of these orbits determine whether the solar system is stable or chaotic,
%whether orbits may change drastically at some future time, give clues as to how the solar
%system form, and whether any asteroid is likely to hit the earth.
%With large objects like planets their shape and rotation may need to be taken into account.}
%\item{Animal behaviour. Animals use the positions of other animals and objects around them to decide how they
%should move in order to acheive their goals. The goals might include getting food, fleeing predators, staying
%in a group and avoiding collisions. This simulations apply to people and traffic flow and can be used to design
%adequate escape routes from burning buildings and sinking ships, road systems that minimise congestions, or to
%suggest driving techniques that avoid collisions.}

\end{document}


\chapter{Applications I:  Pure Binary Arithmetic}\label{arithchapter}

[PLACEHOLDER]

% [TODO I need to clean up this chapter. This paper this chapter is
% based on presented the definitions in Prolog.  I've translated the
% code to miniKanren, but much of the English still refers to Prolog's
% SLD resolution strategy and incomplete, depth-first search.  I still
% need to clean up this wording, since miniKanren uses a complete,
% interleaving search strategy.  I also need to integrate the text from
% the intro and conclusion sections into the rest of the chapter, and
% the thesis intro and conclusion chapters, as appropriate]

% %%% This could bite me when it comes to Slatex.  Better disable at end of this chapter.
% %\DefineShortVerb{\|}

% %\begin{abstract}
% We present \emph{decidable} logic programs for addition, multiplication,
% division with remainder, exponentiation, and logarithm with remainder over the
% \emph{unbounded} domain of natural numbers.  Our predicates represent
% \emph{relations} without mode restrictions or annotations.  They are
% fully decidable under the common, Depth-First-Search-like, SLD resolution strategy of
% Prolog, or under an interleaving refinement of DFS\@, such as that used by miniKanren. We prove that
% the evaluation of our arithmetic goals always terminates, given arguments
% that share no logic variables. Further, the (possibly infinite) set of
% solutions for a goal denotes exactly the
% corresponding mathematical relation. (For SLD without interleaving, and for
% some infinite solution sets, only half of the relation's domain may
% be covered.) We define predicates to handle unary (for illustration)
% and binary representations of natural numbers, and prove termination
% and completeness of these predicates. Our predicates are written in pure miniKanren, without
% \scheme|conda|/\scheme|condu|, \scheme|varo|, \scheme|project|, or other non-logical operators.  The purity and
% minimalism of our approach allows us to declare arithmetic in other
% logic systems, such as Haskell type classes.
% %\end{abstract}

% %% \begin{keywords}
% %% declarative arithmetic, binary, logic programming, termination
% %% \end{keywords}

% \section{Introduction}

% Logic programming is said to be programming with relations, but
% arithmetic is often dealt with in a non-relational, restricted way.
% For example, Prolog's built-in \verb|is/2| predicate for evaluating
% arithmetic expressions does not allow free (unbound) logic variables
% in the expressions.  Whereas the goal \verb|Z is 6*7|
% succeeds, binding \verb|42| to~\verb|Z|, the related goal \verb|42 is X*Y| is
% considered erroneous because its multiplicands `are not sufficiently
% instantiated.' Multiplication is not treated as a ternary relation
% between multiplicands and the product because of mode restrictions on
% the first two arguments.  Constraint logic programming (CLP) overcomes
% this drawback to some extent~\cite{apt03principles}; for example,
% disjunctive Datalog~\cite{Eiter:1997:DD} treats arithmetic
% relationally.  Indeed, relational handling of arithmetic was one of
% the motivations for CLP\@.  Unfortunately, this flexibility has a
% price: CLP restricts the
% arithmetic domain to be finite and changes the evaluation mode
% of the logic programming system away from Kowalski's `predicate as
% function' model~\cite{Kowalski74a}.

% We present fully relational arithmetic on the \emph{unbounded} domain
% of binary natural numbers for conventional
% (SLD~\cite{lloyd:lp}, or SLD with
% interleaving~\cite{backtracking}) logic
% programming systems.  We define predicates for addition,
% multiplication, division with remainder, and logarithm with
% remainder. These predicates express the remaining arithmetic
% operations, including subtraction and exponentiation.  These so-called base
% predicates have \emph{no} mode restrictions or annotations
% on their arguments, and are
% implemented in a \emph{pure} logic system without
% \scheme|conda|/\scheme|condu|, \scheme|varo|, \scheme|project|, or negation. Furthermore,
% each base predicate terminates under SLD evaluation (and re-evaluation, upon
% backtracking), provided that the predicate's arguments share no
% logic variables.  The stream of answers produced by (re-)evaluating
% each arithmetic predicate under SLD with interleaving~\cite{backtracking}
% covers exactly the corresponding
% mathematical relation; under SLD resolution and some infinite domains,
% only half of the relation is covered.

% In particular, we define the following decidable predicates:
% %
% \begin{description}
% \item[\scheme|addo|] such that \scheme{(addo x y z)} can be used to add two numbers
% \scheme{x} and \scheme{y} to get \scheme{z}, to subtract \scheme{x} or \scheme{y} from \scheme{z}, to decompose
% \scheme{z} into summands, or to compare two naturals. For example,
% we can determine that the triple $(1,2,3)$ is in the ternary addition
% relation%
% \footnote{We mean a relation that relates triples of numbers $(x,y,z)$
% so that $x+y=z$.}
% by
% evaluating either the goal
% \scheme{(addo bn1 bn2 bn3)}%
% \footnote{\bn{3} means the representation of the binary numeral 3, which in
%   miniKanren is encoded as \schemeresult{(l l)} (\S\ref{s:binary}).}
% or the goal:

% \schemedisplayspace

% \begin{schemebox}
% (exist (x y z)
%   (addo x y z)
%   (== bn1 x)
%   (== bn2 y)
%   (== bn3 z)).
% \end{schemebox}

% By evaluating \scheme{(addo x bn3 bn2)} we determine, also in finite
% time, that the addition relation does \emph{not} include
% \emph{any} triple $(n,3,2)$.

% \item[\scheme|mulo|] such that \scheme{(mulo x y z)} can be used, inter alia, to
%   multiply \scheme{x} and~\scheme{y}, to factor~\scheme{z},
%   or to generate a stream of triples related
%   by multiplication.

% \item[\scheme|divo|] such that \scheme{(divo n m q r)}
% succeeds if and only if $n = m \cdot q + r < m\cdot(q+1)$.%
% \footnote{This equation implies that \scheme{divo} fails when $m$ is
%   \bn0. Hence \scheme{mulo} is not reducible to \scheme{divo}. Besides,
%   the former is simpler and is part of the implementation of the latter.}
% For instance, the goal \scheme{(divo bn1 bn0 q r)} to relate the
% divisor zero to a non-zero dividend
% fails instantly, without trying to enumerate all natural numbers.
% The goal \scheme{(divo bn5 m bn1 r)} finds all
% numbers $m$ that divide 5, perhaps unevenly,
% with a quotient of 1. These values are $5$, $4$, and $3$. Finally,
% \scheme{(divo bn5 m bn7 r)} fails in finite time rather than diverging.

% \item[\scheme|logo|] such that \scheme{(logo n b q r)} succeeds if
% and only if $n = b^q + r < b^{q+1}$.
% We can use \scheme{logo} to perform exponentiation, find logarithms,
% and find $n$-th roots.
% \end{description}
% %
% We prove that these base predicates are decidable and
% that the arithmetic relations over natural numbers form their
% universal model
% \begin{comment}
% \oleg{\url{http://www.inf.ed.ac.uk/teaching/courses/fpls/note15.pdf}}
% \end{comment}
% (see the
% \emph{faithfulness} property introduced in~\S\ref{s:unary}).

% \subsection{Challenges}

% We require the predicates to be both effective and efficient.
% First, the
% evaluation of base arithmetic goals must terminate. Put
% differently, it must be effectively computable whether a
% tuple of naturals is included in or \emph{excluded} from a
% base arithmetic relation (addition, multiplication, division with
% remainder, and logarithm with remainder).
% Further, these computations must finish
% without taking an exponential amount of time or space with respect to
% the `search depth' (corresponding, in the case of binary numbers,
% to the logarithm of the largest
% number appearing in the computation). In other words, we wish to
% maintain the efficiency of depth-first search (DFS) (or DFS with
% interleaving \cite{backtracking,kanrensite}) of the and-or tree expressing the
% solution space of our base goals.

% The main challenge in defining our predicates is that the domains of
% natural numbers, and of arithmetic relations in general, are
% infinite---enumerating them is not an option.
% The incompleteness of DFS (used in SLD resolution) immediately
% presents a problem. For example, assuming that \scheme{geno} is a predicate
% that generates all (ground) natural numbers in sequence, one may be
% tempted to implement \scheme{mulo} (separating the generation and testing for
% clarity) as

% \schemedisplayspace
% \begin{schemedisplay}
% (define mulo
%   (lambda (x y z)
%     (exist (a b c)
%       (geno a)
%       (== x a)
%       (geno b)
%       (== y b)
%       (geno c)
%       (== z c)
%       (project (a b)
%         (== (* a b) c)))))
% \end{schemedisplay}

% In addition to its obvious inefficiency,
% this implementation%
% \footnote{Bra{\ss}el, Fischer, and Huch \citep{numbers-Curry} describe the drawbacks of this
% residuation-based approach in functional logic programming.}
% often diverges under
% DFS\@. For example, evaluating \scheme{(mulo x y 1)}
% instantiates \scheme{a} and \scheme{b} to \verb|0| and \scheme{c} to \verb|1|, causing the goal
% \scheme{(== (* a b) c)} to fail; after backtracking into \scheme{(geno b)}, \scheme{mulo}
% keeps forever instantiating \scheme{b} to
% larger and larger positive numbers, each time resulting in failure of
% the goal \scheme{(== (* 0 b) 1)}.

% One may attempt to fix this problem by using a complete search
% strategy, such as breadth-first search (BFS) or iteratively-deepening
% DFS\@. Even ignoring efficiency concerns, this
% implementation of \scheme{mulo} is still unacceptable: a complete search strategy
% will find a solution \emph{if it exists}, but if no solution exists
% the search will continue forever.  For example, although BFS finds the
% instantiation of \scheme{y} that satisfies \mbox{\scheme|(mulo 1 y 2)|}, the goal
% \mbox{\scheme|(mulo 2 y 1)|} still diverges. Thus we must devise a termination
% criterion for \scheme{mulo}.

% Devising a termination criterion may seem easy. For example, when
% searching for \scheme{x} and \scheme{y} that satisfy the goal
% \scheme{(mulo x y 5)}, we
% only need to examine \scheme{x} and \scheme{y} values up to~$5$---since
% the search space is finite, the evaluation of the goal
% certainly terminates.  The problem arises when determining whether the
% third argument in a specific use of \scheme{mulo} is instantiated to a
% ground numeral.  This task is trivial if we use the `impure'
% non-logical features provided by Prolog's reflection facilities, such
% as the infamous \verb|var/1| predicate. Even if \verb|var/1| were absent from
% Prolog, it could be emulated using cuts and negation. We
% disavow such tools---we aim to implement our predicates in a pure
% subset of Prolog, without cuts, reflection, or any way to distinguish
% a logic variable. This aim for purity is a
% challenge that in return makes our approach most
% elucidating and extensible.

% The final challenge is that the binary representation of a number
% may not be structurally part of that of its successor.
% For example, the binary numeral 111 (in decimal, 7)
% is not structurally part of its successor 1000. This lack of
% structural inclusion prevents straightforward structural recursion.

% \subsection{Termination and Solvability}

% These challenges make the arithmetic predicates tricky to code.
% It is not obvious that the resulting predicates have the
% claimed properties, in particular, that they terminate in all
% modes. We therefore devote much of the paper to proofs. A typical
% termination theorem we prove assures that evaluating or re-evaluating
% \mbox{\scheme|(addo x y z)|} terminates, provided that the terms initially associated
% with \scheme{x}, \scheme{y}, and \scheme{z} share no logic variables. Successive
% re-evaluations of this goal recursively enumerate the stream of unique
% triples $(x,y,z)$ of potentially non-ground terms whose denotation
% (\S\ref{s:solution-sets-of-addition}) is the domain $\set{(u,v,w) \in x\times
% y\times z : u+v=w}$.  Thus, membership and non-membership are
% computable for base arithmetic relations.

% We guarantee termination only for stand-alone base arithmetic goals but
% not their conjunctions (see \S\ref{s:solution-set}). This
% non-compositionality is expected, since conjunctions of arithmetic
% goals can express Diophantine equations; were such conjunctions
% guaranteed to terminate, we would be able to solve Hilbert's 10th
% problem, which is undecidable~\cite{hilbertstenth}.  We also do not
% guarantee termination if the goal's arguments share variables.  Such a
% goal can be expressed by conjoining a sharing-free base goal and
% equalities.

% We proceed as follows.
% In~\S\ref{s:unary} we define addition and multiplication predicates
% for a \emph{unary} representation of natural numbers.
% We introduce solution sets, \S\ref{s:solution-set}, to carefully
% establish termination for these predicates, laying a
% foundation for our analysis of binary predicates.
% In~\S\ref{s:binary} we introduce our representation of binary
% numerals, and in \S\ref{s:addsub} and~\S\ref{s:mult}
%  we define predicates for binary addition and
% subtraction, and multiplication, respectively.
% In~\S\ref{s:div-exp-log} we briefly describe our predicates
% for binary division, exponentiation, and logarithm.  For lack of
% space, we relegate our pure Prolog implementation of exponentiation,
% logarithm, and non\hyp interleaving binary multiplication to
% the accompanying source
% code,\footnote{\url{http://okmij.org/ftp/Prolog/Arithm/}}
% along with additional proofs, tests, examples, and discussion.
% We review related work in~\S\ref{s:related}, and
% conclude in~\S\ref{s:conclusion}.
% The full version of this
% paper\footnote{\url{http://okmij.org/ftp/Prolog/Arithm/arithm.pdf}}
% includes appendices outlining proofs of the properties of solution sets.
% We have also implemented
% declarative arithmetic as Haskell type-level relations (type classes)
% \cite{lightweight-resources}.

% \section{Predicates for Unary Arithmetic}
% \label{s:unary}

% We begin with unary numerals.
% Unary is simpler than binary, since every unary numeral is
% structurally part of its successor, so we may use structural
% recursion. However, membership and non-membership still need to
% be decidable for the base arithmetic predicates, whose domains are
% infinite however they are represented.
% Hence, the unary case already presents our main challenges.
% The unary case also lets us introduce and illustrate
% most of our terminology in this section.

% We represent unary numerals as lists of atoms \schemeresult{u}: \scheme{`()} denotes zero,
% \scheme{`(u)} denotes one, \scheme{`(u u)} denotes two, etc.%
% \footnote{We could just as easily use a more common representation
% $z$, $s(z)$, $s(s(z))$, etc. We chose lists for consistency with our
%   binary representation.}  Throughout this section
% we use the shorthand \bn{n} to indicate our representation of
% the number $n$---that is, the list of \schemeresult{u}'s of length~$n$.

% Although miniKanren is not statically typed, we assume an
% implicit type of `unary numerals' and an implicit
% typing of logic variables. For example, the implicit type of the term
% \scheme{`(u u . ,x)} is `unary numeral'; the logic variable \scheme{x} has
% the same type. The type predicate for unary numerals can be expressed
% as a generator:

% \schemedisplayspace
% \begin{schemedisplay}
% (define genuo
%   (lambda-e (t)
%     (`(()))
%     (`((u . ,x)) (genuo x))))
% \end{schemedisplay}

% \noindent A term \scheme{t} has the type of `unary numeral' if the goal \scheme{(genuo t)}
% succeeds.  When providing denotations for terms and goals we
% use the implicit type of a logic variable to characterize the
% variable's domain.

% We can add unary numerals with a special case of the
% \scheme{appendo} predicate.

% \schemedisplayspace
% \begin{schemedisplay}
% (define addo
%   (lambda-e (n m s)
%     (`(() ,x ,x))
%     (`((u . ,x) ,y (u . ,z)) (addo x y z))))
% \end{schemedisplay}

% \noindent We can use \scheme{addo} to add numerals: the goal
% \scheme{(addo bn1 bn2 x)} unifies \scheme{x} with \bn3.  We can also use \scheme{addo} for
% subtraction: both \scheme{(addo x bn1 bn3)} and
% \scheme{(addo bn1 x bn3)} unify \scheme{x} with \bn2, and the evaluation of
% \scheme{(addo x bn3 bn1)} fails finitely. We can further use \scheme{addo} to
% decompose a number into its summands: for example, \scheme{(addo x y bn3)}
% has four solutions, in which \scheme{x} and \scheme{y} are unified in turn with
% $\bn0$ and $\bn3$, $\bn1$ and $\bn2$, $\bn2$ and $\bn1$, and $\bn3$
% and $\bn0$. Finally, passing three distinct uninstantiated logic
% variables to \scheme{addo} lets us enumerate the domain of addition over the
% natural numbers.  The evaluation of the query \scheme{(addo x y z)} in miniKanren yields an infinite set of solutions; here are the first three, assuming a {\em depth-first} search strategy:

% \schemedisplayspace
% \begin{schemedisplay}
% (run3 (q)
%   (exist (x y z)
%     (addo x y z)
%     (== `(,x ,y ,z) q)))  $\Rightarrow$
% \end{schemedisplay}
% \nspace
% \begin{schemeresponse}
% ((() _$_{_{0}}$ _$_{_{0}}$)
%  ((u) _$_{_{0}}$ (u . _$_{_{0}}$))
%  ((u u) _$_{_{0}}$ (u u . _$_{_{0}}$)))
% \end{schemeresponse}

% \noindent This stream of solutions represents the infinite addition
% relation \emph{in two different ways}. First, the goal produces an
% infinite number of solutions; we can always re-evaluate the
% goal to get another solution. Second, each solution represents
% infinitely many triples, all members of
% the addition relation. For example, the second solution
% compactly represents the infinitely many triples of naturals $(x,y,z)$
% for which $x$ is one and $z$ is the successor of $y$.  Each instantiation
% of the free logic variable \schemeresult|_$_{_{0}}$| to a member of its domain
% (corresponding to its implicit type) yields a new triple of naturals
% that is a member of the addition relation. We will make extensive use of
% this compact representation of infinite domains when proving
% termination properties of our predicates.

% \subsection{Solution Sets}\label{s:solution-set}

% To formulate propositions about \scheme{addo} and other predicates, we
% introduce the notion of \emph{solution sets}, which accounts for the
% search strategy used to run a logic program (unlike other procedural
% notions of solutions).  We use miniKanren syntax.
% We identify a bound logic variable with the term it is bound to,
% so all variables are free for us, as for Lloyd \cite{lloyd:lp}.
% Our goals are all pure (contain no \scheme|varo|, \scheme|project|,
% negation, or \scheme|conda|/\scheme|condu|).

% We assume an \emph{idempotent} notion of substitution
% \cite{FBaade01}: a substitution~$\theta$
% is a finite map $\set{x_i=t_i}$ from logic variables~$x_i$ to
% terms~$t_i$ such that no $t_j$ contains any~$x_i$.
% \begin{comment}
% The finite set $\set{x_i}$ is
% the domain $\dom\theta$.
% and the set of variables occurring in
% $\set{t_i}$ is the set $\fv\theta$ of free variables of $\theta$.
% \end{comment}
% We write the application of the substitution $\theta$ to a term $t$ as
% $t\theta$; this application easily extends to tuples of
% terms and sets of tuples.

% \begin{definition}[Conjunction of substitutions]\label{defn:conjunction}
% We define the \emph{conjunction} $\theta\xi$ of two
% substitutions $\theta$ and $\xi$ by treating them
% as sets of equations $\set{x_i = t_i}$: we combine both
% sets (the result may contain two equations for the same $x_i$) and use
% unification to solve the resulting equations
% \cite[\S2.2.3]{FBaade01}. Our conjunction of substitutions is thus
% commutative and associative.  Because of the unification our
% conjunction is partial: if unification fails we call
% the original substitutions contradictory.
% \end{definition}

% \begin{comment}
% Notion of instantiatedness and instantiatedness tree from Mercury
% documentation.
% \url{http://www.cs.mu.oz.au/research/mercury/information/doc-release/mercury_ref/Insts-modes-and-mode-definitions.html#Insts-modes-and-mode-definitions}
% \end{comment}

% \newcommand{\bind}{\star}
% \newcommand{\plus}{\oplus}
% \newcommand{\equal}{=}
% We can interpret a goal~$g$ as a function from a substitution
% to a (finite or infinite) stream of substitutions.  Both SLD and
% SLD-interleaving \cite{backtracking} interpret (right-associative and non-commutative)
% disjunction and conjunction by

% \hspace{2.9cm}\scheme|(conde (g1) (g2))|$(\theta) \equal g_{_{1}}(\theta) \plus g_{_{2}}(\theta)$,

% \hspace{3.2cm}\scheme|(exist () g1 g2)|$(\theta) \equal g_{_{1}}(\theta) \bind g_{_{2}}$

% % we use ; and , rather than \land and \lor for consistency with Prop 2
% where the \emph{bind} operation $\bind$ is defined recursively by
% \begin{align*}
%     \boldleftparen \boldrightparen                    &\bind f \equal \boldleftparen \boldrightparen, \\
%     \boldleftparen \theta\ \centerdot\ \vec\theta \boldrightparen &\bind f \equal (f \theta) \plus (\vec\theta \bind f).
% \end{align*}
% The difference between SLD and SLD-interleaving is that $\plus$ above is
% defined as stream concatenation in SLD but stream
% interleaving in SLD-interleaving.

% \begin{definition}[Solution sequence and set]
%   Given an $n$-ary predicate \scheme{g} and $n$ terms $t_1,\ldots,t_n$ that may
%   contain logic variables, a \emph{solution}
%   of a goal {\rm \scheme|(g t1 ... tn)|} is an $n$-tuple
%   $(t^{\prime}_1,\ldots,t^{\prime}_n)$ where each $t^{\prime}_i$ instantiates $t_i$
%   after the evaluation of the goal succeeds
%   using SLD or SLD-interleaving strategy.
%   A solution can be represented as $(t_1,\ldots,t_n)\theta$ for some
%   substitution $\theta$.
%   A \emph{solution sequence} is
%   a sequence of solutions obtained by evaluating and
%   successively re-evaluating a goal.
%   The sequence is a \emph{solution set} if no two of its members
%   unify with each other.
% \end{definition}
% A goal that fails has the empty solution set. A goal whose evaluation
% or re-evaluation does not terminate does not have a solution
% sequence.
% In contrast, the goal \mbox{\scheme|(genuo x)|} does have a solution sequence (which
% can be infinite)
% because its evaluation and re-evaluation always terminates.
% We assume SLD as the default solution strategy.
% If we add the clause \scheme{(addo x '() x)} as a well-meaning optimization ($x+0=x$)
% after the first clause of \scheme{addo} above, the solution sequence may not
% necessarily be a solution set: for example, the goal \scheme{(addo x y bn0)}
% will have $(\bn0,\bn0,\bn0)$ in duplicate.

% The notion of solution sequence is constructive, `proof-theoretic,' to
% be distinguished from a model of a logic program: each
% solution has been actually \emph{derived}, in finite time, from
% the facts and rules at hand using the given solution strategy. A term
% in a solution may contain free logic variables.  We can prove
% the following properties of solution sets
% (see Appendix~A of our full paper).

% \begin{comment}
% \oleg{define the monotonicity property: what happens with the solution
%    sequence if we add one more clause to the definition of the goal,
%    after the existing clauses. Note starvation: under SLD, solution set
%    remains the same if it is already infinite.}
% \end{comment}

% \begin{proposition}\label{p:ss-monotonicity}
% If a goal {\rm \scheme|(g t1 ... tn)|} has a (finite or infinite) solution set
% $\set{ (t_1,\ldots,t_n)\theta_i }$
% and $\xi$ is a substitution that contradicts only finitely many
% $\theta_i$, then the goal
% \mbox{{\rm \scheme|(g t1$\xi$ ... tn$\xi$)|}} has a solution set
% $\set{ (t_1,\ldots,t_n)({\theta_i}\xi) }$,
% omitting the elements where $\theta_i$ and $\xi$ are contradictory.
% \end{proposition}

% The solution set of a conjunction of goals
% \scheme{(g1 t11 ... t1n)} and \scheme{(g2 t21 ... t2n)} is
% (as in a natural database join)
% the set of tuples $\set{ (t_{11},\ldots,t_{1n},t_{21},\ldots,t_{2n}) }$
% after the evaluation of the conjunction has succeeded.

% \begin{proposition}\label{p:ss-conj-finite}
% If the goals $g_1$ and $g_2$ have a finite solution set,
% then the conjunction of $g_1$ and $g_2$ has a finite solution set.
% \end{proposition}
% This proposition is a corollary of the previous proposition. It
% does not generally hold if the solution set of one of the conjuncts is infinite. For example,

% \schemedisplayspace
% \begin{schemedisplay}
% (define mfo
%   (lambda-e (n m)
%     (`(() (u . ,y)) (genuo y))
%     (`((u . ,x) ,y) (mfo `(u . ,x) y))))
% \end{schemedisplay}

% \noindent The goal \scheme{(mfo x y)}, with the variables \scheme{x} and \scheme{y} free, has the infinite solution set
% $\set{(\bn0,\bn{i}): i \in \mathbb{N}^+}$. However, the (left or right)
% conjunction of this goal with \mbox{\scheme|(== x bn1)|} diverges and has no solution set.
% Similarly, the conjunction of \mbox{\scheme|(mfo x y)|} with \mbox{\scheme|(== x y)|} has no solution set
% either.
% Prop.\,\ref{p:ss-monotonicity} applies to neither conjunction because
% the substitutions $\{x=\bn1\}$ and $\{x=y\}$ both
% contradict infinitely many solution-set substitutions (in fact, all
% of them).
% The latter conjunction is equivalent to the goal
% \scheme{(mfo x x)}; such sharing of variables among the arguments of
% a goal is lethal to the termination guarantees below (such as
% Prop.\,\ref{p:add-unground}).

% \begin{proposition}\label{p:ss-conj-infinite}
% If a goal {\rm \scheme|(g1 t1 ... tn)|} has a finite solution set
% $\set{(t_1,\ldots,t_n)\theta_i}$ and the goal
% \mbox{{\rm \scheme|(g2 $t^{\prime}_1$$\theta_1$ ... $t^{\prime}_m$$\theta_1$)|}} has an infinite solution set
% $\set{(t_1^{\prime}\theta_1,\ldots,t_m^{\prime}\theta_1)\xi_j}$, then
% the conjunction of $g_1$ and $g_2$ has the infinite solution set
% $\set{(t_1,\ldots,t_n,t_1^{\prime},\ldots,t_m^{\prime})\penalty\binoppenalty(\theta_1\xi_j)}$.
% \end{proposition}
% This proposition describes the incompleteness of SLD\@: its underlying
% depth-first search becomes trapped exploring the leftmost
% infinite branch of the search tree. However, using
% the SLD-interleaving strategy, we can strengthen the proposition:

% \begin{proposition}\label{p:ss-conj-interleaving}
% If a goal
% \mbox{{\rm \scheme|(g1 t1 ... tn)|}} has a (finite or infinite) solution set
% $\set{(t_1,\ldots,t_n)\theta_i}$ and the goal
% \mbox{{\rm \scheme|(g2 $t^{\prime}_1$$\theta_i$ ... $t^{\prime}_m$$\theta_i$)|}} has a non-empty (finite or
% infinite) solution set $\set{(t_1^{\prime}\theta_i,\ldots,t_m^{\prime}\theta_i)\xi_{ij}}$
% for each~$i$, then
% the conjunction of $g_1$ and $g_2$ has the solution set
% $\set{ (t_1,\ldots,t_n,t_1^{\prime},\ldots,t_m^{\prime})(\theta_i\xi_{ij}) }$.
% \end{proposition}
% The proof is based on the laws of fair conjunction and disjunction in
% \cite{backtracking}; details are given in
% Appendix~B of our full paper.
% We use analogous properties for disjunctions of goals.

% \subsection{Properties of Addition: Solution Sets of Addition}\label{s:solution-sets-of-addition}

% If $t$ is a term and $n$ is a natural number, then we write
% \mbox{\scheme|`(u$^{n}$ . ,t)|} to mean \mbox{\scheme|`(u ... u . ,t)|} where \mbox{\scheme|`u ... `u|}
% consists of $n$ occurrences of~\scheme{`u}.

% One can easily prove the following propositions:
% \begin{proposition}\label{p:add-ground-XY}
% The goal {\rm \scheme|(addo x y z)|}, where \scheme{x} and \scheme{y} are instantiated to ground
% numerals and \scheme{z} is free, has a singleton solution set
% unifying \scheme{z} with the
% numeral that is the sum of those corresponding to \scheme{x} and \scheme{y}.
% \end{proposition}
% That is, if the first two arguments of \scheme{addo} are instantiated to
% numerals, the goal is decidable and has one solution.
% \begin{proposition}\label{p:add-ground-Z}
% The goal {\rm \scheme|(addo x y z)|} where \scheme{z} is instantiated to a ground numeral
% has a finite solution set.
% \end{proposition}
% The proof is an easy induction on the third argument.

% \begin{proposition}\label{p:add-ground-X}
% The goal {\rm \scheme|(addo x y z)|}, where \scheme{x} is a ground numeral \bn{n} and \scheme{y} and \scheme{z} are
% free, has the singleton solution set
% $\{ (\bn{n},g,${\rm \scheme|`(u$^n$ . ,g)|}$) \}$ where \scheme{g}
% is a free logic variable.
% \end{proposition}
% The proof is by induction on \scheme{x}. The proposition easily extends to
% the case where \scheme{y} and \scheme{z} are arbitrary terms, using
% Prop.\,\ref{p:ss-monotonicity}.

% \begin{proposition}\label{p:add-free}
% The goal {\rm \scheme|(addo x y z)|}, where the arguments are distinct
% free logic variables, has an infinite solution set
% $\{ (\bn{n},g,${\rm \scheme|`(u$^n$ . ,g)|}$) : n\in\mathbb{N} \}$
% where $g$ is a free logic variable. In each solution,
% $x$ is unified to a ground numeral.
% \end{proposition}
% The proof is by induction on $x$ and soundness of SLD resolution.

% \begin{definition}[Denotation of arithmetic solutions]
% The \emph{denotation} $\denot\cdot$ of an arithmetic term or solution set is defined as follows.
% \begin{align*}
% \denot {\bn n} &= \{n\}\\
% \denot t &= \set{\, n \in \mathbb{N} : n \ge m \,} \notag\\[-\jot]
% &\qquad\text{where $t$ is the non-ground term \emph{$\boldleftparen \sfusymbol^m\ \centerdot\ x\boldrightparen$}} \notag\\[-\jot]
% &\qquad\text{where $x$ is a free logic variable of the type of unary numerals}\\
% \denot{(t_1,\ldots,t_n)} &= \denot{t_1} \times \dotsb \times \denot{t_n} \\
% \denot S &= \cup_{s \in S}\denot {s}
% \quad\text{for a solution set $S$ (whose elements are all disjoint)}
% \end{align*}
% \end{definition}

% \noindent
% The previous propositions along with Prop.\,\ref{p:ss-monotonicity} let
% us prove:
% \begin{proposition}\label{p:add-unground}
% The goal {\rm \scheme|(addo x y z)|} where the arguments have no shared logic variables has
% a solution set with \scheme{x} always unified to a ground numeral.
% The denotation of the solution set is
% $\set{(u,v,w) \in \denot{x} \times \denot{y} \times \denot{z} : u+v=w}$.
% \end{proposition}
% The proof simply invokes Prop.\,\ref{p:add-ground-Z} or
% Prop.\,\ref{p:add-ground-X} if $z$ or $x$ is ground.
% If neither $z$ nor $x$ is ground, then the arguments of the goal,
% since they share no logic variables,
% contradict only finitely many solutions in the set of
% Prop.\,\ref{p:add-free}, so we invoke Prop.\,\ref{p:ss-monotonicity}.

% The proposition states that the predicate \scheme{addo} is fully decidable:
% for any arguments sharing no free variables, the predicate
% decides if the denotation of these arguments is in the domain
% of addition \emph{or not}. Furthermore, for any subset of the domain
% of addition of the form
% $\set{(u,v,w) \in \denot{x} \times \denot{y} \times \denot{z} : u+v=w}$,
% there is a goal with exactly this denotation.
% We call such a predicate \emph{faithful}.

% \subsection{Multiplication}\label{s:unary-mul}

% Multiplication of unary numbers may seem as trivial as
% addition. (We will be developing several versions of multiplication,
% so we label the \scheme{mulo} predicates with a numeric version
% to distinguish them.)

% \schemedisplayspace
% \begin{schemedisplay}
% (define mul1o
%   (lambda-e (n m p)
%     (`(() __ ()))
%     (`((u . ,x) ,y ,z)
%      (exist (z1)
%        (mul1o x y z1)
%        (addo z1 y z)))))
% \end{schemedisplay}

% \noindent This predicate directly encodes the inductive definition of
% multiplication: \mbox{$0 \cdot x = 0$,} $(x+1)\cdot y = x\cdot y + y$. Indeed,
% the goal \scheme{(mul1o bn3 bn2 x)} has the singleton solution set with $x$
% unified with $\bn6$. However, the goal \scheme{(mul1o x bn2 bn6)}
% diverges after producing the first solution, the goal
% \scheme{(mul1o x bn2 bn5)} diverges without producing anything, and
% \scheme{(mul1o x y bn6)} overflows the stack after producing three solutions.
% % -- $x=\bn1,y=\bn6$, $x=\bn2,y=\bn3$, $x=\bn3,y=\bn2$ --

% The problem is left-recursion in the second clause: the goal
% \scheme{(mul1o x bn2 z)} with free $x$ and~$z$ requires evaluating
% \scheme{(mul1o x^ bn2 z^)} again with free \scheme{x^} and~\scheme{z^}. Reordering
% goals in the body of the second clause eliminates left-recursion:

% \schemedisplayspace
% \begin{schemedisplay}
% (define mul2o
%   (lambda-e (n m p)
%     (`(() __ ()))
%     (`((u . ,x) ,y ,z)
%      (exist (z1)
%        (addo z1 y z)
%        (mul2o x y z1)))))
% \end{schemedisplay}

% \noindent Now \scheme{(mul2o x bn2 bn6)} has a singleton solution set and
% \scheme{(mul2o x bn2 bn5)} fails finitely.
% However, whereas before
% \scheme{(mul1o bn3 bn2 x)} had a singleton solution set (with $x=\bn6$),
% this version \scheme{mul2o} diverges after the
% first solution, so the goal has no solution set.

% Interestingly, simply swapping the arguments to \scheme{addo} fixes the
% problems.

% \schemedisplayspace
% \begin{schemedisplay}
% (define mul3o
%   (lambda-e (n m p)
%     (`(() __ ()))
%     (`((u . ,x) ,y ,z)
%      (exist (z1)
%        (addo y z1 z)
%        (mul3o x y z1)))))
% \end{schemedisplay}

% \noindent Now \mbox{\scheme|(mul3o x bn2 bn6)|} and \mbox{\scheme|(mul3o bn3 bn2 x)|} both have singleton
% solution sets, and \mbox{\scheme|(mul3o x bn2 bn5)|} fails finitely.
% The reason is important. Evaluating
% \mbox{\scheme|(mul2o bn3 bn2 z)|} requires evaluating
% \mbox{\scheme|(addo z1 bn2 z)|} whereas evaluating
% \mbox{\scheme|(mul3o bn3 bn2 z)|} requires evaluating
% \mbox{\scheme|(addo bn2 z1 z)|}.
% Although both addition goals denote the same relation, the former
% has the infinite solution set
% $\set{ (\bn0,\bn2,\bn2), \penalty\binoppenalty (\bn1,\bn2,\bn3),
%     \penalty\binoppenalty (\bn2,\bn2,\bn4),\ldots}$
% whereas the latter has the singleton solution set
% $\{ (\bn2,g,$\scheme|`(u u . ,g)|$) \}$ (Prop.\,\ref{p:add-ground-X}).
% That makes all the difference, as we prove below.

% However, \scheme{mul3o} is not perfect. Evaluating
% \scheme{(mul3o x y bn6)} overflows the stack,
% because it requires evaluating
% \mbox{\scheme|(addo y z1 bn6)|}, which gives $z_1=\bn6, y=\bn0$ as one
% solution.  This solution causes a recursive call
% \mbox{\scheme|(mul3o x^ y bn6)|}, same as the original call. Thus we must treat
% zero multiplicands separately,
% taking care to avoid overlapping solutions so that the solution
% sequence remains a solution set.

% \schemedisplayspace
% \begin{schemedisplay}
% (define mulo
%   (lambda-e (n m p)
%     (`(() __ ()))
%     (`((u . __) () ()))
%     (`((u . ,x) (u . ,y) ,z)
%      (exist (z1)
%        (addo `(u . ,y) z1 z)
%        (mulo x `(u . ,y) z1)))))
% \end{schemedisplay}

% \noindent This pattern of fixing one problem only to see another problem emerge
% is quite common, which is why we need proofs.

% \begin{comment}
% In conducting the proofs below, we will appeal to the size-change
% termination principle (Jones et al, GPCE 2002) ``a program terminates
% on all inputs if every valid infinite call sequence would, if
% executed, cause an infinite decrease in some parameter values''
% trivially extended to logic programs (exploration of search trees).
% \oleg{use that paper and a paper at FLOPS2006 for relevant literature
%   on termination analysis of logic programs. Mention Mercury's
%   termination checker.}
% \end{comment}

% \begin{proposition}\label{p:mul-ground-XY}
% The goal {\rm \scheme|(mulo x y z)|}, where $x$ and $y$ are instantiated to ground
% numerals and $z$ is free, has the singleton solution set that
% unifies $z$ with the
% numeral that is the product of the numerals for $x$ and $y$.
% \end{proposition}
% The proof is an induction on $x$ using Prop.\,\ref{p:ss-conj-finite}
% and Prop.\,\ref{p:add-ground-X}.
% \begin{comment}
% \oleg{or should we appeal to the size-changing principle?}
% That is, if the first two arguments of \verb|mul/3| are instantiated to
% numerals, the goal is decidable and has at most one solution.
% \end{comment}

% \begin{proposition}\label{p:mul-ground-Z}
% The goal {\rm \scheme|(mulo x y z)|}, where $z$ is instantiated to a ground numeral,
% has a finite solution set.
% \end{proposition}
% The proof depends on Prop.\,\ref{p:ss-conj-finite} and
% Prop.\,\ref{p:add-ground-Z}:
% each solution of
% \scheme{(addo `(u . ,y) z1 z)} instantiates
% $z_1$ to a ground numeral smaller than the numeral for~$z$.
% \begin{comment}
% The latter
% fact follows from the soundness of addition.
% \end{comment}

% \begin{proposition}\label{p:mul-ground-Y}
% The goal {\rm \scheme|(mulo x y z)|}, where $y$ is instantiated to a positive
% ground numeral \bn{n} and $x$ and $z$ are free, has the solution set
% $\set{ (\bn{i},\bn{n},\bn{i\cdot n}) : i \in \mathbb{N} }$. If $y$ is \bn0,
% the solution set is finite: $\{ (\bn0,\bn0,\bn0), (${\rm \scheme|`(u . ,x)|}$,\bn0,\bn0) \}$.
% \end{proposition}
% The proof is by induction on $y$ and Prop.\,\ref{p:add-ground-X}.

% \begin{proposition}\label{p:mul-unground-interleave}
% Under the SLD-interleaving strategy,
% the goal {\rm \scheme|(mulo x y z)|}, where the arguments share no logic variables,
% has a solution set that denotes
% $\set{ (u,v,w) \in \denot{x} \times \denot{y} \times \denot{z} :
% u\cdot v=w}$.
% \end{proposition}
% The proof depends on Props.\,\ref{p:add-unground}, \ref{p:mul-ground-Y}
% and~\ref{p:ss-conj-interleaving}.
% Thus under SLD with interleaving, our \scheme{mulo} predicate is faithful
% to the multiplication
% relation on naturals.

% Without interleaving, the goal \scheme{(mulo x y z)} has the solution set:

% $\{ (\bn0, g,\bn0), (${\rm \scheme|`(u . ,g$^{\prime}$)|}$,\bn0,\bn0), (\bn1,\bn1,\bn1), (\bn2,\bn1,\bn2),(\bn3,\bn1,\bn3),\ldots \}$.

% \noindent The denotation of this solution set
% obviously does not cover the entire
% multiplication relation: the second argument gets `stuck' on~$1$.
% Under SLD\@, then, our predicate \scheme{mulo} covers only an infinitesimal part of
% the domain of multiplication. We can do better: we define
% a predicate \scheme{semimulo} that
% has the \emph{same} termination properties as \scheme{mulo} but covers \emph{half} of the
% domain of multiplication, namely $y \le x$, whichever arguments are instantiated.

% We first define the predicate \scheme{lesso}, corresponding to the less-than
% relation.

% \schemedisplayspace
% \begin{schemedisplay}
% (define lesso
%   (lambda-e (n m)
%     (`(() (__ . __)))
%     (`((u . ,x) (u . ,y)) (lesso x y))))
% \end{schemedisplay}

% \noindent The \scheme{semimulo} predicate is then as follows.

% \schemedisplayspace
% \begin{schemedisplay}
% (define semimulo
%   (lambda-e (n m p)
%     (`(() __ ()))
%     (`((u . __) () ()))
%     (`((u . ,x) (u . ,y) ,z) (lesso x z) (lesso y `(u . ,x))
%      (mulo `(u . ,x) `(u . ,y) z))))
% \end{schemedisplay}

% \begin{proposition}
% The goal {\rm \scheme|(semimulo x y z)|}, where the arguments are free logic variables,
% has a solution set that denotes
% $\set{ (u,v,w) \in \mathbb{N}^3: v \le u,\, u\cdot v=w }$.
% \end{proposition}
% The proof depends on the goal \scheme{(lesso x z)}, which asserts the trivial inequality
% $x < (x+1)\cdot (y+1)$ for all $x,y \in \mathbb{N}$.
% With free $x$ and $z$, the goal
% \scheme{(lesso x z)} has an infinite solution set whose solutions each
% instantiate $x$ to a ground numeral.
% The goal \scheme{(lesso y `(u . ,x))}
% then has a \emph{finite} solution set that grounds $y$ as well.
% The last goal has thus a singleton
% solution set, by Prop.\,\ref{p:mul-ground-XY}.

% These attempts to define decidable multiplication even for the
% seemingly trivial unary case show the difficulties that become more
% pronounced as we move to binary arithmetic. We rely on a
% finite representation of infinite domains, precise instantiatedness
% analysis, and reasoning about SLD using search trees.

% \section{Binary Numerals}\label{s:binary}

% We represent numerals as lists of binary digits in little-endian order
% (least significant bit first), with zero represented as the empty
% list.  A zero bit is denoted by \schemeresult{o} (lower-case `oh') and a one bit is denoted
% by \schemeresult{l} (lower-case `el')---to distinguish a
% number from its representation.  For example, the terms \scheme{`()}, \scheme{`(l)},
% \scheme{`(o l)}, \scheme{`(l l)}, \scheme{`(o o l)} represent $0$ through~$4$.
% The last bit of
% a positive numeral \emph{must} be~\schemeresult{l}. Our code below takes special
% care to maintain this well-formedness condition.
% It is trivial to convert
% between this and Prolog's native representations of integers.

% We often use the auxiliary one-clause
% predicates \scheme{zeroo}, \scheme{poso}, and \scheme{gtlo}:

% \schemedisplayspace
% \begin{schemedisplay}
% (define zeroo
%   (lambda-e (n)
%     (`(()))))

% (define poso
%   (lambda-e (n)
%     (`((__ . __)))))

% (define gtlo
%   (lambda-e (n)
%     (`((__ __ . __)))))
% \end{schemedisplay}

% \noindent The goal \scheme{(zeroo n)} succeeds if $n$ is zero. The goal \scheme{(poso n)}
% succeeds if $n$ is positive. The goal \scheme{(gtlo n)} succeeds
% if $n$ is at least two.

% The predicate \scheme{genbo} below expresses the
% implicit type of binary numerals.

% \schemedisplayspace
% \begin{schemedisplay}
% (define genbo
%   (lambda-e (n)
%     (`(()))
%     (`((l . ,x)) (genbo x))
%     (`((o . ,x)) (poso x) (genbo x))))
% \end{schemedisplay}

% \noindent The presence of \scheme{(poso x)} in the last clause ensures that the last
% bit of a positive numeral is~\schemeresult{l}. The code below contains similar
% guarding occurrences of \scheme{poso}.

% Recall that one challenge of binary arithmetic is that a numeral
% is not structurally part of its
% successor. However, such a notion of inclusion exists (with
% the attendant induction principle) if we consider the `length' of a binary
% number, i.e., the number of bits in its binary representation.
% More precisely, the length~$\norm{n}$ of a numeral~$n$
% is $\floor{\log_2 n} + 1$ if $n>0$, and $0$ if $n=0$. We define \scheme{lesslo} by

% \schemedisplayspace
% \begin{schemedisplay}
% (define lesslo
%   (lambda-e (n m)
%     (`(() (__ . __)))
%     (`((__ . ,x) (__ . ,y)) (lesslo x y))))
% \end{schemedisplay}

% \noindent It has the meaning and form of the unary \scheme{lesso}
% in~\S\ref{s:unary-mul}---and the same termination properties---but
% compares the length of binary numbers rather their magnitude.

% \section{Addition and Subtraction}\label{s:addsub}

% % http://en.wikipedia.org/wiki/Adder_(electronics)

% % full adder: one-bit adder
% % what below is full_adder is nbit adder (multiple-bit) adder
% % of the ripple-carry adder type

% Our treatment of addition is inspired by hardware
% full-adders and multi-bit adders,
% as found in a digital computer's arithmetic logic
% unit \citep{hennessy-computer}.  A one-bit full-adder
% \mbox{\scheme|(full1-addero cin a b s cout)|} relates two input bits $a,b$ and the incoming
% carry bit $c_{\mathrm{in}}$ with the sum bit~$s$ and the outgoing carry
% bit $c_{\mathrm{out}}$, according
% to the equation $c_{\mathrm{in}} + a + b = s + 2 c_{\mathrm{out}}$. In miniKanren,
% we define \scheme{full1-addero} by enumerating eight facts:

% \schemedisplayspace
% \begin{schemedisplay}
% (define full1-addero
%   (lambda-e (cin a b s cout)
%     (`(o o o o o))
%     (`(o o l l o))
%     (`(o l o l o))
%     (`(o l l o l))
%     (`(l o o l o))
%     (`(l o l o l))
%     (`(l l o o l))
%     (`(l l l l l))))
% \end{schemedisplay}

% The multi-bit adder \mbox{\scheme|(fulln-addero cin a b s)|} relates
% the incoming carry bit \scheme{cin} (either \schemeresult|o| or \schemeresult|l|),
% two binary numbers $a,b$, and their sum~$s$, according to the equation $c_{\mathrm{in}} + a + b = s$.
% It is defined by recursively combining one-bit adders
% as in a ripple-carry adder of digital logic,
% only in our case, the summands' bitwidths need not be the same or limited.

% \schemedisplayspace
% \begin{schemedisplay}
% (define fulln-addero
%   (lambda-e (cin a b r)
%     (`(o ,a () ,a))
%     (`(o () ,b ,b) (poso b))
%     (`(l ,a () ,r) (fulln-addero 'o a '(l) r))
%     (`(l () ,b ,r) (poso b) (fulln-addero 'o '(l) b r))
%     (`(,cin (l) (l) (,r1 ,r2)) (full1-addero cin 'l 'l r1 r2))
%     (`(,cin (l) (,ba . ,bd) (,ra . ,rd)) (poso bd) (poso rd)
%      (exist (cout)
%        (full1-addero cin 'l ba ra cout)
%        (fulln-addero cout '() bd rd)))
%     (`(,cin ,a (l) ,r) (gtlo a) (gtlo r)
%      (fulln-addero cin '(l) a r))
%     (`(,cin (,aa . ,ad) (,ba . ,bd) (,ra . ,rd))
%      (poso ad) (poso bd) (poso rd)
%      (exist (cout)
%        (full1-addero cin aa ba ra cout)
%        (fulln-addero cout ad bd rd)))))
% \end{schemedisplay}

% \noindent The first four clauses above deal with the cases
% of a summand being zero. The next three clauses handle
% the cases of a summand being one. The last clause adds
% numbers at least two bits wide. We take
% care to keep clauses from overlapping, so the solution
% sequence of a \scheme{fulln-addero} goal is a solution set. The
% splitting of the cases and the many occurrences of \scheme{poso} are
% necessary to keep all numerals in a solution `well-typed':
% If logic variables in a solution are instantiated according to their
% implicit types, we never see a list whose last element unifies with \schemeresult{o}.
% \begin{comment}
% i.e., satisfy the typing predicate \verb|genb/1|. If free logic variables in a
% solution are instantiated according to their implicit types,
% all the numerals are well-formed---we never have a finite list
% whose last element unifies with \verb|o|.
% \end{comment}

% This multi-bit adder expresses binary addition, subtraction, and
% ordering:

% \schemedisplayspace
% \begin{schemedisplay}
% (define addo
%   (lambda (a b c)
%     (fulln-addero 'o a b c)))

% (define subo
%   (lambda (a b c)
%     (addo b c a)))

% (define lesso
%   (lambda (a b)
%     (exist (x)
%       (poso x)
%       (addo a x b))))
% \end{schemedisplay}

% \begin{comment}
% The latter says that the number $a$ is less than the number $b$ if
% there exists a positive number $x$ that can be added to $a$ to produce
% $b$.
% \end{comment}

% Our predicate \scheme{addo} for binary numerals satisfies
% Prop.\,\ref{p:add-ground-XY} (by induction on \mbox{$4 c_{\mathrm{in}} + 3a + b$}) and
% Prop.\,\ref{p:add-ground-Z}.
% However, due to carry propagation (clauses 4 and 6 of \scheme{fulln-addero}),
% Prop.\,\ref{p:add-ground-X} and Prop.\,\ref{p:add-free} no longer
% accurately describe the solution sets of binary \scheme{addo}:
% the goal \mbox{\scheme|(addo x y z)|}, with either $x$ or $y$ ground and the other
% arguments being distinct free variables, has an infinite solution
% set.

% Prop.\,\ref{p:add-unground} holds (without $x$ being always
% ground) only in the case of SLD with interleaving;
% for SLD\@, we can develop a binary addition
% predicate that covers half of the domain of addition,
% as in~\S\ref{s:unary-mul}.
% The proofs begin by unrolling the recursion in clauses 3, 4,
% and~7 of \scheme{fulln-addero} (splitting cases for clauses 3 and~4),
% so that \scheme{fulln-addero} invokes itself recursively only for shorter
% arguments.
% \begin{comment}
% \oleg{For the full proof, we need
%   one more proposition about the interleaving, about adding
%   to the disjunction.
%   Actually, the proposition is as follows: limited completeness of
%   SLD with interleaving: if a goal $\mathtt{g}(\vec t)$ has a
%   (possibly infinite) solution set, and $\mathtt{g}(\vec t)\theta$
%   has a non-empty solution set, the solution set of the latter goal is
%   included in the solution set of the former goal. That is not the
%   full completeness since it does not address the divergence. That's
%   why there is a premise that a goal must have a solution set to
%   start with. To prove that the solution set exists, we can prove that
%   given any particular `depth' the strategy will find a fact there.
% }
% \end{comment}

% \section{Multiplication}\label{s:mult}

% Binary multiplication may seem an obvious generalization of unary
% multiplication. The most complex case is to multiply an odd number by
% a positive one, $(2n + 1) m = 2 (n m) + m$, because it
% involves addition. One may think that the
% approach in \scheme{mulo} in~\S\ref{s:unary-mul} will work here. Alas, binary
% addition does not satisfy Prop.\,\ref{p:add-ground-X}, so we must
% turn to a much less obvious solution.

% \schemedisplayspace
% \begin{schemedisplay}
% (define mulo
%   (lambda-e (n m p)
%     (`(() ,m ()))
%     (`(,n () ()) (poso n))
%     (`((l) ,m ,m) (poso m))
%     (`((o . ,nd) ,m (o . ,pd)) (poso m) (poso nd) (poso pd) (mulo nd m pd))
%     (`((l . ,nd) ,m ,p) (poso m) (poso nd) (gtlo p)
%      (exist (p1)
%        (lessl3o p1 p `(l . ,nd) m)
%        (mulo nd m p1)
%        (addo `(o . ,p1) m p)))))
% \end{schemedisplay}

% \noindent This solution relies on a seemingly contrived predicate \scheme{lessl3o}:

% \schemedisplayspace
% \begin{schemedisplay}
% (define lessl3o
%   (lambda-e (p1 p n m)
%     (`(() (__ . __) __ __))
%     (`((__ . ,p1d) (__ . ,pd) () (__ . ,md)) (lessl3o p1d pd '() md))
%     (`((__ . ,p1d) (__ . ,pd) (__ . ,nd) m) (lessl3o p1d pd nd m))))
% \end{schemedisplay}

% \noindent The goal \mbox{\scheme|(lessl3o p1 p n m)|} relates four numerals such that
% \mbox{$\norm{p_1} < \min(\norm{p},\penalty\binoppenalty \norm{n} + \norm{m} + 1)$}.
% As long as the arguments of the goal, \emph{however instantiated},
% share no logic variables, the goal has a solution set. In any solution,
% $p_1$ is a numeral whose bits may be free but whose length is fixed.
% We call such numerals \emph{L-instantiated}.
% Moreover, whenever $p_1$, $p$, or both $n$ and $m$ are
% L-instantiated, the solution set is finite.

% In the code for binary \scheme{mulo} above, \scheme{lessl3o} occurs in a clause that is
% selected when multiplying an odd number $2 n + 1$ (where $n>0$) by a positive
% number~$m$ to yield~$p$. Under these conditions, clearly
% $\floor{\log_2 n m}$ is less than both $\floor{\log_2 p}$
% and $\floor{\log_2(2n+1)} + \floor{\log_2 m} + 2$, so the
% constraint imposed by \scheme{lessl3o} does not affect the declarative meaning
% of \scheme{mulo}.
% The guarantee
% of \scheme{lessl3o} mentioned above lets us prove
% Prop.\,\ref{p:mul-ground-XY} and Prop.\,\ref{p:mul-ground-Z} for binary
% multiplication. For Prop.\,\ref{p:mul-ground-Z},
% \scheme{lessl3o} ensures that $p_1$ is L-instantiated,
% so we can use induction to prove that \mbox{\scheme|(mulo n m p)|} with an
% L-instantiated $p$ has a finite solution set.

% The important role of \scheme{lessl3o} can be informally explained as follows.
% Given the goal \mbox{\scheme|(mulo x y z)|}, when $x$ and $y$ are instantiated but $z$
% is free, or when $z$ is instantiated but $x$ and $y$ are free, the
% search space is finite even though the free variables can be
% instantiated an infinite number of ways: the length of the
% product limits the lengths of the multiplicands, and vice versa.
% The predicate \scheme{lessl3o} enforces these limits, even
% though our code cannot distinguish these two cases by
% determining which arguments are instantiated.

% The \scheme{mulo} predicate also satisfies
% Prop.\,\ref{p:mul-unground-interleave} (the proof again relies on the
% properties of \scheme{lessl3o}). As in the unary case, using SLD without
% interleaving, we cannot cover the whole domain of natural
% multiplication---but we can cover half of it. The technique is
% essentially the same as explained for unary
% multiplication.

% \section{Division, Exponentiation, and Logarithm}\label{s:div-exp-log}

% Our predicate for division with remainder
% \mbox{\scheme|(divo n m q r)|} relates four natural
% numbers such that $n = m \cdot q + r < m\cdot(q+1)$. The implementation is
% quite complex so as to finitely fail as often as possible: for example, not only
% when the divisor $m$ is zero, but also in the case
% \mbox{\scheme|(divo `(o . ,x) '(o l) q '(l))|} with \emph{free} $x$ and $q$, as
% no even number divided by~$2$ gives the remainder~$1$.
% Our algorithm is akin to long division as taught in elementary school, only
% done right-to-left. At each step, we determine at
% least one bit of the quotient in finite time.

% First, we handle the easy case when the divisor~$m$ is
% bigger than the dividend~$n$, so $q=0$ and $n=r$.

% \schemedisplayspace
% \begin{schemedisplay}
% (define divo
%   (lambda-e (n m q r)
%     (`(,n ,m () ,r) (== n r) (lesso n m))
%     ...))
% \end{schemedisplay}

% \noindent Otherwise, $q$ must be positive.
% The second easy case is when $n$ is at least~$m$
% and has the same length as~$m$.

% \schemedisplayspace
% \begin{schemedisplay}
% (define divo
%   (lambda-e (n m q r)
%     ...
%     (`(,n ,m (l) ,r) (samelo n m) (addo r m n) (lesso r m))
%     ...))
% \end{schemedisplay}

% \noindent This code relies on the auxiliary predicate \scheme{samelo}, which holds if its
% two arguments are binary numerals with the same number of digits.

% \schemedisplayspace
% \begin{schemedisplay}
% (define samelo
%   (lambda-e (n m)
%     (`(() ()))
%     (`((__ . ,x) (__ . ,y)) (samelo x y))))
% \end{schemedisplay}

% The main case of division is when $n$ has more digits than~$m$.
% The key is to represent $n = m \cdot q + r < m\cdot(q+1)$ as the conjunction
% of the two relations
% \begin{align*}
% 2^{l+1}r_1 &= m q_2 + r - n_2
% &&\text{and}&
% n_1 &= m q_1 + r_1
% \end{align*}
% where
% \begin{align*}
% n &= 2^{l+1} n_1 + n_2, & q &= 2^{l+1} q_1 + q_2, & l &= \norm{r},
% \end{align*}
% and $n_2$ and~$q_2$ are at most $l+1$ long.
% Given $l$, then, we can decide the first
% relation. Because $0 \le r_1 < m$, we can invoke
% \mbox{\scheme|(divo n1 m q1 r1)|} recursively to decide the second
% relation. That gives us a convenient induction principle:
% either $n_1$ is zero and so $q_1$ and $m q_2 + r - n_2$ are both zero,
% or $n_1$ is positive and shorter than~$n$.  These two cases correspond
% to the disjunction below.

% \schemedisplayspace
% \begin{schemedisplay}
% (define divo
%   (lambda-e (n m q r)
%     ...
%     (`(,n ,m ,q ,r) (lesslo m n) (lesso r m) (poso q)
%      (exist (n1 n2 q1 q2 q2m q2md r1 rd)
%        (splito n r n1 n2)
%        (splito q r q1 q2)
%        (conde
%          ((== '() n1)
%           (== '() q1)
%           (subo n2 r q2m)
%           (mulo q2 m q2m))
%          ((poso n1)
%           (mulo q2 m q2m)
%           (addo q2m r q2md)
%           (subo q2md n2 rd)
%           (splito rd r r1 '())
%           (divo n1 m q1 r1)))))))
% \end{schemedisplay}

% \noindent The calls to \scheme{lesslo} and \scheme{lesso} at the beginning of this code
% ensure that \scheme{m} and then \scheme{r} are both L-instantiated.
% The code also relies on the predicate \scheme{splito} to `split' a binary
% numeral at a given length: The goal
% \mbox{\scheme|(splito n r n1 n2)|} holds if
% $n = 2^{l+1} n_1 + n_2$ where $l = \norm{r}$ and $n_2 < 2^{l+1}$. The goal should be
% invoked only when $r$ is L-instantiated, which is the case in the
% \scheme{divo} code above. The goal has a finite solution set, in which
% $n_2$ is L-instantiated in every solution.

% \schemedisplayspace
% \begin{schemedisplay}
% (define splito (n r n1 n2)
%   (lambda-e
%     (`(() __ () ()))
%     (`((o ,b . ,n) () (,b . ,n) ()))
%     (`((l . ,n) () ,n (l)))
%     (`((o ,b . ,n) (__ . ,r) ,n1 ()) (splito `(,b . ,n) r n1 '()))
%     (`((l . ,n) (__ . ,r) ,n1 (l)) (splito n r n1 '()))
%     (`((,b . ,n) (__ . ,r) ,n1 (,b . ,n2)) (poso n2) (splito n r n1 n2))))
% \end{schemedisplay}

% Our predicate
% \mbox{\scheme|(logo n b q r)|}
% relates four numbers such that
% $n = b^q + r < b^{q+1}$, so it implements
% exponentiation, logarithm, and
% $n$-th root.
% Our implementation uses an
% upper bound on $r$, namely $r b < n (b-1)$, and upper and lower bounds on $q$,
% namely $(\norm{b}-1) q < \norm{n}$ and $\norm{n}-1 < \norm{b} (q+1)$. These
% bounds constrain the search just as \scheme{lessl3o} does for
% binary multiplication in~\S\ref{s:mult}. Because the base-$2$
% case is so simple, we treat it separately.

% \section{Conclusions}\label{s:conclusion}

% [TODO Integrate this text into rest of chapter, and thesis conclusion,
% as appropriate.]

% In a pure logic programming system,
% we have declared decidable arithmetic of unrestricted unary and
% binary natural numbers: addition, multiplication, division with
% remainder, exponentiation, and logarithm with remainder.
% The declared relations have unlimited domain and
% are free from any mode restrictions or annotations.  We have proven
% that our arithmetic predicates are fully decidable and faithfully
% represent the corresponding arithmetic relations.  Our technique can
% be easily extended to full integers (i.e., a tuple of the sign and a
% natural number).

% The gist of our approach is to limit the search space by a
% balancing act of computing \emph{bidirectional} bounds from arguments of unknown
% instantiatedness. For example, the key to decidable
% multiplication is to limit the search using bounds that
% the inputs place on each other, without
% testing whether any input is instantiated. We
% also rely on the ability to finitely represent infinite domains
% using logic variables, so that goals with infinite denotations
% may have only a finite solution set.
% Our notion of solution sets and the associated proof techniques
% are not specific to arithmetic and SLD\@; rather, they appear
% applicable to logic programming in other domains using a variety
% of search strategies.

% %\UndefineShortVerb{\|}

% \newpage

% % [fix typography:  remove sfu, bind definition should use bold parens and dot]

% % [should include expo and logo code.  Make sure logo code is the corrected code.]

% % [need to test all of this]

% % [I dumped the two proofs in the appendix--refer the reader to the published paper, or the full version on Oleg's site]

% % [should I build up the definition of divo one function at a time?  Probably not as important if we use the lambda-e macro.]

% % [need to discuss varo, project, conda, condu, somewhere, preferably before this chapter]

% % [Careful with the use of 'we'.  Should refer to authors, not 'we', when referring to work I wasn't part of (for example, Ken and Oleg's arithmetic system using Haskell typeclasses).]

% % [is it necessary or desirable to include all of the proofs?  Or can I point to the full paper?]

% % [the *full* paper, with proof outlines, wasn't presented at FLOPS.  the full paper is on Oleg's website (see footnote)]

% % [does this code include the fix for logo?]

% % [check against canonical miniKanren arithmetic code]

% % [can we write a relational quicksort program, like in Apt's paper?
% % See page 3 of Apt's paper 'Declarative Programming in Prolog']

% % \noindent [also, can we write the trans relation w/out negation?  see
% % page 15 of Apt's paper]

% % [no constraints (other than equality constraints via unification).]

% % [individual operations are decidable]

% % Interesting examples (need to translate to chapter's conventions and names):

% % factoring

% % \schemedisplayspace
% % \begin{schemedisplay}
% % (run* (q)
% %   (exist (x y)
% %     (mulo x y '(o o l l))
% %     (== `(,x ,y) q)))
% % \end{schemedisplay}
% % \begin{schemeresponse}
% % (((l) (o o l l))
% %  ((o o l l) (l))
% %  ((o l) (o l l))
% %  ((o o l) (l l))
% %  ((l l) (o o l))
% %  ((o l l) (o l)))
% % \end{schemeresponse}

% % division

% % \schemedisplayspace
% % \begin{schemedisplay}
% % (run* (t)
% %   (exist (x q r)
% %     (divo '(o l l) x q r)
% %     (== `(,x ,q ,r) t)))
% % \end{schemedisplay}
% % \begin{schemeresponse}
% % (((_.0 _.1 _.2 _.3 . _.4) () (o l l))
% %  ((l l l) () (o l l))
% %  ((o l l) (l) ())
% %  ((l o l) (l) (l))
% %  ((o o l) (l) (o l))
% %  ((l) (o l l) ())
% %  ((l l) (o l) ())
% %  ((o l) (l l) ()))
% % \end{schemeresponse}