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 <tiago@skewed.de>