0 で切って 1? だけからなる文字列について考える。長さ K 未満の文字列が 1 を含んでいたら 0 通りだから No。長さ K 以上の複数の文字列が 1 を含んでいたら 0 通りだから No。1 を含む文字列が 0 個のとき、? からなる長さが K より大きな文字列が存在してはならず、長さが K の文字列が１つだけ存在するときに限り答えは Yes。1 を含む長さ K 以上の文字列が 1 個だけあるとき、それの長さが K なら答えは Yes。K より大きいときは 1 の左右端の位置を調べてその幅が K より大きければ No。K ならば Yes。K 未満で左右に ? が存在していれば No。さもなければ Yes。これで全部。複数考えられる場合と１つも考えられない場合をどちらも除外しなければいけないのだけど、意識の切り替えがうまくいかないときに間違えると思う。■地獄の場合分けといえば ABC160-D「Line++」(緑 diff) を思い出す。他に解法がいくつもあって全然場合分け地獄に入り込む理由がないんだけど、時間内に AC にたどりつけない人間が解法を選べるわけもなく>20200701p01。A に含まれない最小の非負整数」を 0 からカウントアップしていって、その数字が答えになる操作回数を逆に求めた。それを効率的にやる。
-1.0/0 から -10**12 に変えただけで劇的に改善した。意味的には無限大にしたいし遅いのを知りつつそう書いてきたんだけど、TLE になるほど遅くなるなら制約の範囲外の整数値を使うしかないなあ。■■■精進２。第11回 PAST-I「お片付け」。これも同ブログでデータの持ち方を教えてもらった。自分で書いた TLE 解では文字列化した盤面全体をキーにしていた。だけど記録すべき特徴というのはすぬけくんの位置と荷物の位置という２つの数値だけなんだな。なんでわからないんだろう。■提出 #35384851 (AC / 1950 ms)。制限時間４秒なのでまあまあ。N=10; A=3,4,4,5,6,7,8,9,9,10 のとき、自分の答えが 7 で、AC 提出の２つが 8 を返している。あー！！！ ほとんど同じ構成だけど事前に重複している本を処理していた tinsep19 さんの提出 #35285896 が処方箋だった。最初に見たときは自分も同じことをしてると思ったけど、同じではなかったのだな。■提出 #35324229 (AC / 224 Byte / 228 ms)。すがすがしいほどの完敗だよ。ローカルで小さいケースをいくつも作ってデバッグしていたんだけど(成果なし)、答えを用意する人間が間違っていてはどうにもならない。プログラムは完全に意図通りに動作していたが答えを間違えていた。どうでもいいことだけど提出したスクリプトの変数 read は過去分詞なので【réd】と読みます。どうでもいいね。■勇気づけられるツイート。「アライグマ「ABC271だったのだ！ C問題は最初の方の巻から順に「読みたい巻なら読む。もう読んだ巻なら売る。読みたい巻より先なら、一番後ろの巻から2冊売って読みたい巻を買う」を繰り返せばいいのだ！」 フェネック「それだとA=(2,2,3,4)のときにWAだねー」 https://t.co/Jh41vbHFqP https://t.co/MLXPSXt5tm」 ちなみにこれに「じゃあ答えを二分探索するのだ！」というツイートが続く。この流れも想定の範疇にあった。別の解法なら落とし穴を踏まないのではないか二分探索ではどうかと考えていた。でもそういうときに意地になっちゃうんだよね。最初の解法を修正することに拘ってプランＢが選べない。そういう性質だと知っているし開き直って受け入れている。■■■精進。今日の ABC271-F「XOR on Grid Path」(ぎりぎり青 diff)。半分全列挙の問題が半分全列挙だと教えられる前に解けたためしがない。強いて言えば制約の数字に特徴が現れるが、手掛かりがなさすぎる。■提出 #35327661 (AC / 477 Byte / 472 ms)。最初から半分全列挙だとわかっていればやることはほとんど愚直解法なので。やっぱり TLE だよね、というのを確認していたものを手直ししただけ。■TLE 回避のために半分全列挙でない問題を半分全列挙みたいに解いたことがあるけど、無駄すぎる>20220726。点数とパフォーマンスにつなげたい。
L+1 を L に変更しただけなんだな。off-by-one エラーってやつ。TLE である 04_corner_11.txt はどんなコーナーケースか。ppppp....ppppp だろうことは想像に難くない。■提出 #34804490 (AC / 64 ms)。連続する p を一塊で扱うようにした。一番後ろの p を使わないで得をすることがないので。■■■C 問題「Lights Out on Tree」(水 diff)。与えられた頂点集合の上下関係を知るためにダブリングを書いたり、深さの偶奇が関係するかと思って深さを記録したりしたけど、実は直接の親子関係しか関係しなかった。ボタン操作の基本は「表向いてる親を裏返して、つられて反転した子孫ノードを裏向きに戻すために直接の子を再度裏返す」なんだけど、直接の子が最初に表向きだったノードなら操作回数が節約できる。■提出 #34798597 (TLE×18)。クエリのたびに子ノードのリストをたどる愚直解。■提出 #34799643 (AC / 422 ms)。子ノードは数だけ数えておいて一律に操作回数を計上し、子から親を調べることで足しすぎた分を引く。終了 12 分前に２完のノルマ達成。■■■B 問題と C 問題の配点が同じだから AC の２完遅解きは AB の２完遅解きと同じであり、２完遅解きは A の１完早解きに毛が生えたパフォーマンスしか出ない。-27。ARC にはレートを吸われてばかり。上昇したレートだけ数えたらもう赤なのではないか(頭がパー)。未来のレート上昇を演出するために現在のレートを捧げるのだ。2つの文字列のどっちを前にした方が得か考えてソートするのだ」というのが無意識に作用していた。二項関係だけでソートしていいんだと、知らずに気付かされていた。推移律はどうですか？ よくわかりませんよね。祈りながら提出したら AC だっただけです。■ゴルファーの提出(#34766963)を見てると複素数を使ってるんだけど、そういえば自分が書いたソートのための比較関数が外積と同じ式だった。この前の外積を使う問題(ABC266-C「Convex Quadrilateral」)を自分は複素数で解いたから(#34376180)、なにかしら関係があるのだろうか。ソートからどうして複素数が出てくるのか飛躍がありすぎてさっぱりわからんけど。「（解説を見て）なるほどこれ「Xの個数/1の個数」の降順にソートしてたのか」という声もあるけれど、こちらもさっぱりわからない。俺にもなるほどさせてくれ。