On Tue, 2004-12-21 at 08:06, Francesc Altet wrote:
Hi,
I'm a bit lost with the next example:
In [28]: from numarray import * In [29]: a=arange(10) In [30]: a.iscontiguous() Out[30]: 1 In [31]: b=a[::2] In [32]: b.iscontiguous() Out[32]: 0
That seems to suggest that b shares the same data buffer than a. Indeed:
In [36]: a._data Out[36]: <memory at 0x082494d8 with size:0x00000028 held by object 0xb762c260 aliasing object 0x00000000> In [37]: b._data Out[37]: <memory at 0x082494d8 with size:0x00000028 held by object 0xb762c260 aliasing object 0x00000000>
At this point, I believe that _bytestride should be different on both arrays, but:
In [33]: a._bytestride Out[33]: 4 In [34]: b._bytestride Out[34]: 4
while I expected to find b._bytestride equal to 8.
Is that an error or a lack of understanding on my part?
Hi Francesc,
This is a difficult question for me, but I think the answer is that the use of _bytestride is very limited. _bytestride is used to compute the "natural" strides of an almost contiguous array, e.g. a field of a recarray. That is, given a bytestride and a shape, the strides of a field of a contiguous RecArray are implied.
However, once we start slicing (say in more than one dimension), _strides contains more and more information and is no longer implied by just the shape and bytestride but also by the history of slicing. From that perspective, it's not clear what _bytestride can be relied upon for in general or that it needs to be (or can be) kept up to date during slicing.
FWIW, looking into this uncovered a related bug in numarray.strings where I tried to use _bytestride to do a simple iteration over all the elements of an array... that doesn't work.
Regards, Todd