はじめに
競技プログラミングのコンテストを開く時、参加者からは気づかないような準備が多数必要になります。この記事ではwriter初心者向けに必要最小限の準備リストを一覧にしました。
また、これらの準備をするときはtestlibやRimeといった、既に整備されているライブラリを利用することを推奨します。
チェックリスト
ソースコード
-
ジャッジ解
少なくとも2つは用意する。 -
想定誤答
想定されるWA・TLEは全て用意してちゃんと落とせるかの確認が必要。 -
愚直解
小さなケースについてジャッジ解と同じ出力になることを確認する。 -
入力ジェネレータ
テストケースの入力を生成するコード。
環境依存で生成される入力が変化することを避けるために、testlibの利用を推奨。 -
入力検証器
testlibの利用を推奨。
誤って空白が1つ入っただけでもリジャッジが必要になりコンテスト全体の質に影響を与えるので、特に慎重に用意しなければならない。
なるべくたくさんの人が書く。特に入力ジェネレータを書いた人しか書いていない状況はNG。 -
出力検証器（diffジャッジにできない場合）
例えば誤差を許容するような問題や、構築で解が複数あるような問題の場合、検証器を用意する必要がある。
出力検証器はバグらせやすいのでtestlibの利用を推奨。
その上で、出力がない場合に正しく落とせるかなどを確認する。
データセット
-
サンプルケース
サンプルが通らないのにACが出るという状況は好ましくない。 -
ランダムケース
-
小さなランダムケース
想定外の誤答を落としやすくなる。 -
最大ケース
これがないとTLE解が落としにくくなる。
最大ケース1つだけだと埋め込みなどで突破される危険があるので、最大よりほんの少しだけ小さいケースもいくつか用意するとより良い。 -
コーナーケース
想定誤答を落とせるケースを揃えておく。
問題文
-
問題文
なるべく誤解を生まない問題設定を考える。
数式を用いて形式的に書いておけば誤読される危険性が減る。
物語などをつける場合、あまりに文章が長くなると読みづらくなる。この場合は「背景」など別段落に分けることを検討するべき。 -
制約・入力・出力
入力形式・出力形式を正確に語弊なく書き下す必要がある。
入力検証器を自然言語に翻訳するつもりで書くと曖昧さが減りやすい。 -
サンプル
サンプルが入力フォーマットに従っていない・出力がおかしいなど、ミスが頻発するパート。
入力検証器・ジャッジ解を用いたチェックを通っていることの確認が必要。
手元でのチェック
-
ジャッジ解・想定誤答が想定通りAC・WA・TLEになる
TLE解は十分余裕を持って落とせているか確認する必要がある。 -
ストレステスト
ランダムケースを大量に生成してジャッジ解が全てACすることを確認する。
小さなケースについては愚直解との一致も確認する。
ジャッジシステム上でのチェック
-
ジャッジ解がACになる
-
想定誤答が想定どおりWA・TLEになる
-
問題文が正しく表示されている
-
Time Limit/Memory Limitに2倍以上の余裕がある
逆に、TLを少し伸ばした程度ではTLE解が通らないことのチェックも必要。
想定解とTLE解の幾何平均がTLになるように入力サイズを調整すると事故りにくい。
過去問
-
既出チェック
シンプルな問題設定ほど被りやすい。
「(アルゴリズム名) 競技プログラミング」「(アルゴリズム名) AtCoder」「(アルゴリズム名) Codeforces」などでググって確認する。 -
OEIS
オンライン整数列大辞典。
特に入力が整数1つの場合は必ずチェックが必要。