[Numpy-discussion] Why does fancy indexing work like this?

[Aaron Meurer]

On Wed, Aug 19, 2020 at 8:18 PM Sebastian Berg
<sebastian at sipsolutions.net> wrote:
>
> On Wed, 2020-08-19 at 19:37 -0600, Aaron Meurer wrote:
> > These cases don't give any deprecation warnings in NumPy master:
> >
> > > > > np.arange(0)[np.array([0]), False]
> > array([], dtype=int64)
> > > > > np.arange(0).reshape((0, 0))[np.array([0]), np.array([],
> > > > > dtype=int)]
> > array([], dtype=int64)
> >
> > Is that intentional?
>
> I guess it follows from `np.array([[1]])[[], [10]]` also not failing
> currently.

Sure, I think that's the same thing (sorry if my example is "too
trivial". I was copy-pasting a hypothesis shrunk example).

>
> And that was intentional not to deprecate when out-of-bound indices
> broadcast away. But I am not sure I actually think that was the better
> choice.  My initial choice was that this would be an error as well, and
> I still slightly prefer it, but don't feel it matters much.

There's an inconsistency here, which is that out-of-bounds indices
that are broadcast away are not bounds checked unless they are scalar
indices, in which case they are.

>>> a = np.empty((1, 1))
>>> a[np.array([], dtype=int), np.array([10])]
array([], dtype=float64)
>>> a[np.array([], dtype=int), 10]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: index 10 is out of bounds for axis 1 with size 1
>>> np.broadcast_arrays(np.array([], dtype=int), np.array([10]))
[array([], dtype=int64), array([], dtype=int64)]
>>> np.broadcast_arrays(np.array([], dtype=int), 10)
[array([], dtype=int64), array([], dtype=int64)]

This breaks the rule that scalar integer indices have the same
semantics as integer arrays with shape ().

Aaron Meurer

>
> - Sebastian
>
> >
> > Aaron Meurer
> >
> > On Thu, Jul 23, 2020 at 12:18 PM Aaron Meurer <asmeurer at gmail.com>
> > wrote:
> > > > After writing this, I realized that I actually remember the
> > > > *opposite*
> > > > discussion occurring before.  I think in some of the equality
> > > > deprecations, we actually raise the new error due to an internal
> > > > try/except clause.  And there was a complaint that its confusing
> > > > that a
> > > > non-deprecation-warning is raised when the error will only happen
> > > > with
> > > > DeprecationWarnings being set to error.
> > > >
> > > > - Sebastian
> > >
> > > I noticed that warnings.catch_warnings does the right thing with
> > > warnings that are raised alongside an exception (although it is a
> > > bit
> > > clunky to use).
> > >
> > > Aaron Meurer
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion at python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> >
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion