[SciPy-dev] Does it worth the trouble to support non contiguous array in C extensions ?
oliphant at ee.byu.edu
Tue Nov 28 18:18:03 CST 2006
David Cournapeau wrote:
> I am about to push in SVN the first version of a small package to
>compute lpc coefficients and lpc residual. I spent most of the time
>trying to understand how to handle non contiguous arrays in various
>parts of the C code...
> Now, I am wondering: does it really worth the trouble ? I noticed
>that most of the time, it is even faster (and obviously much easier to
>code/debug/test, and much more reliable) to just copy the data in a
>contiguous new array before processing with a C function expecting
> Is there a general policy regarding thoses issues for scipy ? Is it
>enough to write simple C extensions expecting contiguous arrays, and
>converting input to contiguous layout if necessary ?
There is no policy.
I'm of the opinion that strided arrays are often handled very
straightforwardly (except in Fortran) and so try to implement the
algorithm on strided arrays when possible. But, if it takes me too much
time to think about it, then I just force a contiguous array.
There is also the problem of byte-order and alignment that can occur for
a general NumPy array. Dealing with these always involves a copy (at
least of a chunk at a time). Therefore, at the very least you should
request an "aligned" array of a native data-type. Most, just extend
that request to a CONTIGUOUS array as-well (either FORTRAN or C-order).
I don't see it as a problem except for in memory-limited situations.
Lot's of code in NumPy itself forces a contiguous array in order to do
More information about the Scipy-dev