Add Sliding window

[breznak]

Add class providing fast & reusable sliding window implementation

• simplifies MovingAverage
• improves compare==
• fix CI error
• old,long PR, squash commits before merging

Fixes numenta#1276
Moved from numenta#1277
Please see discussion there

[breznak]

This should be an easy one, heavily reviewed PR back from Numenta. Add sliding window/circular buffer implementation.
If you see a place where this could simplify code, feel free to put it there.

[dkeeney]

I was going to replace the circular buffer with a simple std::deque. @christian Henning <[email protected]> had a boost::circular_buffer which is actually a better fit but almost the same as a std::deque. Either of these two things is basically the same as a sliding window since we are using an Array object with a shared pointer to the real buffer. But I will look at their implementation.

…

On Thu, Aug 30, 2018 at 5:42 AM breznak ***@***.***> wrote: This should be an easy one, heavily reviewed PR back from Numenta. Add sliding window/circular buffer implementation. If you see a place where this could simplify code, feel free to put it there. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFBa_zcmraE3hOVbLArJECBeaTU5anJ0ks5uV92hgaJpZM4RkXfE> .

[breznak]

Good point, I was using boost::circular_buffer too, this sprang to life just to get rid of it.
Deque is ofc a good fit, I think we've used it..and later this evolved to fit some sugar with operators etc.

[dkeeney]

Oh...after looking at the Numenta issues. We are not talking about the same thing. I am talking about the use of a circular_buffer in the Link to handle Propagation Delay. You are talking about the MovingAverage function. Very different. However, if you can use a boost::circular_buffer there you could also use a std::deque and avoid the extra dependency.

…

On Thu, Aug 30, 2018 at 2:58 PM David E Keeney ***@***.***> wrote: I was going to replace the circular buffer with a simple std::deque. @christian Henning ***@***.***> had a boost::circular_buffer which is actually a better fit but almost the same as a std::deque. Either of these two things is basically the same as a sliding window since we are using an Array object with a shared pointer to the real buffer. But I will look at their implementation. On Thu, Aug 30, 2018 at 5:42 AM breznak ***@***.***> wrote: > This should be an easy one, heavily reviewed PR back from Numenta. Add > sliding window/circular buffer implementation. > If you see a place where this could simplify code, feel free to put it > there. > > — > You are receiving this because your review was requested. > Reply to this email directly, view it on GitHub > <#10 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AFBa_zcmraE3hOVbLArJECBeaTU5anJ0ks5uV92hgaJpZM4RkXfE> > . >

[breznak]

oh, well..this is intended as a "lib", so it's perfect if you can see whether the current implementation of SlidingWindow would fit your needs in Link?

[breznak]

@dkeeney please review, if merging, merge as "Squash and merge" this time, to avoid all the fixup commits

[dkeeney]

Interesting implementation.
I wrote one of these once; used a deque rather than a vector. But I did not have the requirement of having to directly index into the elements of the window.

Perhaps you could overload [ ] operator and remap the index such that it always indexes in order. Do the same with the iterator. Then you would not need the getLinearizedData() function and data will always be in queue order. getData() would require copying into a new vector so it would be ordered.
Just thoughts... not a requirement.

[breznak]

..I forgot to implement serialization, dig into it and got stuck on possible design flaw in Serializable (I have problem serializing any object with const member, as serialization assumes default constructor())

[breznak]

Will merge as is, and do the Serialization etc in other PR.

Perhaps you could overload [ ] operator and remap the index such that it always indexes in order. Do the same with the iterator. Then you would not need the getLinearizedData() function and data will always be in queue order. getData() would require copying into a new vector so it would be ordered.

I like this idea. Will add it to comment in that file and revisit when we finish other things in progress