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

脳log[20250705]



2025年07月05日 (土) [AtCoder] 今日はデンソークリエイトプログラミングコンテスト2025(ABC413)があった。制約に泣かされた F 問題。■A 問題 Content Too Large。A 問題で DP はありません。A の合計と M を比較する。■B 問題 cat 2。全部作って許される制約。改行をちょん切るのを面倒くさがっても許されるかなと(一度書いたものを消して)試してみたけど、サンプルが合わなかった。AB+CD と ABC+D を同一視できなくなるからそれはそう。面倒くさがった結果手を加えることに矛盾はありません。■C 問題 Large Queue。タイプ2のクエリが長さを超えることはないという制約を読んで条件式を1つ省いたんだけど、実は省いてはいけなくて RE を一度出した。ぎりぎりを狙うのに軽率すぎるんよ。■D 問題 Make Geometric Sequence。0を含まないのが温情なのか? それでも公比 1 と公比 -1 と公比が負のケースが罠になる。それぞれ場合分けをすれば対処はそれほど難しくない。最後に残るありふれたケースの判定は、3項(a,b,c)を並べて前後2項で r に関する等式を作って(b/a==c/b)、通分したら b*b==a*c で判定できるらしかった。なるほどゼロがあると土台が成り立たない。Ruby には組み込みで Rational (有理数) クラスがあるのは知ってるんだけど、計算量が読めないのと、Rational がないと解けないとなると Ruby でないと解けないということになり、それは甘受できないのだった。オーバーフローに対する警戒心のなさなど普段は Ruby に甘えまくりだけども、謎の線引き。■E 問題 Reverse 2^i。2分割してそのままか前後を入れ替えるか。■F 問題 No Passage。やるべきことがよくわからなかった。できるできないは別として G 問題の方が求められていることがわかりやすかった。F 問題。あるマスの移動先(最大4つ)のうち2つまでゴールまでの手数が確定しているなら、大きい方+1 の手数でゴールできる。0手ゴールからじわじわ確定範囲を広げていく。終了2分前に間に合わせた提出 #67355089 は TLE×6 だった。判定と書き込みに時間差を付けてきっちり分けないとサンプル3が合わないのだけど、その結果キューに同一座標が複数回入るようになってしまった。9行目で事後的に弾いているけど、Ruby でその無駄は許されなかった。キューに入れましたよということだけを記録するメモを用意すると TLE×5 に減ったけどまだダメ。2次元座標を1つのキーにして配列参照を減らしたら TLE×3 だけどまだダメ。予めキューを H*W 本用意するのをやめて今と次の2本だけにしたり、キーの増減を代入してしまって演算子を減らしたりしてやっと AC (#67360123)。時間内の提出はたしかに多少の無駄はあったけど、許されないほどではなかったと思う。そこから AC までの改善は、はっきりいってしょうもない。■G 問題 Big Banned Grid。問題の概要はすぐわかる。それをどう実装するか。思いつけば実装は軽かった。提出 #67363448 (AC)。グリッドの左辺下辺に接した障害物からスタートして、障害物を伝って上辺右辺まで辿り着けるかどうか。F を捨てて G に粘着していれば時間内に解けたかもしれんけどね、気持ちが負けてるからあわよくば G をという発想にならないのであって、実際には可能性はなかった。■G 問題は ARC076-C「Connected?」っぽさがある。どちらも何が障害なのかを見切るのが大事で、実装は難しくないという点が共通。障害の正体も共通。これは解いたあとの感想であって、コンテスト中に一読したときの印象はフレンズさんのツイートの通りに ABC361-G「Go Territory」だった。あれは UnionFind なんだけど碁石(障害物)の配置から隣接頂点を引くあたりの実装が重かったので、今日の問題におすすめできる解法ではない。今日のは障害物で BFS/DFS をするだけで良かった。■■■F 問題。自分のやり方は実はあまりうまくなかった。どうやっていたか。ゴールまでの手数が確定したマスがあるとする。これを自マスとする。その隣接4マスに未確定のマスがあるとき、未確定のマスの隣接4マスに自マス以外の確定マスがあるなら、未確定マスを確定予定であるとしてキューに入れる。これは自マスを中心とした周囲8マスに加えて上下左右に2マス離れた4マス(合わせて 12 マス)の確定状況を調べることになる。定数倍が重いですね。どうやら想定解法(フレンズさん情報)は訪問済みフラグを数値で持って2回目の訪問で初めてキューに入れる BFS であるらしかった。なーんだ。TLE×2。←想定解法でもダメです。提出 #67382500 (AC / 1440 ms)。自分の不器用な解法が 1941 ms だったのに比べると想定解法は 25 % 速い 1440 ms になるポテンシャルがあるみたいだけど、配列を1次元化するような定数倍の改善なしでは TLE が避けられないのに変わりはなかった。どうあっても制約に泣かされたんだな。制限時間が通常と違う 2.5 秒であることの意味は、C++ と Python で解法の優劣により AC と TLE が分かれるように制約と時間でぎりぎりの調整をしていますよ、ということであって、これは即ち Ruby では針の穴を通すような最適化をして初めて AC になるかもしれないし不可能かもしれない、ということを示唆している。要するに、2.5 秒を見たときから予想はしていた。だからこそ最初の提出からループを展開したコピペコードを書いていたのだけど、足りなかったのだなあ。■■■D 問題。半年前にあった ABC390-B に Geometric Sequence というドストレートに等比数列の判定を行わせる問題があったらしく(覚えていない)、自分の提出を見てみたらこれ #62034196。to_r して b/a を比較している。「Rational がないと解けないとなると Ruby でないと解けないということになり、それは甘受できないのだった」とはなんだったのか。きっちり楽してるやんけ。あ、でも次の日に今日と同じ式変形を試して提出してる (#62124460)。覚えてないけど。