In the tutorial of 1172E - Nauuo and ODT, I didn't write things on how to maintain subtree information, because I thought it was a popular trick. However, through tmwilliamlin168's comment, I realized that this trick may be not so common in other countries, so I decided to write a blog on it.
This blog will tell you how to maintain subtree information using LCT, with solutions on some problems, so you should know LCT before reading this blog.
Main Idea
The main idea is simple: record the sum of information of "virtual subtrees", where the "virtual subtrees" refers to the subtrees except the one in the Splay.
In the picture, $$$1$$$, $$$2$$$, $$$6$$$, $$$10$$$ are in a Splay, while $$$8$$$ and $$$12$$$ are in another. The "virtual subtrees" of $$$1$$$ is $$$3$$$ and $$$4$$$, the "virtual subtrees" of $$$4$$$ is $$$7$$$ and $$$8$$$, the node $$$8$$$ has no "virtual subtree".
You need to update the information when the "virtual subtrees" changes, usually, when accessing and linking.
An easy example is using LCT to maintain the size of subtrees.
Here are some codes:
struct Node
{
int fa, ch[2], siz, vir; // father, two children, size of subtrees (including the root), size of virtual subtrees
} t[N];
void access(int x)
{
for (int y = 0; x; x = t[y = x].fa)
{
Splay(x);
t[x].vir -= t[y].siz; // update the size of virtual subtrees
t[x].vir += t[t[x].ch[1]].siz;
t[x].ch[1] = y;
pushup(x); // update the information of the node x
}
}
void link(int x, int y)
{
makeroot(x);
access(y);
Splay(y);
t[x].fa = y;
t[y].vir += t[x].siz;
}
void pushup(int x)
{
t[x].siz = t[t[x].ch[0]].siz + t[t[x].ch[1]].siz + t[x].vir + 1;
}
Problems
Some problems are in Chinese, I will translate the statements (in a simplified version).
[BJOI2014] Great Integration
There are initially $$$n$$$ nodes, there will be $$$q$$$ operations in two types:
A x y
add an edge between $$$x$$$ and $$$y$$$Q x y
a query, asking how many simple paths are there which go through the edge between $$$x$$$ and $$$y$$$.
It is guaranteed that the graph is always a forest (one or more trees).
Input
n m
m lines of operations
UOJ #207. Gongjia toured Changsha
There is a tree consisting of $$$n$$$ nodes and a multiset of simple paths $$$S$$$. $$$S$$$ is initially empty. There are $$$m$$$ operations in $$$4$$$ types:
x y u v
$$$cut(x, y)$$$, $$$link(u, v)$$$x y
insert the simple path $$$(x, y)$$$ in $$$S$$$x
delete the $$$x$$$-th simple path inserted in $$$S$$$x y
a query, asking if all simple paths in $$$S$$$ go through the edge $$$(x,y)$$$
It is guaranteed that the graph is always a tree.
Input
the id of subtask
n m
n-1 lines of the initial tree
m lines of operations
1172E - Nauuo and ODT
You can see the problem on Codeforces, and the tutorial is also available here.
Is it possible to both support path queries between u and v as well as subtree queries? My understanding is that to support path queries, one typically roots the "real" tree at u or v, and then can access the path query along the "aux/virtual" tree from the root to v.
However, that fundamentally changes the structure of the "real" tree, right? Isn't that incompatible with subtree queries? I could imagine one could do it if you implemented path queries with LCA or something like that, but I haven't seen anybody do so.
Notation: "aux/virtual" tree = tree represented by splay "real" tree = your underlying tree being represented.
I believe the link function in your example code should have a "access(y);splay(y)" just like in your code for "[BJOI2014] Great Integration"?
Added now.
Can this be adapted to maintain aggregate subtree values for things that you can't 'remove' from? Like subtree max, for instance?
Yes. You can change the variable vir from an integer to a multiset, and change the corresponding function.
Okay, I think I see. And then if you needed something like GCD, you could make it a treap and recalculate the answer in log(n) time each remove. I suppose it adds a log factor to everything, but it works. Thanks!