[Networkit] Read simple edgelist

Jérôme Deschênes jeromedesch at gmail.com
Thu Oct 1 22:21:01 CEST 2015

Thank you for all your answers.

I computed some measures and now I want to export them.

The problem is that it seems like my nodes ids are being replaced by
sequantial node numbers by the NetworkIt readGraph process. Hence, I can
export my centrality measures by doing something (inefficient) like:
numpy.savetext("degreemeasure.txt", dc.ranking(), fmt="%s", delimiter=' ')

However, I get new ids that I cannot relate to the one in my target
dataset. In an ideal world would like to have all the measures in one
matrix or table that would look like this :

My_old_id, degree, eigen, between, close
...               ...           ...        ...              ...
I know how to append vectors or merge tables in Python but since I don't
have my old ids, I don't know where to start...

So, is there a way in Networkit to get back the old ids?

Sorry for my newbyness!


2015-09-30 5:14 GMT-04:00 Christian Staudt <christian.staudt at kit.edu>:

> On 28 Sep 2015, at 22:36, Maximilian Vogel <
> maximilian.vogel at student.kit.edu> wrote:
> So is there a good parallelized SNA program out there that I should
> consider for a good implementation of parallalized centrality measures?
> We once benchmarked most of our implementations and compared them with
> other frameworks, however I can't find them right now. Maybe, Christian has
> them somewhere. Either we are better or you'd get to know better
> frameworks... ;-)
> An early paper on NetworKit [2] contains some comparative benchmarks, but
> they are outdated by now: Several NetworKit kernels have become faster.
> When using ApproxBetweenness2 or ApproxCloseness (both sequential), you
> have to specify the number of samples and this directly relates to the
> running time. Unfortunately I don't know how many samples to choose to get
> "reasonable" results.
> What a “reasonable” approximation is is a good but tricky question. I
> think we can’t answer this independently of an application and an
> application-specific cost/benefit analysis. Here is what we know:
> - centrality.ApproxBetweenness (Riondato/Kornaropoulos) accepts a
> parameter epsilon such that the absolute values are at most epsilon off
> from the exact betweenness. The good thing is that you have this guarantee
> and you do not have to estimate the number of samples directly. The bad
> thing is that a) the benefit of an additive error bound on betweenness
> (which is a fraction) is debatable, and b) in order to hold this provable
> guarantee, the algorithm is somewhat less efficient than it could be.
> - centrality.ApproxBetweenness2 (Sanders/Geisberger) computes more
> efficiently, but you have to estimate the number of samples and you get no
> proven error bound. I recommend this as the default, because efficiency
> trumps additive error bound when doing exploratory analysis.
> - In experiments, we have seen that both algorithms preserve the ranking
> of nodes by betweenness quite well with few samples. The error is usually
> far lower than the given bound for ApproxBetweenness, and it is lower the
> higher the betweenness of a node [1].
> [1]:
> https://www.researchgate.net/publication/265967336_Approximating_Betweenness_Centrality_in_Large_Evolving_Networks
> [2]:
> https://www.researchgate.net/publication/260756093_NetworKit_An_Interactive_Tool_Suite_for_High-Performance_Network_Analysis
> Best,
> Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ira.uni-karlsruhe.de/mailman/private/networkit/attachments/20151001/5ca6acce/attachment.html>

More information about the NetworKit mailing list