Hi, On Mon, Apr 1, 2013 at 4:51 PM, Chris Barker - NOAA Federal <chris.bar...@noaa.gov> wrote: > HI folks, > > I've been teaching Python lately, have taught numpy a couple times > (formally), and am preparing a leacture about it over the next couple > weeks -- so I'm taking an interest here. > > I've been a regular numpy user for a long time, though as it happens, > rarely use ravel() (sode note, what's always confused me the most is > that it seems to me that ravel() _unravels_ the array - but that's a > side note...) > > So I ignored the first post, then fired up iPython, read the > docstring, and played with ravel a bit -- it behaved EXACTLY like I > expected. -- at least for 2-d.... > > Mathew, I expect your group may have gotten tied up by the fact that > you know too much! kind of like how I have a hard time getting my > iphone to work, and my computer-illiterate wife has no problem at all.
Thank you for the compliment, it's more enjoyable than other potential explanations of my confusion (sigh). But, I don't think that is the explanation. First, there were three of us with different levels of experience getting confused on this. Second, I think we all agree that: > So: yes, I do think it's bit confusing and unfortunate that the > "order" parameter has two somewhat different meanings, - so there is a good reason that we could get confused. Last, as soon as we came to the distinction between index order and memory layout, it was clear. We all agreed that this was an important distinction that would improve numpy if we made it. Before I sent the email I did wonder aloud whether people would read the email, understand the distinction, and then fail to see the problem. It is hard to imagine yourself before you understood something. > but they are in > fat, used fairly similarly. And while the idea of "fortran" or "C" > ordering of arrays may be a foreign concept to folks that have not > used fortran or C (or most critically, tried to interace the two...) > it's a common enough concept that it's a reasonable shorthand. > > As for "should we teach memory order at all to newbies?' > > I usually do teach memory order early on, partly that's because I > really like to emphasize that numpy arrays are both a really nice > Python data structure and set of functions, but also a wrapper around > a block of data -- for the later, you need to talk about order. Also, > even with pure-python, knowing a bit about whether arrays are > contiguous or not is important (and views, and...). You can do a lot > with numpy without thinking about memory order at all, but to really > make it dance, you need to know about it. > > In short -- I don't think the situation is too bad, and not bad enough > to change any names or flags, but if someone wants to add a bit to the > ravel docstring to clarify it, I'm all for it. I think you agree that there is potential for confusion, and there doesn't seem any reason to continue with that confusion if we can come up with a clearer name. So here is a compromise proposal. How about: * Preferring the names 'c-style' and 'f-style' for the indexing order case (ravel, reshape, flatiter) * Leaving 'C" and 'F' as functional shortcuts, so there is no possible backwards-compatibility problem. Would you object to that? Cheers, Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
