草庐IT

并查集 size 的优化

runoob 2023-04-06 原文

并查集 size 的优化

按照上一小节的思路，我们把如下图所示的并查集，进行 union(4,9) 操作。

合并操作后的结构为：

可以发现，这个结构的树的层相对较高，若此时元素数量增多，这样产生的消耗就会相对较大。解决这个问题其实很简单，在进行具体指向操作的时候先进行判断，把元素少的集合根节点指向元素多的根节点，能更高概率的生成一个层数比较低的树。

构造并查集的时候需要多一个参数，sz 数组，sz[i] 表示以 i 为根的集合中元素个数。

// 构造函数
public UnionFind3(int count){
    parent = new int[count];
    sz = new int[count];
    this.count = count;
    // 初始化, 每一个parent[i]指向自己, 表示每一个元素自己自成一个集合
    for( int i = 0 ; i < count ; i ++ ){
        parent[i] = i;
        sz[i] = 1;
    }
}

在进行合并操作时候，根据两个元素所在树的元素个数不同判断合并方向。

public void unionElements(int p, int q){
    int pRoot = find(p);
    int qRoot = find(q);
    if( pRoot == qRoot )
        return;
    if( sz[pRoot] < sz[qRoot] ){
        parent[pRoot] = qRoot;
        sz[qRoot] += sz[pRoot];
    }
    else{
        parent[qRoot] = pRoot;
        sz[pRoot] += sz[qRoot];
    }
}

优化后，合并结果如下，9 指向父节点 8。

Java 实例代码

源码包下载：Download

UnionFind3.java 文件代码：

package runoob.union;

/**
 * 并查集size的优化
 */
public class UnionFind3 {
    // parent[i]表示第一个元素所指向的父节点
    private int[] parent;
    // sz[i]表示以i为根的集合中元素个数
    private int[] sz;
    // 数据个数
    private int count;

    // 构造函数
    public UnionFind3(int count){
        parent = new int[count];
        sz = new int[count];
        this.count = count;
        // 初始化, 每一个parent[i]指向自己, 表示每一个元素自己自成一个集合
        for( int i = 0 ; i < count ; i ++ ){
            parent[i] = i;
            sz[i] = 1;
        }
    }

    // 查找过程, 查找元素p所对应的集合编号
    // O(h)复杂度, h为树的高度
    private int find(int p){
        assert( p >= 0 && p < count );
        // 不断去查询自己的父亲节点, 直到到达根节点
        // 根节点的特点: parent[p] == p
        while( p != parent[p] )
            p = parent[p];
        return p;
    }

    // 查看元素p和元素q是否所属一个集合
    // O(h)复杂度, h为树的高度
    public boolean isConnected( int p , int q ){
        return find(p) == find(q);
    }

    // 合并元素p和元素q所属的集合
    // O(h)复杂度, h为树的高度
    public void unionElements(int p, int q){
        int pRoot = find(p);
        int qRoot = find(q);
        if( pRoot == qRoot )
            return;
        // 根据两个元素所在树的元素个数不同判断合并方向
        // 将元素个数少的集合合并到元素个数多的集合上
        if( sz[pRoot] < sz[qRoot] ){
            parent[pRoot] = qRoot;
            sz[qRoot] += sz[pRoot];
        }
        else{
            parent[qRoot] = pRoot;
            sz[pRoot] += sz[qRoot];
        }
    }
}
size并查spanstylecolor【数据结构与算法

有关并查集 size 的优化的更多相关文章

  1. ruby - 在 Ruby 中，为什么 Array.new(size, object) 创建一个由对同一对象的多个引用组成的数组？ - 2

    如thisanswer中所述,Array.new(size,object)创建一个数组，其中size引用相同的object。hash=Hash.newa=Array.new(2,hash)a[0]['cat']='feline'a#=>[{"cat"=>"feline"},{"cat"=>"feline"}]a[1]['cat']='Felix'a#=>[{"cat"=>"Felix"},{"cat"=>"Felix"}]为什么Ruby会这样做，而不是对object进行dup或clone？ 最佳答案 因为那是thedocumenta

  2. Ruby 缺少常量表达式优化？ - 2

    我希望Ruby的解析器会进行这种微不足道的优化，但似乎并没有(谈到YARV实现，Ruby1.9.x、2.0.0):require'benchmark'deffib1a,b=0,1whileb由于这两种方法除了在第二种方法中使用预定义常量而不是常量表达式外是相同的，因此Ruby解释器似乎在每个循环中一次又一次地计算幂常数。是否有一些Material说明为什么Ruby根本不进行这种基本优化或只在某些特定情况下进行？ 最佳答案 很抱歉给出了另一个答案，但我不想删除或编辑我之前的答案，因为它下面有有趣的讨论。正如JörgWMittag所说，

  3. ruby-on-rails - 优化读取数据库和写入csv文件 - 2

    我正在尝试从数据库中读取大量单元格(超过100.000个)并将它们写入VPSUbuntu服务器上的csv文件。碰巧服务器没有足够的内存。我正在考虑一次读取5000行并将它们写入文件，然后再读取5000行，等等。我应该如何重构我当前的代码以使内存不会被完全消耗？这是我的代码:defwrite_rows(emails)File.open(file_path,"w+")do|f|f该函数由sidekiqworker调用:write_rows(user.emails)感谢您的帮助! 最佳答案 这里的问题是，当您调用emails.each时，

  4. 软约束、硬约束、Minimum Snap的轨迹优化方法 - 2

    文章目录前言约束硬约束的轨迹优化Corridor-BasedTrajectoryOptimizationBezierCurveOptimizationOtherOptions软约束的轨迹优化Distance-BasedTrajectoryOptimization优化方法前言可以看看我的这几篇Blog1，Blog2，Blog3。上次基于MinimumSnap的轨迹生成，有许多优点，比如：轨迹让机器人可以在某个时间点抵达某个航点。任何一个时刻，都能数学上求出期望的机器人的位置、速度、加速度、导数。MinimumSnap可以把问题转换为凸优化问题。缺点：MnimumSnap可以控制轨迹一定经过中间的

  5. ruby-on-rails - 负载测试期间 Unicorn CPU 使用率激增，优化方法 - 2

    我对为我的RubyonRails3.1.3应用优化我的Unicorn设置的方法很感兴趣。我目前正在高CPU超大实例上生成14个工作进程，因为我的应用程序在负载测试期间似乎受CPU限制。在模拟负载测试中，每秒大约20个请求重放请求，我的实例上的所有8个内核都达到峰值，盒子负载飙升至7-8个。每个unicorn实例使用大约56-60%的CPU。我很好奇可以通过哪些方式对其进行优化？我希望能够每秒将更多请求汇集到这种大小的实例上。内存和所有其他I/O一样完全正常。在我的测试过程中，CPU越来越低。 最佳答案 如果您受CPU限制，您希望使用

  6. 美团外卖搜索基于Elasticsearch的优化实践 - 2

    美团外卖搜索工程团队在Elasticsearch的优化实践中，基于Location-BasedService（LBS）业务场景对Elasticsearch的查询性能进行优化。该优化基于Run-LengthEncoding（RLE）设计了一款高效的倒排索引结构，使检索耗时（TP99）降低了84%。本文从问题分析、技术选型、优化方案等方面进行阐述，并给出最终灰度验证的结论。1.前言最近十年，Elasticsearch已经成为了最受欢迎的开源检索引擎，其作为离线数仓、近线检索、B端检索的经典基建，已沉淀了大量的实践案例及优化总结。然而在高并发、高可用、大数据量的C端场景，目前可参考的资料并不多。因此

  7. 关于yolov5训练时参数workers和batch-size的理解 - 2

    关于yolov5训练时参数workers和batch-size的理解yolov5训练命令workers和batch-size参数的理解两个参数的调优总结yolov5训练命令python.\train.py--datamy.yaml--workers8--batch-size32--epochs100yolov5的训练很简单，下载好仓库，装好依赖后，只需自定义一下data目录中的yaml文件就可以了。这里我使用自定义的my.yaml文件，里面就是定义数据集位置和训练种类数和名字。workers和batch-size参数的理解一般训练主要需要调整的参数是这两个：workers指数据装载时cpu所使

  8. 基于RTS超低延时直播优化强互动场景体验 - 2

    RTS在阿里云视频直播的基础上进行底层技术优化，通过集成阿里云播放器SDK，支持在千万级并发场景下节点间毫秒级延时直播的能力，弥补了传统直播存在3~6秒延时的问题，确保了超低延时、低卡顿、秒开流畅的直播观看体验。本文介绍了基于RTS超低延迟直播优化强互动场景体验的最佳实践方案，并以阿里云播放器Aliplayer为例，详细介绍RTS超低延迟拉流接入、自动降级、排障信息获取等逻辑的实现，助力企业打造互动直播行业的产品竞争力。适用场景该方案适用于对超低延迟直播有诉求的客户，尤其是业务中存在强互动场景直播的场景。强互动场景直播主要是指对主播和观众存在互动，或观众存在更高实时性观看、画面互动需求的情况，

  9. ruby - 无法使用 CONSTANT 优化字符串 - 2

    我目前正在研究Ruby2.1.1的改进，但遇到了一些奇怪的事情。我正在尝试改进String类并定义一个名为FOO的常量。沙箱.rbmoduleFoobarrefineStringdoFOO="BAR"deffoobar"foobar"endendendusingFoobarputs"".class::FOO#=>uninitializedconstantString::FOO(NameError)puts"".foobar#=>"foobar"这给了我未初始化的常量String::FOO(NameError)。但是我可以调用"".foobar这让我相信我在正确的范围内。奇怪的是，如果我

  10. ruby - 如何优化 ActiveRecord find_in_batches 查询？ - 2

    我正在使用Rails4.0.0和Ruby2.0.0。我的Post(如在博客文章中)模型与用户相关联，该用户具有用户的user_name、first_name、last_name的组合。我想迁移数据，以便通过外键(即用户ID)将帖子关联到用户。我在posts表中有大约1100万条记录。我在Linux服务器上使用rake任务运行以下代码来迁移数据。然而，我的任务一直被服务器“杀死”，大概是由于rake任务，特别是下面的代码，消耗了太多内存。我发现将batch_size降低到20并将sleep(10)增加到sleep(60)允许任务运行更长的时间，在不被杀死的情况下总共更新更多的记录，但需要

随机推荐