[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [igraph] clustering coefficients for bipartite networks

From: Simone Gabbriellini
Subject: Re: [igraph] clustering coefficients for bipartite networks
Date: Sat, 26 Feb 2011 11:24:04 +0100

Dear Jordi,
dear Tamas,

this is really a very good new!!!

my implementation was a rough translation of R code, and because of the fact 
that I am not working with very huge networks, it was ok... but if Jordi's 
implementation is way faster, I am really happy to use it! thanks!

So, Tamas, I wish, as Jordi, that you and Gabor will consider to add bipartite 
analysis tools in the future igraph releases...

BTW, Jordi: there are other measures in Latapy... I have code for users' deg 
and degree of nei, but since my code proved to be slow... :) 
Do you have code also for, let's say, code for the correlation between users' 
deg with 2-dist-nei?


Il giorno 24/feb/2011, alle ore 20.12, jordi torrents ha scritto:

> Hi Tamás,
> 2011/2/24 Tamas Nepusz <address@hidden>:
>> One thing that seems to be different in your code and
>> in the authors' (but I haven't checked it thoroughly) is that when they
>> calculate the second-order neighbors of the original vertex, they
>> exclude the vertex itself while you don't. This means that your sums and
>> averages will include the vertex's "similarity" (cc_dot, cc_min, cc_max)
>> with itself, which is always going to be 1.
> Thank you very much for your help. This was the problem in my
> implementation. We must exclude the focal node from the second-order
> neighbors because, as you say, if we do not, the sums and averages
> will include the node pairwise CC with itself (which will always be
> 1). This error was especially problematic in the case of top (or
> bottom) nodes that are only connected to bottom (or top) nodes (eg an
> author that has only published solo authored papers in arXiv), because
> their CC must be 0, but with my original implementation it would be 1.
> Thus biasing a lot the CC computation upwards.
> I've rerun the test with the modifications that you've proposed (see
> script attached) and now it yields the same results that the authors
> report in the paper. I've also tested the new implementation in other
> networks and the results are much more plausible. So I'm willing to
> accept that the implementation is correct. The output of the script
> attached is:
> =============================================================
> address@hidden:~$ python test_bip_cc_correct.py
> Code based on the paper:
> Matthieu Latapy, Clémence Magnien and Nathalie Del Vecchio.
> Basic Notions for the Analysis of Large Two-mode Networks.
> Social Networks 30 (1), p. 31-48, 2008
> Loading coauthorship network from the paper. You can download it from:
> http://www.milnou.net/~jtorrents/bipartite_cc/coauthoring_latapy_2mode.graphml
> The authors report the results in Table 3 p. 41
> cc_dot_top = 0.29; cc_dot_bottom= 0.31
> cc_min_top = 0.56; cc_min_bottom= 0.73
> cc_max_top = 0.36; cc_max_bottom= 0.33
> Testing implementation of cc_dot:
> cc_dot_top = 0.29; cc_dot_bottom= 0.31; time spend = 2 seconds
> Testing implementation of cc_min:
> cc_min_top = 0.56; cc_min_bottom= 0.73; time spend = 2 seconds
> Testing implementation of cc_max:
> cc_max_top = 0.36; cc_max_bottom= 0.33; time spend = 2 seconds
> The results now do match!
> Thanks for your help Tamás ;)
> ==================================================================
> Salut!
> PS: Would you (and Gabor) consider to add bipartite clustering
> coefficients to igraph 0.6? That would be very useful for me because
> many of the networks that I have to deal with are bipartite. And, as
> Latapy et al (2008) convincingly show, we do loss a lot of interesting
> information if we use the usual procedure of only analyze one mode
> projections.
> <test_bip_cc_correct.py>_______________________________________________
> igraph-help mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/igraph-help

reply via email to

[Prev in Thread] Current Thread [Next in Thread]