[SciPy-Dev] Enhancements to scipy.spatial.cKDTree
Sun Jul 8 10:10:25 CDT 2012
Thanks for the PR, Patrick.
Regarding the interface change: I personally have never used KDTree: in
my experience it's simply too slow to do anything meaningful. cKDTree
is very fast in some applications, however, and I have used it in
research and in several packages which depend on scipy. If we're going
to change an interface, we should change KDTree rather than cKDTree. It
will likely affect fewer people.
I wonder if, in addition, we should think about deprecating KDTree. It
would be less confusing in the long run to have only the one object
available, especially if the last few pieces of functionality can be
ported to cKDTree.
On 07/06/2012 04:36 PM, Patrick Varilly wrote:
> Dear all,
> I've recently been putting together a wrapper around
> scipy.spatial.KDTree to transparently handle periodic boundary
> conditions that are common in analyzing the results of molecular
> simulations (https://github.com/patvarilly/periodic_kdtree). In the
> process, I've started enhancing some of scipy.spatial.cKDTree by
> adding a Cythonized query_ball_point method. A pull request is here
> Two things I have noticed are that the interfaces to the KDTree and
> cKDTree query() methods aren't quite in line, and that it wouldn't
> take a whole lot of extra effort to Cythonize the rest of KDTree. The
> innards of the code could also be reorganized a bit to make it easier
> for other people to extend these classes. For the periodic kd-trees,
> for example, I had to jump through a few hoops, and ended up with two
> different codebases for wrapping KDTree's and cKDTree's, which is not
> I was writing to gauge if there's actually any interest in cleaning up
> KDTrees and Cythonizing the rest of the KDTree interface. If so, I'd
> be willing to put a bit of effort into doing so. A delicate question
> that comes up is whether anyone relies on the subtle differences
> between KDTree.query() and cKDTree.query() (e.g., passing k = None),
> so that bringing the two interfaces exactly in line with each other
> would break existing code. How is this issue usually dealt with?
> All the best,
> SciPy-Dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SciPy-Dev