You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should consider the option of separate weights to each forecast horizon (e.g. auto.arima performs very well for short horizons, nnetar for medium horizons, and ets for long horizons, so if we are forecasting a series the first through sixth predictions receives higher weight from the auto.arima model, the 7th through 10th receives higher weight from the nnetar model, and later observations receive heavier weight from the ets model).
This would ideally be calculated for each horizon, so the weights could be stored in an h * n matrix (n models and h periods). This would involve a minor reworking of the way the weights are stored and used for forecasts, but the bigger issue is computing each horizon since we set the weights during the model selection process hybridModel(), but we wouldn't know how many periods in advance are needed until forecast.hybridModel() is called. We could fix this in several ways. Perhaps we could cap the horizon at some reasonably far distance (e.g. h no longer than twice the length of the input series) and compute these horizons during model selection. Or we could add an argument in hybridModel() that the user sets for the maximum horizon to compute if these separate weights are wanted. Finally, the separate weights could be exposed through an additional argument separate = TRUE. In any case we should consider what happens if h greater than these precomputed horizon weights is input (perhaps throw a warning and then fall back on equal weights or the weight values for the last available horizon)
The text was updated successfully, but these errors were encountered:
We should consider the option of separate weights to each forecast horizon (e.g.
auto.arima
performs very well for short horizons,nnetar
for medium horizons, andets
for long horizons, so if we are forecasting a series the first through sixth predictions receives higher weight from theauto.arima
model, the 7th through 10th receives higher weight from thennetar
model, and later observations receive heavier weight from theets
model).This would ideally be calculated for each horizon, so the weights could be stored in an h * n matrix (n models and h periods). This would involve a minor reworking of the way the weights are stored and used for forecasts, but the bigger issue is computing each horizon since we set the weights during the model selection process
hybridModel()
, but we wouldn't know how many periods in advance are needed untilforecast.hybridModel()
is called. We could fix this in several ways. Perhaps we could cap the horizon at some reasonably far distance (e.g. h no longer than twice the length of the input series) and compute these horizons during model selection. Or we could add an argument inhybridModel()
that the user sets for the maximum horizon to compute if these separate weights are wanted. Finally, the separate weights could be exposed through an additional argumentseparate = TRUE
. In any case we should consider what happens ifh
greater than these precomputed horizon weights is input (perhaps throw a warning and then fall back on equal weights or the weight values for the last available horizon)The text was updated successfully, but these errors were encountered: