On Thu, 2021-09-16 at 14:39 -0600, Aaron Meurer wrote: > On Thu, Sep 16, 2021 at 12:32 AM Nico Schlömer < > nico.schloe...@gmail.com> wrote: > > > > > I was playing with this though and was a little surprised to find > > > NumPy allows things like this: > > > > > > > > > a = np.array([1, 2, 3]) > > > > > > a[:] = np.array([[[5, 6, 7]]]) > > > > > > a > > > array([5, 6, 7]) > > > > Thanks Aaron for this example! I hadn't seen this before, and > > indeed > > the suggested PR doesn't intercept this case. Perhaps that's > > something > > we should consider deprecating as well. I'll add a comment to the > > PR; > > let's take it from there. > > Is there some valid use-case for this "reverse broadcasting"? It > seems > to me like an error would be better. Clearly a[idx] = b should work > if > a[idx] and b broadcast to a[idx].shape, but here the broadcast shape > is not the same as a[idx]. I would expect this to generally be a bug > in user code, but maybe I'm missing why this was implemented in the > first place. > > The semantics are a bit odd. Clearly something like a[:] = > np.array([[[5, 6, 7], [6, 7, 8]]]) in the above example can't work, > even though they are also both broadcast compatible. So it only works > if they are broadcast compatible and the broadcasting of the lhs just > adds 1s to its shape (which get implicitly removed in the assignment > since slice assignment can't change an array's shape)? >
TL;DR: I agree that reverse broadcasting seems unnecessary and confusing. But is getting rid of it worth the trouble if it causes downstream pain (it may not cause pain, but I do not know)? Personally, I just place "reverse broadcasting" into history... The discussion seems like an example of how NumPy, Python, etc. over time move from a laissez-faire approach to valuing consistency more. It seems easy to think: "why not, may be practical" but switch to a "refuse to guess, there is no important use-case" mentality. Neither change is probably a big bug-magnet (at least I cannot think of why); although the `__float__` and `__int__` one seems worse to me. And I think getting rid of it might help with removing other quirks around item assignment. Personally, I would be happy to change both, but they are probably distinct. And I think the worry is mainly/only about the cost (user pain) to benefit ratio. Nico has taken some time to try and make sure that the effect of this deprecation is hopefully not very large (although this discussion may very well turn that!). We should figure this out for "reverse broadcasting". I currently don't see a big reason for picking that particular battle myself. Cheers, Sebastian > Aaron Meurer > > > > > Cheers, > > Nico > > > > On Thu, Sep 16, 2021 at 2:00 AM Aaron Meurer <asmeu...@gmail.com> > > wrote: > > > > > > Presumably this also changes int(), bool(), and complex() in the > > > same way. > > > > > > The array API standard (and numpy.array_api) only requires > > > float(), > > > bool(), and int() (and soon complex()) for dimension 0 arrays > > > (the > > > standard does not have scalars), in part because of this NumPy > > > issue > > > https://data-apis.org/array-api/latest/API_specification/array_object.html#float-self > > > . > > > > > > On Wed, Sep 15, 2021 at 6:18 AM Nico Schlömer < > > > nico.schloe...@gmail.com> wrote: > > > > > > > > Hi everyone, > > > > > > > > This is seeking input on PR [1] which I've worked on with > > > > @eric-wieser > > > > and @seberg. It deprecates > > > > ``` > > > > float(x) > > > > ``` > > > > if `x` is an array of ndim > 0. (It works with all arrays of > > > > size 1 > > > > right now.) This aligns the behavior of float() on ndarrays > > > > with > > > > float() on lists which already fails today. It also deprecates > > > > the > > > > implicit conversion to float in assignment expressions like > > > > ``` > > > > a = np.array([1, 2, 3]) > > > > a[0] = [5] # deprecated, should be a[0] = 5 > > > > > > This already gives a ValueError in NumPy 1.21.1. Do you mean a[0] > > > = > > > np.array([5]) is deprecated? > > > > > > I was playing with this though and was a little surprised to find > > > NumPy allows things like this: > > > > > > > > > a = np.array([1, 2, 3]) > > > > > > a[:] = np.array([[[5, 6, 7]]]) > > > > > > a > > > array([5, 6, 7]) > > > > > > Array assignment allows some sort of reverse broadcasting? Given > > > this > > > behavior, it seems to me that a[0] = np.array([5]) actually > > > should > > > work. Or is the idea that this entire behavior would be > > > deprecated? > > > > > > Aaron Meurer > > > > > > > ``` > > > > In general, the PR makes numpy a tad bit stricter on how it > > > > treats > > > > scalars vs. single-item arrays. > > > > > > > > The change also prevents the #1 wrong usage of float(), namely > > > > for > > > > extracting the scalar value from an array. One should rather > > > > use > > > > `x[0]` or `x.item()` to that which doesn't convert the value to > > > > a > > > > Python float. > > > > > > > > To estimate the impact of the PR, I looked at major numpy > > > > dependents > > > > like matplotlib, scipy, pandas etc., and of course numpy > > > > itself. > > > > Except scipy, all projects were virtually clean to start with. > > > > Scipy > > > > needed some changes for all tests to pass without warning, and > > > > all of > > > > the changes were improvements. In particular, the deprecation > > > > motivates users to use actual scalars when scalars are needed, > > > > e.g., > > > > in the case of scipy, as the return value of a goal functional. > > > > > > > > It'd be great if you could try the branch against your own > > > > project and > > > > let us know (here or in the PR) about and problems that you > > > > might > > > > have. > > > > > > > > Thanks! > > > > Nico > > > > > > > > [1] https://github.com/numpy/numpy/pull/10615 > > > > [2] https://github.com/numpy/numpy/issues/10404 > > > > _______________________________________________ > > > > NumPy-Discussion mailing list > > > > NumPy-Discussion@python.org > > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > _______________________________________________ > > > NumPy-Discussion mailing list > > > NumPy-Discussion@python.org > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion@python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > _______________________________________________ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: sebast...@sipsolutions.net
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
