Send igraph-help mailing list submissions to
address@hiddenTo subscribe or unsubscribe via the World Wide Web, visit
https://lists.nongnu.org/mailman/listinfo/igraph-helpor, via email, send a message with subject or body 'help' to
address@hiddenYou can reach the person managing the list at
address@hiddenWhen replying, please edit your Subject line so it is more specific
than "Re: Contents of igraph-help digest..."
Today's Topics:
1. Neighbors & Degree not matching (Thomas)
2. Re: Neighbors & Degree not matching (Tam?s Nepusz)
3. Definition of Modularity (Zhige Xin)
4. Re: Different results from fastgreedy.community on different
systems (Franz)
5. Re: Definition of Modularity (Tamas Nepusz)
6. A single function to calculate clustering in bipartite
networks (Simone Gabbriellini)
----------------------------------------------------------------------
Message: 1
Date: Tue, 12 Feb 2013 09:05:26 +0000
From: Thomas <
address@hidden>
To: Help for igraph users <
address@hidden>
Subject: [igraph] Neighbors & Degree not matching
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
In the code/output below Node 153 has one neighbor (Node 156) but the
degree function returns 2. Does anyone know why this would happen? The
code for reading in g is included below and I took out loops so it
shouldn't be joined to itself.
> j <- 153
> neighbors(g,j)
[1] 156
> degree(g,j)
[1] 2
g <- read.graph("EL.txt",
format=c("edgelist"))
g <- simplify(g, remove.multiple = TRUE, remove.loops = TRUE)
g <- delete.vertices(g,which(degree(g) < 1)-1)
I'm using iGraph in R.
Thank you,
Thomas
------------------------------
Message: 2
Date: Tue, 12 Feb 2013 19:50:37 +0100
From: Tam?s Nepusz <
address@hidden>
To: Help for igraph users <
address@hidden>
Subject: Re: [igraph] Neighbors & Degree not matching
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=us-ascii
> In the code/output below Node 153 has one neighbor (Node 156) but the
degree function returns 2. Does anyone know why this would happen?
Your graph is directed and node 153 has an outgoing and an incoming edge. degree() returns the "undirected" degree by default, i.e. it counts both the incoming and the outgoing edges, while neighbors() returns the "outbound" neighbors. Use the mode= argument of neighbors() or degree() to change this behaviour; mode=... may be "in" for incoming edges only, "out" for outbound edges only and "all" for both.
--
T.
------------------------------
Message: 3
Date: Tue, 12 Feb 2013 12:04:37 -0800
From: Zhige Xin <
address@hidden>
To: Help for igraph users <
address@hidden>
Subject: [igraph] Definition of Modularity
Message-ID:
<CAGxEPm0DWTCJSk5S5uOq=OX=+=
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hi dear all,
I have a question about the definition of Modularity proposed by Mark
Newman in 2004. In his formula, for
any two nodes i and j in the same community in the network N, we sum the
following Aij - Ki*Kj/2m and divide
it by 2m, where Aij is the corresponding entry in the adjacency matrix of N
and Ki is the degree of node i and m
is the number of edges of N.
So my question is that why Ki*Kj/2m is "the probability of an edge existing
between vertices i and j if connections
are made at random but respecting vertex degrees". Of course, I understand
Ki*Kj is the all possible events for the
connection between i and j. Also, I checked the
wiki page for Modularity
which said this was based on Configuration
Model but I do not get why Expected [Full edges between *i* and *j*] =
(Full edges between *i* and *j*)/(Total number of rewirings possible)
and what rewiring means? Besides, the wired thing is that it seems that
Mark Newman did not include this Configuration Model
in his reference. So could someone explain this for me?
Thanks!
Isaiah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.nongnu.org/archive/html/igraph-help/attachments/20130212/6a1433ff/attachment.html>
------------------------------
Message: 4
Date: Wed, 13 Feb 2013 08:09:54 +0100
From: Franz <
address@hidden>
To: Help for igraph users <
address@hidden>
Subject: Re: [igraph] Different results from fastgreedy.community on
different systems
Message-ID:
<CAFZ=FRjKWyBTM5VRK0Vr1hcirPGSp0=4zT0+
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
HI Tam?s,
Thank you very much for your prompt and thorough answer.
I will take care to use the same PC on my work :)
All the bests
Franz
2013/2/11 Tam?s Nepusz <
address@hidden>
> > I am doing some research on networks and I find that
>
fastgreedy.community returns different results when run on different PC.
> fastgreedy.community is not fully deterministic because the original
> algorithm does not specify what should happen when more than one possible
> merge of communities would yield exactly the same increase in the
> modularity score. igraph chooses one of the possible merges quasi-randomly.
> "Quasi-randomly" means that there are no explicitly generated random
> numbers involved (the algorithm will always give the same result on the
> same machine), but it is unpredictable which of the possible merges igraph
> will perform. It is quite likely that in your case igraph chooses one of
> the possible merges on one machine and another one of the possible merges
> on another machine. Since the two merges are equivalent "locally" (they
> yield the same local increase in modularity) but not "globally" (one of
> them
leads to a more advantageous situation than the other), it can happen
> that the final result differs both in terms of the number of communities
> and in terms of the actual modularity score.
>
> To illustrate one possible source of randomness: igraph maintains a list
> of "neighboring communities" for each community and sorts the list by
> modularity gain in descending order. Sorting is done by the qsort function
> of the standard C library. Different qsort implementations may break ties
> in different ways; for instance, the man page of qsort on my machine says
> this:
>
> "The algorithms implemented by qsort(), qsort_r(), and heapsort() are not
> stable; that is, if two
> members compare as equal, their order in the sorted array is undefined."
>
> This can easily lead to the behaviour I described above.
>
> Best,
> Tamas
>
>
>
_______________________________________________
> igraph-help mailing list
>
address@hidden>
https://lists.nongnu.org/mailman/listinfo/igraph-help>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.nongnu.org/archive/html/igraph-help/attachments/20130213/5fbb7746/attachment.html>
------------------------------
Message: 5
Date: Wed, 13 Feb 2013 16:28:26 +0100
From: Tamas Nepusz <
address@hidden>
To:
address@hiddenSubject: Re: [igraph] Definition of Modularity
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
> So my question is that why Ki*Kj/2m is "the probability of an edge existing
> between vertices i and j if connections
>
> are made at random but respecting vertex degrees".
In the Molloy-Reed model (i.e. a random graph generation model that
"respects the vertex degrees"), edges are drawn as follows. Vertex i
initially has Ki "stubs". Edges are drawn by selecting two stubs from all
the stubs of all the vertices randomly and then connecting them. The total
number of stubs is of course 2m because we are going to have m edges in the
end and each edge connects two stubs. Now, since vertex i has Ki stubs,
the
probability of selecting the first stub from vertex i is Ki/2m, and the
probability of selecting the second stub from vertex j is Kj/2m. Thus, the
probability of drawing an edge between vertex i and vertex j in a single
step of the graph generation process is Ki/2m * Kj/2m. However, since we are
actually drawing m edges, and edges between i and j are the same as edges
between j and i, the probability of drawing an edge between vertex i to
vertex j is Ki/2m * Kj/2m * 2m, so we get Ki*Kj / 2m.
--
T.
------------------------------
Message: 6
Date: Wed, 13 Feb 2013 16:40:27 +0100
From: Simone Gabbriellini <
address@hidden>
To: igraph users Help for <
address@hidden>
Subject:
[igraph] A single function to calculate clustering in
bipartite networks
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="us-ascii"
Hello list,
Here:
http://igraph.wikidot.com/r-recipes#toc8there are three clustering measures, namely ccbip, cclowdot and cctopdot that calculates clustering coefficients in bipartite networks.
I am trying to simplify these three functions into a single one which calculates the three values only for a set of nodes, either the top or the bottom one.
Do you have any hints on how to proceed? One of the networks that I have to analyze is 50000 nodes and 130000 links, so speed would be an
asset.
Best,
Simone.
Sent from my iPhone. Please excuse brevity and odd typos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.nongnu.org/archive/html/igraph-help/attachments/20130213/517d995a/attachment.html>
------------------------------
_______________________________________________
igraph-help mailing list
address@hiddenhttps://lists.nongnu.org/mailman/listinfo/igraph-helpEnd of igraph-help Digest, Vol 79, Issue 12
*******************************************