The original version of this problem concerns manuscripts and proofreaders, instead of source code and programmers. It was posed and solved by George Polya and published in 1976 on The American Mathematical Monthly under the name of Probabilities in Proofreading. Because the problem is interesting and Polya’s solution is short and elegant, I have decided to record and share it. Also, since code sharing and reading is a frequent activity in the software development world, estimating the desired value can be helpful for some readers of this blog.

Estimating the number of unnoticed errors

Let E be the number of all errors, noticed and unnoticed, in the source code. Our goal is to estimate the value of E-(A+B-C). Let p be the probability that friend notices any given error and q the analogous probability for friend . The expected number of errors that may be detected by is and by is . Assuming that these probabilities are independent, the expected number of errors that may be mutually detected by both friends is .

Because we are interested in an estimate, we can safely assume that the expected numbers are approximately equal to the number of errors detected, that is, , , and . (We use the notation to denote that two numbers are approximately equal.)

We now have all the ingredients to conclude the solution. Recall that our goal is to estimate the value of E-(A+B-C). We calculate:

This is the desired estimate!

Related Articles:

• Multiples in the Fibonacci series
• Calculational proofs are usually direct

Graph 0: Example of an undirected graph with five nodes

A well-known property is that every undirected graph contains an even number of vertices with odd degree. The result first appeared in Euler’s 1736 paper on the Seven Bridges of Königsberg and is also known as the handshaking lemma (that’s because another way of formulating the property is that the number of people that have shaken hands an odd number of times is even).

As we can easily verify, graph 0 satisfies this property. There are four vertices with odd degree (A,B,C, and D), and 4, of course, is an even number.

Although the proof of this property is simple, I have never seen it proved in a calculational and goal-oriented way. My aim with this post is to show you a development of a goal-oriented proof.

Before we start, let me explain the notations that I use. I assume the existence of two predicates, even and odd, that test the parity of numbers. For example, even.8 and odd.3 are both true, and even.5 and odd.6 are both false. Also, I use the so-called Eindhoven notation for quantifiers; for example, to express the sum of all natural even numbers less than 50 I write , and instead of writing , I write .

Now, the first step in any goal-oriented solution is to express the goal. In other words, what do we want to prove or calculate? Using the notation just described and assuming that V is the set of all vertices, our goal is to determine the value of the following expression:

Note that we are adding 1 (counting) for each node a in V with an odd degree. We then apply the predicate even to the result. If the result is true, there is an even number of vertices with odd degree; otherwise, there is an odd number. Our goal is thus to determine its value. (We know that it must evaluate to false, because the property is well-known. However, in general, when doing mathematics, we don’t know what is the final value; that is why goal-oriented and calculational proofs are important.)

We know that the predicate even distributes over addition, so we calculate:

This calculation shows that the parity of the number of vertices with odd degree is the same as the parity of the sum of all the degrees. But because each edge has two ends, the sum of all the degrees is simply twice the total number of edges. We thus have:

And so we can conclude that every undirected graph contains an even number of vertices with odd degree.

What is wrong with conventional solutions?

Conventional solutions for this problem are usually very similar to the following one, taken from the book “Ingenuity in Mathematics” (p. 8), by Ross Honsberger:

The proof in general is simple. We denote by T the total of all the local degrees:

(1) T = d(A) + d(B) + d(C) + … + d(K) .

In evaluating T we count the number of edges running into A, the number into B, etc., and add. Because each edge has two ends, T is simply twice the number of edges; hence T is even.

Now the values d(P) on the right-hand side of (1) which are even add up to a sub-total which is also even. The remaining values d(P) each of which is odd, must also add up to an even sub-total (since T is even). This shows that there is an even number of odd d(P)’s (it takes an even number of odd numbers to give an even sum). Thus there must be an even number of vertices with odd local degree.

There is nothing seriously wrong with this solution. It clearly shows why the property holds. However, it is, in my view, oriented to verification: it starts by introducing the total sum of all the local degrees, observing that its value is even; then it analyses that sum to conclude the property. My question is: how can we teach students to come with the total sum of all the local degrees? In general, how can we teach students to come with seemingly unrelated concepts that will be crucial in the development of their arguments? I don’t think we can.

On the other hand, if we look at the goal-oriented proof, we see that the goal is simple to express. Furthermore, with some training, most students would write it correctly and would be able to calculate that the parity of the number of vertices with odd degree is the same as the parity of the sum of all the degrees. And then (and only then) the introduction of the total sum of all the degrees would make sense. In a way, goal-oriented calculations are like that famous masked magician that reveals magic’s biggest secrets, for they reveal how the rabbit got into the hat.

So why study computer science? The job prospects at the end are usually pretty good – because, if nothing else, you can become a pretty good software developer fairly quickly – but they are unknown. My argument is that the study of computer science is enough of an incentive enough to make it worthwhile.

Related Articles:

• The programmers of tomorrow

“It is our view that Computer Science (CS) education is neglecting basic skills, in particular in the areas of programming and formal methods. We consider that the general adoption of Java as a first programming language is in part responsible for this decline. We examine briefly the set of programming skills that should be part of every software professional’s repertoire.”

The comment about Java’s adoption annoyed some Java aficionados, but in a recent interview, Robert Dewar adds that the problem goes far beyond the choice of Java as the first programming language. The real problem is that CS programs are being dumbed down, so that they become more accessible and popular. In result, they “are not rigorous enough and don’t promote in-depth thinking and problem solving”.

“A lot of it is, ‘Let’s make this all more fun.’ You know, ‘Math is not fun, let’s reduce math requirements. Algorithms are not fun, let’s get rid of them. Ewww – graphic libraries, they’re fun. Let’s have people mess with libraries. And [forget] all this business about ‘command line’ – we’ll have people use nice visual interfaces where they can point and click and do fancy graphic stuff and have fun.”

Although the paper is concerned with the American reality, I believe we have the same problem in Europe — at least, and as far as I know, in the UK and in Portugal. However, in my opinion, the problem starts before university. The maths’s programs in secondary schools are also being simplified (or dumbed down, if you prefer) and many important concepts, like logic and proofs, are being ignored.

In result, first-year students usually have a poor background on maths and problem solving. In fact, most of them have never seen a proof and don’t even understand the importance of mathematical reasoning. With poor reasoning abilities, they become intellectually less curious, accepting things as they are presented, and they have tremendous difficulties creating new algorithms, or convincing someone that their own algorithms are correct.

Moreover, once they are in the university, one of two things happens:

1. they are not taught explicitly how to solve problems or how to derive algorithms from their formal specifications (this is the most common case);
2. or they are taught the above skills but their poor background doesn’t allow them to fully appreciate these subjects.

What can be done?

Dewar and Schonberg suggest some skills to be taught:

“Students need to be exposed to the tools to construct large-scale reliable programs, as we discussed at the start of this article. Topics of relevance are studying formal specification methods and formal proof methodologies, as well as gaining an understanding of how high-reliability code is certified in the real world. When you step into a plane, you are putting your life in the hands of software which had better be totally reliable. As a computer scientist, you should have some knowledge of how this level of reliability is achieved. In this day and age, the fear of terrorist cyber attacks have given a new urgency to the building of software that is not only bug free, but is also immune from malicious attack. Such high-security software relies even more extensively on formal methodologies, and our students need to be prepared for this new world.”

I agree with every word in this paragraph! We really need professionals capable of creating certified software that works under all circumstances.

Joel Spolsky’s proposal

Joel Spolky’s wrote an interesting post where he suggests the following:

“I think the solution would be to create a programming-intensive BFA in Software Development–a Julliard for programmers. Such a program would consist of a practical studio requirement developing significant works of software on teams with very experienced teachers, with a sprinkling of liberal arts classes for balance. It would be a huge magnet to the talented high school kids who love programming, but can’t get excited about proving theorums.”

Obviously, this is a much more pragmatic and “hackish” approach than what Dewar and Schonberg suggest. He also writes:

“When I said BFA, Bachelor of Fine Arts, I meant it: software development is an art, and the existing Computer Science education, where you’re expected to learn a few things about NP completeness and Quicksort is singularly inadequate to training students how to develop software.”

I think I understand what Joel means when he writes that programming is an art. However, I prefer to call it a science. You see, art is subjective: it exists in your mind. We can both look to the same photograph or painting, and express different interpretations. A program, however, can’t be seen subjectively. Given a program, we have to be able to say objectively if it is correct (according to some specification) or if it is efficient. It is not a matter of aesthetic principles.

Other Comments

The author of Ekinoderm caught my attention when he wrote the following:

“When I got my B.S. (in 2003), I can remember students in my classes constantly grousing about how topics like Scheme or Finite State Automata were “useless” and we should spend our time doing “useful” things like learning how to use VB to make a database app or something. Or, God forbid, writing web apps in PHP.”

Interestingly, I had a very similar experience during my university degree. Many students in my classes didn’t like functional programming nor formal methods, because, according to them, these skills were useless to get a job; and they also didn’t like to encode the usual algorithms for trees or graphs in C, because their favourite language (usually Java or VB) already had libraries with the algorithms implemented.

On the contrary, I was interested in functional programming and formal methods. And I think I have benefited quite a lot from studying them. I also learned a lot implementing data structures and algorithms in C. Even so, and after several programming projects at the university, and a job programming Python for a company that offered Plone services, I didn’t feel ready for delivering certified programs (with proofs of correctness included). That was basically the reason why I have embarked in a PhD: I felt the need of programming by construction.

Final Notes

In 1975, Edsger Dijkstra wrote a famous note named “How do we tell truths that might hurt?“, where he enumerated some of the unpleasant truths about Computer Science. In the first paragraph, he basically explains why exposing truths (just like Dewar and Schonberg did) gives rise to so much discussion and discordance:

“Sometimes we discover unpleasant truths. Whenever we do so, we are in difficulties: suppressing them is scientifically dishonest, so we must tell them, but telling them, however, will fire back on us. If the truths are sufficiently impalatable, our audience is psychically incapable of accepting them and we will be written off as totally unrealistic, hopelessly idealistic, dangerously revolutionary, foolishly gullible or what have you. (Besides that, telling such truths is a sure way of making oneself unpopular in many circles, and, as such, it is an act that, in general, is not without personal risks. Vide Galileo Galilei…..)”

What is really amazing is that, 33 years later, some of the most unpleasant truths he enumerated are still true:

• Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.
• The easiest machine applications are the technical/scientific computations.
• The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities.
• The problems of business administration in general and data base management in particular are much too difficult for people that think in IBMerese, compounded with sloppy English.
• About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead.
• Besides a mathematical inclination, an exceptionally good mastery of one’s native tongue is the most vital asset of a competent programmer.
• Simplicity is prerequisite for reliability.
• By claiming that they can contribute to software engineering, the soft scientists make themselves even more ridiculous. (Not less dangerous, alas!) In spite of its name, software engineering requires (cruelly) hard science for its support.

To conclude the post, allow me to add one to the list:

As long as programming is considered a soft science and the formal derivation of algorithms is neglected, there will always be people enumerating unpleasant truths about Computer Science.

Related Articles:

• On Programming and Mathematical Methodology -- Part II
• On Programming and Mathematical Methodology

Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.

It was Edsger W. Dijkstra, the famous computer scientist, who wrote these words in his note named “How do we tell truths that might hurt?“. I am sure that many people didn’t like to read them, and didn’t understand what he meant.

Although it is not my intention to discuss his words, I want to present a simple example that demonstrates how mathematics can be used to program better and to make you more confident about your own programs.

This post includes a fair amount of mathematical definitions and concepts, but they should not be difficult to understand. After the mathematical discussion, I present an example using the Perl programming language (it also applies to languages like C or Java).

The Problem

The problem I am going to deal with, involves the ceiling and floor functions. If you don’t remember, the floor of a real number is (usually) written as and it is defined as the greatest integer that is at most . Similarly, the ceiling of a real number is written as and it is defined as the smallest integer that is at least .

The goal is to implement the ceiling function supposing that our programming language only provides the floor function to round numbers. Formally, given a real , we want to calculate an expression such that:

The ceiling and floor functions

As I said before, the floor of a real number is the greatest integer that is at most . Formally, we capture this notion in the following definition:

For all real , is an integer such that, for all integers ,

This very compact and elegant definition allows us to derive some properties very quickly. If, for instance, we instantiate to be , we get:

Since the left side of the equivalence is true, the right side is also true. We thus have our first property:

Please note that since is an integer by definition, we can only replace it by integer values. That is why we can replace it by , which is an integer, but we can’t instantiate it to be because is a real number. However, we can replace by , since all integers are also reals. Replacing by , we get:

which simplifies to

Now, instantianting to in (0), we can also conclude that

Finally, from (1) and (2), we conclude that

We already knew this property: the floor of an integer number is .

We can do a very similar analysis for the ceiling function. We’ve seen that the ceiling of a real is the smallest integer that is at least . So, formally, we have:

For all real , is an integer such that, for all integers ,

Note that we can apply the contrapositive rule (that’s when we negate both sides) to this definition. Doing that, we get the equivalent definition:

For all real , is an integer such that, for all integers ,

I leave as an exercise to prove the dual properties of the ones we’ve seen for the floor function.

Indirect equality and the solution to the problem

Ok, so now that we have seen the formal definitions of the ceiling and floor functions, we can proceed. Note that these definitions have the aproppriate shape to use the proof technique named Indirect Equality. Briefly, the rule of Indirect Equality claims that two numbers and are equal if, for all numbers of the same type as and , the following holds:

Recall that we want to calculate an expression , such that, for a given real :

To use indirect equality, we will prove, for all , the following:

The detailed proof is as follows:

We have thus proved that:

Note that we still have a problem: our floor expression still involves an application of the ceiling function! However, since

we can easily determine the value of by a simple case analysis. If is an integer, then , else . Hence,

An example in Perl

An example of a language that does not provide a native function ceiling is Perl. The only native function related with rounding numbers (as far as I know) is the function int. This function is a mixture of the floor and ceiling function: for positive numbers it behaves as the floor function and for negative numbers it behaves as the ceiling function. This means that to solve the problem in Perl, we just have to worry about positive arguments!

Therefore, from our previous analysis, we can write a correct implementation of the ceiling function as follows:

sub correct_ceil {
  my $r = shift;
  my $frac = $r - int($r);
  if($frac<=0) {
    return int($r);
  } else {
    return 1+int($r);
  }
}

And that’s it! We have a real proof that this function is correct! Although the problem is simple, it is very common to make mistakes. As an example, I found the following wrong ceiling implementation in a programming forum:


# ceil() funtion to use instead of loading in
# the POSIX module each time
{
local ($amount) = @_;
$floor = int($amount);
$ceil = int($amount + 0.5);
if ($ceil == $floor)
{
$ceil++;
}
return $ceil;
}


Clearly, this function does not work for integer arguments! I just hope it is not being used anywhere

Note: in Perl you can import the module Posix and use the function ceil, but our goal was to write the ceiling function knowing that the floor function is defined.

Conclusions

The main goal of this post was to show how mathematical arguments can be used to give us confidence in our own programs. I’m aware that, although the ceiling and floor functions are widely used (in financial applications, for instance), this example could be presented in a different way. The most obvious drawback is that the main proof is quite long; it could be shortened, but I would have to omit some intermediate steps.

On the positive side, once we adopt the definitions given, most part of the proofs involving the ceiling and floor functions become similar, and thus systematic. This allows us to reuse the proof techniques over and over again.

I hope you have enjoyed the post and I’d be glad to get some comments!

A much better solution by Rob Mayoff

Rob Mayoff proposed a much better solution (see comments) to this problem! A proof of his solution can be:

Therefore,

.

Thanks Rob!

Related Articles:

• On Programming and Mathematical Methodology -- Part II
• On Programming and Mathematical Methodology

I start by presenting the properties involved in the traditional solution and then I generalize it for arbitrary operators. I finish the note with a simple refinement. If you have any nice example instantiation for the last set of assumptions, I would be glad to know it. Other than that, comments or corrections are more than welcome!
The note is available in PDF. Click the following link to get it:

JFF1 – Swapping the value of two variables

Related Articles:

• On Programming and Mathematical Methodology -- Part II
• On Programming and Mathematical Methodology

A few days later Alexandra got ill with some strange pain in the abdominal area. The following weeks were really hard, since she had to go to the hospital emergency services. So that you have an idea of how strange the whole thing was, the doctors still don’t know what the problem is! Now, she has occasional pain, but it seems to be much more controlled.

Anyway, more or less at the same time I started to read a very nice article (a Functional Pearl) written by Jeremy Gibbons, Richard Bird and David Lester named “Enumerating the Rationals“. The paper presents some algorithms encoded in Haskell to enumerate the positive rational numbers. In particular, it presents algorithms to construct the famous Stern-Brocot and Calkin-Wilf trees. It also presents a very efficient algorithm to enumerate the rationals in Calkin-Wilf order just by using as current state the previous rational (i.e., two integer numbers). However, the authors claim that “it is not at all obvious” how to create a similar efficient algorithm for enumerating the rationals in Stern-Brocot order. Well, after reading it, Roland (my supervisor) and me found a way of doing it. The key idea is that rational numbers are pairs of coprime numbers (numbers which greatest common divisor is 1) and thus, we can use Euclid’s algorithm as a basis for enumerating these pairs. By using the Extended Euclid’s algorithm written using matrix multiplication, we were able to derive both Calkin-Wilf and Stern-Brocot enumerations from the same algorithm. We wrote a paper named “Recounting the Rationals: Twice!” that was submitted to the journal American Mathematical Monthly.

I’ve also presented the algorithm at the “Fun in the Afternoon” event in Cambridge, last May. I think the talk was clear enough and, although it has nothing to do with functional programming, its methodological aspect should be interesting enough to any (functional) programmer. I’ve had very positive feedback on the talk, which is a good sign. The slides of the talk are available in the event’s webpage.

In April I’ve attended to the Midlands Graduate School (MGS Spring School). It was a very nice event organised by our group (in particular, I have to congratulate Henrik and Graham for their excellent work!) with very nice talks as well. My favourite courses were Category Theory, Algorithmic Problem Solving and Operational Semantics, but I’ve also enjoyed the others I’ve attended. The best thing about this kind of event is the social interaction that you have with other students and researchers. And again, as happened before in other similar events, I always get that cold sensation that I don’t know nothing about anything! The good news is that this feeling is a constructive one, since I get motivated to learn more!

And since we’re talking about learning, I’m currently studying Generating Functions, which are formal power series that encode information about sequences. Generating Functions are a very powerful tool: they can be used to prove identities very easily, to find nice and closed formulas to recurrence relations, to work with datatypes in order to find isomorphisms and, more importantly to my work, they can be used to solve counting problems in a very effective way. I’m writing a note about what I’m learning and I’ll probably post it here.

To finish the news about work, I’m currently preparing two JFFs (JFFs are my personal technical notes). The first one deals with the very known and simple problem that consists in swapping the value of two variables without using another temporary one. The second shows how to construct a very famous algorithm. I promise that I will post the notes here, as soon as they are available!

Besides work, I guess that the only relevant thing to talk about is that we went on holidays to Halkidiki in Greece in the last week of May. It was excellent and Alexandra and me will post a somewhat detailed description on our joint blog Furiousmind.org.

1. Post JFF0, JFF1 and JFF2 (these are the notes on distributivity and the greatest common divisor, how to swap values of variables without using another temporary one and the construction of an algorithm that is well-known, respectively);
2. Prepare a note I have written together with my supervisor about Number Theory to be distributed;
3. Prepare things to the Summer School in Marktoberdorf (Formal Logical Methods for System Security and Correctness). It’s true! I’ve been accepted to participate in the school and I already got the plane tickets. This means that I’ll be in Germany from the 31st July to the 12th August. Then I fly directly to Portugal and I return to Nottingham on the 29th August. So, if you want something from Germany or Portugal, let me know
4. Since I’m talking about trips, Alexandra and me are going to Amsterdam this next weekend. We’re really looking forward for it! And if you want something from there, please let us know.

Thanks for reading and see you in the next post!

In this post, I’ll talk about mathematical proofs. And what’s the relevance of this topic to programmers? Well, computer programs are mathematical formulae, with a precise formal meaning and embodying constructive theorems about the systems they implement (as well-written in “Mathematics and Programming – A Revolution in the Art of Effective Reasoning“, by Roland Backhouse). The difference between theorems embodied by computer programs and the ones usually studied in mathematics is that they are applied by an unforgiving machine, with the effect that the smallest error can cause a huge damage. This means that computer programmers must create trustworth designs, i.e., the constructive theorems embodied by their programs must be programmed correctly.

Mathematical Proofs

Mathematicians job is to do mathematics, i.e., to design and present theorems, arguments, algorithms and in some cases whole theories. However, the traditional mathematical curriculum is more concerned with teaching mathematical facts — existing theories and concepts — than with the doing of mathematics. And even when design and presentation get some attention, they are treated separately: design of solutions is viewed as a psychological issue, while presentation is viewed as a matter of personal style (words from this Dijkstra’s note on Mathematical Methodology).

A proof of a theorem should demonstrate, using certain facts (also known as axioms) or previously proved theorems, why it is true. Additionally, a good proof should explain clearly how the facts are combined and it should express the design considerations so that readers can understand it better, explain it to others and prove other theorems in a similar fashion. Now, look at the following conventional proof of , which is similar to the majority of proofs we can find in math textbooks (the proof is actually from a math textbook, but it was extracted from [GS95]).

Proofs are usually like this one: written using natural language, which, by nature, admits ambiguity. These proofs, also called informal proofs, place a large burden on the reader since it is difficult to see precisely how facts interact. In order to achieve the crispness we aspire to, we must deviate from informal proofs. That is why most of our mathematical reasoning is carried out in what is known as calculational method. This method reduces proof obligations to targets to be reached by formula manipulation. Although there are some criticisms and objections to the method, the experience shows that arguments become more clear and systematic, since we are (usually) restricting ourselves to a very modest repertoire and to simple syntactic manipulations. Besides, with the development of the method, some heuristics have been created, allowing the writer to prefer certain decisions (almost according with the principle “There is really only one thing one can do.”).

Proof Format

Note that calculational arguments usually start with a boolean expression that, by value-preserving transformations, is massaged according to our needs (we can evaluate it to true or false, or we can transform it into an equivalent boolean expression). So, if we want to evaluate a boolean expression A to true and it takes 3 steps, then, for general expressions B and C, we would have:

the first step would establish A is B ;
the second step would establish B is C;
the third step would establish C is true .

This means that we would have the intermediate expressions B and C repeated twice. In general, B and C can be long expressions, so we need a proof format that allows us to omit intermediate expressions. We use Wim Feijen’s proof format (described in detail in EWD999: Our Proof Format, Predicate Calculus and Program Semantics and in Chapter 3 of Program Construction: Calculating Implementations from Specifications), which for this small example would render:

The advantages of this format are more than just brevity. It allows us to conclude immediately that A is true without reading the intermediate expressions and we also can use any transitive relation between the steps. Also, the use of a systematic proof format allows us to compare two different proofs of the same theorem more effectively. Now, look how the proof presented above in an informal style can be rewritten in a calculational style:

In this second version, the proof format makes all the ingredients much more evident; every step is well identified and we can see it uses a common strategy: it eliminates the union and disjunction operators using their definition, performs some manipulation and reintroduces the operators. Also, this second argument eliminates the “if” and “only if” argument.

Final notes

To conclude I’d just like to quote a paragraph from Roland’s Backhouse article I’ve mentioned above:

“The vast complexity of computer software makes its unreliability understandable, but not excusable. The implementation of reliable computer systems, carrying a guarantee of fitness-for-purpose, imposes major intellectual challenges that can only be met by a science of computing whose hallmark is the avoidance of error.”

Related Articles:

• On Programming and Mathematical Methodology

My research is on algorithmic problem solving and its main goal is to develop calculational problem-solving techniques resulting in educational material supporting the use of a calculational approach to algorithmic problem solving. The focus of the project will be on the dynamics of problem solving – the processes of mathematical modelling and effective calculation in the formulation of concise and precise algorithmic methods.

As any other researcher, I spend most of my time reading and writing. That is one of the reasons I have created this blog: to organise my written notes. Using a blog system brings me some advantages like:

• I can tag my notes and use the system search capabilities to find them;
• I can access and change them from any place in the world, as long as I have Internet access;
• I can add new content from any place in the world, as well;
• I can share my notes and get feedback from my colleagues, supervisors, friends or anyone who is just interested in the same topics.

Other important reason to share my notes and thoughts is that I think they may be of interest for programmers. Since this is my first post, and (probably) most of you don’t really understand what I am doing, I will start by presenting some historical facts (mixed with personal opinions) and motivations. It is my hope that these facts will help you understand the relation and importance of mathematical methodology to programming. Please note that to read the entire post, you may need to click the “Read more” link.

Historical context

In the 1960s, programmers started recognising that there were serious problems in the programming field and that it was necessary to prove the correctness of programs. At the time, software engineering was facing a software crisis and programming was not very well understood. Many software projects ran over budget and schedule and some of them even caused property damage and loss of life (see the RISKS-FORUM Digest for some examples).

To solve these problems, computer scientists focused on programming methodology and on ways to build programs in a systematic way. A common consensus was that programs should be proved correct, and in the late 1960s, some important articles had an important impact on the field. In 1968, Edsger W. Dijkstra published an article on the harmfulness of the Go To statement, where he claims that its use makes it impossible to determine the progress of a program. Also, one year later, Tony Hoare published a seminal article where he introduces the Hoare triples and an axiomatic approach to language definition.

Although Hoare’s theory had a great impact, it was quite difficult to use it to prove existing programs correct, since one was forced to find an invariant for each loop. Programmers started studying alternatives, and the most plausible one was to develop the program together with its proof. Some years later, in 1975, Edsger W. Dijkstra published a paper where he introduced weakest preconditions. One year later he published the book “A Discipline of Programming” and showed how to use weakest preconditions as a “calculus for the derivation of programs”. Programmers were now able to build programs in a more reliable and systematic way, and the art of programming became more and more a discipline of programming.

From here, Dijkstra and others, dedicated themselves to the “mathematization” of programming and they learned to derive programs from their specifications: first simple ones, then more complicated programs. As the programs were becoming more and more complicated, the solutions were becoming less and less simple and beautiful. The reason was the “standard mathematical reasoning patterns” (see this note, page 9), which were not suitable for the task at hands. The conclusion was that computer scientists would have to learn how to construct proofs more effectively, in order to solve more ambitious problems. This was the beginning of a new period: computer scientists started to investigate ways of streamlining the mathematical argument. Mathematics and mathematicians were now faced with this new side of Computer Science.

During this new period, several problems were identified with traditional mathematics. One of the first problems was that mathematicians hardly manipulate their formulas: they interpret them; and one of the reasons is that the notation they use is not adequate for manipulation. This and other conclusions were also presented in the PhD thesis of Netty van Gasteren “On the shape of mathematical arguments“, where she presents a very interesting study about proofs (proofs of correctness of programs included).

My project is basically a continuation of Netty’s study, but while she did a breadth study, I am concerned specifically with algorithmic problems: construction of new algorithms and usage of algorithmic techniques to simplify mathematical invention.

Final notes

Algorithms have been studied and developed since the beginning of civilisation, but, over the last decades, the unprecedented scale of programming problems and the consequent demands on precision and concision have made computer scientists hone their algorithmic problem-solving skills to a very fine degree.

Even so, and although much of mathematics is algorithmic in nature, the skills needed to formulate and solve algorithmic problems do not form an integral part of mathematics education; also, the teaching of computer-related topics at pre-university level focuses on enabling the student to be an effective user of information technology, rather than equip them with the skills to develop new applications or to solve new problems.

I believe that making clear the algorithmic nature of problems can help students understand what’s going on, and more importantly, they will be able to solve new problems more effectively. And since tomorrow’s programmers are today’s students, it is important that we learn how to streamline the mathematical argument, how to demystify the process of mathematical invention and how to turn the design of crisp arguments into a teachable discipline.

Thank you very much for reading my first post. It is already too long, so I will leave concrete examples and more detailed explanations — including derivation of programs from their specification — for later. I intend to write similar articles in the future, so if you like this one, consider subscribing this blog.

Related Articles:

• On Programming and Mathematical Methodology -- Part II