Mato is No.1

（从NOI以后一直在各网站上做水题……谁叫我这么弱做不动难题呢……）
（最近实在感觉到弱得令人吃惊……这样下去还混什么集训队啊……于是只好去挑难题了……中间对某些知识点有一些见解……就总结在这里了囧……）

（最近见到了比较多的树分治的题目，因此第0个总结的就是树分治了……）

相关论文

树分治用于解决有关路径的问题。
树分治分为点分治和边分治（其实还有一种叫“链分治”，是树的路径剖分思想的更高级的体现，一般链分治的题目都可以用路径剖分解决）。点分治就是每次找到重心，然后把重心去掉，对分成的每两棵树之间分别统计路径信息（以重心的每个相邻点为根，遍历整棵子树即可得到这个根到每个结点的统计信息），就可以知道包含这个重心的所有路径的信息，然后对于剩下的路径就是在子树里面进行同样的操作了，直到只剩一个点为止（注意这一个点所构成的路径有时也要处理一下）。边分治就是每次找到一条边，使得删掉这条边后分成的两棵子树大小尽可能平均，然后以删掉的边的两端点为根，分别统计根到两棵树中的每个结点的路径信息，最后合并算路径，即可得到包含这条边的所有路径的信息，剩下的路径在两棵树中递归处理。

点分治和边分治是可以通用的，不管树上的信息记录在结点上还是边上。这时一个很囧的问题就出现了：这两种分治到底哪个好？这也是本总结讨论的重点。
有关“哪个好”的问题显然要从三种复杂度上考虑。由于点分治和边分治的空间复杂度均为O(N)，因此讨论空间复杂度木有意义。所以需要比较的就是时间复杂度和编程复杂度了。
先说时间复杂度。点分治每次找到重心后，需要将重心删掉然后分成很多棵子树，对每两棵子树之间都要统计一下。如果操作是可反的（比如计数问题：统计某种路径的条数），可以通过先将所有子树合在一起统计，再减去两端点处在相同子树内的路径，但是，如果操作不可反（比如找“最优路径”），就不能这样做了，只能枚举所有的子树对。显然，如果有S棵子树，则有O(S²)个子树对，最坏情况下（星形的树），S=N-1，此时一一枚举子树对必然会导致总时间复杂度升到O(N²)以上。当然这是有解决办法的，可以从小到大枚举子树，每处理完一棵子树就将其和前面的合并，此时算法效率取决于合并的方法。如果使用归并法（大小为A的和大小为B的合并次数为A+B），对于星形树的合并总次数仍然为O(N²)，如果能保证大小为A的和大小为B的合并次数为min{A, B}，则可以保证合并总次数在O(N)以内，从而可以保证总时间复杂度为O(NlogN)。边分治由于分成的永远是两棵子树，所以在处理子树之间的关系上能够保证O(N)，问题是它并不能保证每次分成的两棵子树大小非常平均，在最坏情况下（星形的树），不管删哪条边分成的两棵子树大小都是一个1一个(N-1)，这样就会使总的时间复杂度上升为O(N²)。

从以上的讨论中可以看出，点分治和边分治最怕的都是星形的树，也就是那种某个点的度数特别大的树。相关论文中提到一种办法通过加无用点的方式将其转化为二叉树，从而解决这个问题。这样一来，点分治和边分治的时间复杂度都可以保证了。接下来是编程复杂度的问题：点分治需要找重心（三次DFS或BFS），删掉重心（需要删点），且分成最多三棵树，需要处理三对关系，代码量肯定大一些，而边分治只需要算出子树大小后就可以找到最优边，并且分成的是两棵树，更重要的是，在有根树上删掉一条边后，分成的两棵树中有一棵已是有根树，另一棵可以通过扭根的方式将其转化为有根树，由于二叉树扭根是很方便的，所以就不需要每次重新建树，代码量较小。综合以上因素，边分治更好些。

另外，其实那种加无用点转化为二叉树的方式是有问题的，因为它改变了路径的意义，可能导致一条路径由于LCA是无用点而在统计时出现错误（明明是跨越了重心或最优边的路径被当成木有跨越的），但是……这个问题有一种很简单的解决办法，想知道是什么……AC了ALOEXT再告诉你……

相关题目：
<1> (2013年候选队互测•a142857a) 树
边分治，每次找到所有点到根路径的XOR和，以及特殊点的个数，按照特殊点个数排序后有序插入Trie，查找即可。
代码：
<2> (VK Cup 2012 R1-D) Distance in Tree
边分治，很容易实现，不说了。
代码：不显示。