igraph中的社区检测算法之间有什么区别?


83

我有大约100个igraph对象的列表,其中典型的对象具有大约700个顶点和3500条边。

我想确定更多可能存在联系的顶点组。然后,我的计划是使用混合模型来预测使用顶点和组属性的组内连接顶点数。

某些人可能想对我项目的其他方面做出回应,这可能很棒,但是我最感兴趣的是有关igraph中用于将顶点分组的函数的信息。我遇到过这些社区检测算法,但是我不确定它们的优缺点,或者不确定某些其他功能是否适合我的情况。我在这里也看到了链接,但它们并非特定于igraph。谢谢你的建议。

Answers:


190

以下是有关igraph中当前实现的社区检测算法的简短摘要:

  • edge.betweenness.community是一个层次分解过程,其中边缘以其边缘中间性得分(即通过给定边缘的最短路径数)的降序删除。这是由于以下事实:连接不同组的边更可能包含在多个最短路径中,这仅仅是因为在许多情况下它们是从一组移到另一组的唯一选择。该方法产生了很好的结果,但是非常慢,这是因为边缘中间性计算的计算复杂性以及每次去除边缘后都必须重新计算中间性得分。您的具有约700个顶点和约3500个边的图形都在图形的尺寸上限附近,可以使用这种方法进行分析。另一个缺点是edge.betweenness.community构建完整的树状图,并且不提供任何指导,说明从何处切割树状图以获取最终组,因此您必须使用其他措施来确定(例如,分区的模块化得分在树状图)。

  • fastgreedy.community是另一种分层方法,但它是自下而上而不是自上而下的。它试图以贪婪的方式优化称为模块化的质量函数。最初,每个顶点都属于一个单独的社区,并且社区被迭代合并,以使每个合并都是局部最优的(即,在模块化的当前值上产生最大的增长)。当无法再增加模块性时,算法将停止,因此可以为您提供分组以及树状图。该方法速度快,并且由于没有参数可调整,因此通常将其作为一阶近似方法进行尝试。但是,已知存在分辨率限制的问题,即低于给定大小阈值的社区(取决于节点和边的数量,如果我没有记错的话,取决于社区的数量)将始终与相邻社区合并。

  • walktrap.community是一种基于随机游走的方法。通常的想法是,如果您在图表上执行随机游走,则游走更有可能停留在同一社区内,因为只有少数几条边通向给定社区之外。Walktrap会进行3-4-5步的短时随机游走(取决于其参数之一),并使用这些随机游走的结果以自下而上的方式合​​并单独的社区,例如fastgreedy.community。同样,您可以使用模块化得分选择在哪里切割树状图。它比快速贪婪方法要慢一些,但也要准确一些(根据原始出版物)。

  • spinglass.community是统计物理学基于所谓的Potts模型的一种方法。在此模型中,每个粒子(即顶点)可以处于c个自旋状态中,并且粒子之间的相互作用(即图的边缘)指定哪些对顶点更愿意保持在相同的自旋状态,以及哪些对顶点保持相同的自旋状态宁愿具有不同的自旋状态。然后针对给定数量的步骤对模型进行仿真,并且最终粒子的自旋状态定义了群落。结果如下:1)尽管您可以将c设置为200,但最终不会超过c个社区,这可能足以满足您的目的。2)可能少于c最终,一些自旋状态可能会变空。3)不能保证网络的完全远程(或断开连接)部分中的节点具有不同的自旋状态。仅对于断开连接的图,这更有可能是一个问题,因此我不必担心。该方法不是特别快速且不确定(由于模拟本身),但是具有可调整的分辨率参数来确定群集大小。Spinglass方法的一种变体也可以考虑否定链接(即,其端点倾向于位于不同社区的链接)。

  • leading.eigenvector.community是一种自上而下的分层方法,可再次优化模块化功能。在每个步骤中,将图形分为两部分,以使分隔本身可以显着提高模块性。通过评估所谓的模块化矩阵的前导特征向量来确定拆分,并且还有一个停止条件,该条件阻止紧密连接的组进一步拆分。由于涉及本征向量计算,因此它可能不适用于ARPACK特征向量求解器不稳定的退化图。在非退化图上,它的模块性得分可能比快速贪婪方法更高,尽管它的速度要慢一些。

  • label.propagation.community这是一种简单的方法,其中为每个节点分配了k个标签之一。然后,该方法迭代进行,并以使每个节点以同步方式获取其邻居的最频繁标签的方式将标签重新分配给节点。当每个节点的标签是其附近最频繁的标签之一时,该方法将停止。它非常快,但是根据初始配置(随机决定)会产生不同的结果,因此应该多次运行该方法(例如,对图形进行1000次),然后建立共识标签,这可能是乏味。

igraph 0.6还包括基于信息理论原理的最新Infomap社区检测算法;它尝试建立一个分组,为图上的随机游走提供最短的描述长度,其中描述长由编码随机游走路径所需的每个顶点的预期位数来衡量。

无论如何,当我发现这两种方法由于某种原因不适合特定问题时,我可能会采用fastgreedy.communitywalktrap.community作为第一种近似方法,然后评估其他方法。


3
据我所知,这与非确定性算法是很常见的事情。但是,您应该小心,因为算法的一次运行中的社区i不一定与另一次运行中的社区i相匹配,因为社区ID没有语义。
塔玛斯

2
有一个新的:multilevel.community。介意将其添加到您的列表吗?(顺便说一句,答案很不错。谢谢!)
扎克

1
@Tamás您能解释一下multilevel.communityfastgreedy.community算法之间的区别吗?看来这两者非常相似。非常感谢。
Antoine

3
他们是不一样的; fastgreedy.community迭代地合并社区对,请始终选择对整体模块化有最大增长的社区。在中multilevel.community,社区未合并;取而代之的是,在社区之间移动节点,以便每个节点做出本地决策,以最大程度地提高自己对模块化评分贡献。当此过程陷入困境时(即,所有节点都没有更改其成员身份),则所有社区都折叠为单个节点,并且流程继续进行(这就是为什么它是多层的)。
塔玛斯

2
@Antoine:InfoMap算法具有一种很好且科学合理的方法来处理有向边。igraph中的实现不是最有效的(由于许可问题),但是它应该适用于较小的图。如果原来是太慢了,你可以尝试从算法的作者的代码mapequation.org

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.