Quelles sont les différences entre les algorithmes de détection communautaire dans igraph?
J'ai une liste d'environ 100 objets igraph avec un objet typique ayant environ 700 sommets et 3500 bords.
Je voudrais identifier des groupes de sommets au sein desquels les liens sont plus probables. Mon plan est ensuite d'utiliser un modèle mixte pour prédire combien de sommets de liens intra-groupe ont en utilisant des attributs de sommet et de groupe.
Certaines personnes voudront peut-être répondre à d'autres aspects de mon projet, ce qui serait formidable, mais ce qui m'intéresse le plus, ce sont les informations sur les fonctions en igraph pour regrouper les sommets. J'ai rencontré ces algorithmes de détection communautaire mais je ne suis pas sûr de leurs avantages et inconvénients, ou si une autre fonction serait meilleure pour mon cas. J'ai également vu les liens ici , mais ils ne sont pas spécifiques à igraph. Merci pour vos conseils.
Voici un bref résumé des algorithmes de détection de communauté actuellement implémentés dans igraph:
Edge.betweenness.communityest un processus de décomposition hiérarchique dans lequel les bords sont supprimés dans l'ordre décroissant de leurs scores d'interdépendance des bords (c'est-à-dire le nombre de chemins les plus courts qui traversent un bord donné). Cela est motivé par le fait que les bords reliant différents groupes sont plus susceptibles d'être contenus dans plusieurs chemins les plus courts simplement parce que dans de nombreux cas, ils sont la seule option pour passer d'un groupe à un autre. Cette méthode donne de bons résultats mais est très lente en raison de la complexité de calcul des calculs d'interdité des bords et parce que les scores d'interdépendance doivent être recalculés après chaque suppression des bords. Vos graphiques avec ~ 700 sommets et ~ 3500 arêtes sont autour de la limite de taille supérieure des graphiques qui peuvent être analysés avec cette approche. Un autre inconvénient est queEdge.betweenness.communityconstruit un dendrogramme complet et ne vous donne aucune indication sur l'endroit où couper le dendrogramme pour obtenir les groupes finaux, vous devrez donc utiliser une autre mesure pour en décider (par exemple, le score de modularité des partitions à chaque niveau du dendrogramme).fastgreedy.communityest une autre approche hiérarchique, mais elle est ascendante plutôt que descendante. Il essaie d'optimiser une fonction de qualité appelée modularité de manière gourmande. Initialement, chaque sommet appartient à une communauté distincte, et les communautés sont fusionnées de manière itérative de sorte que chaque fusion est localement optimale (c'est-à-dire qu'elle génère la plus grande augmentation de la valeur actuelle de la modularité). L'algorithme s'arrête lorsqu'il n'est plus possible d'augmenter la modularité, il vous donne donc un regroupement ainsi qu'un dendrogramme. La méthode est rapide et c'est la méthode qui est généralement essayée en première approximation car elle n'a pas de paramètres à régler. Cependant, il est connu de souffrir d'une limite de résolution, c'est-à-dire que les communautés en dessous d'un seuil de taille donné (en fonction du nombre de nœuds et de bords si je me souviens bien) seront toujours fusionnées avec les communautés voisines.walktrap.communityest une approche basée sur des marches aléatoires. L'idée générale est que si vous effectuez des promenades aléatoires sur le graphique, les promenades sont plus susceptibles de rester dans la même communauté car il n'y a que quelques bords qui mènent à l'extérieur d'une communauté donnée. Walktrap exécute de courtes promenades aléatoires de 3-4-5 étapes (en fonction de l'un de ses paramètres) et utilise les résultats de ces promenades aléatoires pour fusionner des communautés distinctes de manière ascendante commefastgreedy.community. Encore une fois, vous pouvez utiliser le score de modularité pour sélectionner où couper le dendrogramme. C'est un peu plus lent que l'approche gourmande rapide mais aussi un peu plus précis (selon la publication originale).spinglass.communityest une approche de la physique statistique, basée sur le modèle dit de Potts. Dans ce modèle, chaque particule (c.-à-d. Sommet) peut être dans l'un des états de spin c, et les interactions entre les particules (c.-à-d. Les bords du graphique) spécifient les paires de sommets qui préfèrent rester dans le même état de spin et lesquels préfèrent avoir des états de spin différents. Le modèle est ensuite simulé pour un nombre donné d'étapes, et les états de spin des particules définissent finalement les communautés. Les conséquences sont les suivantes: 1) Il n'y aura jamais plus de c communautés à la fin, bien que vous puissiez définir c à 200, ce qui est susceptible d'être assez pour vos besoins. 2) Il peut y avoir moins de c communautés à la fin car certains des états de rotation peuvent devenir vides. 3) Il n'est pas garanti que les nœuds dans des parties complètement éloignées (ou déconnectées) des réseaux aient des états de spin différents. Cela est plus susceptible d'être un problème pour les graphiques déconnectés uniquement, donc je ne m'inquiéterais pas à ce sujet. La méthode n'est pas particulièrement rapide et non déterministe (en raison de la simulation elle-même), mais possède un paramètre de résolution réglable qui détermine les tailles de cluster. Une variante de la méthode du spinglass peut également prendre en compte les liens négatifs (c'est-à-dire les liens dont les points d'extrémité préfèrent être dans différentes communautés).leading.eigenvector.communityest une approche hiérarchique descendante qui optimise à nouveau la fonction de modularité. À chaque étape, le graphique est divisé en deux parties de manière à ce que la séparation elle-même entraîne une augmentation significative de la modularité. Le fractionnement est déterminé en évaluant le vecteur propre de tête de la matrice dite de modularité, et il existe également une condition d'arrêt qui empêche les groupes étroitement connectés d'être encore divisés. En raison des calculs de vecteurs propres impliqués, il peut ne pas fonctionner sur des graphiques dégénérés où le solveur de vecteurs propres ARPACK est instable. Sur les graphiques non dégénérés, il est susceptible de donner un score de modularité plus élevé que la méthode rapide et gourmande, bien qu'elle soit un peu plus lente.label.propagation.communityest une approche simple dans laquelle chaque nœud se voit attribuer l'une des étiquettes k. Le procédé procède ensuite de manière itérative et réattribue des étiquettes aux nœuds de manière à ce que chaque nœud prenne l'étiquette la plus fréquente de ses voisins de manière synchrone. La méthode s'arrête lorsque l'étiquette de chaque nœud est l'une des étiquettes les plus fréquentes de son voisinage. Il est très rapide mais donne des résultats différents en fonction de la configuration initiale (qui est décidée au hasard), par conséquent, il faut exécuter la méthode un grand nombre de fois (disons, 1000 fois pour un graphique), puis créer un étiquetage de consensus, qui pourrait être fastidieux.
l'igraphe 0.6 comprendra également l'algorithme de détection de la communauté Infomap à la pointe de la technologie, qui est basé sur des principes théoriques de l'information; il essaie de construire un groupement qui fournit la longueur de description la plus courte pour une marche aléatoire sur le graphique, où la longueur de description est mesurée par le nombre attendu de bits par sommet requis pour coder le chemin d'une marche aléatoire.
Quoi qu'il en soit, j'irais probablement avec fastgreedy.community ou walktrap.community comme première approximation, puis évaluer d'autres méthodes lorsqu'il s'avère que ces deux méthodes ne conviennent pas à un problème particulier pour une raison quelconque.
Un résumé des différents algorithmes de détection de communauté peut être trouvé ici: http://www.r-bloggers.com/summary-of-community-detection-algorithms-in-igraph-0-6/
Notamment, l'algorithme InfoMAP est un nouveau venu récent qui pourrait être utile (il prend également en charge les graphiques dirigés).