Expanding vs sliding window splitter (window splitter with fixed start point)

Is your feature request related to a problem? Please describe.

As in real use cases we collect data to enlarge our training set, it would be useful to have an option on the SlidingWindowSplitter to have fixed start windows for the fold. For example for window_length = 5, step_length = 1 and fh = 3 here is a representation of the folds:

|-----------------------|
| * * * * * x x x - - - |
| - * * * * * x x x - - |
| - - * * * * * x x x - |
| - - - * * * * * x x x |

* = training fold.
x = test fold.  

We could add the option to have the folds of the form:

|-----------------------|
| * * * * * x x x - - - |
| * * * * * * x x x - - |
| * * * * * * * x x x - |
| * * * * * * * * x x x |

Describe the solution you’d like Just add an option on the SlidingWindowSplitter class to keep start_fixed.

Describe alternatives you’ve considered When this parameter is set to True we compute the folds as

end = self._get_end(y)
start = self._get_start()

for split_point in range(start, end, step_length):
            training_window = np.arange(start, split_point)
            test_window = split_point + fh - 1
            yield training_window, test_window

Additional context See fixedWndow parameter from Caret

[juanitorduz]

https://scikit-lego.netlify.app/timegapsplit.html has an interesting approach.

[juanitorduz]

You are right @fkiraly! We should indeed be careful in the distinction between tuning and evaluation! Having an evaluation/monitoring module would be really helpful! For example, I find Prophet’s diagnostics quite handy.

I would be interested in contributing, although my capacity is limited at the moment (baby at home 👶 ). I could support with small bugs/features and also testing module designs 🤓 .