[SciPy-Dev] Enhancements to scipy.spatial.cKDTree

Jake Vanderplas vanderplas@astro.washington....
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
> https://github.com/scipy/scipy/pull/262
> 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 
> ideal.
> 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,
> Patrick
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20120708/33262b53/attachment.html 

More information about the SciPy-Dev mailing list