[Numpy-discussion] reshape and ravel methods of arrays now return views or raise error
tim.hochberg at cox.net
Tue Mar 28 15:36:01 CST 2006
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...
More information about the Numpy-discussion