[Numpy-discussion] reshape and ravel methods of arrays now return views or raise error

[Tim Hochberg]

Travis Oliphant wrote:

>
> It look's like Tim's arguments have won out for the most part.

Hooray. Now let's hope I'm right!

>
> The .reshape and .ravel methods of arrays now return views only or 
> raise an error if that is not possible.  However, both of these 
> methods still have an order argument because I don't think it is 
> prudent to have a.transpose().ravel() automatically column-scan --- 
> you have to tell ravel you want a Fortran-order result.

OK, I think I understand why you want the order flag now.  But isn't 
flat in a weird state now? All of the other reshape methods take an 
order parameter, but flat is inherently C-ordered, is it not?

Also, is it useful to view an array as fortran ordered?  I suppose if 
you are working with multidimensional Fortran data you want to keep it 
in the correct order. Still, something seems not quite right about the 
current state of affairs.

Let me ask a question about the order flag: does it mean anything for a 
noncontiguous array? As I interpret it, right now:

    CONTIGUOUS = True, FORTRAN = True => Strides are Fortran order
    CONTIGUOUS = True, FORTRAN = False=> Strides are C order
    CONTIGUOUS = False, FORTRAN = Any=> Matrix is Discontiguous

Is that correct? Or is it possible to have strides that neither C-order 
not Fortran-Order in a contiguous matrix? I'm trying to find a way to 
shoehorn an order flag in here without breaking anything, but  I don't 
think it'll fit. So you'd need a separate flag to indicate the 
reshape-order if one wanted to do that.

Mostly this would make life simpler for everyone, in normal use, the 
reshape-order flag gets set at array creation and everything just works. 
flat works properly, the order flag is only needed in construction. 
However, since the behaviour of the array is different with respect to 
reshape, you'd probably want to tag the repr somehow ('farray' instead 
of 'array' perhaps).

In practice, this would be essentially the same as having a sister class 
to ndarray that worked on Fortran ordered data. Everything would behave 
the same except for how reshape works.

I'm not sure if any of that is a good idea, but I'm not entirely 
convinced that the order flag, although a big improvement over what it 
replaced, is the best approach, so I'm musing.

> The reshape and ravel functions behave exactly as they used to (view 
> if possible, copy otherwise).  I don't think these functions should be 
> deprecated.  I don't think any of the functional interfaces should be 
> deprecated, either.

The good thing about functions is that I can always hot patch numpy with 
safer versions if I like. So I'll call this good. When I get around to 
it, I'll probably try patching in versions of reshape and transpose that 
lock either views or copies and see how that works out. I'll report back 
on how it goes.

>
> Part of the reason for the change is that it was not disruptive. None 
> of the NumPy code broke (except for a small piece of arrayprint) after 
> the change.  None of the SciPy code broke either (as far as I can tell).
> Hopefully we can put this to rest and move on to more important issues...

Hooray!

-tim