How to handle multiple forecasts from the same model?

[robjhyndman]

Here is an example:

library(fpp3)
fit <- us_change %>%
  model(lm = TSLM(Consumption ~ Income + Savings + Unemployment))
up_future <- new_data(us_change, 4) %>%
  mutate(Income = 1, Savings = 0.5, Unemployment = 0)
down_future <- new_data(us_change, 4) %>%
  mutate(Income = -1, Savings = -0.5, Unemployment = 0)
fc_up <- forecast(fit, new_data = up_future) %>%
  mutate(Scenario = "Increase") %>% as_fable(response=Consumption, key = Scenario)
fc_down <- forecast(fit, new_data = down_future) %>%
  mutate(Scenario = "Decrease") %>% as_fable(response=Consumption, key = Scenario)

us_change %>%
  autoplot(Consumption) +
  autolayer(rbind(fc_up, fc_down)) +
  ylab("% change in US consumption")

Having to manually rbind these results is not ideal (and bind_rows won't work).

Also, the as_fable() needs the response variable re-specified when it should already have that information. We are just adding a key.

[mitchelloharawild]

Hmmm... we could support differing key structures between the mable and new_data, as long as the mable key structure is a subset of the new_data keys.

Do you think that producing forecasts with different xregs will be a common use? I would think that forecasting with xregs will usually be used if the future is known or easily forecastable, and so only one set of xregs would be provided.

[robjhyndman]

This is very common in scenario forecasting where different scenarios are used for the new data. Currently new_data is a tsibble with the same keys as the original data. We could allow the user to add keys (or one new key?) to the new_data object, and each combination of new keys leads to a new forecast.

[mitchelloharawild]

From discussions at the ISI WSC, one somewhat safe approach would be to allow a .scenario key variable which defines separate scenarios in new_data.

[mitchelloharawild]

I think using the key structure for this is the wrong approach. Instead allowing users to provide a (potentially named) list of scenarios would be better. We could also wrap this up into a scenarios() function or something to provide a more readable workflow if we wanted to be strict with usage.