Greedy modularity optimization community detection algorithm #314
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #314 +/- ##
==========================================
- Coverage 97.26% 96.72% -0.54%
==========================================
Files 115 113 -2
Lines 6795 6201 -594
==========================================
- Hits 6609 5998 -611
- Misses 186 203 +17 ☔ View full report in Codecov by Sentry. |
|
Try a weighted version and for every number that is not an integer, use the |
| m = sum(w[src(e), dst(e)] for e in edges(g)) * 2 | ||
| n_groups = maximum(c) | ||
| a = zeros(modularity_type, n_groups) | ||
| e = zeros(modularity_type, n_groups, n_groups) |
There was a problem hiding this comment.
Could we try a dict or sparse matrix here?
| return rewrite_class_ids(cs[imax]) | ||
| end | ||
|
|
||
| function modularity_greedy_step!( |
There was a problem hiding this comment.
Test that this loop does not allocate
| n = nv(g) | ||
| dq_max::typeof(Q) = typemin(Q) | ||
| to_merge::Tuple{Int,Int} = (0, 0) | ||
| for edge in edges(g) |
There was a problem hiding this comment.
investigate the case of self-loops
There was a problem hiding this comment.
Self-loops indeed appear in modularity computation (in a correct way)
They do participate in modularity optimization step and they can also impact which merge is optimal. Yet we never merge a cluster with itself as we check that ends of an edge belong to different clusters at traversal stage.
add fast algo of Clauset and Newman with dense storage of potential modularity increase
Greedy modularity optimization algorithm as per paper of Newman