Difference in degree assortativity between Barabasi model in python-igraph and R igraph

[sztal]

Hi,

I hope this issue can be considered related to the python interface of igraph, sorry if not.

I found a weird inconsistency between behaviour of Barabasi preferential attachment model in python-igraph and R igraph with respect to degree assortativity. In python-igraph assortativity for graphs with m > 1 tends to be significantly negative, while in R it seems to converge assymptotically towards zero.

Perhaps in both cases assortativity converges to zero, but in python-igraph the rate of convergence is surely much slower.

Examples

# R
library(igraph)

g <- sample_pa(1000, m = 5, power = 1, algorithm = 'psumtree', directed = FALSE)
assortativity_degree(g, directed = FALSE)  # ~ -0.03
g <- sample_pa(100000, m = 5, power = 1, algorithm = 'psumtree', directed = FALSE)
assortativity_degree(g, directed = FALSE)  # ~ -0.00

# Python
import igraph as ig

g = ig.Graph.Barabasi(1000, m=5, power=1, implementation='psumtree', directed=False)
g.assortativity_degree(directed=False) # ~ -0.30
g = ig.Graph.Barabasi(100000, m=5, power=1, implementation='psumtree', directed=False)
g.assortativity_degree(directed=False) # ~ -0.13

[ntamas]

https://github.com/igraph/python-igraph/issues/26 could be related - does your result change if you add outpref=True in the Python code?

[sztal]

Indeed it does. Assortativity drops towards zero now.

But it should not matter for undirected networks, right?

[ntamas]

Well, it shouldn't, that's why #26 was filed in the first place. Internally, igraph does not build the Graph object until the very end of the generation process, it simply works with a flat edge list plus a partial-sum tree with degree counters. Before #26 was fixed, the degree counters were updated in a way that depended solely on the value of the outpref argument even if the graph was undirected.

The reason why you see a discrepancy between the Python interface and the R interface right now (years after #26 was fixed) is that the R interface always bundles the latest master revision of the igraph/igraph repository in itself (so it gets the latest version of the code in the C code even if there was no "official" release of the C core), while the Python interface downloads the latest official release on-the-fly. This could be rectified with a new release of the C core, or you could compile the Python interface from scratch with the master revision of the C core.

[sztal]

Ok, so #26 has not been included in the latest official igraph release yet?

[ntamas]

No, not yet - the latest release is version 0.7.1, dated around April 2014 or so :(

[sztal]

Ok, I see. But do you plan to release it in any foreseeable future?

[ntamas]

Well, the whole situation is like this. I am not doing research any more and I don't really have too much time that I could spend on the development of igraph or its Python interface any more. @vtraag has approached me yesterday in an email asking about the future of python-igraph, and he mentioned that he could try to gather a team that would help with the maintenance of python-igraph. If this succeeds and python-igraph gains traction again, then a new release will be the very first thing that we'll do.

[sztal]

Ok, thanks for help and info. As for this issue I think we may close it now. Thanks!