problem_checklist.html

<title>作問用チェックリスト</title>


<h4 class="shadow">有志の方の資料</h4>

<a href="https://drive.google.com/file/d/1kTfrNKGXMhJOgUdyDhYo2dswbwPAhZ7a/view">optさんの競プロ作問チェックリスト (初心者向け)</a> <br>
大変まとまっておりますので参考にしてください <br><br>

<a href="http://tozangezan.hatenablog.com/entry/2015/12/02/000030">作問の失敗 判例集</a><br>
<a href="https://codeforces.com/blog/entry/70178">On the problem setting by antontrygubO_o</a><br>
<a href="https://drive.google.com/file/d/1CVTQBkLNRfciEJeCaRwBUfy3w7mt-G6P/edit">初心者のための作問テクニックについて by E869120</a><br>


<h4 class="shadow">作問用チェックリスト</h4>

yukicoder作問用のチェックリストです。完成度を高めるために参考にしてください。

<h5 class="shadow">コミュニケーション</h5>

<dl>
    <dt>やり取りしやすいように是非yukicoder Slackにご参加ください</dt>
    <dd>トップページの上から参加することが出来ます。たまにでも見てもらえると助かります。</dd>
</dl>

<h5 class="shadow">制約</h5>

<dl>
    <dt>★1問題の想定解は100ms未満にしてください</dt>
    <dd>
        コンテスト中にジャッジが詰まる原因になりやすいのでご協力お願いします。
    </dd>

    <dt>★2以下の問題の入力の個数は多くても$10^5$あたりまでにしましょう</dt>
    <dd>
        Python・Ruby等のスクリプト言語の入力が読み取れなくなる可能性があります。<br>
        $10^5$を超える場合は、入力するだけのコードを書いてみて、どの程度時間が掛かっているのか、計測してみると良いです。
    </dd>

    <dt>それぞれの入力で与えられる変数の値が、整数か小数か、もしくは文字列かを記述する（非自明な場合）</dt>
    <dd>小数の場合、小数点以下何桁まで入力で与えられるかも記述しましょう。</dd>

    <dt>不必要にコーナーケースを増やすような制約になっていませんか</dt>
    <dd>
        例えば、$N=1$の場合に特別な考察を必要とする場合、制約を$2\le N$としてしまうと良いです。<br>
        非自明に多倍長整数や128bit浮動小数点数を必要とする問題もできるだけ避けましょう。
    </dd>

    <dt>（なるべく）モンテカルロ法でも通りそうな制約は避ける</dt>
    <dd>
        想定解がモンテカルロ法を使う問題は大丈夫ですが、モンテカルロ法でも通ってしまうと
        想定解法を勉強するモチベーションがあまり出ないと思われるため[要出典]<br>
    </dd>
</dl>

<h5 class="shadow">問題文・解説</h5>

<dl>
    <dt>曖昧・抽象的な用語を避けましょう</dt>
    <dd>
        例えば、以下のようなものがあります。
        <dl>
            <dt>自然数</dt>
            <dd>
                「1以上の整数」と習ったかもしれませんが、0を含める事もあり曖昧なので控えておいたほうが無難です。
                「正整数」や「非負整数」を使うようにしましょう。
            </dd>
            <dt>グラフ</dt>
            <dd>
                無向グラフ(undirected graph)・有向グラフ(directed graph)なのかをきちんと明記する。<br>
                自己ループを持ったり、多重辺を許したりする場合はそれを明記しよう。
            </dd>
        </dl>
    </dd>

    <dt>用語や記号は問題文中で定義する</dt>
    <dd>
        たとえそれが比較的一般的な関数であっても、問題文中で定義するようにしましょう。
    </dd>
    
    <dt>ランダムな事象な問題の場合は、「同様に確からしい」や「一様」などのランダムとわかる記述をする</dt>
    <dd>条件（戦略）が記述されてないと、数学的に何の値を求めてるのかわからない(確率ではない何か)ことになるので問題として不適切になります。</dd>


    <dt>$i \neq j $の時に$(A_i,B_i) \neq (A_j,B_j)$などではありませんか？</dt>
    <dd>問題文章上、そう読み取れるかもしれませんが、制約にちゃんと書きましょう</dd>

    <dt>2次元配列などで 幅=W 高さ=H があるのは $H W$の順番のほうが好まれてるらしい</dt>
    <dd>
        （要出典）
    </dd>

    <dt>サンプルケース内はMathJaxを使わない</dt>
    <dd>コピペが正常にできなくなったり、ジャッジヘルパーの対応ができないため。</dd>

    <dt>色覚特性対応を検討してください</dt>
    <dd>
        例えば、赤と緑が区別しづらい方もいらっしゃるということです。<br>
        こちらで紹介されているツールでチェックを検討してください。<a target="_blank" href="https://twitter.com/su8ru_/status/1408786559524954121">https://twitter.com/su8ru_/status/1408786559524954121</a>
    
    </dd>
</dl>

<h5 class="shadow">テストケース</h5>
    <dt>YES/NOの表記は<code>Yes</code>か<code>YES</code>が良さそう</dt>
    <dd>
        <!--最近のAtCoderをざっと見た感想-->（要出典）
    </dd>
    
    <dt>テストケースは少なくとも20個を用意する</dt>
    <dd>
        強いケースはもちろん、ランダムなども用いて20個は用意しましょう。嘘解法が通るとお互い良くないです。
    </dd>

    <dt>テストケースを強くする</dt>
    <dd>テストケースには、最小ケース、最大ケース、コーナーケースとなりうるケースは全て入れましょう（問題にもよりますが、コーナーケースは案外小さいケースが多いor発生しやすいのです）。<br>
        ある変数は最小値、ある変数は最大値、と言ったケースも入れれる限り入れると良いです。<br>
        場合分けで解ける問題の場合は、全てのケースを入れましょう。<br>
        また、最大ケースの場合、複数の変数が同じ値の場合は微妙に速くなったりするのと、最大ケースのみ埋め込みなどをされる可能性があるので、「だいたい最大ケース」みたいなのも入れましょう。<br>
        数え上げ問題などではテストケースの数は少なくても嘘解法は通りにくい傾向にありますが、最適化問題などでは嘘解法が通りやすい傾向にあるので注意しましょう。特に貪欲法でかなり良い答えが出るような問題や効率的に枝刈りできる問題は要注意。<br>
        嘘解法が通りやすい問題の場合、手軽にテストケースを強くするためには、１ファイルに複数のテストケースを入れる形式にして、テストケースの数を増やして、数の暴力で対抗するのが簡単で確実です。<br>
        また、枝刈りが効率的に出来る問題の場合は、考えうる枝刈りを行った解法を用意して、テストケースをランダムに作成し続けて、実行時間がかかるものを拾ってくるというのは結構有効な方法です。<br>
        ありうる想定誤解法を想定して、それらが落ちるテストケースを入れるのも理想ですが、コストが高いので数の暴力のほうがおすすめ。<br>
        なお、wataさんの<a href="http://d.hatena.ne.jp/wata_orz/20111218/1324226179">嘘解法のススメ</a>を読み、嘘解法を絶対に通さないぞという心意気があれば完璧です。<br>
        また，yukicoderでは $N \leq 10^9$ でも $O(N)$ 解法が通ったりするので、そういう場合も複数テストケースにすると、良いかもしれません。<br>
        <a href="https://yukicoder.me/wiki/hack">嘘解法・誤解法対策として入れるケース</a>のページも参考に。<br>
    </dd>
    
    <dt>サンプルの確認</dt>
    <dd>
        手作業で作成されるサンプルケースは間違いが発生しやすい部分です。<br>
        テストケースを手で作ってミスってたり、制約変更の適用を忘れてたり、サンプルの説明が間違えてたり。<br>
        テスターは必ず確認しましょう。提出コードで assertion を行えば、これらは防げます。
    </dd>
    
    
    <dt>テストケースの改行チェックには、Unix系なら「file」コマンドを使いましょう  </dt>
    <dd>（yukicoderは末尾改行が自動で付加されるようなったのであまり必要ありません）<br>
    「ASCII text」とだけ出れば、末尾に改行がありでLFで終わってます。「with no line terminators」なら末尾に改行がありません。「with CR line terminators」ならCRで終わってます。<br>
    「file *」とするとディレクトリ内、全部のファイルを指定できます。
    <p>ディレクトリ内のCRLFをLF（yukicoderの改行コード）に変換するコード
        <code> find . -type f | xargs -n 10 nkf -Lu --overwrite</code>
    
    </p>
    <p>例外</p>
    <p>"yz","yx","xz","zz","zy","zy"から始まっているファイルは「MGR bitmap,・・・」と表示される。</p>
    などがある（他の例はコメントアウトされてます）
<!--
    <p>"777"から始まっているファイルは「777 archive data」と表示される。</p>
    <p>「改行」だけのファイルは「very short file (no magic)」と表示される。</p>
    <p>"UU"から始まっているファイルは「VISX image file」と表示される。</p>
-->    
    </dd>
<dl>
    
</dl>

<h5 class="shadow">想定解・提出コード</h5>

<dl>
    <dt>問題文中のサンプルケースとテストケースが同じか確認する</dt>
    <dd>
        チェックの意味でサンプルとテストケースが同じ結果になっているか確認しましょう。<br>
        また、答えだけでなく、説明に使われる値も正しいか確認しましょう。
    </dd>

    <dt>制約は、writer提出コードにassertをつける</dt>
    <dd>
        念の為にもつけましょう。想定解とは別にassertだけのコードでもいいと思います。<br>
        余分な半角スペースが含まれていないかなどもassertでチェックするともっと良いです。<br>
    </dd>    

    <dt>想定解法のチェックをする</dt>
    <dd>
        想定解法にバグがないことを確認するためにも、想定解法より計算量が重い愚直な解法（全探索やモンテカルロ法）を利用して、
        想定解法と一致するか確認しましょう。<br>
        ランダムにテストケースを作成し、想定解法と愚直な解法の答えが一致するか試し続けるプログラムを1つ作ると安心度増し増しです。</dd>

</dl>

<h5 class="shadow">仕上げ</h5>

<dl>

    <dt>問題文を読みなおす</dt>
    <dd>頭のなかを一度空っぽにして読みなおして、問題文が理解できるかどうか確認しましょう。知ってる人だけにしか伝わらないような日本語／英語になっていませんか？<br>
        問題文には一番時間をかけた方が良いです。<br>
        数字と数の使い分けを確認しましょう。<br>
    </dd>

    <dt>writer/tester提出を全てリジャッジする</dt>
    <dd>
        assertコードを提出した後にテストケースを変えていると、そのテストケースはassertを通していないことになります。
    </dd>
</dl>

<h4 class="shadow">作問用チェックリスト（スコア問題）</h4>

<p>スコア問題では追加の推奨事項があります。</p>

<dl>
    <dt>入力生成方法と得点計算方法は必ず書く</dt>

    <dt>なるべくローカルテスタを用意する</dt>
    <dd>
        スコア問題ではローカルで改善を繰り返すことが多く、
        ローカルテスタの有無で参加しやすさが大きく変わることが珍しくありません。<br>
        特にリアクティブ問題ではローカルテスタがないとデバッグが困難になることがあります。
    </dd>
    
    <dt>ビジュアライザを用意できるならなるべく用意する</dt>
    
    <dt>サンプルコードを提供する場合はシンプルで十分弱い解法にする</dt>
    <dd>
        参加するハードルを下げるためにサンプルコードを置くのは良いアイデアですが、
        サンプルコードが強すぎると逆に初級者が楽しめなくなる可能性があります。<br>
        サンプルコードでは最低点狙いのように無理に点数を下げる必要はありませんが、
        作問者が思っているより低い点数の解法の方がいいかもしれません。<br>
        作問者にとっては自明な解法でもコンテスタントにとっては難しいことがよくあります。
    </dd>
</dl>

<hr>

<h4 class="shadow">作問用テクニック（？）</h4>

こっそりと書いているのです。
<dl>
    <dt>自分が書きたいライブラリ／アルゴリズムの問題を作る</dt>
    <dd>ライブラリが充実／勉強が捗ってハッピーです。</dd>

    <dt>なんかネタを探す（思い浮かんだ時にストックしておく）</dt>
    <dd>どんなネタでも★１や★２の問題（あるいはそれ以上）は作れるものです。</dd>

    <dt>きれいな性質／公式を見つける</dt>
    <dd>きれいな性質を発見した時は作問チャンス。</dd>

    <dt>ちょっとひねってみる</dt>
    <dd>ある変数の制約を極端にきつくすると、出題形式をちょっと変えてみると、その他ちょっとした変更で別の解法が思い浮かんだりしませんか。<br>
        同じ題材でも制約次第で色々な問題ができるかもしれません。
    </dd>
</dl>