On 5/24/07, Albert Strasheim wrote:

Hello all

Me vs the flags again. I found another case where the flags aren't what I would expect:

In [118]: x = N.array(N.arange(24.0).reshape(6,4), order='F')

In [119]: x Out[119]: array([[ 0., 1., 2., 3.], [ 4., 5., 6., 7.], [ 8., 9., 10., 11.], [ 12., 13., 14., 15.], [ 16., 17., 18., 19.], [ 20., 21., 22., 23.]])

In [120]: x[:,0:1] Out[120]: array([[ 0.], [ 4.], [ 8.], [ 12.], [ 16.], [ 20.]])

# start=0, stop=1, step=2 In [121]: x[:,0:1:2] Out[121]: array([[ 0.], [ 4.], [ 8.], [ 12.], [ 16.], [ 20.]])

In [122]: x[:,0:1].flags Out[122]: C_CONTIGUOUS : False F_CONTIGUOUS : True OWNDATA : False WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False

The column is C_CONTIGUOUS also. Another example that should be both C_CONTIGUOUS and F_CONTIGUOUS is In [1]: ones(2)[:,newaxis].flags Out[1]: C_CONTIGUOUS : False F_CONTIGUOUS : False OWNDATA : False WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False I think indices that can only have the value 0 should be ignored in determining contiguity, but it seems we are not doing that at the moment. Another example: In [3]: array([1])[:,newaxis].flags Out[3]: C_CONTIGUOUS : False F_CONTIGUOUS : False OWNDATA : False WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False In [123]: x[:,0:1:2].flags

Out[123]: C_CONTIGUOUS : False F_CONTIGUOUS : False OWNDATA : False WRITEABLE : True ALIGNED : True UPDATEIFCOPY : False

In [124]: x[:,0:1].strides Out[124]: (8, 48)

In [125]: x[:,0:1:2].strides Out[125]: (8, 96)

The views are slightly different (as can be seen from at least the strides), but I'd expect F_CONTIGUOUS to be true in both cases. I'm guessing that somewhere this special case isn't being checked for, which translates into a "missed opportunity" for marking the view as contiguous. Probably not a bug per se, but I thought I'd mention it here.

Contiguous detection misses a few opportunities but it is hard to get all the cases right. But maybe we can improve it a bit more. Chuck