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 do
not want to 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
using 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 is at 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]:
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 be terminated with a “#” symbol while
the judge input terminates with end-of-file.
General Suggestions for Contests
The maximum memory allowed on the Valladolid site is 32MB. This
includes memory for global variables, the heap, and the stack. Even if
you find that you have allocated much less than 64K memory, you will
find that the judge often shows that more memory has been allocated.
Also, you should not allocate 32 MB of global memory because 32MB
is maximum for all types of memory. The maximum memory for real
contests varies; for the World Final, it is greater than 128MB.
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.
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, did not 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.
Problems with DOS Compilers and Memory Allocation
Many of us like to use DOS compilers like Turbo C++ 3.0 and Borland
C++, which do not support allocating more than 64K memory at a time.
It is always a good idea to allocate memory with a constant so that your
test runs use less than 64K memory. Before the submit run, the size of
memory can be increased by just changing the value of the constant. If you
do not practice this, it is very likely that you will face problems like “Run
time error,” “Time limit exceeded,” and “Wrong answer.” An example:
int const SIZE =100;
void initialize (void)
int i, j;
for (i = 0; i < SIZE; i++)
for (j = 0; j < SIZE; j++)
store[i][j] = 0;
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 “Time Limit Exceeded” is Not Always “Time Limit Exceeded”
is incorrect. The input file is in most cases in the current directory. When you submit a program to the judge, the judge gives you a
Errors often occurs because of poor variable type selection or because response, but this response is not always accurate. For example, if you
a runtime error has occurred, but the judge failed to detect it. allocate less memory than is required, the program may not terminate
(it may not even crash), and the judge will tell you “Time limit
exceeded.” On seeing this message, if you try to optimize your program
rather than correcting the memory allocation problem, your program
will never be accepted. The following example illustrates this problem.
The skeleton of your program is as follows:
Presentation errors occur when your program produces correct output
for the judges’ secret data but does not produce it in the correct format. Presentation error is discussed in detail later in this article.