Union-Find(并查集): Quick union improvements

Quick union improvements1: weighting

为了防止生成高的树，将smaller tree放在larger tree的下面（smaller 和larger是指number of objects）,而不是将larger tree放在smaller tree的下面(如上图中的第一种情况)

Examples: quick-union & weighted quick-union

从上面的这个例子可以看到用quick-union时的树的高度很大，而用weighted quick-union时，树的高度要小得多。

Java代码的实现weighted quick-union

数据结构与quick-union相似，用数组来表示，不同的是多了一个表示以该结点为root的objects的个数的数组=>sz[n]

在union中对这个sz[n]进行修改操作，合并时要修改相应root的objects的个数

没有增加多少代码，但是却大大的提升了算法的性能

weighted quick-union性能分析

Find和union都是O(lgN)，树高度最坏的情况下为lgN

如果N为1000,则lgN=10,N=10⁶，则lgN=20,可以看出随着N的增大，lgN要远远小于N，即lgN的性能要比N要好很多

weighted quick-union性能分析:为什么是lgN

数学归纳法：

weighted quick-union性能分析比较

性能还有提高的空间吗？=>path compression

 improvements2: Path compression

如上图所示，将寻找P的root时所经过的所有的结点，都直接指向root,这样树就会变平。

Path compression：用java实现,在root函数里面

我们仅仅只需要一行代码(白色的部分)就可以基本实现将树变平,这行代码是将node指向它的祖父母(grandnparents)。

虽然它并没有像上上个图那样完全将树变平，但是实际使用过程中，这种方法已经足够好了（keeps tree almost completely flat）。

weighted quick-union with path compression

lg*N是指对N做lg操作到1所要进行的次数（迭代次数）

lg*N最大不会超过5因为2⁶⁵⁵³⁶是5

实际操作中，WQUPC接近于线性的。

几种算法的性能对比

当我们使用WQUPC算法时，对于大型的复杂的问题带来的性能提升是supercomputer也不能带来的。(运行30年与运行6秒相比较)