脳log[2024-07-27～]

2024年07月27日 (土) [AtCoder] 今日は日本レジストリサービス（JPRS）プログラミングコンテスト2024#2（AtCoder Beginner Contest 364）があった。先週(20240720)と似たようなことを書いてもいいかな。Ruby にとっては D 問題が難しすぎて TLE が解消できなかった。D と F を見比べて、F の方に見込みがあると思って F 問題に８割方集中していたが時間内には解けなかった。終了 11 分後に F 問題の AC が出た。あとちょっとで解けたと思えばこそ得点にならなくてくやしい。■A 問題「Glutton Takahashi」。サンプルの２で示されているのは親切だけど、そこそこ殺意の高い罠がありますね。全部食べたあとで気持ち悪くなるパターンがある。`sweet\nsweet` を検索していたのを修正して `sweet\nsweet\ns` を検索するようにした。■B 問題「Grid Walk」。やります。B 問題にしては実装が重め。グリッドのサイズが小さくても実装量が減るわけではないんだよね、当たり前だけど。そこんとこ承知してくれているかな？■C 問題「Minimum Glutton」。C 問題で DP か？と一瞬身構えたけど、最小値を求めるということで、２通りの貪欲法を比較するだけ。大丈夫です、最大値を求める DP 問題は E にあります。■D 問題「K-th Nearest」。二分探索してくださいという問題にしか見えなくて他に方法が思いつかないんだけど、制限時間３秒のところ、(１割増しの 3.3 秒ではなく) 3.22 秒かかって TLE だったので、220 ms ほどの高速化が必要。どうするの？■E 問題「Maximum Glutton」。C 問題の難しい版。甘さとしょっぱさの組み合わせを状態のキーにはできないけど、甘さとしょっぱさのどちらかと個数を組み合わせてキーにすることはできる。甘さをキーの１つにしたら、しょっぱさを最小化する DP をする。これもサンプルが教えてくれたんだけど、A 問題と同じ罠があります。同じ罠に落ちかけました。■F 問題「Range Connect MST」。どういう風に辺を引くことになるのか、イメージがしづらい。木なので本数は N+Q-1 本だと決まっている。それを最大 N×Q の組み合わせからどう選ぶと全域木になるのか。あれこれ考えてようやく納得できたのは、i=1..Q において、Li..Ri のあいだに連結成分が g 個あるなら、g 本の辺を引くのだということ。両手の 5+5 本の指を使って考えると、それで N+Q-1 本の辺が選ばれるようだったのでそう思った。答えが合わなくて時間内に提出できなかったんだけど、原因がしょうもなくて、貼り付けた BIT のイニシャライザにある初期化コードが今回は不要だと思って削除したけど、削除してはいけなかったという、そういう理由で答えが合わなかった。たとえばヒープだと、ソート済みの配列を内部データにする場合、初期化の必要がない。ソート列はそのままでヒープの要件を満たしている。だけど BIT の内部データは違うんだなあ。解ける問題だったなあ。１から数年前の自分なら解いていたなあ。■自分のすべての提出。最近ユーザー名の横に表示されるへの字。ノイズではあるんだけど、水色でもまだ 1500 台を維持しているなという慰めにもなっているもよう。■精進。D 問題。Q のループの中で二分探索をする中で二分探索を２回行って TLE を出していた。二分探索の上限を指定せずに TLE×11。上限を指定して TLE×7。最も内側にある２個目の二分探索を省けるときは省くようにして TLE×1。最内の２個目の二分探索を完全に省いて AC。これが 1765 ms なんだけど、Ruby で 627 ms で解いている人がいるんだよね。気になるけどネタバレは嫌だ。■D 問題。別解。提出 #56088391 (AC / 325 Byte / 340 ms)。log １つでできると読んだので、k 幅のウィンドウを二分探索で置いてみた。判定条件は、右端の要素が初めて左端の要素よりも b から遠くなる瞬間。そのひとつ手前では逆に、左端の要素が右端の要素より b から遠くなっている。この両者を比較する。二分探索の高速化っていうと尺取りが定番なんだけど、だから昨日はその方面で TLE 回避策を考えたりしてたんだけど、この D 問題はウィンドウの幅 k がクエリごとに可変だから、尺取りはうまくない。今日の提出では同じ二分探索を使っていてあまり違いを感じないんだけど、よく見れば二重の log が一重に減っている。log １つの差ってたしかにこれくらい微妙なものではあった。Pairs を解いていたときに書いている。「log ひとつの差ってちょっとした違いなんですよ。ちょっと見る角度を変えるだけ」。提出したあとでもういちどさっき読んだブログを読み返すと、まんま自分の提出がやっていることが書いてある。「初めて左端のが遠くなった場所を見つけてその一つ前も（存在すれば）候補なので比較して」。なんかよくわからんなあと思いながら読んでいたけど、実際今も「自分より１離れたもの同士を比較」「長さが１短い区間を考えて」「初めて右のが遠くなったら左のを付け加えてそれがそのまま答え」とかよくわからないんだけど、必要なことは一度読んだだけで頭の中に入ってるんだな！自分では思い出せないだけで。

ツッコミを入れる

2024年07月20日 (土) [AtCoder] 今日は AtCoder Beginner Contest 363 があった。Ruby にとっては C 問題が難しすぎて解けなかったが AC を出している人もいる。精進が足りない。Ruby で通している人が１人でもいるなら自分も通せなければいけない。なんなら自分が最初で唯一の AC でありたい。E まで解いてから F と C を見比べて F の方に見込みがあると思って F に専念していた。その見込みは間違っていなかったが、TLE を出したあと誤った解法の実装にのめり込んでいる内に時間切れになった。実は関数に引数を１つ付け加えるだけで AC になったのだが、30 分ちかく時間を残していてそれに気がつけなかった。くやちい。■A 問題「Piling Up」。全パターンの差分を並べてもっともふさわしいものを選んだ。短い解答を見てみると、すべての基準値が 100 の倍数だということを利用していた。そういう法則がすぐに見抜けないし、見抜けるまで問題を読んでもいない。■B 問題「Japanese Cursed Doll」。ソートして P 番目なんだけど、昇順ソートして前から P 番目ではない。それを間違えていてもサンプル３を試すまでは答えが合うのが怖い。■C 問題「Avoid K Palindrome 2」。順列全列挙では間に合わなかった。どうやるの？ C 問題で順列全列挙以外はやる気がないよ。■D 問題「Palindromic Number」。これぞ ABC の D 問題、緑 diff って感じの問題。実際の難易度が何色かはまだ知らないけども。順番に生成して 10^{18} 番目まで数えることはできないので、まずは桁数を決めて、桁数が決まったら先頭の桁から確定していった。■E 問題「Sinking Land」。UnionFind です。最大６桁の数字が 100 万個という入力はそれだけでけっこう重い処理。正確さを重視して富豪的に書くと AC と TLE のボーダーを超える可能性があるので、全体を通して最初から書き方を選んでいく……余裕があるといいね！グリッドの各マス＋海用に１個の頂点を用意して、海抜の低い順に、自分より低い頂点とのあいだで結合する。海のマスを数えたら陸のマスが求まる。■F 問題「Palindromic Expression」。やるだけの問題だと思うんですよ。解けたはずだと思えばこそ悔しい。まず中心に N を置きます。これが最初から条件を満たしているならこれが答え。さもなければ、N を LMR で置き換える。L と R は左右対称でなければならず、M に対しては再帰的に同じことを繰り返す。２数の積で N を割っていくので、N≦10^{12} だから、L,R として列挙する数は 10^6 個程度に収まって許されそう。終了条件を N<[L,R].min**2 として愚直にやったら TLE だった。N や M に関して結果をメモしたら数は減ったけどまだ TLE だった。AC になった鍵は、ABCDE という状況で A<=B でなければならないと定めたこと。こういう方針自体は TLE が出た直後に考えて実装に取りかかってるんだけど、なぜか実装の途中で L が回文数でなければいけないという条件が加わっていて、その実装に忙殺されてしまっていた。なんでだよー。■自分のすべての提出。■F 問題。日記を読み返すと「なんでだよー」の答えが見つかるんだよなあ。LMR の L と R に関して、「L と R は左右対称でなければならず」と表現しているところに誤りの種がある。左右対称なのは LMR 全体なのであって、L と R について書くなら表現を改めて、「L と R は反転して一致しなければならず」とする方がよりふさわしいと思う。雰囲気で理解して細部がぼんやりだから途中ですりかわるんだよ。コンテキストが遠ざかったときに左右対称という断片に引っぱられて勘違いをする。■精進。C 問題。Array#permutation で N の階乗通りを列挙する代わりに、再帰関数で同じ文字を区別しないで列挙するようにしてもまだ TLE だった(#55827067)。X で読んだ通りに、１度しか出現しない文字を統合する前処理を施すことでさらに列挙数を減らすことができて AC になった。提出 #55827317 (AC / 536 Byte / 584 ms)。300 点問題にかけていいコストではない。同じ時間で D と E と F を解いたあとで初めてペイする。■■■D 問題。「N=19999のとき、正解が99999999(8桁)だけどコードが出す解が9999999(7桁)になっちゃうみたいですが通りはしました」と投稿している人がいて、試しに自分の AC 提出(#55797000)を実行してみたら 100000001 (９桁) になって、どちらでもなかった。投稿主の提出(#55831310)をコードテストで実行してみたら、たしかに書いてある通り７桁の９が出力された。正しい答えはなんなんです？ Ruby の AC 提出２、３個で多数決をとったら、正しい答えは 99999999 (８桁) らしい。入力と出力の見た目には桁数が違っても維持されるパターンが見られるのだけど、自分の提出は N=100000 型とか N=999999 型では他と一致していても、N=19999 みたいな型の入力に対してはずれている。だって N=199 と N=200 の答えが同じなんだもん。サンプルの３を合わせるために ≦ を < に修正してから提出したのだけど、たぶん修正すべき場所が間違っていた。ザルなジャッジにお目こぼしされてしまったか。提出 #55833437 (AC)。after_contest はまだないみたいだけど修正版を提出。N=19...9 と N=20...0 っていうのは、出力の桁数が変化するという点でのコーナーケースみたい。テストケースにコーナーケースがなかったんだね。■E 問題。別解。提出 #55860799 (AC / 523 Byte / 707 ms)。UnionFind 解が #55800705 (AC / 524 Byte / 1629 ms) だったので、長さはほぼ同じなものの、時間は倍以上早くなった。別解は BFS。プライオリティキューすら必要ではなかった。■精進。「砂の城 (Sandcastle)」。E 問題と似た問題だと名前が挙がっていたので。提出 #55862476 (AC / 354 Byte / 578 ms)。たしかに、これも BFS だった。かなりシンプルに書けたと思う。

ツッコミを入れる

2024年07月17日 (水) 二三日は何日なのか問題。もちろんこれが問題になったことはない。自分としては、四六時中や四十九日、七十五日、三々五々から演繹するとニサンニチになるしかないと思うのだけど、実際にそうだったことがあるのを知っていることからもそう考えるのだけど、今 ATOK で明鏡国語辞典を引くと「しじゅうく‐にち【四十九日】〘名〙人の死後四九日目に当たる日。また、その日に行う法要。七七日(しちしちにち)。」とか書いてあって、これもうわかんねえな。いやホントはわかりますよ。「四十九日」「七七日」の２つと「四九日(目)」とでは使用時期にずれがある。辞典の言葉は収録される言葉よりも新しい。23 日を二三日と書くことの帰結として、10 月が一〇月になっていたのが先々週読んでいた小説。何を今更感しかないけども、そうなんだ、そりゃそうなるよな、だけど気持ち悪いな、その○はなんなんだ、漢字ではないよな、とひっかかってしまったのが今日の日記になっている。十月って書きたいよ。■ATOK で 10 を変換して出した一〇で使われているのは○ではなかった。U+3007 は「漢数字ゼロ IDEOGRAPHIC NUMBER ZERO」であり、U+25CB 「丸印，白丸 WHITE CIRCLE」とは異なる文字だった。〇が比較すると新しい字だけど数百年はさかのぼれるみたいなことが Wikipedia の漢数字のページに書いてある。お前漢数字なのか。漢数字とアラビア数字を区別して一方では位取り記数法を認めたくないっていうのは、単に好みや慣れや、旧弊に囚われているってだけなのか。自分はこれからも区別して用途を分けていきます。■用途を分ける(漢数字では位取り記数法を使わない)ことの別の一面は、「健康第１」とか「３位１体」とか「別の１面」とは書かないということ。算用数字を使うのは１、２、３と数を数える場面だけでいい。X と X+1 が可換な場合だけでいい。

ツッコミを入れる

2024年07月16日 (火) 子供の頃にスーパーボールで遊んだ記憶。今でも理解できないし説明できないのだけど、たとえば床に２バウンドさせて壁にぶつけるとする。１バウンドした位置から A の距離で２バウンドし、そこからさらに B の距離で壁にぶつかるとする。この A と B の距離(あるいは時間)の比率が跳ね返ったボールの跳ね方に反映されて、不等間隔の規則的な跳ね方を繰り返す。だったよね？おもちゃにも流行り廃りと技術や素材のアップデートがあって、今の子供はスーパーボールなんかでは遊ばないかなあと思ったので書いた。

ツッコミを入れる

2024年07月13日 (土) [AtCoder] 今日はトヨタ自動車プログラミングコンテスト2024#7（AtCoder Beginner Contest 362）があった。特に書くことはないけども参加記録として。自分のすべての提出。■A 問題「Buy a Pen」。３通りなのでどうとでも書きます。■B 問題「Right Triangle」。２乗のまま整数のまま三平方の定理で判定します。■C 問題「Sum = 0」。最初はすべて L に寄せて和の最低値を求めます。あとは和が負である限り、各組 R-L を上限として右に寄せていきます。■D 問題「Shortest Path 3」。辺だけでなく頂点にも重みがあって何かが変わるかなと考えたけど、普通に普通のダイクストラ法のままだった。■E 問題「Count Arithmetic Subsequences」。N の制約が 80 以下と非常に小さい。これだけ小さいと O(N) と O(logN) の差よりも定数倍の違いの方が大きくなりがち。80 の３乗が大した大きさでないことを確認して愚直３重ループを書いたら TLE が出てびっくりした。３重ループと書いたけど実は３つ目のループは再帰関数の中に隠れている。それって３重にとどまらないのでは？やばいのは公差が０のケースなのでそれだけ別で数えて AC。■F 問題「Perfect Matching on a Tree」。マッチングとかフローとか辺被覆とか点被覆とかはわかりません。「最大重み最大マッチング」てなんだったんでしょうか。まんまと「知らないキーワード、怖い」と G 問題に流れていっちゃったけど、この問題は難しいことは考えずに、木の中心で頂点集合を２つに割って組み合わせたらどうかなと思った。WA だった。この問題の何が問題なのかがわかっていないか、うまくできなかったか、どちらなのかもわかりません。とはいえ、うまくできていなかったのは間違いない。中心に頂点があるとして、中心から３本以上の辺が出ている場合が考慮できていなかった。■G 問題「Count Substring Query」。ミシシッピの s が足りないのが気になってしょうがない。なんでコンテスト中に辞書を引いてるんだ……。F 問題より見込みがあるかと先に考えていたけど、数を数えようとするとどうしても２乗の時間がかかりそうになる。接尾辞配列を使うだけみたいなツイート(？)を読んだ。その使うだけもできないのだから惜しくも悔しくもないけども、接尾辞配列とか完備辞書とか Trie とか、見て見ぬ振りをして実装せずに来たツケなのは間違いない。「SA-IS 法のメモ - まめめも」８割くらい読んだ。しれっと挟まれた翻訳者自らの宣伝だけど、その本はもう持っている。悲しいかな理解が追いつかなくて積まれているけども。SA-IS 法に話を戻すと、２割が完遂できなくて写経することしかできない。たとえ写経でもするべきなのかなあ(やらないつもり)。やると書いて、やる、有言実行メソッドと、やらないと書いて、やる、天邪鬼メソッドの両方があります。自分のモチベーションをより高める方を選んでどうぞ。■■■精進。F 問題。提出 #55644781 (AC / 1365 Byte / 636 ms)。やりたいことのイメージは合ってたみたい。中心で２つかそれ以上の頂点集合に分けて、異なる集合から１つずつ選んでペアを作る。それをどうやってうまくやるか。葉から処理を始めて、親にどんどん頂点集合を集約していく。その集合の大きさが過半数になってはいけない。最終状態がいくつか考えられる。わかりやすいのが、集約された結果ある頂点とその２つの子が残り、そのサイズとつながりが (N/2)-(1)-(N/2) である場合。左右の子から１つずつ頂点を取り出してペアを作ればいい。総頂点数の偶奇により中央に頂点がない (N/2)-(N/2) のパターンも考えられるがやることは同じ。もうちょっとわかりにくいのは、ある頂点が３つ以上の子を持っていて、どの子に軸足を移そうとしてもその瞬間に他の子が過半数の大きさの頂点集合を作ってしまう場合。最も単純なケースは、２から N のすべての頂点が頂点１につながるスター型のグラフ。頂点１を中央に据えて、他のどの子の頂点集合もサイズはたったの１だけど、どの２頂点もマージできない。そんな感じで頂点集合をマージできるだけマージして残った頂点集合の集合からペアを作るのが次のステップ。同じ集合の中からペアを選びさえしなければいい。だからプライオリティキューを使ってサイズの大きい頂点集合から優先して２つ選んでペアを作ることを繰り返した。もっと洗練されたうまいやり方と考え方が絶対にありそうだけど、AC なんやしまあええやろ(向上心のない怠惰な態度)。あと、自分が中心と呼んでいるものに重心という名前がついているらしいのは何か所かで読んで把握している。■■■F 問題。某週記を読みまして DFS 順でペアが作れると知った。DFS の行きがけ順(に限らない？)に 27 個ないし 26 個の頂点を `A-M$N-Z` と並べたなら、`(A,N),(B,O),(C,P),...,(M,Z)` のペアを作る(のだと思う)。ローカリティに注目すればなんとなくそれでいいような気がするし、逆に両端からペアを作っていくのがダメなのもわかる気がするが、いつでも絶対それで OK とはわからない。■自分の解答の後半のステップはプライオリティキューを使わないで、単純に入れ子配列をフラットにして真ん中で切ってペアを作るので良さそう(`C.flatten!; C[C.size/2..].zip(C)`)。どの解説もそういうペアの作り方をしてるので。どの頂点集合も過半数に届かないようにしているのだから、たしかにそれで同一集合からペアを作ることはないみたい。それと、DFS での頂点の並べ方は帰りがけ順でも OK と解説に書いてあった。

ツッコミを入れる

2024年07月12日 (金) PS5 のコントローラーって臭くなりやすいと思う。手に汗握る状況が多いというのが根本にあるとしても、PS4 まではコントローラーが臭いとかコントローラーを握っていた手が臭いとかが気になったことはなかった。ウェットティッシュでよく拭いてリセットしても数日で臭くなる。材質かな。表面処理かな。何が違う？

ツッコミを入れる

2024年07月08日 (月) 先日自転車のハンドルを掴み損ねて上半身から地面にダイブした。雨の日で手袋をしていたので手は平気。手袋も無事。ズボンの膝がちょっとほつれてるけど穴は空いていない。一番のダメージが肋骨にある。指で押さえると痛む場所が１か所特定できるだけなのだけど、肋骨の痛みによる QOL の低下が著しい。咳をすると痛む。深呼吸をすると痛む。布団でうつぶせになると痛む。日常の、ささいな、何かしらの行動に対するリアクションとして痛みが発生することのなんと不自由でうっとうしいことか。年を取るとたんが絡むんですよ。若い子みたいにのどの奧がつるっとしてないんで。咳払いでいっときの疎通を確保しようとするたび肋骨が痛む。つら。■「雨の日で手袋をしていたので」と書いたことについて。まぎれもない事実なのだけど、雨の日でないなら手袋をしていないという裏読みをさせてしまうとしたらミスリーディングである。ある命題の真偽と裏の真偽に関連はないのだとしても。誤解がないように書くと、雨の日だから雨用の手袋をしていた(晴れの日は晴れ用の手袋をしている)。どちらも手のひらは革で丈夫。もし「手のひら以外は革でない」という裏読みをしたなら、半分間違っている。

ツッコミを入れる

2024年07月06日 (土) [AtCoder] 今日はデンソークリエイトプログラミングコンテスト2024（AtCoder Beginner Contest 361）があった。自分のすべての提出。■A 問題「Insert」。問題名の通りに Array#insert を呼び出す。いつまでも引数の順序が覚えられないメソッド。今日はリファレンスを引くのも面倒がってテキトーに位置と値を並べて呼び出して結果を確かめた。■B 問題「Intesection of Cuboids」。現在は修正されているタイトル名のなごりが見える(イン「テ」セクション)。コンテスト中に気が付かなかったのは不覚というほかない。誤字脱字はかなり神経質に駆逐したいタイプなので。さて本題。頭で立体交差を想像するのは難しいけども、これは１次元の交差を３回確かめるだけ。制約を確かめてから、ソートしたりイコールの場合を考慮したりしたけども、今改めて制約を見るとちゃんと不等号で大小関係が規定されていた。目がついていない。言い訳をすると、同じ範囲の制約がたくさん並んでいたから、すべての入力値が範囲内で無制限の値を取るのだと思ったのだった。６つも 12 個も同じようにたくさんでしょうよ。目がついていないのと数が数えられないのと、どちらがましか、言い訳になっているか。■C 問題「Make Them Narrow」。ソートして最小値を決め打つ。`Array#each_cons` がおそらく線形時間を要するせいで TLE を１回出した。たしか以前も同じメソッドで TLE を出している。学習しないな。だけども、配列の dup や shift、pop では配列の要素レベルのコピーが抑制されると知っているから、配列から固定サイズの部分配列を切り出すのに単位時間しかかからないと期待するのは当然じゃない？ each_cons が Array#each に基づいて実装されてるとしても、一度の each_cons 呼び出し(と複数回のブロック実行)で線形時間しかかからないなら TLE にはならなかった。尺取りをするなら TLE にはならない。ブロック実行のたびに線形時間かかっていて、each_cons 全体では２乗の時間がかかっているからこそ TLE になる。これが予想外。■D 問題「Go Stone Puzzle」。制約がごく小さいのでメモして BFS をする。実装でいろいろミスをした。たとえば (1,2)、(3,4)、(5,6) みたいな (奇数番目,偶数番目) のペア単位でしか交換できないと思い込んでいたり。そこはちゃんとサンプルで落とされたけども、見るべき要素数が N ではなく N+2 だったりも。15 分かかった。■E 問題「Tree and Hamilton Path 2」。ARC179-D Portable Gate の簡単バージョン。精進記録はこちら>20240602。根を決めて DFS ですべての頂点を訪れてまた根に戻ることを考えると、すべての辺をきっちり２度ずつ通るのでコストの上限がまず決まる。本問題では根に戻る必要がないのでどれだけのコストが節約できるか。直径。自分の提出がすでに求まっている直径を再帰関数で改めて求めているのは、紆余曲折の結果なのです。引き算で求めるのではなく、２種類の再帰関数で積算して答えを求めようと迷走していたなごり。プライオリティキューを貼ったけど、いらなかったらしい。根からすべての頂点への距離を求めているのだし、各頂点へのパスは１つだけなのだから、それはそう。■F 問題「x = a^b」。苦手な苦手な数学問題。指数を３以上に決め打つなら N 以下の全ての立方数、４乗数、５乗数(って呼ぶのか知らないけども)……を列挙して重複を排除できる。じゃああとは最大で 10^9 個ある平方数をどうやって数えるかだけ。すでに数えた立方数、４乗数……が平方数でもあるかどうかを確かめて重複を除外することでクリアした。この問題の提出でも自分は変なことをしている。b を固定したときの a の最大値を Math.log で求めてからすべての a^b を列挙してるんだけど、それだったら a=1 から始めて N<a^b になるまで a+=1 を繰り返せばいい。コンテスト中はそこまで頭が回らないんだなあ。■G 問題「Go Territory」。解けてないよ。サンプルにあるように囲われている格子点を数えたい。縦横斜めに並んだ石のあいだで UnionFind をして、まずは輪っかを作っているかもしれないグループを特定した。次にグループを構成する石の周囲８マスから BFS を開始して孤立している格子点の島を数えようとした。どこで探索を打ち切るか。グループを構成する石の X 座標 Y 座標の最大最小を限度にして BFS を打ち切って孤立していないと判断をした。これでサンプルは合ったけど、WA があるかもそうだけど TLE は間違いないと思うんだよなあ。おおざっぱに２乗の範囲を塗りつぶそうとしてるわけだから。■コンテスト成績証。黄パフォに限りなく近いいいパフォが出たけども、前回(ABC が Unrated 判定だったので配点と Writer から必敗を覚悟して出た ARC)の緑パフォの傷が癒せただけなんだよなあ。F 問題まで４桁人数が解いてるので早解き回だったみたい。それは配点からも読み取れる。簡単な問題に滅法強いという自己評価を裏切らない結果。■G 問題。自分のやり方で WA になる例。ループが２つ左右にくっついていて、右のループの周辺ということで、右のループの外側、左のループから見れば内側から BFS を開始した場合、打ち切るタイミングを誤る。盤面を BFS のたびにクリアすれば解決するけど、ますますもって TLE が加速する。■■■精進。G 問題。提出 #55351016 (AC / 796 Byte / 571 ms)。kotatsugame さんの動画(【競技プログラミング】ABC361【実況】)で解法を聞いたんですよ。UnionFind をするのは石と石ではなく、縦もしくは横方向に連続した格子点列の隣り合ったもの同士だった。やってることは難しくなくて、付加情報として格子点数を持った UnionFind だけど、頂点番号が与えられているわけではないので、格子点列に自分で番号を割り振らないといけないひと手間がやっかい。Y 座標列をソートし忘れたり、ひと手間に色んなミスがからんでくる。グループの管理と格子点数の管理を同時にやろうとしてグループ０と数０を混同したりもした。また、格子点の総数が数えられなくて答えがなかなか合わなかった。X 座標の最大値が 200000 だとして、0 から 200000 のあいだには 200001 個の格子点があるんですよ(あたりまえ……ではなかったんだなあ)。

ツッコミを入れる

2024年07月01日 (月) [AtCoder] 精進。昨日あった ABC360-E「Random Swaps of Balls」。ひとえに、ひとえにデバッグ力が足りなかった。サンプルの２に `3 2` という入力例がある。サンプル１のように解説がないし、出力例が実数ではなく `554580198 (mod 998244353)` だということで、途方に暮れていたのが昨日。だけどね、自分で計算すればいいんですよ。昨日の方針だけど、場合の数を K 回数え上げていって、最後に N^{2K} で割ることで確率に変換するようにしていた。ということは、`3 2` という入力に対しては９通りの出目が２つ続く 81 通りの場合がうまく数えられていれば良かった。81 に足りなければ遷移の式が誤っているということ。そのようにして今日はサンプルの２が合った。そして次のサンプル３の入力が `4 4`。これの答えがまた合わなかったのだけど、同じようにして `4 2` に対する 256 通りの数え漏らしを見つけることでサンプルの３もまた合った。■提出 #55117837 (AC / 362 Byte / 126 ms)。N=1 で WA を出さなかったのはすでに他所で知っていたから。全く警戒していなかった。■この E 問題までささっと解けてまだ不満というのが自分の現状認識なんだけど、また脳みそにクモの巣が張ってきてるみたい。半年後からの挽回に期待！■続けて G 問題 Suitable Edit for LIS にも取り組んで提出したのだけど、#55121924 (WA×8/AC×45)、WA になるケースが全く作れなくてデバッグが進まない。C++ の AC 提出と答えを突き合わせたりしてるんだけど、最初にコピーしてきた提出は長さ６程度のシャッフルした順列に対する答えがおかしかったよ(それでも AC)。２つめにコピーしてきた C++ の AC 提出とは意見の一致を見たので、自分だけが盛大な勘違いをしているということはなさそう。こんなザルなジャッジだったら８個くらいの WA は見逃してくれてもええやろ。■G 問題について現在わかっていること(あるいは勘違いしていること)。操作によってできるのは LIS の長さを +1 することだけ。先頭か末尾の値を含まないで LIS が作れるなら、先頭か末尾の値を操作して +1 できる。では先頭と末尾の値が LIS に不可欠だったら？適切な位置に LIS に参加しない空き要素があるなら +1 できる。適切とは？空き要素があってもその前後にある LIS を構成する要素が連番だったら +1 できない。条件はこれだけだと思う。ところで LIS って候補がいくつもあるのが普通。最長の長さを知りたいだけならそれらを区別する必要がないけど、今回は空き要素を挟めるか挟めないかがポイントなので、LIS の個別の列に踏み込んでいかないといけない。添字列に対して LIS を求める操作をして作業配列を上書き更新せずに追記して履歴を残すようにしたらうまくできないかなーと思って書いたのがさっきの提出。なにがうまくないのかわかんない。思いつきでいけるやろって思う方がおかしいか。そうか。■■■通ったー！！！ G 問題。提出 #55154669 (AC / 672 Byte / 277 ms)。前の提出が 671 Byte だった。17 行目の `<` を `<=` にすると WA が AC になった。狭義単調増加だから、値の比較にイコールがないのは一見自然なんだ。でも 17 行目では LIS に含まれない要素をはじいていた。`<` の否定が `>=` であるように、そこではイコールが必要だった。なんだー、１文字かー。ランダムケースの生成ルールを `A = 1,([2,3,4]3).shuffle,5; puts A.size,A*' '` に変えたらすぐに見つかった。同値の要素の重複がキーだった。ともあれ、やろうとしたことがちゃんと AC に繋がっていたのは良かった。■LIS の履歴の活用法について書く。作業配列には通常長さ i の増加列の末尾の値を記録する。最終的に i が取り得る最大値が LIS の長さ。今回は値の位置も知りたいので値の代わりに添字を記録し、さらに履歴も知りたいので各長さ i それぞれに添字列を記録していった。入れ子配列の総要素数は N+(LISの長さ) になる。作業配列には最長に届かなかった短いものも含む全ての長さの増加列の情報が記録されている。これを後ろから見ていくことで LIS の一部ではない要素をはじいていくことができる。値を見ることで添字列の先頭から、添字を見ることで添字列の末尾から取り除いていくことができる。たぶんね。あとは前後の添字列を見比べて LIS に中間値を挿入する添字の空きと値の空きがあるかを確かめる。■■■遅れていたレート更新があったのだけど、B 問題で範囲が間違っていた普通の WA コードを投げた人が Unrated に不満を表明していた。テストケースの制約違反とは関係なく WA だった人も Unrated なの？確かめたら自分も Unrated で草。４完低パフォだから不満はありませんけども。1≦c≦w という範囲を添字にするときに、c を 0 始まりにするのを忘れて各行１文字目を縦読みするケースが漏れていて WA を１回出したんだよね。

ツッコミを入れる

2024年06月26日 (水) 「競プロ出身者の使えなさは異常」■すごくありそうだなって思う。全体から見れば一部だし界隈によらず存在する特性でもあるはずだけど、特に優秀で他によりどころがない場合に、ああいう悪い感じに増長してしまうことはあるだろうなと思う。競技プログラミングになじむ時点でその素養は高いかもしれない。もちろん主語がでかいし偏見だし個人を見ろと言いたいし、クソと言っている周囲がクソな環境にずぶずぶにつかったクソである可能性も常に考えている。増長っていうか防衛にも見える、ハリネズミ的な。誰も認めないから主張が先鋭化するんじゃないのか。認めつつ穏当に導くことも、マウントを取り返して黙らせることもできなかった結果ではないのか。なんにせよミスマッチはその通り。お互いに不幸でしたね。

ツッコミを入れる

2024年06月25日 (火)

最終更新: 2025-03-15T01:11+0900

♪ [AtCoder] JOI Open Contest 2024 過去問／A - 試験 2 (Examination 2)

いつもの前置き：提出先は AtCoder だけど問題は AtCoder の作成ではなく JOI で、だけど競プロカテゴリを意図して AtCoder タグを付けています。

しんどかった。BC 問題を読むのは気が向いたときにして、A 問題についてだけ書く。

どういう問題？

４種類の論理演算(! & ^ |)と、かっこと、ある値を境にして真偽が切り替わる関数から成る式の値について、クエリに答える問題。式の長さが 1M 文字以下で、クエリとして与えられる値の数が 200K 個以下。つまりどちらもとてもでかい。

アイデア１：クエリの並び替え

クエリを昇順に並べ替えたら、入力値との比較で真偽が決まる関数というのは、一度だけ false から true に値が切り替わる関数になる。更新頻度が (関数の数)×(クエリの数) から (関数の数) に減る。

アイデア２：セグメント木みたいに関数の値の変化の影響範囲が対数レベルにならへんの？(願望)

以上の２つのアイデアというか願望に基づいて最初に書いたのが次の提出

提出 #54709820 (RE/TLE/AC)

関数を class で置き換えて、そのクラスに演算子を定義して、式全体の評価を eval で行うお手軽な実装。

RE の原因は Ruby が非ゼロの終了コードを返すこと

eval であるか *.rb ファイルを実行しているかに関係なく、大きな式を評価しようとすると Ruby は黙って異常終了する。式の形によっては終了する前に nesting too deep (SyntaxError) というエラーが出ることもある。p 1^1^1^1^1^...^1 という 1 か 0 を表示するスクリプトをコピペで膨らませて実行すると、Ruby のバージョンと Windows でのスタックサイズに左右されるんだろうけど、手元では 7 KiB を超える前に何も出力されなくなった。

TLE の原因は、願望が現実ではなかったということ

両極端の例を挙げると、1+2+3+4+5+6+7 という式を [+ [+ [+ [+ [+ [+ 1 2] 3] 4] 5] 6] 7] と解釈するとき、(1+(2+(3+(4+(5+(6+7)))))) という式を [+ 1 [+ 2 [+ 3 [+ 4 [+ 5 [+ 6 7]]]]]] と解釈するとき、階層が直線的に増えていく。

対策１：逆ポーランド記法

中置記法とかっこの存在が式の扱いを難しくしている。

変換アルゴリズムがうまく書けなかったので、検索してトップに出てきた「逆ポーランド記法入門２｜中置記法から逆ポーランド記法への変換」というページを参考にした。

うまく書けなかった部分、求めていた答えがまさに「演算子を全てpopして」と与えられていて喜んだのだけど、あとになって答えが合わない原因が「全て」にあることがわかった。上のページで扱っている四則演算のように、演算子の優先順位が１位と２位の２つだけなら「全て」で正しい。それより多いなら、「これから入れようとする演算子よりも優先順位が高い演算子を pop できる限り全て」が正しい。日本語の説明と Python の実装例に齟齬はなかったので、日本語だけの問題ではないみたい。その一部分を除けば文章だけでアルゴリズムの全体像がイメージできるわかりやすい説明ではあった。

これで RE は解消するけど TLE はなくならない。むしろ eval を呼び出してインタープリタに丸投げすることができないぶん遅くなる。

対策２(失敗)：更新の伝播を下の階層から、更新を階層ごとにまとめて

例えば [1]^[2]^[3]^[4]^[5] という１つの式があって、クエリが 10 だったとする。最初は全ての関数が false で、クエリの昇順に true に切り替えていく。10 が最小のクエリなら、1 から 10 までの関数を順番に true に切り替えていくのだけど、その過程でこの式は false>true>false>true>false>true と値をチカチカ切り替えていく。もしこの式の全体が別の式の一部分であるなら、それら外側の式も同時に連鎖的に値を切り替えていくことになる。

更新の伝播を階層ごとに一旦ためておいて、深い階層から足並みを揃えて各項につき１度だけ値を更新しようとした。その過程で更新と更新が重なって更新が消えることも期待できる。ただまあ、これは根本的な解決策ではなく、効果がある入力もあるかもね、というレベルの対策にすぎなかった。TLE はなくならなかった。

対策３(失敗)：式を真ん中で半分に

演算子の優先順位を考慮して、| ^ & の順番で、もっとも真ん中にある演算子で分割する。

たとえば [1]&[2]&[3]&[4]&[5]&[6] という式なら [& ([1]&[2]&[3]) ([4]&[5]&[6])] と分割する。

たとえば [1]&[2]&[3]&[4]|[5]|[6] という式なら [| ([1]&[2]&[3]&[4]) ([5]|[6])] と分割する。

ところでこの分割は同一階層内でしかできないので、[1]&([2]&[3]&[4]&[5]&[6]) の分割結果は [& ([1]) ([2]&[3]&[4]&[5]&[6])] になる。かっこを無視して分割してしまうとあとでどうくっつけていいかわからないので。

かっこに制約されるということで、更新が影響する範囲を対数レベルに抑えて TLE を解消する助けにはならなかった。

対策４(失敗)：逆ポーランド記法の式を操作して同一演算をマージする

なぜか抵抗があって考えないようにしていたのだけど、TLE 続きでなりふりかまっていられなくなったので、結合法則を使う。実は対策３でももう使っている。

「なぜか」っていうか、左結合だと問題に明記されていたから、それを無視するのはずるであると、理性ではなく感情が訴えるのだ。答えが合いさえすれば何をしてもいいという教育は受けていない。たぶんそういう理由。問題の解釈が曖昧にならないように出題者が左結合だと定義するのはわかる。交換して答えが変わらないのを見抜いて利用するのが解答者だというのもわかる。だけど無意識が抵抗している。まあいいや。

中置記法の式はかっこがあってややこしいので逆ポーランド記法の式を操作する。

たとえば 1+2+3+4+5+6 を逆ポーランド記法に書き換えると、1 2 + 3 + 4 + 5 + 6 + になるのだけど、演算順序をいじって 1 2 3 4 5 6 + + + + + に書き換えたい。

そうすると何が嬉しいか。演算子に由来する階層を取り去って [+ ([1]) ([2]) ([3]) ([4]) ([5]) ([6])] と解釈することが容易になる。次にこれを６項演算として扱うこともできるし、２項演算のまま引数列を半分半分にしていくこともできる、半分半分にするということは、セグメント木のようにきれいで効率的な階層が作れるということ。

正しい方向に向かっていることを予感させるけど、１パスでやろうとして十分にマージできなかった。

たとえば次の式の書き換えを考える。1 2 + 3 + 4 5 6 + + +。参照範囲が限定できるので予め連続する演算子を結合しておくと便利。1 2 + 3 + 4 5 6 +++ になった。左から読んでいって最初の + 演算子に出合うとき、右の要素が被演算子(3)でその次の要素が + 演算子なら、順番を入れ替えて 1 2 3 ++ 4 5 6 +++ にできる。しかしこれ以上の結合ができない。被演算子もまとめておくとひとつ飛ばすだけで +++ にアクセスできる？だけど 4 という項は 2 2 * という演算子を含む３項として存在していることもありますね。

対策５：逆ポーランド記法の式を解釈するときに同一演算をマージする

対策４とやりたいことは同じなんだけど、今度はうまくできた。演算子に行き当たったとき、スタックから取り出した２つの値(a, b)を即座に [op a b] としてスタックに戻すのではなく、a、b が単独の値か何らかの演算の結果なのかを調べて可能ならマージして、できるだけ階層を増やさないようにした。そしてそれが最後でもなく、スタックから取り出されてまたマージされることもある。

提出 #54933176 (AC / 2299 Byte / 1088 ms)

これの 92 行目から 107 行目のあたり。

2K オーバーの長大なスクリプトになってしまった。絶対もっと短く賢く書けるはずでしょ。

ざっと読んだ

Review って解説なのね。(JOI Open Contest 2024)

「Static Top Treeの覚書」とりあえず「何が嬉しいか」だけ把握した！

ツッコミを入れる

2024年06月24日 (月) 「セルフレジであたふたしてる年配者を見るにあの手の人々は「文字を読まない」ので文字情報は彼らには無力 - Togetter [トゥギャッター]」■何度も利用しているスーパーのセルフレジに言いたいことがあります。セルフレジに２種類あるのね。それぞれに、「こういうキャッシュレス決済が使えます」「キャッシュレス専用です。現金使えません」とか書いてある。一度間違えたからその次の機会に、どこに注意していれば間違えずに済んだかという観点で注意を払って観察してみたことがある。全然わからなかった。２種類のセルフレジは大きく左右のゾーンに分かれていて、待機場所も左右に隣り合った位置が別々に指定されている。レジと列に違いがあると知っていて、どちらに立つべきか注意して観察して、それで全然わからなかった。足下を見ても、左右に視線をやってレジまわりのポップを眺めても、判別できなかった。あとになって判明した理由は２つ。１つは、どこにも「現金が使えます」とは書かれていなかった。「現金が使えない」ことを知りたいんじゃないんだよ、しかもそれをレジ前で知っても遅いんだよ(これが２つ目の理由)。そして現金が使えないレジを見つけることは、現金が使えるレジを見つけることを助けはしない。現金が使えるかどうかわからないレジが存在しているだけなんだ。現金が使えないレジが現に存在しているのだから、これは自然に生じる疑いだと思いますがどうですか。あたふたする原因が導線の悪さにある例でした。スキャンを全部終わらせたあとで支払い方法の選択肢に現金がなかったんだよね(サポート店員さんがレシートを発行して現金可のレジに読み取らせることになった)。レジを区別するという注意コストを不特定の客に要求しているのだからこれはもうどうしようもない。ハードルがあるから越えられない人が出る。なくせないならせめて低くする仕組み作りを続けるしかない。

ツッコミを入れる

2024年06月22日 (土) [AtCoder] 今日はユニークビジョンプログラミングコンテスト2024 夏（AtCoder Beginner Contest 359）があった。F 問題まで解けたけどなぜか D 問題が解けない謎の回。ではふりかえり。■A 問題「Count Takahashi」。普通に `Takahashi` を探したけど、制約を読めば `T` を数えるだけでも良かったらしい。他の人の提出で知った。そうか、手の抜き方を見習わないといけないな。無駄にコンピューティングパワーを使ってしまった。■B 問題「Couples」。正規表現の先読みでやったけど、結構複雑で罠もあるパターンになったので(`/\b(\d+)(?= \d+ \1\b)/`)、普通に `Array.each_cons(3).count{...}` でやるのが良かった。■C 問題「Tile Distance 2」。数え方が ABC353-F Tile Distance と同じ。斜めを数えてから縦と横を数える。横移動のコスト計算が難しかった。目的地がタイルの右側か左側か判別してから、右と左のどちらから移動してくるのか場合分けをした。■D 問題「Avoid K Palindrome」。ABCDEF で一番難しかった。えっとね、まず否定で良い文字列を定義するのをやめてほしい(わがまま)。かなり長いあいだ勘違いしていた。何を数えたらいいのかまだわかっていない。長さ K の枠の中について回文があるとかないとかを数えるとするじゃない、でも枠の外を数えることができない。重複を省いてどうやって数えられるのか。■E 問題「Water Tank」。特別なデータ構造はいらない。スタックが１つと数を１つ覚えておくだけで答えが出せる。こういう単純な道具をこねこねする問題は好きだけど、前回の D 問題が灰 diff だったことを考えると、緑 diff どころか茶 diff があるかどうかもわからないと思う。高めに出てもそれは D 問題の壁があったからだよ。■F 問題「Tree Degree Optimization」。Ruby での他の人の提出を見ると、自分のよりずいぶんとシンプルで、自分には見えていない何かがあるのかなと思わされる。自分が考えたこと。各頂点が単独でばらばらに存在していて、(相手のいない)辺を１本伸ばしている。コストはその頂点の値(A)と現在の次数による。木を作るのだから、N-1 回、２本の辺を選んで繋ぐことを繰り返す。繋いだときにコストが発生して、それぞれの頂点からはまた新しい辺を生やす。辺を選ぶのにプライオリティキューを使ったけど、同じ連結成分から生える２本の辺を繋ぐことはできないので、単純にキューから２つ取り出して繋ぐというわけにはいかない。自分はキューを２本使った。１本目のキューにすべての辺を入れて、２本目のキューには最小コストの辺と、それと同じ連結成分の辺を入れた。そうすると２本のキューの最小同士を連結することでうまく処理が進む。だけど他の人の提出を見ると、キューは１本で足りるみたいなんだよね。どう考えるとそうできるのかわからない。■F 問題。次数の和が 2(N-1) になることを利用するのかな。キューには常に N 個の数を入れておいて、２つ取り出してコストを計算して、２つ戻す。自分の提出が無駄に複雑になったのは、個々の頂点の繋ぎ方を区別していたからだ。次数だけをカウントして繋ぎ方は考えないでおくと、シンプルになる。たぶんね。ほらね。提出 #54856675 (AC / 753 Byte / 562 ms)。ほらねじゃない。２つ取り出すのは嘘だった。１つずつ N-2 回取り出す。次数の和が 2(N-1) になるというだけでは条件が足りない気がした。各頂点の次数が最低でも１あるというのも条件なのかな。だから次数 N は予約済みとして、残りの N-2 をキューから引いた。■F 問題。tinsep19 さんのこの提出 #54855773 は個々の辺の繋ぎ方を考えつつもシンプル。木の問題の制約で自分が好きな形式があって、こういう形で親を定めるもの `p2,p3,p4,...,pN (1≦pi<i)`。これでどんな形の木も作れるんだよ。これと同じ考え方で処理を進めていてシンプルになっている。自分の考えが１つも２つも足りないのが明らかになっていくなあ。■F 問題。自分の最初の AC 提出には嘘があると思う。辺を繋いで、新しい辺をキューに追加するときに、２つ目のキューが空かどうかを確かめて適切なキューに追加するようにしないと、取り出し済みのコスト最小の辺と、２本目のキューに入っている同じ連結成分の２番目以降の辺の、コストの大小が入れ替わってしまうおそれがある。これは自分がキューのトップを参照するのではなく、とりあえず取り出してみた最小値を変数に保存して利用しているせいで生じているバグ。あぶないところだったなあ。■■■G 問題「Sum of Tree Distance」。全方位木 DP だと思ったら普通の木 DP だった。木 DP は DP の中でもやりやすい印象を持っている。積み上げの基礎となる葉の部分が最も単純でとっかかりとして好都合だからだと思う。その代わり子のマージに神経と時間を使う。提出 #54881518 (TLE×2 / AC×50)。２ケースダメでした。何が弱点だろう。メモリ消費と時間がだいたい比例している。メモリ消費は Hash かなと思うけど、どういう形の木だと無駄が増えるんだろう。単純に頂点数じゃあないんだよな。■精進。D 問題。X で ABC305-G Banned Substrings の簡易版だと読んだので、自分の提出 #42262239 をなんとか解読してそれっぽいものを書いた。提出 #54884526 (AC / 496 Byte / 147 ms)。おもしろいのは、っていうかやられたなって思うのは、入力文字列中の `?` の出番がごく控えめなこと。力技で長さ N の良い文字列を構築していくにあたって、入力文字列中の `A` と `B` はふるいとしての役割を果たしているのだけど、`?` というのは A でも B でもいいという意味だから、ふるいとして働かないことが機能なのだ。注目する部分が間違っていたし、プログラムの構成も全く予想していないものだった。■■■G 問題。朝のトイレでひらめいてしまった。マージテクのためにサイズでソートしてるんだけど、そのサイズって５とか３の固定だったりしませんか。帰ってからデバッグする。提出 #54896069 (AC / 839 Byte / 3169 ms)。通りました。まさかのマージテク失敗が TLE の原因だった。あれこれ考えることが多いと手癖にまかせて `.sort_by(&:size)` とか書いちゃうんだな。ところで、今確認したところ tinsep19 さんが G 問題を 528 ms で通している。同じ Ruby なのに桁が違うんだけど、何をどうやっているのか、知りたいが読んで知りたくはないんだな。■F 問題。「自分の最初の AC 提出 #54840376 には嘘があると思う」と書いた。実際に確認したところ、新しい辺を無条件に２番目のキューに入れていたので、懸念していたコストの逆転は起こらないはずだけど、代わりに「２つ目のキューが空かどうかを確かめて適切なキューに追加する」ことができていなかったことが明らかになった。これの何がまずいか。新しい辺を空っぽの２番目のキューに追加すると、そのキューから選ばれた辺が次に繋ぐ辺の一方として必ず使われるんだけど、これがコスト最小であるとは保証されない。１番目のキューから取り出されたものを２番目のキューに入れるからコスト最小が保証される。一方でこれが WA の原因にならない理由もわかってきた。どれか１つ任意の連結成分を選んで、これに属する辺を２番目のキューに入れると決めることでも N-1 回の操作で木を構成することができる。自分は UnionFind を使っていながら、ミスによって UnionFind による連結成分の管理を必要としない木の構成法を実行していた。なんだかなあ。考えが２つ足りず(次数への着目、インクリメンタルな木の構成法)、実装ミスをし(追加するキューの選定)、ミスしたと勘違いをしていた(IMKK)。素直に F 問題の AC を喜ばせてはくれないのか。

ツッコミを入れる