This page contains information about common errors in past programming
contests, includes some general tips for future contests.
Some of these "tips" might seem unreasonable or impractical at first. But,
they help reduce the amount of "unnecessary" errors. After a little time
they become second nature and will save headaches during contests.
Remember that these tips are for programming contests ONLY. They do
not necessarily represent good programming style.
- Look at all of the problems before you start, and do them in order
of easyness. In a tie situation, the sum of the solution times from start of contest
minus a 15 minute penalty for each wrong submission for those solutions determines the winner..
- See here for team strategy tips.
- You can used this codebook from Stanford if you want. However, you must print it out before you start the contest, and
type in whichever code snippets you need. This is how contests are run.
- Know the details of your IO routines
- This may seem obvious, but it is important. You don't want to spend
what limited time you have during the contest figuring out how to do
IO. What you don't know here will hurt you. Recall that the Java
number formatter added a comma to the number by default. We were
nice in judging this because it should be a learning exercise. But
in a "real" contest the programs would not have been excepted.
- Always use doubles
- OK, don't always use them, but NEVER use floats. Carrying operations
to a higher precision inside a program will never make an answer
wrong, but not using the doubles can cause problems sometimes.
If you always use them you will never have that problem.
- End you output with a newline
- Note: This does not mean put an extra blank line at the end
of your output, it just means that EVERY line your program produces
should end with a '\n'. There are a number of reasons for this, but
the easiest to understand is "You ended every other line in your output
with a newline, what makes the last line any different?"
- Don't use exceptions -- even in Java
- Exceptions are just that, exceptions. They are used when there is a
problem, NOT in the normal course of execution. If, for example, you
are expecting a file to end CHECK FOR IT. Don't let an end of file
exception, or any other side effect exception (like null pointer) get
thrown. Along the same lines, DON'T catch any exceptions. Exceptions are
BAD. They indicate a problem with YOUR code. The judges will guarantee
that all the input is valid, so if you program functions correctly it
should not generate any exceptions. This means if you get a "run-time
error" result back from the judge you know there is a bug with your
code that reads / access the test data, NOT an error in your algorithm.
This also means that when you get a "wrong answer" you know that there is
an error in your algorithm, NOT some other error that threw an exception
that caused the output to be incorrect.
Another motivation for NOT using exceptions is that they introduce many
more paths of execution through your code. And the additional paths
are not always obvious. So if you don't use exceptions you will reduce the
complexity of your code, making it easier to code correctly the first time,
and easier to debug.
- Don't write ANYTHING to standard error
- Assume that the judging scripts will capture BOTH standard out and
standard error. Anything written to standard error will cause your
program to be rejected with a "wrong answer".
- Test your program before you submit it
- Run the version of the program you are about to submit. This helps
you catch problems like not taking out debug code, and provides a
last sanity check. Remember programs that are bounced add 20 minutes
per bounce to your final score.
- Read the problem carefully
- Again this may seem obvious, but there is a lot of important information
that is IMPLIED in the problem statement. It is also possible to skip
over important information because you are racing the clock. Take the
extra minute to read and understand the problem. And then reread it
before you submit your solution to double check.
- Test your solution
- Use more than the sample data. The judges have their own hidden tests
that they use to test your solutions. These hidden tests will test
every legal aspect of the problem, including boundary conditions and large
cases. Remember that the judges data will never be invalid. The sample
data provided in the problem description will not test these boundary
conditions. Test them. If you are working in a team try to have a
person who didn't code up the solution generate the test cases. Usually
a fresh mind sees things differently and can find problems quicker.
- Know one language well
- This is another one that seems obvious, but it is worth mentioning.
Don't spend time figuring out all the languages the contest is offering.
Make sure you know ONE of the well. The judges will guarantee that all
problems are solvable in all languages. Having the ability to "select
the best language for the problem" do not buy you much, unless you
know and are comfortable with all the languages.
Read all the questions before you start solving any of them; we may
have stashed all the easy ones at the end. Tackle the easy ones
first; because of the scoring algorithm, solving easy ones fast and
first gives you an advantage.
Before you submit and after you think you are done, reread the
question carefully and be sure you solved the right problem,
named the files correctly, formatted the output correctly, etc.
Test the boundary conditions. If n can go from 0 to 10000, we will
probably try 0 and 10000 and lots in between.
Don't get stuck on one problem for too long; if you feel you aren't
making progress, try another one.