(more or less finished but not polished … feedback welcome)
Extend our methodology of proving termination of computational processes and programs
How to construct an ARS from a program.
Learning about the discrete maths technology of partial orders, which are of fundamental importance in many areas of computer science and the sciences in general
On the way we illustrate some more useful programming languages technology (we may come back to those in more detail later)
This is already quite a lot of material and will be taught over the course of two lectures.
What is a good way of proving termination of Euclids algorithm, which is sometimes considered to be the historically first algorithm.[1]
int a
int b
function gcd(a, b)
while a ≠ b
if a > b
a := a − b;
else
b := b − a;
return a;
Exercise: Write the algorithm recursively.
How to prove termination by exhibiting a measure function
If we want to find
If you learned about hardware you should relate the following explanations to what you know about program counters and registers, about how the program and the data are stored in memory and about how the CPU accesses the program and the data.
Roughly speaking, when defining an ARS
But we don't need to go down to the machine level to understand what is going on. It is enough to understand some basics about John von Neumann's idea of how computation separates into control and data. [2]
The general idea is to introduce locations
where
We see now that in this simple example, we do not need to keep track of the locations after all, that is, we can go to a more abstract ARS where
So on order to find a measure function
Exercise: Show that
While in this case it was not too hard to guess that addition would be a good measure function, there is an easier way. Namely to think of
So our next task is to understand how to build larger orders (such as
For this we need to understand we mean by order in general. While we can identify particular orders such as
These are the topics of the next section.
We want to define from the order
Exercise: Show that a first try of
From a mathematical point of view, the reason for the failed try of the previous exercise is that we work with a strict "greater than" relation instead of with the often more useful notion of "greater or equal".
So what is an order? It is time to make some definitions. We need what we learned about relations.
Definition: A pre-order
This axiomatises the intuitive notion of "less-or-equal".[5]
Examples:
Exercise: The points in the plane are not linearly ordered. Define at least two different ways of making them into a pre-order or partial order.
We can also axiomatise the notion of strict "less-than":
Definition: A strict partial order, or just strict order,
To ease notation we make the following
Convention: Let
Let
The definitions above already suggest that it doesn't matter whether we define a relation as a partial order or a strict order. We can always go back and forth. Indeed, whether we start with
We formulate this as a proposition.
Proposition: For every partial order
Exercise: It is interesting at this point to think about whether a similar correspondence can be found for pre-orders instead of partial orders.
While the second definition (strict partial order) is closer to our application (proving termination), the first definition is often easier to use. For example, the product of two partial orders is easily defined in the obvious way:
Definition: Let
be partial orders. Define the product partial order
where, abbreviating
Exercise: Go back to the previous exercise. Show that you get a useful notion of strict order on
Exercise: Show termination of the ARS of the Euclidean algorithm with a measure function into
By the way, in order to justify the use of measure functions into
Definition: A partial order
Remark: It is the same to say that
Fact: Let
Remark: To summarise, from the point of view of our application, partial orders are interesting because the product of linear orders is not linear but only partial in general.
This finishes the first lecture on the topic
Example: We talked about The Ackermann function, see also the Wikipedia article for more information. If you implemented the Ackermann function, you know that termination is not experimentally observable even for quite small inputs. This shows that what happens computationally is not straight-forward. But the termination argument that we are going to see is. This is a good example for the power of abstraction: Complicated computations can be understood, at least to some extend, by simple abstractions.
Let us go back another example that we have seen already and which I quote again below.
Example: Let
We can also write this as a program, where the ->
notation is much like an if ... then ...
but allows to choose non-deterministically between the two branches as long as the condition (the "guard") is satisfied. This is called Dijkstra's guarded commands.
function example(i,j)
j>0 -> example(i,j-1)
i>0 -> example(i-1,i-1)
Exercise: This program only shows control flow. No actual data is computed. Can you add some data to the program?
Activity: Recall how to prove termination of this programm using a measure function into
Finding the measure function
In the following, we will define a way of ordering
We have already seen how to define the product of two partial orders. But this order requires us to get small either in the first or in the second component while keeping the other constant.
The lexicographic ordering allows the second component to behave arbitrarily as long as we get smaller on the first component. Only if we stay the same in the first component, the second component needs to get smaller.
In other words:
Definition: Let
where, abbreviating
We denote the lexicogrphic product by
Fact: If
Example: Let
The lexicographic product captures exactly the idea that the goal difference does not matter if one team has more points than the other, but that the goal difference decides if two teams have the same number of points. Btw, this ranking is only a preorder if two teams have the same number of points and the same goal difference.
Exercise: Model the program
function example(i,j)
j>0 -> example(i,j-1)
i>0 -> example(i-1,i-1)
by an ARS
Example: Let us apply the same technology to the program
a(0,n) = n+1
a(m+1,0) = a(m,1)
a(m+1,n+1) = a(m, a(m+1,n))
We immediately that each recursive call either makes the first argument smaller or leaves the first the same and makes the second argument smaller. This seems taylored for the lexicographic ordering. So let us take again
where
The principle of well-founded induction states that to prove that a property
Let us see how this plays out in our example.
There are three cases to check.
First,
Second,
Third,
Extended our methodology of proving termination of computational processes and programs
Constructed ARSs from a programs.
Learned about the discrete maths technology of partial orders, which are of fundamental importance in many areas of computer science and the sciences in general
On the way we illustrated some more useful programming languages technology
int a
int b
function gcd(a, b)
if a = b
return a
else
if a > b
gcd(a−b, b)
else
gcd(a, b-a)
Given the astonishing amount of science we inherited from the ancient greeks, it should not come as a surprise that we honour them by using Greek letters such as
For the historically interested, why not look at John von Neumann's First Draft Report on the EDVAC. ↩︎
Notice that this is analogous to building bigger data types from smaller data types (like you build eg a Java class from more basic types such as int or bool or char etc). ↩︎
We switched from "greater than" to "less than" because this is more common in general. Of course, it does not really make a difference. ↩︎
More generally, preferences in economics (such as which goods are prefered by consumers) are preorders. This also applies to all areas of decision making. ↩︎
A relation