ENH: Add Moving Average Function
![](https://secure.gravatar.com/avatar/ee3831a5e7eaa034f0b257c792129f7d.jpg?s=120&d=mm&r=g)
Hi all, I opened a Pull Request (https://link.getmailspring.com/link/58478F5E-3390-4C6D-8AA4-0B8724FC079A@getmailspring.com/0?redirect=https%3A%2F%2Fgithub.com%2Fnumpy%2Fnumpy%2Fpull%2F13923&recipient=bnVtcHktZGlzY3Vzc2lvbkBweXRob24ub3Jn) to include this package in numpy (https://link.getmailspring.com/link/58478F5E-3390-4C6D-8AA4-0B8724FC079A@getmailspring.com/1?redirect=https%3A%2F%2Fpypi.org%2Fproject%2Fmvgavg%2F&recipient=bnVtcHktZGlzY3Vzc2lvbkBweXRob24ub3Jn), along with the associated sliding window function in this PR (https://link.getmailspring.com/link/58478F5E-3390-4C6D-8AA4-0B8724FC079A@getmailspring.com/2?redirect=https%3A%2F%2Fgithub.com%2Fnumpy%2Fnumpy%2Fissues%2F7753&recipient=bnVtcHktZGlzY3Vzc2lvbkBweXRob24ub3Jn). The function picks the fastest method to do a moving average if there is no weighting, but with weights it resorts to the second-fastest method which has an easier implementation. It also contains a binning option which cuts the number of points down by a factor of n rather than by subtracting n. The details are in the package documentation and PR. Thanks, Nicholas
![](https://secure.gravatar.com/avatar/93a76a800ef6c5919baa8ba91120ee98.jpg?s=120&d=mm&r=g)
I would be very interested to see the “sliding window view” function merged into np.lib.stride_tricks. I don’t think it makes sense to add a suite of dedicated functions for sliding window calculations that wrap that function. If we are going to go down the path of adding sliding window calculations into a NumPy, they should use efficient algorithms, like those found in the “bottleneck” package. Best, Stephan On Sun, Aug 25, 2019 at 3:33 PM Nicholas Georgescu <nsg27@case.edu> wrote:
![](https://secure.gravatar.com/avatar/998f5c5403f3657437a3afbf6a16e24b.jpg?s=120&d=mm&r=g)
I think having some function for common cases like moving average and spectrogram would be good. Having a jumping-off point and simple reference for testing against could encourage someone to make a faster implementation down the road. -Todd On Mon, Aug 26, 2019 at 12:24 AM Stephan Hoyer <shoyer@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/5f88830d19f9c83e2ddfd913496c5025.jpg?s=120&d=mm&r=g)
On Mon, Aug 26, 2019 at 8:38 AM Todd <toddrjen@gmail.com> wrote:
This could also be done as a docstring example in the sliding window view function. It's pretty straightforward, the moving average function in PR 13923 (fnjn_mvgavg) is ~5 lines of code. That way we don't get stuck with a function that's not as efficient as it should be, and we can point from there to `bottleneck` and/or something else that's a high-quality implementation. Cheers, Ralf
![](https://secure.gravatar.com/avatar/93a76a800ef6c5919baa8ba91120ee98.jpg?s=120&d=mm&r=g)
I would be very interested to see the “sliding window view” function merged into np.lib.stride_tricks. I don’t think it makes sense to add a suite of dedicated functions for sliding window calculations that wrap that function. If we are going to go down the path of adding sliding window calculations into a NumPy, they should use efficient algorithms, like those found in the “bottleneck” package. Best, Stephan On Sun, Aug 25, 2019 at 3:33 PM Nicholas Georgescu <nsg27@case.edu> wrote:
![](https://secure.gravatar.com/avatar/998f5c5403f3657437a3afbf6a16e24b.jpg?s=120&d=mm&r=g)
I think having some function for common cases like moving average and spectrogram would be good. Having a jumping-off point and simple reference for testing against could encourage someone to make a faster implementation down the road. -Todd On Mon, Aug 26, 2019 at 12:24 AM Stephan Hoyer <shoyer@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/5f88830d19f9c83e2ddfd913496c5025.jpg?s=120&d=mm&r=g)
On Mon, Aug 26, 2019 at 8:38 AM Todd <toddrjen@gmail.com> wrote:
This could also be done as a docstring example in the sliding window view function. It's pretty straightforward, the moving average function in PR 13923 (fnjn_mvgavg) is ~5 lines of code. That way we don't get stuck with a function that's not as efficient as it should be, and we can point from there to `bottleneck` and/or something else that's a high-quality implementation. Cheers, Ralf
participants (4)
-
Nicholas Georgescu
-
Ralf Gommers
-
Stephan Hoyer
-
Todd