Reviewed Papers

Application of Computer Science Ideas to the

Presentation of Mathematical Theorems and Proofs
Orit Hazzan
Department of Education in Technology and Science
Technion Israel Institute of Technology
1 Haifa, 32000 Israel
<oritha@techunix.technion.ac.il>

It is reasonable to hope that the relationship between

computation and mathematical logic will be as fruitful in
the next century as that between analysis and physics in
the last. The development of this relationship demands a
concern for both applications and for mathematical
elegance.
(Dijkstra, 1986, p. 52.)
Abstract
Based on the analogy between mathematical proofs and computer programs this paper illustrates how it is possible to
apply methodologies from computer science, used in the development and presentation of computer programs, for the
presentation of mathematical theorems and proofs. The following three methodologies are discussed: stepwise
refinement, abstraction, and program verification.

Introduction
The community of computer science has developed several
methods for improving the development and presentation
of computer programs. As it turns out, this practice of
presentation is not a tradition in the mathematics
community. The style by which mathematical ideas are
presented is usually formal and thrifty. For example,
proofs are usually presented in a perfect manner, in full
detail. Thus, it is not always clear to the reader what the
structure of a proof is and what the role of each of the
details appearing in it is. Of course, there are many cases
in which instructors do improve the traditional method of
presenting mathematics. However, these are individual
attempts and do not represent the official mathematical
culture.
Needless to say that the mathematicians
themselves are aware of the disadvantages in presenting
mathematical ideas in this way (Steenrod, 1973; Halmos,
1973). However, at the same time, the number of papers
which deal with methods for improving the presentation of
mathematical ideas, is relatively small.
Many discussions focus on connections between
mathematics and computer science in general, as well as on
analogies between mathematical proofs and computer
programs in particular (Dijkastra, 1972, 1986; Knuth, 1974;
De Millo, Lipton and Perlis, 1979; Martin-Lof, 1985;
Hoare, 1986; Gray, 1991; Wells, 1995). Based on the
analogy between computer programs and mathematical

inroads The SIGCSE Bulletin

proofs this paper illustrates how it is possible to apply

methodologies from computer science used in the
development and presentation of computer programs, for
the presentation of mathematical theorems and proofs. The
working assumption is that in the same way that these
methodologies may improve the presentation of computer
programs, they may also illustrate the structure and
development of mathematical ideas.
Thus, these
methodologies may help improve communication between
the person presenting the mathematical material and the
person learning it.
Sections 1-3 deal with stepwise refinement,
abstraction, and proving correctness of computer programs,
respectively. An additional computer science methodology
that may be used in the presentation of mathematical proofs
is structured programming (Cf. Leron, 1983, 1985).
1. Stepwise Refinement
Stepwise refinement is one of the main tools aiding
programmers in the process of computer programs
development. By using stepwise refinement, a computer
program is built in stages, through a series of steps, each
step refining the preceding one. The on-going addition
of details results in a more compound and specified
computer program than the one we start with.
The implementation of successive refinement in
mathematics is illustrated by the proof of Eulers theorem

38

Volume 35, Number 2, 2003 June

Reviewed Papers
that prevent one from moving ahead. But, conceiving a
development task as a process which is based on
improvements and refinements of the product we are
developing, puts a different light on situations in which
problems arise.

about polyhedra as it is presented in Lakatos (1976).

Eulers Theorem states that for all regular polyhedron VE+F=2, where V is the number of vertices, E is the number
of edges, and F is the number of faces of the polyhedron.
The discussion in Lakatoss book takes place in an
imaginary classroom between a teacher and his students.
At the beginning, Eulers Theorem is introduced as a
conjecture and the teacher presents a proof for the theorem.
After the proof is presented, the students raised a number of
questions about the validity of the proof, such as: Are all
the steps of the proof correct for all polyhedra? Are there
polyhedra for which the conjecture is correct, but for which
the proof does not work? During the discussion, the proof
is refined and its accuracy is tested a number of times.
Such a discussion reflects the similarity between the
development of a computer program by means of the
stepwise refinement process and the development of a
mathematical proof through this process. Specifically, in
the presentation of the proof of Eulers Theorem, a number
of details are added only after it becomes clear why it is
necessary to add them and what their role in the proof is.

2. Abstraction
Abstraction is applied in mathematics and in computer
science similarly in at least two ways. First, in both fields
abstraction is expressed through a description of objects by
their characteristics rather than by the way they are
constructed or how they work. Second, abstraction is
applied in the two fields by retaining what objects in a
given set have in common while ignoring their differences
as much as possible.
The continuation of this section illustrates the
application of an additional computer science interpretation
of abstraction to the presentation of mathematical
theorems. Specifically, it is examined how computer
science may contribute to mathematical presentations by
setting up abstraction barriers. Abelson & Sussman (1986)
use the metaphor of abstraction barriers to present one of
the methods aiding in the development of computer
programs (p. 73). Abstraction barriers separate between
the assignment of meaningful names to instructions used in
a computer program, and the definition of these instructions
in the programming language. When we develop a
computer program, we choose a language that describes the
solution to the problem in a human language. In this
process, we set up a barrier that prevents us from going into
technical details arising from the use of a programming
language. In other words, above the abstraction barrier, we
describe a solution to a problem by a collection of words
that are meaningful for us. Below the abstraction barrier,
we define these words by means provided for us through
the programming language. In practice, several abstraction
barriers are set up in the development of complex computer
programs. That is, the same idea is applied in the process
of defining each of the words that describe the solution in
earlier stages.
The application of abstraction by setting up abstraction
barriers is expressed in the mathematical context for
presenting the following theorem about real and rational
numbers.
For every irrational number and for all real number
> 0, there are two rational numbers r1, r2 which satisfy
r1 < < r2 and r2-r1 < . (Mizler, 1968).
In what follows, the theorem is introduced by a sequence of
descriptions.

Pedagogical implications of stepwise refinement

The presentation of the development of computer programs
and of mathematical proofs through the process of stepwise
refinement demonstrates how complex problems are
solved. Thus, it may be an efficient teaching tool. As
already stated with respect to mathematical proofs,
computer programs are sometimes also presented as
finished products. Their aims and syntactic details are
explained but the process in which they were developed is
not discussed (Wirth, 1971). As a result, of this teaching
method, students may get an incorrect impression that
programming is based on syntactic skills only, and that
writing a computer program is a simple process based on
the translation of the programmers intuition directly into
the programming language.
This is also correct, of course, with respect to
mathematical proofs. Complex mathematics proofs are not
usually made up over night. Often, a mathematical proof
is developed in a process that may take years. In spite of
this fact, in mathematics literature, as well as in university
lecture halls, proofs are usually presented in their entirety,
in full detail, without hinting at the gradual process of their
development. Indeed, Lakatos relates to a mathematical
proof as if it is a thought-experiment, in which it is
analyzed, and while refining it, one moves on from the
initial formulation to a more exact formulation.
If our aim is to have our students develop skills for
developing computer programs and mathematical proofs,
the full picture should be presented to them. The idea is to
get students to understand that developing complex objects
such as computer programs or mathematical proofs, is not
the simple, instant process it is often presented to be. In
reality, developing complex objects is sometimes a longterm process, accompanied by difficulties and problems

inroads The SIGCSE Bulletin

First formulation
There is an irrational number between every two different
rational numbers. This fact is intuitive and leads us to the
next stage, which uses the term rational segment a
section on the real axis whose edges are rational numbers.
This is an example of choosing an appropriate terminology

39

Volume 35, Number 2, 2003 June

Reviewed Papers
Two proofs for this theorem are presented. The first one is
presented in the traditional way of presenting mathematical
proofs; in the second proof, the theorem is reformulated as
a programming problem whose solution is based on
constructing an algorithm that consists of a While Loop.

for describing a certain situation. It also uses the intuitive

expression as small as we want.
Second formulation
For every irrational number, there is a rational segment,
as small as we want, which contains that number.
After an intuitive background has been prepared, in the
next stage the original formulation of the theorem may
appear.

Proof A (Honsberger, 1985)

Out of all the possible pairings, we choose one in which the
sum of the lengths of the pairing segments is minimal (such
a one exists since the number of pairing possibilities is
final). It is sufficient to prove that in this pairing there is
no possibility for two pairing segments to intersect. Let us
assume that in this pairing two intersecting segments do
exist (Figure 1):

Pedagogical implications of abstraction

In our discussion of abstraction, three ways in which
abstraction is expressed were presented. If these three
ways are to be examined through the lens of abstraction
(that is to say, we carry out a meta-abstraction and examine
the ways by which abstraction is expressed), we are then
able to see that the three methods have a common
characteristic. This characteristic is the guideline which
tells us to avoid going into unnecessary detail in certain
stages of problem solving.
It is easy to see that education towards description of
ideas (mathematics and others) at an appropriate
abstraction level has a number of advantages. First,
students are guided to concentrate on the essence of an idea
they describe; second, students should consider the
understanding of a listener or a reader of the message
presented by them; and, finally, this kind of education
equips students with an additional heuristic tool for
problem solving.
Deliberating over a solution to a problem and
presenting the solution at an appropriate abstraction level,
are not trivial tasks. However, students may get the wrong
impression that in giving up on formal and precise
language at certain stages of solving a problem, it is
legitimate to express ideas carelessly. Therefore, one must
draw students attention to the fact that abstraction is there
to help us in solving problems at certain stages and its role
is to guide us in the process of finding a solution. In the
end, the solution must be presented in an explicit manner,
perfect in every detail.

A1

A2

B2

B1

Figure 1: Bijective correspondence with intersecting

segments
In such a case, we substitute the sub-pairing (A1,B1) and
(A2,B2) with the sub-pairing (A1,B2) and (A2,B1) and we get
a pair of pairing segments which do not intersect (Figure
2).

A1

B2

A2

B1

Figure 2: Omitting the intersecting segments

3. Program Correctness
This section presents the application of a method, which
was originally developed to prove the correctness of
computer programs, in proving mathematics theorems. The
idea is to reformulate a mathematical theorem as a
programming problem, whose solution requires a
construction of an algorithm. The proof of the theorem
stems from the correctness of the algorithm.
The discussion focuses on the following theorem:
Consider two finite, equinumerous sets of points in the
plane. Assume there are no colinear triples. Show that
there exists a pairing (bijective correspondence) between
the two sets so that no two line segments connecting
corresponding points intersect.

inroads The SIGCSE Bulletin

From the triangle inequality, it follows that the total

length of the pairing segments in the new pairing is smaller
than that of the original one. This is contradictory to our
assumption that the original pairing was considered to be
the minimum in the total sum of the segment length.
Therefore, no two pairing intersecting segments exist in the
pairing that was originally chosen.
The following proof is based on constructing an
algorithm. When the algorithm stops, an object fulfilling
the conditions of the theorem is attained, and thus the
theorem is proved. This approach makes it possible to
develop the proof in the same way as a computer program
is developed.

40

Volume 35, Number 2, 2003 June

Reviewed Papers
Pedagogical implications of program correctness
As can be observed, both proofs are based on the same
object (that is, the sum of the segment lengths).
However, while in the second proof, in which the algorithm
is constructed, the variant function on the set of situations
the sum of the segment lengths is built as an integral
part of the proof, in the first proof the object on which the
proof leans the pairing with the minimum sum of the
segment lengths is pulled out of the hat at the beginning
of the proof. This is what Avital (1973) describes as the
Let us define a function Syndrome. This syndrome
refers to the phenomenon that sophisticated objects are
introduced in a certain stage of proving a theorem without
any preparation. For a mature mathematician it is obvious
that this object emerged from some examination; for
novices, it may be seen as a magic that not everyone is
capable of carrying out. As has been mentioned before,
showing students the true process by which a task is solved,
is an important part of problem-solving education.

Proof B Proof which builds an algorithm

(based on Dijkstra, 1989)
The theorem is rephrased as a programming problem
design an algorithm that constructs a pairing between two
groups having the same number of points without
intersecting segments- and then solve it by standard
programming methodology.
The correctness of the
algorithm is based on the properties of a While loop.
Formal details about While loops can be found in Gries
(1981).
Let us look at the set of situations the set of all
possible pairing between the two groups of points, and at
the variable X which its value equals to one of the
situations in that set of situations. We define an invariant
H: The value of X is a pairing. The algorithm changes the
value of X as long as its value is an intersecting pairing.
The algorithm stops when the value of X is a nonintersecting pairing.
Dijkstra (1989) presents the proofs in stages,
explaining each of its steps. For reasons of space
limitation, intermediate formulations are skipped. The final
algorithm is:
Initiate X with some pairing. While the value of the
variable X is an intersecting pairing, substitute it with a
pairing created by carrying out a FLIP. (1)
To ensure the termination of the algorithm, we look for
a variant function defined on the set of situations whose
value decreases by carrying out a Flip. After several
examinations and heuristic considerations, it turns out that
the appropriate variant function is the sum of the lengths of
the segments. As the triangle inequality guarantees that the
sum of the lengths of the segments in Figure 2 is smaller
than the sum of the lengths of the segments in Figure 1, the
sum of the lengths of the segments decreases by a Flip.
Therefore, the sum of the lengths of the segments of the
pairing is a variant function on the set of situations which
decreases by a Flip. Since the number of pairing is final,
the finality of the algorithm is ensured.

4. Epilogue
This paper focuses on the following three methodologies of
computer science stepwise refinement, abstraction and
program verification.
It illustrates how these
methodologies may be helpful in the presentation of
mathematical theorems and proofs. What is argued is that
in the same way that these methodologies help improving
the presentation of computer programs, they may improve
the presentation of mathematical ideas.
Structured
programming is an additional computer science
methodology that may be used in the presentation of
mathematical proofs (Cf. Leron, 1983, 1985).
Acknowledgement
I would like express my gratitude to Uri Leron and to Rina
Zazkis for their useful and thoughtful remarks on an earlier
draft of this paper.

References
[1] Abelson, H. and Sussman, G. J. (1986). Structure and Interpretation of Computer Programs, MIT Press and McGraw-Hill.
[2] Avital, S. M. (1973). The Let us define a function syndrome. International Journal of Mathematics Education in Science and
Technology 4, pp. 143-147.
[3] De Millo, R. A., Lipton, R. J. and Perlis, A. J. (1979). Social processes and proofs of theorems and programs. Communications of the
ACM 22(5), pp. 271-280.
[4] Dijkstra, E. W. (1972). Notes on structured programming. In Dahl, O. J., Hoare, C. A. R. and Dijkstra, E. W. (eds.). Structured
Programming, Academic Press, New-York.
[5] Dijkstra, E.W. (1986). On a cultural gap. The Mathematical Intelligencer 8(1), pp. 48-52.
[6] Dijkstra, E.W. (1989). A somewhat open letter to Uri Leron EWD1049. Unpublished personal correspondence.
[7] Gray, R. (1991). Computer Programs and Mathematical Proofs. The Mathematical Intelligencer 13(4), pp. 45-48.
[8] Gries, D. (1981). The Science of Programming, Springer-Verlag, New-York, Inc.
[9] Halmos, P. R. (1973). How to write mathematics. In Steenrod, N. E., Halmos, P. R., Schiffer, M. M. and Dieudonne, J. A. How to
Write Mathematics?, American Mathematical Society.
[10] Hoare, C. A. R. (1986). Mathematics of programming. Byte, August , pp. 115-124, 148-150.
[11] Honsberger, R. (1985). Mathematical Games III. The Mathematical Association of America.
[12] Knuth, D. E. (1974). Computer science and its relation to mathematics. The American Mathematical Monthly, 81 (April), pp. 323-343.
[13] Lakatos, I. (1976). Proofs and Refutations. Cambridge: Cambridge University Press.
[14] Leron, U. (1983). Structuring mathematical proofs. American Mathematical Monthly, 90(3), pp. 174-185.

inroads The SIGCSE Bulletin

41

Volume 35, Number 2, 2003 June

Reviewed Papers
[15] Leron, U. (1985). Heuristic presentations: The role of structuring. For the Learning of Mathematics 5(3), pp. 7-13.
[16] Martin-Lof, P. (1985). Constructive mathematics and computer programming. In Hoare, C. A. R. and Shepherdson (eds.).
Mathematical Logic and Programming Languages, Prentice-Hall International.
[17] Mizler, D. (1968). Calculus, Haomanim Press, Jerusalem. (Hebrew).
[18] Steenrod, N. E. (1973). How to write mathematics. In Steenrod, N. E., Halmos, P. R., Schiffer, M. M. and Dieudonne, J. A. How to
Write Mathematics?, American Mathematical Society.
[19] Wells, C. (1995). Communicating mathematics: Useful ideas from computer science. The American Mathematical Monthly 102(5),
pp. 397-408.
[20] Wirth, N. (1971). Program development by stepwise refinement. Communications of the ACM 14(4), pp. 221-227.

Endnote
(1) A flip is a change that is made by moving from Figure 1 to Figure 2 which deletes an intersection in a pairing.

CITIDEL
Computing and Information Technology
Interactive Digital Educational Library

Goes Live!! Check it out!!

<www.citidel.org>

inroads The SIGCSE Bulletin

42

Volume 35, Number 2, 2003 June