Well, we’ve only been back at school for a very short time and it feels like I have never been away. The pile of marking is mounting, the websites I should really have implemented during the holidays are now politely tapping on my shoulder and demanding to be finished, the Mac Mini I was going to investigate is still sitting in its box on my study floor. So instead of taking care of all that, I’m going to write a blog post. (Well, I already ate the chocolate pudding so I didn’t have much left on my procrastination list…)

This week I have been covering recursion with the Lower 6th and also as revision with the Upper 6th. I quite like recursion because it makes me feel smart. Smart in the sense that I didn’t understand it at university and I do now…so maybe I would now understand all of those things our logic lecturer always said were “trivial”, were I to venture back to start my degree again. Maybe. Anyhow, the students wrote both iterative and recursive methods for finding the Fibonacci numbers and also computing factorials, and they were intrigued by the fact that the recursive function fell over when higher arguments were put in whereas the iterative version was able to cope with a lot larger arguments without throwing in the towel.

This led to a conversation about efficiency (happily on the syllabus!) and I thought of a sneaky way of getting them to implement a very basic number search algorithm – now we have a competition next week!

### The task

1. You think of a number between 1 and 100.

2. The computer must use any means possible to guess the number. It may ask any question (except “what is your number?” or similar) in order to find out. Each “guess” of a number costs 1 point. Each “answer” that a user must give also costs 1 point. If an error occurs at any point, a 10 point penalty is awarded and that test is ended.

3. On the day of the competition, I will tell you the 5 items of test data. You will use this data to test your program, and the program which scores the least points across all 5 test items added together is the winner.

I like this idea, and so did they – I could tell because they were silent and their tongues were sticking out as they coded! I think it’s a good opportunity for:

1) independent algorithm design

2) discussion after the competition about why certain algorithms may be more efficient

3) doing some testing of a real program

4) thinking about interesting things such as whether some methods are more efficient at finding certain ranges of numbers, and other such discussions

I did my teaching interview lesson on recursion about 14 years ago and I still love the topic! I’ve always gone for Towers of Hanoi to illustrate the beauty, then Fibonacci to show the pitfalls. I think the reason students have problems is that it just looks too darned simple. When mathematical induction was on the maths A- level then the maths students could tie it to that, but I understand it’s no longer there. I’ve just set my students a task to write a spilt function (split(“12,34,56″,”,”,0)=”12″, spilt(“12,34,56,”,”,”,3)=””, split(“12,34″,”,”,2)=”ERROR”), then set up some unit tests so I could test their functions quickly. Amazing how difficult it is to get the boundary cases right, but it shows some misunderstandings up very plainly. I offered them Raspberry Pi keyboard stickers as an incentive.

It also made me realise that one student was a lot better than his performances in class would indicate.

That’s really frustrating isn’t it, when someone clearly “gets it” but then can’t jump through the hoops the exam board requires to show it off.

To be honest, I always hated the Towers of Hanoi – found it really hard to get my head around at the time so I have avoided teaching that so that I don’t put people off! The reaction to the lessons so far has been overwhelmingly positive though which is great.