Subject: Re: [boost] Gauging interest in new library re: multiscale/multigranular containers
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2011-06-07 17:00:10
Antony Polukhin wrote:
> It would be much easier to understand your library proposal, if you
> write some program using STL library and then write the same program
> using your library.
> Best regards,
It may not be that easy. From what I could gather, he is generating a tree data structure where intermediate nodes in the tree act as a representative element of the subtree when viewed at the level of coarseness that corresponds to the depth of the node in the tree. You can then iterate and query the tree at diverent levels of detail. I expect all the magic happens when you partition the data into sub trees. If you had some multi-modal data set then at the coarsest level you would see the modes of the data set as the representative elements for the sub trees that contain each cluster of data. I can think of many bad ways to do this, so I expect a good way would be very useful. Most likely it is application of standard statistical techniques. It is a little alarming that he seems to be coupling the general problem of how to define a generic tree data structure with the specific problem of multiscale partitioning/clustering algorithms. However, there seem to be a few wrinkles such as computing and storing the representative value in each intermediate node and iterating over intermediate nodes at a given depth instead of leaf nodes that may prove to be outside the scope of the generic tree library effort that is currently ongoing. In either case I think putting a healthy abstraction between the data structures and the algorithms would be a good design goal for this library proposal. I would suggest the author look at the BGL and think about the tree as a graph where the algorithms that operate on the tree are free functions that abstract away the tree data type.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk