[barrkel]

See now, the IOI problem sets do emphasize algorithmic thinking - I think they're marginally better than Project Euler problems - but again, it's very low-level stuff. It must be, in order to have a handful of problems that can be tackled in a couple of hours or so.

I happen to believe that taste in crafting of program structure and selection of appropriate abstractions is more important than algorithmic acuity for most modern programming. Computational geometry, graph theoretical manipulations, dynamic programming and so on certainly have their uses, but they are usually a small core of something and not reimplemented often. Maintainable programs are a bigger issue IMO; and an excess of focus on the finer details of computational algorithms doesn't necessarily solve that issue.

I rather think it can hamper the goal. Really efficient algorithms often "break the rules", exploiting commonalities or attributes that cross abstraction boundaries. Take an ultra-simple example: finding the index of a (possibly missing) element in an unsorted array with a linear search. The fastest in-order sequential algorithm is to add the element being searched for to the end of the array, and then iterate through the array and halt when the element is found. This reduces the amount of work that needs to be done over a more simple search because it removes the need for a termination condition test (index in array less than length of array) on the search loop. But it also breaks other things; it won't work in the presence of threads, and it's surprising that a search operation is not a read-only operation. Adding may need a memory reallocation; if the array is large and the growth algorithm is geometric (which it should be), then it could very surprisingly cause an OOM. Sure, you can get around this by pre-allocating the required slot, and detecting multiple threads etc., but now you've made things more complicated and harder to maintain in the search for the most efficient algorithm. The goal of efficiency can cause more assumptions to be made or pre-conditions required, and for these assumptions / pre-conditions to leak across abstraction boundaries, ultimately making maintenance changes have multiplicative rather than additive complexity costs.

So I think it's fine to target big-O algorithmic costs when it makes sense and doesn't contort the software architecture too much, but applying an excess of problem insight can work against better architecture. Premature optimization, as tautologically as ever, is premature.

(I write as someone self-taught who competed in IOI etc. The problems sets were fun, but I wasn't under any illusions that I was learning a whole lot. Using recursion and branch pruning to solve combinatorial search problems is a distraction when you're better off looking at the bigger picture, dare I say it, the business picture.)

[dkersten]

I've also taken part in the IOI - twice - and like you, am a self-taught programmer (I was when I took part in the IOI, I've since also studied computer science). In my opinion the IOI problems, at least for a competition, are pretty good as they focus on using correct algorithms and data structures as opposed to hacks or mathematical tricks. Brute force solutions almost never produces good results for IOI problems. Edge cases must usually be considered as the test cases used to grade the solutions try to be varied and cover as many cases as possible.

IOI does nothing to teach good software architecture and I don't think any similar competition could ever hope to do that. It does, however, teach algorithmic thinking, use of data structures, understanding of time and space complexity and coding under pressure. (Well, all of these to a degree - like you said, recursion, branch pruning, trees and graphs and the like. more to be desired? Sure! But not a bad start, especially for high school students who are unlikely to have much exposure to problems which would otherwise have forced them to learn these things - I know people even now who, having only ever done business applications, would fail miserably at solving any IOI-like or algorithmically-heavy programming problem because they were never sufficiently introduced to the things the IOI focuses on.) All great lessons, even if there is more left to learn to become a great programmer.

I personally dislike PE because the problems I attempted seemed like they could often be better solved by employing a mathematical trick or insight as opposed to clever use of algorithms, data structures or programming ingenuity. My programming skills are much greater than my math skills, so I guess ultimately, because of that, PE just doesn't do it for me.