CとEの2完（「CEの2完」と書かないのはコンパイルエラーに見えてしまうからだ）。
C - Same Integers
n=3として入力を受け取りソート。最大値との差が重要（全体に定数を足しても答えは変わらない）。最初は1つずつ（a[0]とa[1]を）処理していたが、サンプルも合わないし偶奇4通りで場合分けとか考え始め、偶奇が一致すれば簡単だと気づいた。両方奇数なら両方1以上だから、その2つを選んで1増やせば両方偶数のケースに帰着できる。偶奇が一致しないなら必ず1個余るので、そこを2増やし他を1増やせばいいしそうするしかない。
6分台AC、そこまで速いわけではないが、考えた内容を見ればいいテンポで進めていてまあ満足のいく出来。
D - Worst Case
「なんだ簡単じゃないか」という見た目。考えていくと、内包されている困難に気づいていく、というのがいつものパターンだが、2回のコンテストの総合スコアによる順位が相異なると誤読。スコアが同じでも順位は異なりうるのでは？とも考えたが、なんかサンプルを適当に計算した感覚でアクセプトしちゃったんだなあ。
まあ適当にsqrt(A*B)で計算してサンプルと全然合わないからなあ。なんかそういう難しい問題だと思ってしまったんだ。いや実際難しいけど、解けるかもしれないとは思える難しさだったのに誤読というか誤解や思い込みで絶対に解けない問題にしてしまった。
結局なんでクエリだったんだ。コンテスト中は、100msくらいの前準備をする問題かと思っていた。sqrt(10^9)以下の素数を求めるくらいしか思いつかんかった。それはそんなに時間かからんよな。
E - Tozan and Gezan
手で色々試して、どんな形の問題か探っていく。暗闇でわしわししてる感じ。和が等しいという条件を想像するのが自分にとって難しい。小さい例で過学習されて、Aのほうが大きいペアがたくさんある状況を考えない。
先手は「いましかできないことがある」と言って、Aのほうが大きいところを減らしていく。後手は「いつかやらなきゃならないことがある」と言って、Bのほうが大きいところを減らしていく。これが見えて、解けそうだと思った。
ARCのEって、よくこういうのあるよね。簡素な法則を見つけるだけと言えばだけで難易度がよくわからんやつ。
F - Normalization
解けないにしても、不変量（mod 3）が見えなかったのは悲しいね。
