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.

Direct proofs

The concept of direct proof can vary slightly from person to person. For instance, Wikipedia defines it as:

In mathematics and logic, a direct proof is a way of showing the truth or falsehood of a given statement by a straightforward combination of established facts, usually existing lemmas and theorems, without making any further assumptions.

Alternatively, in Larry W. Cusick’s website we can read:

A direct poof [sic] should be thought of as a flow of implications beginning with “P” and ending with “Q”.

P -> … -> Q

Most proofs are (and should be) direct proofs. Always try direct proof first, unless you have a good reason not to.

I consider the wording ‘without making any further assumptions‘ in the first definition ambiguous and I don’t understand why the second definition only applies to implications. But anyway, with these definitions in mind, a direct proof for the irrationality of can be something like:

Or, alternatively, we can also use a proof of the following shape:

Irrational numbers

An irrational number is a real number that can’t be expressed as a simple fraction. Therefore, the number is irrational because for all integers m and n, with n non-negative, we have that:

A direct proof for the irrationality of

Now that we have clarified the concepts above, we prove that is irrational. For all integers m and n, with n non-negative, we have:

Note that, unlike traditional proofs, we don’t assume that m and n are co-prime, nor that is a rational. We essentially derive the boolean value of the expression

If you have any suggestions or corrections, please leave a comment. I’d be more than happy to hear from you.

Note: I learnt the contrapositive of this proof from Roland Backhouse (page 38, Program Construction — Calculating Implementations from Specifications).

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