Closed jammy4536 closed 6 years ago
It was probably meant to be that way so that the radius value is consistent with the distance values returned by the search functions (which are squared distances in the L2 case). This behavior is also documented in the README.
Hi @jammy4536 , it's exactly as @kzampog said!
I must add that it's like that to prevent the costly and avoidable sqrt() in the cost function. Note that squaring the input search radius was not a direct alternative since it wouldn't be generic for other metrics. Also, this "feature" is publicized in the readme and has been around since the beginning, so changing it would break existing code. Cheers
Implementing the library in an SPH code, I realised that I needed to square the radius in order to find the particles within the radius I was interested about. So, in order to return particles within a radius H, I had to search H*H. Whilst easy enough once I knew about it, it doesn't make sense practically for the library to be so, and should be an extremely simple fix. Using KDTreeVectorofVectorsAdaptor for vector data setup.