[Numpy-discussion] Indexing changes in 1.9

Travis Oliphant travis at continuum.io
Sun Feb 2 14:11:01 EST 2014


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.

Travis
On Feb 2, 2014 11:07 AM, "Charles R Harris" <charlesr.harris at 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 at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140202/4d836281/attachment.html>


More information about the NumPy-Discussion mailing list