F = lambda{|a,p,k| } のシグニチャが見いだせたら９割解けている。それがなかなか解らなかった。シグニチャとは、親が p である(p の色は決定済みである)ノード a が取り得る色が k 種類のとき、a を根とする部分木を塗り分ける通り数。■提出 #34462566 (AC / 262 Byte / 313 ms)。こんがらかった考えをお風呂で整理したら、９行目の K-1,K-2 の場合分けが自然に出てきて、するするっと実装が完了しました。昨日から何度も解けた気がしては答えが合わないということを繰り返していたのにね。
.min だった部分を .then(&@m) に書き換えただけで通ってしまうのだなあ。あと細かいことだけど、コンストラクタに lambda を渡したのは失敗。ブロックが普通。b = a^x; (b&x)-(b&a) を書いた。これの間違いは A の方が X より大きな MSB を持つときに、それを操作(足し算)回数の節約には利用できないし、ましてや負の操作回数によって操作回数を貯金することもできないのにしてしまっているところ。■提出 #34171598 (WA×4 / TLE×10)。さっきの提出の修正版。BIT の添字の操作と同じように LSB を順番に取り出して、節約できる操作回数を正確に数えるようにした。WA が大幅に減って TLE が生じてるのはその結果。ではすべてが TLE になるのではなく依然として WA が４つあるのはなぜか。解を二分探索しているのだけど、MSB が異なる２つの解を比較したとき、ある要素 A にとって小さい方の解では無視されたビットが大きい方の解では操作回数の節約に利用できるという状況が起こりうる。判定に単調性がない。■……１時間経過。提出 #34178565 (TLE×1 / 5307 ms)。解の MSB が同じなら単調性があるわけなので高次のビットから 0/1 を決める方針。１ケースだけ 307 ms オーバーした。■終了後の提出 #34182184 (AC / 2052 ms)。判定が済んだ部分について入力のビットを折っておくことで時間の節約をした。そうすると決めて時間があれば書き換えはただの作業。■あわや緑落ちかというところまで下降しているレートにとっては１完でも +1 だったので、悪い日ではなかった。以下の操作を 0 回以上 N 回以下行うことができます」という制約が付いていた。一応ね、実装前にざっと制約を探しはしていた。でも制約セクションには入力の制約は書いてあっても出力の制約は書かれていなかったのだな。転倒数の総和の最大値はたぶん入力となる数列が逆順にソートされている場合で、0 から 2N-1 の範囲の和(=N(2N-1))になるから、入力次第で操作回数が N を超える。■次に考えたのは、入力の先頭を出力の先頭にとりあえず配置して、次に配置する要素を、出力の末尾との比較によって入力の前の方から貪欲に引っぱってくる方法。考えなければいけないのは、出力の末尾より大きい(小さい)要素が入力の中に残っていないときにどうやってジグザグを維持するか。たとえば出力の末尾２要素が O1,O2 で入力の残りが I1,I2,I3 のときに大小関係が O1<O2<I1<I2<I3 だったら、O2 より小さい要素を入力から選んでジグザグを作ることができない。解決するのは簡単で、入力の先頭を出力の末尾の１つ手前に挿入すればジグザグになる。O1 との大小関係も大丈夫。I1 が O1 より小さいせいでジグザグが壊れるならそもそも苦労していない。この解法のネックも操作回数で、2N の入力のそれぞれに対して 0 回から複数回の操作が必要になる。ランダム入力では N=100000 に対して 180000 回くらいの操作が必要になった。■次に思いついたのは(考えたって書くのやめちゃった)、さっきの解法の例で出した O1,O2,I1,I2,I3 の中で、O2,I1,I2 の大小関係にだけ注目してジグザグが作れるんじゃないかということ。３つの大小関係がどうであれ０回か１回のスワップで山ないしは谷が作れる。(O2 がスワップ対象だけど)スワップによる既成出力への影響はどうか。スワップが必要なのは真ん中の要素が山なら極大値、谷なら極小値になっていなければいけないのにそうではなかったときだから、山を作るためにスワップされたどちらかの端の要素はそれまでより小さくなり、逆に谷を作るためのスワップでは端の要素が大きくなる。山になる要素の隣は谷になるべき要素だから、スワップで小さくなってもジグザグは維持される。谷を作る場合も同じ。■提出 #34071956 (AC / 331 Byte / 212 ms)。N 回のループの各回で１回以下のスワップだから交換回数も大丈夫。精進だからこそトントントンと AC までステップが踏めたんだろうなあ。２番目のトンがなければ AC につながる３歩目のトンはなかったし、次の一歩が出てこないことも２歩目があさっての方向に向いていることもよくあることなので、５割以上の確率で０完になる AGC はリスキーすぎる。緑だったときにレート変動対象から外れて以来不参加だよ。■■■B 問題「Adjacent Chmax」は小さい P から順番に DP かなと思ったけど、何を記録するのかが(実装を始めても)はっきりせず。
低血糖症(ハイパーグリセミア hyperglycemia)」と書かれていた。低なのに hyper？ hypo では？ と疑問に思って検索したらやっぱり Wikipedia には hypoglycemia と書いてある。そうだと思った。■ここからが自分の鈍いところだけど、タイポグリセミアに残っているのはグリセミアであって低～要素が残ってないし、高血糖症からできあがっていていけない理由はないよねって思ったけど(食い違っている症状名カタカナ英語のどれが間違いで訂正すべき対象なのかを考えていた)、ややあって typo と hypo がかかっていることに気がついたのだった。hypoglycemia だから typoglycemia なのであって低血糖症でなければいけないのだった。
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 を取りなさいよ。