Read the Error Messages, Notes to Teams, and Notes to Sites right now.

Really, read those first. OK, now pass Go and collect $200.

Clarifications and corrections will be posted on the web at the top of the standings pages, so be sure to check the standings regularly, even if you have no scores to enter.

The judges' CD contains one subdirectory for each problem, which includes the description in HTML, the source file, the input and output files, and either an executable program or Java bytecode files. It contains a subdirectory called NOTES that includes the HTML source for these notes. It also contains a subdirectory called JUDGE that includes the version of the judging utilities used in the last several contests. If you do not already have a tried-and-true method for judging, you might want to take a look at them. Instructions are provided in Using the Judging Utilities.

The judge's input and output files in the individual problem directories and the judging utilities are for a Windows environment. The unix subdirectory contains all the input and output files with unix newline '\n' rather than the two character Windows versions. This distinction is important for grading by exact output file matching.

All the textual information on the judges' disk can be viewed through a Web browser by accessing browse.html in the mcpc2004 directory installed by the judging utilities (or on the judges' CD).

Regardless of what judging method you use, remember the following (the included utilities take care of these details for you):

• Remove a team's diskette or write-protect it before judging to ensure that nothing is written to it.
• Always copy a fresh set of correct input and output files before judging a run, because teams' programs have been known to trash files.
• If a program is correct, the team's output file will match the correct output file exactly, i.e., they must be byte-for-byte identical. If the match is not exact, you will have to do a visual inspection to tell whether the problem is a wrong answer or a presentation error.

Each submitted run must be judged by at least two judges. This helps guard against procedural mistakes and ensures some dialog between judges. This is especially critical when choosing between Wrong Answer and Presentation Error, where there can be room for differences of opinion. Presentation errors are ancillary or non-essential mistakes. Sometimes it's easy to categorize presentation errors, sometimes not. For example, consider a program that is supposed to print 3.1415. If it prints 4.23, that is obviously a wrong answer. If it prints 3.14159, then it is a presentation error for printing too many digits. But what about if it prints 3? This could be from not printing enough digits, or it could be because the programmer used integers instead of real numbers, or it could be an incorrect algorithm. These are kinds of issues that require discussion. Unresolved or heavily debated issues should always be presented to the Head Judge, who is the final arbiter.

As in recent contests,

• problem solutions are unique and must be formatted exactly, so output can be judged using a file comparison utility,
• all problems are judged with one test file (which of course will include multiple test cases), and
• all input files have sentinels that signal the end of the input, so it is not necessary for teams to detect end-of-file. (End-of-file handling differs between languages and sometimes between different compilers for the same language. It can cause problems for teams using tools that they're not used to.)

We have some notes about the problem set, including who wrote them and their relative difficulty.

We need fresh ideas. Please submit a problem! See http://csc.smsu.edu/~mcpc/call_for_probs.html.

John Cigas will be your regional contact during the contest. If you have any questions or corrections you can send him email at cigas@acm.org, or if it's an emergency you can phone him at 816-501-4534.