On Thu, 2020-11-05 at 17:35 -0600, Sebastian Berg wrote: > On Thu, 2020-11-05 at 12:51 -0800, Stephan Hoyer wrote: > > On Thu, Nov 5, 2020 at 11:16 AM Ralf Gommers < > > ralf.gomm...@gmail.com> > > wrote: > > > > > On Thu, Nov 5, 2020 at 4:56 PM Sebastian Berg < > > > sebast...@sipsolutions.net> > > > wrote: > > > > > > > Hi all, > > > > > > > > just a brief note that I merged this proposal: > > > > > > > > https://github.com/numpy/numpy/pull/17394 > > > > > > > > adding `np.sliding_window_view` into the 1.20 release of NumPy. > > > > > > > > There was only one public API change, and that is that the > > > > `shape` > > > > argument is now called `window_shape`. > > > > > > > > This is still a good time for feedback in case you have a > > > > better > > > > idea > > > > e.g. for the function or parameter names. > > > > > > > > > > The old PR had this in the lib.stride_tricks namespace. Seeing it > > > in the > > > main namespace is unexpected and likely will lead to > > > issues/questions, > > > given that such an overlapping view is going to do behave in ways > > > the > > > average user will be surprised by. It may also lead to requests > > > for > > > other > > > array/tensor libraries to implement this. I don't see any > > > discussion on > > > this in PR 17394, it looks like a decision by the PR author that > > > no > > > one > > > commented on - reconsider that? > > > > > > Cheers, > > > Ralf > > > > > > > +1 let's keep this in the lib.stride_tricks namespace. > > > > I have no reservations against having it in the main namespace and am > happy either way (it can still be exposed later in any case). It is > the > conservative choice and maybe it is an uncommon enough function that > it > deserves being a bit hidden...
In any case, its the safe bet for NumPy 1.20 at least so I opened a PR: https://github.com/numpy/numpy/pull/17720 Name changes, etc. are also possible of course. I still think it might be nice to find a better place for this type of function that `np.lib.stride_tricks` though, but dunno... - Sebastian > > But I am curious, it sounds like you have both very strong > reservations, and I would like to understand them better. > > The behaviour can be surprising, but that is why the default is a > read- > only view. I do not think it is worse than `np.broadcast_to` in this > regard. (It is nowhere near as dangerous as `as_strided`.) > > It is true that it is specific to NumPy (memory model). So that is > maybe a good enough reason right now. But I am not sure that > stuffing > things into a pretty hidden `np.lib.*` namespaces is a great long > term > solution either. There is very little useful functionality hidden > away > in `np.lib.*` currently. > > Cheers, > > Sebastian > > > > > > > > > > > Cheers, > > > > > > > > Sebastian > > > > > > > > > > > > > > > > On Mon, 2020-10-12 at 08:39 +0000, Zimmermann Klaus wrote: > > > > > Hello, > > > > > > > > > > I would like to draw the attention of this list to PR #17394 > > > > > [1] that > > > > > adds the implementation of a sliding window view to numpy. > > > > > > > > > > Having a sliding window view in numpy is a longstanding open > > > > > issue > > > > > (cf > > > > > #7753 [2] from 2016). A brief summary of the discussions > > > > > surrounding > > > > > it > > > > > can be found in the description of the PR. > > > > > > > > > > This PR implements a sliding window view based on stride > > > > > tricks. > > > > > Following the discussion in issue #7753, a first > > > > > implementation > > > > > was > > > > > provided by Fanjin Zeng in PR #10771. After some discussion, > > > > > that PR > > > > > stalled and I picked up the issue in the present PR #17394. > > > > > It > > > > > is > > > > > based > > > > > on the first implementation, but follows the changed API as > > > > > suggested > > > > > by > > > > > Eric Wieser. > > > > > > > > > > Code reviews have been provided by Bas van Beek, Stephen > > > > > Hoyer, > > > > > and > > > > > Eric > > > > > Wieser. Sebastian Berg added the "62 - Python API" label. > > > > > > > > > > > > > > > Do you think this is suitable for inclusion in numpy? > > > > > > > > > > Do you consider the PR ready? > > > > > > > > > > Do you have suggestions or requests? > > > > > > > > > > > > > > > Thanks for your time and consideration! > > > > > Klaus > > > > > > > > > > > > > > > [1] https://github.com/numpy/numpy/pull/17394 > > > > > [2] https://github.com/numpy/numpy/issues/7753 > > > > > _______________________________________________ > > > > > 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 > > https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion