CF1137F

CF1137F

首先那个 compare 是过来搞笑的。

我们只关注这个 up,when 即可。

先关注最初的局面，我们通过一定观察会发现最后一次被删除的元素一定是最大值。

每次修改都是变成 \(\max+1\)，换而言之我们可以认为每次修改是使得某个元素变成了最后被删除的元素，为了方便考虑，我们令这棵树的根为最后一次被删除的元素。

通过一定的观察/手玩，设当前根为 \(\rm rt\)，修改至 \(v\)，则我们发现一次修改影响的答案仅为 \(rt\to v\) 这条路径，其余点的相对被删除顺序不会改变

感性理解可以将这条路径想象成一个大点缩起来，同时由于之前根为最后被删除的，所以在那个节点被删除（即其余所有点被删除）之前，这条路径上的节点不会被删除，于是可以直接当作大点看待是没有问题的，剩余的点显然顺序便不会改变。

进一步观察，我们不难得到一个这样的事实：对于初始树 \(T\)，我们可以将 \(n-1\) 到根\((n)\) 号节点的路径保留，那么这条路径自顶往下就是第二个被删除，第三个被删除...的节点。

然后我们类似于 LCT 的树上染色操作，从大到小枚举编号，如果当前节点没有被统计过，那么暴力向上统计直到遇到了一个被统计过的节点，然后自上而下，我们可以得到每个节点的被删除顺序。

假想本次操作是一个染色操作，那么每次修改本质上是破坏了若干条链，然后将这些节点合并成了一条新的链，并赋予新的颜色，而我们的查询，实际上是求当前链中有多少个节点比他深度更大，以及他之前的链的大小和。

如果将颜色从大到小（按照上述顺序）进行染色，那么查询本质在查颜色比他小的节点以及同色且深度比他大的节点的数量。

事实上，这个操作与 LCT 的 \(\rm access\) 和 \(\rm makeroot\) 操作异斧同工，我们不难想到对于每个同色连通块通过 \(\rm Splay\) 来维护相对深度，通过树状数组来维护颜色比 \(x\) 小的连通块的数量的前缀和，涉及到修改\((\rm makeroot)\) 时，我们不断对同色连通块做单点修改，每次查询直接做前缀查询即可。复杂度是 \(\mathcal O(n\log^2 n)\) 的。