graph-tool

Download

graph-tool@skewed.de

February 2022

8 participants
12 discussions

Passing different rec_types for different layers
by arttu.malkamaki＠helsinki.fi 07 Feb '22

07 Feb '22

Hello, Given a situation where I'm trying to fit a LayeredBlockState with somewhat different edge weight distributions across the layers, is it possible to pass different rec_types for different layers when using LayeredBlockState? Or should I pick one that fits the aggregate distribution of my ten layers? Or is it perhaps best to convert the weights in each layer to discrete values? This is how I'm currently doing it, but I know that "real-normal" works better for the first two layers if I fit them separately. state = gt.minimize_blockmodel_dl(g, state = gt.LayeredBlockState, state_args = dict(deg_corr = True, overlap = True, layers = True, ec = g.ep.layer, recs = [g.ep.weight], rec_types = ["real-exponential"])) Best, Arttu

2 1

graph_tool.topology.shortest_distance() - Confusing documentation or possible bug in return_reached; wrong documentation
by João Aveiro 02 Feb '22

02 Feb '22

Hello everyone, In the "shortest_distance" routine there is the option to return an array with the reached vertices by setting the flag/attribute "return_reached" to True. While using this routine, having set the max_dist, I have found that in the returned array not only are included the vertices in fact reached within the max_dist limit, but also some neighbouring vertices that probably were visited during the Dijkstra steps but exceeded the limit. I believe this behaviour is confusing and it may lead to erratic code/bugs for those who are not expecting it. I propose either: 1. Change the routine as to return only the vertices that are in fact reached within max_dist; 2. Change this flag to something like "return_visited", as to hint that the returned vertices may not in fact be reached within the expected distance limit; 3. Add a warning in the documentation regarding this behaviour. Regarding the same method but on another subject, I believe there is an error in the documentation, namely on the return variables. There we can see two optional return values named "pred_map", while in fact one of them is the reached-vertices array mentioned above. Having the same name one may think that it might actually be a exclusive OR return where only either one is returned and it is just an matter of weird naming. I may try to implement one of the changes above, if it is decided so, but the access to the GitLab repo through GitHub account linking has not been accepted by the admin yet. JA

2 2