tion is very difficult. Another example is “For a given number find two such equal numbers whose multiplication result will be equal to the given number.” Though the second statement is longer than the first, the second problem statement is only asking to find the square root of a number, which can be done using a built-in function.

 

Use the Assert Function

It is always nice to use the C/C++ assert function, which is in the header file assert.h. With the assert function you can check for a predefined value for a variable or an expression at a certain stage of your program. If for some reason the variable or expression does not have the specified value, assert will print an error message. See your C/C++ documentation for further details.

 

Avoid Recursion

It is almost always a good idea to avoid recursion in programming contests. Recursion takes more time, recursive programs crash more frequently especially in the case of parsing, and, for some people, recursion is harder to debug. But recursion should not be discounted completely, as some problems are very easy to solve recursively (DFS, backtracking), and there are some people who like to think recursively. However, it is a bad habit to solve problems recursively if they can be easily solved iteratively. In live programming contests, there is no point in writing classic code, or code that is compact but often hard to understand and debug. In programming contests, classic code serves only to illustrate the brilliance of the programmer. For example, the code for swapping two values can be written classically as:

 

#define swap(xxx, yyy) (xxx) ^= (yyy) ^= (xxx) ^= (yyy)

But in a contest you will not get extra points for this type of code writing.

 

Improve Your Understanding of Probability and Card Games Having a good understanding of probability is vital to being a good programmer. If you want to measure your grasp of probability, just solve problem 556 of Valladolid and go through a statistics book on probability. Know about probability theorems, independent and dependent events, and heads/tails probability. You should also be able to solve common card game-related problems.

 

Be Careful About Using gets and scanf Together You should also be careful about using gets and scanf in the same program. Test it with the following scenario. The code is:

 

scanf("%s\n", &dummy); gets(name);

And the input file is:

ABCDEF bbbbbXXX

 

What do you get as the value of name? “XXX” or “bbbbbXXX” (Here, “b” means blank or space.)

Suggestions for UNIX-based Online Judges and Contests Function Portability Not all C/C++ functions available in DOS are available in UNIX. Check the documentation for the portability among operating systems. If a function is portable to UNIX, you can use it to solve problems on the Valladolid and USU sites. Use only standard input and output functions for taking inputs and producing outputs.

 

itoa, the Important Function that UNIX Does Not Have UNIX does not support the important function itoa, which converts an integer to a string. The replacement for this function can be:

 

char numstr[100];
int num = 1200;
sprintf(numstr, "%d", num); //to decimal
sprintf(numstr, "%X", num); //to uppercase hexadecimal

 

Try to find replacements for other functions that are not available in UNIX/LINUX.

 

Problems with the Settings of Mailer Programs Some problems do not get accepted even if they are solved correctly. Such problems from Valladolid are 371–Ackermann Function, 336– A node too far, 466–Mirror, mirror, etc. It is because our e-mail programs (e.g., Outlook Express, Eudora) break longer lines, and these problems have long lines in their output. So in Outlook Express you should go to Tools —> Options —> Send —> Send text setting and change the Automatically Wrap Text from 76 (default) to 132. Similar options can be found in other mailer programs. The Ural State University online judge has a program submission form with which you can directly submit your program without sending an e-mail. Remember that problems with mailer settings can cause both wrong answers and compile errors.

 

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.