前言:
现时同学们对“并查集算法视频”大约比较讲究,同学们都想要知道一些“并查集算法视频”的相关内容。那么小编也在网络上收集了一些有关“并查集算法视频””的相关文章,希望同学们能喜欢,姐妹们一起来了解一下吧!今天是算法与数据结构的第18篇文章,我们一起来看一个经典的数据结构——并查集。
首先我们来解释一下这个数据结构的名称,并查集其实是一个缩写,并指的是合并,查指的是查找,集自然就是集合。所以并查集的全称是合并查找集合,那么顾名思义,这是一个用来合并、查找集合的数据结构。
并查集的定义
集合虽然是一个抽象的概念,但是生活当中关于集合的操作其实不少,只是我们身处其中的时候往往习以为常了。
举个例子,比如A和B两个人都是社会精英,两人名下都有一大笔资产。突然某一天,两个人宣布结婚了,那么很显然,一般情况下两个人的资产会被合并成夫妻共同财产。如果我们把它们两人的资产都看成是一个集合,那么结婚其实就代表了这两个集合进行合并。再举一个例子,比如在古时候交通不便,河两岸的村庄往往很少来往。如果某一天河上建了一座桥,连通了河两岸,如果我们把两岸的紧密来往的村庄各自看成是一个集合,桥的建成显然也会让这两个集合合并。
上面的例子都是关于集合合并的, 关于集合查找的例子也很多。最经典的就是DNA检测,比如经常会有一些人号称自己是某某家族的后代。如果我们想要验证他们的身份最好的办法就是去查DNA谱系,我们人有一半的基因来自父亲,一半的基因来自母亲,这些基因也可以看成是集合。如果某个人号称是某朝皇室,我们把皇室的基因和他自己家族的基因一匹配,发现并非来自同一个集合,那么自然这些论调就不告而破了。据说科学家用这种方法考证了中山靖王刘胜并非刘邦的后裔,而是来自某个不知名的南方种群。
并查集正是解决了这两类集合相关的问题,即集合的合并与查找。
集合的查找
首先我们来看集合的查找,我们还是看上面那个例子,我们怎么判断两个不同的人是否来自同一个家族呢?
这个很简单,我们只需要查找它们是否有共同的祖先。如果我们基因分析他们两人的基因来自一个共同的祖先,那么说明这两人很有可能来自同一个家族。如果我们把这中间的血缘关系铺展开来,会得到一棵树形结构。祖先是树根,辈分最小的子女是树叶,和树一样,每个节点都只能有一个父节点(把父母看成一个节点),但是可以有多个子节点。
所以我们判断两个人是否来源同一个祖先,也就是判断两个节点是否在同一棵树。
由于我们要处理的数据有限,不像基因链路那么长,我们处理这个问题可以很简单。我们只需要找到这两个节点所处在的树的树根,然后比较它们的树根是否相等即可。如果相等,说明这两个节点来自同一棵树,自然属于同一个集合,否则则属于不同的集合。
到这里,我们不仅知道了应该如何查找两个节点是否属于同一个集合,还知道我们应该用树结构来表示集合。
集合的合并
既然我们明白了我们是通过树来表示集合,通过查找树根的方式来判断两个节点是否属于同一个集合,那么集合合并的操作就变得很简单了。我们只需要把两棵树合并就行了,如果需要考虑树深或者是逻辑结构的话,还不太容易,但是我们并不需要那么多信息,只需要保证集合内的元素正确。我们可以直接把其中一棵树连到另一颗树当中。
比如我们有A和B两棵树需要合并:
我们只需要将B的根节点连到A树上即可:
这样原来A树和B树上所有的节点都属于同一个集合,使用我们刚才查找的逻辑得出的结果也是正确的。但是我们分析一下会发现,如果我们这样合并两棵树的话会导致合并之后的树深变长,这样会使得我们后续查找的效率变低,因为我们从叶子节点到根节点变得更远了。所以我们可以直接将B树的树根指向A树的树根:
代码实现
对于树上的每一个节点而言,由于我们查找集合需要查找它们的树根,而不是叶子。所以对于树上的每一个节点而言,我们只需要记录它们的父节点即可。我们可以用一个dict存储所有节点的父节点,对于根节点而言,我们通常将它的父节点设置成它自己。也就是说当我们找到一个节点的父节点等于它自己的时候,就说明我们已经找到了树根。
明白了这个逻辑之后,我们用代码实现就变得非常简单:
father = {}def query(x): if father[x] == x: return x return query(father[x])def union(a, b): fa, fb = query(a), query(b) if fa == fb: return father[fb] = fa
你看,这段代码十行都不到,这样当然是可以work的,但是它还有很大进步的空间。
效率优化
虽然我们已经实现了算法,但是这并不是最优的,我们还可以进行一些优化。首先我们比较容易想到,既然我们每次判断元素是否在同一个集合是通过树根来判断的,并且我们并不在意树的结构,我们只在意树根是什么。既然如此,我们完全可以不用保留树的结构,让它变得扁平,让除了根节点之外的节点都是叶子节点,比如这样:
这两个棵树我们查询的结果是一样的,节点数和边的数量也是一样的,但不同的是左边的树我们查询树根最多需要遍历3次,但是右边的所有节点都最多只需要进行一次查询。如果树的结构更加复杂,那么这个优化还会更加明显。
但问题是我们做树结构的变动也是需要开销的,理论上来说每次我们进行合并之后,树结构都会发生变化。难道我们每次合并之后都需要耗费 O(n) 的时间进行树的重构吗?但我们并不能确定查找和合并出现的比例,有可能查找的情况很多,那我们重构树就是非常划算的,如果查找很少,大部分都是合并操作,那可能我们花了很大的代价进行了树重构,但是却没派上用场。
另外一个问题是,我们重构树是针对树上所有节点而言的,我们把所有节点都抬升到了根节点的子节点。但问题是可能并不是所有节点都参与查找的,有可能我们只查找其中几个节点的情况,那其余的节点我们也同样白白计算了。
针对这个问题,有一个非常简单也非常绝妙的优化——懒惰运算。
懒惰运算我们不是第一次遇见了,之前介绍替罪羊树的时候就曾经提到过懒惰运算。在替罪羊树当中,由于我们删除节点会导致树结构发生变化,这会带来大量开销。所以我们就不删除节点,而是给它打上一个已经删除的标记。这样当我们查找到这个节点的时候,这个节点当中的内容不参与查询,从而模拟删除。当打上了删除标记的节点数量达到一定程度的时候,我们再将它们整体批量删除。
在并查集当中同样用到了这样的懒惰计算的思想,如果我们要进行树的重构,那么势必需要查找根节点。查找根节点需要开销,那除了重构树的时候,还有什么情况下会需要重找根节点呢?很明显,就是当我们查找两个节点是否属于同一个集合的时候。既然如此,我们可以一边查找一边重构,将查找这条链路上所有的节点全部指向根节点。
我们来举个例子,假设某一次查找的是下图当中的F元素,那么查找完成之后,整棵树会变成右边的样子:
我们用递归很容易实现这个逻辑,非常简单:
def query(x): if father[x] == x: return x father[x] = query(father[x]) return father[x]
除此之外,我们还有另外一个优化。就是在我们合并两棵树的时候,其实我们合并的顺序是会影响合并之后的结果的。我们用下图举个例子:
从图中可以看到,同样是两棵子树相加,A+B和B+A的结果是不同的。这两个结果当然都是正确的,但问题在于它们的深度不同。我们把树深更小的B加到树深更大的A上得到的结果树深是3,但如果反过来,得到的树深会是4。所以我们会想到可以维护每一棵子树的树深,当我们进行合并的时候,永远把树深小的加到树深大的上面,而不是相反。
最后,我们把所有的思路全部整合,写出完整的代码,非常简单,核心逻辑只有40行不到。
class DisjointSet: def __init__(self, element_num=None): self._father = {} self._rank = {} # 初始化时每个元素单独成为一个集合 if element_num is not None: for i in range(element_num): self.add(i) def add(self, x): # 添加新集合 # 如果已经存在则跳过 if x in self._father: return self._father[x] = x self._rank[x] = 0 def _query(self, x): # 如果father[x] == x,说明x是树根 if self._father[x] == x: return x self._father[x] = self._query(self._father[x]) return self._father[x] def merge(self, x, y): if x not in self._father: self.add(x) if y not in self._father: self.add(y) # 查找到两个元素的树根 x = self._query(x) y = self._query(y) # 如果相等,说明属于同一个集合 if x == y: return # 否则将树深小的合并到树根大的上 if self._rank[x] < self._rank[y]: self._father[x] = y else: self._father[y] = x # 如果树深相等,合并之后树深+1 if self._rank[x] == self._rank[y]: self._rank[x] += 1 # 判断是否属于同一个集合 def same(self, x, y):总结
如果你仔细思考会发现树深优化有一点点问题,因为我们在查询树根的时候做了树的重构处理,所以很有可能在此过程当中树深会发生变化。比如刚好我们查找的是树深最深的叶子节点,那么查找之后树深会减小。但是虽然有这么一个小问题,但是对我们实际使用的影响不大。一个是因为这种情况发生的概率并不大,另一个是即使发生了也不会带来很糟糕的后果,单次合并顺序不对,至多只会让树上小部分的节点的树深有常数级别的偏差。
除此之外,还有一些其他的优化方法,比如根据树的节点数来作为合并的依据。每次将节点少的树合并进节点数多的树当中,我个人觉得这个更不靠谱,因为节点越多的树并不一定树深越大,很有可能树深更小。所以总体来说一般我们还是习惯使用树深作为依据。
并查集这个算法非常经典,它并不难理解,代码量也很少,效率也高,学习曲线也很平滑,可以说除了使用场景比较窄之外几乎没有缺点。毕竟世上没有完美无缺的算法,这也是算法的魅力所在吧。
希望大家都能有所收获,原创不易,厚颜求个关注~
标签: #并查集算法视频