This message was deleted.

Hey. The configuration you provide to the intervals is used to perform cross validation, so two windows of size 52 would use 104 validation samples. If you have 156 points that should leave you with 52 training samples in the first window, however if one of your features requires more then it would be null and if your model can't handle nulls then you'd get that error. Are you also getting warnings like "Found nulls in feature X"?

Hey José, no I don't get any warnings from the preprocess part with my lags configs for series with len >= 156 :

mlf = MLForecast(
    models=[model],
    freq="W",
    lags=list(range(1, 53)),
    lag_transforms = {
        1:  [(rolling_mean, 51), (rolling_std, 51)],
        26: [(rolling_mean, 26), (rolling_std, 26)],
        40: [(rolling_mean, 12), (rolling_std, 12)],
        44: [(rolling_mean, 8), (rolling_std, 8)],
        48: [(rolling_mean, 4), (rolling_std, 4)],
    }
)

But it seems like it works if I let at least 2 * 52 + 1 points by series after the preprocess, by setting

lags=list(range(1, 52))

(excluding lag 52).

lag 52 requires 53 samples, so that could be it

df.groupby("unique_id")["ds"].count().min()

==> 156

prep.groupby("unique_id")["ds"].count().min()

==> 104

prep.isnull().sum().max() + 1

==> 1

It needs n_windows * h + min_samples, because it performs CV, so it's like: • n_samples: 156 • first window is the earliest one, so we move back 104 timestamps and save the next 52 as the first validation. at this point you have 52 training samples. • Run the feature engineering on the 52 samples, if your features require more than that you'll get null values and if you set dropna=True you could drop your training set entirely, which should raise a different error

Oh ok, I got it! So it's the normal behavior and my model crashed because it can't handle NaN values in the first 1-step ahead cross-validation iteration.

Yeah you could do that or use a pipeline that does some kind of imputing, e.g.

from sklearn.impute import SimpleImputer
from sklearn.pipeline import make_pipeline

model = make_pipeline(
    SimpleImputer(strategy='constant', fill_value=0),
    LinearRegression()  # or any other model you're using
)
fcst = MLForecast(models=[model], ...)

that would fill the nulls with zeros before passing them to the model, which is easier to implement I thnk

You’re right, in that case, for the first window I will have y=lag52_y and it could add a serious bias to the training. But I don’t see another (simple) way to deal with my problem right now :p

I was going to suggest using n_windows=1 but I see we don't allow it haha

Why not haha. But do you know exactly why this assert for min 2 windows exists?

Yeah it's for statistical rigor I suppose. Since we're computing quantiles based on the errors just having one sample (window) isn't very reliable, but I believe it'd provide a better estimate than providing fictional samples

Thanks! I try it today

which model are you using?

I was testing with a simple linear regression as baseline

Can you use one of the techniques here to inspect the inputs? It's weird for the linear regression to predict inf

I've already explored this with a debugging tool. On the 15th iteration out of 52 (in my case h=52), after generating the lags, the X entry contains inf and NaN, which causes the execution to crash when sklearn checks the inputs. However, no problem for a dataset of similar size generated with

generate_series

... My dataset can contain series with quite sparse values and large peaks. From what I've seen, 6 series out of 32,000 are involved.

Are you using target transformations?

Nope, only lags & lag_transforms

Which lag transforms?

rolling_mean

&

rolling_std

They both divide by the window size so I don't think they could divide by zero. So it's probably coming from the forecast. Are you able to see the forecast in the step before? If the linear regression coefficients are somewhat big and it gets one of the spikes I guess it could produce an Inf but that seems to be a bit hard (they'd have to be really big values)

that’s exactly my conclusion, and that’s why I gave up and switched to LGBM 😛

haha ok. Let me know if that produces an error as well

The problem is LGBM natively handle NaN values. I will double check with xgboost to be sure!