Mathieu Gueydan

I'm just sharing here my happiness, as I received today the centurion award in Project Euler. Of course, it's not as shiny as the one related here, but I'm proud anyway.


If you're wanting to train your algorithm programming abilities, Project Euler is a good place to go. If you're new to this, let me advise you some basic tips :

1. Don't try to rush high level problems

Problems often are related to previous problems. Skipping some of them may force you to spend time trying to solve problems you don't have tools for.

2. Think about complexity first

Most of the problems ask you to iterate on things. Generally, they are several elements you may choose to iterate on. You may always want to choose the lesser complexity for your algorithm, which means, the fewer and the fastest iterations.

As you design your algorithm (in you head or on paper), you may want to shortly evaluate the number of iterations you will need to full-fill the calculation. If it's to high, you're solution is wrong.

3. Think "out of the box"

If you think you are tackling the problem from the right angle but it doesn't work, it's probably that you don't have the right angle. Most of the time, there is another way to watch the problem you didn't figured out at the moment.
Don't spend time in small optimisation and lesser algorithms improvement (I know, this is fun to do). Generally, if you're wrong, it's not about 10% it's about a factor 1000.

One slight note of caution : be aware that a few number of the first 100 problems may need you to use specific mathematical theories (often linked to Euler's work). For those ones, you may search long hours without any chance to find a solution (as it would ask you to re-invent the mathematical theory, which is not what you are trying to do). So if you are stuck on a problem for a very long time, you may want to search for associate mathematical theory. Which is not very easy without cheating.

4. Keep your programs (and keep them clean)

As each problem ask you a single answer and nobody will comes after you to read your application, you may want to write disposable code in order to spare time. Here's why I see it as a bad idea.

You will spend more time troubleshooting : involved concepts are pretty hard to understand, there is a good chance that you will miss things. And if you do, finding them in a messy code will take you a lot of time.

You will not be able to reuse things : as told before, some problems are linked to previous one. So you will often have to go back to a previous problem's solution to re-use not the code, but the way of thinking. If you coded it cleanly the first time, this will be easier.

5. Use assertions

I often suggest co-workers to make no assumption in their code (check everything always - let's keep this topic for another post).
Project Euler is a good illustration of that. I use a large amount of assertions in my code despite the low number of lines (about 50 a problem), in order to catch unpredicted cases. The algorithms you will develop are complex, and it's pretty easy to miss one spot. Your own code is the best place to check every assumption you made.

6. Don't cheat and Enjoy

So far I resisted the temptation to cheat (with the few frustrating consequences explained before when specific mathematical theories are involved in the solution). Almost every answers are available just here on internet, but the only meaning of this exercise is to improve your algorithm skills not your google search abilities.

I still can remember the joy I felt, by solving the 393th problem, after days of unsuccessful tries. It worth it.