Dag Sverre Seljebotn wrote:
> First: This question (how to safely pass numpy arrays to C or Fortran
> code using Cython) actually comes up a lot. I'm wondering about perhaps
> making it a feature in Cython itself, borrowing a few syntax things from
> Fortran. (That would clean up a lot of code I'm using myself with Cython
> these days, so it could get realized in some months).
>
> Basically, perhaps one should allow declaring functions like this:
>
> cdef extern from "myheader.h":
> int myfunc(double[0:nrows, 0:ncols] data, int nrows, int ncols)
>
> (here data is really "double* data" in the C header) and then call it
> like this:
>
> cdef np.ndarray[double, ndim=2] arr = x
> myfunc(arr)
>
> nrows and ncols would be inferred from the shape of "arr", and Cython
> would transparently make sure contiguous memory is passed, making a copy
> if necesarry. (One could leave out the auto-nrows-ncols-bit for now though.)
>
> This would be backed by the buffer PEP and not be NumPy-specific.
>
> The thing lacking from the syntax above is how to specify whether data
> only needs to be passed in, or whether it is written to. "const
> double[...]" perhaps...
>
> Thoughts?
>
My thoughts are that I would expect such a functionality to be present,
yes.
> Then to your question:
>
>
>>
>> I realize that the mode is not really important for 1D arrays, but was
>> merely working my way up to matrices.
>>
>
> Mode is important for 1D arrays in this setting -- if you have strided
> memory, you cannot pass it on to C. I.e.
>
> x = arange(10)
> x = x[::2]
>
> Here no memory is changed on the second line, only a stride is set
> skipping every other element.
>
You are right, I hadn't considered that.
>> This requires the explicit use of a = zeros(n, numpy.float32) in the
>> calling Python code, which I was hoping to avoid.
>>
>
> You can also use arr.astype(), which will make a copy without filling
> with zeros. If that isn't flexible enough (cannot set C or Fortran
> mode?), one can also use np.empty, which only allocates memory and
> doesn't fill with zeros either.
>
>
The zeros part was just for demonstration, my point was that I had
choose the type of array that could be sent to the cython function, it
can not be determined at runtime except if I start juggling with several
temporary arrays.
>> My question is, can I use an alternative to
>> cdef float * p_a = <np.float32_t*>a.data
>>
>> in case the arrays have dtype float64, for instance, for simply writing
>> cdef float * p_a = <np.float64_t*>a.data
>>
>> doesn't help. Aka: is it possible to not make assumptions on the array
>> dtype? Using np.float without 32 or 64 works fine, but the data sent to
>> the C function is wrong. I guess float in C has the same precision as
>> float32 in numpy and double in C has the same precision as float64 in numpy?
>>
>
> If you simply write "np.ndarray[double] arr", you WILL get a runtime
> exception if arr is assigned something that does not contain a C double.
> So this is already handled automatically and you do not need to code
> the check yourself -- simply do
>
> cdef np.ndarray[double] a = x
> cdef double * p_a = <double*>a.data
>
> Yes, usually double == float64.
>
>
You mean that x as argument to the Cython function is given without
buffer arguments?
I want the users to be able to call the Cython function with any type of
numpy array, and to use the data from that array as float* for a C
function. This is what I do now:
def tridag(a, b):
cdef np.ndarray[double, ndim=2] a2 = a
cdef np.ndarray[double, ndim=2] b2 = b
but while this will work for float, float64 and double, this will not
work for float32. Is there any way at all to allow the user calling
tridag to sent all types of floting point number array (float32 as well
as float64)?
It might very well be that I am missing a point here, if so, I'm sorry.
Also, my questions might not be frased in the most obvious way, as I am
still trying to grasps new concepts. Static typing never was my favorite :-)
ilmar
_______________________________________________
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
