I want to calculate closeness centrality on a disconnected graph. closeness function in igraph in r is not well-defined for disconnected graphs since the closeness of a vertex is defined as the inverse of the average distance to all other vertices, and so if there are two vertices that have no path between them, closeness measures of these vertices can not be computed properly. To somehow cure this issue, estimate_closeness function in igraph is suggested, it works for disconnected graphs by specifying cutoffparameter as being greater than zero.
However, when I try to run V(network)$closeness <- estimate_closeness(network, mode = "all", cutoff > 0), it gives the following error:
Error in as.igraph.vs(graph, vids) : object 'cutoff' not found
How can I solve this issue?
Related
How is decay centrality defined for a bipartite graph? I am unable to find a clear definition. All I got is https://www.centiserver.org/centrality/Decay_Centrality/. Which wasn't really helpful.
Also, is there some nice implementation of decay centrality for graphs in python? Because I managed to find only networkx (https://networkx.org/documentation/stable/index.html) and it does not have decay centrality. Though it does have all the other centrality measures like degree, closeness, betweenness, eigenvector centrality.
The definition of decay centrality given on the website you linked should work for bipartite and nonbipartite graphs alike.
Here’s how decay centrality is computed. Given a node v whose centrality you’re interested in, your first step is to pick a parameter δ between 0 and 1. The closer δ is to zero, the more emphasis you’ll place on nodes close to v. The closer δ is to 1, the more emphasis you place on nodes further from v.
Next, compute the distance from v to each other node x in the graph. (I’m not specifically familiar with networkx, but this should be easy to compute via breadth-first search if the graph doesn’t have edge weights, Dijkstra’s algorithm if the graph has edge weights and they’re nonnegative, or the Bellman-Ford algorithm if the graph has edge weights which can be negative.) Notationally, let’s have d(v, x) denote the distance from v to x that you computed.
Finally, for each node x other than v, compute δd(x, v), and add up all those values. That final number is the decay centrality for v.
I am trying to improve my understanding of eigenvector centrality. This overview from the University of Washington was very helpful, especially when read in conjunction with this R code. However, when I use evcent(graph_from_adjacency_matrix(A)), the result differs.
The below code
library(matrixcalc)
library(igraph)
# specify the adjacency matrix
A <- matrix(c(0,1,0,0,0,0,
1,0,1,0,0,0,
0,1,0,1,1,1,
0,0,1,0,1,0,
0,0,1,1,0,1,
0,0,1,0,1,0 ),6,6, byrow= TRUE)
EV <- eigen(A) # compute eigenvalues and eigenvectors
max(EV$values) # find the maximum eigenvalue
centrality <- data.frame(EV$vectors[,1])
names(centrality) <- "Centrality"
print(centrality)
B <- A + diag(6) # Add self loops
EVB <- eigen(B) # compute eigenvalues and eigenvectors
# they are the same as EV(A)
c <- matrix(c(2,3,5,3,4,3)) # Degree of each node + self loop
ck <- function(k){
n <- (k-2)
B_K <- B # B is the original adjacency matrix, w/ self-loops
for (i in 1:n){
B_K <- B_K%*%B #
#print(B_K)
}
c_k <- B_K%*%c
return(c_k)
}
# derive EV centrality as k -> infinity
# k = 100
ck(100)/frobenius.norm(ck(100)) # .09195198, .2487806, .58115487, .40478177, .51401731, .040478177
# Does igraph match?
evcent(graph_from_adjacency_matrix(A))$vector # No: 0.1582229 0.4280856 1.0000000 0.6965127 0.8844756 0.6965127
The rank correlation is the same, but it is still bothersome that the values are not the same. What is going on?
The result returned by igraph is not wrong, but note that there are subtleties to defining eigenvector centrality, and not all implementations handle self-loops in the same way.
Please see what I wrote here.
One way to define eigenvector centrality is simply as "the leading eigenvector of the adjacency matrix". But this is imprecise without specifying what the adjacency matrix is, especially what its diagonal elements should be when there are self-loops present. Depending on application, diagonal entries of the adjacency matrix of an undirected graph are sometimes defined as the number of self-loops, and sometimes as twice the number of self-loops. igraph uses the second definition when computing eigenvector centrality. This is the source of the difference you see.
A more intuitive definition of eigenvector centrality is that the centrality of each vertex is proportional to the sum of its neighbours centralities. Thus the details of the computation hinge on who the neighbours are. Consider a single vertex with a self-loop. It is its own neighbour, but how many times? We can traverse the self-loop in both directions, so it is reasonable to say that it is its own neighbour twice. Indeed, its degree is conventionally taken to be 2, not 1.
You will find that different software packages treat self-loops differently when computing the eigenvector centrality. In igraph, we made a choice by looking at the intuitive interpretation of eigenvector centrality rather than rigidly following a formal definition, with no regard for the motivation behind that definition.
Note: What I wrote about refers to how eigenvector centrality computations work internally, not to what as_adjacency_matrix() return. as_adjacency_matrix() adds one (not two) to the diagonal for each self-loop.
I am trying to calculate degree centrality, eigenvetor centrality and bonacich power centrality using igraph package in R. My data is South Korea's commuting data.
My data looks like this1st column: orientation region code, 2nd column: destination region code, 3rd column: commuting times between the two regions
I have made igraph graph using function graph_from_data_frame() like the picture below.
od18 is the data I used. The same one mentioned at the first picture.
But here are my problems.
I can't make an adjacency matrix using this graph.
: Error in get.adjacency.sparse(graph, type = type, attr = attr, edges = edges, :
Sparse matrices must be either numeric or logical,and the edge attribute is not
this is the code I executed.
this is the error.
Actually, I don't care about the adjacency matrix if centrality calculations don't have problems. But I am worrying what if this means that I am not going to get correct results of centrality calculations.
I tried to calculate the degree centrality using function degree() but the results values are all same.
All of my nodes have the same degree values as 250.
Any help about Bonacich power centrality using -beta.
Can you help me with these problems?
I'm not a pro programmer, but I've been learning on my own. I have a problem with betweenness centrality. I have an undirected weighted graph of 28 actors, in an adjacency matrix. When I run the code betweenness(PG_Network4, v = V(PG_Network4), directed = FALSE, nobigint = TRUE, normalized = TRUE) the results differs significantly than those I ran in UCINET, Pajek, Gephi (all of them are the same results). What is weird is that, if I do not load my network into R as "weighted" then the results are the same. And the differences are really considerable, for instance, in igraph, those nodes at the 2nd, 3rd, 4th (betweenness degree) in UCINET, Gephi or Pajek passes to the 6th, 10th, and 13th positions. What am I doing wrong here? I thought it was the weighted specification, but UCINET considers that, and still maintain the same results than Pajek and Gephi.
Thank you so much.
The issue you're having is caused by the weighted edges in the graph. UCINET and the other programs make use of it automatically, but in igraph you need to specifically define it in the betweenness function. Add edge weight to your graph: E(g)$weight <- sum(ecount(g)).
Then you can call it in the function betweenness(g, weights = E(g)$weight).
This should resolve your issue and get your values to match up with the other programs.
I want to calculate the average clustering coefficient of a graph (from igraph package). However, I am not sure which approach I should follow.
library(igraph)
graph <- erdos.renyi.game(10000, 10000, type = "gnm")
# Global clustering coefficient
transitivity(graph)
# Average clustering coefficient
transitivity(graph, type = "average")
# The same as above
mean(transitivity(graph, type = "local"), na.rm = TRUE)
I would be grateful for some guidance.
Using transitivity(graph) computes a global clustering coefficient (transitivity):
This is simply the ratio of the triangles and the connected triples in
the graph. For directed graph the direction of the edges is ignored.
Meanwhile, transitivity(graph, type = "average") being an average of transitivity(graph, type = "local") first computes the local clustering coefficients and then averages them:
The local transitivity of an undirected graph, this is calculated for
each vertex given in the vids argument. The local transitivity of a
vertex is the ratio of the triangles connected to the vertex and the
triples centered on the vertex. For directed graph the direction of
the edges is ignored.
See, e.g., ?transitivity and Clustering coefficient.
So firstly both of them are valid measures and the choice should depend on your purposes. The difference between them is quite clear (see the wikipedia page):
It is worth noting that this metric places more weight on the low
degree nodes, while the transitivity ratio places more weight on the
high degree nodes. In fact, a weighted average where each local
clustering score is weighted by k_i(k_i-1) is identical to the global clustering
coefficient
where k_i is the number of vertex i neighbours. Hence, perhaps using both of them would be quite fair too.
#Julius Vainora answered it. Additional note for those that are trying to look for some answers for what does type = "average" do since igraph documentation doesn't say anything about it:
transitivity(graph, type = "average")
is the same as
transitivity(graph, type = "localaverage")
is the same as
transitivity(graph, type = "localaverageundirected")
is the same as
mean(transitivity(graph, type = "local"), na.rm = TRUE)
transitivity(g, type="local")
How about the order of the output vector?
Is it same as the order of:
degree(g, mode="all")
The degree vector has indexs but clustering coefficient not