[an error occurred while processing this directive] CIS at UO: 2001 ACM Programming Competition  
Computer and Information Science
University of Oregon



2001 ACM Programming Competition Strategy

Here are some thoughts on team strategy for the competition:
  1. Since there is only one workstation per team, it is absolutely essential that this resource be used as efficiently as possible. This means that the solutions should be designed on paper all the way to the point of hand written code, so that the workstation is only used for typing in a solution and compiling it. As much as possible, the hand written solution should be free of syntax errors. The contest time crunch demands that the workstation not be used for development, and only minimally for debugging. In particular, once your solution compiles, if it does not produce the correct results, print a hard copy and debug on paper so that the workstation is free for someone else.
  2. All team members should first do a quick read of all the problems with the goal of guessing at their difficulty and the general nature of their solutions. Use the assessment sheet for recording these initial impressions. No more than a half hour should be spent on this initial reading. Each team member should start looking at the problem sequence at a different point so that all of the problems are read as soon as possible. I.e., the first member should begin with problem A, the second with problem D, and the third with problem G, but all team members should eventually look at all of the problems. During this initial assessment, if any member is confident they can solve a problem in fifteen minutes, then that team member should go ahead and work out the solution and submit the problem, then come back to reading the other problems.
  3. After the initial individual reading, the team should together discuss the problems and decide on a first problem for each member. The easy problems should be solved first, even if they aren't as interesting. Remember that the goal of the competition is to solve as many problems as possible, so go for the easy ones first. A secondary goal is to get correct solutions submitted as soon as possible.
  4. When you are working on a solution, read the problem description carefully, paying special attention to any constraints (or lack of) on the input, and the format of the output. It might help to first write the code for reading the input and generating output before implementing the logic to get the correct output.
  5. Some things to keep in mind:
  6. Consider boundary conditions on input
  7. Consider possible value overflows
  8. Consider algorithm efficiency only to the extent that solution will terminate for extreme input cases in a reasonable amount of time
  9. Consider the possibility of "trick" problems, i.e., the problem may look complex and actually be very simple, or may look simple, but require a complex solution.
  10. Before submitting a solution, try it with the sample input and compare the output to the sample output. Also try input not given, but allowed by the problem description, and verify that the output is correct to the extent possible. Try extreme cases of input values.
  11. Probably most important - remember that the competition experience should be fun. It is an opportunity to challenge yourself and use your problem solving skills, and you should have an enjoyable time doing so.
datkins@cs.uoregon.edu

Last updated 2001/10/08



[an error occurred while processing this directive]