March 2019 - graph-tool - archives.skewed.de

How to control the orientation of the graph topology
by Xun Xiao 26 Feb '22

26 Feb '22

Hi Tiago, sometimes, when delete the graph and create a new one, then plot it, the plotted graph is shown upside down (in terms of the node text). So how could we control the orientation of the graph? Or which parameter we should use to always make node text shown in a correct orientation. 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.

3 5

Upside down labels
by charlie 26 Feb '22

26 Feb '22

Hi, I'm suffering from the same issue mentioned in this post: https://git.skewed.de/count0/graph-tool/issues/174 Namely, I'm trying to draw a graph that includes a lot of self-looping edges, and my labels are being printed upside down. If I remove the self-loops the labels are shown the right way up. Is there a fix for it? Thanks, Charlie -- 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 3

random graph
by JM 01 Sep '21

01 Sep '21

Dear Tiago, I have a directed graph of about half a million nodes and approximately a million edges following scale free behaviour and a power law degree distribution. To test some of my hypothesis, I would like to generate random smaller graphs (about 50 up to 200 nodes) representative of the big one. When I used a sample function that samples straight away from the real distribution of the big network, I have following problems: - I generate unconnected nodes with both 0 in AND out degree. - I generate small sub parts of a few nodes that are not connected to the main graph. - If only sampling from nodes with at least 1 degree, the generated graph is coherent, but not representative anymore as I need a big portion of nodes with either only one in or one out degree. Here is the part of my script I used for that, where samples are drawn from dictionaries of the degrees: def sample_in(): a=np.random.randint(num) k_in = in_degrees[a] return k_in def sample_out(): if sample_in()==0: b=np.random.randint(num_out) k_out=out_zero_zeros.values()[b] return k_out else: b=np.random.randint(num) k_out=out_degrees[b] return k_out N=200 g=gt.random_graph(N, lambda:(sample_in(), sample_out()), model="constrained-configuration", directed=True) I also tried sampling from a list of tuples as you have mentioned before in the forum, but I didn't receive any results, as the tuples randomly drawn from my list might not be combinable. degs=[(7,1),(4,3),(5,6),(2,4),(6,8),(2,0),(3,5),(0,3),(2,7),(2,1)] g = gt.random_graph(4, lambda i: degs[i], directed=True) - Is there any option I could active that would help me in those cases I described above? - Is there a better way how to create representative small networks? Any help on that issue will be much appreciated. Best wishes, Jana -- Sent from: http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/

3 5

What formula is used for std in vertex_average and edge_average?
by VaSa 16 Jul '20

16 Jul '20

I am curious what is being used to calculate the standard deviation of the average in gt.vertex_average and gt.edge_average >>> t2=gt.Graph() >>> t2.add_vertex(2) >>> t2.add_edge(t2.vertex(0), t2.vertex(1)) >>> gt.vertex_average(t2, "in") (0.5, 0.35355339059327373) Now, shouldn't std be σ(n)=sqrt(((0-0.5)^2+(1-0.5)^2)/2)=0.5 ? also q(n-1)=sqrt((0.5^2+0.5^2)/(2-1))~=0.70710 0.3535 is sqrt(2)/4 which happens to be σ(n-1)/2, so it seems there is some relation to that. A little bigger graph. >>> t3=gt.Graph() >>> t3.add_vertex(5) >>> t3.add_edge(t3.vertex(0), t3.vertex(1)) >>> gt.vertex_average(t3, "in") (0.2, 0.17888543819998318) Now, we should have 0,1,0,0,0 series for vertex incoming degree. So Windows calc gives σ(n)=0.4 and σ(n-1)~=0.44721, so where does 0.1788854 come from ? Reason, I am asking because, I have a large graph, where the average looks quite alright but the std makes no sense, as going by the histogram, degree values are quite a bit more distributed than the std would indicate. -- 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 3

assigning vertex properties when adding edges
by m jadidi 04 Mar '20

04 Mar '20

Hi, I was wondering if there is any way to assign vertex properties while adding edges to the graph. for example using "add_edge_list" I can assign edge properties but later I have to iterate through all vertices again to assign their properties. I know this is not a problem when the vertex property is of the type "int" or "float" because then one can use "vprop.a = values", but in case of "string" and "object" this method doesn't work What would be the best/fastest way to handle this situation. I guess it would be very helpful to extend the "add_edge_list" function to accept vertex property in some way. cheers, -- Mohsen

3 4

Nested Block State hierarchy level after mcmc_equilibrate
by ilyco 16 Jan '20

16 Jan '20

I ran mcmc_equilibrate on a nested block state model in a weighted graph. As per instructions, I copied the initially computed state in another object with increased hierarchy depth to 10. However, this fixed the depth to 10. Everything computed afterwards has depth 10 even if is clear that after 3 or 4 levels the nodes converge to one. There are many empty branches and when I try to plot it with empty_branches = False, I get an error stating it is not a tree. RuntimeError: Invalid hierarchical tree: No path from source to target. Did anybody perform any similar analyses? The hierarchy after mcmc_equilibrate: <NestedBlockState object, with base <BlockState object with 24 blocks (24 nonempty), degree-corrected, with 1 edge covariate, for graph <Graph object, undirected, with 230 vertices and 11230 edges, edges filtered by (<PropertyMap object with key type 'Edge' and value type 'bool', for Graph 0x7fc3a89f1210, at 0x7fc3a64911d0>, False), vertices filtered by (<PropertyMap object with key type 'Vertex' and value type 'bool', for Graph 0x7fc3a89f1210, at 0x7fc3a64912d0>, False) at 0x7fc3a89f1210>, at 0x7fc3a6491950>, and 10 levels of sizes [(230, 24), (24, 5), (5, 1), (1, 1), (1, 1), (1, 1), (1, 1), (1, 1), (1, 1), (1, 1)] at 0x7fc3a6491590> -- Sent from: http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/

4 4

Generate price networks with different constant factors
by Weitao Han 20 Mar '19

20 Mar '19

Dear all Function graph_tool.generation.price_network has a parameter named *constant factor.* According to graph-tool documents, for undirected graphs, the degree distribution of generated graph should be [image: image.png]. However, when I use different *constant factors *to generate different price network graphs, I notice that all graphs have a same degree distribution. It seems that different *constant factors *have no influence on the degree distributions. For example: g1 = gt.price_network(100000, m=3, directed=False) g2 = gt.price_network(100000, m=3, c=-0.9, directed=False) For g1, the degree distribution should be [image: image.png]. For g2, the degree distribution should be [image: image.png]. When I draw the degree distributions of the two graphs, they are almost the same. So, does the parameter *constant factor really *change the graph degree distribution? Regards, Weitao Han

1 0

Understanding the move proposals & the agglomerative initialization in fitting a SBM
by Tzu-Chi Yen 15 Mar '19

15 Mar '19

Hi Tiago, I am trying to understand the optional argument *d* in the graph_tool.inference.blockmodel.BlockState.mcmc_sweep() function. Reading from its documentation, it seems to me that *d* directly controls the probability to move to a new group, whereas the remaining move proposals take the probability of "εB/[e_t + εB]" (where we should use B instead of B+1). If I am understanding correctly, what is the proposal probability for its reverse move (of the forward move to an unoccupied group)? Does it only apply to the case where the to-be-moved node is the last one in its current group? My second question is about the agglomerative merge that was presented in PRE 89, 012804 (2014). Specifically, I am trying to understand the right column of its page 4. To initialize a partition for group numbers B, the approach instructs us to start from B' > B, and do one and only one "agglomerative sweep" to reach B. To do so, we had to enumerate n_m * N possible merges for each node starting from B'. I can see that choosing a minimal entropic change pair greedily and heuristically selects the best block merge, but since the merge candidates are not adaptive, how does a single enumeration of n_m * N possibilities provides sufficient candidates that lead to B, where B'-B > 1? Thanks, Tzu-Chi -- Sent from: http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/

2 1

Computing K number of shortest paths for a single end-node
by sergzz 01 Mar '19

01 Mar '19

Hello, I have just discovered graph-tool and read through a bunch of documentation. I am fairly new to python and graphs. The speed comparison to networkx really impressed me! I was utilizing networkx for a project to find K number of weighted shortest paths from a source to a target node. It has 'all_simple_path' function - outputting a generator that generates all paths starting from shortest to longest. I would simply cut the generator to the K number of paths that I needed. I can't find a similar function in graph-tool, but I am sure this could be implemented. The only thing I found was the all_shortest_paths function, but that only returns the shortest path(s), in most cases only 1. Could you point me in the right direction how to efficiently generate and store K number of shortest paths for a specified node? I know I could just generate all paths and then cut down based on order, but that's not a real solution since I am running into memory issues with a small amount of nodes. Thanks! -- Sent from: http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/

2 3