## Contest Instructions and Rules

### Eligibility and Participation

All are welcome to participate in USACO contests and training. 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.

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. Promotions are permanent, even across seasons, so for example once you are promoted from the silver division to gold, you will never again need to take a silver-level contest.

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++, 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 and C++, and 4 seconds per input case for Java and Python, although 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!

Contest are typically 3..5 contiguous hours in length. You can take the contest during any block of time you want within 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 judging 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 perfect score during a contest, you 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 ever 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 share any technical information or code pertaining to a contest while it is actively running.
• The USACO contest environment is meant to mimic the environment at the International Olympiad in Informatics, where all code must be written from scratch, and the only references you may consult are those describing syntax or library functions of your programming language. You may therefore NOT use pre-written code or "templates" to get a head start on your coding, and you may not consult resources other than those that provide information about basic functionality of your programming language (e.g., syntax, library functions, input / output, etc.). (Note that this particular rule has been updated (as of December 2020) to be more clear and slightly more strict than in the past, so do not worry if on past contests you did not adhere to this rule precisely as written above).
• Do not 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. Submission of code must be done via the interface on the usaco.org website (i.e., by selecting your file and clicking "submit solution"); attempts to submit via other means (e.g., scripts that attempt to automate this process) are NOT permitted.

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!). We often follow up on cheating offences by contacting a student's teachers or school principal; expulsions have resulted from this in the past, so know that consequences of cheating may extend beyond just participation in USACO.

### 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. A common source of a "runtime error" that appears on the grading server but not on your local machine at home is allocating too much memory.
• Do not submit programs that open data files that aren't related to the contest task at hand. Read only input files and write only output files that are specified by a problem. 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). On some problems (particularly in higher divisions), it may not be possible to solve all inputs within the requisite running time using Python, due to its slowness. We generally try to ensure that all problems are fully solvable in C/C++/Java, and that all bronze-level problems are also fully-solvable in Python.
• 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 may 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.
• Programs 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-existent keypress, returning an error like "empty output file".
• Headers that were used in past USACO contests and on our training system (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.
• Some programs --- specifically, solutions of most tasks prior to the December 2020 contest --- will read their input from a file named in the problem statement (e.g., cow.in'). If you are using file input, 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. Some 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. If a problem uses file input / output, then output written to stdout or stderr will not be graded. Note that as of the December 2020 contest, input and output switched from file-based to terminal-based, using standard input and standard output (e.g., cin and cout in C++). The input and output spec of a problem will specify which mode is being used.
• 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++ 7.5.0 using the "-O2" optimization flag and "-lm" to access the math library, and "-std=c++11" or "-std=c++17" to enable support for C++11 or C++17. 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 Java programmers: Programs are compiled and executed with the OpenJDK Runtime Environment, version 11.0.10 (we have recently upgraded from Java 8 to Java 11). 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.17 and Python 3.6.9; 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 that due to the slower speed of Python, we cannot always guarantee that it is possible to solve the largest test cases for some problems even with the inflated time limit given to Python submissions (we make our best efforts to design our contests so they are accessible to Python programmers, particularly in the lower divisions, but you may eventually wish to consider learning a faster language once you move up to higher divisions, where running time becomes more critical). Executions are run with the "-O" flag to enable some optimization.
• Note that Pascal support has been discontinued.

### Clarifications, Contacting the Contest Organizers

If you find a problem has poor wording or an ambiguity, you can send email to the contest organizer, Brian Dean (bcdean@clemson.edu), to request clarification; you may receive nothing more than a "read the problem more carefully" response, although important clarifications that have merit will be published on the contest page.

If you send contest email to bcdean@clemson.edu, please make sure the subject contains the word 'USACO', and please be sensible about timezones -- no replies will come until daylight hours in USA Eastern Standard Time (EST).