[Numpy-discussion] order flag again

[Tim Hochberg]

Travis Oliphant wrote:

> Tim Hochberg wrote:
>
>>
>> I notice that some methods of the array object, notably reshape, take 
>> the order flag. I think this is a mistake. At this point, x.reshape() 
>> should always be returning a view.
>
>
> The reason for the order flag is that it is needed to interpret what 
> you think a reshape operation should do.   How should the reshape 
> method think the data is stored.  That is the intended meaning of the 
> reshape flag.
> The FORTRAN flag on the array means the strides are actually 
> equivalent to FORTRAN order
> The CONTIGUOUS flag on the array means the strides are actually 
> equilvalent to C-CONTIGUOUS order.
>
> For a non-contiguous array, you may still have a sense of which 
> dimension you think ought to vary the fastest.  This kind of "sense" 
> is not needed all the time --- only on certain operations.  For these 
> operations, the order keyword needs to be present.
> To do what Tim suggests would require the addition of an additional 
> flag (call it the ORDER flag) on the array that would be carried 
> around to tell everybody how to think about this array as a 
> one-dimensional sequence of bytes.
> Such an approach is possible, of course. 

OK, so the order flag is needed anytime you might want to copy the data, 
correct?  What x.reshape() should do is still up in the air, but I feel 
strongly that it shouldn't be copying *sometimes*. I'm going to assume 
for the moment that my previous proposal regarding reshape and ravel 
gets adopted. We have three use cases:

    1. Want a reshaped view:
                b = a.reshape(*newshape)
    2. Want a reshaped copy
                b = a.ravel(*newshape=[-1], order=neworder)
    3. Want a reshaped view if possible or a copy:
                b = ascontiguousarray(a, order=neworder).reshape(*newshape)

Reshape doesn't need the order flag since it's not in the business of 
making copies. If you want a copy, use the new, revamped ravel which 
makes a copy and respects the order[*].

Now this third case is what I would consider an advanced usage as 
described in Travis' previous email. You want a contiguous array, 
probably flat, and you want it as efficiently as possible. However it's 
also a potential source of subtle bugs since you may or may not get a 
view. For this reason, I think that requiring ascontiguousarray to 
support this case is not only acceptable, it's a very good thing. As 
I've mentioned before, I'd like to sweep all of the operations that may 
return a view or a copy into a few asXXXarray functions so that these 
potentially problematic operations are localized and easily identifiable.

Regards,

-tim

[*] I've never been convinced of the need for ravel myself, since it's 
always been possible to write it efficiently some other way. However, 
it's more useful under the current proposal and I have no desire to get 
rid of it as long as it's behaviour stops being evil!