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
