[SciPy-dev] Does it worth the trouble to support non contiguous array in C extensions ?

Travis Oliphant 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 
>contiguous array...
>    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 
the processing.


More information about the Scipy-dev mailing list