Suggestions ----------- Before the Contest ------------------ 1) Bring books to the contest. You are allowed to bring any printed materials. So, DO! The books that are most useful are language references (C/C++ for most people), math books (ones with equations like geometric, vector and trig stuff are a good idea), and algorithms books. Also, there is often a problem that requires calculating with big numbers (100 decimal digits or more). It is a good idea to solve +/-/*/div/mod for large numbers and bring the solution with you. Lastly, bring snacks and drinks so you can keep your body in a productive mode throughout the contest (be nice to the computers). You should also bring scratch paper (graph paper is also a good idea), writing tools and highlighters. 2) Learn how to do I/O better than you know how to tie your shoe! I strongly suggest if you are using C -OR- C++ to use these functions for I/O (#include stdio.h and stdlib.h): Input: fgets (and then sscanf sometimes) fscanf Output: fprintf Every problem I have ever seen can be done easily with these three functions. Typically you will only use fgets OR fscanf for a problem. Mixing them can cause subtle errors. If you need both, I suggest fgetsing a line in and then using sscanf on the string. Look these functions up and become fluent with them. Know how they respond to the end of the file. WARNING: DO NOT MIX C++ and C-style IO! You will run into more subtle problems because they use different buffers. (Above is C-style, if you didn't know.) Starting the Contest -------------------- 1) Scan all of the problems before you start. 2) Start with the problem you can get done quickest. Since the score for each finished problem is the time from the beginning of the contest to the problem's completion (plus 20 for each wrong submissions), spending an extra 10 minuets on the first problem adds 10 minutes to every other problem you finish. Remember, the easiest problems can be anywhere in the problem set. 3) As you start that first problem, make a template file with the basic I/O, headers and a shell 'main'. You can then copy this for every problem - speeding you up. During the Contest ------------------ 1) Read the problem slowly and carefully. Note and HIGHLIGHT the key facts and boundary conditions. 2) Test your solution against the sample input and come up with new tests to test ALL boundary conditions you found in 2. If n can go from 0 to 10000, we will certainly test 0 and 10000 and lots in between. Remember, your program is not required to handle invalid input. 3) Just like when you are taking a test, if you are stumped on one, problem, don't hesitate to switch to another one. Don't get stuck on one problem for too long; if you feel you aren't making progress, try another one. One year when our team at nationals was 4 students, two of them spent the entire 5 hours on one problem. They kept saying they were soooooo close, just one more try. They never got it. 4) Always do a detailed verification that your output exactly matches the problem's description. Check spacing, alignment, formatting, spelling, as well as correctness. Remember we will be doing a case-sensitive, byte-for-byte compare! 5) Wrong submissions are costly and experience has shown that most are due to rushing a submission. Always go through the following checklist immediately before you submit: a) Is the source-code filename correct? b) Is its output exactly right? c) Have you tested the sample input with THIS iteration? d) Have you tested the boundary conditions with THIS iteration? e) Is the input coming from the right place? output going to the right place? For the Next Contest: Regionals ------------------------------- 1) Teamwork. You guys haven't had to deal with this yet, but at the regionals, you have a team of 3 solving the problems. The difficulty is that you only get one computer (and you cannot bring your own to the contest). So, sharing the keyboard becomes a major issue. Practice solving problems on paper so that when you get the keyboard all you have to do is type it up. Also practice debugging on paper so that you can find your bugs while someone else types up another problem (you are allowed you print out your code during the contest). A general rule of thumb is that if you can't find the bug in 5 minutes at the keyboard, give up the keyboard to someone else (if someone is ready). Share problems. In general, one person works on one problem. However, if your solution didn't work, let someone else either read your code or implement their own solution. There is no pride within the group -- the only thing that matters is getting the problems done. 2) All my suggestions above are things you guys can use for the next contest. In the long-run, though, pick up an algorithms book and read it. Once you have I/O down (and a few other logistics), you are only limited by the algorithms you know.