# graph:::length.communities (sometimes) produces the wrong length

**URL:** <https://igraph.discourse.group/t/graph-length-communities-sometimes-produces-the-wrong-length/1309>\
**Category:** Usage\
**Tags:** R\
**Created:** [25 July 2022 15:01 UTC](https://igraph.discourse.group/t/graph-length-communities-sometimes-produces-the-wrong-length/1309 "2022-07-25T15:01:33Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![KeesP](https://avatars.discourse-cdn.com/v4/letter/k/2bfe46/32.png) [@KeesP](https://igraph.discourse.group/u/KeesP)\
**Post date:** [25 July 2022 15:01 UTC](https://igraph.discourse.group/t/graph-length-communities-sometimes-produces-the-wrong-length/1309/1 "2022-07-25T15:01:33Z")

</div>

```auto
# as expected.
g <- make_full_bipartite_graph(4,4)
clu <- structure( list(membership = c(1, 1, 1, 1, 2, 2, 2, 2)
                , algorithm = "onto"), class = "communities")
length(clu)
clu[length(clu)]
[1] 2
$`2`
[1] 5 6 7 8

```

```auto
# not as expected when membership vector in cummunities is corrupted.
g <- make_full_bipartite_graph(4,4)
clu <- structure( list(membership = c(1, 1, 1, 1, 4, 4, 4, 4)
                , algorithm = "outside (1,2)"), class = "communities")
length(clu)
[1] 4

```

This can harm applications that depend on ‘[[’, e.g. plot.

```auto
clu[[length(clu)]]
Error in groups(x)[[i]] : subscript out of bounds.

```

---

<div class="post-metadata">

**Author:** ![tamas](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/tamas/32/1261_2.png) [@tamas](https://igraph.discourse.group/u/tamas)\
**Post date:** [28 July 2022 19:00 UTC](https://igraph.discourse.group/t/graph-length-communities-sometimes-produces-the-wrong-length/1309/2 "2022-07-28T19:00:31Z")

</div>

For the record: this is due to a bug in the C core, and it will be resolved automatically after introducing the fix in the C core:

```auto
> g <- make_empty_graph(1, directed=F)
> clu <- cluster_leiden(g)
> length(clu)
[1] 1
> clu$membership
[1] 1

```

---

<div class="post-metadata">

**Author:** ![KeesP](https://avatars.discourse-cdn.com/v4/letter/k/2bfe46/32.png) [@KeesP](https://igraph.discourse.group/u/KeesP)\
**Post date:** [29 July 2022 07:53 UTC](https://igraph.discourse.group/t/graph-length-communities-sometimes-produces-the-wrong-length/1309/3 "2022-07-29T07:53:58Z")

</div>

The point I would like to make: if the groups in the $membership vector are not numbered consecutively and starting at 1, then max($membership) is wrong. A safer alternative is length(unique()). But that’s a lot of overhead for an unlikely situation. Is that worth it?

---

<div class="post-metadata">

**Author:** ![tamas](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/tamas/32/1261_2.png) [@tamas](https://igraph.discourse.group/u/tamas)\
**Post date:** [29 July 2022 09:20 UTC](https://igraph.discourse.group/t/graph-length-communities-sometimes-produces-the-wrong-length/1309/4 "2022-07-29T09:20:04Z")

</div>

In theory, the C core of igraph will always return membership vectors where the communities are numbered consecutively and there are no empty communities. We have a function for that in the C core called [`igraph_reindex_membership()`](https://igraph.org/c/doc/igraph-Community.html#igraph_reindex_membership). I think that all community detection functions in the C core call this function in the end, and if not, that’s a bug in the C core and should be fixed there.

---

<div class="post-metadata">

**Author:** ![szhorvat](https://yyz2.discourse-cdn.com/free1/user_avatar/igraph.discourse.group/szhorvat/32/3_2.png) [@szhorvat](https://igraph.discourse.group/u/szhorvat)\
**Post date:** [29 July 2022 10:34 UTC](https://igraph.discourse.group/t/graph-length-communities-sometimes-produces-the-wrong-length/1309/5 "2022-07-29T10:34:31Z")

</div>

I added a test to the C core to verify that membership vectors use proper indexing when detecting communities in one particular random graph

> <https://github.com/igraph/igraph/commit/d4424be8560a405bd1e5193b2a3717ae3febb9c0>