6
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

Atcoder歴9か月で青になりました(python)

Posted at

前回の続きのようなものです。

ABC168で青になりました。

image.png

ちなみに4月の第2回PASTで上級も取得しました。
image.png

色変したのでこの5か月の振り返りをしたいと思います。

取り組み方の変化

1月以降は前よりモチベが下がっていて、問題を解くペースが明らかに落ちていた。
image.png
これはAtcoder ProblemsのUnique ACのHeatmap。年が変わったあたりから目に見えて新規ACの量が減っている。3月くらいからはコンテスト以外ほとんど触っていないことがわかる。

しかし、このHeatmapをパフォーマンスのグラフと重ねてみると、むしろ精進をサボりだした頃から高い値で安定していることがわかる。
image.png

補足しておくと、CodeForces等の別コンテストに参加してたわけではないし、蟻本などの技術書をしっかり読み込んでいたわけでもない。
本当にコンテスト以外は何もしてないのだ。ではなぜパフォーマンスが上がっているのだろう?
振り返って考えてみると、この前後の時期で要因と思われるものがいくつか思い当たった。

ライブラリがおおよそ完成した

確認してみたが、前回の記事から増えたライブラリはセグ木のみだった。
chokudaiさんの色について解説した記事でも

水色や青あたりで、競技プログラミングで必要な知識はほぼ揃ってしまうので、そこから先は応用力の違いになってきてしまいます。

との記述があるが、やはりこれが正しかったのだと思う。
基本的なアルゴリズムを習得する時期はおおむね終了したので、必然的に**「問題を沢山解いて基本的な使い方と使い所の見極め方を身につける」必要もなくなってしまった**。そのため、大量に問題を解く、いわゆる「精進」の必要性が下がったと言えるだろう。

実際、水diffや青diffくらいになると貼り付けて終わりみたいな問題はほぼ出てこないため、DFSやDPなども、ライブラリからコピペしたものを修正するより問題に合わせて1から書いていった方が楽だったりする(と言えるくらいの実力にはなっている)。
そういう意味でも、ライブラリを整えて時間短縮を目指す時期は終わったと言える。

コンテスト後に振り返りをしっかりと実施するようにした

コンテスト以外で問題を解く頻度が下がった代わりに、3~4月あたりからはコンテスト終了直後にしっかりと反省会を行っている
終了直後に上がる解説を読んだり、YouTube Liveの解説放送を聞くなどして、A問題からしっかりと振り返りを実施するようにした。
A問題やB問題でも、コンテスト時は早さを優先して書き方が雑になることは多いので、コンテストが終わってからじっくり考えてどういう解き方が最もスマートか考えるクセをつけておくと、コードの質の向上、ひいては速度の向上にもつながる。
また、解説放送では他の人が「こういう考え方でやった」とか「ここで詰まった」などのコメントをするし、すぬけさんがコメントを読んで質問対応や補足などを適宜行ってくれるので、解けた問題も含め、問題に対する理解がより深まる。
解説放送のリアルタイム参加はまじでパフォーマンス向上に役立つのでABC勢は全員見ろ(暴言)

後ろの問題を先に解くのを原則禁止した

これはパフォーマンスが安定するようになった要因。
まず、パフォーマンスが大きく下がってしまうケースというのは
「DかなりめんどそうだからEを先に考えたけど、結局Eもわからず時間ギリギリにDを通す」
みたいなケースがかなり多いのではと思う。
そういうのが無いよう、「これ大変だな」と思ってもよそ見をせず前の問題から着実に解いていくことで、パフォーマンスが大きく下がってしまうのを防ぐことができるようになった。
後ろの問題から先に手をつけるようにすると、運が良ければ少し高いパフォーマンスが出ることもあるが、それよりも失敗して下振れするデメリットの方が大きく、長期的に損をしてしまうと思う。
寄り道せず、前の問題を確実に通してから次の問題に取りかかることで、パフォーマンスのブレを減らせる。

ただし、例外として「DよりE(EよりF)の方が簡単だった」という事も時々はある。
そのため、少し詰まった時はいったん順位表を確認して、難易度の逆転が起こっていないかチェックするようにしている。正答者数が近い(逆転している)ケースの場合は、一度問題を見比べて、解けそうな方から手をつけることはある。ただしあくまでも例外である。

雑感

ここからは、振り返って感じたことを色々雑多に書く。

Atcoder Problemsのdifficultに関して

よくある思い込みとして「青色になるためには青diffを解けるようにならなければいけない」というものがあるが、これはあまり正しくない。
というのも、AtCoder Problemsのdiffというのはおおむね**「制限時間ギリギリでその問題までを完答したときのパフォーマンス」**になっている。そのため、例えば実際のコンテスト上でdiff1800(青中盤)に相当する問題を解けた場合、パフォーマンスとしては2000程度出る。なので、青色になるために青diffを解ける必要はないのだ。

もう一つの思い込みとして「青になりたいなら水色diffは全て解けるようにならなければいけない」というものもある。
人間、得手不得手というものがある。diffはあくまで平均化されたものなので、問題によって黄diffが解けたり、水diffが解けなかったりということは当たり前にある。diffが上がると解ける確率がシグモイド的に下がっていく、というのが正しい理解である。
解けるか解けないか位の問題に取り組むのは結構メンタル的にしんどいものがあるため、解けなかったからといっていちいち落ち込んでいるとかなり精神的にクる。diffに対して正しく理解したうえで、解けないことに深刻になりすぎない図太さが大事である。

自分の体感としては、青になりたいのであれば
・水色は8割解ける
・青前半は半分くらい解ける
・青後半は基本解けない(まれに解けるやつもある)

くらいが目安ではないかと思う。(実際今でも解けない水diff結構あります)

twitterの活用

ABCに精力的に参加しており、実力が黄色くらいの人をフォローしておくと、終了後に解法の要旨が流れてくるので参考にするとよい。
また、自分の場合は大学時代の知り合いに今も競プロに取り組んでいる人が多く、そういう人の存在もモチベーション維持に役立った。
我々も人間なので、やはり**「一緒に取り組んでる人の存在」がいるということはかなり重要**である。
一方的にでもよいので競プロ勢を見るようにしておくとモチベを保ちやすい(誰でも一方的にフォローできるのがtwitterのいいところである)。

python,pypyの高速化

4月にatcoderの言語アップデートが実施され、python、pypy共にかなり高速化した。また、Cythonという選択肢も登場した。
pypyの苦手分野であった多重再帰も深刻な問題とまではいかないレベルになったので、python勢も十分高いレート帯で戦えるようになってきたと言える。

解説AC

解説ACは全然悪じゃない。
人間心理的にどうしても「自力で解ける」ことが重要視されがちであるが、コンテスト以外では「自力で解けること」など全然重要ではない。
**一番大事なのは「解けなかったものが解けるようになること」**であるから、15分考えて何もできないならさっさと解説を見るべきだし、30分考えて計算量の改善が思いつかなかったら解説を見るべきだし、40分考えてWAが消えないならテストケースを見るべきである。
うんうん唸ってるのが楽しいのであればそれでもいいが、実力を伸ばすという観点で言うならその時間で解説を読んで「なぜ解けなかったか」に時間を割いた方がよっぽどいい。

今後の目標

AtCoderを始めた頃は青になるのが大目標だったので、それはひとまず達成したことになる。
ここから先レートをあげていくにはさらなる努力を要する(それこそAtCoderのコンテストだけでは厳しくなってくるだろう)ので、そこまで自分のモチベが保つかどうか、といったところだろう。まぁやってみないと何ともわからないが。
勿論コンテストに参加するだけでも楽しいのだが、折角やってるのであればレート向上を目指して頑張りたいと思うタイプの人間なので……
とりあえず今後もレートを伸ばすことは意識して取り組んでいきたい。

6
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?