[Carroll Morgan told me this puzzle.]

Prove that for any positive K, every Kth number in the Fibonacci sequence is a multiple of the Kth number in the Fibonacci sequence.

More formally, for any natural number n, let F(n) denote Fibonacci number n. That is, F(0) = 0, F(1) = 1, and F(n+2) = F(n+1) + F(n). Prove that for any positive K and natural n, F(n*K) is a multiple of F(K).

This problem caught my attention, because it looks like a good example for using a result that I have derived last year. My result gives a reasonable sufficient condition for showing that a function distributes over the greatest common divisor and shows that the Fibonacci function satisfies the condition.

In fact, using the property that the Fibonacci function distributes over the greatest common divisor, we can solve this problem very easily. Using to denote the Fibonacci number , to denote the greatest common divisor of and , and to denote the division relation, a possible proof is:

The crucial step is clearly the one where we apply the distributivity property. Distributivity properties are very important, because they allow us to rewrite expressions in a way that prioritizes the function that has the most relevant properties. In the example above we could not simplify nor , but applying the distributivity property prioritised the operator — and we know how to simplify . Furthermore, in practice, distributivity properties reduce to simple syntactic manipulations, thus reducing the introduction of error and simplifying the verification of our arguments.

(Now that I think about it, perhaps it would be a good idea to write a note on distributivity properties, summarizing their importance and their relation with symbol dynamics.)

If you have any corrections, questions, or alternative proofs, please leave a comment!

The new and official URL of this website is now shorter and r’s-free: joaoff.com .

If you don’t like it and prefer the old one, please let me know!

Inside, there was a check for a correction I sent him some months ago. In fact, it was not really a correction; it was more like a comment. And it was so obvious (he even said that) that he just sent $0.32, instead of the usual $2.56. But hey, who cares? I’ve got Knuth’s autograph now

Perhaps I should set as one of my goals to find a proper error, so that I can receive a $2.56 check By the way, the errata of the Concrete Mathematics is available online and this particular omission is documented as follows:

page 338, line 2 from the bottom
   change “for $z$” to “for $z$ and multiplying by $a$”

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

Problem statement

Starting in the top left corner of a 2×2 grid, there are 6 routes (without backtracking) to the bottom right corner.

How many routes are there through a 20×20 grid?

My solution

In order to make the problem more interesting, let us investigate the more general problem of counting the number of routes in a n×n grid. Our argument is based on three observations:

1. all the paths have size 2×n (the reason is obvious: you have to go right n positions and down another n positions);
2. since we can only go right or down, we can identify every path by a string of Rs and Ds, where a R means going right and a D means going down; as an example, the paths illustrated in the problem statement are (from left to right and from top to bottom): RRDD, RDRD, RDDR, DRRD, DRDR and DDRR;
3. the strings mentioned above must contain the same number of Rs and Ds.

From these three observations, we can transform the problem to the following:

How many different strings of size 2×n, consisting of n Rs and n Ds, there are?

The solution is now very simple, because the positioning of n Ds (or Rs) determines the positioning of the other n Rs (or Ds). Hence, the number we are interested in is the number in which we can choose n positions from 2×n available. The answer, using the traditional notation for the binomial coefficient, is:

Instantiating n with 20, we get the answer to the initial problem of the 20×20 grid.

Generalization to m×n grids

The generalization to a m×n grid is also simple. The only difference is that the strings have length m+n. Using the same reasoning as above, the number of paths through a m×n grid is:

Final note: If you want to access the forum of the problem, you have to solve it.

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!