你是代码调用的，可以断点看看 这里构造的初始图中点的数量，我又看了下算法逻辑没看到有缩减点数量。
是不是做join的时候内联了呀，不然感觉没理由啊
我要不把源码下下来每一次迭代都打印一遍点的数据量看问题出在谁那儿了
join都是左关联的，你用的数据是公共数据集吗，是的话可以发一下我试下。
大佬你等我下，我大概看了下源码，在关键地方都加了输出我先看下结果，代码逻辑是最终迭代的结果louvainG上保留的是有多少分组，对应的innerVertices里存这个分组里包括多少个点对吧，最终所有组的innerVertices累计的数量应该等于初始时候输入的点的数量，是这个逻辑没错吧
1 个赞
是的，2.5以后输出的就是把所有组的innerVertices展开后的结果
step1不会导致点的数量减少
刚执行完step1的时候，点的数量是正常的
这个weight是把全图所有边的权重都加在一起了，和论文里提到的“the weights of the links
between the new nodes are given by the sum of the weight of the links between nodes
in the corresponding two communities” 社区间权重有点差异， 你看下得到的社区是符合预期的吗
The second phase of the algorithm consists in building a new network whose nodes
are now the communities found during the first phase. To do so, --- the weights of the links
between the new nodes are given by the sum of the weight of the links between nodes
in the corresponding two communities [20].--- Links between nodes of the same community
lead to self-loops for this community in the new network.
得到的社区数比之前的要多好多，之前得到的社区数只有45个，现在得到了好几百万，但是我觉得之前的45也是有问题的诶，因为我拿这份数据跑过SparkGrpahx中的弱连通分量算法就是connectedComponents()这个，跑出来的结果也有几百万个分组。理论上讲连通分量算法划分出的组数应该是少于louvain算法划分出的组数的吧，两个完全不连通的点难道也能通过louvain算法划分到同一组内？如果从这个角度讲，我反而觉得现在这个角度是合理的
大佬你要不给个邮箱或者加个微信，我把脱敏后的数据发你
连通分量算法结果取决于设定的最大迭代次数，你设定的maxIter是多少？
数据可以发来anqi.wang@vesoft.com，感谢大佬提供数据
用的Spark中的connectedComponents()算法这个算法，没写参数，默认迭代20次
数据已发
20应该是一个已经收敛的次数，应该就是对应的最大连通分量
我用你的数据跑了几遍，去掉针对 相同社区号的过滤后得到的结果更合理，比联通分量多是合理的，论文中的描述看来要这么理解： 社区间的权重 包括了社区内部的权重和社区间的权重。
这么改完跑的慢了好多，大佬这是不是还得再搞搞优化？我改完慢到怀疑人生