MovingTimeWindow but for other x

[yakir12]

MovingTimeWindow is great when the windowing acts on TimeTypes. It would be great to have a more general one that doesn't restrict the type of the windowing variable to a TimeType. Imagine a situation where the windowing variable is seconds as floats for instance.

[joshday]

I don't think I want OnlineStats to handle units of time when TimeType already exists for that purpose.

That being said, there doesn't seem to be a simple way to convert data of seconds typed as Float64 to a time. Maybe take a look at what Dates.unix2datetime does for inspiration for that use case.

[yakir12]

Sorry, I wasn't especially clear: the domain of the window doesn't need to be time, in fact it is entirely irrelevant what it represents in real life, it can be oranges, height, temperatures, percent, time, etc. The point is that some of these can be floats, some integers, some rationals, and some time. Right now, the only way we can define a window is in terms of one of these, <:TimeType. I'm suggesting that the functionality of MovingTimeWindow -- to keep a collection of values whoes corresponding "x" values are contained within an interval -- is useful enough to warrant including other types than just that of TimeTypes.

[joshday]

Hmm okay. I think I'm still missing one piece. This is from the MovingTimeWindow docstring. What takes the place of now() for other data types? Or would the interval be fixed?

Observations with a timestamp NOT in the range
now() - window ≤ timestamp ≤ now()
are discarded on every fit!

[yakir12]

The last "x" value.

So in the following case

(1, 0.1), (3, 0.032), (3.2, 1), (5, -0.5)

for a window of 2.1 you do:

5 - 2.1 ≤ x ≤ 5

and therefore only:

(3, 0.032), (3.2, 1), (5, -0.5)

are kept in the collection.

[joshday]

Ah, okay! I'm with you now! I think it would make the most sense as a new type, MovingOrderedWindow? Or maybe I should figure out the right abstractions so that we don't have 3 moving window types...

[yakir12]

I totally agree that this should not be some weird version of MovingTimeWindow. And yea, it would be golden to have an implementation that parameterizes the type for the window.
I'm happy I managed to explain myself!