/ 最近 .rdf 追記 編集 設定 本棚

脳log[20250119]



2025年01月19日 (日) [AtCoder] 精進。昨日あった ABC389-F「Rated Range」。これまで何度もこの日記にお風呂で考えてきたと書いてきたけど、とうとうお風呂に入る必要がなくなってしまった。服を脱いで入ろうとしているときにひらめいたんだけど、ある範囲のレートを1増やす操作を何度行っても、レートの序列が入れ替わることはないんだよね。操作の前後でソートされた状態が維持されている。q 番目のクエリの初期レート x が i 番目の大きさだったとして、値がある範囲である区間に1加算する操作を繰り返したあとでも、i 番目の位置にクエリ q の答えがある。提出 #61874909 (AC / 1265 Byte / 1075 ms)。最初の実装に 10 分、貼り付けた自分の BIT の使い方を間違えてデバッグに 15 分ほど。だけど問題を十分に理解して解法を導くまでにひと晩寝る必要があった(布団の中で考えようとしたらそのときまで解こうとしていた問題を覚えてなくてそのまま寝た)。F 問題の精進でけりがついたので A から E までについても書く。どこまでがふりかえりでどこからが精進でしょうか。喜んで書く気にはならない不本意な出来であるのは間違いない。■A 問題 9x9。スクリプトなのを利用して eval で。■B 問題 tcaF。Fact のリバースだということがわかるまでしばらく問題名を眺めていた。意味までは考えなかったけど今あらためて考えてみると、一般的に下りで定義される階乗を上り階段で計算するような解答になることを反映していたのだった。■C 問題 Snake Queue。累積和を伸縮すれば解けるんだけど、数字を合わせるのにかなり手こずった。なぜか。長さで定義されるヘビであるけれど、i 番目のヘビの長さは i 番目のヘビの頭の位置に寄与しない。このずれがわかっていてもややこしかった。■D 問題 Squares in Circle。結論を書くと、0.5×0.5 の正方形を単位として、ある x における原点を中心とする半径 R の円の Y 座標を求めれば、1×1 の正方形の数も数えられる。第1象限についてだけ考えて2倍したり4倍したりすれば良い。ただし X 軸 Y 軸に重なっている正方形だけは分けて考えなければいけない。ふりかえれば別に難しい計算ではないのだけど、このやり方でできるとわからなかったし、見通しが利かないなかで正しい式を見つけ出すまでにはそれなりの時間と試行錯誤が必要だった。■E 問題 Square Price。最初に提出したプライオリティキュー解が TLE だった。制約を見たら M の上限が 10 の 18 乗だった。キューから M 回取り出そうとしたら TLE になるのは当たり前。どうするか。ある程度の操作をまとめたい。二分探索でボーダーラインを決め打って、+1 個のコストがボーダーを超えない範囲で各商品を買う。その合計金額が M 円を超えない範囲を探る。ボーダーと合計金額に直接的な関係はないけども、連動していることでしょう。ここからが長かった。ボーダーラインから個数を求めるのに二分探索をしたら外の二分探索とあわせて log が2乗になって TLE だったから、式をこねくりこねくりして、いつまでもいつまでもこねこねしていた。この提出 #61841606 の6行目の式(k = (b/p+1)/2)がまったく一筋縄ではいかなかった。他にもね、14 行目と 15 行目にある2つの式 k*k*p(k+k+1)*p が似てるでしょ。自分の目には同じに見える。取り違えてもしかたないよね。それから、後半7行でやっているボーダーライン上のアイテムを買えるだけ買う処理だけど、これ単純に割り算で計算できるらしい。二分探索で求めたボーダーラインの意味を考えればその通りなんだけど、半信半疑になってしまうところがあると思う。■F 問題まで解ける問題が並んでいて、だけど時間内に解けたのは C 問題までってどういうことですか。最近の問題傾向のせいにしてもいいですか。自分は数字とか式を精密に扱うのはまったく苦手なので、たこ焼きに関する問題が解きたいです。文章で発想のヒントとなる過剰なディテールが与えられてるといいなあ。そして発想だけで解けるといいなあ。式変形とかまじ無理なんで、D と E が解けなかったのもそれが原因なので。■D 問題の早い人の提出を見てると、ループで1つの式の合計を求めて、4倍して1を足して答えにしていた (#61802287)。どういう見かたをすればそんなシンプルな理解に至れるのだろう。■F 問題に関連してセグメント木の max_right メソッドへの言及をいくつか見た。どうやらそれは前回の ABC388-F に関して自分が「セグメント木で解こうとすると、何をリクエストして何を得るかという検索インタフェイスがどうあるべきかがよくわからない」「懸案だった検索インタフェイスは左側の境界を与えて判定関数が true を返す区間の右端を探るメソッドということにした」(20250111) と書いていたメソッドそのものではないかという気がする。お名前いただきました。■E 問題。「制約を見たら M の上限が 10 の 18 乗だった。キューから M 回取り出そうとしたら TLE になるのは当たり前」とさっき書いた。AC までいった今だからわかるけど、キューから取り出す回数の上限は M 回ではない。(k+1)^2-k^2 = 2k+1 であることから、+1 個のコストは個数に比例して上がっていき、その和は2乗のオーダーになるから(Σk = n(n+1)/2)、取り出す回数は M の平方根である 10 の9乗に比例する。ていうかコストの定義が kkPi なのだからそれはそう。それでもやっぱり TLE になるように M の上限が 10 の 18 乗程度に定められている。■E 問題。ボーダーラインを求めてさらにボーダー上の境界に注目する問題としては PAST8-I「/2 and *3」を思い出す (#26574800)。知ってる問題だったんだよ。解法の枠組みが自明で、でも式変形が難しすぎた。