April 2012 - graph-tool - archives.skewed.de

Re: [graph-tool] subgraph_isomorphism on filtered graph / GraphView => segfaults
by Ingo Lohmar 10 Apr '12

10 Apr '12

> I have fixed this now in the git version, please check it out. > Thanks for noticing this and providing a simple example! Hi Tiago, Thank you very much for your super-fast fix! I checked the git version, and I do not get any segfaults anymore. Back to finding bugs in my code for now :) Best, Ingo

1 0

How to access properties (stackoverflow question)?
by Mikhail Spivakov 09 Apr '12

09 Apr '12

Hello Tiago and everyone, I'd like to bring your attention to a question on stackoverflow, which I'd also like to know the answer to: http://stackoverflow.com/questions/9526827/graph-tool-how-to-access-propert… In particular, this bit: "How do I get an object [vertex] with a certain title back from the graph ? One way seems to be to create a vertex filter using graph.set_edge_filter(...) and apply that - which seems a pretty expensive operation considering all I want is to get one single object back. I really don't want to maintain my own object title / vertex index mapping as IMO, that is one of the tasks of the graph". Consider, for example, the following simple situation: I've got an existing set of vertices and then obtain information on edges between them from somewhere, which may sometimes also involve vertices not yet in the graph. In networkx, I would simply do: add_edge(x,y), where x and y are vertex names (that have or have not been defined a priori using add_node(x)). Is there a straightforward way to do the same in graph_tool? Thanks, Mikhail

2 1

subgraph_isomorphism on filtered graph / GraphView => segfaults
by Ingo Lohmar 08 Apr '12

08 Apr '12

Dear Tiago, Thank you for your great work on this very useful library! I have played with it for a project over the last few days, and today I have discovered a real roadblock: subgraph_isomorphism seems to segfault (at least very often, have not found any pattern yet) when searching on a graph with filtered vertices (or the equivalent GraphView) --- this has never occurred to me for an unfiltered graph. Here is a minimal example: ##### from graph_tool.all import * G = price_network(100) sub = Graph() sub.add_vertex(3) sub.add_edge(sub.vertex(0), sub.vertex(1)) sub.add_edge(sub.vertex(1), sub.vertex(2)) # WORKS FINE: print G print subgraph_isomorphism(sub, G, random=False) # FILTER FOR "OLDEST" VERTICES vmap = G.new_vertex_property("bool") for i in range(20): vmap[G.vertex(i)] = True # EITHER THIS... G.set_vertex_filter(vmap) print G print subgraph_isomorphism(sub, G, random=False) # segmentation fault! G.set_vertex_filter(None) # OR THIS... H = GraphView(G, vfilt=vmap) print H print subgraph_isomorphism(sub, H, random=False) # segmentation fault! ##### I am using the latest release from the oneiric repo, here is the show_config() output: ##### version: 2.2.15 (commit b435362a, Wed Aug 31 23:11:56 2011 +0200) gcc version: 4.6.1 compilation flags: -I/usr/include/python2.7 -I/usr/include -I/usr/lib/pymodules/python2.7/nu mpy/core/include/numpy -I/usr/lib/python2.7/dist-packages/scipy -g -O2 -g -O2 -Wall -Wall -ft emplate-depth-150 -Wno-deprecated -Wno-unknown-pragmas -O99 -fvisibility=default -fvisibility -inlines-hidden -fopenmp -Wl,-Bsymbolic-functions -L/usr/lib/python2.7 -lpython2.7 install prefix: /usr python dir: /usr/lib/python2.7/dist-packages graph filtering: True openmp: True uname: Linux acer 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 20:45:39 UTC 2012 x86_64 ##### Any help/ideas on this would be greatly appreciated! Please let me know whether/how I can provide any more information or test results to resolve this issue. Kind regards, Ingo

2 1

Re: [graph-tool] Graph-tool make error
by Mikhail Spivakov 07 Apr '12

07 Apr '12

> I'm trying to compile graph-tool on CentOS 5.4 with boost 1.49.0, and I'm getting two errors Just thought I'd upload the full output of make, although it looks scary: www.ebi.ac.uk/~spivakov/makelog_graph_tool.txt Would very much appreciate if you could look into this. Many thanks! Mikhail On Thu, Apr 5, 2012 at 12:37 PM, Mikhail Spivakov <spivakov(a)ebi.ac.uk> wrote: > Hello! > > I'm trying to compile graph-tool on CentOS 5.4 with boost 1.49.0, and > I'm getting the following two errors: > > boost/property_map/property_map.hpp:354: error: no match for > 'operator[]' in '(const boost::unchecked_vector_property_map<long > double, boost::adj_list_edge_property_map<boost::bidirectional_tag, > long unsigned int, long unsigned int&, long unsigned int, > boost::property<boost::edge_index_t, long unsigned int, > boost::no_property>, boost::edge_index_t> >&)((const > boost::unchecked_vector_property_map<long double, > boost::adj_list_edge_property_map<boost::bidirectional_tag, long > unsigned int, long unsigned int&, long unsigned int, > boost::property<boost::edge_index_t, long unsigned int, > boost::no_property>, boost::edge_index_t> >*)(& pa))[k]' > > /homes/spivakov/n/boost_1_49_0/boost/property_map/property_map.hpp:361: > error: no match for 'operator[]' in '(const > boost::unchecked_vector_property_map<double, > boost::adj_list_edge_property_map<boost::bidirectional_tag, long > unsigned int, long unsigned int&, long unsigned int, > boost::property<boost::edge_index_t, long unsigned int, > boost::no_property>, boost::edge_index_t> >&)((const > boost::unchecked_vector_property_map<double, > boost::adj_list_edge_property_map<boost::bidirectional_tag, long > unsigned int, long unsigned int&, long unsigned int, > boost::property<boost::edge_index_t, long unsigned int, > boost::no_property>, boost::edge_index_t> >*)(& pa))[k]' > > As I understand, it's related to a problem with boost library itself > (http://www.digipedia.pl/usenet/thread/14158/17481/#post17481) but > I'm wondering if there is any workaround. > > Many thanks, > Mikhail

2 2

Re: [graph-tool] graph-tool make error
by Mikhail Spivakov 06 Apr '12

06 Apr '12

Hi Tiago, Many thanks for your reply - I've compiled with boost 1.46.1 for now. Got lots of very obscure warnings (you know what boost's gcc output is like), but no errors. Best, Mikhail --------------------------------------------------------------------- Date: Thu, 05 Apr 2012 14:21:08 +0200 From: Tiago de Paula Peixoto <tiago(a)skewed.de> To: Main discussion list for the graph-tool project <graph-tool(a)skewed.de> Subject: Re: [graph-tool] Graph-tool make error Message-ID: <4F7D8E34.1010505(a)skewed.de> Content-Type: text/plain; charset="utf-8" Hi Mikhail, On 04/05/2012 01:49 PM, Mikhail Spivakov wrote: > I'm trying to compile graph-tool on CentOS 5.4 with boost 1.49.0, and > I'm getting the following two errors: [...] > > As I understand, it may be related to a problem with boost library itself > (https://bugs.kde.org/show_bug.cgi?id=287772) but > I'm wondering if there is any workaround. Yes, there is a problem with boost 1.49. They changed some things which broke compatibility. I'll provide a fix for this soon. In the meantime, you should probably just use boost 1.48. Cheers, Tiago -- Tiago de Paula Peixoto <tiago(a)skewed.de>

1 0

Graph-tool make error
by Mikhail Spivakov 05 Apr '12

05 Apr '12

Hello! I'm trying to compile graph-tool on CentOS 5.4 with boost 1.49.0, and I'm getting the following two errors: boost/property_map/property_map.hpp:354: error: no match for 'operator[]' in '(const boost::unchecked_vector_property_map<long double, boost::adj_list_edge_property_map<boost::bidirectional_tag, long unsigned int, long unsigned int&, long unsigned int, boost::property<boost::edge_index_t, long unsigned int, boost::no_property>, boost::edge_index_t> >&)((const boost::unchecked_vector_property_map<long double, boost::adj_list_edge_property_map<boost::bidirectional_tag, long unsigned int, long unsigned int&, long unsigned int, boost::property<boost::edge_index_t, long unsigned int, boost::no_property>, boost::edge_index_t> >*)(& pa))[k]' /homes/spivakov/n/boost_1_49_0/boost/property_map/property_map.hpp:361: error: no match for 'operator[]' in '(const boost::unchecked_vector_property_map<double, boost::adj_list_edge_property_map<boost::bidirectional_tag, long unsigned int, long unsigned int&, long unsigned int, boost::property<boost::edge_index_t, long unsigned int, boost::no_property>, boost::edge_index_t> >&)((const boost::unchecked_vector_property_map<double, boost::adj_list_edge_property_map<boost::bidirectional_tag, long unsigned int, long unsigned int&, long unsigned int, boost::property<boost::edge_index_t, long unsigned int, boost::no_property>, boost::edge_index_t> >*)(& pa))[k]' As I understand, it may be related to a problem with boost library itself (https://bugs.kde.org/show_bug.cgi?id=287772) but I'm wondering if there is any workaround. Many thanks, Mikhail -- Mikhail Spivakov, PhD European Bioinformatics Institute Hinxton, Cambridgeshire, UK

2 1

astar_search and weights as Python objects
by Guillaume Lemaître 05 Apr '12

05 Apr '12

Hi, I'm trying to use the astar_search algorithm for my own problem, and I get the following error: ====> File "/usr/lib64/python2.7/site-packages/graph_tool/search/__init__.py", line 125, in wrap ret = func(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/graph_tool/search/__init__.py", line 1528, in astar_search compare, combine, zero, infinity, h) RuntimeError: No static implementation was found for the desired routine. This is a graph_tool bug. :-( Please follow but report instructions at http://graph-tool.skewed.de. What follows is debug information. Graph view: boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, boost::no_property, boost::property<boost::edge_index_t, unsigned long, boost::no_property>, boost::no_property, boost::listS>* Action: boost::_bi::bind_t<void, do_astar_search, boost::_bi::list9<boost::arg<1>, boost::_bi::value<unsigned long>, boost::arg<2>, boost::_bi::value<std::pair<boost::any, boost::any> >, boost::arg<3>, boost::_bi::value<graph_tool::AStarVisitorWrapper>, boost::_bi::value<std::pair<graph_tool::AStarCmp, graph_tool::AStarCmb> >, boost::_bi::value<std::pair<boost::python::api::object, boost::python::api::object> >, boost::_bi::value<std::pair<boost::python::api::object, boost::python::api::object> > > > Arg 1: boost::checked_vector_property_map<boost::python::api::object, boost::vec_adj_list_vertex_id_map<boost��perty, unsigned long> > Arg 2: boost::checked_vector_property_map<boost::python::api::object, boost::adj_list_edge_property_map<boost::bidirectional_tag, unsigned long, unsigned long&, unsigned long, boost::property<boost::edge_index_t, unsigned long, boost::no_property>, boost::edge_index_t> > <==== Please note this is not always the same error message. How did I got this ? I' ve defined a own cost type for edge weights and distances: class Cost(object): nb_turns = 0 distance = 0 def __add__(self, other): """so that astar_search.combine may work""" ... def __cmp__(self, other): """so that astar_search.compare may work""" ... def __hash__(self, other): """so that Cost equality is done by value""" ... This could have been a tuple, but I thought it was more elegant to define a named type after it (even if less efficient?) I also defined an INFINITE_COST: >>> INFINITE_COST = Cost() >>> INFINITE_COST.nb_turns = float("inf") >>> INFINITE_COST.distance = float("inf") I inspired myself from the HammingVisitor example (http://projects.skewed.de/graph-tool/doc/search_module.html#graph_tool.sear…) to build up the graph during its exploration for my own problem. Compared to this example, I thought that I have to call the astar_search procedure with zero and infinity attributes defined, respectively with zero = Cost() infinity = INFINITE_COST I *suppose* this could be the main reason for such an error message to rise up. Alternatively, the HammingVisitor example works perfectly well (after replacing 'array' by 'list') on my computer. How could I tackle down the real issue? Maybe using classes for weights instead of predefined types is not recommended? Regards, Guillaume -- Si les dauphins étaient si malins, ils ne vivraient pas dans des igloos.

2 6