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

[Patrick Varilly]

Hi, Jake,

I agree that the bare KDTree is painfully slow, and deprecating it once
cKDTree has all its functionality sounds like the right thing to do.  I've
now finished porting over query_ball_tree and added it to the pull request,
and the rest (query_pairs, count_neighbors and sparse_distance_matrix)
shouldn't take too much longer, since they're conceptually very similar to
query_ball_tree.

That said, one good reason to keep the KDTree code alive, even if
deprecated, is that it's very readable.  This is useful if you want to know
how each of the algorithms work.

All the best,

Patrick

On Sun, Jul 8, 2012 at 4:10 PM, Jake Vanderplas <
vanderplas at astro.washington.edu> wrote:

>  Hi,
> 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.
>    Jake
>
>
> 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 listSciPy-Dev at scipy.orghttp://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20120709/c51b43aa/attachment.html>