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

Matthew Brett matthew.brett at gmail.com
Sat Mar 30 19:42:38 EDT 2013


On Sat, Mar 30, 2013 at 4:31 PM, Bradley M. Froehle
<brad.froehle at gmail.com> wrote:
> On Sat, Mar 30, 2013 at 3:21 PM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
>> On Sat, Mar 30, 2013 at 2:20 PM,  <josef.pktd at gmail.com> wrote:
>> > On Sat, Mar 30, 2013 at 4:57 PM,  <josef.pktd at gmail.com> wrote:
>> >> On Sat, Mar 30, 2013 at 3:51 PM, Matthew Brett
>> >> <matthew.brett at gmail.com> wrote:
>> >>> On Sat, Mar 30, 2013 at 4:14 AM,  <josef.pktd at gmail.com> wrote:
>> >>>> On Fri, Mar 29, 2013 at 10:08 PM, Matthew Brett
>> >>>> <matthew.brett at gmail.com> wrote:
>> >>>>>
>> >>>>> Ravel and reshape use the tems 'C' and 'F" in the sense of index
>> >>>>> ordering.
>> >>>>>
>> >>>>> This is very confusing.  We think the index ordering and memory
>> >>>>> ordering ideas need to be separated, and specifically, we should
>> >>>>> avoid
>> >>>>> using "C" and "F" to refer to index ordering.
>> >>>>>
>> >>>>> Proposal
>> >>>>> -------------
>> >>>>>
>> >>>>> * Deprecate the use of "C" and "F" meaning backwards and forwards
>> >>>>> index ordering for ravel, reshape
>> >>>>> * Prefer "Z" and "N", being graphical representations of unraveling
>> >>>>> in
>> >>>>> 2 dimensions, axis1 first and axis0 first respectively (excellent
>> >>>>> naming idea by Paul Ivanov)
>> >>>>>
>> >>>>> What do y'all think?
>> >>>>
>> >>>> I always thought "F" and "C" are easy to understand, I always thought
>> >>>> about
>> >>>> the content and never about the memory when using it.
>> >>
>> >> changing the names doesn't make it easier to understand.
>> >> I think the confusion is because the new A and K refer to existing
>> >> memory
>> >>
>> I disagree, I think it's confusing, but I have evidence, and that is
>> that four out of four of us tested ourselves and got it wrong.
>> Perhaps we are particularly dumb or poorly informed, but I think it's
>> rash to assert there is no problem here.
> I got all four correct.

Then you are smarted and or better informed than we were.  I hope you
didn't read my explanation before you tested yourself.

Of course if you did read my email first I'd expect you and I to get
the answer right first time.

If you didn't read my email first, and didn't think too hard about it,
and still got all the examples right, and you'd get other more
confusing examples right that use reshape,  then I'd add you as a data
point on the other side to the four data points we got yesterday.

> I think the concept --- at least for ravel --- is
> pretty simple: would you like to read the data off in C ordering or Fortran
> ordering.  Since the output array is one-dimensional, its ordering is
> irrelevant.

Right - hence my confidence that Josef's sense of thinking of the 'C'
and 'F' being target array output was not a good way to think of it in
this case.  It is in the case of arr.tostring() though.

> I don't understand the 'Z' / 'N' suggestion at all.  Are they part of some
> pneumonic?

Think of the way you'd read off the elements using reverse
(last-first) index order for a 2D array, you might imagine something
like a Z.

> I'd STRONGLY advise against deprecating the 'F' and 'C' options.  NumPy
> already suffers from too much bikeshedding with names --- I rarely am able
> to pull out a script I wrote using NumPy even a few years ago and have it
> immediately work.

I wish we could drop bike-shedding - it's a completely useless word
because one person's bike-shedding is another person's necessary
clarification.  You think this clarification isn't necessary and you
think this discussion is bike-shedding.

I'm not suggesting dropping the 'F' and 'C', obviously - can I call
that a 'straw man'?

I am suggesting changing the name to something much clearer, leaving
that name clearly explained in the docs, and leaving 'C' and 'F" as
functional synonyms for a very long time.



More information about the NumPy-Discussion mailing list