See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/228798863

Algorithmic Problem Solving—Three Years On

Article · January 2006

CITATIONS READS

5 1,726

1 author:

Roland Backhouse
University of Nottingham
126 PUBLICATIONS   1,517 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Regular Algebra View project

Algorithmic Problem Solving View project

All content following this page was uploaded by Roland Backhouse on 06 January 2014.

The user has requested enhancement of the downloaded file.

 Algorithmic Problem Solving — Three
Years On
Roland Backhouse
School of Computer Science and Information Technology
University of Nottingham
Nottingham NG8 1BB,
England
[email protected]

Abstract
”Algorithmic problem solving” introduces problem-solving skills based on the
principles of correct-by-construction algorithm design. Introduced three years ago
as a 1st-year option, the module has overcome initial opposition, and became
compulsory for all 1st-year students of Computer Science and Mathematics and
Computer Science at the University of Nottingham from September, 2006. This paper
gives a short introduction to the goals of the module and how the goals are being
realised.

Keywords: algorithm, problem-solving, program construction

1. INTRODUCTION

The module entitled ”algorithmic problem solving” (APS for short) was first offered as a 1st-year
option in September 2003. In the three years that it has been given, it has steadily grown in
popularity, in 2005-2006 attracting slightly more students than the hitherto most popular option
”Introduction to Artificial Intelligence”. In the current academic year, it became compulsory for all
1st-year students of Computer Science and Mathematics and Computer Science at the University
of Nottingham.

The title of the module is deliberately ambiguous. Parsed as algorithmic-problem solving, it is

about solving problems that involve the construction of an algorithm for their solution. Parsed as
algorithmic problem-solving, it is about problem solving in general, using the principles that have
been learnt in the development of correct-by-construction algorithm-design techniques [11].

This paper gives a brief account of the main elements of the module. Full details can be obtained
by downloading the lecture material from the author’s website (www.cs.nott.ac.uk/~rcb). The
paper concludes with an assessment of the success of the module.

2. GOALS

In order to properly explain the goals of the module, this section introduces the module as it is
introduced to the students in the first lecture — via a problem and its solution1 .

Knockout Tournament A knockout tournament is a series of games. Two players compete in

each game; the loser is “knocked out” (i.e. doesn’t play anymore), the winner carries on. The
winner of the tournament is the player that is left after all other players have been knocked
out. Suppose there are 1234 players in a tournament. How many games are played before the
tournament winner is decided?
1 The problems that are chosen vary from year to year. The problem chosen here is typical of the initial problem presented

to the students, rather than being the initial problem. The discussion is also abbreviated for the purposes of this paper.

Teaching Formal Methods:

Practice and Experience, 15 December 2006
1
 Algorithmic Problem Solving — Three Years On

Solution We are required to determine the number of games that have been played when the
number of players has been reduced to one. Let us introduce two variables g and p, denoting
respectively the number of games that have been played and the number of players.

Initially, g is 0 and p is 1234. Whenever a game is played, g is increased by 1 and p is decreased

by 1. This is expressed in computer-programming terms by the assignment statement

g , p := g+1 , p−1 .

Now, we are required to determine g when p has the value 1. This is done by observing that the
value of g+p is unchanged by the assignment. It is called an invariant of the assignment. Since
g+p is initially 0+1234, it will always be 1234. In particular, when p is 1, g+p will still be 1234 and,
so, g will then be 1233. The total number of games played is thus 1233, i.e. one less than the
number of players. End of Solution

Even though this is a very simple problem, it illustrates well the modus operandi throughout the
module:
• A problem is introduced which the students can readily comprehend in the course of the
lecture itself.
• The problem is used to introduce a programming statement, in this case the assignment
statement.
• Simultaneously with introducing the programming statement, the students are shown how to
reason about the statement, in this case how to determine an invariant of the assignment.
(In fact, the students themselves are invited to suggest a combination of g and p that is
unchanged by the assignment, which they do.)

The module is, first and foremost, problem-oriented. The goal is to teach problem-solving skills
that have become vital to correct-by-construction algorithm design. The problems have been
carefully chosen to introduce these skills in a systematic fashion. It is no accident, for example,
that the notion of an invariant is introduced in the very first example. (Note, however, that the term
“invariant” is applied to an integer value, g+p, rather than to a boolean value, g+p = 1234, in order
to avoid unnecessary complexity.)

The chosen problems are typically challenging but easy to formulate in everyday English. They
are thus deliberately not “mathematical”, but they are used to demonstrate how mathematics (in
Dijkstra’s sense of the art of effective reasoning) is vital to their successful solution.

Programming elements introduced in turn are (multiple) assignments, pre- and postconditions,
sequential decomposition, case analysis and induction. Elements of calculational logic [8, 1] are
introduced early, and used throughout the module. The notation used for program statements is
that of the guarded command language [5], one reason being that nondeterminism is an essential
element of some of the problems.

Because of its introductory nature, the module is not about algorithm development. In particular,
loops in their full generality are not discussed. An important decision made when designing the
module was not to try to push the students too far; if problem solving is to be taught effectively, it
is important that students are given sufficient time to tackle the problems for themselves, and the
syllabus needs to be tailored accordingly.

3. TOPICS

In this section, we give a brief outline of some of the topics discussed in the module, in the order
that they are presented.

Teaching Formal Methods:

Practice and Experience, 15 December 2006
2
 Algorithmic Problem Solving — Three Years On

3.1. Assertions

The use of assertions, in particular pre- and postconditions, is introduced via river-crossing
problems. These problems involve getting a number of people or things across a river under
given constraints. Standard presentations use brute force — a very ineffective problem-solving
technique— , and commit the sin of unnecessary naming (eg. the goat-cabbage-wolf problem in
[10]). Beautiful solutions can be constructed by exploiting the fact that crossing a river is symmetric
about the left and right banks; solutions are found by decomposing the problems into three parts,
the first and last being “mirror images”. An example is the so-called “jealous-couples” problem
(also known as the the “presidents-and-bodyguards” problem).

In the jealous-couples problem, there are three “couples” each consisting of a “husband” and
“wife”. There is one boat, which can take no more than two people at once. It is required to get
everyone across the river under the constraint that a wife cannot be with a husband unless her
own husband is also present.

A first step is to introduce notation. A state is denoted by two sequences separated by bars. An
example is 3H || 3W , which denotes the state in which all three husbands are at the left bank, and
all three wives are at the right bank. A second example of a state is 1C,2H || 2W , which denotes
the state in which one couple and two husbands are at the left bank and two wives are at the right
bank. The starting state is thus 3C || and the required finishing state is || 3C.

An action (or state transition) is when some individuals are being transported across the river. An
example is 3H |2W | 1W ; this denotes the action of transporting two wives across the river, leaving
three husbands at the left bank and one wife at the right bank.

Having introduced notation, the goal, as well as a strategy for its achievement, can be formulated
precisely . The goal is to construct a sequence of actions S0 satisfying

{ 3C || } S0 { || 3C } .

Exploiting the left-right symmetry, one strategy is to decompose S0 into S1 ; S2 ; S3 where the
three components are specified by:

{ 3C || } S1 { 3H || 3W } ,

{ 3H || 3W } S2 { 3W || 3H } ,

{ 3W || 3H } S3 { || 3C } .

The sequence S1 changes the state from the start state to the state where all the wives are at the
right bank and all the husbands are at the left bank. The function of S3 is the mirror image, and S2
provides the link between S1 and S3 .

The remaining details are not relevant here. What is relevant is the problem-oriented way that
sequential decomposition —specified formally in terms of pre- and postconditions— is introduced.
Note particularly that, although the specification of the component actions is completely formal,
a self-explanatory, domain-specific notation is used. Many introductions to “formal methods” view
the goal as teaching some specific specification language, like Z or B or VDM, but this misses
the real point. We should never forget that “formal methods” are only a tool to assist in problem
solving and not an end in themselves.

3.2. Games

Simple impartial, two-person combinatorial games [3] form a significant part of the module. They
fit the bill very well. After all, playing games is all about winning, which means determining an
algorithm (the winning strategy), and the students need no motivation. Games are used in the
module to introduce non-determinism and case analysis, as well as simple complexity issues and

Teaching Formal Methods:

Practice and Experience, 15 December 2006
3
 Algorithmic Problem Solving — Three Years On

the idea of the development of a mathematical theory. The use of invariants —stressed from the
outset of the module— is, of course, crucial.

For the class of games considered in the module, all positions can be categorised as winning
or losing positions. A winning position is one from which there is a move to a losing position,
and a losing position is one from which every move is to a winning position. Determining winning
and losing positions thus affords an interesting exercise in the use of existential and universal
quantification. The determination of a winning strategy is identified with an invariant: a property
of positions such that, from a position that satisfies the property there is a move to a position that
truthifies the property, and from a position that does not satisfy the property, every move is to one
that falsifies the property.

For example, take a simple matchstick game. There is one pile of matches, and the two players
take it in turns to remove some number m of matches, where m is at least 1 and at most N . The
player who cannot move is the loser. The “invariant” is the property k mod (N +1) = 0, where k
is the number of matches remaining. From a position satisfying this property every move falsifies
the property, and from a position that does not satisfy the property, the removal of k mod (N +1)
matches truthifies the property (and is legal). The winning strategy is thus to truthify the property,
if possible.

A highlight of the study of impartial games is the analysis of “sum” games. A “sum” game is a
composite of two games. A position in the “sum” game is a pair of positions, one in each of the
component games. A move in the “sum” game is determined by choosing one of the component
games and moving in that game. (So, only one of the component positions is changed by a move.)
Play is lost when it is not possible to move in either of the component games.

It is possible to form quite “difficult” games (in terms of the ease of identification of a winning
strategy) by combining two very “simple” games. For example, the well-known game of Nim [4]
is the “sum” of three copies of a trivial matchstick game (the game with one pile of matches
from which any positive number of matches can be removed). More entertaining examples are
constructed by “summing” two quite different, but nevertheless trivial, games. (The possibilities
are endless, which is very useful for setting coursework and/or examination questions.)

A winning strategy for “sum” games is to maintain “symmetry” between the component games.
Calling the component games the left and right games, two functions, L and R say, are defined on
left and right positions, respectively, in such a way that a position (l,r) is a losing position exactly
when L.l = R.r. The question is: what properties should these functions satisfy? In other words,
how do we specify the functions L and R?

The analysis given earlier of a winning strategy allows one to distill the specification. First, since
(l,r) is an end position2 of the sum game exactly when l is an end position of the left game and r
is an end position of the right game, it must be the case that L and R have equal values on end
positions.

Second, every allowed move from a losing position —a position (l,r) satisfying L.l = R.r— , that
is not an end position, should result in a winning position —a position (l,r) satisfying L.l = R.r— .
That is,

{ L.l = R.r ∧ (l is not an end position ∨ r is not an end position) }

if l is not an end position → change l
2 r is not an end position → change r
fi
{ L.l = R.r } .
2 End positions are positions from which no move is possible; these are, by definition, losing positions.

Teaching Formal Methods:

Practice and Experience, 15 December 2006
4
 Algorithmic Problem Solving — Three Years On

Third, applying the winning strategy, from a winning position —a position (l,r) satisfying
L.l = R.r— should result in a losing position —a position (l,r) satisfying L.l = R.r—. That is,

{ L.l = R.r }
apply winning strategy
{ L.l = R.r } .

This analysis of the requirements on L and R leads to the well-known “mex” (also called Sprague-
Grundy [9]) numbering of positions.

In the module, the above theory is used to develop the students’ understanding of program
specifications, and is reinforced by coursework. (The pace at which it is presented is, however,
much, much slower!) Undoubtedly, they find it challenging but evidence provided by coursework
and examination questions suggests that they find it rewarding.

3.3. Induction

As mentioned earlier, the module is not about the design of algorithms. It is very important that
the students are allowed to develop confidence in their own problem-solving ability, and space
must be allowed in the syllabus for that purpose. An unfortunate consequence is the omission of
the design of loops in their full generality (maintaining an invariant whilst making progress towards
the required postcondition). However, induction does form an important element of the module.

A major difference with standard accounts of induction is the stress on inductive construction
rather than verification. This is an important point. Although I am myself an author of a book
with “verification” in the title, I believe that the overwhelming emphasis on program “verification”
in the formal-methods community is having a major detrimental effect on the adoption of formal
methods.

There is an abundance of constructions that can be used to introduce the idea of induction
in a much more convincing way than standard mathematical verifications (for example, of the
formula for the sum of the first n natural numbers). An inductive construction solves a problem by
identifying the “size” of instances of the problem; it is then shown how to solve problems of size 0
—the base case— and how to solve problems of size n+1 assuming that problems of size at most
n can be solved. The problems I use in the module include the fake-coin problem [6, 7], the Towers
of Hanoi problem, and the Knight’s-circuit problem. (The Towers of Hanoi problem illustrates
how much our problem-solving ability has improved. Standard presentations of its solution are
unnecessarily complex. The solution presented in APS, based on [2], exploits rotational symmetry
of the poles and shows how invariant properties enable an iterative solution to be derived from
the inductive solution.)

4. CONCLUSIONS

Although the problems presented in the Algorithmic Problem Solving (APS) course covered in
this paper are mostly well-known (one might even say old-hat!) the “algorithmic” approach to their
solution is very novel, indeed quite revolutionary. The success of the module is demonstrated by
its increased popularity among students, and the fact that it has overcome initial opposition by
academic staff. (It has become a compulsory module, albeit not for all the undergraduate degrees
offered by the School, in spite of vigorous opposition to its introduction as an optional module
three years ago.)

The most important factors contributing to its success are, I believe:

• Avoidance of demotivation.
There is often much discussion about how to “motivate” students. But this is the wrong
question. My assumption is that students are motivated, but may lack self-confidence. They
appreciate and are ready for the challenges of a university education, but may be unsure of

Teaching Formal Methods:

Practice and Experience, 15 December 2006
5
 Algorithmic Problem Solving — Three Years On

how they will cope in a new environment. The biggest mistake we can make is to demotivate
the students by not challenging them sufficiently, or by undermining their self-confidence by
setting challenges that are unclear or beyond their grasp. The problems in APS are carefully
chosen to achieve the right balance. They are challenging but doable. Most importantly, the
students are able to appreciate how the methods taught in the module can improve their
problem-solving skills.
• Practical relevance.
Problem-solving skills are generally acknowledged to be a vital element of undergraduate
education. Algorithmic problem solving is a particularly important skill, since the formulation
of algorithms is relevant to all manner of tasks, and not just to computer programming. The
combination of concision and precision, the sine qua non of software design, makes APS
stand out from other accounts of problem solving.
• Focus on method.
The problem-oriented nature of the module means that its focus is truly on method rather
than knowledge. For example, it would be stupid to suppose that being able to memorise a
knight’s circuit of a chessboard will ever be a useful skill! But a study of how the problem
is analysed and broken down into simpler problems, and how these simpler problems are
solved is very frutiful because the same skills can be applied elsewhere (are “transferrable”
in current jargon). Unfortunately, algorithm design is often presented in a knowledge-based
fashion, reducing it to a specialist skill. It is much harder to instil good method, but much
more worthwhile. APS tries to articulate sound problem-solving skills, even though these
may be informal and imprecise.

Because of time limitations, the module does not go as far as I would like to take it. This year, for
the first time, I have been given the opportunity to integrate the problem-oriented approach of APS
with an introduction to calculational mathematics. I hope to be able to report on this endeavour in
the near future.

On a longer timescale, I believe that there is a real scope for a revolution in the way that
mathematics —the art of effective reasoning— is taught and practised, both at school and
university, a revolution driven by the lessons learnt from correct-by-construction programming
techniques. This is my “grand challenge” for research and education in formal methods and the
science of computing.

REFERENCES

[1] Roland Backhouse. Program Construction. Calculating Implementations From Specifica-

tions. John Wiley & Sons, 2003.
[2] Roland Backhouse and Maarten Fokkinga. The associativity of equivalence and the Towers
of Hanoi Problem. Information Processing Letters, 77:71–76, 2001.
[3] Elwyn R. Berlekamp, John H. Conway, and Richard K. Guy. Winning Ways, volume I and II.
Academic Press, 1982.
[4] Charles L. Bouton. Nim, a game with a complete mathematical theory. Ann. of Math.,
Princeton, 3(2):35–39, 1901-02.
[5] Edsger W. Dijkstra. Guarded commands, nondeterminacy and formal derivation of
programs. Communications of the ACM, 18:453–457, 1975.
[6] Edsger W. Dijkstra. EWD1083: The balance and the coins.
http://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1083.PDF, September 1990.
[7] Edsger W. Dijkstra. EWD1260: The marked coins and the scale.
http://www.cs.utexas.edu/users/EWD/ewd12xx/EWD1260.PDF, March 1997.
[8] David Gries and Fred B. Schneider. A Logical Approach to Discrete Math. Springer-Verlag,
1993.
[9] P.M. Grundy and C.A.B. Smith. Disjunctive games with the last player losing. Proc.
Cambridge Philos. Soc., 52:527–533, 1956.
[10] Ian Stewart. The Magical Maze. Weidenfield and Nicolson, London, 1997.
[11] A.J.M. van Gasteren. On the Shape of Mathematical Arguments. Number 445 in LNCS.
Springer-Verlag, 1990.

Teaching Formal Methods:

Practice and Experience, 15 December 2006
6

View publication stats