# Problem Author's Handbook

## Drafts

Drafts is our tool for designing programming problems. It lets you prepare your problem, share it with coauthors and more!

Toph uses Markdown extensively and so does Toph Drafts. To learn more about Markdown and its syntax, read John Gruber’s Markdown syntax reference.

### Known Issues

#### The execution modal keeps showing old data

This happens rarely. However, if it happens please reload the page and execute again.

## Preparing a Problem

### Problem Statements

Problem statements should primarily be in English. Translations can then be added for solvers to read the problem in their native or preferred language.

#### Title

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).

#### Excerpt

Each problem must have a short excerpt (no longer than 140 characters). This excerpt must be relevant to the problem (primarily to its narration). The excerpt is not shown publicly until the problem is added to the archive, but it is still a wise idea to make the excerpt tease and not reveal.

#### Body

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.

#### Input/Output Specification

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)). Avoid listing the constraints all at once at the end. Emphasize each variable name, but not when in equations (e.g. **T**, **T** (T < 100)).

#### Notes

Include any additional notes for the problem solver in this field, e.g. explanation of test cases, links to relevant resources, etc.

### Tests

#### Label

A label can be used to make it easy to identify test cases. It is entirely optional.

#### Input

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.

#### Output

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.

#### Sample

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.

#### Weight

Enter a weight for the test case.

It is recommended that you assign a weight of 0 to sample test cases.

### Checker

#### Comparators

A comparator is used to compare the output file provided as a part of a test case and the output generated by a user submission.

Toph has the following comparators:

• The comparator “Words” compares space separated words. Line breaks and any other white space are all treated the same. Each word can be no longer than 64 kB.

• The comparator “Lines” compares corresponding lines. Line ending characters are all treated the same. Each line can be at most 8 MB long.

• The comparator “Ints” compares space separated integers. Each integer can be if 64 bits (signed).

• The comparators “Floats (1e-4)”, “Floats (1e-6)” and “Floats (1e-8)” compares space separated floating point numbers. The maximum error allowed in comparison is indicated by the fraction in the comparator’s name. Each floating point number can be of double precision.

• The “Custom” comparator can be a program written in any of the supported languages. The program is run with four files in the same directory: answer.txt (the test case output), output.txt (the submission output), input.txt (the test case input) and source.txt (the submission source code). The program must output a single integer: the number of differences found between answer.txt and the expected answer.txt. If the output is 0, the verdict is considered to be “Accepted” for that test case.

### Limits

#### CPU

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.

#### Memory

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.

#### Source

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.

### Solutions

#### Label

A label can be used to make it easy to identify solutions. It is entirely optional.

#### Language

Choose the language in which the solution is implemented in.

#### Source

Enter the contents of the solution source code in the textarea under the Editor tab, or upload a file through the Upload tab.

### Editorials

#### Content

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.

## Math and Equations

To enter mathematical symbols or equations as LaTeX code, use the the following syntax:

$…$


For example,

$A = \pi r^2$