Daily Forecast forces lag_periods. Customer has no option to override

[AKannanMSFT]

When customers submit a daily forecast, no matter what, we force the lag_periods to be a fixed value in multivariate_prep_recipe_2:

lag_periods_r2 <- unique(c(1, 2, 3, 4, 5, 6, 7, 14, 21, 28, 28*2, 28*3, 28*6, 28*9, 28*12, 365, forecast_horizon))

We don't allow for the customer to override this value like we do in multivariate_prep_recipe_1

This is a problem in a setting where the data doesn't have 365 data points. i.e. say we have 300 data points, this line breaks.

[mitokic]

Thanks for calling this out Aadharsh.

Now by default R2 recipes are turned off for daily forecasts.

Currently there is a hybrid process going on. Yes there are some default lag values that are created in your code reference above, but later in the function these values are joined with the "lag_periods" object that allows users to adjust it or use the default. So there is some control there. The extra lags are added to ensure we are getting most out of the features the R2 brings compared to R1, mostly around using lags that are less than the forecast horizon.

With that being said there could be cases where an error occurs like your example. I think in most situations this will not happen, since the R2 recipe is turned off by default for daily forecasts. And if a user has specifically tuned on the recipe, I assume they would have a robust historical data set to leverage.

This is an area we could explore more in the future to fix potential errors with small datasets. I think for now we can hold off on this fix until after v0.1 launch.