[Numpy-discussion] Indexing changes in 1.9
Travis Oliphant
travis at continuum.io
Mon Feb 3 16:32:33 EST 2014
Hey Sebastien,
I didn't mean to imply that you would need to necessarily work on it. But
the work Jay has done could use review.
There are also conversations to have about what to do to resolve the
ambiguity that led to the current behavior.
Thank you or all the great work on the indexing code paths.
Is their a roadmap for 1.9?
Travis
On Feb 3, 2014 1:26 PM, "Sebastian Berg" <sebastian at sipsolutions.net>
wrote:
> 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.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
> >
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion at scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
> _______________________________________________
> 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/20140203/fc097fd8/attachment.html>
More information about the NumPy-Discussion
mailing list