Tim Hochberg wrote: >>> >>> >>> >>That would be easy to do. Right now the opcodes should work correctly >>on data that is spaced in multiples of the itemsize on the last axis. >>Other arrays are copied (no opcode required, it's embedded at the top >>of interp_body lines 64-80). The record array case apparently slips >>through the cracks when we're checking whether an array is suitable to >>be used correctly (interpreter.c 1086-1103). It would certainly not be >>any harder to only allow contiguous arrays than to correctly deal with >>record arrays. Only question I have is whether the extra copy will >>overwhelm the savings of that operating on contiguous data gives. The >>thing to do is probably try it and see what happens. >> >> > >OK, I've checked in a fix for this that makes a copy when the array is >not strided in an even multiple of the itemsize. I first tried copying >for all discontiguous array, but this resulted in a large speed hit for >vanilla strided arrays (a=arange(10)[::2], etc.), so I was more frugal >with my copying. I'm not entirely certain that I caught all of the >problematic cases, so let me know if you run into any more issues like this. > > > There is an ElementStrides check and similar requirement flag you can use to make sure that you have an array whose strides are multiples of it's itemsize.
-Travis ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
