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/

Hi again,
I'm writing a small package that builds on graph-tool, but not on its graphics capabilities (also because I have to represent other things rather than the graph itself). Still I could use some of the functions "under the hood" for my purposes. I have a question about gt.draw.get_hierarchy_control_points(): the function returns the Bézier spline control points for edges in a given graph, but I'm having difficulties in understanding how this information is encoded. For a single edge in graph, I have dozens of values as control points (half dozens + 2), hence I suspect all splines going from node A to the root of a hierarchy and back to node B are encoded there, and control points should be taken 6 by 6 (3x2 by 3x2 coordinates?). How (x,y) for control points are encoded then: (x, x, x, y, y, y) or (x, y, x, y, x, y)? What are the 2 additiona values I have for each vector? Also, are values absolute or relative to one node in particular (A, B or root...)?
Thanks
d

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.

Dear Graph-Tool Community,
I am interested in analysing the hierarchical partitions generated by the nested blockmodel. Specifically, after I have generated a nested SBM; I would then like to post-process this and calculate measures such as eigenvector centrality for a given hierarchical node; save this as a property, and then in visualisation apply either a size or colormap constraint to said node weighted by its centrality.
Using the collection data;
g = gt.collection.data["celegansneural”]
state = gt.minimize_nested_blockmodel_dl(g)
I can then ascertain what my levels are with;
l1state = state.levels[1].g
l2state = state.levels[2].g
etc.
I can then calculate eigenvector centrality of a given hierarchical partition as follows;
ee1, x1 = gt.eigenvector(l1state)
ee2, x2 = gt.eigenvector(l2state)
1) This presumably then needs to be saved as a hvprops(?!). But, I am unclear how to do this, not least in a way that I know for sure that the correct hierarchical vertices within l1state and l2state are aligning to the generated centrality measures of x1 and x2, respectively.
2) Furthermore, if/when that is achieved, how can I call upon this in drawing, for example to size the level 1 hierarchical vertices according to centrality, or level 2 vertices by another measure, etc.?
Hugely grateful for any solutions!
James

Dear community / Tiago
I have a hierarchical partition of a nested block state.
The original network contained 4453 vertices and 50051 edges.
state.print_summary()
l: 0, N: 4453, B: 126
l: 1, N: 126, B: 46
l: 2, N: 46, B: 20
l: 3, N: 20, B: 9
l: 4, N: 9, B: 3
l: 5, N: 3, B: 1
I want to extract the community label of each vertex of each possible hierarchical level.
To do this I wrote a loop based upon the guide at https://graph-tool.skewed.de/static/doc/demos/inference/inference.html
Where vertexblocksdf is simply a df populated with the vertex numbers 0-4452.
for idx in range(len(vertexblocksdf)):
r = levels[0].get_blocks()[idx] # group membership of node idx in level 0
vertexblocksdf.ix[idx, 'level0'] = r
r = levels[0].get_blocks()[r] # group membership of node idx in level 1
vertexblocksdf.ix[idx, 'level1'] = r
r = levels[0].get_blocks()[r] # group membership of node idx in level 2
vertexblocksdf.ix[idx, 'level2'] = r
r = levels[0].get_blocks()[r] # group membership of node idx in level 3
vertexblocksdf.ix[idx, 'level3'] = r
r = levels[0].get_blocks()[r] # group membership of node idx in level 4
vertexblocksdf.ix[idx, 'level4'] = r
r = levels[0].get_blocks()[r] # group membership of node idx in level 5
vertexblocksdf.ix[idx, 'level5'] = r
But, I am getting strange results. My level0 column variables make sense, with 126 possibilities (as per l0 above). But my level1 column is a number between 0 and 13; of which none of my levels have 14 blocks. My level2 output is either 0 or 1, again doesn’t make sense! Level3-5 are all simply 0.
*this also reproduces the same behaviour if done manually without loop.
Any ideas??
James

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

I’ve managed to install graph-tool version 2.29 (commit d4154c6c) via
aptitude installer on Ubuntu 18.04 in a python3 miniconda venv. The
following example gist causes a 127 exit code caused by some sort of fudged
up library linking to libgraph_tool_draw.so with:
undefined symbol:
_ZN5Cairo7Context16select_font_faceERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENS_9FontSlantENS_10FontWeightE
from graph_tool.all import *
g = Graph()
ug = Graph(directed=False)
ug = Graph()
ug.set_directed(False)
assert ug.is_directed() == False
v1 = g.add_vertex()
v2 = g.add_vertex()
graph_tool.draw.graph_draw(g, vertex_text=g.vertex_index,
vertex_font_size=18,
output_size=(200, 200), output="test.png”)
Incidentally, when try to compile graph-tool from upstream master the make
routine fails with a libtools error on reading libsigc-2.0.la in my
configuration using
--with-python-module-path=…/miniconda3/envs/mne/lib/python3.7/site-packages.
On the verge of losing more hair than I can afford. Magic fix commands
appreciated.
-Kam

Dear Tiago,
Thanks for building this wonderful package!
As a novice in Python I'm struggling to install this package- My operating
system is MacOS and I installed graph-tool via Homebrew.
It seems the installation was successful. When compiling, the command
'./configure' doesn't work, could you please give the further instructions?
Many thanks,
Yingjie
--
Sent from: http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/

Dear all,
We have a doubt about good practices in collecting vertex marginals during equilibration. In the howto, collection is done with an additional mcmc_equilibrate step with force_niter set to the desired "precision" but in principle this can be done during a single mcmc_equilibrate after mcmc_sweep. We observed some differences (especially when we collect the marginals for groups at each level of the NSBM), so we wonder which would be preferred.
Thanks
d