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

[Sebastian Berg]

On Mon, 2020-08-24 at 15:31 -0600, Aaron Meurer wrote:
> 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 ().
> 

Good observation. I agree, that is a subtle inconsistency for 0-D
objects!
(To be precise, I expect 0-D arrays behave identically to integers,
since they will be optimized out of the "advanced index" part of the
indexing operation).

I suppose this may be an argument for always checking indices even when
they are broadcast away?  I am not certain how straight forward, or
even desirable, it is to fix it so that 0-D integer arrays/integers can
be "broadcast away".

- Sebastian


> 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
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200824/e263977e/attachment.sig>