A.*B 型の入力はどうやっても不可。次に、文字数が奇数のときは中心に自由に使える文字があるので、左右どちらの半分の文字列に対しても右から寄せるような操作も左から寄せるような操作も好きに選ぶことができるので、左右ともに好きな文字列に書き換えられて回文にもできる。ここまでは当日にもわかっていた。今日お風呂で考えていて気がついたのは、ある程度の文字数があればどんな入力でも BA+B+A+B 型か AB+A+B+A 型の文字列に書き換えられるな、ということ。要するに最低５文字あって A.*B 型でなければ常に Yes。というわけであとは N=2 と N=4 だけケアできれば良い。■提出 #33772876 (AC / 258 Byte / 86 ms)。ほとんどどんな文字列でも回文に書き換えられるので、入力の長さと４文字だけ見れば答えが出せる。なんだよそれー。縛りがざる過ぎて逆に手掛かりが少ないのが難しい。■@2022-08-10 それどころではなかったな。こちらの提出 #33643866 (AC / 75 Byte) を見ると A.*B 型と N=2 だけケアすれば答えが出せたらしい。■■■精進２。同 ARC-B「AB Game」(茶 diff)。公倍数を使うのかなとか予想しながら考えてみたらもっと単純だった。まず N/A、N/B でそれぞれが可能な操作回数の最大がわかる。この時点で N/A = 0 なら Alice の負けが確定する。それぞれ最大の回数が決まっていて、自分の操作回数を残しながら相手の操作回数を削るには……とか考え始めたんだけど、もし A<=B なら Alice が最大限取り去った残りは B より少ないのが決まっていて Bob は１回も操作できない。これは逆も言えて、もし A>=B で Bob に操作が回ったなら Alice に勝ちの目はない。０手１手２手までで全部決まる。■提出 #33773060 (AC / 149 Byte / 59 ms)。A の剰余(0..A-1)が A..N のあいだに何周といくつあるかを N/A と N%A で数えるだけ。～だけって言うなら当日に AC を取りなさいよ。d1.values_at(*vs).sum が vs.sum{|v| d1[v] } だともっとオーバーする。頂点ごとにまとめた辺(E)の代わりに辺の集合(UV)をそのまま使うと制限時間を数倍オーバーする。色々な積み重ねの上できわっきわの AC なんだ。初期値& で初期値が１のビットに対応する累積結果を取り出し、~初期値& で初期値が０のビットに対応する累積結果を取り出すみたい。実際、初期値２種類、出力２種類の４通りしか考えることがない単純な問題なんだよ、本来は。自分の提出 #33472932がなんで実際のビット演算をする代わりに :nop, :zero, :one, :flip という疑似演算子を使っているかというと、初期値のビットが１の場合と０の場合の２種類のケースを分けて準備すればいいということに気がつけなかったから、０が来ても１が来ても１つのデータで両対応できるように、疑似演算子を操作して実際の演算を遅延させるしかなかった。疑似演算子だから 30 ビット並列でまとめて計算することもできなかった。不思議だね、愚か者は自分で問題を難しくするんだね。そして本当に難しい問題は自分が理解できる程度まで過度に単純化して間違えるんだよね。度し難い。I = Array.new(M+1){[]} と T = [0]*N というデータの置き場所を用意したところが解法の８割。それぞれ、I が Ai や Bi といった 1..M の範囲の値から i を逆引きするもので、T が現在の尺取りの範囲が何種類の条件を満たしているかを数えるための 0,1,2 の３値の配列。■Ruby によるすべての提出を見ると、最初の提出 #33313831がコンテスト中唯一の AC だというのがすごいね。中身を見ると構成も記述も自分の提出とそっくりで驚く(Ruby で青色になるような人でも for ループ、while ループ、if 式をばりばりに使う手続き型のコードを書いてたりするんだ。そういうのはだらだらとまとまりがなくて読むのがつらい)。自分も時間内に書けて然るべきなんだよなあ。■D 問題「Draw Your Cards」は緑 diff だったみたいだけど、まだ解けないよ。土曜日の緑は昨日(20220718)片付いたけど、こっちの緑はこのまま解けずの緑になりそうだよ。LIS をやりながら配列の中間削除を繰り返す愚直解法しか思いつかないよ。