August 2017 - graph-tool - archives.skewed.de

get_in_neighbours() and get_in_edges() output do not match
by yu.zheng.columbia＠gmail.com 24 Aug '17

24 Aug '17

I have a directed graph: <Graph object, directed, with 61560 vertices and 42858 edges, edges filtered by (<PropertyMap object with key type 'Edge' and value type 'bool', for Graph 0x11a5e9190, at 0x11a5e96d0>, False), vertices filtered by (<PropertyMap object with key type 'Vertex' and value type 'bool', for Graph 0x11a5e9190, at 0x11a5e9710>, False) at 0x11a5e9190> I would like to get all in neighbors of a vertex, using the following codes: for v in g.vertices(): print('') print("vertex id:") print(v) print('all out neighbors') print(g.get_out_neighbours(v)) print('all in neighbors') print(g.get_in_neighbours(v)) print('all in edges') print(g.get_in_edges(v)) raw_input() Here's the console output: vertex id: 0 all out neighbors [18099] all in neighbors [0] all in edges [[1 0 1]] Output from get_in_edges() suggests that the in neighbor should be vertex 1; but get_int_neighbours() suggests that the in neighbors is itself. I am not sure what's going wrong. Any help would be appreciated. Thanks a lot! -- View this message in context: http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com… Sent from the Main discussion list for the graph-tool project mailing list archive at Nabble.com.

4 4

real-valued correlates
by Valery Topinsky 24 Aug '17

24 Aug '17

Good day, In "Inferring the mesoscale structure of layered, edge-valued and time-varying networks" Ch.V you described the way how to find optimal discretisation of the real-valued correlates. I'm wondering is there an implementation of it in graph_tool ? Thank you, Valeriy

2 1

Are the Debian files version controlled anywhere?
by Nicholas Brown 23 Aug '17

23 Aug '17

That is are the likes of the debian/control debian/rules files for the graph-tool package versioned in git anywhere? Cheers, Nick

3 2

Cookbook model averaging question
by Valery Topinsky 09 Aug '17

09 Aug '17

Hello. I've got a question about the following example from cookbook https://graph-tool.skewed.de/static/doc/demos/inference/inference.html#id11 I work on my own network in exact same way, trying to perform sampling to estimate some metrics. But the results are in some way replicates the behaviour from the cookbook example: For both cases (simple and nested SBM) the marginal distributions for vertices most of the times has too many non-zero values for different clusters, hence the colouring is so fine granular. Only few (1-2) clusters obey some explicit dominant group membership. But the rest of clusters exhibit very distributed marginals. Do you have any explanation for this? In case of my network I also have only 1-3 groups of nodes with some explicit dominant group membership. And the rest of vertices has too many non-zero, almost uniformly distributed marginals. I was thinking that for the simple cookbook example it's not natural that some vertices has more than 10 non-zero marginal values. May be it's just the result of independent launches of mcmc algorithm and random nature of groups labelling? Or there is some intuition behind this high marginal variance in group membership? I launched several times the optimisation, and drew the results. Topologically the outputs were very close to each other, although colouring was always different except a few kind of "stable" vertices. Hence, I guess, the resulted marginals for them have the same properties. But labels are not informative it selves. May be there is some trick how to force some deterministic labelling policies to stabilise it ? Thank you Valery.

3 3

How to effectively get the nested blockmodel block memberships of each of the nodes in your graph
by lenail 05 Aug '17

05 Aug '17

Hello Graph Tool developers, I'm interested in the nested stochastic block model (nsbm). What interests me most is: when I fit the model, where did each of my nodes get clustered? The closest function I can find to this in the API by reading the docs is: nsbm.get_bs() which returns [PropertyArray([0, 0, 0, 0, 0, 0, 0, 0, 0, 0], dtype=int32), PropertyArray([1, 1, 2, 2, 3, 4, 5, 0, 6, 4, 7, 1, 1, 4, 0, 5, 0, 0, 8, 2, 6, 5, 6, 6, 2, 2, 3, 3, 1, 1, 0, 7, 5, 5, 7, 3, 3, 6, 3, 7, 9, 8, 0, 8, 6, 7, 7], dtype=int32), PropertyArray([ 0, 1, 1, 13, 4, 5, 6, 7, 8, 9, 10, 4, 11, 0, 12, 13, 10, 14, 15, 4, 16, 17, 18, 5, 19, 20, 21, 22, 23, 9, 16, 14, 7, 24, 25, 26, 9, 27, 28, 29, 30, 5, 35, 14, 23, 30, 11, 41, 31, 13, 32, 6, 25, 33, 8, 34, 0, 12, 4, 16, 32, 35, 0, 28, 36, 13, 30, 27, 36, 11, 19, 13, 26, 13, 36, 37, 23, 28, 32, 19, 25, 29, 5, 24, 20, 27, 25, 4, 17, 36, 22, 11, 15, 12, 14, 2, 5, 38, 9, 9, 24, 39, 29, 13, 34, 17, 8, 20, 9, 5, 23, 8, 9, 40, 40, 27, 31, 40, 41, 10, 3, 12, 25, 38, 20, 40, 9, 9, 25, 42, 10, 24, 43, 3, 37, 2, 17, 34, 35, 21, 38, 32, 26, 22, 28, 13, 17, 44, 45, 36, 42, 26, 17, 27, 24, 40, 39, 9, 13, 5, 43, 38, 35, 30, 13, 36, 13, 11, 14, 40, 40, 12, 3, 40, 38, 1, 40, 21, 42, 9, 10, 29, 43, 45, 40, 31, 46, 40, 31, 5, 42, 40, 14, 11, 38, 34, 31, 34, 40, 31, 31, 45, 10, 4], dtype=int32), PropertyArray([ 0, 1, 2, ..., 163, 98, 18], dtype=int32)] The solution I ended up using was: vertex_name = nsbm.g.vertex_properties['_graphml_vertex_id'] clustering = [(nsbm.g.vertex_index[v], vertex_name[v], nsbm.get_bs()[0][nsbm.g.vertex_index[v]]) for v in nsbm.g.vertices()] clustering = [(i, name, base_clustering, nsbm.get_bs()[1][level0]) for i, name, level0 in clustering] clustering = [(i, name, level0, level1, nsbm.get_bs()[2][level1]) for i, name, level0, level1 in clustering] clustering = [(i, name, level0, level1, level2, nsbm.get_bs()[3][level2]) for i, name, level0, level1, level2 in clustering] at which point I had my result. Is there a less verbose way of putting this? If not, this serves as a feature request to add such a method, maybe called "get_clabels" ? -- View this message in context: http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com… Sent from the Main discussion list for the graph-tool project mailing list archive at Nabble.com.

3 2