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