-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
Rolling window #31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rolling window #31
Conversation
It seems natural to me for the axis to change "in place"; that is, the window axis is immediately after the axis being "windowed". I'd also like a "step" keyword that determines the increment of the start of each window. This should do it:
For example,
|
Additional feature suggestion: How about 2-D (and higher dimensional) windows? These may also useful, and it would be nice to have everything done by a single function. |
Just to note, something like this is very easy to generalize for n-dimensions, of course that would make an axis argument a bit ill defined as to what it would do, I guess it would be possible to add it when window is scalar, and maybe a choice as to add the new dimensions at the start or end. If window == step, it creates non overlapping "tiles". EDIT: I created a new very general version which allows for pretty much all of the above (I could imagine adding axis argument to build a up the correct window), also there is no support for negative steps, but I am not sure that matters. I guess the comments are not understandable probably... sorry for the spam, have put that code here: https://gist.github.com/3866040 instead. |
What's the status of this? It looks like @seberg already has a working implementation. What's left? |
Also relevant: the c-level neighborhood iterator. (One of the few things
|
Maybe a bit harsh, but I am going to just close this due to age, and the fact that I would like to see such a function be more general, so a few changes would be needed here still. I would be happy to see someone pick it up though! |
DOC: Add __all__ and document lock
Merge in numpy-hpy from ss/array_array_full to labs-hpy-port * commit '0fa5e68fbdfede59074ff30dd867cb4e1113b753': Remove the use of typeobjects: global PyObject* array Fully port array_array (enough for the example)
A useful stride trick that not many people are aware of.