You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Are there any plans to add the other query methods available in scipy's KDTree implementation? Is it possible with pykdtree's method? How difficult would it be and what kind of headaches could you imagine?
It wasn't something I had considered. Would it make an important difference to some known use cases or is it more nice to have compatibility?
Looking at the scipy code there's some C++ code to make sense of but nothing complex just time consuming. There would also be a benchmarking effort to make sure scipy is defeated properly. The cKDTree implementations are not parallelized so that would have to be added (can be trivial or really difficult depending on implementation details)
Good points. This was for use cases that @leouieda and I were discussing when he made a PR for his "verde" library that basically meant the user had to pick if they wanted a scipy or pykdtree KDTree based on what methods they may call in the future.
Hi @storpipfugl, the PR that @djhoese mentioned is fatiando/verde#165. I mostly need query_ball_point as well but I could imagine needing some other methods in the future. I can run some benchmarks on my code if you need.
Are there any plans to add the other query methods available in scipy's KDTree implementation? Is it possible with pykdtree's method? How difficult would it be and what kind of headaches could you imagine?
See the bottom of this page for a list of the query methods: https://docs.scipy.org/doc/scipy/reference/generated/scipy.spatial.cKDTree.html
The text was updated successfully, but these errors were encountered: