yukicoder No.2116 Making Forest Hard を平方分割+rerootingで解く
お久しぶりです。最近はTTPC2022のtesterやったりICPC観戦したりして急に競プロ熱が再燃しています。
ところで今回はyukicoder No.2116 “Making Forest Hard” を平方分割+rerootingで解こうと思います。
https://yukicoder.me/problems/no/2116
問題概要
- 頂点の木 がある
- 各頂点には整数 が書かれている
- 木 の任意の連結成分 について、 内の頂点数を 、 内の頂点の最大の の値を と定義し、連結成分 のスコアを と定義する
- 木 の辺集合 の任意の部分集合 を考え、 から の辺をすべて削除した木(連結成分)の集合を とする
- のスコアを、任意の 内の連結成分 のスコアの総和 と定義する
- 任意の部分集合 に対する のスコアの総和 を MOD で剰余を取って出力せよ
基本考察: 寄与
最大値(×サイズ)の任意の操作における総和を考える際、典型的な方法の1つが寄与の計算です。 今回はある頂点 に書かれている値 がどの程度スコアに寄与するかを考えます。
なお、 の計算のために使う最大値計算を、頂点IDによってタイブレークしてどの頂点の値かを一意に定めることにします。つまり のようにします。
以降はこのタイブレークされた値を考え、 は全て相違なるものと仮定し、単純に の大小で記述します。
木DP O(N2)
さて、頂点 に着目するため、一度 を根として木を見、これを とします(元々の木 は根の決まっていない無向木です)。
例として適当な木 を挙げます。 に着目しています。
なお簡単のため、この図では頂点ID = としています。実際の問題ではそのような制約は無いので留意してください。
またグレーに塗られた頂点は となる頂点です。これらの頂点は連結成分に含まれないようにする必要があります。
この根付き木 において、各頂点 について
- を根とした の部分木(連結成分) で、 であるようなものの通り数
- そのような についての の総和
- を根とした の部分木に含まれる辺の数
を求める木DPを考えます。
まず辺の数 はそのまま辺の数を足し上げるだけで良いです。
次に について、頂点 に対して子 の部分木の結果を順番にマージした際の値の変化を考えます。 子 の手前までマージしていった現在の頂点 の値を とし、子 をマージした後の値を とします。子 の値は とします。
- 辺 を加え入れる場合
- 通り数は 側と 側の値を乗算することになり となる
- サイズの総和は 側の総和 が 通り寄与し、 側の総和 が 通り寄与するため、 となる
- 辺 を取り除く場合
- 子 の部分木内に含まれる辺はどのようにしても良くなる
- そのため 及び となる
以降、簡単のため と表記します。また毎回 pow を計算するのも面倒なので実装上も基本的にはこの形で持つことにします。
この2通りを足し合わせれば良いですが、 となる場合は辺 を取り除かなければなりません。よって
- の時
- の時
となりますが、 の時に とすれば上側の計算だけで済みます。 またこれらの計算は全て の線形和になるので、初期化のタイミングで とすれば場合分けが除去できます。 ちなみに の場合は と初期化します。
木DPの結果、 に の寄与する乗数が求まるため、答えに を足し合わせます。
以上で、各頂点 に対して のDFSで寄与が求まるため、全ての頂点に対して行えばトータル の計算量で求まりました。
発展考察: 平方分割+rerooting
さて、木DPを高速化するにあたり、典型の一つである全方位木DPを考えてみます。が、上述の木DPは根の値 に応じてグレーに塗られた切らなければいけないノード が変わるという問題点があります。
逆に という制約に対処しようと考えると の昇順もしくは降順で木DPすることで、変化する頂点は根に来るため の変化でほとんど同じ木DPを解くことが出来るようになりますが、逆にrerootingのコストが1回につき最大で直径分かかります。
そこで、平方分割によって木の直径を に圧縮し、rerootingのコストを1回あたり とし、トータルコストを にすることを目指します。
平方分割
平方分割した状態でrerootingとクエリ対象の頂点編集を行いたいので、次のような性質が必要です:
- クエリする頂点集合を とする
- 頂点 は圧縮しない
- 平方分割後の木の直径が である
- 木DPの値の整合性を保ったまま回転が出来る
このように平方分割するには次のようにするのが良いです:
- を根とするような木を考える
- 任意の について、 も圧縮しない
- このとき、圧縮しない頂点を分割点と呼び、その集合を とする
- このとき が根であることに注意すると
- によって分割された連結成分について、それらは1個か2個の分割点と繋がっている
- 0個: 元々その連結成分が木全体である場合のみ起こり得るが のため存在しない
- 3個以上: そのような連結成分があると仮定すると、連結成分内のある1つの頂点から相違なる3つの分割点 への交わらないパスが取れるが、このときその頂点は3つの分割点のどれかのLCAであり、 に属さない頂点から構成されるという仮定に矛盾するため、存在しない
- (これはつまるところtop treeにおけるclusterとboundary vertexである)
- 2個の分割点と繋がっている連結成分はたかだか 個
- つまり 個
下図はクエリする頂点集合を 9~12 としたときの木のサンプルです。
青い 9~12 の頂点が 、赤い 7 の頂点が 、太めの黒い曲線に囲まれた連結成分が2点の分割点に隣接する(圧縮対象の)連結成分です。
分割点では通常の木DPを計算することとし、連結成分に対する木DPを効率化します。
- 全ての分割された連結成分について、隣接する分割点を根方向としたときの木DPの値を計算できるようにする
- 隣接1個: rerootingによって根方向が変わることは無いため、特に何もしなくて良い(極論圧縮もしなくて良い)
- 隣接2個: rerootingによって根方向が変わることがあり、たかだか1個の分割点を部分木に持つ。この分割点以下の木DPの値を入力とし、もう一方の分割点を根方向とした連結成分の木DPの値を出力する作用素を構成する必要がある
この作用素について考えます。
木DPの圧縮
元の木DPを再掲します:
葉方向の分割点を とすると、木の回転などによって の値は変化するため、これらの値を自由変数と考えると、
- 分割点 : という値は の線形結合(恒等関数)で書ける
- 分割点 を子孫に含まない頂点 : に依存しない定数値で書ける
- 分割点 を子孫に含む頂点 : 分割点 を含む部分木が の線形結合で書けるなら、定数とのマージなので計算結果も の線形結合で書ける
- の深さに関する帰納法で証明できる
となるため、この線形結合の係数行列さえ保存すれば木の回転によって根方向が変わった場合でも木DPの値を高速に更新することが出来ます。
木DPの計算式から上三角行列となるため、係数保持に必要な値は6個で十分です(実際には5個でも大丈夫です)。
木DPのrerooting
次に木の回転(rerooting)を考えます。
rerootingの典型として「逆演算を定義し、回転する部分木を打ち消す」という手法が考えられます。一方で今回は剰余乗算を含んでいるため、0が乗算される際の扱いが困難です。また剰余除算に がかかってしまうのもネックです。
今回は平方分割によって主要な木の頂点数が となっているため、そもそも任意のパス上の次数の総和も になりそうです。
ただし分割点との隣接が1点のみの連結成分の数は抑えられていません。これらの部分木については値の更新が行われないため、木の回転のたびに計算しないようにすることで、1回の rerooting が で収まります。
実装方針
- 根 を決める
- 最初のクエリは について行うことに留意
- の頂点を塗っておく
- 圧縮のDFSを行う: 各頂点 について
- の子孫に の頂点を含むか、 の頂点を含む子の数を求める
- の頂点を含む子の数が1の場合は圧縮対象、2以上の場合は分割点となる
- 通常の木DPの値 及び の頂点を含まないstaticな木DPの値 を求める
- 圧縮対象の分割点へのリンクと係数行列を計算する
- 圧縮対象のパスの長さが1の場合は圧縮しないことにするとちょっと楽
- の子孫に の頂点を含むか、 の頂点を含む子の数を求める
- について
- を根にする: の親を根にする(再帰) → が浅くなるように回転する
- 回転は圧縮ノードを間に挟むか否かで若干変わる
- についてクエリ結果を求める
- を変化させる (今回は となるように変化させる等)
- を根にする: の親を根にする(再帰) → が浅くなるように回転する
解答ソース
まとめ
ちなみにオフライン限定ですが、直径が のためパス系クエリや、圧縮をうまく取り扱えば遅延伝播系クエリ、更に森に対して圧縮すればLink Cutにも対応出来ると思います。
まぁ多分top-treeで良いんですが、しいて言えば以下のメリットを見いだせると思います:
- 「木を木で取り扱う」のに対し、このアルゴリズムは連結成分の圧縮しかしない
- 定数倍は軽い(はず)
- オーダーはめちゃめちゃ悪い、まだ最適化の余地がありそうですが N=100000 が限度だと思います
- 実装も軽い(はず)
- 多分……オフラインだからその取り扱いが煩雑かも
補遺: 経緯
今回のアルゴリズムはTTPC2022のtesterをしている際に思いついたものになります。TTPC2022 testerに呼んでくださった運営の方ありがとうございました。今更ですが参加してくださった皆様もありがとうございました。
実はもう1問原案を担当していたのですが⋯ pic.twitter.com/6bipTytdYh
— ⚡すく⚡ (@0214sh7) 2022年11月5日
まぁTTPC2022の木の問題はD: XOR Tree Pathだけだったんですけどね。
参考文献
- 木の平方分割、出来るもの出来ないもの - noshi91のメモ
- https://noshi91.hatenablog.com/entry/2019/12/07/140433
- 今回使った平方分割は例1の亜種と言えそうです
- top tree 概要 - noshi91のメモ
- https://noshi91.hatenablog.com/entry/2019/08/05/175545
- 概念を考えるにあたって参考になりました
- 列と木の対比と言えば、列のマージ・分割に対するオンライン平方分割のようなデータ構造が確か存在します
- もしかしたら今回の手法も似た形でオンライン化が可能かもしれません (が、速度が実用に耐えない予感がします)
- 東京工業大学プログラミングコンテスト2022 - AtCoder
- https://atcoder.jp/contests/ttpc2022
- 2015と2019もよろしくお願いします