Toph uses Markdown extensively and so does Drafts. To learn more about Markdown and its syntax, read our Markdown guide.
Problem statements should primarily be in English. Translations can then be added for solvers to read the problem in their native or preferred language.
Problem titles must be run through http://www.titlecase.com/ and then tweaked further to account words that make sense in particular letter case only (e.g. XOR, CPU, GIF, etc).
This is the primary content of the problem statement. Go nuts!
While adding images to this, and any other sections of the statement, please keep in mind that not all images found on the Internet are free. Downloading an image from the Internet may not cost you money, but that doesn’t mean we have the right to use it.
Briefly explain the structure of the input file(s). Include constraint details next to the first appearance of each variable name (e.g. $T$
($T < 100$
)). Do not list all constraints at once at the end.
Include any additional notes for the problem solver in this field, e.g. explanation of test cases, links to relevant resources, etc.
Add a Scanspec for your tests to validate inputs automatically.
You can learn more about Scanspec here.
A label can be used to make it easy to identify test cases. It is entirely optional.
Enter the contents of the test case input in the textarea under the Editor tab, or upload a file through the Upload tab.
An input file may not be any larger than 48 MB.
Enter the contents of the test case output in the textarea under the Editor tab, or upload a file through the Upload tab.
An output file may not be any larger than 48 MB.
Tick this checkbox if you want this test case to appear as a part of the problem statement.
It is recommend that you keep sample input/output smaller than 10 KB.
Tick this checkbox if you are preparing this problem for contest with two-phase judging, and the test case belongs to the set for after-contest testing.
Enter a weight for the test case.
It is recommended that you assign a weight of 0 to sample test cases.
Enter the CPU time limit in seconds. Precision up to 2 decimal places is allowed.
Avoid entering a time limit lower than 0.5s as it may severely restrict the ability for others to solve the problem using interpreted or scripting languages.
Enter the memory limit in megabytes.
In case you do not have any specific reason to enter a lower or a higher value, set a memory limit of 512 MB.
Enter the source code length limit in kilobytes.
In case you do not have any specific reason to enter a lower or a higher value, set the source code length limit to 32 kB.
A label can be used to make it easy to identify solutions. It is entirely optional.
Choose the language in which the solution is implemented in.
Enter the contents of the solution source code in the textarea under the Editor tab, or upload a file through the Upload tab.
Explain how the problem may be solved, what algorithms or data structures are necessary, how such algorithms will meet the constraints of the problem, and so on.
The editorial should be comprehensive. Anyone reading the editorial should no longer feel absolutely clueless about the problem - they should have sufficient information to solve the problem or at least know what they have to learn next to be able to solve the problem.
To enter mathematical symbols or equations as LaTeX code, use the the following syntax:
`$ … $`
For example,
`$ A = \pi r^2 $`