若某个家族人员过于庞大,要判断两个是否是亲戚,确实还很不容易,现在给出某个亲戚关系图,求任意给出的两个人是否具有亲戚关系。
规定:x和y是亲戚,y和z是亲戚,那么x和z也是亲戚。如果x,y是亲戚,那么x的亲戚都是y的亲戚,y的亲戚也都是x的亲戚。
第一行:三个整数n,m,p,(n<=5000,m<=5000,p<=5000),分别表示有n个人,m个亲戚关系,询问p对亲戚关系。
以下m行:每行两个数Mi,Mj,1<=Mi,Mj<=N,表示Ai和Bi具有亲戚关系。
接下来p行:每行两个数Pi,Pj,询问Pi和Pj是否具有亲戚关系
输出格式
P行,每行一个'Yes'或'No'。表示第i个询问的答案为“具有”或“不具有”亲戚关系。
样例输入
6 5 3
1 2
1 5
3 4
5 2
1 3
1 4
2 3
5 6
样例输出
Yes
Yes
No
这应该是并查集的经典题目了。并查集是树型结构的,要查询任意两个元素是不是在同一个集合里,要查找这两个元素所在树的根节点,看看是不是同一个。
并查集的操作很简单,用father[i]表示第i个元素的父亲所在的位置,初始化的状态应该是father[i] = i;
之后我们得到了元素之间的关系,开始对集合树进行合并,特别是这一题。如果x和y是亲戚,那么x的亲戚都是y的亲戚,这说明要对两颗集合树进行合并。
合并很简单,便是把一方的根的父亲赋值为另一方的父亲: father[getRoot(y)] = getRoot(x);
查询的效率非常好。但是如果并查集的元素在合并的时候并不是把整个集合树进行合并,而是对单个元素进行从一颗集合树转移到另一颗
这样的费用很高,因为要把以其为父亲的子节点的父亲指向都转移了,才能对本身进行转移。这就要考虑为了使用并查集的查询效率,这些是否值得花费。
关于并查集,还有一点就是路径的压缩问题。我知道的有两个。
1.在进行查询的时候顺便改变树的结构。
2.在建树的时候,当两棵集合树要进行合并的时候,我们把深度小的树并在深度较大的另一棵树下面,这样得到的树的新树的深度最小
代码: