Practical additions to kdtree library

[Prabhanjan Kambadur]

Dear Sylvain and Paul,

Thank you for the interest. Just to clarify, I did not envision a KDTree
that would change dimensionality on the fly. The use case would be more
like:

KDTree<MyCoordinateType> my_tree;
my_tree.set_dimension(3);
// use the tree
my_tree.wipe();
my_tree.set_dimension(5);
// use it again.

Here, MyCoordinateType can be dynamically reconfigured. Of course, the
method names could be more fitting :-). The reason I mention this is because
we use the KDTree as a primary data structure in the library. We support
reconfiguring our library through a similar mechanism. Being a staunch
supporter of the generic programming paradigm, I am all for compile-time
polymorphism. At the same time, I have been convinced by the scientists we
work with at the IBM T J Watson Research Center that the dimensionality
really is a feature of the data set, and as such, should be a runtime
parameter (in this particular case at least).

Actually, one could support setting the dimension both at compile-time and
at run-time. For example, one can imagine partial specialization of the
KDTree for a particular sentinel value of dimension.

For example:

*enum {KDTree_reconfigurable=0xDEADBEEF};

template <typename __Val,
                 typename _Acc,
                 typename _Cmp
                 typename _Alloc>
struct KDTree<KDTree_reconfigurable,
                         __Val,
                         _Acc,
                         _Cmp
                         _Alloc> KDTree : public ... {

};
*
Please let me know if you have any questions regarding the use of the
suggested features.

Thanks,

Anju
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/libkdtree-devel/attachments/20080930/1f9fc829/attachment.htm