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

Sturla Molden sturla@molden...
Mon Jul 16 14:20:09 CDT 2012

Den 16.07.2012 20:50, skrev Patrick Varilly:
>     Also observe that Cython has closures now, and you can nest Python
>     functions in Cython (and declaring them cpdef makes the call
>     almost as efficient as a cdef).
> By this, do you mean putting back the workhorse "traverse" methods 
> inside their respective function (e.g., query_ball_tree), like KDTree 
> does?  I would certainly like to do that (it would save passing in 
> tons of arguments in the recursive calls), but I tried the following 
> test and got the Cython error "C function definition not allowed here" 
> (here being "print_i()"):
> cdef class Test(object):
>     cpdef test():
>         cdef int i = 2
>         cpdef print_i():
>             print i
>         print_i()

Unfortunately it seems it is only allowed with Python functions (Cython 

cdef class Test(object):
     def test(self):
         cdef int i = 2
         def print_i():
             print i


> Thanks, this makes more sense.  I thought there might be a 
> circumstance when "inner_maxes = maxes" might create a copy of maxes, 
> but I now see that it will only check that ndim is 1 and dtype is 
> np.float64 before making the data available.

"inner_maxes" extends the PyArrayObject "maxes" with a PEP 3118 buffer, 
checks the assigned NumPy array "maxes", uses PyArray_DATA et al. to 
grab the data pointer, dimensions and strides, and unboxes them into the 
local scope. I does not make a copy.

This is also why the current "inner_maxes.data" is wrong, becuase this 
will access the "data" member in the PyArrayObject struct "maxes" (from 
which np.ndarray in Cython inherits) - and we should not touch that 
member directly.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20120716/7fe1ecf6/attachment-0001.html 

More information about the SciPy-Dev mailing list