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.
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:
And the input file is:
What do you get as the value of name? “XXX” or “bbbbbXXX” (Here,
“b” means blank or space.)
Suggestions for UNIX-based Online Judges
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:
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
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 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.