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.

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.

Additional tips

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.