[Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering

Chris Barker - NOAA Federal chris.barker@noaa....
Thu Apr 4 11:21:07 CDT 2013

On Wed, Apr 3, 2013 at 6:13 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
>> We all agree that 'order' is used with two different and orthogonal
>> meanings in numpy.

well, not entirely orthogonal -- they are the some concept, used in
different contexts, so there is some benefit to their having
similarity. So I"d advocate for using the same flag names in any case
-- i.e. "C" and "F" in both cases.

>> I think we are now more or less agreeing that:
>> np.reshape(a, (3, 4), index_order='F')
>> is at least as clear as:
>> np.reshape(a, (3, 4), order='F')


The trick is:

np.reshape(a, (3, 4), index_order='A')

which in mingling index_order and memory order......

> I believe our job here is to come to some consensus.


> In that spirit, I think we do agree on these statements above.

with the caveats I just added...

> Now we have the cost / benefit.
> Benefit : Some people may find it easier to understand numpy when
> these constructs are separated.
> Cost : There might be some confusion because we have changed the
> default keywords.
> Benefit
> -----------
> What proportion of people would find it easier to understand with the
> order constructs separated?

It's not just numbers -- it's depth of confusion -- if, once you "get"
it, you remember it for the rest of your numpy use, then it's not big
deal. However, if you need to re-think and test every time you
re-visit reshape or ravel, then there's a significant benefit.

We are talking about "separating the concepts", but I think it takes
more than a keyword change to do that -- the 'A' and 'K' flags mingle
the concpets, and are going to be confusing with new keywords -- maybe
even more so (it says index_order, but the docstring talks about
memory order)

Does anyone think we should depreciate the 'A' and 'K' flags?

Before you answer that -- does anyone see a use case for the 'A' and
'K' flags that can't be reasonably easily accomplished with .view() or
asarray() or ???

if we get rid of the 'A' and 'K' flags, I think think the docstring
will be more clear, and there may be less need for two names for the
different "order" concepts (though we could change the flags and the

> The ravel docstring would looks something like this:
> index_order : {'C','F', 'A', 'K'}, optional
>     ...   This keyword used to be called simply 'order', and you can
> also use the keyword 'order' to specify index_order (this parameter).
> The problem would then be that, for a while, there will be older code
> and docs using 'order' instead of 'index_order'.  I think this would
> not cause much trouble.  Reading the docstring will explain the
> change.  The old code will continue to work.

not a killer, I agree.



Christopher Barker, Ph.D.

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception


More information about the NumPy-Discussion mailing list