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

Sturla Molden sturla at molden.no
Sat Jul 14 19:29:14 EDT 2012


Den 15.07.2012 00:36, skrev Sturla Molden:
>
> Thanks. On Windows 64, query_pair returns bad results depending on the 
> size of the tree. I don't know why but Patrick's code hade the same 
> problem.
>

Which brings me to the other issue I'd like to discuss...

In its current state, Patrick's enhancement to cKDTree (IMHO) is close 
to unmaintainable. It might be 'fast', but it is not estetically nice 
looking code (no pun intended),  about 2500 lines of low-level C 
masquerading as Cython, very difficult to read and follow with respect 
to logic, it was full of bugs (and might still be), and still don't pass 
all the tests on my computer (even though I have been debugging it quite 
extensively).

Who is going to maintain it? Patrick? Ralph? Anne? (I am not 
volunteering...)

On the other hand, Anne's KDTree.py is an example of very beautiful 
Python code, and very easy to read and understand. KDTree is also robust 
and rather bug-free, after having been tested for quite a long time, and 
more or less feature-complete for a KDTree. But it is a bit slow, 
courtesy to Python...

How fast do we need it to be?

I think it might be better to just gently 'Cythonize' out the worst 
bottlenecks in KDTree.py, but leave the rest as it is. It might not be 
equally fast as Patrick's rewrite of cKDTree enhancement, but will be 
100 times easier to maintain, and probably "fast enough" for most usecases.

cKDTree was intended as a very fast kd-tree for nearest-neighbor 
queries. It was never intended as general-purpose kd-tree like, well, 
KDTree. Currently in SciPy master it is very "lean and mean" for its 
particular purpose. (It could still use some minor updating, such as 
64-bit support.)


I think at least this should be discussed before this major rewrite is 
pulled into SciPy master. I am not saying Patrick's rewrite is bad anbs 
should not be pulled into SciPy. But I don't think we should drop code 
into SciPy if it will never be properly maintained. It must be 
maintainable for years ahead.

Sturla







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20120715/ef6ab788/attachment.html>


More information about the SciPy-Dev mailing list