[graph-tool] Stop current search path in a DFS
Hi, I'd like to perform a DFS to find some nodes. However, I only need the first occurrences of these nodes. To visualize the problem, I have drawn a little example graph: https://i.imgur.com/BgdUzOz.png The graph is directed but has no further constraints. The search should start at the orange node. It should reveal the two nearby red nodes but not the red node labeled with "This one not". Precisely said: It should not reveal a red node that is dominated by another red node. If I would implement the DFS by myself I just wouldn't follow the outgoing edges of a red node (and stop the search for this path). However, within graph-tool I have only found a way to stop the _whole_ search with an StopSearch exception. Is there a way to use graph-tool to perform a search like I have described it? Kind regards, Gerion signature.asc Description: This is a digitally signed message part. ___ graph-tool mailing list -- graph-tool@skewed.de To unsubscribe send an email to graph-tool-le...@skewed.de
[graph-tool] Re: ValueError: invalid edge descriptor. How to debug?
Am Freitag, 3. September 2021, 17:42:40 CEST schrieb Gerion Entrup: > Am Freitag, 3. September 2021, 11:12:45 CEST schrieb Tiago de Paula Peixoto: > > Am 03.09.21 um 00:18 schrieb Gerion Entrup: > > > My question: How can I debug this and find out, why it is invalid? Can I > > > do/print anything in Python? Should I use GDB? Where would be a good > > > place to set a breakpoint? > > > > > > I cannot print the faulty edge. It is fairly complicate to make an > > > minimal example. My whole code uses no remove_edge() or remove_vertex(). > > > I'm using graph_tool 2.43. > > > > What you should do is produce a minimal example that shows the > > problem... No debugger is going to replace this simple strategy. > > The function is not new. It has worked for some time now. I'm pretty sure, > that this exact graph produces the problem. > So to make a minimal example, it would help to understand the problem first. I have found my error. The function `get_function_bbs` actually is a generator and thus leaving the out_edges() iterator intact. In the code which calls `get_function_bbs`, however, some additional edges are created for this exact node (`function`) which probably destroys the iterator. Storing the generator output in memory first fixes the problem. Best, Gerion signature.asc Description: This is a digitally signed message part. ___ graph-tool mailing list -- graph-tool@skewed.de To unsubscribe send an email to graph-tool-le...@skewed.de
[graph-tool] Re: ValueError: invalid edge descriptor. How to debug?
Am Freitag, 3. September 2021, 11:12:45 CEST schrieb Tiago de Paula Peixoto: > Am 03.09.21 um 00:18 schrieb Gerion Entrup: > > My question: How can I debug this and find out, why it is invalid? Can I > > do/print anything in Python? Should I use GDB? Where would be a good place > > to set a breakpoint? > > > > I cannot print the faulty edge. It is fairly complicate to make an minimal > > example. My whole code uses no remove_edge() or remove_vertex(). I'm using > > graph_tool 2.43. > > What you should do is produce a minimal example that shows the > problem... No debugger is going to replace this simple strategy. The function is not new. It has worked for some time now. I'm pretty sure, that this exact graph produces the problem. So to make a minimal example, it would help to understand the problem first. > From the code fragment that you have shown, it's not possible to say much. > > I notice that you are subclassing Graph, and probably omitting to us > specializations that you are making to Graph.vertex() and other methods. There are no specializations of any graph-tool function in the subclass. It only exists to provide additional specialized functions. Has the Python wrapper object that boost creates some special data fields that I could print? I'm compiling graph-tool on my own, anyway. Can I add some prints at the place in the graph-tool sourcecode where the "invalid edge descriptor" is generated? Best Gerion signature.asc Description: This is a digitally signed message part. ___ graph-tool mailing list -- graph-tool@skewed.de To unsubscribe send an email to graph-tool-le...@skewed.de
[graph-tool] ValueError: invalid edge descriptor. How to debug?
Hi,
I got a strange problem. I have this code (simplified, the Graph represented by
graph_tool is a control flow graph):
```
class CFG(graph_tool.Graph):
def get_function_bbs(self, function):
print(self.vertex(function))
for edge in self.vertex(function).out_edges():
print(edge.__dict__)
print(edge)
if self.ep.type[edge] == CFType.f2b:
yield edge.target()
```
Calling the function `get_function_bbs` now leads to a `ValueError: invalid
edge descriptor`. The stack trace says the `print(edge)` instruction is
responsible for the error:
```
File "/.../graph.py", line 93, in get_function_bbs
print(edge)
ValueError: invalid edge descriptor
```
In my tests the function is called many times. This is the output (---
indicates a new call of get_function_bbs)
```
---
12
{}
(12, 13)
---
24
{}
(24, 25)
---
40
{}
(40, 41)
---
71
{}
(71, 72)
{}
(71, 73)
{}
```
So: `71` is the vertex, where the functions fails. There are two edges `(71,
72)` and `(71, 73)` where the descriptor is valid and another unknown edge that
is _not_ valid.
All edge descriptors have no dict.
My question: How can I debug this and find out, why it is invalid? Can I
do/print anything in Python? Should I use GDB? Where would be a good place to
set a breakpoint?
I cannot print the faulty edge. It is fairly complicate to make an minimal
example. My whole code uses no remove_edge() or remove_vertex(). I'm using
graph_tool 2.43.
Best,
Gerion
signature.asc
Description: This is a digitally signed message part.
___
graph-tool mailing list -- graph-tool@skewed.de
To unsubscribe send an email to graph-tool-le...@skewed.de
[graph-tool] Re: Fail to build on macOS with boost 1.76
Am Donnerstag, 10. Juni 2021, 16:17:01 CEST schrieb da.su...@gmail.com: > Using various options to build graph-tool on macOS (brew and generic build), > I'm getting the following error: > > ``` > In file included from ./graph_avg_correlations.hh:21: > ./graph_correlations.hh:113:22: error: no template named 'greater' in > namespace 'boost::mpl'; did you mean simply 'greater'? > typename mpl::greater::type, > ^~~~ > greater > ``` > > Is it some update in boost (I'm using the latest 1.76) or another issue? > Thanks for the help! > ___ > graph-tool mailing list -- graph-tool@skewed.de > To unsubscribe send an email to graph-tool-le...@skewed.de > Has nothing to do with MacOS. I encounter the same error: https://git.skewed.de/count0/graph-tool/-/issues/703 Best, Gerion signature.asc Description: This is a digitally signed message part. ___ graph-tool mailing list -- graph-tool@skewed.de To unsubscribe send an email to graph-tool-le...@skewed.de
[graph-tool] Feature Request: Output dominator tree as GraphView
Hi, the dominator_tree function in graph_tool.topology outputs a vertex property map that codifies a graph. To use the other graph_tool algorithms, it would be beneficial to get the dominator_tree back as Graph (or better GraphView). Is there already a way to do this? Otherwise, how do you like the idea to implement it? A possible use case is it to check, if a dominates b. This would be the pseudo code, if dominator_tree returns a graph like object: dom_tree = graph_tool.topology.dominator_tree(graph, start, as_graph=True) try: next(graph_tool.topology.all_paths(a, b)) return True except StopIteration: return False This is without (the path search runs in Python, not that much LOCs but more difficult to understand in my opinion): dom_tree = graph_tool.topology.dominator_tree(graph, start, as_graph=True) while b: if a == b: return True b = dom_tree[b] return False Best, Gerion signature.asc Description: This is a digitally signed message part. ___ graph-tool mailing list graph-tool@skewed.de https://lists.skewed.de/mailman/listinfo/graph-tool
Re: [graph-tool] Mark all reachable Nodes
Nice, that works. Thank you.
Gerion
Am Freitag, 18. September 2020, 08:55:35 CEST schrieb Snehal Shekatkar:
> Looks like you want to find the out-component for a given vertex. Have a look
> at this:
>
> https://graph-tool.skewed.de/static/doc/topology.html#graph_tool.topology.label_out_component
>
> Snehal
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Friday, September 18, 2020 6:47 AM, Gerion Entrup
> wrote:
>
> > Hi,
> >
> > I need to find a way to label all reachable nodes in a directed graph
> > starting at a specific node. Is there a short way to do this?
> >
> > Currently I use this:
> >
> > graph = get_graph()
> > is_reachable = graph.new_vp("bool")
> > start_vertex = get_start_vertex()
> >
> > tc = gt.transitive_closure(graph)
> > is_reachable[start_vertex] = True
> > for node in tc.vertex(start_vertex).out_neighbors():
> > is_reachable[graph.vertex(node)] = True
> >
> >
> > This works, but seems quite inefficient, since I don't need the full
> > transitive closure (although I have multiple such start vertexes).
> > Another possibility should be a raw DFS but this needs far more LOC, since
> > it needs to stop when it backtracks and therefore needs a custom visitor.
> >
> > Gerion___
> > graph-tool mailing list
> > graph-tool@skewed.de
> > https://lists.skewed.de/mailman/listinfo/graph-tool
>
>
> ___
> graph-tool mailing list
> graph-tool@skewed.de
> https://lists.skewed.de/mailman/listinfo/graph-tool
>
___
graph-tool mailing list
graph-tool@skewed.de
https://lists.skewed.de/mailman/listinfo/graph-tool
[graph-tool] Mark all reachable Nodes
Hi,
I need to find a way to label all reachable nodes in a directed graph starting
at a specific node. Is there a short way to do this?
Currently I use this:
```
graph = get_graph()
is_reachable = graph.new_vp("bool")
start_vertex = get_start_vertex()
tc = gt.transitive_closure(graph)
is_reachable[start_vertex] = True
for node in tc.vertex(start_vertex).out_neighbors():
is_reachable[graph.vertex(node)] = True
```
This works, but seems quite inefficient, since I don't need the full transitive
closure (although I have multiple such start vertexes).
Another possibility should be a raw DFS but this needs far more LOC, since it
needs to stop when it backtracks and therefore needs a custom visitor.
Gerion
signature.asc
Description: This is a digitally signed message part.
___
graph-tool mailing list
graph-tool@skewed.de
https://lists.skewed.de/mailman/listinfo/graph-tool
Re: [graph-tool] Extract C++ edge from graph_tool.libgraph_tool_core.Edge
Am Montag, 7. September 2020, 22:04:36 CEST schrieb Gerion Entrup:
> Hi,
>
> I'm using graph-tool from both Python and C++. Normally, all works well
> with the dispatch function. But now I came to a situation, where I get
> an edge object (graph_tool.libgraph_tool_core.Edge) and want to use
> this from C++. Is there a way to do this?
>
> This is the same question as: I have a function `void do_stuff(PyObject* foo)`
> where `foo` is a `graph_tool.libgraph_tool_core.Edge`. Can I extract the
> boost::detail::adj_edge_descriptor somehow (or whatever is the correct
> edge type)?
>
> Kind regards
> Gerion
Found out by myself. It is actually fairly simple.
void extract_edge(PyObject* py_edge) {
graph_tool::EdgeBase& edge_base =
boost::python::extract(py_edge);
graph_tool::GraphInterface::edge_t edge = edge_base.get_descriptor());
}
Best,
Gerion
signature.asc
Description: This is a digitally signed message part.
___
graph-tool mailing list
graph-tool@skewed.de
https://lists.skewed.de/mailman/listinfo/graph-tool
[graph-tool] Extract C++ edge from graph_tool.libgraph_tool_core.Edge
Hi, I'm using graph-tool from both Python and C++. Normally, all works well with the dispatch function. But now I came to a situation, where I get an edge object (graph_tool.libgraph_tool_core.Edge) and want to use this from C++. Is there a way to do this? This is the same question as: I have a function `void do_stuff(PyObject* foo)` where `foo` is a `graph_tool.libgraph_tool_core.Edge`. Can I extract the boost::detail::adj_edge_descriptor somehow (or whatever is the correct edge type)? Kind regards Gerion signature.asc Description: This is a digitally signed message part. ___ graph-tool mailing list graph-tool@skewed.de https://lists.skewed.de/mailman/listinfo/graph-tool
Re: [graph-tool] fail to build for GCC 8.3.0
Am Montag, 1. Juni 2020, 12:56:51 CEST schrieb slitvinov: > I am on a shared supercomputer. It has only the following versions > gcc/6.1.0 > gcc/7.3.0 > gcc/8.1.0 > gcc/8.2.0 > gcc/8.3.0(default) > > Do I have any chance to build graph-tools? Maybe an older version? Maybe also Gentoo Prefix [1] is an option. In short: Compile all software in your user space again but get newer versions. Gerion [1] https://wiki.gentoo.org/wiki/Project:Prefix signature.asc Description: This is a digitally signed message part. ___ graph-tool mailing list graph-tool@skewed.de https://lists.skewed.de/mailman/listinfo/graph-tool
[graph-tool] Postdominator
Hi, I have seen the algorithm for the dominator tree in graph_tool. Is there an algorithm present that calculates the postdominator tree [1] as well? Best, Gerion [1] https://en.wikipedia.org/wiki/Dominator_(graph_theory)#Postdominance signature.asc Description: This is a digitally signed message part. ___ graph-tool mailing list graph-tool@skewed.de https://lists.skewed.de/mailman/listinfo/graph-tool
Re: [graph-tool] GraphView with lambda function
Am Mittwoch, 8. Januar 2020, 18:49:47 CET schrieb Tiago de Paula Peixoto:
> Am 08.01.20 um 15:33 schrieb Gerion Entrup:
> >
> >> Note that it would be completely unreasonable performance-wise to
> >> populate the filter property map lazily on demand.
> > Only kind of. It should be feasible to populate the property on demand
> > (only for the nodes/edges requested), but cache them and only recalculate
> > them if a graph change is done and only for the changed vertices/edges.
> > Then overall, it should be an O(N) operation again (with N = amount of
> > all vertices/edges, even the deleted ones).
>
> The point is that this would require the GraphView to know and be
> updated when the underlying graph changes, and it would tie _access_ to
> the filtered graph (even from C++) to function calls to the Python-side
> filter function.
>
> > A somewhat related but other question. Currently, I use lambdas only to
> > match for enum (int) values of properties, because my property can have
> > three variants instead of two, e.g.:
> > ```
> > from enum import IntEnum
> >
> > class TypeEnum(IntEnum):
> > Type_A = 1
> > Type_B = 2
> > Type_C = 3
> >
> > g = graph_tool.Graph()
> > g.vertex_properties['type'] = g.new_vp('int')
> >
> > v = g.add_vertex()
> >
> > g.vp.type[v] = TypeEnum.Type_C
> >
> > g_view = graph_tool.GraphView(g, vfilt=lambda x: g.vp.type[x] ==
> > TypeEnum.Type_C)
> > ```
>
> A much more efficient approach would be to use the numpy array interface
> to property maps, instead of a lambda function:
>
> g_view = GraphView(g, vfilt=g.vp.type.fa == TypeEnum.Type_C)
>
> The equal comparison is done in C, and hence is much faster.
>
> > This works with the behavior described above. I guess, the same filter
> > directly
> > in C++ would be really efficient. What do you think of adding C++-Filters?
> >
> > One possible syntax could be:
> > ```
> > from graph_tool.filter import Filter, Equal, Lesser
> > g_view1 = graph_tool.GraphView(vfilt=Filter(Equal(g.vp.type,
> > TypeEnum.Type_C)))
> > g_view2 = graph_tool.GraphView(vfilt=Filter(Equal(g.vp.type, 2)))
> > g_view3 = graph_tool.GraphView(vfilt=Filter(Lesser(g.vp.type, 3)))
> > ```
> > Of course they need some constraints:
> > 1. The comparison can only done between two properties or a constant and a
> > property
> > 2. Only basic operations (<, >, <=, >=, ==, !=) are possible. Maybe also
> > boolean
> > operations (and, or).
>
> All of this is completely unnecessary once you remember that the numpy
> array interface exists, which already implements all of this and more.
Nice, thank you for the hint! I was not aware of it. Then of course you are
right.
Best,
Gerion
signature.asc
Description: This is a digitally signed message part.
___
graph-tool mailing list
graph-tool@skewed.de
https://lists.skewed.de/mailman/listinfo/graph-tool
Re: [graph-tool] GraphView with lambda function
Am Montag, 6. Januar 2020, 15:11:53 CET schrieb Tiago de Paula Peixoto:
> Am 06.01.20 um 13:53 schrieb Gerion Entrup:
> > Hi,
> >
> > the documentation describes that GraphView can be given a unary function
> > to filter vertices or edges.
> >
> > I have tried that and it seems to fail. My GraphView has not the
> > expected vertices and edges.
> >
> > However, my assumption is that the filter is only evaluated one time
> > (at initialization).
> >
> > Let me make an example:
> >
> > ```
> > g = graph_tool.Graph()
> > a = graph_tool.GraphView(g, vfilt=...)
> >
> > fill_the_graph(g)
> > do_stuff_with(a) # <- here a does not contain any data
> > ```
> >
> > From the documentation, it seems that graph_tool constructs a property
> > from the filter function and uses this for filtering (therefore also
> > needing O(N)), but fill this property only on construction. Can you
> > mention this in the documentation as a hint or warning?
>
> Right, this is entirely expected behavior. It seems obvious to me in the
> documentation, but I will make it more explicit.
Thanks.
> Note that it would be completely unreasonable performance-wise to
> populate the filter property map lazily on demand.
Only kind of. It should be feasible to populate the property on demand
(only for the nodes/edges requested), but cache them and only recalculate
them if a graph change is done and only for the changed vertices/edges.
Then overall, it should be an O(N) operation again (with N = amount of
all vertices/edges, even the deleted ones).
> Note also that if you had modified `a` instead of `g` in your example,
> the filtering would behave as expected (i.e. new vertices or edges would
> appear in the graph view).
>
> > Maybe also a recalculate function for GraphView is meaningful that
> > evaluates the lambda function again.
>
> I don't think this is good design. GraphViews are supposed to be cheap
> objects that can be constructed on demand. If the filtering needs to be
> re-done, then a new GraphView should be constructed, maybe even composed
> from the older one. I.e. in your example you would re-create `a` after
> you had modified `g`.
Ok, this should make some additional allocations, but probably is
lightweight enough.
A somewhat related but other question. Currently, I use lambdas only to
match for enum (int) values of properties, because my property can have
three variants instead of two, e.g.:
```
from enum import IntEnum
class TypeEnum(IntEnum):
Type_A = 1
Type_B = 2
Type_C = 3
g = graph_tool.Graph()
g.vertex_properties['type'] = g.new_vp('int')
v = g.add_vertex()
g.vp.type[v] = TypeEnum.Type_C
g_view = graph_tool.GraphView(g, vfilt=lambda x: g.vp.type[x] ==
TypeEnum.Type_C)
```
This works with the behavior described above. I guess, the same filter directly
in C++ would be really efficient. What do you think of adding C++-Filters?
One possible syntax could be:
```
from graph_tool.filter import Filter, Equal, Lesser
g_view1 = graph_tool.GraphView(vfilt=Filter(Equal(g.vp.type, TypeEnum.Type_C)))
g_view2 = graph_tool.GraphView(vfilt=Filter(Equal(g.vp.type, 2)))
g_view3 = graph_tool.GraphView(vfilt=Filter(Lesser(g.vp.type, 3)))
```
Of course they need some constraints:
1. The comparison can only done between two properties or a constant and a
property
2. Only basic operations (<, >, <=, >=, ==, !=) are possible. Maybe also boolean
operations (and, or).
Best,
Gerion
signature.asc
Description: This is a digitally signed message part.
___
graph-tool mailing list
graph-tool@skewed.de
https://lists.skewed.de/mailman/listinfo/graph-tool
[graph-tool] GraphView with lambda function
Hi, the documentation describes that GraphView can be given a unary function to filter vertices or edges. I have tried that and it seems to fail. My GraphView has not the expected vertices and edges. However, my assumption is that the filter is only evaluated one time (at initialization). Let me make an example: ``` g = graph_tool.Graph() a = graph_tool.GraphView(g, vfilt=...) fill_the_graph(g) do_stuff_with(a) # <- here a does not contain any data ``` >From the documentation, it seems that graph_tool constructs a property from the filter function and uses this for filtering (therefore also needing O(N)), but fill this property only on construction. Can you mention this in the documentation as a hint or warning? Maybe also a recalculate function for GraphView is meaningful that evaluates the lambda function again. Best, Gerion signature.asc Description: This is a digitally signed message part. ___ graph-tool mailing list graph-tool@skewed.de https://lists.skewed.de/mailman/listinfo/graph-tool
[graph-tool] graph-tool package for Debian Sid
Hi, the package for sid currently seems uninstallable. It seems to depend on both, boost 1.67 (installed in sid) and boost 1.62 (not available). Can you fix it? Best, Gerion signature.asc Description: This is a digitally signed message part. ___ graph-tool mailing list graph-tool@skewed.de https://lists.skewed.de/mailman/listinfo/graph-tool
[graph-tool] Inverted keyword argument in GraphView
Hi, I have a graph with two types of nodes. This is specified via the boolean vertex property `is_typeA`. I currently have code like: ``` typeA_graph = graph_tool.GraphView(my_graph, vfilt=is_typeA) ``` I'd like to create an `typeB_graph` GraphView, too. The condition obviously is that the node is _not_ typeA. However, I don't see an inverted keyword argument like in the `set_vertex_filter()` function. Is there a possibility to get that? Best, Gerion signature.asc Description: This is a digitally signed message part. ___ graph-tool mailing list graph-tool@skewed.de https://lists.skewed.de/mailman/listinfo/graph-tool
[graph-tool] Filter in iterators
Hi, I often have this pattern in Python: ``` for vertex in mygraph.vertices(): if not mygraph.vp.is_foo[vertex]: continue do_stuff_that_uses_all_vertices() ``` `is_foo` is a boolean property. I know that there a vertex filters and GraphViews but in the loop body I need access to all vertices. Only the iterator should be filtered. Is there a way to specify a vertex filter only in the vertices iterator? Something like: ``` for vertex in mygraph.vertices(vfilt=mygraph.vp.is_foo): do_stuff_that_uses_all_vertices() ``` Of course, this would be nice in all iterators (edges(), out_edges(), ...) ;). Best, Gerion signature.asc Description: This is a digitally signed message part. ___ graph-tool mailing list graph-tool@skewed.de https://lists.skewed.de/mailman/listinfo/graph-tool
Re: [graph-tool] C++: Extract internal property maps of an GraphInterface object
Am Dienstag, 22. Oktober 2019, 23:43:26 CET schrieben Sie:
> Am 22.10.19 um 18:16 schrieb Gerion Entrup:
> > Hi,
> >
> > when using graph-tool from C++, you can use one or more PropertyMaps. In
> > the documentation they are always given as an extra argument. Since
> > graph-tool has internal PropertyMaps, is it possible to extract internal
> > PropertyMaps out of the GraphInterface object?
> >
> > In pseudo code (like in the documentation):
> > ```
> > void kcore_bind(GraphInterface& gi)
> > {
> > // Vertex property map of type int32_t
> > typedef typename vprop_map_t::type vprop_t;
> > vprop_t c =
> > boost::any_cast(gi.get_internal_vertex_property_map("foo"));
> >
> > gt_dispatch<>()
> > ([&](auto& g){ kcore_decomposition(g, c.get_unchecked()); },
> > all_graph_views()) (gi.get_graph_view());
> > }
> > ```
> >
> > Is there a way to simulate the `get_internal_vertex_property_map`
> > method?
>
> No, that's not possible, because the internal property maps are not
> stored in GraphInterface; they are kept only in the Python side of things.
>
> But you map pass the property map dictionary (e.g. g.edge_properties) to
> C++, and lookup from there.
Ok, thank you. I now do exactly that. Here is a minimal example in case
anyone else need it (I have not tested exactly this version, maybe some
errors are present). Maybe you also know a more elegant version.
```
#include
#include
#include
#include
#include
template
Property get_property(PyObject* prop_dict, const char* key) {
PyObject* prop = PyObject_GetItem(prop_dict, PyUnicode_FromString(key));
assert(prop != nullptr);
PyObject* prop_any = PyObject_CallMethod(prop, "_get_any", nullptr);
assert(prop_any != nullptr);
boost::python::extract get_property(prop_any);
assert(get_property.check());
try {
return boost::any_cast(get_property());
} catch (boost::bad_any_cast& e) {
std::cerr << "Bad any cast for attribute '" << key << "'" <<
std::endl;
throw e;
}
}
struct CPPGraph {
graph_tool::GraphInterface* graph;
typename graph_tool::vprop_map_t::type strprop;
typename graph_tool::vprop_map_t::type intprop;
typename graph_tool::vprop_map_t::type boolprop;
typename graph_tool::eprop_map_t::type edge_intprop;
typename graph_tool::eprop_map_t::type edge_boolprop;
CPPGraph(PyObject* graph) {
PyObject* py_graph = PyObject_GetAttrString(graph,
"_Graph__graph");
assert(py_graph != nullptr);
boost::python::extract
get_graph_interface(py_graph);
assert(get_graph_interface.check());
this->graph = &get_graph_interface();
PyObject* vprops = PyObject_GetAttrString(graph,
"vertex_properties");
assert(vprops != nullptr);
strprop = get_property(vprops, "strprop");
intprop = get_property(vprops, "intprop");
boolprop = get_property(vprops, "boolprop");
PyObject* eprops = PyObject_GetAttrString(graph,
"edge_properties");
assert(eprops != nullptr);
edge_intprop = get_property(eprops,
"edge_intprop");
edge_boolprop = get_property(eprops,
"bool_intprop");
}
};
```
signature.asc
Description: This is a digitally signed message part.
___
graph-tool mailing list
graph-tool@skewed.de
https://lists.skewed.de/mailman/listinfo/graph-tool
[graph-tool] C++: Extract internal property maps of an GraphInterface object
Hi,
when using graph-tool from C++, you can use one or more PropertyMaps. In
the documentation they are always given as an extra argument. Since
graph-tool has internal PropertyMaps, is it possible to extract internal
PropertyMaps out of the GraphInterface object?
In pseudo code (like in the documentation):
```
void kcore_bind(GraphInterface& gi)
{
// Vertex property map of type int32_t
typedef typename vprop_map_t::type vprop_t;
vprop_t c =
boost::any_cast(gi.get_internal_vertex_property_map("foo"));
gt_dispatch<>()
([&](auto& g){ kcore_decomposition(g, c.get_unchecked()); },
all_graph_views()) (gi.get_graph_view());
}
```
Is there a way to simulate the `get_internal_vertex_property_map`
method?
Gerion
signature.asc
Description: This is a digitally signed message part.
___
graph-tool mailing list
graph-tool@skewed.de
https://lists.skewed.de/mailman/listinfo/graph-tool
Re: [graph-tool] Accessibility from C++
Am Donnerstag, 10. Januar 2019, 23:51:29 CEST schrieb Tiago de Paula Peixoto: > Am 10.01.19 um 13:48 schrieb Gerion Entrup: > > So my question is: Is it possible to get the C++ graph object out of the > > Python graph object? Is it possible to fill the C++ graph object > > directly with nodes and edges? > > This is possible, and not very difficult. However, it's undocumented at the > moment. > > I'm working on some documentation, and I'll release it soon. > > > Another point is that I need to attach a pointer (or shared_ptr) to a > > custom C++ type to some nodes. The pointer does not need to be > > accessible or visible from Python. Is this possible in a simple way? > > (Of course I can workaround with an e.g. map of type (vertex id, > > pointer).) > > You can either use a property map of type int64_t, which is enough to hold > pointers. You can also use type python::object, which will hold whatever you > can express in python, inclusive custom classes. > > I have seen that you wrote some documentation [1]. Thank you! Gerion [1] https://graph-tool.skewed.de/static/doc/demos/cppextensions/cppextensions.html signature.asc Description: This is a digitally signed message part. ___ graph-tool mailing list graph-tool@skewed.de https://lists.skewed.de/mailman/listinfo/graph-tool
[graph-tool] Accessibility from C++
Hi, I need a graph library that is accessible for both Python and C++ together with a few other requirements. graph-tool seems to fulfill all this requirements. However, I don't find any information whether the library is usable from C++ code as well. My project consists out of several modules that are all aware a one main graph object. Each module can be written either in Python or C++. The modules itself are managed with some Python code. So my question is: Is it possible to get the C++ graph object out of the Python graph object? Is it possible to fill the C++ graph object directly with nodes and edges? Another point is that I need to attach a pointer (or shared_ptr) to a custom C++ type to some nodes. The pointer does not need to be accessible or visible from Python. Is this possible in a simple way? (Of course I can workaround with an e.g. map of type (vertex id, pointer).) Regards, Gerion signature.asc Description: This is a digitally signed message part. ___ graph-tool mailing list graph-tool@skewed.de https://lists.skewed.de/mailman/listinfo/graph-tool
