終了後36.8。最近ABCは、過度な緊張をせずそれでいて始まったら体温が少し上がる程度に集中できて、いい感じだ。レーティングが低い状態なので、この結果でも微増。それはそうとtokuminiさんに追いつけないのは悔しい。コンテスト内容はわりと満足。Fを全然考えないまま残り10分になって完全に失敗したと思ったが、想定誤解っぽいのを提出することができた（Fをやらずに終わるのがすごく嫌だったが、最低限できた）。
A - Password
3乗。一瞬3^Nと迷う（Nが桁数という言語化できないレベルでの誤解かな）。
B - Buffet
めちゃんこ難しいB。最近簡単すぎたのでこのくらい難しいのを望んでいたけど、こういう系統の難しさは別に面白くないからなあ（単に苦手分野なだけでは？）。満足度Cを得る条件をAの入力時に処理したが、実装はすぐ浮かんだけどちゃんとした理解は本当に難しかった。
C - Maximal Value
そこそこ悩む、いい感じのC。問題文にはmaxと書いてあるのに実装にはminが出てくるのが面白い。最初、b[0]だけ特別扱いしてn-1回ループを回そうとしてた。n-2回なのね。解けるかどうかという意味では簡単なんだけど、解き進める中で「へーそれ知らなかった」というのがいくつか出てきてやりがいがあった。
D - Face Produces Unhappiness
難しそうに書いてあるけど典型じゃんと気づく（ややがっかり感ある）。こうなると、問題文から真面目に考えるのではなく、LとRの切り替わり回数だけが重要だとほぼ確信したうえでそれを証明する方向で考えることになる。ちゃんと証明できたわけではないが、まあよさそうなので提出。
E - Second Sum
1番目ならできるかなあとか考えつつ。最初に考えたのは、全体の1番と2番を取ってきてそれらを両方含む区間を処理して、あと1番だけを含むのと2番だけを含むのと1番と2番の間にあるのと場合分けする（そういえば1番も2番も含まず1番と2番の間にもない区間を見落としてたな）。しかし、複雑すぎてこの方針では解ける気がしない。ここでセグ木の匂いを感じ取る（昨日yukicoderでセグ木コンテストがあり、AtCoderではめったに使わないよねとツイートした）。でもBITで済むねｗ。Pを大きいほうから追加していく。すると、自分より大きいものが指定区間に何個あるかがO(logN)でわかる。方針は、各P_iが2番目になる区間の数をカウントするというもの。すぐ左の大きいやつを含むかすぐ右の大きいやつを含むかしかないのでいける。BITは二分探索できるけど、さすがに使い慣れないので普通に（10^5なのでO(Nlog^2N)も余裕）。左右両方を書かないといけないので（今思うと実装量増えても右だけにするって方法もあったな）かなりしんどい。両側について一番近い大きいやつの位置を求め、右側の大きいのをとるときは、左側が0個の範囲*右側が1個の範囲。右側が2個以上も含めてたり左側にそもそもないときの扱いとか無限にバグらせてINF時間が過ぎた。左側の二分探索ほんとに苦手。これ捨ててFに行くことも考えたけど、まあ今回は簡単な（）Eを手堅く取りに行く。色々な立ち回りができてるのいいね。最後にn * (n - 1) / 2を足すように最初してたけど、期せずしてちょっとした検算になった（0-indexedにすると1が0になって答えに寄与しなくなるのもなんか混乱して時間食った）。実装に1時間近くかかってる（つらい）。復習のしがいはある。
F - Many Slimes
Eの実装に注力する前に一応読んだ（読んで寝かせると時間を有効に使えそう）。ただちゃんと読めてなかった感がある（Eの早解きになる可能性もあるわけであまり時間かけたくなかった）。なんか「最初のスライム」と「生成されるスライム」の区別がわからなくて、「あなたは最初にスライムを生成します」みたいな話かと思ってた。スライムによって生成されるスライムのことね。
最初のスライムは（体力を変えないまま）最後まで残る。大きい順にソートしてよい。一番大きいやつが、最初のスライムなのは確定。その次も確定では？その次も小さいのを生成するメリットないよね？ということで貪欲を書いて提出、WA。なにげに5分くらいでこれ実装できててすごい。4分前のWAで実装ミスでもなさそうなので望みはうすい。でも、「この方針の穴はどこだろう」と悩むところまで短時間で行けたのはうれしい。Fに挑戦することもないまま終わるのかと思ってたから。これはちゃんと挑戦できている。短時間だけど、最低限よかった。
（追記）当時考えていたのは下のような例。
5 9 8 8 7 3 3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 1 1 1
貪欲にとっていくと3が多くて無理になる。これを、先に3を使うことで改善できないかと考えていた。しかし、小さい数をとるメリットはない。よってこの貪欲は正しいという結論になってしまった。さて、布団の中で次の例を思いついた。
3 9 8 8 8 3 3 3 2
8が多いからダメと判定するか？いや、9は8を何回でも生成できる！つまり、これも最初の例もYesだ。残った中で最大のものを常にとる必要はない。大きいのがあるのに小さいものをとるメリットはないが、とれる中で最大なら残った中で最大のものを後回しにできる。なぜ気づかない。まあそれは問題が絶妙に難しいからだが、なぜ証明できないのに納得してしまった。証明が苦手すぎる。ゴミのような感情に頼って問題を解いている。
