hspc-handout
TRANSCRIPT
-
7/29/2019 Hspc-Handout
1/18
Programming Competition Coaches Workshop
November 10, 2007
Contents
Agenda..................................................................................................................................................2
Programming Contest Rules.................................................................................................................3
Resources..............................................................................................................................................4
Anatomy of a problem..........................................................................................................................5
Necessary skills.................................................................................................................................... 6
Input and Output...................................................................................................................................6
Data Structures and Algorithms............................................................................................................7
Teamwork.............................................................................................................................................8
Testing and Debugging.........................................................................................................................8
Common Mistakes in Online and Real-time Contests......................................................................... 9
Teamwork in Programming Contests: 3 * 1 = 4 ................................................................................14
1
-
7/29/2019 Hspc-Handout
2/18
Agenda
Time Topic Location Materials
9:00 Welcome and overview. Introductions B016 Agenda
9:05 What's CS, why is it cool, and how programming
contests make it cooler.
B016 Presentation
9:30 Programming Competition overview
Basic rules
Anatomy of a problem
Programming tools
B016 Handout with rules
Links to get more
sample problems.
9:45 Theory: Programming competition skills and teaching
the skills
Data Structures Algorithms
Input and Output
Teamwork
Testing and debugging
How to write a problem
B016 Handouts
10:15 Break: Move to ARC cluster
10:30 Practical Session with PC2:
Input/output problem
Basic algorithm problem
Testing problem
ARC 3 problems
11:00 Mini Competition
Team up with members of CMU programming
team.
ARC 3 problems
11:45 Final Discussion ARC
12:00 Lunch ARC
2
-
7/29/2019 Hspc-Handout
3/18
Programming Contest Rules
Overview
Teams of up to three students are given a set of computer problems and will have to work togetherto find a solution to as many as possible within a specific time limit.
Regulations
Contestants are not to converse with anyone except members of their team and organizers of
the contest.
A team may be disqualified for any activity that jeopardizes the contest such as dislodging
extension cords, unauthorized modification of contest materials, or distracting behavior.
A team may have up to 3 students per team.
Each team may use only one computer, keyboard, and monitor.
Sample test data will be provided for each problem.
The team will run their solution. If they deem it correct, they can submit it to the judges.
The judges will review the submitted program and give feedback indicating the solution is
accepted or rejected. The test data files used by the judges might be different than the ones
given to the teams.
Each problem is solved when it is accepted by the judges.
Each team may submit a clarification request to the judges. If the judges agree that there is
an ambiguity or an error exists, a clarification will be issued to all participating teams.
Evaluation Criteria
Teams are ranked according to the most problems solved. For the purposes of awards, teams who
solve the same number of problems are ranked by least total time. The total time is the sum of the
time consumed for each problem solved. The time consumed for a solved problem is the time
elapsed from the beginning of the contest to the submittal of the accepted solution plus 10 penalty
minutes for every rejected solution for that problem regardless of submittal time. There is no time
consumed for a problem that is not solved.
3
-
7/29/2019 Hspc-Handout
4/18
Resources
Java Programming Environment
DrJava
http://www.drjava.org
Eclipse
http://www.eclipse.org/
Netbeans
http://www.netbeans.org
C,C++ Programming Environment
Eclipse CDT plugin
Netbeans C, C++ plugin
Both the plugins require a c++ compiler. They both work well with the gcc compilers built into
cygwin.
http://www.cygwin.com
Install gcc, g++, make, gdb and make sure the cygwin directory is in your path system variable.
PC2 Contest Environment
http://www.ecs.csus.edu/pc2
Sample Problems
The following link is to IBM's online resource for high school programming contests.
http://www-304.ibm.com/jct09002c/university/students/highschool
This site includes sample problems, teaching resources, tutorials for students, and instructions for
running and judging contests.
Carnegie Mellon HSPC
http://www.qatar.cmu.edu/hspc
4
http://www.drjava.org/http://www.eclipse.org/http://www.netbeans.org/http://www.cygwin.com/http://www.ecs.csus.edu/pc2http://www-304.ibm.com/jct09002c/university/students/highschoolhttp://www.qatar.cmu.edu/hspchttp://www.eclipse.org/http://www.ecs.csus.edu/pc2http://www-304.ibm.com/jct09002c/university/students/highschoolhttp://www.qatar.cmu.edu/hspchttp://www.netbeans.org/http://www.cygwin.com/http://www.drjava.org/ -
7/29/2019 Hspc-Handout
5/18
Anatomy of a problemAlmost every problem has five parts: the story, input specification, algorithm, output specification,
and test data.
StoryThe story usually includes some fictitious situation where someone has a problem and needs a
computer program to solve it. Sometimes the story can be misleading. It might make the problem
seem harder than it really is, so students need to be able to determine the fundamental problem
posed by the story. The story is also a way to get students to think about real world problems that
can be solved with computer science. The subtle goal is to get students beyond the software syntax
to see the power and versatility of computer science.
Input Specification
This contains a detailed description of the input format. A good input specification for a problem
gives exactly enough detail for the problem. For example if a program should be able to accept
both integer and floating point input that is strictly positive, then the specification could say input
will be a positive number.
Algorithm
The students should be able to clearly understand what the program should do. The description
should give exactly enough detail to understand the problem while requiring the student to identify
the challenging test cases. Students should know common mathematical formulas, so common
formulas should usually be omitted.
Output Specification
The output specification should be more detailed than the input specification. The teams need to
think about all the possible crazy input the judges might throw at them, but they should always
know the exact format for the answer.
Test Data
The given test data usually includes some simple examples. As a general rule the judges will notinclude tricky examples in the sample input/output; they want to save those test cases for judging
the competition. Students should be able to identify the tough test cases for a given problem.
5
-
7/29/2019 Hspc-Handout
6/18
Necessary skillsTo do well in a programming contest the students should know how to
Handle various types of input and output
Implement basic data structures and algorithms
Work together efficiently Test and debug their solution.
Input and Output
Input
In Java, input from the command line can be done with the Scanner class. The Scanner class
separates input into tokens separated by white space and converts them into the specified type.
import java.util.Scanner; // Import the package
Scanner input = new Scanner(System.in); // Scanner that reads from the console
Scanner input = new Scanner(new FileStream(file.txt); // read from input file
Selected Methods:
next() - reads next token and returns a String.
nextInt() - returns the next token as an integer value.
nextDouble() - returns the next token as a double value.
nextLine() - reads to the next new line and returns a String.
hasNext() - returns true if there is at least one more token.
Notes:
Be as specific as is necessary when writing the input specification for a problem. Will the
input be integers, floating point numbers? If the specification if vague then the solution
should be able to handle all permissible input.
When writing the specification, or when looking at a problem think about
Integers or floating point?
Positive, zero, negative input?
What's the largest and smallest possible input value?
What's the maximal or minimal length for a string?
OutputSystem.out.print(String) // outputs String to the console without a new line
System.out.println(String) // outputs String with a new line
6
-
7/29/2019 Hspc-Handout
7/18
Data Structures and AlgorithmsA problem set archive for high school competitions was surveyed to determine common algorithms.
The most frequently used algorithms were:
Comparisons: if-else > < == >=
-
7/29/2019 Hspc-Handout
8/18
Teamwork
Problem:
How do you use 3 people and one keyboard to solve as many problems as possible?
There are many useful ideas in the attached article:
Teamwork in Programming Contests: 3 * 1 = 4
by Fabian Ernst, Jeroen Moelands, and Seppo Pieterse
Every problem requires time at the computer. The students should try to solve as much of the
problem as possible before typing (except when solving the first problem). This reduces congestion
at the keyboard. Students that can work separately can usually solve more problems.
Testing and DebuggingJudges will always test the extreme cases. They will test the largest, smallest, hardest case to make
sure the team has a correct solution. If negative numbers are allowed then they will be used. When
a team submits a problem and receives an incorrect reply the problem is usually because they aren't
handling some strange extreme test case correctly. Teams should make sure that their assumptions
about input data are correct.
For more information read the attached article:
Common Mistakes in Online and Real-time Contests
by Shahriar Manzoor
This article is targeted to university teams, so some of the concepts are advanced for high school
students. However, the types of mistakes that commonly occur in contests is shared by both.
8
Read &ClassifyProblem
FormulateSolution
CodeSolution
TestSolution
DebugSolution +1
+1
+1
+1
-
7/29/2019 Hspc-Handout
9/18
Common Mistakes in Online and Real-time Contestsby Shahriar Manzoor
http://www.acm.org/crossroads/xrds7-5/contests.html
(Selected sections that are applicable to high school contests)
Introduction
Each year the Association for Computing Machinery (ACM) arranges a worldwide programming
contest. This contest has two rounds: the regional contests and the World Final. The teams with the
best results in the regional contests advance to the World Final. The contest showcases the best
programmers in the world to representatives of large companies who are looking for talent. When
practicing for programming competitions, remember that all your efforts should be directed at
improving your programming skills. No matter what your performance is in a contest, don't bedisappointed. Success in programming contests is affected by factors other than skill, most
importantly, adrenaline, luck, and the problem set of the contest. One way of getting immediate
feedback on your efforts is to join the Valladolid Online Programming Practice/Contest or the
online judge hosted by Ural State University (USU). Successfully solving problems increases your
online ranking in the respective competitions.
This article is for beginning programmers who are new to programming contests. I will discuss the
common problems faced in contests, the University of Valladolid online judge, and theUSU online
judge. The suggestions are divided into three parts: General Suggestions, Online Contest
Suggestions, and Valladolid-Specific Suggestions. Throughout this paper, please note that in real-
time contests, the judges are human and in online contests, the judges are computer programs,
unless otherwise noted.
Some Tips for Contestants
A good team is essential to succeeding in a programming contest. A good programming team must
have knowledge of standard algorithms and the ability to find an appropriate algorithm for every
problem in the set. Furthermore, teams should be able to code algorithms into a working program
and work well together.
The problems presented in programming contests often fall into one of five categories including
search, graph theoretic, geometric, dynamic programming, trivial, and non-standard. Search
problems usually require implementing breadth-first search or depth-first search. Graph theoreticproblems commonly include shortest path, maximum flow, minimum spanning tree, etc. Geometric
problems are based on general and computational geometry. Dynamic programming problems are to
be solved with tabular methods. Trivial problems include easy problems or problems that can be
solved without much knowledge of algorithms, such as prime number related problems. Non-
standard problems are those that do not fall into any of these classes, such as simulated annealing,
mathematically plotting n-queens, or even problems based on research papers. To learn more about
how problems are set in a contest you can read Tom Verhoeff's paper [ 6].
9
http://www.acm.org/crossroads/xrds7-5/contests.html#biohttp://www.acm.org/crossroads/xrds7-5/contests.html#linkshttp://acm.uva.es/problemsethttp://acm.timus.ru/http://acm.timus.ru/http://acm.timus.ru/http://www.acm.org/crossroads/xrds7-5/contests.html#Tomhttp://www.acm.org/crossroads/xrds7-5/contests.html#biohttp://www.acm.org/crossroads/xrds7-5/contests.html#linkshttp://acm.uva.es/problemsethttp://acm.timus.ru/http://acm.timus.ru/http://www.acm.org/crossroads/xrds7-5/contests.html#Tom -
7/29/2019 Hspc-Handout
10/18
What you should do to become a good team
There is no magic recipe to becoming a good team, however, by observing the points below (some
of which were taken from Ernst et al. [3]) you can certainly improve. When training, make sure that
every member of the team is proficient in the basics, such as writing procedures, debugging, and
compiling. An effective team will have members with specialties so the team as a whole has
expertise in search, graph traversal, dynamic programming, and mathematics. All team membersshould know each other's strengths and weaknesses and communicate effectively with each other.
This is important, for deciding which member should solve each problem. Always think about the
welfare of the team. Solving problems together can also be helpful. This strategy works when the
problem set is hard. This strategy is also good for teams whose aim is to solve one problem very
well. On the other hand, the most efficient way to write a program is to write it alone, avoiding
extraneous communication and the confusion caused by different programming styles.
As in all competitions, training under circumstances similar to contests is helpful. During the
contest make sure you read all the problems and categorize them into easy, medium and hard.
Tackling the easiest problems first is usually a good idea. If possible try to view the current
standings and find out which problem is being solved the most. If that problem has not yet been
solved by your team, try to solve it immediately, odds are it is an easy problem to solve.
Furthermore, if the your solution to the easiest problem in the contest is rejected for careless
mistakes, it is often a good idea to have another member redo the problem. When the judges reject
your solution, try to think about your mistakes before trying to debug. Real-time debugging is the
ultimate sin, you don't waste too much of your time with a single problem. In a five-hour contest
you have 15 person-hours and five computer-hours. Thus, computer-hours are extremely valuable.
Try not to let the computer sit idle. One way to keep the computer active is to use the chair in front
of the computer only for typing and not for thinking. You can also save computer time by writing
your program on paper, analyzing it, and then use the computer. Lastly, it is important to remember
that the scoring system of a contest is digital. You do not get any points for a 99%-solved problem.
At the end of the contest you may find that you have solved all the problems 90%, and your team isat the bottom of the rank list.
Different Types of Judge Responses
The following are the different types of judge replies that you can encounter in a contest [2]:
Correct
Your program must read input from a file or standard input according to the specification of the
contest question. Judges will test your program with their secret input. If your program's output
matches the judges' output you will be judged correct.
Incorrect output
If the output of your program does not match what the judges expect, you will get an incorrect
output notification. Generally, incorrect output occurs because you have either misunderstood the
problem, missed a trick in the question, didn't check the extreme conditions or simply are not
experienced enough to solve the problem. Problems often contain tricks that are missed by not
reading the problem statement very carefully.
10
http://www.acm.org/crossroads/xrds7-5/contests.html#fabianhttp://www.acm.org/crossroads/xrds7-5/contests.html#Rezaulhttp://www.acm.org/crossroads/xrds7-5/contests.html#fabianhttp://www.acm.org/crossroads/xrds7-5/contests.html#Rezaul -
7/29/2019 Hspc-Handout
11/18
No output
Your program does not produce an output. Generally this occurs because of a misinterpretation of
the input format, or file. For example, there might be a mixup in the input filename e.g., the judge is
giving input from "a.in," but your program is reading input from "b.in." It is also possible that the
path specified in your program for the input file is incorrect. The input file is in most cases in the
current directory. Errors often occurs because of poor variable type selection or because a runtime
error has occurred, but the judge failed to detect it.
Presentation error
Presentation error's occur when your program produces correct output for the judges' secret data but
does not produce it in the correct format. Presentation erroris discussed in detail later in this article.
Runtime error
This error indicates that your program performs an illegal operation when run on judges' input.
Some illegal operations include invalid memory references such as accessing outside an array
boundary. There are also a number of common mathematical errors such as divide by zero error,
overflow or domain error.
Time limit exceeded
In a contest, the judge has a specified time limit for every problem. When your program does not
terminate in that specified time limit you get this error. It is possible that you are using an inefficient
algorithm, e.g., trying to find the factorial of a large number recursively, or perhaps that you have a
bug in your program producing an infinite loop. One common error is for your program to wait for
input from the standard input device when the judge is expecting you to take input from files. A
related error comes from assuming wrong input data format, e.g., you assume that input will beterminated with a "#" symbol while the judge input terminates with end-of-file.
General Suggestions for Contests
Test the program with multiple datasets
There is always a sample input and output provided with each contest question. Inexperienced
contestants get excited when one of their programs matches the sample output for the corresponding
input, and they think that the problem has been solved. So they submit the problem for judgment
without further testing and, in many cases, find they have the wrong answer. Testing only one set ofdata does not check if the variables of the program are properly initialized because by default all
global variables have the value zero (integers = 0, chars = '\x0', floats= 0.0 and pointers = NULL).
Even if you use multiple datasets the error may remain untraced if the input datasets are all the same
size, in some cases descending in size or ascending in size. So, the size of the dataset sequence
should be random. It is always a good idea to write a separate function for initialization.
Mark Dettinger's suggestions on geometric problems
Mark Dettinger was the coach for the team from the University of Ulm. He suggested to me that
sometimes it is a good idea to avoid geometric problems unless one has prewritten routines. The
routines that can be useful are:
11
http://www.acm.org/crossroads/xrds7-5/contests.html#PEhttp://www.acm.org/crossroads/xrds7-5/contests.html#PEhttp://www.acm.org/crossroads/xrds7-5/contests.html#PE -
7/29/2019 Hspc-Handout
12/18
Line intersection.
Line segment intersection.
Line and line segment intersection.
Convex hull.
If a point is within a polygon.
From a large number of points what is the number of maximum points on a single line.
Closest pair problem. Given a set of points you have to find out the closest two pointsbetween them.
Try to learn how to use C's built-in qsort() function to sort integers and records.
Area of a polygon (convex or concave).
Center-of-gravity of a polygon (convex or concave).
Minimal circle, a circle with the minimum radius that can include the coordinates for a given
number of points.
Minimal sphere.
Whether a rectangle fits in another rectangle even with rotation.
Identify where two circles intersect. If they don't, determine whether one circle is inside
another or if they are far away.
Line clipping algorithms against a rectangle, circle, or ellipse.
Problems with equality of floating point (double or float) numbers
You cannot always check the equality of floating point numbers with the = = operator in C/C++.
Logically their values may be same, but due to precision limit and rounding errors they may differ
by some small amount and may be incorrectly deemed unequal by your program. So, to check the
equality of two floating point numbers a and b, you may use codes like:
if (fabs(a-b)
-
7/29/2019 Hspc-Handout
13/18
Presentation error
Presentation errors are neither caused by algorithmic nor logical mistakes. There is a difference
between the presentation error of online judges and that of live judges. The latter are able to detect
mistakes such as misspellings, extra words, extra spaces, etc., and differentiate them from
algorithmic errors, such as wrong cost, wrong decisions, etc. These mistakes are the presentation
errors as graded by the human judges. On the other hand, online judges in most cases compare the
judge output and the contestant output with the help of a file compare program so that even spelling
mistakes can cause a "wrong answer." Generally, when the file compare program finds extra new
lines, these are considered to be presentation error. Human judges, though, do not typically detect
these mistakes. But now computers are becoming more powerful, larger judge inputs are being used
and larger output files are being generated. In live contests, special judge programs are being used
that can detect presentation errors, multiple correct solutions, etc. We are advancing towards better
judging methods and better programming skills. The recent statistics of the ACM shows that
participation in the ACM International Collegiate Programming Contest is increasing dramatically,
and in the near future the competition in programming contests will be more intense [5]. So the
improvement of the judging system is almost a necessity.
A common mistake of contestants
Recently, I arranged several contests with Rezaul Alam Chowdhury and in collaboration with the
University of Valladolid and have seen contestants make careless mistakes. The most prominent
mistake is taking things for granted. In a problem I specified that the inputs will be integers (as
defined in mathematics) but did not specify the range of input and many contestants assumed that
the range will be 0->(2^32-1). But in reality many large numbers were given as input. The
maximum input file size was specified from which one could assume what was the maximum
possible number. There were also some negative numbers in the input because integers can be
negative.
References
1Astrachan, O., V. Khera, and D. Kotz. The Internet Programming Contest: A Report and
Philosophy
2Chowdhury, R. A., and S. Manzoor. Orientation: National Computer Programming Contest 2000,
Bangladesh National Programming Contest, 2000.
3Ernst, F., J. Moelands, and S. Pieterse. Teamwork in Programming Contests: 3 * 1 = 4, Crossroads,
3.2.
4Kaykobad, M. Bangladeshi Students in the ACM ICPC and World Championships, Computer
Weekly.
5Poucher, W. B. ACM-ICPC 2001, RCD Remarks, RCD Meeting of World Finals 2001.
6Verhoeff, T. Guidelines for Producing a Programming-Contest Problem Set:
http://wwwpa.win.tue.nl/wstomv/publications/guidelines.html
13
http://www.acm.org/crossroads/xrds7-5/contests.html#Poucherhttp://wwwpa.win.tue.nl/wstomv/publications/guidelines.htmlhttp://www.acm.org/crossroads/xrds7-5/contests.html#Poucherhttp://wwwpa.win.tue.nl/wstomv/publications/guidelines.html -
7/29/2019 Hspc-Handout
14/18
Teamwork in Programming Contests: 3 * 1 = 4byFabian Ernst
Jeroen Moelands, andSeppo Pieterse
http://www.acm.org/crossroads/xrds3-2/progcon.html
Introduction
Every year since 1977, the ACM has organized the ACM
International Collegiate Programming Contest. This contest,
which consists of a regional qualifying contest and the
Finals, provides college students with the opportunity to
demonstrate and sharpen their programming skills. During
this contest, teams consisting of three students and one
computer are to solve as many of the given problems as
possible within 5 hours. The team with the most problems
solved wins, where ``solved'' means producing the right
outputs for a set of (secret) test inputs. Though the individual
skills of the team members are important, in order to be a top
team it is necessary to make use of synergy within the team.
As participants in the 1995 Contest Finals (two of us also
participated in the 1994 Finals), we have given a lot of
thought to strategy and teamwork.
In this article we summarize our observations from various contests, and we hope that if you ever
participate in this contest (or any other) that this information will be valuable to you.
The Basics: Practice, Practice, Practice!
Because of the fact that only one computer is available for three people, good teamwork is essential.
However, to make full use of a strategy, it is also important that your individual skills are as honed
as possible. You do not have to be a genius as practicing can take you quite far. In our philosophy,
there are three factors crucial for being a good programming team:
Knowledge of standard algorithms and the ability to find an appropriate algorithm for every
problem in the set;
Ability to code an algorithm into a working program; and
Having a strategy of cooperation with your teammates.
Team strategy will be the core discussion of this article. Nevertheless, there are some
important considerations for improving your individual skills.
After analyzing previous contest programming problems, we noticed that the same kind of
problems occurred over and over again. They can be classified into five main categories:
1. Search problems. These involve checking a large number of situations in order to find the
best way or the number of ways in which something can be done. The difficulty is often the
imposed execution time limit, so you should pay attention to the complexity of your
algorithm.
2. Graph problems. The problems have a special structure so they can be represented as a
14
http://www.acm.org/crossroads/doc/crew/fabian_ernst.htmlhttp://www.acm.org/crossroads/doc/crew/fabian_ernst.htmlhttp://www.acm.org/crossroads/doc/crew/jeroen_moelands.htmlhttp://www.acm.org/crossroads/doc/crew/seppo_pieterse.htmlhttp://www.acm.org/crossroads/doc/crew/seppo_pieterse.htmlhttp://www.acm.org/~contesthttp://www.acm.org/~contesthttp://www.acm.org/contest/current/regionshttp://www.acm.org/crossroads/doc/crew/fabian_ernst.htmlhttp://www.acm.org/crossroads/doc/crew/jeroen_moelands.htmlhttp://www.acm.org/crossroads/doc/crew/seppo_pieterse.htmlhttp://www.acm.org/crossroads/doc/crew/seppo_pieterse.htmlhttp://www.acm.org/~contesthttp://www.acm.org/~contesthttp://www.acm.org/contest/current/regions -
7/29/2019 Hspc-Handout
15/18
graph-theoretical problem for which standard algorithms are available.
3. Geometrical problems. These involve geometrical shapes, lines, and angles.
4. Trivial problems. The choice of appropriate algorithm is clear, but these usually take quite a
long time to program carefully.
5. Non-standard problems.
For the first three categories, standard algorithms are well documented in the literature, and youshould program these algorithms beforehand and take the listings with you to the contest. In this
way, you can avoid making the same (small) mistakes repeatedly and you can concentrate on the
difficult aspects of the problem.
Another angle of practice is efficient programming. This does notmean type as fast as you can and
subsequently spend a lot of time debugging. Instead, think carefully about the problem and all the
cases which might occur. Then program your algorithm, and take the time to ensure that you get it
right the first time with a minimum amount of debugging, since debugging usually takes a lot of
valuable time.
To become a team, it is important that you play a lot of training contests under circumstances which
are as close to the real contest as possible: Five hours, one computer, a new set of problems eachtime, and a jury to judge your programs.
Team Strategy: The Theory
When your algorithmic and programming skills have reached a level which you cannot improve any
further, refining your team strategy will give you that extra edge you need to reach the top. We
practiced programming contests with different team members and strategies for many years, and
saw a lot of other teams do so too. From this we developed a theory about how an optimal team
should behave during a contest. However, a refined strategy is not a must: The World Champions of
1995, Freiburg University, were a rookie team, and the winners of the 1994 Northwestern European
Contest, Warsaw University, met only two weeks before that contest.
Why is team strategy important? There is only one computer, so it has to be shared. The problems
have to be distributed in some way. Why not use the synergy that is always present within a team?
``Specialization'' is a good way of using the inherent synergy. If each team member is an expert for
a certain category of problem, they will program this problem more robustly, and maybe more
quickly than the other two team members. Specialization in another sense is also possible. Maybe
one of the team is a great programmer but has poor analytical skills, while another member can
choose and create algorithms but cannot write bug-free programs. Combining these skills will lead
to bug-free solutions for difficult problems!
Another way to use synergy is to have two people analyze the problem set. Four eyes see more thantwo, so it is harder for a single person to misjudge the difficulty of a problem. Forming a think-tank
in the early stages of a contest might help to choose the best problems from the set and find correct
algorithms for them. However, once the algorithm is clear, more than one member working on a
single program should be avoided.
It is our experience that the most efficient way to write a program is to write it alone. In that way
you avoid communication overhead and the confusion caused by differing programming styles.
These differences are unavoidable, though you should try to use the same style standards for
function and variable names. In this way you can really make 3*1 equal to four!
15
-
7/29/2019 Hspc-Handout
16/18
Other Considerations
Since the contest final standings are based on the number of problems correctly solved, and (in the
case of ties) on the sum of elapsed time for each problem, a team should adopt a strategy that
maximizes the number of solved problems at the end of the five hours, and view the total elapsed
time as a secondary objective. In every contest there are some teams in the ``top six'' after three
hours, that are not even in the ``top ten'' after the total five hours. The reverse also occurs. A longterm strategy is therefore important: Try to optimize the 15 man hours and 5 hours of computer
time, and do not worry about your total time or how quickly you solve the first two problems.
To optimize this scarce time, try to finish all problems that you start. A 99% solved problem gives
you no points. Analyze the problem set carefully at the beginning (for example, by using a ``think-
tank'' approach) to avoid spending more time than absolutely necessary on a problem that you will
not finish anyway, and to avoid misjudging an easy problem as being too difficult. You need a good
notion about the true difficulty of the various problems as this is the only way to be sure that you
pick exactly those which you can finish within five hours.
Since you never have perfect information, you have to take risks. If you follow a risky strategy by
choosing to tackle a large number of problems, you might end up in the bottom half of the score listwhen each is only 90% solved, or you might be the winner in the end. On the other hand, choosing
a smaller number of problems has the risk that you have solved them correctly after four and a half
hours, but the remaining time is too short to start and finish a new problem, thus wasting ten percent
of the valuable contest time.
Time management should play a role in your strategy. If you are going to work on a large problem,
start with it immediately or you will not finish it. Although this sounds trivial, there are a lot of
teams which start out with the small problems, finish them quickly, and end up with only three
problems solved because they did not finish the larger ones. In our opinion, debugging should have
the highest priority at the terminal after 3.5 hours. When you start with a new problem that late in a
contest, the terminal will become a bottleneck for the rest of the contest.Of course terminal management is crucial. Though most programs are quite small (usually not
exceeding one hundred lines of code), the terminal is often a bottleneck: Everyone wants to use it at
the same time. How can this be avoided? The first thing to remember is: Use the chair in front of
the terminal only for typing, not for thinking. Write your program on paper, down to the last
semicolon. In this way you usually have a much better overview, and you have the time to consider
all possible exceptions without someone breathing down your neck, longing for the terminal. Once
you have finished writing, typing will take no more than 15 minutes. Though you should avoid
debugging (this IS possible if you plan the program carefully on paper), when you really have to do
it you should do it in a similar way: Collect as much data as possible from your program, print it out
and analyze it on paper together with your code listing. Real- time tracing is THE ULTIMATE SIN.
Some Example Strategies
1. The Simple Strategy
This strategy is quite useful for novice teams, or those who do not want to get into a lot of practice
and strategy tuning, and, therefore, is in no way optimal. The basic idea is to work as individually as
possible to try to minimize overhead. Everyone reads a couple of problems, takes the one he likes
most and starts working on it. When a problem is finished, a new one is picked in the same way and
so on.
16
-
7/29/2019 Hspc-Handout
17/18
Advantages are that little practice is needed. Total elapsed time will be minimal, since the easiest
problems are solved first. However, there are also severe disadvantages: Since the easiest problems
usually have the same level of difficulty, everyone will finish their problem at about the same time.
Thus the terminal will not be used for the first hour, since everyone is working on a problem on
paper, and remains a bottleneck thereafter. Furthermore, only the easy problems will be solved,
because no time will be left for the hard ones. The conclusion is that, provided your programming
skills are adequate, you will solve about three or four problems as a team. This will bring you, witha good total elapsed time, into the top ten, but probably not into the top three.
2. Terminal Man
In the terminal man (TM) strategy, only one of the team members, the T, uses the computer. The
other two team members analyze the problem set, write down the algorithms and the (key parts) of
the code, while the T makes the necessary I/O-routines. After an algorithm is finished, the T starts
typing and, if necessary, does some simple debugging. If the bug is difficult to find, the original
author of the algorithm helps the T to find it.
Advantages of this strategy are that the terminal is not a bottleneck anymore, and the task of solving
a problem is split over people who specialized in the different parts of the problem solving process.
A disadvantage is that no optimal use is made of the capacities of the T, who is mainly a kind of
secretary. If you only one of you is familiar with the programming environment, this might be a
good strategy. You can write a lot of programs in the first part of the contest when your brain is still
fresh, since the typing and debugging is done by someone else. It depends strongly on the
composition of your team if this strategy is suitable for you.
3. Think Tank
The strategy we followed during the preparation and playing of the Contest Finals of 1995 made
use of the above-mentioned ``think tank'' (TT). We felt that choosing and analyzing the problemswas such a crucial task in the early stages of a contest that it should not be left to a single person.
The two team members who are the best problem analyzers form the TT and start reading the
problems. Meanwhile the third member, the ``programmer'', will type in some useful standard
subroutines and all the test data, which are checked carefully. After 15 minutes, the TT discusses the
problems briefly and picks the one most suitable for the third team member. After explaining the
key idea to the programmer, they can start working on it. Then the TT discusses all problems
thoroughly, and puts the main ideas of the algorithm down on paper. We found out that two people
examining hard problems often lead to creative solutions. After one hour the TT had a good
overview over the problem set, and all algorithms were found. The next decision is how many
problems you want to solve. The easiest or shortest problems are handled by the programmer, while
the TT divides the other ones among themselves.The terminal is only used for typing in code from paper or gathering information from a buggy
program. If a program is rejected by the jury and no bug can be found, it is put aside until the last
hour of the contest. In principle, after three and a half hours no more new code is typed. The team
will briefly discuss the situation, and a plan is made for how to solve the problems which have yet
to be debugged.
Some advantages of this approach are that you will almost always tackle the programs which have a
reasonable chance of being solved correctly, and the hard problems can be solved because the TT
will start working on them in an early stage of the contest. A clear disadvantage is that you will
have a relatively slow start and your total time is not optimal. So to win, you need to solve one
problem more than the other teams. We feel that for a team consisting of partners with about equal
17
-
7/29/2019 Hspc-Handout
18/18
skills, this strategy will help you solve as many problems as possible.
Some Other Tips
You can practice a lot for a programming contest, and your strategy can be very good. However,
luck always has its part in the contest and you have to live with that. Do not be disturbed by it (or
the lack of it). Play your own contest. Never look at other team's standing, except to see if someteams solved a problem rather quickly that you thought to be too hard. If a program gets rejected by
the jury, don't panic. Try to find the bug, there always is one. Consider especially the limits of your
program, and ask yourself under which circumstances these limits will be exceeded. You do not
have to submit a correct program. It only has to produce the right output for the jury input.
Therefore you should program robustly and cleanly, and not write the shortest or fastest code
possible. And always remember: Programming contests are great fun!
Concluding Remarks
In this article we have recorded some of our experiences with programming contest strategies.Though these strategies are very dependent on the individual qualities of the team members, the
concepts apply equally to all teams. We hope that the information contained in this article will be
useful to you, should you ever want to participate in the ACM Programming Contest (we definitely
recommend it!). More information about the contest can be found on http://www.acm.org/~contest .
A report of our experiences at the Contest Finals, including more considerations on team strategy,
can be found athttp://www.cs.vu.nl/~acmteam/.
18
http://www.acm.org/~contesthttp://www.cs.vu.nl/~acmteam/http://www.cs.vu.nl/~acmteam/http://www.acm.org/~contesthttp://www.cs.vu.nl/~acmteam/