关于算法:UnionFind算法详解

34次阅读

共计 4486 个字符,预计需要花费 12 分钟才能阅读完成。

———–

明天讲讲 Union-Find 算法,也就是常说的并查集算法,次要是解决图论中「动静连通性」问题的。名词很高端,其实特地好了解,等会解释,另外这个算法的利用都十分乏味。

说起这个 Union-Find,应该算是我的「启蒙算法」了,因为《算法 4》的结尾就介绍了这款算法,可是把我秀翻了,感觉好精妙啊!起初刷了 LeetCode,并查集相干的算法题目都十分有意思,而且《算法 4》给的解法居然还能够进一步优化,只有加一个渺小的批改就能够把工夫复杂度降到 O(1)。

废话不多说,间接上干货,先解释一下什么叫动静连通性吧。

一、问题介绍

简略说,动静连通性其实能够形象成给一幅图连线。比方上面这幅图,总共有 10 个节点,他们互不相连,别离用 0~9 标记:

当初咱们的 Union-Find 算法次要须要实现这两个 API:

class UF {
    /* 将 p 和 q 连贯 */
    public void union(int p, int q);
    /* 判断 p 和 q 是否连通 */
    public boolean connected(int p, int q);
    /* 返回图中有多少个连通重量 */
    public int count();}

这里所说的「连通」是一种等价关系,也就是说具备如下三个性质:

1、自反性:节点 pp是连通的。

2、对称性:如果节点 pq连通,那么 qp也连通。

3、传递性:如果节点 pq连通,qr 连通,那么 pr也连通。

比如说之前那幅图,0~9 任意两个 不同 的点都不连通,调用 connected 都会返回 false,连通重量为 10 个。

如果当初调用union(0, 1),那么 0 和 1 被连通,连通重量降为 9 个。

再调用 union(1, 2),这时 0,1,2 都被连通,调用connected(0, 2) 也会返回 true,连通重量变为 8 个。

判断这种「等价关系」十分实用,比如说编译器判断同一个变量的不同援用,比方社交网络中的朋友圈计算等等。

这样,你应该大略明确什么是动静连通性了,Union-Find 算法的要害就在于 unionconnected函数的效率。那么用什么模型来示意这幅图的连通状态呢?用什么数据结构来实现代码呢?

二、基本思路

留神我方才把「模型」和具体的「数据结构」离开说,这么做是有起因的。因为咱们应用森林(若干棵树)来示意图的动静连通性,用数组来具体实现这个森林。

怎么用森林来示意连通性呢?咱们设定树的每个节点有一个指针指向其父节点,如果是根节点的话,这个指针指向本人。比如说方才那幅 10 个节点的图,一开始的时候没有互相连通,就是这样:

class UF {
    // 记录连通重量
    private int count;
    // 节点 x 的节点是 parent[x]
    private int[] parent;

    /* 构造函数,n 为图的节点总数 */
    public UF(int n) {
        // 一开始互不连通
        this.count = n;
        // 父节点指针初始指向本人
        parent = new int[n];
        for (int i = 0; i < n; i++)
            parent[i] = i;
    }

    /* 其余函数 */
}

如果某两个节点被连通,则让其中的(任意)一个节点的根节点接到另一个节点的根节点上

public void union(int p, int q) {int rootP = find(p);
    int rootQ = find(q);
    if (rootP == rootQ)
        return;
    // 将两棵树合并为一棵
    parent[rootP] = rootQ;
    // parent[rootQ] = rootP 也一样
    count--; // 两个重量合二为一
}

/* 返回某个节点 x 的根节点 */
private int find(int x) {// 根节点的 parent[x] == x
    while (parent[x] != x)
        x = parent[x];
    return x;
}

/* 返回以后的连通重量个数 */
public int count() {return count;}

这样,如果节点 pq连通的话,它们肯定领有雷同的根节点

public boolean connected(int p, int q) {int rootP = find(p);
    int rootQ = find(q);
    return rootP == rootQ;
}

至此,Union-Find 算法就根本实现了。是不是很神奇?居然能够这样应用数组来模拟出一个森林,如此奇妙的解决这个比较复杂的问题!

那么这个算法的复杂度是多少呢?咱们发现,次要 APIconnectedunion 中的复杂度都是 find 函数造成的,所以说它们的复杂度和 find 一样。

find次要性能就是从某个节点向上遍历到树根,其工夫复杂度就是树的高度。咱们可能习惯性地认为树的高度就是 logN,但这并不一定。logN 的高度只存在于均衡二叉树,对于个别的树可能呈现极其不均衡的状况,使得「树」简直进化成「链表」,树的高度最坏状况下可能变成N

所以说下面这种解法,find,union,connected的工夫复杂度都是 O(N)。这个复杂度很不现实的,你想图论解决的都是诸如社交网络这样数据规模微小的问题,对于 unionconnected的调用十分频繁,每次调用须要线性工夫齐全不可忍耐。

问题的关键在于,如何想方法防止树的不均衡呢?只须要略施小计即可。

三、平衡性优化

咱们要晓得哪种状况下可能呈现不均衡景象,关键在于 union 过程:

public void union(int p, int q) {int rootP = find(p);
    int rootQ = find(q);
    if (rootP == rootQ)
        return;
    // 将两棵树合并为一棵
    parent[rootP] = rootQ;
    // parent[rootQ] = rootP 也能够
    count--; 

咱们一开始就是简略粗犷的把 p 所在的树接到 q 所在的树的根节点上面,那么这里就可能呈现「头重脚轻」的不均衡情况,比方上面这种场面:

长此以往,树可能成长得很不均衡。咱们其实是心愿,小一些的树接到大一些的树上面,这样就能防止头重脚轻,更均衡一些 。解决办法是额定应用一个size 数组,记录每棵树蕴含的节点数,咱们无妨称为「分量」:

class UF {
    private int count;
    private int[] parent;
    // 新增一个数组记录树的“分量”private int[] size;

    public UF(int n) {
        this.count = n;
        parent = new int[n];
        // 最后每棵树只有一个节点
        // 分量应该初始化 1
        size = new int[n];
        for (int i = 0; i < n; i++) {parent[i] = i;
            size[i] = 1;
        }
    }
    /* 其余函数 */
}

比如说 size[3] = 5 示意,以节点 3 为根的那棵树,总共有 5 个节点。这样咱们能够批改一下 union 办法:

public void union(int p, int q) {int rootP = find(p);
    int rootQ = find(q);
    if (rootP == rootQ)
        return;
    
    // 小树接到大树上面,较均衡
    if (size[rootP] > size[rootQ]) {parent[rootQ] = rootP;
        size[rootP] += size[rootQ];
    } else {parent[rootP] = rootQ;
        size[rootQ] += size[rootP];
    }
    count--;
}

这样,通过比拟树的分量,就能够保障树的成长绝对均衡,树的高度大抵在 logN 这个数量级,极大晋升执行效率。

此时,find,union,connected的工夫复杂度都降落为 O(logN),即使数据规模上亿,所需工夫也非常少。

四、门路压缩

这步优化特地简略,所以十分奇妙。咱们能不能进一步压缩每棵树的高度,使树高始终保持为常数?

这样 find 就能以 O(1) 的工夫找到某一节点的根节点,相应的,connectedunion 复杂度都降落为 O(1)。

要做到这一点,非常简单,只须要在 find 中加一行代码:

private int find(int x) {while (parent[x] != x) {
        // 进行门路压缩
        parent[x] = parent[parent[x]];
        x = parent[x];
    }
    return x;
}

这个操作有点匪夷所思,看个 GIF 就明确它的作用了(为清晰起见,这棵树比拟极其):

可见,调用 find 函数每次向树根遍历的同时,棘手将树高缩短了,最终所有树高都不会超过 3(union的时候树高可能达到 3)。

PS:读者可能会问,这个 GIF 图的 find 过程实现之后,树高恰好等于 3 了,然而如果更高的树,压缩后高度仍然会大于 3 呀?不能这么想。这个 GIF 的情景是我编出来不便大家了解门路压缩的,然而理论中,每次 find 都会进行门路压缩,所以树原本就不可能增长到这么高,你的这种放心应该是多余的。

五、最初总结

咱们先来看一下残缺代码:

class UF {
    // 连通重量个数
    private int count;
    // 存储一棵树
    private int[] parent;
    // 记录树的“分量”private int[] size;

    public UF(int n) {
        this.count = n;
        parent = new int[n];
        size = new int[n];
        for (int i = 0; i < n; i++) {parent[i] = i;
            size[i] = 1;
        }
    }
    
    public void union(int p, int q) {int rootP = find(p);
        int rootQ = find(q);
        if (rootP == rootQ)
            return;
        
        // 小树接到大树上面,较均衡
        if (size[rootP] > size[rootQ]) {parent[rootQ] = rootP;
            size[rootP] += size[rootQ];
        } else {parent[rootP] = rootQ;
            size[rootQ] += size[rootP];
        }
        count--;
    }

    public boolean connected(int p, int q) {int rootP = find(p);
        int rootQ = find(q);
        return rootP == rootQ;
    }

    private int find(int x) {while (parent[x] != x) {
            // 进行门路压缩
            parent[x] = parent[parent[x]];
            x = parent[x];
        }
        return x;
    }

    public int count() {return count;}
}

Union-Find 算法的复杂度能够这样剖析:构造函数初始化数据结构须要 O(N) 的工夫和空间复杂度;连通两个节点 union、判断两个节点的连通性connected、计算连通重量count 所需的工夫复杂度均为 O(1)。

当初解决这道朋友圈问题就很简略了:

    public int findCircleNum(int[][] M) {
        int n = M.length;
        UF uf = new UF(n);
        for (int i = 0; i < n; i++) {for (int j = 0; j < i; j++) {if (M[i][j] == 1)
                    uf.union(i, j);
            }
        }
        
        return uf.count();}

接下文:Union-Find 算法利用

正文完
 0