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

Maximum Memory

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.

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, 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;
int store[SIZE][SIZE];
void initialize (void)
{

int i, j; for (i = 0; i < SIZE; i++)

for (j = 0; j < SIZE; j++) store[i][j] = 0;

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