<< をおそらくヒアドキュメントの開始と勘違いしているせいで、lb メソッドと BIT クラスが折りたたみできなくなっている。直前に数値(1)があることは認識できてるんだから、ビットシフトと解釈するのが自然だと思うんだけどな。数値と文字列をそのまま並べるような文法はないのだから。■インスタンス変数 @a を ace_variable ace_instance とクラス分けしているあたり、完璧ではないけど Ruby のことを知ってそうな雰囲気はある。■レイヤー分けの弱点がこういうところに現れたのだろうか。「AtCoder の新エディタに使われている Ace、多バイト文字の扱いがたまに怪しいので、 「※」などの全角記号を使うとカーソルの位置がズレる （※は「なでしこ」の行コメントの1つ、「プロデル」のプリプロセッサとして使われている） https://t.co/YwDlWqNNjf」。ひらがなとか漢字を使ったくらいでは問題ないので、あまり気にすることはないかな。それを確かめるためにさっきリンクした(日本語変数を使っている)提出をいろいろ調べていた。■もう昨日だけどこんなんがあったらしい。「新エディタテストコンテス」。A 問題難しくない？ 前回の ABC-G に似た雰囲気を感じる。"月 日" という文字列の配列を全部生成してから真ん中を選んだんだけど、そこはさ、単に通年での day-of-year を数えておいて、文字列を生成するかわりに適切なタイミングで答えを出力すれば良かったじゃない。■C 問題「Flavors」。フレイバーごとにおいしさを記録してから異種組み合わせと同種組み合わせを考えた。ツイッターを見てると最大のおいしさが必ず採用されることに着目した解法が目立つ。そのアイスを２回食べてしまうミスにだけ注意すれば配列１本で処理できるのが魅力的な解法だと思う。ミスへの対処法は、必ず選ぶ１つを配列の先頭もしくは末尾の要素とスワップして、先頭もしくは末尾を探索範囲から外すのがいいかな。■D 問題「Magical Cookies」。最終的に E 問題の３分の１くらいしか正解者がいないいわくありげな問題。下手をするとすぐ TLE になるみたい？ 自分も 35 分と、E 問題より時間をかけて慎重にやっている。TLE 以外に小さな罠もあるにはあって、問題文に書いてある通りの手順を守らないと最後に残るクッキーが違ってくるような気がする。行を取り除くには２列以上、列を取り除くには２行以上残っていないといけないという条件から、残り２行もしくは残り２列付近で手順が最終結果を左右するのではないかと思う。手順を守るように途中で書き直したおかげかは知らないけど、というか書き直しだけなら５回も６回もそれ以上でも行きつ戻りつしていたのだけど、ペナルティを出さずに AC だった。TLE を回避する手段は、まだ残っている行番号と列番号を記録して使用することと、行と列にある文字の種類と数を記録して使用すること。■E 問題「Prerequisites」。スタックに積んで順番に読むだけ。WA を出したのはひとえにあほだからです。もう読んだフラグを立てるタイミングを間違えた。そのタイミングで何かするのを帰りがけ順っていうらしい(聞いたことはあるよ)。■F 問題「Shortcuts」。とりあえず DP で解けるのはわかる。制約が１万以下とよくあるものより１桁少ない。２乗で１億、定数倍２分の１で 5000 万。言語アップデートにより「倍早い」こともある Ruby-3.2 ならワンチャンあるかという数字。時間内に提出したものは TLE だった。ああ無情。■F 問題。悪いのはもちろん Ruby ではない。実は途中で必要に迫られて DP 配列の次元を増やしていた。O(N^3) にはどんなチャンスもない。ツイッターで見ちゃったんですよ、ペナルティは 50 回まで考えれば十分だと。見積もってみれば 28 ビットで上限を突破しそうだったので 30 を上限にしてみたら通った。O(30*30*N) だから 900 万のレベル。大枠は完成していたんだから時間内に通したかったねえ。SyntaxError: invalid identity escape in regular expression editor.bundle.min.js:1:882506」というエラーが出るのはブラウザが古すぎるせいかもしれないけど、ページのつくりとして、静的に完成したページを出してからデコレートしてほしい。そしたらデコレート部分がシンタックスエラーで壊れていても影響がない。提出結果ページにおいて不可欠のコンテンツが提出内容であるソースコードだということを忘れてほしくない。そして、コンテンツはマークアップ対象としてあるべきであって、属性値に置くのは筋違いだというのが原理主義的な意見。スクリプトがなくても、スタイルシートがなくても、タグがなくても残るのがコンテンツ。もっとも、最近そういうのは API をたたいて JSON なりなんなりで取得するみたい？■Twitter でも提出結果ページが壊れてるって報告が見えるので流動的だとは思うけど、とりあえずこれで>AtCoder-Submission-Page-Fix.txt。以前の提出結果ページとくらべて copy ボタンは機能しないし行番号もなくなったけど、それでも、最低限はある。ソースコードが読めるようにはなった。
4 4／1 2 R／4 3 B／4 1 B／3 4 R／RRRB。１と２の頂点は１番の辺で両方とも満足している。３番の頂点を満足させられるのは４番の辺だけ。４番の頂点を満足させられるのは２番と３番の辺だけど、２番の辺を使ってしまうと３番の頂点を満足させる方法がなくなってしまう。２番の辺と４番の辺は同じ２頂点を結んでいてそれぞれ異なる側を満足させる対称的な辺だけど、これに正しい優先順位を付けて使用しなければ答えを誤る。小数第 N+1 位で切り捨て」と書かれているのがミスリーディングだと思う(やつあたり)。切り捨てであってもないもの(N+1 桁目)を操作することはできないじゃない。考えちゃうよ。提出 #44490051 (AC / 142 Byte / 43 ms)。■B 問題「Roulette」。制約は小さいしやるだけではある。でもあまりやりたくない気分になる。見通しよく素直に実装すると３パスの操作になる。すぱっときれいに片付ける方法はないものか。考えた結果ソートなんてしてしまう人間(私です)は計算量についてイチからやり直そうな。提出 #44494576 (AC / 235 Byte / 44 ms)。■C 問題「Rotate Colored Subsequence」。色ごとに文字を積んでローテートして取り出すだけではある。でもケチなことを考えた。総要素数が N 個になる M 個の配列を作りたくないなと。要素数 M 個の文字配列だけで済ませたいなと。それで TLE を出しているのはただの間抜け。4-7 行目が良くなかった。提出 #44500699 (AC / 220 Byte / 158 ms)。TLE の解消方法がまだいまいち。reverse_each をやめても前から順に常に上書きするなら同じ結果が得られる。■D 問題「LOWER」。クエリ２と３があると文字列の大文字小文字がすべて決まってしまうのだから、文字列を直接書き換える他に、クエリ２と３の後のクエリ１についてだけ記録を残して上書きすればいい。例によって toupper やら tolower やら locase やらを試してとうとうリファレンスを調べた。upcase の反対は downcase らしいです。提出 #44506770 (AC / 266 Byte / 666 ms)。クエリ先読みが有力だったっぽい。■G 問題「Amulets」。問題の構図は比較的理解しやすく、データ構造の知識が問われる問題だった。持ち込むアミュレットの種類は後出しで選ぶ。どのように選ぶか。n 体目のモンスターまでで総ダメージが sa になるとする。モンスターのタイプ別でも総ダメージを記録しておく。タイプ別総ダメージが大きい方から k 個を選んでアミュレットでダメージを無効化するのが最善。その結果総ダメージが H 未満になるならいいが、H 以上になるなら n 体目のモンスターは倒せなかった。アミュレットの個数と倒せるモンスターの数は比例関係にあるので、アミュレットの数とモンスターの数を増やしながら答えを記録していく。たぶんだけどアミュレットは増加していく単一の集合ではないと思う。つまり、k=2 で選ぶアミュレットは k=1 で選ぶアミュレット＋１ではないと思う。だから BIT で都度都度最適な k 個を選ぶようにした。top k の総和を効率良く求めることがこの問題の中心だった。BIT にたどり着く前にはプライオリティキューを貼り付けたりしていた(でも行き止まり)。BIT で個数と総和を管理するのはついこの前 ABC312-F Cans and Openers でやったばかり>提出 #44067838。その問題にその解法は log が余分に付くうまくない解答だったのだけど、それが今日の解答のプロトタイプになったのだから怪我の功名。提出 #44529976 (AC / 1412 Byte / 1731 ms)。べつに今回が２回目ってわけでもない。ABC287-G Balance Update Query への提出 #38427641 でもやってる。