graph-tool issueshttps://git.skewed.de/count0/graph-tool/-/issues2020-05-23T07:40:46Zhttps://git.skewed.de/count0/graph-tool/-/issues/659Distinctiveness Centrality [feature request]2020-05-23T07:40:46ZAndrea Fronzetti ColladonDistinctiveness Centrality [feature request]We recently developed a new metric of Social Network Analysis, named **Distinctiveness Centrality**.
The metric gives importance to nodes with distinctive/non-redundant network ties, and is fully described in this paper: https://doi.org/10.1371/journal.pone.0233276
Distinctiveness also has a very reasonable computational complexity.
We are not expert programmers so, for now, we were just able to develop a Python package that calculates Distinctiveness and is built upon Networkx: https://github.com/iandreafc/distinctiveness
However, we would love to also use it through graph-tool, which we always use with large networks.
It would be great if you could help us integrate it in your library!We recently developed a new metric of Social Network Analysis, named **Distinctiveness Centrality**.
The metric gives importance to nodes with distinctive/non-redundant network ties, and is fully described in this paper: https://doi.org/10.1371/journal.pone.0233276
Distinctiveness also has a very reasonable computational complexity.
We are not expert programmers so, for now, we were just able to develop a Python package that calculates Distinctiveness and is built upon Networkx: https://github.com/iandreafc/distinctiveness
However, we would love to also use it through graph-tool, which we always use with large networks.
It would be great if you could help us integrate it in your library!https://git.skewed.de/count0/graph-tool/-/issues/658graph_draw changes the value of a property map2020-05-08T13:00:41ZFrancesco D'Amatograph_draw changes the value of a property map# Bug reports:
## Please follow the general troubleshooting steps first:
- [Y ] Are you running the latest `graph-tool` version?
- [Y] Do you observe the problem with the current git version?
- [N] Are you using Macports or Homebrew? If yes, please submit an issue there instead: https://github.com/Homebrew/brew/issues and https://trac.macports.org/newticket
- [N] Did you compile `graph-tool` manually?
- [Not sure] If you answered yes above, did you use the exact same compiler to build `graph-tool`, `boost-python` and `Python`?
Running the code below somehow causes the value of the property map ew to double each time (when it's more than one edge, each value doubles). It does not happen on other properties that I have tried, and changing ew with ew.copy() in graph_draw runs as expected. I looked at the code for graph_draw but can't figure out what is happening
``` g = Graph()
g.add_vertex(2)
g.add_edge(0,1)
ew = g.new_ep('double')
ew[g.edge(0,1)] = 1
graph_draw(g, edge_pen_width = ew)
print(ew.a)
graph_draw(g, edge_pen_width = ew)
print(ew.a)
graph_draw(g, edge_pen_width = ew)
print(ew.a)
graph_draw(g, edge_pen_width = ew)
```
I am running this in Ubuntu WLS, Windows 10 version 2004. Installed it through conda, and I am running it on a jupyter notebook.# Bug reports:
## Please follow the general troubleshooting steps first:
- [Y ] Are you running the latest `graph-tool` version?
- [Y] Do you observe the problem with the current git version?
- [N] Are you using Macports or Homebrew? If yes, please submit an issue there instead: https://github.com/Homebrew/brew/issues and https://trac.macports.org/newticket
- [N] Did you compile `graph-tool` manually?
- [Not sure] If you answered yes above, did you use the exact same compiler to build `graph-tool`, `boost-python` and `Python`?
Running the code below somehow causes the value of the property map ew to double each time (when it's more than one edge, each value doubles). It does not happen on other properties that I have tried, and changing ew with ew.copy() in graph_draw runs as expected. I looked at the code for graph_draw but can't figure out what is happening
``` g = Graph()
g.add_vertex(2)
g.add_edge(0,1)
ew = g.new_ep('double')
ew[g.edge(0,1)] = 1
graph_draw(g, edge_pen_width = ew)
print(ew.a)
graph_draw(g, edge_pen_width = ew)
print(ew.a)
graph_draw(g, edge_pen_width = ew)
print(ew.a)
graph_draw(g, edge_pen_width = ew)
```
I am running this in Ubuntu WLS, Windows 10 version 2004. Installed it through conda, and I am running it on a jupyter notebook.https://git.skewed.de/count0/graph-tool/-/issues/655GraphIsomorphism: IndexError2020-04-27T12:01:48ZDarkaMaulGraphIsomorphism: IndexError# Bug reports:
## Please follow the general troubleshooting steps first:
- [x] Are you running the latest `graph-tool` version? 2.31 (commit 8561bac9, Fri Mar 27 23:59:57 2020 +0100)
## Bug description
Trying to perform an isomorphism between two graphs. The isomorphism fails when we use a vertex_property with "large" numbers.
## Sample case
```python
# The values must be large but the actual number does not matter much
values = [851733746, 1390959473, 0, 0]
edge_list = [[0, 1], [2, 1], [2, 3]]
g1 = graph_tool.Graph()
g1.add_edge_list(edge_list)
g1.vp.prop_int = g1.new_vertex_property('int')
g1.vp.prop_int.get_array()[:] = values
g2 = graph_tool.Graph()
g2.add_edge_list(edge_list)
g2.vp.prop_int = g2.new_vertex_property('int')
g2.vp.prop_int.get_array()[:] = values
# This fails:
graph_tool.topology.isomorphism(g1, g2, vertex_inv1=g1.vp.prop_int, vertex_inv2=g2.vp.prop_int)
```
## General information
- [x] Your operating system : Debian 10 (buster) - Linux 5.4.0-0.bpo.4-amd64 Debian 5.4.19-1~bpo10+1 (2020-03-09) x86_64 GNU/Linux
- [x] The Python version you are using: 3.7.3
## Error report
```shell
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "bug.py", line 22, in main
return graph_tool.topology.isomorphism(g1, g2, vertex_inv1=g1.vp.prop_int, vertex_inv2=g2.vp.prop_int)
File "/usr/lib/python3/dist-packages/graph_tool/topology/__init__.py", line 626, in isomorphism
_prop("v", g1, imap))
IndexError: vector::_M_range_check: __n (which is 18446744073587462741) >= this->size() (which is 2242693221)
```# Bug reports:
## Please follow the general troubleshooting steps first:
- [x] Are you running the latest `graph-tool` version? 2.31 (commit 8561bac9, Fri Mar 27 23:59:57 2020 +0100)
## Bug description
Trying to perform an isomorphism between two graphs. The isomorphism fails when we use a vertex_property with "large" numbers.
## Sample case
```python
# The values must be large but the actual number does not matter much
values = [851733746, 1390959473, 0, 0]
edge_list = [[0, 1], [2, 1], [2, 3]]
g1 = graph_tool.Graph()
g1.add_edge_list(edge_list)
g1.vp.prop_int = g1.new_vertex_property('int')
g1.vp.prop_int.get_array()[:] = values
g2 = graph_tool.Graph()
g2.add_edge_list(edge_list)
g2.vp.prop_int = g2.new_vertex_property('int')
g2.vp.prop_int.get_array()[:] = values
# This fails:
graph_tool.topology.isomorphism(g1, g2, vertex_inv1=g1.vp.prop_int, vertex_inv2=g2.vp.prop_int)
```
## General information
- [x] Your operating system : Debian 10 (buster) - Linux 5.4.0-0.bpo.4-amd64 Debian 5.4.19-1~bpo10+1 (2020-03-09) x86_64 GNU/Linux
- [x] The Python version you are using: 3.7.3
## Error report
```shell
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "bug.py", line 22, in main
return graph_tool.topology.isomorphism(g1, g2, vertex_inv1=g1.vp.prop_int, vertex_inv2=g2.vp.prop_int)
File "/usr/lib/python3/dist-packages/graph_tool/topology/__init__.py", line 626, in isomorphism
_prop("v", g1, imap))
IndexError: vector::_M_range_check: __n (which is 18446744073587462741) >= this->size() (which is 2242693221)
```https://git.skewed.de/count0/graph-tool/-/issues/653Graph Isomorphism with VertexPropertyMap of type long2020-04-24T15:15:25ZDarkaMaulGraph Isomorphism with VertexPropertyMap of type long# Bug reports:
## Informations
* graph-tool version: 2.31 (commit 8561bac9, Fri Mar 27 23:59:57 2020 +0100)
* System: Debian 10 / 5.4.0-0.bpo.4-amd64 / Python version 3.7.3
## Bug description
I want to compute an isomorphism between two graph using an invariant.
This does not work if the type of the `VertexPropertyMap` is long (while it works for int or bool).
## Reproducible example (may not be minimal)
```python
import graph_tool
# Create g
g: graph_tool.Graph = graph_tool.Graph()
g.add_vertex(3)
g.vp.prop_int = g.new_vertex_property('int')
g.vp.prop_long = g.new_vertex_property('long')
g.vp.prop_int.get_array()[:] = [3, 1, 2]
g.vp.prop_long.get_array()[:] = [2**32, 2**32-1, 2**32-5]
g.add_edge_list([(0, 1), (1, 2)])
# Create g2
g2: graph_tool.Graph = graph_tool.Graph()
g2.add_vertex(3)
g2.vp.prop_int = g2.new_vertex_property('int')
g2.vp.prop_long = g2.new_vertex_property('long')
g2.vp.prop_int.get_array()[:] = [3, 1, 2]
g2.vp.prop_long.get_array()[:] = [2**32, 2**32-1, 2**32-5]
g2.add_edge_list([(0, 1), (1, 2)])
# Works as expected
graph_tool.topology.isomorphism(g, g2, vertex_inv1=g.vp.prop_int, vertex_inv2=g2.vp.prop_int)
# This fails:
graph_tool.topology.isomorphism(g, g2, vertex_inv1=g.vp.prop_long, vertex_inv2=g2.vp.prop_long)
```
## Python error
```shell
MemoryError Traceback (most recent call last)
<ipython-input-34-0535769d768c> in <module>
----> 1 graph_tool.topology.isomorphism(g1, g2, vertex_inv1=g1.vp.prop_long, vertex_inv2=g2.vp.prop_long)
/usr/lib/python3/dist-packages/graph_tool/topology/__init__.py in isomorphism(g1, g2, vertex_inv1, vertex_inv2, isomap)
624 _prop("v", g2, vertex_inv2),
625 inv_max,
--> 626 _prop("v", g1, imap))
627 if isomap:
628 return iso, imap
MemoryError:
```# Bug reports:
## Informations
* graph-tool version: 2.31 (commit 8561bac9, Fri Mar 27 23:59:57 2020 +0100)
* System: Debian 10 / 5.4.0-0.bpo.4-amd64 / Python version 3.7.3
## Bug description
I want to compute an isomorphism between two graph using an invariant.
This does not work if the type of the `VertexPropertyMap` is long (while it works for int or bool).
## Reproducible example (may not be minimal)
```python
import graph_tool
# Create g
g: graph_tool.Graph = graph_tool.Graph()
g.add_vertex(3)
g.vp.prop_int = g.new_vertex_property('int')
g.vp.prop_long = g.new_vertex_property('long')
g.vp.prop_int.get_array()[:] = [3, 1, 2]
g.vp.prop_long.get_array()[:] = [2**32, 2**32-1, 2**32-5]
g.add_edge_list([(0, 1), (1, 2)])
# Create g2
g2: graph_tool.Graph = graph_tool.Graph()
g2.add_vertex(3)
g2.vp.prop_int = g2.new_vertex_property('int')
g2.vp.prop_long = g2.new_vertex_property('long')
g2.vp.prop_int.get_array()[:] = [3, 1, 2]
g2.vp.prop_long.get_array()[:] = [2**32, 2**32-1, 2**32-5]
g2.add_edge_list([(0, 1), (1, 2)])
# Works as expected
graph_tool.topology.isomorphism(g, g2, vertex_inv1=g.vp.prop_int, vertex_inv2=g2.vp.prop_int)
# This fails:
graph_tool.topology.isomorphism(g, g2, vertex_inv1=g.vp.prop_long, vertex_inv2=g2.vp.prop_long)
```
## Python error
```shell
MemoryError Traceback (most recent call last)
<ipython-input-34-0535769d768c> in <module>
----> 1 graph_tool.topology.isomorphism(g1, g2, vertex_inv1=g1.vp.prop_long, vertex_inv2=g2.vp.prop_long)
/usr/lib/python3/dist-packages/graph_tool/topology/__init__.py in isomorphism(g1, g2, vertex_inv1, vertex_inv2, isomap)
624 _prop("v", g2, vertex_inv2),
625 inv_max,
--> 626 _prop("v", g1, imap))
627 if isomap:
628 return iso, imap
MemoryError:
```https://git.skewed.de/count0/graph-tool/-/issues/652Max flow segfaults with source=target2020-04-23T19:52:00ZSteve HarenbergMax flow segfaults with source=targetgraph-tool is segfaulting when running maxflow with source=target
version: '2.29 (commit d4154c6c, Tue Aug 27 13:21:10 2019 +0000)'
python version: 3.7.5
```python
import graph_tool as gt
import graph_tool.flow as gtf
g = gt.Graph()
v1 = g.add_vertex()
v2 = g.add_vertex()
e = g.add_edge(v1, v2)
cap = g.new_edge_property("double", val=1)
result = gtf.edmonds_karp_max_flow(g, source=v1, target=v1, capacity=cap)
```graph-tool is segfaulting when running maxflow with source=target
version: '2.29 (commit d4154c6c, Tue Aug 27 13:21:10 2019 +0000)'
python version: 3.7.5
```python
import graph_tool as gt
import graph_tool.flow as gtf
g = gt.Graph()
v1 = g.add_vertex()
v2 = g.add_vertex()
e = g.add_edge(v1, v2)
cap = g.new_edge_property("double", val=1)
result = gtf.edmonds_karp_max_flow(g, source=v1, target=v1, capacity=cap)
```https://git.skewed.de/count0/graph-tool/-/issues/626Drawing more than 2 graphs in a window2020-01-28T02:26:09ZXinlong YinDrawing more than 2 graphs in a window![Screenshot_from_2020-01-27_21-17-30](/uploads/3a4cec1d0f85e55ccd41a1acae19aae4/Screenshot_from_2020-01-27_21-17-30.png)
I am trying to do an animation of several graphs in one window. When I try to add more than 2 GraphWidgets in a window, only the first 2 can be rendered, and the others just show a black rectangle. However, the simulation seems to be fine, because the plots seem to be normal. Is this a bug of the library or there's something wrong in my code?
[myTest.py](/uploads/bad2e728e055020cf9b3e93aa982f7e0/myTest.py)![Screenshot_from_2020-01-27_21-17-30](/uploads/3a4cec1d0f85e55ccd41a1acae19aae4/Screenshot_from_2020-01-27_21-17-30.png)
I am trying to do an animation of several graphs in one window. When I try to add more than 2 GraphWidgets in a window, only the first 2 can be rendered, and the others just show a black rectangle. However, the simulation seems to be fine, because the plots seem to be normal. Is this a bug of the library or there's something wrong in my code?
[myTest.py](/uploads/bad2e728e055020cf9b3e93aa982f7e0/myTest.py)https://git.skewed.de/count0/graph-tool/-/issues/600[feature request] Structural Holes Constraint2019-07-27T08:09:02ZAndrea Fronzetti Colladon[feature request] Structural Holes ConstraintIt would be great to have a graph-tool function to calculate Structural Holes, i.e. the Constraint theorized by Burt.
Networkx does it, but it is deadly slow: https://networkx.github.io/documentation/stable/reference/algorithms/generated/networkx.algorithms.structuralholes.constraint.html#networkx.algorithms.structuralholes.constraintIt would be great to have a graph-tool function to calculate Structural Holes, i.e. the Constraint theorized by Burt.
Networkx does it, but it is deadly slow: https://networkx.github.io/documentation/stable/reference/algorithms/generated/networkx.algorithms.structuralholes.constraint.html#networkx.algorithms.structuralholes.constrainthttps://git.skewed.de/count0/graph-tool/-/issues/597Graphviz_draw core dumping when using HTML labels2019-07-12T16:01:26ZJoe MichaelsGraphviz_draw core dumping when using HTML labels# Bug report:
- [X] Are you running the latest `graph-tool` version?
- [ ] Do you observe the problem with the current git version?
- [ ] Are you using Macports or Homebrew? If yes, please submit an issue there instead: https://github.com/Homebrew/brew/issues and https://trac.macports.org/newticket
- [ ] Did you compile `graph-tool` manually?
- [ ] If you answered yes above, did you use the exact same compiler to build `graph-tool`, `boost-python` and `Python`?
When using `graphviz_draw()` with an HTML vertex label, it core dumps. The `graphviz_draw()` works without issues otherwise. I tracked the issue to the `agstrdup_html()` function call (https://git.skewed.de/count0/graph-tool/blob/master/src/graph_tool/draw/graphviz_draw.py#L97).
I am currently using Ubuntu 18.04, Python 3.6 (default), graph-tool 2.28 installed from apt from this repository: http://downloads.skewed.de/apt/bionic.
```
from graph_tool.all import *
g = Graph()
g.add_vertex(2)
g.add_edge(0, 1)
graphviz_draw(g, vprops={'label': '<x>' })
```
I would expect both vertices to have the same label `x`. If I remove the enclosing < >, it works. However, when enclosed with < >, to specify an HTML label, it core dumps - regardless if I place actual HTML tags or not.# Bug report:
- [X] Are you running the latest `graph-tool` version?
- [ ] Do you observe the problem with the current git version?
- [ ] Are you using Macports or Homebrew? If yes, please submit an issue there instead: https://github.com/Homebrew/brew/issues and https://trac.macports.org/newticket
- [ ] Did you compile `graph-tool` manually?
- [ ] If you answered yes above, did you use the exact same compiler to build `graph-tool`, `boost-python` and `Python`?
When using `graphviz_draw()` with an HTML vertex label, it core dumps. The `graphviz_draw()` works without issues otherwise. I tracked the issue to the `agstrdup_html()` function call (https://git.skewed.de/count0/graph-tool/blob/master/src/graph_tool/draw/graphviz_draw.py#L97).
I am currently using Ubuntu 18.04, Python 3.6 (default), graph-tool 2.28 installed from apt from this repository: http://downloads.skewed.de/apt/bionic.
```
from graph_tool.all import *
g = Graph()
g.add_vertex(2)
g.add_edge(0, 1)
graphviz_draw(g, vprops={'label': '<x>' })
```
I would expect both vertices to have the same label `x`. If I remove the enclosing < >, it works. However, when enclosed with < >, to specify an HTML label, it core dumps - regardless if I place actual HTML tags or not.https://git.skewed.de/count0/graph-tool/-/issues/573Support yum package manager2019-03-27T08:40:57ZRegev SchweigerSupport yum package managerPlease add support for the yum package manager. This is mainly useful for installing on the default Amazon AWS image.Please add support for the yum package manager. This is mainly useful for installing on the default Amazon AWS image.https://git.skewed.de/count0/graph-tool/-/issues/506Extract change point information2018-09-20T07:34:24ZHaiko LietzExtract change point informationgt allows inferring change points in layered graphs when time is passed as an edge property (Peixoto (2015). Inferring the mesoscale structure of layered, edge-valued, and time-varying networks. https://doi.org/10.1103/PhysRevE.92.042807). But extracting the bin / change point information from the SBM is not automatized in gt. The goal is to produce a figures as in figure 8 of the referenced paper. Help is truly appreciated...gt allows inferring change points in layered graphs when time is passed as an edge property (Peixoto (2015). Inferring the mesoscale structure of layered, edge-valued, and time-varying networks. https://doi.org/10.1103/PhysRevE.92.042807). But extracting the bin / change point information from the SBM is not automatized in gt. The goal is to produce a figures as in figure 8 of the referenced paper. Help is truly appreciated...https://git.skewed.de/count0/graph-tool/-/issues/491[feature request] Weighted diameter and average distance2018-07-08T21:45:35ZFabrÃcio[feature request] Weighted diameter and average distanceI am working with large graphs calculating diameter and average path length. I am using the `shortest_distance()` function with weights which returns the dist_map then I use the `get_2d_array()` to convert to a `np.array` and calculate the diameter (np.max) and the average distance (np.mean). The problem is that the `shortest_distance()` is taking around 6 minutes but the `get_2d_array()` is taking much more than that, which is strange. I wonder if maybe having both average distance and diameter implemented C++ wouldn't provide a huge performance boost.
Is there any other alternative for what I am trying to do? I can provide the graph in `.graphml` if it can be of any help.I am working with large graphs calculating diameter and average path length. I am using the `shortest_distance()` function with weights which returns the dist_map then I use the `get_2d_array()` to convert to a `np.array` and calculate the diameter (np.max) and the average distance (np.mean). The problem is that the `shortest_distance()` is taking around 6 minutes but the `get_2d_array()` is taking much more than that, which is strange. I wonder if maybe having both average distance and diameter implemented C++ wouldn't provide a huge performance boost.
Is there any other alternative for what I am trying to do? I can provide the graph in `.graphml` if it can be of any help.https://git.skewed.de/count0/graph-tool/-/issues/463[feature requrest] Rich-club coefficient2018-05-01T18:19:07ZAlain Fonhof[feature requrest] Rich-club coefficient@count0 I was wondering if you ever got around to implementing the rich-club coefficient algorithm as discussed in this thread: http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/Rich-club-td4025697.html
Just for reference this is the algorithm I would love to see in graph-tool: https://networkx.github.io/documentation/stable/reference/algorithms/generated/networkx.algorithms.richclub.rich_club_coefficient.html#networkx.algorithms.richclub.rich_club_coefficient
I made a small start but I am not quiet sure how to implement the normalization with graph-tool.
```
def rich_club_coefficient(g):
deghist = gt.vertex_hist(g, 'total')[0]
total = sum(deghist)
rc = {}
# Compute the number of nodes with degree greater than `k`, for each
# degree `k` (omitting the last entry, which is zero).
nks = (total - cs for cs in np.cumsum(deghist) if total - cs > 1)
deg = g.degree_property_map('total')
for k, nk in enumerate(nks):
if nk == 0:
continue
sub_g = gt.GraphView(g, vfilt=lambda v: deg[v] > k)
ek = sub_g.num_edges()
rc[k] = 2 * ek / (nk * (nk - 1))
return rc
```@count0 I was wondering if you ever got around to implementing the rich-club coefficient algorithm as discussed in this thread: http://main-discussion-list-for-the-graph-tool-project.982480.n3.nabble.com/Rich-club-td4025697.html
Just for reference this is the algorithm I would love to see in graph-tool: https://networkx.github.io/documentation/stable/reference/algorithms/generated/networkx.algorithms.richclub.rich_club_coefficient.html#networkx.algorithms.richclub.rich_club_coefficient
I made a small start but I am not quiet sure how to implement the normalization with graph-tool.
```
def rich_club_coefficient(g):
deghist = gt.vertex_hist(g, 'total')[0]
total = sum(deghist)
rc = {}
# Compute the number of nodes with degree greater than `k`, for each
# degree `k` (omitting the last entry, which is zero).
nks = (total - cs for cs in np.cumsum(deghist) if total - cs > 1)
deg = g.degree_property_map('total')
for k, nk in enumerate(nks):
if nk == 0:
continue
sub_g = gt.GraphView(g, vfilt=lambda v: deg[v] > k)
ek = sub_g.num_edges()
rc[k] = 2 * ek / (nk * (nk - 1))
return rc
```https://git.skewed.de/count0/graph-tool/-/issues/460[feature request] Implement 2-edge-connected components2018-04-26T13:46:47ZAndre Vieira[feature request] Implement 2-edge-connected componentsAs recommended, I am opening an issue suggesting the addition of an algorithm that labels the 2-edge-connected components of an undirected graph.
Cheers,
Andre.As recommended, I am opening an issue suggesting the addition of an algorithm that labels the 2-edge-connected components of an undirected graph.
Cheers,
Andre.https://git.skewed.de/count0/graph-tool/-/issues/452get_edges_prob() alters state entropy with real-normal edge covariates2018-03-26T15:27:40ZKatharina Baumget_edges_prob() alters state entropy with real-normal edge covariates# Bug report:
Experienced in version 2.26, under Python 2.7 and 3.6 as well as using the latest Docker image (18-03-26).
## Bug description
Calling get_edges_prob() alters the state object and gives inconsistent results if using a real-normal edge prior (apparently not for real-exponential prior or models without edge covariates).
## Example illustrating the problem
```python
import graph_tool.all as gt
g=gt.collection.data['celegansneural']
state=gt.minimize_blockmodel_dl(g,state_args=dict(recs=[g.ep.value],rec_types=['real-normal']))
original_entropy=state.entropy()
edge_prob=[]
for i in range(10000): edge_prob.append(state.get_edges_prob(missing=[],spurious=[(0,2)]))
original_entropy-state.entropy() #this is not zero...
edge_prob[0]-edge_prob[-1] #this is not zero...
```# Bug report:
Experienced in version 2.26, under Python 2.7 and 3.6 as well as using the latest Docker image (18-03-26).
## Bug description
Calling get_edges_prob() alters the state object and gives inconsistent results if using a real-normal edge prior (apparently not for real-exponential prior or models without edge covariates).
## Example illustrating the problem
```python
import graph_tool.all as gt
g=gt.collection.data['celegansneural']
state=gt.minimize_blockmodel_dl(g,state_args=dict(recs=[g.ep.value],rec_types=['real-normal']))
original_entropy=state.entropy()
edge_prob=[]
for i in range(10000): edge_prob.append(state.get_edges_prob(missing=[],spurious=[(0,2)]))
original_entropy-state.entropy() #this is not zero...
edge_prob[0]-edge_prob[-1] #this is not zero...
```https://git.skewed.de/count0/graph-tool/-/issues/450Dot parser fails on graph attributes2019-07-22T04:26:49ZAlexander UstimenkoDot parser fails on graph attributes# Bug reports:
On latest docker repeats, repeats under python 2/3. Seems issue inside cpp.
To repeat:
## Fails
```
echo 'digraph Wtf {graph[layout="dot"]}' | python -c 'import sys; import graph_tool.all as gt; g = gt.load_graph(sys.stdin, fmt="dot");'
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python2.7/dist-packages/graph_tool/__init__.py", line 2936, in load_graph
g.load(file_name, fmt, ignore_vp, ignore_ep, ignore_gp)
File "/usr/lib/python2.7/dist-packages/graph_tool/__init__.py", line 2485, in load
ignore_vp, ignore_ep, ignore_gp)
RuntimeError: boost::bad_any_cast: failed conversion using boost::any_cast
```
## Works
```
echo 'digraph Wtf {graph[]}' | python -c 'import sys; import graph_tool.all as gt; g = gt.load_graph(sys.stdin, fmt="dot");'
```# Bug reports:
On latest docker repeats, repeats under python 2/3. Seems issue inside cpp.
To repeat:
## Fails
```
echo 'digraph Wtf {graph[layout="dot"]}' | python -c 'import sys; import graph_tool.all as gt; g = gt.load_graph(sys.stdin, fmt="dot");'
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python2.7/dist-packages/graph_tool/__init__.py", line 2936, in load_graph
g.load(file_name, fmt, ignore_vp, ignore_ep, ignore_gp)
File "/usr/lib/python2.7/dist-packages/graph_tool/__init__.py", line 2485, in load
ignore_vp, ignore_ep, ignore_gp)
RuntimeError: boost::bad_any_cast: failed conversion using boost::any_cast
```
## Works
```
echo 'digraph Wtf {graph[]}' | python -c 'import sys; import graph_tool.all as gt; g = gt.load_graph(sys.stdin, fmt="dot");'
```https://git.skewed.de/count0/graph-tool/-/issues/428graph_draw not mapping integer props correctly2017-12-02T20:33:15ZTiemengraph_draw not mapping integer props correctlyI'm not sure if this is intended behaviour of graph_tool.draw.graph_draw, but it seems erroneous. If I add an edge property as an 'int' with some values (e.g. 1 and 11) they are **color**mapped differently as opposed to 'float' with the same values.
Perhaps conversion to (normalized) floats is essential for the mapping to work out, but I feel this is something that should be covered behind the scenes. For instance, if you would like to map according to vertex degree, you would have to convert your property to float first, because it would otherwise be mapped with bogus colors (they seemingly do something, which could be even worse).
## Bug reports:
* I'm running graph_tool 2.25 on Ubuntu 16.04, Python 3.6.2, not manually compiled.
- Do you observe the problem with the current git version?
* I see no relevant changes in the files and cannot build from source sadly.
```python
import numpy as np
import graph_tool.all as gt
from graph_tool.draw import graph_draw
g = gt.Graph()
# Edge prop
adj = g.new_ep('int') # CHANGE TO FLOAT FOR CORRECT BEHAVIOUR
g.ep['adj'] = adj
# Populate
a = np.array([[0, 1, 11], [1, 0, 1]])
g.add_edge_list(a, eprops=[adj])
# Names
vnames = g.new_vp('string', vals=['A', 'B'])
g.vp['vnames'] = vnames
# Draw
graph_draw(g,edge_color=adj, vertex_text=vnames, edge_pen_width=6.0, output='test_int.png')
```
## Integer result (wrong!)
![test_int](/uploads/af3f9075e3717f2f180ce1a98c08e2ad/test_int.png)
## Float result (correct)
![test_float](/uploads/b3e27aba17381e462117bfb9a89094ca/test_float.png)I'm not sure if this is intended behaviour of graph_tool.draw.graph_draw, but it seems erroneous. If I add an edge property as an 'int' with some values (e.g. 1 and 11) they are **color**mapped differently as opposed to 'float' with the same values.
Perhaps conversion to (normalized) floats is essential for the mapping to work out, but I feel this is something that should be covered behind the scenes. For instance, if you would like to map according to vertex degree, you would have to convert your property to float first, because it would otherwise be mapped with bogus colors (they seemingly do something, which could be even worse).
## Bug reports:
* I'm running graph_tool 2.25 on Ubuntu 16.04, Python 3.6.2, not manually compiled.
- Do you observe the problem with the current git version?
* I see no relevant changes in the files and cannot build from source sadly.
```python
import numpy as np
import graph_tool.all as gt
from graph_tool.draw import graph_draw
g = gt.Graph()
# Edge prop
adj = g.new_ep('int') # CHANGE TO FLOAT FOR CORRECT BEHAVIOUR
g.ep['adj'] = adj
# Populate
a = np.array([[0, 1, 11], [1, 0, 1]])
g.add_edge_list(a, eprops=[adj])
# Names
vnames = g.new_vp('string', vals=['A', 'B'])
g.vp['vnames'] = vnames
# Draw
graph_draw(g,edge_color=adj, vertex_text=vnames, edge_pen_width=6.0, output='test_int.png')
```
## Integer result (wrong!)
![test_int](/uploads/af3f9075e3717f2f180ce1a98c08e2ad/test_int.png)
## Float result (correct)
![test_float](/uploads/b3e27aba17381e462117bfb9a89094ca/test_float.png)https://git.skewed.de/count0/graph-tool/-/issues/417Implementation of sub-graph centrality2017-10-02T14:17:33ZEmilio BertiImplementation of sub-graph centralityI would like to use the subgraph centrality index as defined in Estrada E. 2007
Link to article: http://www.estradalab.org/wp-content/uploads/2015/10/paper-951.pdf
Did someone already implement it?I would like to use the subgraph centrality index as defined in Estrada E. 2007
Link to article: http://www.estradalab.org/wp-content/uploads/2015/10/paper-951.pdf
Did someone already implement it?https://git.skewed.de/count0/graph-tool/-/issues/414Documentation for deg_sampler in generation.random_graph2017-09-24T07:44:20ZSnehal ShekatkarDocumentation for deg_sampler in generation.random_graphThe documentation for deg_sampler function from random_graph says:
A degree sampler function which is called without arguments, and returns a tuple of ints representing the in and out-degree of a given vertex (or a single int for undirected graphs, representing the out-degree). This function is called once per vertex, but may be called more times, if the degree sequence cannot be used to build a graph.
Optionally, you can also pass a function which receives one or two arguments. If block_membership is None, the single argument passed will be the index of the vertex which will receive the degree. If block_membership is not None, the first value passed will be the vertex index, and the second will be the block value of the vertex.
We have already discussed this issue in the past and then you had replied saying that "The function random_graph() will look at how many parameters the deg_sampler takes, and this will trigger different behaviors. Although it is in fact documented, I agree this is confusing and unexpected. Please open an issue in the website, and this will be improved in the future."
I request you to kindly make the necessary improvements whenever it would be possible for you.The documentation for deg_sampler function from random_graph says:
A degree sampler function which is called without arguments, and returns a tuple of ints representing the in and out-degree of a given vertex (or a single int for undirected graphs, representing the out-degree). This function is called once per vertex, but may be called more times, if the degree sequence cannot be used to build a graph.
Optionally, you can also pass a function which receives one or two arguments. If block_membership is None, the single argument passed will be the index of the vertex which will receive the degree. If block_membership is not None, the first value passed will be the vertex index, and the second will be the block value of the vertex.
We have already discussed this issue in the past and then you had replied saying that "The function random_graph() will look at how many parameters the deg_sampler takes, and this will trigger different behaviors. Although it is in fact documented, I agree this is confusing and unexpected. Please open an issue in the website, and this will be improved in the future."
I request you to kindly make the necessary improvements whenever it would be possible for you.https://git.skewed.de/count0/graph-tool/-/issues/398Minimum spanning arborescence?2017-09-14T18:09:47ZXiao HanMinimum spanning arborescence?Hi,
I find algorithms for minimum spanning arborescence (MST for directed graph) are missing.
It would be good if they can be considered in the future.
Thanks!
HanHi,
I find algorithms for minimum spanning arborescence (MST for directed graph) are missing.
It would be good if they can be considered in the future.
Thanks!
Hanhttps://git.skewed.de/count0/graph-tool/-/issues/390Feature request - unsigned integer data types.2017-04-27T09:57:34ZAlfredo MazzinghiFeature request - unsigned integer data types.I am trying to store a python integer as a _uint64_t_ in a property map, however the current integral data types supported only include signed data types.
This leaves me with the only option of storing the _uint64_t_ values in a property map with type _object_, however this is suboptimal as the storage required for the graph increases.
I made a simple test with two graphs of a million nodes with random 64-bit integers values attached to the nodes, comparing the graph size in the case of _int64_t_ and _object_ property maps. My results show that in the former case the graph (gt format) takes up about 16MiB while in the latter case it takes 37MiB.
I have not test load times but I suspect that it may have an impact there as well.
I am wondering why unsigned data types have not been provided, but if the task is not too difficult it would be nice to have.I am trying to store a python integer as a _uint64_t_ in a property map, however the current integral data types supported only include signed data types.
This leaves me with the only option of storing the _uint64_t_ values in a property map with type _object_, however this is suboptimal as the storage required for the graph increases.
I made a simple test with two graphs of a million nodes with random 64-bit integers values attached to the nodes, comparing the graph size in the case of _int64_t_ and _object_ property maps. My results show that in the former case the graph (gt format) takes up about 16MiB while in the latter case it takes 37MiB.
I have not test load times but I suspect that it may have an impact there as well.
I am wondering why unsigned data types have not been provided, but if the task is not too difficult it would be nice to have.