[vtkusers] Bug in vtkBoostPrimMinimumSpanningTree?

[Jeff Baumes]

On Fri, May 21, 2010 at 1:54 PM, Thompson, David C <dcthomp at sandia.gov> wrote:
>>> I do have a question (not a criticism): you say what I did was more
>>> hackish but couldn't it also be faster and end up using less memory?
>>> By calling AddVertex once for each of N vertices, the STL container is forced
>>> to reallocate log(N) times and will end up allocating 2**(floor(log2(N))+1)
>>> entries instead of exactly N entries. If that could be a significant problem,
>>> would it be a good idea to add a call like "SetNumberOfVertices" to the
>>> mutable graph classes?
>>
>>I like the SetNumberOfVertices() idea, it would indeed be faster and
>>use less memory. What I meant was that vtkGraphInternals and
>>vtkVertexAdjacencyList are not meant to be manipulated directly, but
>>should be changed by using other vtkGraph API.
>
> What would the semantics of SetNumberOfVertices() be? Should it
> just adjust the GraphInternals->Adjacency ivar or should it also
> try to allocate memory for vertex point coordinates? Also, I'm
> unfamiliar with the distributed graph helper class, but it sounds
> like some attention should be paid to how SetNumberOfVertices
> works in parallel.

The convention is that AddVertex() does not change the size of the
points or vertex attribute arrays; that is assumed to be managed
separately. So I would think SetNumberOfVertices() could act the same
way. BTW, the points can remain NULL in a graph and be made on demand
the first time GetPoints() is called.

For distributed graphs (if the distributed helper is not NULL) I think
it should just produce an error that says the operation is not
supported on distributed graphs.

Jeff