You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To conform with the rest of the networkx API, closeness_centrality should use the weight parameter to specify which edge attribute should be use to calculate the shortest path length, it shouldn't use distance.
I believe we did it that way on purpose since in this case higher-weight (longer distance) leads to lower centrality and we thought it would be less confusing. In some cases you might e.g. want something like distance = 1/weight.
I believe we did it that way on purpose since in this case higher-weight (longer distance) leads to lower centrality and we thought it would be less confusing. In some cases you might e.g. want something like distance = 1/weight.
Hagberg, one question. Isn't this the exact case for betweeness centrality? However, in that case the name of the parameter is "weight" and not "distance". Or maybe I am not understanding correctly. Is it the case that in both cases (betweeness and closeness) the weights capture distances (something that one wants to minimize), or this is the case only for closeness?
So exciting that someone meets the same question with me! How do you deal with the betweeness centrality now? Can we just use 1/weight=distance or just use weight directly? I prefer the first one that is consistent with closeness centrality.
To conform with the rest of the networkx API, closeness_centrality should use the weight parameter to specify which edge attribute should be use to calculate the shortest path length, it shouldn't use distance.
http://networkx.github.com/documentation/latest/reference/generated/networkx.algorithms.centrality.closeness_centrality.html?highlight=closeness_centrality#networkx.algorithms.centrality.closeness_centrality
The text was updated successfully, but these errors were encountered: