problem_policy.html

<title>問題ポリシー</title>

<h3 class="shadow">問題の種類のポリシー</h3>

        定期のコンテストは基本「通常問題」から出しますが、単発やコンテスト向きではないからといって「通常問題」ではないというわけではないです<br>
        理由：「その他問題」におくとページが違うので、リーチがされにくくなりもったいない。

        <dl>
            <dt>通常問題</dt>
            <dd>競プロ的な問題全般（数学問題・実装問題など）<br>
            アイデアの初出が自分ではなかったなど関わらず通常問題として公開したいです。<br> （おさまりが悪い方は、問題文や解説文で触れれば十分かと思います）
            <br>
            「コンテストで出題された過去問」や「初出の問題」というニュアンスではないようにしたいです。
            </dd>
            <dt>その他の問題</dt>
            <dd>競プロ向きではない問題、証明不足（証明がされたら通常に移行を検討）
            </dd>        
            <dt>ネタ枠</dt>
            <dd>Aprilコン・なぞなぞなど</dd>
        </dl>
<h3 class="shadow">問題のポリシー</h3>
        問題は、なるべく投稿してくれた文章・★などそのままで出題します。<br>
        運営側で見られる時は、見て提案をするときもあります。<br>
        作問の練習をして、他の競サイトでも作問してみるための練習として使ってください。<br>

        少なくともC++・Java・C#では通るようにしたいと思います。LL系や関数型言語で厳しい場合もあリます。<br>


<dl>

    <dt>問題文のポリシー</dt>
    <dd>
    数値自体には罪はないとはいえ、一般に知れ渡ってしまった物議を醸してしまう数値を使うのは控えてください。<code>2×31×1847</code>や<code>違法素数</code>など
    </dd>


    <dt>制約のポリシー</dt>
    <dd>
        出題時の制約より厳しくしたいということもあると思います。<br>
        その際は、コンテストとして出さないにしても、別の問題として（元々の問題名 Hardなど）新たに作ってもらい、別の問題として公開する方針で行きたいと思います。 
    </dd>
    


    <dt>スペシャルジャッジポリシー</dt>
    <dd>判定に必要なものが読めれば、余分な出力、多少フォーマットの崩れがあってもACされるかもしれません。<br>
    
    </dd>

    <dt>正解判定のポリシー</dt>
    <dd>Writerが準備したテストが通ればAC(Accepted)となり正解となりますが、<br>
        Writerさんは目安として20個のケースは準備しましょう。（強い方はお任せします）<br>
        システムの都合上、そこまで強いケースを作れない、事前にすべて落とすのはなかなか難しい、コードを見ないと落とせるケースを作れないなど、難しいですが、<br>
        嘘解法が通ったままだと運営側も（その提出を見た）ユーザーも良くないと思うので追加テストを行っております。<br>
        <br>
        追加テストはユーザーさんからの撃墜ケースやシステムによる乱数テストを行っております。<br>
        そこで得た気付きなどを次に生かせればと思いますので、ご了承ください。<br>
        落ちたケースが見つかればお知らせしたいと思います。<br>
        <br>
        アルゴリズム的にはあってるはずだが、標準関数へのアンチケース(<a href="/wiki/trap">標準機能の罠</a>参照)のため、不正解となるケースがでてきました。<br>
        ユーザーがHack出来るようなシステムのために標準関数へのアンチケースの対策は知っておくべきだと思うのですが、運営者としてはプログラマーではなく言語設計者に何とかしてもらうべきではあると思っているので、<br>
        <b>evilケース</b>と呼ぶようにして、参考までに"evil"から始まるテストケースは、ジャッジはされるが提出自体のステータスには影響しないようにしてます。
    </dd>

    <dt>難易度について</dt>
    <dd>作問者は難易度を低く見積もりがちな傾向があります。ですので、可能なら★ の数は writer と tester が話し合って妥当なものにしましょう</dd>
    
    <dt>基本的に何でもありです。</dt>
    <dd>クオリティーが高い問題は、他のジャッジにお任せして、yukicoderでは典型・ライブラリを貼るだけ・実装問題、何でもありです。<br>
        
        提出されたコードからわかったことなどで、運営者が記事を書くかもしれません。
    </dd>
    
    
</dl>