No matching article. Try a shorter search or clear the search.
Input and output
Read the problem's input from standard input and write the answer to standard output. Follow the format in the statement. Do not print prompts, progress messages or debugging text as part of the answer.
For local tests, save the input in a file and redirect it into your program. Redirection supplies the file contents through standard input, just as typing would. You do not need to open a named input file in the program.
Source (online): Kattis input and output
Reading until EOF
Some problems provide a test count or a terminating value. Others end when no input remains. Follow the rule in the statement.
End of file, or EOF, is a condition reported by a read operation. It is not a word to enter in the input. A redirected input file ends automatically. In a terminal, finish your input line with Enter, then press Ctrl+D on an empty line to signal EOF.
Source (online): Kattis end of file
Valid input
The judge's input follows the problem's input specification. Your solution can rely on the stated ranges and structure. Include the boundary values that the statement allows when constructing local tests.
Source (online): Kattis input specification
Testing locally
Use the sample input and expected output from the problem page, then test additional cases. Passing the samples does not prove the solution is correct for every permitted input.
For a C++ file named main.cpp and a sample saved as sample.in, the contest machine provides these commands:
compilecpp main.cpp
runcpp < sample.in > actual.out
diff -u sample.ans actual.out
Save the expected output in sample.ans. Read the Technical Notes for the equivalent commands in the other languages and for IDE build actions. Local runs do not enforce the judge's time and memory limits. A text comparison can help locate differences, but the problem's output rules determine whether an answer is valid.
Source (online): Kattis local testing. Commands are specific to the ACPC image.
How judging works
Kattis first compiles the submission or checks it as required by the chosen language. It then runs the program on test inputs and checks the answers against the problem's rules. Each test run starts a new process, so program variables do not carry over between test files.
The judge enforces resource limits and may stop checking after a failure. A rejection therefore does not describe every possible problem with the submission. Some problems allow several valid answers or a specified numerical tolerance. Read their output requirements carefully.
Source (online): Kattis judging process
Judgements
| Result | Meaning |
| Accepted | The submission passed the required checks. |
| Compile Error | The build or language check failed. Read the compiler output. |
| Run Time Error | The program crashed, raised an uncaught exception or ended with a nonzero exit code. |
| Time Limit Exceeded | A run exceeded the time allowed for a test. |
| Wrong Answer | An answer did not satisfy the output requirements. |
| Output Limit Exceeded | The program produced too much output, possibly because of a loop or debugging prints. |
| Memory Limit Exceeded | The run needed more memory than allowed. Memory exhaustion can also appear as a run time error. |
| Judge Error | The judging system encountered a problem. Ask contest staff. |
Source (online): Kattis judgement list
Investigating a rejection
Read the judgement and any compiler or run feedback available on the submission page. Check the selected language and submitted files, then reproduce the issue locally where possible.
Recheck input parsing, output formatting and the limits in the statement. Test small cases that you can solve by hand, boundary values and cases with different input structures. Remove debugging output before submitting again. Hidden test inputs are generally unavailable, so the samples alone are not a complete test suite.
Sources (online): Rejected submissionsHidden test data
C and C++
Use an int main(...) entry point and finish successful execution with a zero exit status. A nonzero exit status is a run time error even if the printed answer looks correct.
For C++ programs with substantial input or output, stream synchronization and repeated flushing can be expensive. Before any stream I/O, std::ios::sync_with_stdio(false); and std::cin.tie(nullptr); can reduce that overhead. After disabling synchronization, keep input and output within the C++ stream API. Prefer '\n' to std::endl when a flush is unnecessary.
Sources (online): C exit statusC++ exit statusC++ I/O performance
Java main class
The main class is the class containing public static void main(String[] args). Enter its class name, without .java or .class, when Kattis asks for it. If the class belongs to a package, the main class name includes that package.
For the local single-file workflow in the Technical Notes, use a file such as Main.java, a class named Main and no package declaration. Compile with compilejava Main.java and run with runjava Main.
Source (online): Kattis Java main class. Local commands are specific to the ACPC image.
Java input and formatting
Scanner is convenient but may be too slow for large inputs. Buffered reading and writing can reduce I/O overhead. Read the input specification before choosing how to split lines or tokens.
Locale affects formatted numbers. Kattis documents the en_US locale for Java, which uses a decimal point. For predictable local formatting, specify java.util.Locale.US where the formatting API accepts a locale, and follow the problem's requested precision.
Sources (online): Java I/O performanceJava locale
Java exceptions
An uncaught exception normally causes a run time error. Memory exhaustion can be reported as a memory limit error. The feedback available from Kattis may be shorter than the stack trace you see locally.
When reproducing a failure, inspect the local exception and the line where it arose. Check bounds, parsing, null references and memory use against the problem's valid inputs.
Source (online): Kattis Java exceptions
Python 3 and modules
The ACPC Python 3 runtime is PyPy 7.3.23, implementing Python 3.11.15. Use the configured PyPy interpreter or the compilepython3 and runpython3 commands for local tests. CPython and PyPy can differ in performance and some implementation details.
Use the Python standard library available in the contest runtime. Do not assume that a third-party module installed elsewhere will be available on the judge. An import of an unavailable module fails at run time. The local Python 3.11 documentation is available in Language Documentation.
Sources (online): Python implementationPython modules. Version numbers are from the ACPC configuration.