「みんなもっと解説書こうよ!」という記事です。

導入

競技プログラミングの界隈においては、解いた問題の解説を書く文化があまりありません。

解説を書く人としてはkmjpさんが有名です。 現在1活発に解説を書いている人は、軽く調べた限りでは以下が見つかりましたが2、多くはありません。 しかし、解説を書くことは有益であるので、もっと多くの人が書いているべきです。

ついでに挙げておくと、もう更新は止まっていますが、aojの古い問題などであればよく以下のサイトにお世話になっています。

pros cons

解説を書くことの利点としては、

  • 問題に対する理解が深まる。
  • 質のよいライブラリになる。
  • 自分のモチベーションになる。
  • 後から解く人の助けになる。

が挙げられます。

理解が深まるというのは、理解していない問題がそのままにならない、というのが正しいかもしれません。 正直よく分からないけれど直感をたよりに証明なしで書いてみたら通った、というような問題も、解説を書くにはある程度の理解が必要となります。 面倒ですがやるべき作業です。 また、理解が間違っていた場合には、他人から訂正をもらえるかもしれません。

ライブラリになるというのはそのままの意味です。 使い方等もきちんと書いてあって、検索性がよく、ネットに繋がっていればどこからでもアクセスできるので、とても便利です。 ここで言うライブラリとはunion find木やsuffix arrayといったモジュール化されたアルゴリズムやデータ構造に限らず、似たような問題も含みます。 「それを固定して前から見ていく感じのあれ、以前解いたことある気がするな。たしか問題文に電車がどうこうというストーリーが付いてたなあ」といったことを思ったときに、サイト内検索をすればすぐにその問題が見つかります。 かなり便利です3

モチベーションとしては2点です。 解いた問題の一覧が見やすい形で時系列順に並ぶので、「今月は$n$問解いたなあ」みたいな満足感とかが得られます。 だれか強い人もこんな感じのことを言っていた記憶があります4。 加えて、他人から「あなたの書いた解説はたまに参考にしてます」とか言われるとけっこう嬉しいです。

後から解く人の助けになる、というのはほとんどの人が知っているでしょう。 このこと自体には自分への直接的な利益はないですが、後から参加する人が勉強しやすい環境ができれば界隈全体が盛り上がりやすくなります。 そして競技プログラミングをする人が増えれば当然コンテストの頻度や規模が大きくなったりし、間接的に利益にはなるでしょう。

一方で問題点としては1点あって、

  • 書くのに時間がかかる。

です。topcoderやcodeforcesなら、システムテストやレート更新を待つ時間に書くとよいです。

注意

いくつかあります。

  • 解説の公開を禁止しているサイトもあるので注意。
  • コードは綺麗に書いてほしい。
  • 意味のある記事を書いてほしい。

解説の公開が禁止されているなら、それに従いましょう。 当然コンテスト中に書いて公開するのはだめです。出題期間が長期であるサイトにも注意しましょう。

コードは綺麗に書きましょう。 テンプレートからコピペしてきたが使ってないマクロ等は、消しておいてもらえると助かります。 特に、それを使う気がしたのでライブラリから一旦は貼り付けたけれど結局使わなかった、といった際に、そのコードが残っていたりするととても混乱します。 類似問に出会って見返した際等を考えると、自分にとっても不利益となります。

意味のある記事をというのは、ひとこと「解けなかった」とだけ書いてある記事や、非自明な問題であるのにコードのみが貼り付けてある記事は、公開しないほうがよいのではないかという意味です。 解説を検索してひっかかったので開いて、実質的に何も書かれていなかったら悲しいです。 わざわざ記事を作製するのも面倒でしょうからやめたほうがよいと思います。

まとめ

解説を書け。


競技プログラミングにおいて解いた問題の解説を書くことの利点について

  1. Mon Feb 1 06:01:30 JST 2016 

  2. arc NNN Xなどでいくつか適当に検索して、100記事程度以上あるブログを集めてきました。 

  3. しかしバージョン管理はちょっと面倒だったりします。 

  4. 要出展