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

[Sturla Molden]

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 
0.16):

cdef class Test(object):
     def test(self):
         cdef int i = 2
         def print_i():
             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.


Sturla


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