If we have
np.ndarray[double, ndim=2] array
then (array[row,0]) and (array[0,column]) is a trick to get a pointer
to a row or a column.
Strangely, the expression is only allowed in cdef functions. In Python
callable functions, it produces the error message Cannot take address
of Python
Sturla Molden, 25.10.2009 09:58:
If we have
np.ndarray[double, ndim=2] array
then (array[row,0]) and (array[0,column]) is a trick to get a pointer
to a row or a column.
Strangely, the expression is only allowed in cdef functions. In Python
callable functions, it produces the
Buffers/ndarrays declared with mode=c or mode=fortran will only
accept C or Fortran contiguous buffers. But the generated C code does
not assume more than contiguity in the fastest varying dimension.
With
a = np.zeros((10,10))
b = a[::2, :]
the code generated for np.ndarray[double,
Stefan Behnel skrev:
Could you provide complete code examples for the two functions you use?
Sure... I was fiddling with an experimental re-write (or clean-up) of
SciPy's ckdtree. Here it is.
Sturla
# Rewrite by Sturla Molden, Oct 2009
# Changes are public domain.
# Copyright
Hi all,
the wiki has an enhancement page on better C array support.
http://wiki.cython.org/enhancements/arraytypes
Note that this is not about SIMD operations and whatnot, just about plain
int[] x
The page mentions things like dynamic memory allocation happening
automatically behind
On Sun, Oct 25, 2009 at 11:33 AM, Stefan Behnel stefan...@behnel.de wrote:
Hi all,
the wiki has an enhancement page on better C array support.
http://wiki.cython.org/enhancements/arraytypes
Note that this is not about SIMD operations and whatnot, just about plain
int[] x
The page
Stefan Behnel skrev:
The page mentions things like dynamic memory allocation happening
automatically behind the scenes, so that
cdef int a[runtime_size]
would locally allocate memory, as would subsequent slicing, I guess.
This by the way, can be deferred to the C or C++ compiler:
Lisandro Dalcin, 25.10.2009 17:04:
So you could support the lhs = rhs[slice] when lhs is a
pyobject, but generate a Cython compile error if lhs is a C
pointer/array type (perhaps making exceptions for the case of
char[]/char*) until auto mem alloc is implemented.
Yes, that occurred to me,
I just realized the Python does not provide a fast way of popping an
item from a list, just append. I.e. there is a PyList_Append, but no
PyList_Pop. And in Python's code for _listobject.c, the function listpop
is declared static. When using a list as a stack (a common case for
Python lists),
On Sun, Oct 25, 2009 at 2:39 PM, Sturla Molden stu...@molden.no wrote:
I just realized the Python does not provide a fast way of popping an
item from a list, just append. I.e. there is a PyList_Append, but no
PyList_Pop. And in Python's code for _listobject.c, the function listpop
is declared
Sturla Molden wrote:
Buffers/ndarrays declared with mode=c or mode=fortran will only
accept C or Fortran contiguous buffers. But the generated C code does
not assume more than contiguity in the fastest varying dimension.
With
a = np.zeros((10,10))
b = a[::2, :]
the code generated
Stefan Behnel wrote:
Hi all,
the wiki has an enhancement page on better C array support.
http://wiki.cython.org/enhancements/arraytypes
Note that this is not about SIMD operations and whatnot, just about plain
int[] x
The page mentions things like dynamic memory allocation
Stefan Behnel wrote:
This would be a rather straight forward thing to support:
cdef char* s = ...
py_s = s[:30]
It would translate directly to a call to PyString_FromStringAndSize(),
which is a rather often requested feature IMO. All other base types would
return a
Dag Sverre Seljebotn, 25.10.2009 21:26:
Stefan Behnel wrote:
This would be a rather straight forward thing to support:
cdef char* s = ...
py_s = s[:30]
It would translate directly to a call to PyString_FromStringAndSize(),
which is a rather often requested feature IMO. All other
14 matches
Mail list logo
