Problem Setting

Preparation Before Problem Setting

Possess a Certain Level of Skill

On one hand, it is difficult for an individual to create problems that are more challenging than their own skill level. A certain level of OI proficiency helps in generating better ideas and devising excellent solutions. On the other hand, OI skill level to some extent represents OI experience. Contestants who have seen more problems will also have their own insights into what constitutes a "good problem."

Maintain a Serious and Responsible Attitude

Setting problems is for others to solve. Rather than showcasing oneself, it is more about serving others. Algorithm competitions are contests among participants, not battles between problem setters and solvers. Therefore, the goal of problem setting should not be to stump contestants (although appropriate anti-AK measures and good differentiation are also very important). Instead, it should allow contestants to gain something from the competition. Spending sufficient time and effort to learn how to set problems and doing so responsibly is crucial.

Be Prepared to Invest a Significant Amount of Time

If you want to set problems seriously, it will inevitably require a lot of time. Without proper mental preparation, you may rush through contest preparation, resulting in subpar quality, or later regret not spending that time on studying. However, problem setting can also bring many wonderful memories. If you are truly interested in problem setting and are fully mentally prepared, the gains from setting problems can compensate for the time spent.

Read the Content of This Article Carefully

This article introduces the entire problem-setting process from two aspects: how to set problems and how to set good problems. For those who want to set problems, reading this article carefully will undoubtedly be highly beneficial.

Problem Content

When creating a problem, the idea—the essential content of the problem—is its soul and the first step in problem setting.

Sources of Ideas

1. Inspired by existing problems (but do not copy or meaninglessly strengthen them, e.g., moving a sequence problem to a cactus).
2. Inspired by learned knowledge points (but do not arbitrarily combine unrelated knowledge points).
3. Inspired by life/games (but be careful not to turn the game into a large simulation).
4. For no particular reason, you just thought of a problem.

What Kind of Ideas Are Bad

Regarding Original Problems

Original problems can be roughly divided into three types: completely identical, almost identical, and solution-identical.

• Completely identical: The AC code for one problem can AC another problem.
• Almost identical: Modifying the AC code of one problem to AC another can be done by someone who does not know the solution to that problem.
• Solution-identical: The core ideas and solutions are the same, but there are differences in code implementation and less critical details.

These three types of original problems are inclusive from bottom to top.

The following situations should not occur:

1. Setting an original problem while knowingly aware of an "almost identical" original problem.
2. Due to not using a search engine to check, being unaware of an original problem and thus setting an "almost identical" original problem.
3. Setting an original problem when a "solution-identical" original problem is widely known (e.g., NOIP, NOI original problems).
4. Including a "solution-identical" original problem in a non-giveaway problem in a selective exam.

The following situations are best avoided:

1. Setting an original problem while knowingly aware of at least a "solution-identical" original problem.
2. Due to not using a search engine to check, being unaware of an original problem and thus setting a "solution-identical" original problem.
3. Setting an "almost identical" original problem under any circumstances.

Exceptions where requirements can be relaxed:

1. School mock contests.
2. Mock contests aimed at thematic training.
3. Lower-difficulty contests or problems positioned as giveaways.

Regarding "Toxic" Problems

"Toxic problem" is a very vague and subjective concept. Here, we only cite some previous discussions on this topic, along with some personal understanding. This topic is very open, and everyone is welcome to express their views.

A good problem should not be two problems pieced together; a good problem should have its own idea—and it should highlight this idea without excessive packaging.

A good problem should be novel. A truly good problem should inspire new good problems.

——[vfk《The Origin and Flow of UOJ Spirit》][1]

Example: 「XR-1」Conan Family. The two parts of the solution are completely disjoint. The first part is 「Template」Tree Suffix Sorting, and the second part is a classic tree problem. Even if the tree's node weights are input arbitrarily, the second part can still be done; there is no connection between the two parts.

A class of OI problems is primarily mathematical. Both the problem description and the solution have the characteristics of a math problem, and the solution does not contain algorithm-related knowledge points. Such OI problems are collectively called pure math problems.

——[Wang Tianyi《On the Harm of Off-Topic Problems》][2]

Classic example: NOIP2017 Little Kai's Puzzle

The difference between math problems in OI and other math problems, which also reflects the essence of OI, is that the focus of math problems in OI is often not on what the answer is, but on how to speed up the calculation of the answer. If a problem's focus is on "how to compute" rather than "how to compute quickly," such a math problem is generally unsuitable for OI.

Some off-topic problems involve university physics content, causing contestants to become不知所措 when facing these unfamiliar physics knowledge points, creating a knowledge barrier.

——[Wang Tianyi《On the Harm of Off-Topic Problems》][2]

Classic example: 「Tsinghua Training 2015」Polygon Goes to Sea

Not just physics; OI problems should not involve too much knowledge from other disciplines. If involved, detailed explanations should be given, and knowledge from other disciplines should not become a major obstacle to solving the problem.

A good problem, regardless of its difficulty, should have its own thinking difficulty, requiring contestants to think and discover some properties.

The code for a good problem can be long, but it should not be artificially lengthened by forced nesting or added conditions. It should feel natural, as if the code for this problem should be this long.

——[Wang Tianyi《On the Harm of Off-Topic Problems》][2]

Classic examples: 「SDOI2010」Pig Country Kill, 「Training Team Mutual Test 2015」Future Program·Modified

In general OI contests, thinking difficulty should be the main component. Of course, engineering problems like those in THUWC/THUSC Day 2+ also have their reasons for existing—after all, the purpose of experience camps is not only to test contestants' algorithm design abilities but also their engineering code and documentation learning abilities aligned with university studies. However, in general OI contests, what is tested more should still be algorithm design and thinking abilities.

Problem Statement

Use LaTeX to Write Formulas

There are many LaTeX tutorials online, such as:

• LaTeX Introduction
• LaTeX Mathematical Formula Encyclopedia
• LaTeX Various Commands, Symbols

Please note the LaTeX Formula Format Requirements when using.

Problem Background

The problem background should be as brief as possible. When the background is long, it should be separated from the problem description.

Absolutely avoid having the background severely affect the understanding of the problem.

If necessary, provide two versions: one with the background integrated into the description and one with a concise problem description.

Problem Description

In short, the problem description needs to be clear and easy to understand.

Every definition in the statement that may not be understood should be explained. Do not introduce undefined concepts out of thin air. For example, in CF1172D Nauuo and Portals, you must explain what a "portal" is in the statement.

Each concept involved in the statement should be described using a single term. For example, do not say "cost" at one point and "price" at another.

Do not use vocabulary with meanings different from the original or common meaning without explanation. For example, do not use "path" to refer to an edge without explanation.

You need to ensure that your statement does not contradict itself. For example, in CF1173A Nauuo and Votes, "?" is not treated as a "result" because the meaning of "?" is "there are more than one possible results."

You need to ensure that your statement cannot be misinterpreted in a way that is self-consistent, even if that interpretation is counterintuitive and no one would think of it. For example, in CF1172D Nauuo and Portals, the繁琐 definition of "walk into" and its distinction from "teleport" is to prevent the interpretation: you can go to another portal through a portal, and arriving at a portal triggers teleportation, causing反复横跳.

Reading the problem description sequentially should allow understanding each sentence and the task and requirements of the problem. At least in the immediately following paragraph,疑惑 should be resolved, rather than needing several paragraphs for explanation, or having to look at the input/output format to understand the problem, or even needing to guess the problem from samples. For example, in 「GuOJ Round #1」Cirno's Ice and Snow Banquet, the problem's goal "the maximum amount of water the Misty Lake can finally receive" first appears in the output format. Coupled with the misleading sentence "Reimu can quickly calculate the total cost of clearing all streams," it is easier to misinterpret the problem. This is unacceptable; the problem's goal should be explained in the problem description. (This example also has the issue of the background severely affecting problem understanding.) The same mistake appears in CF1423(4)N Bubblesquare Tokens, where the problem's goal "friend pairs and number of tokens each of them gets on behalf of their friendship" first appears in the output format.

Input/Output Format

The input/output format should be clear and complete. There are no rigid requirements; it is recommended to refer to CF problems for writing input/output formats. Specifically, you can refer to [CF Problem Setter Guide][3].

To facilitate contestants, it is best to explain the specific meaning of each variable in the input/output format, unless the variable's meaning is very long and cannot be explained in one sentence (in which case you can say "see problem description for meaning").

It is particularly important to note that if the output contains decimals, try to use SPJ to limit the error size, rather than requiring "保留 x 位小数" (keep x decimal places).

"保留 x 位小数" (keep x decimal places) may impose infinite precision requirements. For example, if要求保留三位小数 (keep three decimal places) and the actual answer is \(0.0015\), any error causing the computed answer to be less than \(0.0015\), even if the computed answer is \(0.00149999\cdots\), will output the wrong answer.

If SPJ cannot be used, ensure that the precision requirement is finite. For example: Please output the answer rounded to three decimal places. Let the standard answer be \(ans\). It is guaranteed that for any \(x\) satisfying \(\frac{|x-ans|}{\max(1,ans)}<10^{-9}\), the rounded result is the same as the rounded \(ans\).

Some example sentences for reference:

The first line of input contains three positive integers $n$, $m$, $k$ ($1\le n,m\le 2\cdot 10^5$, $1\le k\le 100$) — $n$ denotes the length of the sequence, $m$ denotes the number of operations, and the meaning of $k$ is described in the problem statement.

The second line of input contains $n$ non-negative integers $a_1,a_2,\ldots,a_n$ ($1\le a_i\le 10^9$) — the sequence given in the problem.

The $i$-th of the next $m$ lines contains two positive integers $l_i$ and $r_i$ ($1\le l_i\le r_i\le n$), indicating that the $i$-th operation is performed on the interval $[l_i,r_i]$.

The next $n-1$ lines each contain two positive integers $u$ and $v$ ($1\le u,v\le n$), indicating that there is an edge between $u$ and $v$.

It is guaranteed that the given edges form a tree.

The only line of input contains a non-empty string consisting of lowercase English letters, with length not exceeding $10^6$.

The second line of input contains a real number $x$ with at most three digits after the decimal point ($-10^6\le x\le 10^6$), as described in the problem statement.

Output a real number. Your answer is considered correct if the absolute or relative error between your output and the standard answer is less than $10^{-6}$.

The second line of output contains $n$ positive integers, representing the set of cards you play — the $i$-th number denotes the index of the $i$-th card you play.

If there are multiple valid answers, you may output any one of them.

Generating Input Data via Random Number Generator in Contestant's Code

Some problems may have overly large input data. To prevent long read times, contestants may be required to generate data within their code using a given data generator, instead of reading from standard input or files.

This approach should be considered carefully due to many drawbacks:

• It may introduce data randomness not needed by the correct solution or make constructing data difficult.
• It may increase the difficulty of understanding the input format.
• If the random number generator is poorly encapsulated, understanding how to use the data generator itself may be difficult.
• If contestants do not use the recommended language, they may need to write their own data generator.

This approach is generally used to prevent long read times. A possible alternative is to provide a sufficiently efficient I/O optimization template to ensure consistent read times for everyone, so even if read times are long, it won't affect the time difference between contestants. Another solution is to package the problem as a function-call-style (rather than IO-style) interactive problem. Even if there is no interaction during the algorithm, interactive problems can unify read times. IOI adopts the approach where all problems are interactive. However, both alternatives restrict the languages contestants can use, requiring the problem setter to manually support each allowed language.

Returning to the root of the problem, consider whether overly large input data is necessary, whether smaller input data can achieve the purpose, and whether it is necessary to卡掉 (block) solutions with slightly worse complexity than the intended solution.

Data Range

According to CF requirements, data ranges should be written in the input format. However, in China, data ranges are often written at the end of the problem.

The most common mistake in data ranges is incompleteness. Every number and every string in the input should have a clear definition. Some correct ways to write data ranges are given in the input/output format examples above.

Common omissions in data ranges:

1. The "整" in "整数" (integer).
2. The problem statement only says "整数" (integer) but not "正整数" (positive integer), and the data range only has an upper bound but no lower bound.
3. Strings do not specify the character set.
4. Real numbers do not specify the number of decimal places.
5. Some variables are not given ranges.

You need to ensure that the standard solution can pass any set of data satisfying the data range described in the problem statement.

About 'Guaranteed Randomly Generated Data'

Some problems "guarantee randomly generated data." Often, such restrictions are not the optimal solution because "randomly generated" does not clearly restrict the data, making it difficult to determine specific data ranges and provide hack data.

Generally, "guaranteed randomly generated data" can be replaced with the data properties required by the solution. For example, randomly generating a tree can often be replaced with limiting the tree's height.

If data must be randomly generated, specify the exact random generation operation. For example, whether generating a tree randomly selects parent nodes or randomly generates a Prüfer sequence.

Note that non-deterministic algorithms and algorithms relying on data randomness are different. The former has a high probability of obtaining the correct solution for any data, while the latter obtains the correct solution for most data but cannot obtain the correct solution for certain specific data.

Samples

Samples should have some strength to detect simple errors. Those who misread the problem should be able to discover their mistake through samples.

For problems with multiple operations, each operation should appear in samples.

For problems with multiple types of output (e.g., CF1173A Nauuo and Votes), each type of output should appear in samples. Exception: Problems that实际上不可能无解 (are actually impossible to have no solution) but require judging whether a solution exists.

Sample Explanation

The more complex and harder to understand the problem description, the more detailed the sample explanation should be.

The simpler the problem difficulty, the more detailed the sample explanation should be.

Detailed sample explanations can include pictures.

Larger samples may not need sample explanations.

To accommodate those with color vision deficiencies, avoid making color essential for understanding the sample explanation. Colored images can be used to beautify sample explanations, but if color must convey necessary information, avoid同时出现红黄或者红绿 (simultaneously出现红黄或者红绿).

Time Limit, Memory Limit, and Partial Scores

The purpose of time and memory limits is to block solutions with incorrect complexity. (Of course, also to prevent excessively long judging times, e.g., interactive problems with only interaction count limits but no time complexity limits also have time limits.)

Therefore, in principle, the time limit should be set as large as possible without allowing incorrect solutions to pass.

Generally, the time limit should meet the following requirements:

1. At least twice the worst-case runtime of the standard solution.
2. If the contest allows Java, ensure Java can pass.
3. Should not allow incorrect solutions to pass (except when实在卡不掉 (really cannot block) or intentionally allowing certain incorrect solutions).

To better allow solutions with large constants to pass while blocking incorrect solutions, generally increase both data range and time limit simultaneously. However, note that sometimes the correct solution (due to caching or other玄学问题) may have a significant constant increase when data range increases. In such cases, increasing data range may not necessarily increase the runtime gap between correct and incorrect solutions.

In contests with partial scores, you can also set梯度数据 (gradient data) and data with slightly smaller ranges to prevent relatively good incorrect solutions and large-constant correct solutions from passing, while allowing them to obtain higher partial scores.

Note that when data range is less than \(5\cdot 10^5\), consider whether instruction sets can be used to pass.

Generally, memory limits should be set large enough, unless the space-optimal solution is indeed very clever and worth blocking space-inefficient solutions. In such cases, consider setting looser memory limits for partial scores. Notably, if you do not want to block space-consuming solutions, data structure problems generally require larger memory limits.

A good problem should have its selective nature and sufficient differentiation. There should be at least 4 tiers of partial scores, allowing beginners to get some points and experts to demonstrate their abilities.

——vfk《The Origin and Flow of UOJ Spirit》

Partial scores are generally divided into smaller data ranges and special properties.

Smaller data ranges should generally have multiple tiers. Even if you cannot think of a solution with a certain complexity, consider giving a tier for that complexity. Generally, to avoid卡常 (constant optimization blocking), you can set a tier with data size half of the极限数据 (maximum data).

"数据有梯度" (data has gradient) is best replaced with multiple tiers of partial scores.

Setting special property partial scores depends on the specific problem. Ideal special property partial scores should guide contestants toward thinking about the correct solution. Unlike smaller data range partial scores, if you do not know a solution for a certain special property, it is best not to give a tier for that property. For example, the \(k=1\) partial score in 「CTS2019」Random Cube was criticized by many during the solution discussion, saying it hindered thinking about the correct solution.

If the scoring method differs from the default (e.g.,绑 subtask 测试 (binding subtask testing) in general OI-style contests), it must be stated in the problem statement.

It is not recommended to use phrases like "百分之 XX 的数据满足 XX" (XX% of the data satisfies XX), especially when there are multiple variables in the data range. For example, "\(30\%\) 的数据满足 \(n \le 1000\)" and "\(40\%\) 的数据满足 \(m \le 100\)" may describe the properties of \(70\%\) of the data or only \(40\%\) of the data. Generally, subtasks or data range tables are better choices.

Generating Data

Data generation is a necessary step in problem setting and is also required for对拍 (stress testing). Mastering some data generation techniques can make the data generation process easier and produce stronger data.

Generating Random Data

Generating Random Numbers

Refer to the Random Functions page.

It is特别提醒 (especially reminded) that when generating numbers with a range larger than the random function's return value, please do not use rand() * rand() or similar写法 (writing), as such methods produce very uneven random numbers.

Additionally, it is recommended to use testlib for data generation when setting problems. It ensures that the same seed generates the same random numbers across different platforms, and seeds are automatically generated based on command-line arguments.

Generating Random Permutations

You can use the std::shuffle function from STL, like std::shuffle(a, a + n, rng), where rng is a random number generator, e.g., std::mt19937 rng(std::chrono::steady_clock::now().time_since_epoch().count()).

Please do not use std::random_shuffle. It was deprecated in C++14 and removed in C++17.

Generating Random Intervals

Common incorrect method: Randomly generate left endpoint \(l\) in \([1,n]\), then randomly generate right endpoint \(r\) in \([l, n]\). This tends to generate intervals偏向右边 (biased to the right).

More correct method (recommended): Generate two numbers randomly in \([1, n]\), take the smaller as the left endpoint and the larger as the right endpoint.

Truly uniformly random method: Generate a random number \(x\) in \([0, n]\). If \(x = 0\), generate another random number \(y\) in \([1, n]\), and the interval is \([y, y]\); otherwise, generate using the "more correct method."

Generating Random Trees

Common method: For each node \(i\) from \(2\sim n\), randomly choose a father from \([1,i-1]\). This does not generate uniformly random trees; the expected height is \(O(\log n)\).

Another random method: Randomly choose \(i\)'s father from \([i\cdot low, i\cdot high]\). If \(low\) and \(high\) are set appropriately, strong trees can be generated.

Truly uniformly random method uses Prüfer sequence. First generate a random Prüfer sequence, then generate the tree from the sequence. This yields trees with expected height \(O(\sqrt n)\).

Additionally, you can randomize a permutation to renumber nodes/shuffle edge order.

Constructing Data

Problems Related to Intervals

Common constructions: Very small lengths (especially all single points), very large lengths (especially the entire sequence).

Problems Requiring Factorization

Maximize the number of repeated prime factors: powers of \(2\).

Maximize the number of distinct prime factors: product of the smallest several primes.

Maximize the number of divisors: refer to sequence A002182 on OEIS.

Tree Problems

Common constructions:

• Chain
• Star (菊花)
• Complete binary tree
• Replace each node of a complete binary tree with a chain of length \(\sqrt n\)
• A chain attached to a star
• A chain with some single points attached
• A tree of height \(d\) with \(d>1\), where the root has two children: the left subtree is a chain of length \(d-1\), and the right subtree is a tree of height \(d-1\) of this form.

If not in a contest, you can also use Tree-Generator to generate various trees.

Batch Data Generation

The author recommends using command-line arguments + bat/sh scripts.

Example:

gen.cpp:

#include "testlib.h"

using namespace std;

int n, m, k;
vector<int> p;

int main(int argc, char* argv[]) {
  registerGen(argc, argv, 1);

  int i;

  n = atoi(argv[1]);
  m = atoi(argv[2]);
  k = rnd.next(1, n);

  for (i = 1; i <= n; ++i) p.push_back(i);

  shuffle(p.begin(), p.end());
  // Use rnd.next() for shuffling

  printf("%d %d %d\n", n, m, k);
  for (i = 0; i < n; ++i) {
    printf("%d%c", p[i], " \n"[i == n - 1]);
    // Using string as array, space in between, newline at end, is a common technique when generating data.
  }

  return 0;
}

gen_scripts.bat:

gen 10 10 > 1.in
gen 1 1 > 2.in
gen 100 200 > 3.in
gen 2000 1000 > 4.in
gen 100000 100000 > 5.in

The advantage is that for different data, you only need to write one generator and can easily modify parameters for specific test points.

Requirements for Data Generation

Data should include the minimum and maximum values of each parameter.

Data should cover various corner cases.

When using subtasks, data (including input and output) should最好覆盖到值域中的各个范围 (cover various ranges within the value domain), not just the maximum of the data range.

To prevent special-case判过 (judging as correct) via特判 (special handling), combine different constructions within one test point, or have most data constructed with a small portion random.

Data should contain various constructions, even if you do not know what incorrect solution might fail on such constructions. (In contests with per-test-point scoring, handle酌情处理.)

Of course, if you know a (reasonably thinkable and writable) incorrect solution with correctness issues, try to卡掉它 (block it).

特别提醒 (Special reminder): If integer overflow is possible,一定要卡掉会溢出的做法 (must block solutions that overflow). In contests with partial scores, those not using long long should not get the same or lower scores than brute force.

If there are pretests, pretests should be as strong as possible (while尽量少 (as few as possible)). In other words, you need to include all known叉点 (hack points) of the problem in pretests (with as few test cases as possible).

If you expect a small but non-zero number of FSTs, still ensure pretest strength, because actual contests may have unexpected errors leading to far more FSTs than anticipated.

Data Format

Here are some general requirements for input data format,可作为一般情况下的参考 (can be used as reference in general cases):

1. Use the newline format of the testing environment.
2. The last line of the file ends with a newline, i.e., the last character of the entire file should be \n.
3. No whitespace at the beginning or end of any line.
4. No more than 1 consecutive space.

Data generated in Windows environment typically have newline format \r\n, while mainstream judging systems run in Linux environment with newline format \n. Reading Windows-format newline data in Linux may cause newline handling issues when reading strings, leading to different program behavior across environments. Comparing output generated in Linux with standard output generated in Windows in Linux may cause differences due to different newline formats. To maintain consistent program behavior, all data's newline format must be converted to the program's runtime environment newline format.

Generally, Linux-format newline data can be generated as follows:

1. Generate data directly in Linux environment.
2. Convert input/output files using dos2unix tool, included in toolchains like Cygwin, MinGW.
3. Open output file in binary mode and use \n newline format.
4. Refer to dos2unix.cpp code on this page to write your own tool.

Special Judge

SPJ Writing Tutorial

Problems requiring outputting a solution and outputting floating-point numbers are two common types requiring SPJ. Other problems may also need SPJ depending on the situation. On CF, all problems must use testlib-based checkers. For example, when the problem requires outputting several integers, use testlib's built-in ncmp checker. Contestants can output任意空白字符 (any whitespace characters) (spaces or newlines).

Checkers are generally written using testlib. Since checkers must handle various illegal outputs and require极强的鲁棒性 (extremely strong robustness), it is difficult to write a good checker without testlib.

When writing a checker, note the following:

1. You need to handle various illegal outputs. Therefore, check whether each variable read is within the legal range (readInt(minvalue, maxvalue)). For example, when reading a variable that will be used as an array index during checking, its range must be checked; otherwise, it may cause array out-of-bounds, sometimes leading to RE, sometimes判为 AC (judged as AC).
2. In principle, checkers should not check whitespace characters (i.e., should not use readSpace(), readEoln(), readEof()). Notably, testlib automatically checks for多余输出 (extra output).

Solution

The goal of the solution is to be understandable by those expected to participate in the contest. Therefore, official solutions require more detail than general solutions.

Regarding Partial Scores

In problems with partial scores, the solution can consider writing about partial score approaches.

Regarding Knowledge Points

Knowledge points used in the solution should be clearly indicated. For knowledge points with difficulty comparable to the problem difficulty, it is best to provide learning materials (e.g., a blog address).

Regarding Definitions

Do not introduce concepts out of thin air in the solution.

For example, dp solutions should clearly explain state definitions.

Regarding Details

Specific implementation details, if clever, are best written out. Otherwise, "详见代码" (see code for details) is acceptable. If "详见代码," it is best to add some comments in the code.

Standard Solution

Redundant parts should最好去掉 (best removed) from the standard solution. For example, some solutions retain complete define templates (to speed up problem-solving, containing many defines and common functions, often used in online contests like CF), and a large part is unused, which is not good.

If涉及 (involve) implementation details not详细说明 (explained in detail) in the solution, add适量注释 (appropriate comments).

Contest

Problem Difficulty in Contest Announcement Should Be Realistic

Remember that authors tend to underestimate the difficulty of their problems.

——Reminder on Codeforces PROPOSE A PROBLEM page

Problem setters may misestimate problem difficulty. Therefore, if stating contest difficulty in the announcement, consider carefully,最好提前请人来验题并进行评估 (best ask someone to test and evaluate in advance).

Distribution of Problem Difficulty

In OI-style mock contests, often the overall difficulty of three problems should match the contest difficulty.

In online contests like CF/ATC, try to ensure increasing difficulty (although due to misestimation, this often cannot be truly achieved) and avoid large difficulty gaps. You can reduce difficulty gaps by splitting a problem into easy and hard versions (two subtasks), but splitting subtasks needs careful consideration. Many dislike subtasks in CF-style contests (Are subtasks evil?), reasons include but are not limited to:

• Due to contest rules, doing easy version then hard version may yield less penalty and higher total score.
• Subtask scoring often does not proportional to problem difficulty.
• Often easy version problems are not合格题目 (qualified problems) (not interesting).
• Often easy version solutions do not help思考 hard version 的正解 (thinking about the correct solution for hard version).

Distribution of Problem Knowledge Points

A contest should尽量涵盖较广的知识点 (cover a wide range of knowledge points) (except thematic training contests).

Classic counterexample: CTS2019, covering dynamic programming, expectation, combinatorics, inclusion-exclusion, polynomials, etc.

I have to choose six problems from five, I'm helpless too.

——Reason given by CTS2019 problem selection team, not enough problem submissions received.

Problem Setting Platforms

Polygon

Polygon is a very powerful collaborative problem-setting platform. It can be the首选方案 (first choice) for多人合作出题 (collaborative problem setting) on any website (using package function to export to websites not supporting Polygon). It is also a good choice for单人出题 (individual problem setting) (especially on different devices). Usage参见 (see) Polygon Introduction.

Codeforces

Codeforces is one of the world's most famous algorithm contest websites, with high problem quality,非常适合 (very suitable) for problem setters with some experience wanting to further improve and create high-quality problem sets. The drawback is slow review speed (usually several months), but you can start preparing problems during review (though there is risk of rejection wasting preparation).

Problem Setting Qualification

• Blue rating and participated in at least 25 rated contests;
• Purple rating and participated in at least 15 rated contests;
• Orange rating and participated in at least 5 rated contests;
• Red or black-red rating.

Submitting Contest Proposal

After having qualification, you can see the Propose a contest/problems button in the sidebar.

After clicking, first write a contest proposal (in PROPOSE A CONTEST), then write problem proposals and add them to the contest.

After deciding on problems, you can open the contest proposal to review (submit for review).

Preparing Problems on Polygon

Refer to Polygon Introduction.

Contact with Coordinators

Contact with coordinators has two purposes:

1. Speed up review.
2. After entering preparation phase, coordinators provide suggestions and help.

The正规的联系方式 (formal contact method) is submitting a proposal in the proposal system. After coordinators start review, discuss via comments below the proposal.

Actually, if a proposal is not reviewed for a long time, consider私信联系管理 (private messaging coordinators) (though CF states "Don't send private messages or emails to coordinators," 300iq indicated in a comment that you can私信他 (private message him)).

Comet OJ

Comet OJ Link

No longer active (as of November 2021, last contest was January 2020).

Problem setting application: https://info.cometoj.com/contests/Questionnaire_IssuerInfo/

CodeChef

Indian algorithm contest platform with three contest types: 10-day Long Challenge with challenge phase, 2.5h ICPC-style Cook-Off, 3h IOI-style LunchTime.

Problem setting FAQ: https://www.codechef.com/wiki/faq-problem-setters

Problem setting guide: https://www.codechef.com/problemsetting

AtCoder

Japanese algorithm contest platform. Contact for problem setting: contest@atcoder.jp.

---

本页面最近更新：，更新历史
发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：OI-wiki
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用