CHAPTER 2
GAME PLAN FOR A CONTEST
23
5.
The best times for sorting n elements are O(n log n)
6.
DP algorithms which involves filling in a matrix usually in O(n^3)
7.
In contest, most of the time O(n log n) algorithms will be sufficient.
The art of testing your code
You've done it. Identifying the problem, designing the best possible algorithm, you have
calculate using time/space complexity, that it will be within time and memory limit given.,
and you have code it so well. But, is it 100% correct?
Depends on the programming contest's type, you may or may not get credit by solving the
problem partially. In ACM ICPC, you will only get credit if your team's code solve all the
test cases, that's it, you'll get either Accepted or Not Accepted (Wrong Answer, Time
Limit Exceeded, etc). In IOI, there exist partial credit system, in which you will get score:
number of correct/total number of test cases for each code that you submit.
In either case, you will need to be able to design a good, educated, tricky test cases.
Sample input-output given in problem description is by default too trivial and therefore
not a good way to measure your code's correctness for all input instances.
Rather than wasting your submission (and gaining time or points penalty) by getting
wrong answer, you may want to design some tricky test cases first, test it in your own
machine, and ensure your code is able to solve it correctly (otherwise, there is no point
submitting your solution right?).
Some team coaches sometime ask their students to compete with each other by designing
test cases. If student A's test cases can break other student's code, then A will get bonus
point. You may want to try this in your school team training too.
Here is some guidelines in designing good test cases:
1. Must include sample input, the most trivial one, you even have the answer given.
2. Must include boundary cases, what is the maximum n,x,y, or other input variables, try
varying their values to test for out of bound errors.
3. For multiple input test case, try using two identical test case consecutively. Both must
output the same result. This is to check whether you forgot to initialize some variables,
which will be easily identified if the first instance produce correct output but the second
one doesn't.
4. Increase the size of input. Sometimes your program works for small input size, but
behave wrongly when input size increases.
5. Tricky test cases, analyze the problem description and identify parts that are tricky, test
them to your code.
6. Don't assume input will always nicely formatted if the problem description didn't say