%P の位置だった。３項の掛け算のあとに %P をくっつけていたのを前にずらして２項の掛け算にするだけで２秒オーバーが１秒未満になった。Ruby にはオーバーフローがないからついテキトーに %P を付けたり省いたりしてしまうんだけど(%P が多すぎても少なすぎても TLE の原因になるのだ)、同じ１回の %P でも位置によって効果がだいぶ違うんだなあ。■F 問題「Easiest Maze」。出力形式難しすぎ。そして問題文が間違っていた。「壁があるときに辺で結ばれていて、長さ K の唯一のパスを構築する(大きさ K の連結成分では十分ではなく、塊やループや３つ以上の端点があってはいけない)」というのでは壁の既成概念が崩壊する。質問と訂正があるのを待つことにして A 問題からの実装を始めることにした。終了の 25 分前に戻ってきたら問題文の修正は終わっていたが、差分を調べるのが面倒で読まなかった。すること自体は難しくなさそうに見えてやりきるのはすごく難しいかも。自分の頭で考えて答えを構築するなら、縦と横の偶奇の扱いがやっかい。だったら機械に長さ K のパスを探索させれば何も考えなくていい。100×100 というのが素朴な DFS にとってどれだけの規模感なのかよくわからない。やばいとは思う。マスの埋まり具合と現在位置でメモ化してもどうか。２、３日前に読んでいた『競技プログラマー ハンドブック』(PDF) で紹介されていた枝刈り手法が使えそう。壁にぶつかって左右に進路が分かれるとき、ゴールがない方の進路に答えはない。なんにせよ時間がなかった。■精進。G 問題「AtCoder Tour」。F より低い青 diff なのを見たので問題を読んだ。現在のマスが終着点だと仮定したときの想定楽しさを元にした BFS でできそう。提出 #54618901 (AC / 413 Byte / 480 ms)。できた。こんな腑抜けた G 問題を置かれると、目の前の問題を解く以外のことを考えさせられてめんどうくさいんだよなあ。■■■精進。F 問題。やっぱりね、「すること自体は難しくなさそうに見えてやりきるのはすごく難しい」。何をするかって、ぐねぐね左右に線を引いて、ラスト２行の帰り道では縦にぐねぐね線を引いて、それをフォーマットして出力する。がんばってやる！ 提出 #54644107 (AC / 1676 Byte / 51 ms)。右へ線を引く、下に移動する、左へ線を引く、ぐねぐねしながら左へ線を引く、と関数を分けることで、同時に１つのことだけを考えればいいようにした。文字列化するのも、行を出力する関数と行間を出力する関数に分けて、同時に１つのことだけを考えるようにした。もーたいへん。縦横の偶奇と K の偶奇は調べなかった。予め達成可否を判定することはせずに(できませんから！)、やるべきことをやった結果ゴールにたどり着いているかどうかで判断をした。これは ABC347-D の反省から(「RE/WA を出した方では、不可能なケースを最初に判定するようにしていた。一方の AC 提出の方では、操作をしたあとで、結果が満足しているかどうかで出力を切り替えた。要するに、不可能なケースの判定に漏れがあったのだ」)。■■■F 問題のジャッジがザルだったらしい。まあ、あの大作の出力形式を整えて提出しただけで評価されてもいいよ。■G 問題。「現在のマスが終着点だと仮定したときの想定楽しさを元にした BFS でできそう」について書く。まず、待機するマスは必ずパスの末尾になる。最適を目指すとそうなる。パスがあって長さが決まっていて、残りのターンを費やすのは報酬が最大のマスに決まっている。それがパスの途中にあるとするなら、そのマス以降のパスが蛇足だったということになる。移動を省いてそのターンも待機に費やした方が良い。だから待機マスは必ずパスの末尾になる。▐あるマスに到着したときのことを考える。関心事はそのマスを最終地点とした場合のスコアだから、到着時点での残りターンを報酬に変換してスコアを比較する。スコアがすでに記録されているスコアと同じか下回っている場合は探索を打ち切って良い。なぜか。パスを伸ばす目的というのはより良い待機報酬を求めることにあるのだから、あとから訪れていて残りターン数が少ない探索の枝はそれだけでビハインドを背負っている。それなのにパスに依存したスコアが余分に費やしたターン数に見劣りしているというのだから、これ以上の探索で先達より良いスコアを得る可能性はない。▐もう全部書いた？ 提出したあとになって問題があると不安になって、でも実は問題がなかったことがある。BFS で t ターン目の処理をしているときに、隣接マスを t+1 ターン目のキューに入れると同時に t+1 ターン目の状態をその隣接マスに書き込んでいる。このあとさらに t ターン目の処理を進めているときに、さっき t+1 ターン目のキューに追加したマスが出てきてしまったら、t+1 ターン目の状態に基づいて t ターン目の処理をすることになるのではないかと考えた。でもチェス盤を考えるとわかるんだけど、t ターン目のキューと t+1 ターン目のキューに同時に入るマスは存在しないのだった。うまくできてるんだなあ。今までそれを知らずにグリッド BFS を書いてたんだぜ。■■■D 問題。B の降順だと A をスキャンするだけでは済まないみたいなことを書いたけど、具体的には二分探索と中間位置からの効率的な削除が必要だと、平衡二分探索木みたいなものが必要だと思っていたけど、そんなことはなかった。昇順でも降順でも1≦H という制約だった。■B 問題「Uppercase and Lowercase」。やります。ASCII の６ビット目を数えるという猪口才な判定法。■C 問題「Sierpinski carpet」。今日のつまずきはここから。再帰関数でやろうかクラスでやろうか文字列操作でやろうかいつまでも迷っていた。結局文字列配列を敷き詰めて拡張していく操作が簡単で短かったが、15 分かけた。■D 問題「88888888」。まず勘違い。与えられる N が整数型に収まらないサイズだと勘違いしていた。文字列として各桁を扱わなければいけないのだと思って解いていた。求めるものは初項、公比、項数が明らかな等比級数なのだけど、項数が mod 998244353 だとサンプル３の答えが合わない。Integer Sequence Fair を解いたこと(20230327)が糧になっていない。mod をそのまま指数にはできない。で、繰り返し二乗法を自分で実装しなければいけないのかと思って N が何ビットになるのか確かめたら、60 ビットで足りるようだった。なんだよー。公式に３数を当てはめるだけのことに 20 分かけた。■E 問題「Reachability in Functional Graph」。これも勘違いがひどかった。N 頂点 N 辺だというから、輪っかが１つのなもりグラフなのだと思って解き始めたのだけど、このグラフは連結でも単純でもなかった。サンプル１に言及があったのだけど、自己辺がある。それではと複数のループとループに繋がる毛が生えているグラフを想像してサイクルと直線を検出する関数を書き始めたのだけど、サンプルの３が合わない。枝毛の可能性を考慮していなかったせい。問題文の最後にわざわざ「特に、u=v の時は常に到達可能です」と書いてあるのも読み飛ばしていてカウント漏れがあったし、もう散々だった。およそ 40 分かけて変な関数を書いた>提出 #54372312 (AC / 316 Byte / 227 ms)。順方向と逆方向の DFS を２回やるらしい強連結成分分解をそらで書くことがまだできないので、変な関数を発明しがち。出次数がすべて１だという条件があるから、強連結成分分解はオーバーキルなのだと思う(だから変な関数で解ける)。■自分のすべての提出。■■■C 問題。再帰バージョン。提出 #54407583 (AC / 276 Byte / 138 ms)。結局のところ実装の方針に迷っていたというのは、どの方針にしろ実装を最後まで見通せなかったために二の足を踏んでいたということなのだろう。実装力が足りない。■■■級数という言葉について。ちょっと検索したら、級数というと普通は無限項の和を表すみたい。特定の範囲を除いて０と定義することで有限個の和を表すこともできて、そうでないことを示すために無限級数という言葉も使われるけど、基本的に無限個の和なんだって。「級数」(ja.wikipedia.org)。そうかー。等比数列の和って言わないとだめなんか。長ったらしいなあ。てっきり、並べたものが数列で、並べて足すものが級数なんだと思ってた。
AtCoderの開催中のコンテストの問題として発信されている情報の全部または一部を、ソフトウェアに入力として与える行為を禁止します。問題文をコピーした文章・スクリーンショットなどが該当します。提出するソースコードを書くためのエディタも、この制限に該当します。」と書いてあって、完全には無関係ではなかった。エディタも例外ではなかった(想定は VSCode みたいな Copilot 付き高機能エディタらしいけど)。とはいえ、自然言語の問題文をコピペする機会はこれまでなかった。定数や出力用文字列は「
問題文で与えられる固有の整数や固有名詞などの文字列は、任意の場合においてコピーが許されます。998244353などの問題文で与えられる数値、「Takahashi」、「Aoki」などの文字列等。「Monday」などの曜日や、問題文で与えられる数列などは許可されます。」と例外として許可されていた。自分は自分の注意力や指や目を全く信じていないので、
Aoki と４文字タイプするのも避けてコピペしたいタイプなのであって、許可されていて良かった。最近はもう積み重なった慣例を疑う理由もないので、グリッド問題で o や x をコピペするのはやめてしまったけど、字形と文字コードの繋がりって不確かだよね。GitHub やブログに貼り付けられたソースコード片において、円マークに見えるものが 0x5C ではなく 0xA5 だったせいで壊れていたケースを複数回見かけている。タイポを避けるためにコピペしたいし、見た目ではなく文字コードに基づいて入力するためにもコピペしたい。話がそれた。他に注意が必要な点はなかった。ハザードたいて路肩に一時停車するだけ」とあって、実際そういう対応を見かけることは多いのだけど、自分はそういう対応を教習所で習った覚えがない。ハザードをつけるのは害がないと思う。だけどつけろと習った覚えはない。交差点には進入できない。だから交差点に進入しないために停車することはあると思う。だけど、直線で路肩に寄って停止するのは、あまり良くない対応だと思っている。なぜか。車というのは横に寄せるためにも前進しなければいけないのであって、たとえば救急車が後方から接近しているときに、前の方にある車がそそくさと停止してしまうと、後ろにいけばいくほど前進余地が少なくなって横に寄せることができなくなる。ウチの県は１号線であっても片側１車線なので、救急車もその周辺もにっちもさっちもいかなくなる。■「緊急車両（緊急自動車）が近づいてきたときの道の譲り方や進行妨害した場合の罰則 | クルマ情報サイトｰGAZOO.com」 「緊急車両 対応」で検索して出てきたこのページの「3.緊急車両に対する道路交通法での義務」に条文の抜粋がある。前段が交差点付近の対応で、左側に(場合によっては右側に)寄せて一時停止せよと書いてある。後段がそれ以外の場所での対応で、左に(もしくは前段同様右に)寄せて譲れと書いてある。次節(４項目目)記事本文には停車せよと書いてあるから、あえて条文部分を参考にした。「譲る」を日常語として理解してはいけない可能性？ でも前段との比較によっても一時停止までは求められていないと判断できる。もちろんしてはいけないとも書かれていないのだけど、あまりいい考えじゃないんじゃないかなあというのが自分の意見。前が止まれば止まるしかないけど、寄せて減速はしても率先して止まりはしないというのが自分の対応。■左に寄せるときはまずミラーを見て二輪を挟まないように注意します。
(Yi<K かつ Yj≥K) ならば i<j が成り立つ」という型の命題は、前提が成り立たないときは常に真だよね、誰か質問しないかなと考えていた。そのうちに問題文を何回目かに読み返していたときに気がついたんだけど、累積和の初項が必ず０だから、その時点で K 以上の値が出現してしまっている場合があるのだね。K が０以下の場合とそれ以外で場合分け。ここではあっさり書いたけど、境界値が 0 なのか -1 なのか 1 なのかでもじっくり考え込んでしまった。基本的には Yes でソート列が答えになる。判断が分かれるときは正の和と負の和の絶対値の差と K を比較する。ここでも不等号にイコールが付くかどうかをじっくり考えてしまった。なんなら最初に戻って場合分けの条件から考え直している。これが自分の脳みそに収まるぎりぎりのサイズの問題です。■B 問題「Between B and B」。ある文字が要求されているいないの状態が 1<<M あって、これを N 文字分繰り返す DP をするのだと思った。実は最後の文字が何であったかを区別しようとしていて、そうすると１億ステップの処理になって TLE なのではないかと思ったけど、区別しないなら 1000 万なので間に合いそう。どちらにしろ数字合わせができなくて TLE かどうか以前の問題だった。■C 問題「Beware of Overflow」。個別の値の絶対値が R 以下ですよ、値の合計の絶対値も R 以下ですよ、二項間の比較と加算を駆使してどの瞬間どの値も絶対値が R を超えないようにうまい順番で全体を１つの値にまとめましょうね、という問題。最初はソートしてから先頭と末尾の加算を繰り返せばいいかと思った。ソート列を真ん中で折り返して加算するので、１回のイテレーションで全長がおよそ半分になる。だいたい答えは合っていたけど、３ケースだけ WA だった(#54171399)。どういうケースで良くないかというと、
-R,-R,-R,2,2,R-1,R-1,R-1 みたいな場合？ R=3 だとすると 2+2 をしてはいけない。改良版では、加算した結果を二分探索で適切な位置に挿入することで常にソート済みの状態を保ちながら、最大値と最小値の加算を繰り返すことにした。提出 #54175146 (AC / 442 Byte / 177 ms)。■水パフォで喜べないって悲しいね。わざわざ確かめないけどね。自分の想像では ARC、ABC、ABC、ARC と下げが続いている。■■■D 問題「Portable Gate」。Ruby で挑戦している人がいたのでまずは問題を読んでみた。全方位木 DP？ ゲートを置く場合と置かない場合のコストを積み上げていくのかと思って実装を始めたけど、どうもそれではいけない。始点に帰ってくる必要がないのだ。最後に選んだ辺へは行きっぱなしでいい。そうすると、ゲートを置かずに帰還する場合のコスト、ゲートを置いて帰還する場合のコスト、帰還しない場合のコスト(※ゲートを置く置かないは呼び出し元に影響しないので置けばよい)の３つを考える必要があるのかなと考えたところでギブアップ。知力を振り絞るためには頭の良さだけではダメで外国で冬の海に飛び込めるくらいの体力が必要らしいですよ(もちろんそんな体力もエネルギーもないのでさっさと投げ出しちゃいます)。■通った！！！ 提出 #54283484 (AC / 1521 Byte / 1758 ms)。びっくりマークを３つ付けてもいいでしょう。たいへんだった。寝る前に数時間がかりで慎重にコーディングをしたら、ちょっとしたシンタックスエラーを２つ直しただけでサンプルが通って、あとのミスは親方向の深さを計算するときに +1 するのを忘れていたことだけだった(37 行目と 50 行目。子供から見て兄弟は最も近くに見えて２親等だという話)。結局考えるべきは先に挙げた３つに加えて、(ゲートを使わないで)帰還する場合と帰還しない場合の差分として最も遠い子孫との距離を記録した。この問題ならではのフックがありました。全方位木 DP の手順として、全体から子を引いてそれを親方向のパラメータとして子に与える必要があるんだけど、パラメータの計算に最大値(最小値)を使っている部分がある。つまり、複数の子があるときに、１つの子については帰還する必要がないけど、他の子についてはすべてを黒に塗ったあとで戻ってくる必要があって、その選択に最大値(最小値)を使っているんだけど、子の影響を全体から差し引くときに最大値(最小値)が利用できなくなる場合がある(その子がまさしく最大値(最小値)だった場合)。こういうときのトップ２戦略は過去２回の経験がある(20240302)。どうですかね、もっとシンプルに解ける考え方があるんですかね。選び方次第でパラメータが減らせる可能性はあるかな。全方位木 DP というだけでたいへんなのに、それに輪をかけてたいへんだった。パラメータが４つあってそのうち２つでトップ２戦略を使った。最後に補足。ゲートを使う使わないを辺ごとに独立に選んでいい理由は、ゲートを使わずに網羅して帰還する辺を、ゲートを使って網羅して帰還する辺より先に選んだことにすればいいから(そして最後が帰還しない辺)。■■■B 問題。提出 #54413597 (AC / 433 Byte / 1544 ms)。すでに散々悩んだあとで頭の中が整理されていたからか、フツーに普通の DP だった。日記に「ある文字が要求されているいないの状態が 1<<M あって、これを N 文字分繰り返す DP をするのだと思った」と書いたことは忘れていて、ブロックされている文字にビットを立てる DP をした。それで良かったけれど時間が厳しい。３重ループになるのだけど、N のループの中で 1<<M のループの中で M のループを回すとコードテストで 10 秒弱かかった。制限は特に長めでもない２秒。ここで ABC356-D Masked Popcount の解法のひとつ、ビットごとに 0 と 1 の出現サイクルを利用するものを思い出した。ビットごとに 0 または 1 だとわかっている数についてだけループを回すなら、３重ループの最奧でビットが立っているかどうかの判定をしなくて済むし、ループの回数も半分になる。そのためにはループの順番を変えて、N のループの中で M のループの中で 1<<M のループを回す。遷移はビット演算が２つ。ある文字を置いた結果その文字自身をブロックし、そののちいくつかの文字のブロックを解除する。■同じく B 問題。提出 #54414039 (AC / 796 Byte / 1628 ms)。Ruby による B 問題へのすべての提出を見ると Akiyah さんが 2047 ms で AC まで一番近づいていた>#54319004。お楽しみを奪ってしまったとしたら申し訳ないのだけど、速くなりそうな部分があったのでそこを修正したものが冒頭の提出。具体的には ns.sum{|n| dp[n] } を dp.values_at(*ns).sum に変更したら 20 % くらい速くなって AC になった。インタープリタ型の言語は、できるだけ短い指示で多くの仕事をコンパイル済みのネイティブコードにやってもらうのが良い。ちなみに TLE を避ける工夫は自分のものとは異なっていて、1<<M 通りの遷移先をビット演算で N×M 回求める代わりに前計算をして、遷移先ごとに遷移元の集合を用意している。それがさっき出てきた ns。そういう準備があったからこそ dp.values_at(*ns).sum という効率的な遷移を書くことができた。遷移を１行で済ませることができていた。■■■D 問題。解説を読むと、読むのもたいへんなので８割読み飛ばしちゃうんだけど、移動コストの上限は 2(N-1) で固定だから、ゲートを使って帰還コストをどれだけ節約できるかだよと書いてある……ような気がする。提出 #54485687 (AC / 989 Byte / 1765 ms)。パラメータが１つ減って３つになった。解説の最後にリストされている３項目に３つのパラメータを対応付けるなら、順番に R、G+L、G になるのではないかな。最後が一致しているのでヨシ！与えられるテスト結果が誤っており上記の条件を満たす組み合わせが存在しない場合もあります。その場合は 0 通りと解答してください」の意味がよくわからなかった。信頼できない入力が混じっていて、それを見抜いて何らかの対処が求められているのかと思った。実際は単純に矛盾するテストによって答えが０通りの場合があるよということを言っているだけだった。たしかに、複数のテストを照合した結果矛盾が生じて答えが存在しない場合、じゃあ、個々のテストにおいて「開いた(開くはずがない)」「開かなかった(開かないはずがない)」という結果をどう扱えばいいかという疑問が生じる。それは誤りであるという断り書きだった。■D 問題「Masked Popcount」。かつてよく見られた数え上げ問題。苦手だよ。でも精進によってなんとなくの型みたいなものは持っている。上限が N で与えられてるのがやっかいなんだよね。たとえば N=2**60 ならこれは主客転倒で寄与を簡単に数えられる。じゃあどのようにしてそういう状況を作るかというと、与えられた N のビットのうち、最も左にあって最初に倒されるビットを決め打つことによって N を複数の区間に分割する。N のプリフィックスと自由に {0,1} が選べるサフィックスとで構成される区間について問題を解く。たとえば N=0b10101 ならプリフィックスは１のビットの数と同じ次の３つ(0b10100、0b100xx、0b0xxxx)。 もちろん１つもビットを倒さない場合も忘れない。■E 問題「Max/Min」。よくわからない問題。N の上限は 20 万。これは O(N) もしくは O(NlogN) が解法となるよくある制約で、N の制約としてはほぼ上限。そして A が取り得る値が 100 万以下。これは N と比較すると大きい数字だけど、処理すべき区間が 100 万以下であってそれ以上は考えなくてもいいと思うと、そんなに大きい数字には思えない不思議。結局これは調和級数の上限がどうのという問題だったんだろうか。特別な道具を使わずに配列を操作すると決めたあとでも答えを合わせるのに苦労して、結局１時間近くかけてしまった。やるべきことはひと目でわかるんですよ。すべての組み合わせについて足し合わせるに当たって、予めソートして Ai と Aj の大小関係を固定してしまえば考えるべきは分子が分母の１倍か２倍か３倍か……。時間が厳しいので(そこが問われている問題なので)同じ値はまとめて計算しますよ。そうするとどんな入力が嫌かというと、小さい数字が順番に並んでると、処理をまとめることができず、区間を大きくスキップして処理することもできないのが困るなと。だけどね、100 番目、1000 番目の値はすでに十分大きいわけです。100 万割る 100 は１万だし、100 万割る 1000 は 1000 なので、個々の処理量は無に等しい。もちろん１万が１万集まれば馬鹿にならないんだけど、全体で見ても処理可能な範囲に収まることは知っている。名前は出て来なかったけど高３の演習問題でいつの間にか不等号を証明させられていたような気がする。■F 問題「Distance Component Size Query」。解けなかった。セグメント木とか平方分割とか、うまく区間を分割して効率良く数えられないかと考えたけど、できそうでできなかった。でもできるのかなと思ってる。自分にはできないけど。K=0 と K=1、それと K がすごく大きいときでだいぶ様子が違ってくるなとも思った。でも、じゃあ K=1 の場合に限れば問題が解けるかというと、そうでもなかった。■■■D 問題。桁ごとにサイクルを考えるという解法を仕入れてきた☞。LSB から見ていくと、サイクルは２、４、８と倍々になっていく。その中身だけど、前半が０で後半が１という単純なもの。だから 0 から N までの N+1 個の数をサイクルと半端に分けて１の数を数えるのも簡単。提出 #54162917 (AC / 165 Byte / 42 ms)。この考え方だとずるいぐらいに実装が簡単だった。自分は自分の考え方で実装したとき式を間違えて１回 WA を出してるからね>提出 #54107427 (WA)。
w を足し、それまでに採用されていたが不要になった辺のコストを w+1..10 の範囲で探して引くというもの。単純明快でしょ。しかも、コスト１の辺を使うグラフ、コスト１から２の辺を使うグラフ、……という 10 種類のグラフを維持管理する処理と、辺を追加したことで不要になった辺のコストを特定する処理が一体となっているところが美しいと思うんだ。これは解答というより問題の力だとは思うけども。■■■E 問題。kotatsugame さんの動画(【競技プログラミング】ABC355【実況】)でグラフとしての見かたを知ったので、新規に実装して提出した>#53993734 (AC / 1045 Byte / 402 ms)。変数の取り違えで RE を出し、off-by-one エラーで WA を出し、デバッグ版を提出して WA を出したあとでの AC だった。やっぱり難しいね、この問題。ミスのしやすさも問題の難しさのうちだとすればね。やっていることは辺が陽に与えられないだけの BFS。グリッド問題みたいなもんだ。■C 問題。行や列をスキャンする O(N^2) 解が 455 ms (#53855978) だったところ、カウンターを使う O(T) 解が 132 ms (#53993977) だった。制約がちょっと変則的で、1≤T≤min(N^2,200000) かつ 2≤N≤2000 なので、T の上限が 20 万なのに対して N^2 の上限が 400 万。N^2 解を許容するためにあえて制約の桁を減らしていることが窺える。C 問題だしね。まんまと甘えさせてもらいました。