U S A C O

Contest Instructions and Rules

Eligibility and Participation

All are welcome to participate in USACO contests and training. All new participants start out in the bronze division, and those who score particularly well in their current division will be promoted to the next division for future contests (promotion criteria varies per contest, since every contest is different). Please use the same login ID for all contests so we can keep track of everyone’s progress. Official results will generally be reported only for high-school (pre-college) students; visitors/observers/”for fun” entries will be scored and reported separately. Only pre-college students in the USA are eligible for selection as finalists to attend the USACO training camp and to contend for membership on the USA IOI team. There is never any fee for participation.

Contest Format

Each contest has typically 3..4 problems to which you will submit solution programs in C, C++, Pascal, Java, or Python. Problems are algorithmic in nature, so clever algorithms and/or data structures might be necessary to solve all test cases correctly and within the time limits. Your score for each problem depends on the number of input cases your program can solve within the time limit (for most contests, 2 seconds per input case for C, C++, and Pascal, and 4 seconds per input case for Java and Python, although the each contest or problem may use slightly different limits). All problem statements are intended to be straightforward, with no intentional “hidden tricks” (however, note that legal but complex datasets are fair game for testing). Problems are intended to be challenging; it is rarely the case that a large number of competitors receive near-perfect scores! The contest is typically 3..4 contiguous hours in length. You can take the contest during any block of time you want, as long as you start during the larger contest window. When you start the contest, your personal timer starts counting down, and you will be able to view the contest problems and submit solutions via this website. When you submit a program, it will be run against a number of juding test cases and for each one, you will receive feedback, shown in a colored box: green for correct, and red for incorrect. Incorrect submissions are further differentiated by the type of problem: X (incorrect answer), T (time limit exceeded), ! (run-time error or memory limit exceeded), E (empty output file), or M (missing output file). If your program fails to compile, you will be shown the error messages from the compiler. The first test case is typically the same as the sample case described in the problem statement, and you need to solve it correctly before you are given feedback on the remaining cases (which are not revealed during the contest, even though you receive feedback on whether you solved them or not). The judges reserve the right to add or remove test cases after the end of the contest, so it is still worthwhile to test your program even if it passes all of the cases during the contest. If you achieve a particularly high score (often required to be a perfect score) during a contest, you may qualify for an “in contest” promotion; otherwise, promotions will be granted after a contest ends to all participants with scores above the promotion threshold for that contest. If you receive an in-contest promotion, you will be able to start working on the next contest any time within the larger contest window, and with a full timer; that is, time you spent on the earlier contest does not count against the time you will have to solve the next contest. The official language of the contest is English, although we try to offer translations of the problem set into several other languages for convenience of our international competitors. If there is every disagreement between translations, the English version should be treated as the official one.

Contest Conduct and Academic Integrity

The USACO believes strongly in academic integrity, and we have adopted strict policies to ensure the integrity of our competitions:
  • Work by yourself, not in a team environment.
  • Consultation about the contest problems with people other than the contest director is prohibited.
  • Do not submit programs you wrote in the past in collaboration with others.
  • We encourage participants not to use code from books or websites, and you should definitely not search for exact solutions on the web or use solutions posted at the USACO or similar sites. If you must look up some piece of code from a book or website (or more generally, anything you did not write from scratch), insert a comment in the code telling the source. The intent of this rule is to allow students to consult general references for small bits of code like how to call standard library functions, read input, format output, etc. Students are not supposed to reproduce large pieces of code (e.g., entire algorithms) that they did not write themselves.
  • Do not use use two login IDs in order to participate in more than one division. Do not use another login ID to read the problems, to circumvent the contest time limits.
  • Do not submit any code that behaves in a malicious way towards the grading machine (i.e., do not try to open network connections, intentially slow down the grading machine, etc.). The judging environment monitors activities and system calls to prevent forbidden actions.
  • Do not distribute code you have written for a contest while the contest is still active.
PARTICIPANTS WHO VIOLATE OF ANY OF THE POLICIES ABOVE WILL BE BANNED FOR LIFE FROM ALL USACO ACTIVITIES. DON’T CHEAT — THERE ARE NO SECOND CHANCES! (And on a practical note, there really is no benefit to you in cheating on a USACO contest; you can learn much more by making an honest attempt at solving the problems!).

General Technical Details

  • Your program must be less than 100,000 bytes in size and must compile in 30 seconds or less. Unless otherwise stated, your programs will be limited to about 256MB of total memory use.
  • Do not submit programs that open data files that aren’t related to the contest task at hand. Read only the specified input files and write only the specified output files. Do not use `temporary’ data files.
  • Unless otherwise stated, programs must be deterministic in nature and produce identical answers each time they are run with identical input(s). Programs that are not deterministic may be disqualified. Note that random-number based programs can still be entered — they should use a fixed seed so they get the same answer each time.
  • Unless otherwise specified, it is NOT guaranteed that all possible legal datasets will be perfectly solvable within the time limit (for example, we might provide a task where near-optimal solutions are expected, and receive partial credit).
  • Although we typically design problems so that numeric answers will fit into a standard 32-bit integer, this is not guaranteed. If larger data types (e.g., 64-bit integers) are necessary, we often make a note of this in the problem statement for your convenience, but it is ultimately your responsibility to realize when these are needed.
  • Programs that consist of essentially nothing more than print statements will be disqualified. If feedback for certain test cases is provided during a contest, you are NOT to submit repeated programs consisting of essentially print statments in order to reverse-engineer the inputs. Programs must actually compute the requested answers, not just print results from a pre-computed lookup table.
  • Progams must not pause and wait for keypresses. For example, if you call system(“pause”) from your code, the grading environment might time out waiting for a non-existant keypress, returning an error like “empty output file”.
  • Headers that were used in past USACO contests (e.g., PROB: and LANG:) are no longer needed. Instead, be sure to select the correct language for your program from the drop-down box when submitting your code.
  • For compiled languages, you do not need to remove all compiler warnings. Compiler errors, of course, will prevent your submission from being judged.
  • All programs read their input from a file named in the problem statement (e.g., `cow.in’). Do not specify a complete path name in your `open’ statement, just `cow.in’. Note that filenames are case-sensitive. If the problem says `cow.in’ then you must use `cow.in’ since `CoW.In’ and ‘COW.IN’ will not work. All programs write their output to a file named in the problem statement (e.g., `cow.out’); do not specify a path name in your `open’ statement, just `cow.out’. Like the input filenames, output filenames are case-sensitive. Output written to stdout or stderr will not be graded.
  • Virtually every program’s output is in the form of “lines”. Since this is a UNIX environment, lines in all input/output files are terminated with a single newline “\n”, rather than a carriage return plus newline “\r\n” (although properly-designed programs generally should not care which convention is being used). If your output does not contain a newline at the end of every line, it may be graded as incorrect. Note that the last line in the input file and output file should also end with a newline “\n” — this is a common source of bugs; if you are testing your code locally, make sure your input files end with “\n” at the end of the last line, particularly if you are using split(“\n”) to separate individual lines in a language like Python. This is perhaps the number one reason for emails we receive saying “it works on my system but not the contest server”.
  • For some of the more advanced problems with larger input sizes, competitors may benefit from using fast input/output, to more easily pass within the time limit. For C++ users, you may want to add “ios_base::sync_with_stdio(false); cin.tie(0);” to the top of your main method if you are using cin/cout. For Java users, you may want to use BufferedReader instead of Scanner.
  • Java-specific: we have recently upgraded to use Java 8 instead of Java 7. One notable difference between the two is the behavior of the string.split method when splitting on an empty string “”, for example if you want to split a string into its individual characters. In Java 7, this would produce an array whose first element was always empty, but not in Java 8. If you re-submit Java code you previously submitted before or on the January 2017 contest, you may therefore see different results due to this change.
  • If, over time, you submit more than one solution for a single problem, only the LAST one submitted will be graded. That means if you find a bug after your submission, you can re-submit. There is no penalty for re-submitting (although please be reasonable with your rate of resubmissions to reduce load on the server). Of course, once your timer has expired, no more solutions can be submitted.
  • The judges reserve the right to increase time limits or add/remove test cases during grading to produce final results.
  • Decision of the judges is final.

Language-Specific Technical Details

  • For C/C++ programmers: Programs are compiled with gcc/g++ 4.8.2 using the “-O2” optimization flag and “-lm” to access the math library, and also “-std=c++0x” to enable support for C++11. Ints are 32 bits in size; use a “long long” if you need a 64-bit integer. To read or write a long long variable with C-style I/O (e.g., scanf, printf), use the “%lld” format string.
  • For Pascal programmers: Programs are compiled with Free Pascal Compiler version 2.6.2 using the “-O2” flag to provide optimization and the “-Sd” flag to specify that ints should be 32 bits in size. If you need a 64-bit int, use the “int64” data type.
  • For Java programmers: Programs are compiled with Java version 1.8.0_121, and executed with the Oracle Java Runtime Environment (note that this was recently upgraded; Java 7 was used for all submissions up to and including the January 2017 contest). You must submit your entire program in one file, and this file must have exactly one public class named the same as the file (for example, if your file is called “MyFile.java”, then it should contain “public class MyFile”). This class needs to have your public static void main function. All other clases in the file should be defined without the “public” tag (e.g., as “class MyOtherClass”). Do not include a “package” line in your source code.
  • For Python programmers: We offer both Python 2.7.6 and Python 3.4.0; please be sure to select the correct version when you submit, since it is often the case that programs developed for one version will not work properly in the other (use “python –version” to check the version of your local Python interpreter). Note also that due to the slower speed of a Python program, it may not be possible to solve the largest test cases for some problems even with the inflated time limit given to Python submissions — consider using a faster language for problems where execution time is critical. Executions are run with the “-O” flag to enable some optimization.