2番目の記事は、システムのテストに関するものです。
3番目の記事は、組織委員会の仕事に関するものです。
4番目の記事は、ツアー自体に関するものです。
最初の記事では、これらのオリンピックのタスクのコンパイルについてお話したいと思います。 ケースは魅力的で創造的ですが、時には非常に退屈です。
約2〜3年、さまざまなレベルの学校のオリンピックのタスクを書きます。 私はまだ自分のプレイがとても上手で、自分も参加したいと思っているので、まだ生徒のものに到達していません（覚えているように、私の仕事の1つはNSU個人オリンピアードに引き継がれました。
すべてはどこから始まりますか
オリンピアードの学校の約3週間前、私たちのコーチは「古い人々」-NSUの最初の4チーム-を屋内に集め、戸惑っています。 タスクは10〜12個のタスクを選択することで、そのうち8個がツアーに採用されます。
最初は生のアイデアが投げられます。 まず、オリンピアードプログラミングの分野に偏りがないようにしてください。1日中ジオメトリをトレーニングするか、ダイナミクスをトレーニングするのが良いでしょう。 既製のオリンピックでは、ほぼ同等でなければなりません。 グラフに関する1つまたは2つの問題、ほぼ必然-1つのジオメトリ、組み合わせ論に関する何か。 時には単純なターバー（結局、学生は後悔する必要がある）。 動的プログラミングのための2つのタスク、1つは文字列の処理、そして最も重要なことは1つの「コンソール」です。 第二に、オリンピアードの全体的なレベルを維持する必要があります。 目標が次のレベルのオリンピアードの選択である場合、複雑なタスクに夢中になるべきではありません。 トーナメントの決勝戦が行われた場合、優れたコーダーと実際のトップを区別するために、1〜2個の率直なreleasingをリリースすることにより、サディズムの小片を示すことができます。
そのため、脳の中心には常にそれぞれにいくつかのアイデアがあります。 彼らは表現し、記録し、配布します。 その結果、非常に10〜12個のタスクを取得しますが、そのうちのいくつかは（複雑さ/失敗/繰り返しのため）プレイ中に削除されます。
次にアイデアで何をしますか？
各タスクは、できれば別々のチームからの数人に渡されます。 さらに、それぞれがリストから2〜3個のタスクを取得します。
- タスク条件;
- 問題解決;
- タスクのテスト。
- チェッカー（タスクのタイプのオプション）
条件
通常、条件は問題のアイデアの作成者によって作成されます。 通常、ただし常にではありません。 書かれた作品/言語との不一致の著者が中断されていない場合、コース、条件、およびオリンピック自体の技術的なスケルトンを準備するとき、それは読み書きができます。 最も重要なことは、タスクのコーチとパートナーの両方が、決定に必要なものとその方法を理解できることです。 もちろん、事件があります。 状態は特別に傷つけられ、混乱し、消化されず、解決策は簡単で迅速です。 したがって、私たちのチームは、タスクをボトムアップで読み取る方法を使用しています。 まず、入力/出力データの形式が表示され、次に実行時間と空きメモリの制限が表示されます。 この後、髪が逆立っていない場合は、決定を下すことができます。 しかし、ツアーについては少し後、準備ができました。
条件は異なります。 厳密に数学的なものがあります（たとえば、VsesibakhでのShilovのタスク-ほとんどの場合、正式に定義された一部の言語のパーサーへのタスクがあります）。 厳密にユーモラスなものがあります（たとえば、熱烈なサッカーファンで構成された私たちのチームは、フットボール選手のVladislav Bulanovとチームのオーナーであるハロルドイヴァノビッチネルに関するタスクによって5分間活動を停止しました）。 主なことは、どちらか一方と行き過ぎないことです。 私の意見では、条件の真髄は、閉空間、オープンスペース、Java言語、および数字13を恐れる読者の緊急の開発を専門の精神分析医に2つの数字の追加を委任するというミシャカルギンのアイデアです。
解決策
さて、条件に十分です。 次にソリューションについて説明します。 ソリューションは、タスクの作成者とアシスタントの両方が作成する必要があります。 望ましい-異なる言語で（学校の競技会の場合：c ++ /パスカル、生徒用：c ++ / java）。 通常、テストはタスクの作成者によって作成されません。 なぜこれが行われるのですか？ 実際のところ、タスク全体を作成するとき、1人の人は微妙な影響を受けず、極端な場合は見逃されます。実際、最適でない解決方法が選択されています。 多かれ少なかれ知識のある2人によって決定が独立して書かれている場合、それははるかに正しい可能性が高くなります。
決定を書く過程で、問題の状態はしばしば変化します。 制限-そのため、特定の決定をパスするかパスしないかの目標で、それらは千回変化します。 Javaが有効になっている場合、時間/メモリ制限が増加する可能性があります。 ある条件の穴が、解法の1つを取り巻く反例のいずれかに突然見つかることがあります。 その結果、相互作用の過程で2つの決定が発生します。それらは悪名高い「ju審員の決定」であり、間違いなく無敵です=）。
テストとチェッカー
ここではすべてが多かれ少なかれ明確です。 タスクに複数の解決策があり、推論できるのは任意の1つだけである場合、チェッカーが作成されます。 この場合、最適な入出力データをチェックするプログラムが作成されます。 それ以外の場合、正しいソリューションが1つしかない場合、テストはテストシステムに完全に委ねられます。 著者から-入出力テストのセットのみ。
次にテストについて。 これは2つのカテゴリに分けられます。 競争がACMのルールに従って開催される場合、魂が外れます。 この場合、テストは絶対にすべてのテストに合格するタスクのみに合格し、入力データのサイズの作成者が想定した最適な漸近性で書き込まれます。 著者が2-3審員の決定を書くために2〜3週間書いており、オリンピック選手は野生で5時間で10の決定を書くように勧められているため、2〜3の領域に修正定数があります。 境界値のテストが書き込まれます（入力データの最小値で何が起こるかを確認するために-多くの場合、入力データがゼロの場合に見落とされます）。 Maxtestesは書かれています-最適ではないソリューション、または不正確に処理された配列を書いたソリューションは、しばしばそれらに注がれます（ああ、そうです、私は常にダースの追加要素を追加します）。 ジオメトリの場合、精度とエプシロンで確執している人をカットするテストが書き込まれます。 ランダムテストが作成され、必要な場合はテストジェネレーターが作成されます。 そして怠ifなら-ショーは書かれています。
少しオフトピック：
私たちが2年生のとき、私の仲間であり、親友のミーシャ・ゴロディロフと私は簡単なタスクのテストを行いました。 入力は10 ^ 18までの1つの数字で、出力は2つの数字です。 乱数ジェネレーターを作成したくありませんでした。 その結果、ju審員のテストでは、電話番号と、コーヒー缶とコカコーラのボトルのバーコードがあり、最終的にはキーボードで2回頭を打った結果でした。 私たちにとっては、ジェネレータを書くよりも高速でした。
そのため、学校のオリンピックでは状況は多少異なります。 最近のトピックに関するコメントで述べたように、異なる評価システムがあります。 合格したテストの数に対してポイントが付与されます。 すべてが通過-100、入力のみ、またはなし-0。そしてそれらの間-すべてのファンタジーの暴動。 最初に、完全な折りたたみ可能なソリューションの制限が考慮されます。 ポイント15〜20に対して3〜4個のテストが送信されます。 気分を害さないため。 さらに非理想的なオプションと漸近性が考慮されます。 アルゴリズムはO（N ^ 3）で機能します-これが彼の死の薬です。 O（N ^ 2）の場合-それが彼です。 O（NlogN）は良いです。 これが彼の最大テストであり、漸近定数が良好な場合、100ポイントになります。 ジオメトリでは、精度の向上が必要な複雑なテストのカットオフが再び発生します。 さて、この場合、入力/出力データセットのいくつかがスコアリングされています。
すべてが好きです。 条件が書き込まれ、解決策があります。すべてをテストシステムにロードし、チェッカーフラグを振ります。 しかし、それについては次の記事で詳しく説明します。