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=106，则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因为265536是5
实际操作中，WQUPC接近于线性的。
几种算法的性能对比
当我们使用WQUPC算法时，对于大型的复杂的问题带来的性能提升是supercomputer也不能带来的。(运行30年与运行6秒相比较)