130 likes | 265 Views
Beating the odds: winning programming contests. Chris K. Young Presentation for 12ISP September 2004. What are you on about?. There are two well-known programming contests at tertiary level: ACM International Collegiate Programming Contest: http://www.sppcontest.org/
E N D
Beating the odds: winning programming contests Chris K. Young Presentation for 12ISP September 2004
What are you on about? • There are two well-known programming contests at tertiary level: • ACM International Collegiate Programming Contest: http://www.sppcontest.org/ • New Zealand Programming Contest: http://www.nzpc.otago.ac.nz/ • Contestants enter as teams of three. • Solve as many problems as possible in five hours.
So, you wanna win? • So did we! • Our team was: Bradley, Edward, and me. • We entered both contests in 1997–1999. • Nationally, we got in the top three places for all NZPC contests, and ACM for all but one. • So you can win. But it won’t happen willy-nilly. • Two types of strategies are essential: • Programming strategies • Teamwork strategies
Programming strategies • Many people obsess excessively over choice of programming language. • The specific language is unimportant as long as all members are fluent in the one chosen. • More important to understand the problems and the methods required to solve them. • Thus, it’s important to know a good range of solution methods, and for all team members to become familiar with them.
Some methods we liked • Dynamic programming, with pre-computation in extreme cases. • Contest submissions have performance and size requirements. • This method provides a space-time trade-off. • Textual parsing using state machines. • Excellent flexibility for most parsing work. • Many programmers fear this method. • My solution: practice, practice, practice!
Code library • When there is a contest problem we couldn’t solve, we review the problem at a later date. • We usually end up writing code to solve the problem. If it’s really good, we print it to use for future contests. • Bringing good, tested code to contests has saved us a lot of time. • If nothing else, make a compact yet fast bignum library, if your platform lacks one.
It’s all about teamwork • The whole is greater than the sum of its parts. • Choice of team members is very important. • They need to work well together: • Understand each other’s approaches • Share a common jargon • Agree on acceptable practices • Have a common vision • Choice of team captain is equally important.
The team captain • Team captains manage their teams. They make all the essential decisions about the team: • When and what to practise • What to bring to the contest • How long to spend on which problems • How members need to perform to stay in • Need to be highly respected (both technically and socially) by all team members.
Before the contest • Practice is essential: • Work on previous problems to become familiar with required solution methods • Develop scheduling strategies: how long to spend on which types of problems • Resources are essential too: • Sort out which books to take to the contest • Prepare all required code libraries • Decide on transportation arrangements
During the contest • There is only one computer, and only five hours, so computing time has to be rationed. • The team captain must be prepared to be despotic about enforcing this. • Our team has a strict 30-minute policy. If you don’t complete your problem by then, you get off the computer. No exceptions. • There isn’t enough time to solve all the problems. Decide which ones to attempt, in which order, and who to try which.
The coder • During your time on the computer, you need to have your design drafted to a stage where you can just key it in with little thinking. • Usually this means pseudocode is required. • In the name of expediency, be prepared to throw all the “structured” coding rules to the wind. • Your code is likely to be the ugliest (yet still debuggable) piece of turd in the world.
Sideliners are the busiest people • When you’re not on the computer, you don’t twiddle your thumbs. • You either work with the other offline person to draft out the design for the next problem, or help the online person debug their code. • It is thus important for every team member to understand everyone else’s designs. • No member works on a problem alone, except for extremely trivial ones.
It’s all about winning • The strategies I covered worked for our team. They may work for you too. • Part of our team’s success comes from our attitude: we’re there to win, not just to have fun. We worked hard to achieve this. • If the team has an effective captain with clear direction, and its members are competent and work together well, the chances of winning are excellent.