David Cournapeau wrote:
Hi,
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. -Travis