Originally written Tue Oct 30 08:46:23 CDT 2012
Last edited Mon Mar 23 14:49:34 CDT 2015

Greg Hamerly

Here are basic guidelines for writing good ICPC-style problems. Everyone who
writes problems has a different style, but these are the guidelines I recommend.
I've written over 200 problems over the last decade, several dozen of which have
been used for national-level and international-level competitions. I've learned
these guidelines by trial-and-error and feedback from other experts, and I am
still learning to be a better writer. Writing a problem is in many ways just
like any other type of writing, and the more you do it the better you will be.


1. The basic format is almost always the same:
    - catchy title
    - description of the problem (catchy but precise)
    - technical description of the input format
    - technical description of the output format
    - sample input
    - sample output

2. Simple things like correct spelling, correct grammar, and appropriate voice
are important. A common problem I see is voice inconsistency, e.g. switching
between past, present, and future tenses. Avoid passive voice.

3. All technical terms should be well defined. For example, if asked to find the
"best" or "optimal" solution, make sure it is clear exactly which value is
being optimized.

4. Beware of shifting technical terms. For example, don't call something a
"node" in one place and a "vertex" in another. Be consistent and stick with one
term.

5. Watch out for ambiguity and imprecision, which often comes from assuming the
reader thinks like you do. Do not assume that the way you are thinking about a
definition is "obviously the right way" to think about it.  Consider what you
may be assuming without knowing it.

The best way to find ambiguities in a problem is to try to "break your problem".
Read it with a critical eye, thinking about any way that your problem could be
(validly) misunderstood. Seek feedback from others.

6. Place reasonable limits on all variables introduced, including the number of
test cases (even if the number of cases is not explicitly given as part of the
input). Place those limits as close to the definition of the variable as
possible (e.g. "Input consists of $1 < n < 1000$ test cases...").

7. A problem should read naturally. Structure the description so that
definitions build on one another.

8. A personal preference is to define as much of the problem in the first
section (before the input description), leaving the input/output descriptions as
merely technical definitions. Thus, you can understand almost everything about
the problem from its description. Other authors like to put some of the
problem's key details in the input or output descriptions.

9. The sample input and output should demonstrate a variety of test cases.

10. The description should stand on its own, and not leave any "surprises" to
the sample input and output. However, there may be times when the sample input
and output can be used to clarify a minor point that may be omitted from the
description. 

For example, if the output requires something like "X buckets are full", it
might be ambiguous if X=1 whether the output should be "1 bucket is full"
(grammatically correct but inconsistent than the output description) or "1
buckets are full" (grammatically incorrect but consistent with the output
description). If the description doesn't differentiate, the reader could
reasonably assume that the grammatically-incorrect-but-consistent interpretation
is the right one, and the sample input/output could clarify that. However, if
the pattern should change depending on the value of X, then it would be (too)
surprising to learn about this in the sample output; this should be specified
precisely in the problem description.

11. Figures help make problems more understandable. When making a figure, it's
good to make it reflect the sample input and output.


Miscellaneous thoughts:
    - Programs should read form standard input and write to standard output, but
      this is not necessary to specify in the problem statement.


Here are some examples of text that often occur in my problem writing (useful
when you're stuck on how to decsribe something precisely but concisely):
    - "Input ends at end of file."
    - "A blank line appears between each pair of adjacent test cases."