Hi @fede (nixtla) (they/them), I am now using MLForecast and I was wondering whether there is a plan for the

input_size

argument to be implemented in

MLForecast.cross_validation

to enable a sliding window? Happy to raise an issue and contribute if possible.

Hi Again @fede (nixtla) (they/them). Hope you are well. I have been making good progress evaluating MLForecast for our production solution, however, I am having an issue using

keep_last_n

and

cross_validation

. In the electricity_peak_forecasting notebook when using the

keep_last_n

argument the code it fails if

keep_last_n < (Y_df.shape[0] - window_size)

. In the example the minimum window that works is

keep_last_n = 6528

:

Am I doing something wrong?

I have carried different tests and the problem remains with and without differencing/exogenous features.

I have been continuing my investigation and have looked at whether this problem is just present when using

cross_validation.

I have just tried the

end_to_end_walkthrough.ipynb

notebook Training and Forecasting sections and the same error occurs when

differences =[24]

and

keep_last_n

is < 1008. No error is raised if the

differences

argument is not used. This therefore looks like a problem when slicing the data when there are exogenous/differences present and is an issue when both when using

fit

/

predict

or

cross_validation

.

Good afternoon @fede (nixtla) (they/them), I have done some digging and I think there might be two bugs when using

keep_last_n

in MLForecast. First, here the

self.last_dates

is not correct when using

keep_last_n

. This results in null values for the exogenous features when there is a merge in

_get_features_for_next_step

here. I corrected this using a bit of a hack:

self.last_dates = pd.DatetimeIndex([sorted_df.index.get_level_values(self.time_col)[-1]])

This appears to work for my use case but I don't know the design of MLForecast well so this might not be correct for other cases such as multiple `unique_id`'s, Secondly, once this was fixed I noticed that the

X

and

y

used in

fit_model

here had all the data and not just the last n samples. I implemented the following hack before `return self.fit_models(X, y)`:

if keep_last_n is not None:
    X, y  = X[-keep_last_n:], y[-keep_last_n:]

This is not the right place to fix this as it should be done in

core.py

I think but I just did this quickly to fix and get some results. Do you have any thoughts? Happy to keep digging into the code if that helps, raise an issue on Github or share this with someone else if you don't have time? Thanks again

Although those errors you're getting seem a bit odd, the keep_last_n argument should only impact the predict step, I'm not sure why you get errors on the transform. I'd really appreciate if you can open an issue with a minimal reproducible example.

I will create a minimal reproducible example and raise an issue later today - I'll need to have a think about this error based on on my new understanding of what

keep_last_n

is doing so it might be later this evening. I think it might only be occurring in the predict step. I'll tag you in the issue later.