Practical additions to kdtree library
Prabhanjan Kambadur
pkambadu at indiana.edu
Tue Sep 30 04:16:56 UTC 2008
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
More information about the libkdtree-devel
mailing list