Open bschlenk opened 7 years ago
The original plan was to provide nearest-N neighbor search, which is why I had these functions in the header file. I didn't bother to implement them initially, as I happened not to use them in the project for which I originally wrote libkdtree. My recollection is that at that point I started a dummy implementation just for completeness of the API; something like collect nearest neighbors with increasing distances until I have N of them and then sort them before returning the result set. But then I decided that it would be silly to do that, and to left it commented out until I need that feature, at which point I'll just implement it properly. The rest is history :)
TL;DR: the commented code is no good. needs to be thrown away and be implemented correctly from scratch.
hello,i find that something wrong with find_nearest method,One of the reasons why kdtree saves time is to use the distance from the nearest point to the point to be queried as the radius. If there is no intersection with the hyperplane, you do not need to go to the sibling nodes again. However, this method does not have this crucial step。
the method find_nearest_n is also wrong,the same to the method of find_nearest。and kd_nearest_i method is the idea of kdtree
find_nearest_n does not exist, so I don't understand what you mean by saying that it's wrong. That's why this enhancement request was opened in the first place.
About the find_nearest function. If you wish to report an issue about, please start a new one. This is an enhancement request for adding the missing kd_nearest_n function.
Any messages irrelevant to this enhancment request will be deleted.
@jtsiomb ok,i will start a new one about find_nearest function
Just curious as to why the kd_nearest_n methods are commented out? Are they methods that could be made to work with a little work, or is the reason they are commented out because they are broken?