On 04/11/2012 12:58 AM, kavya wrote: > It did not do that. I anyway have a workaround for that.
Do what exactly? Handle the case where a property is defined for only
one graph? This is not yet implemented, I just mentioned it would be
perhaps a good idea.
> There's another issue I am encountering. Before doing a union of two
> graphs (g1, g2), I filter out 5 vertices in g1 which actually has 20
> nodes, leaving it with 15 vertices. The num_vertices() function
> returns the value 15 but the last node still has an index of 19. So
> after union, in the vertex list the graph g2 gets appended to the end
> of g1, which I assumed to be starting at index 15, but its at 20.
>
> I understand that the filter is reversible, but is there any way to
> re-arrange indices after a filtering operation so that there is a
> consistency with the vertex index and the number of vertices actually
> being considered now?
There is no way to change this and still have a vertex/edge filtering
which is at the same time very cheap (O(1)) and reversible. Thus, in
general, you cannot rely on a continuous vertex index range, if you have
filtered graphs.
What you can do is purge the filtered vertices with purge_vertices(), or
create a new unfiltered graph copy, i.e.
u = Graph(g, prune=True) # g is a filtered graph, u is not
In this way, the indexes of u.vertices() will be coherent with
num_vertices(), the way you want.
Cheers,
Tiago
--
Tiago de Paula Peixoto <[email protected]>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ graph-tool mailing list [email protected] http://lists.skewed.de/mailman/listinfo/graph-tool
