<div dir="ltr">Dear Sylvain and Paul,<br><br>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:<br><br>KDTree<MyCoordinateType> my_tree;<br>
my_tree.set_dimension(3);<br>// use the tree<br>my_tree.wipe();<br>my_tree.set_dimension(5);<br>// use it again.<br><br>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). <br>
<br>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.<br><br>For example:<br>
<br><i><b>enum</b> {KDTree_reconfigurable=0xDEADBEEF};<br><br><b>template</b> <<b>typename</b> __Val, <br> <b>typename</b> _Acc, <br> <b>typename</b> _Cmp<br> <b>typename</b> _Alloc><br>
<b>struct</b> KDTree<KDTree_reconfigurable,<br> __Val,<br> _Acc,<br> _Cmp<br> _Alloc> KDTree : <b>public</b> ... {<br><br>
};<br></i><br>Please let me know if you have any questions regarding the use of the suggested features.<br><br>Thanks,<br><br>Anju<br>
</div>