1 / 13

Beating the odds: winning programming contests

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/

Download Presentation

Beating the odds: winning programming contests

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Beating the odds: winning programming contests Chris K. Young Presentation for 12ISP September 2004

  2. 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.

  3. 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

  4. 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.

  5. 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!

  6. 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.

  7. 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.

  8. 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.

  9. 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

  10. 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.

  11. 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.

  12. 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.

  13. 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.

More Related