On Sun, 2014-02-02 at 13:11 -0600, Travis Oliphant wrote: > This sounds like a great and welcome work and improvements. > > Does it make sense to also do something about the behavior of advanced > indexing when slices are interleaved between lists and integers. > > I know that jay borque has some preliminary work to fix this. There > are a some straightforward fixes -- like doing iterative application > of indexing in those cases which would be more sensical in the cases > where current code gets tripped up. >
I guess you are talking about the funky transposing logic and maybe the advanced indexing logic as such? I didn't really think about changing any of that, not sure if we easily can? Personally, I always wondered if it would make sense to add some new type of indexing mechanism to switch to R/matlab style non-advanced integer-array indexing. I don't think this will make it substantially easier to do (the basic logic remains the same -- we need an extra/different preparation and then transpose the result differently), though it might be a bit more obvious where/how to plug it in. But it seems very unlikely I will look into that in the near future (but if someone wants hints on how to go about it, just ask). - Sebastian > Travis > > On Feb 2, 2014 11:07 AM, "Charles R Harris" > <charlesr.har...@gmail.com> wrote: > Sebastian has done a lot of work to refactor/rationalize numpy > indexing. The changes are extensive enough that it would be > good to have more public review, so here is the release note. > > The NumPy indexing has seen a complete rewrite in this > version. This makes > most advanced integer indexing operations much faster > and should have no > other implications. > However some subtle changes and deprecations were > introduced in advanced > indexing operations: > > * Boolean indexing into scalar arrays will always > return a new 1-d array. > This means that ``array(1)[array(True)]`` gives > ``array([1])`` and > not the original array. > * Advanced indexing into one dimensional arrays used > to have (undocumented) > special handling regarding repeating the value > array in assignments > when the shape of the value array was too small or > did not match. > Code using this will raise an error. For > compatibility you can use > ``arr.flat[index] = values``, which uses the old > code branch. > * The iteration order over advanced indexes used to > be always C-order. > In NumPy 1.9. the iteration order adapts to the > inputs and is not > guaranteed (with the exception of a *single* > advanced index which is > never reversed for compatibility reasons). This > means that the result is > undefined if multiple values are assigned to the > same element. > An example for this is ``arr[[0, 0], [1, 1]] = [1, > 2]``, which may > set ``arr[0, 1]`` to either 1 or 2. > * Equivalent to the iteration order, the memory > layout of the advanced > indexing result is adapted for faster indexing and > cannot be predicted. > * All indexing operations return a view or a copy. > No indexing operation > will return the original array object. > * In the future Boolean array-likes (such as lists > of python bools) > will always be treated as Boolean indexes and > Boolean scalars (including > python `True`) will be a legal *boolean* index. At > this time, this is > already the case for scalar arrays to allow the > general > ``positive = a[a > 0]`` to work when ``a`` is zero > dimensional. > * In NumPy 1.8 it was possible to use `array(True)` > and `array(False)` > equivalent to 1 and 0 if the result of the > operation was a scalar. > This will raise an error in NumPy 1.9 and, as > noted above, treated as a > boolean index in the future. > * All non-integer array-likes are deprecated, object > arrays of custom > integer like objects may have to be cast > explicitly. > * The error reporting for advanced indexing is more > informative, however > the error type has changed in some cases. > (Broadcasting errors of > indexing arrays are reported as `IndexError`) > * Indexing with more then one ellipsis (`...`) is > deprecated. > > > Thoughts? > > > Chuck > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
