AtCoderで黄色になりました

AtCoderのコンテスト初参加から2年と5ヵ月。
ようやく黄色になれました、わーい。
ということで記録も兼ねて色々書いていこうかと思います。
例のごとくポエムになると思うので好きな人は見てくださいなって感じで。

黄色になるまで

にやったことなんて「問題を解く」くらいなので、参考として情報を色々書いてみることにします。
指標の1つとして是非。

  • 高校時代の数学の成績はセンターで193点、河合模試の偏差値は大体70ちょっとくらいとってました。*1
  • 数学オリンピックは1回参加したことがあります、しっかり予選落ちしました。
  • プログラミングは大学に入ってから始めました(ほぼ競プロ開始と同時期と考えてよいと思います)。
  • 今までに解いた問題数はTopCoderが4問、CodeForcesが90問、AtCoderが861問、AOJが208問、yukicoderが6問で計1169問。*2
  • AtCoderの詳細はこんな感じ。

f:id:seica_at:20190114131431p:plain
AC詳細inProblems
f:id:seica_at:20190114131557p:plain
AC詳細inScores(黄色)
f:id:seica_at:20190114133736p:plain
黄色時点の精進グラフ

こんな感じでしょうか。
あ、最近Re:ステージ!にはまっています。皆さんもぜひ。

AtCoder Problems、AtCoder Scoresすごいですね。私はこうゆう開発はしない人なので尊敬します。

気を付けていること、コンテスト中に考えていることなどの雑記

ここからは完全にポエムです。
競プロについて普段考えていることをつらつら書いていきます。

精進について

問題演習をする際は基本的に長くても1時間程度しか考えません。というかそれ以上持ちません(えー)
自力で解けない問題についてその解法が簡単に理解できるとは限らないので、その前に時間を使いすぎるとめげやすいというのもあります(笑)
どちらかというと考えて解けなかった問題について、どう吸収するかに時間をかけています。
解法そのものだけでなく、その解法に至る動機などを自分なりに考えると印象に残ったり他の問題に応用しやすくなったりする気がします。
解説については、AtCoderの問題だと私的には解説放送が一番好きです、りんごさんすごい。
PDFについても日本語の解説を読んでわからなかったら英語の解説を読んでみるのもいいと思います、内容全然違ったりもします。

デバッグについて、コードの書き方について

まあ、よく言われていますが。
サークル活動をしてると良く思いますが、バグったときにいかに早く修正するかはかなり重要な気がします。
例えば私は基本的にprintデバッグしていますが、printデバッグをするといっても何処で何をどうゆう形で出力するかで得られる情報は全然変わります。
上手いデバッグ方法を自分なりに確立するのは大事だと思います。

また、そもそもバグらせなければそんなことしなくて済みますので、コードを書くときには自分がわかりやすい、綺麗で簡単なコードを書くように気を使っています。*3

モチベーションについて

強くなりたいとやっていてもなかなかモチベーションを保てなかったりします。

ということで精進仲間を大切にしています。
実力が離れすぎていない*4人とコンテストで競ったり、問題について話したりすることでモチベーションを保っています。
付き合ってくれている人には感謝。

知見?について

よく典型だとかメタ典型だとか定石(定跡)*5だとか言われるやつです、それ以外にも問題を解くにあたって何を考えるべきかなどについても知見としておきます。
ブログとかで問題ごとにきれいにまとめれればいいんですが私には向いていないようで、最近はスプレットシートにまとめていたりします。
そうゆう知見は言語化することで定着できたりする気がします。

少し列挙してみると

  • まずは全探索できないか考えてみる、全探索できるならそれをする。
  • 半分に分けたら全探索できないかも最初に考えておく
  • まず図示する
  • 構築についてはまず達成可能性を考える(極端な例について考えてみる)
  • 簡単に実験できないか
  • 与えられる問題についての値をを2値に分けると簡単にならないか->二分探索など
  • 与えられた問題についてある値を固定したら簡単にならないか(また隠れたパラメーターはないか)->そのパラメータをずらすとどうなるか、二分探索できないか
  • ゲームの問題について、最善の状態から相手の真似をすると良いことが多い
  • あるものについて、考慮する順番を決めると考えやすくならないか(制約のきついものから考えると良かったりする。組み合わせならそのあと階乗を掛けるなどする)
  • 実は考えなくてもよいものはないか
  • たくさんの操作をして、条件を満たす場合の数を求める問題は期待値で考えてHOGE倍すると良い
  • グリッドの問題について、2*2の正方形のうちある要素が奇数個あるものについて注目する
  • 操作をデータ構造に見立てる
  • 余事象を考える(さらにその部分集合を考える->包除原理)
  • 事を独立に考えられないかを考える(2次元座標の問題を縦と横で分けられないかなど)
  • etc

かなり雑に列挙しましたが、こうゆう知見がいい感じにまとまるとよさそうですね。
日本語ゆるふわ過ぎませんか?*6

終わりに

ここまで読んでくださった方、ありがとうございます。
突然ですが2週間前のツイートを見てみます。

今年中に橙になるそうです、橙になった記事は少ないしなれたら書きたいと思います。
お楽しみに。

*1:競プロやってる人の平均はどのあたりなんですかね、ちょっと気になります

*2:まあ、問題数だけだとあまり参考にならない気がしますが

*3:バグる時はバグります。仕方ないね、人間だもの

*4:はずの

*5:私は囲碁をやっていたのでどちらかというと「定石」派

*6:仕方ないね、せいかちゃんだもの