simply gives wrong results. It deletes vertices which are in the LC and have comp[v]==1 !!!
Instead, the much slower
G.remove_vertex_if(lambda v: comp[v] == 0)
call works just fine. The version of graph-tool is something close to 2.2.12, but I haven't seen any changes on git which seems to relate to this issue. It is quite scary that vertex deletion is somewhat unpredictable or I am doing something wrong here.
I cannot reproduce this problem. Do you have a concrete (and simple)
example of where this happens?
With "prune=True", the filtered vertices are not deleted, but rather
only the non-filtered vertices are copied. So in order for this to
somehow fail, there must be something wrong with the filtered graph you
are trying to copy.
BTW, why do you use 'lc' as the vfilt parameter of GraphView, instead of
'comp' directly?
Enclosed is a python script which produces the error. I will send the corresponding data file for the example to your personal address in order not to spam half a megabyte to the list. Moreover, when writing the example I encountered weird problems in the find_vertex function. I compile graph-tool without openmp, but apparently there are some issues here with it. When I use find_vertex, as commented out in the example, then the program crashes with this error:
dyld: lazy symbol binding failed: Symbol not found: _omp_get_num_threads
Referenced from: /Volumes/Data/sebi/.local/lib/python2.6/site-packages/graph_tool/util/libgraph_tool_util.so
Expected in: flat namespace
dyld: Symbol not found: _omp_get_num_threads
Referenced from: /Volumes/Data/sebi/.local/lib/python2.6/site-packages/graph_tool/util/libgraph_tool_util.so
Expected in: flat namespace
^CTrace/BPT trap
Hence, there seem to be some openmp issues even though I disabled it (or at least did not enable it during compilation). Not using find_vertex, but find_pink does work instead.
Enclosed is a python script which produces the error. I will send the
corresponding data file for the example to your personal address in
order not to spam half a megabyte to the list.
So, it seems the problem is not with the copying of the graph itself,
but rather with the _properties_. In the case you sent, the _names_ of
the vertices get wrongly copied, because the vertex index changed...
The fix is easy enough, and is already in git.
Moreover, when writing the example I encountered weird problems in the
find_vertex function. I compile graph-tool without openmp, but
apparently there are some issues here with it. When I use find_vertex,
as commented out in the example, then the program crashes with this
error:
dyld: lazy symbol binding failed: Symbol not found: _omp_get_num_threads
Referenced from: /Volumes/Data/sebi/.local/lib/python2.6/site-packages/graph_tool/util/libgraph_tool_util.so
Expected in: flat namespace
Strange, I cannot reproduce this here... Can you check if USING_OPENMP
is defined in your config.h after you run configure?
So, it seems the problem is not with the copying of the graph itself,
but rather with the _properties_. In the case you sent, the _names_ of
the vertices get wrongly copied, because the vertex index changed...
The fix is easy enough, and is already in git.
Great, this is very good news! Thanks. I will check it out in a minute.
Moreover, when writing the example I encountered weird problems in the
find_vertex function. I compile graph-tool without openmp, but
apparently there are some issues here with it. When I use find_vertex,
as commented out in the example, then the program crashes with this
error:
dyld: lazy symbol binding failed: Symbol not found: _omp_get_num_threads
Referenced from: /Volumes/Data/sebi/.local/lib/python2.6/site-packages/graph_tool/util/libgraph_tool_util.so
Expected in: flat namespace
Strange, I cannot reproduce this here... Can you check if USING_OPENMP
is defined in your config.h after you run configure?
Yes, it is defined as
#define USING_OPENMP 0
I then added --disable-openmp to the configure script and now it is
/* #undef USING_OPENMP */
So, the default seems to be to include the definition set to 0. I guess you check for definition of USING_OPENMP, but not if it is 0 or 1. Anyway, I will try compilation with the last configure output.