OO approach instead of string approach for API

[paulhendricks]

How do you feel about an OO to the API instead of using strings and if statements to specify the model? It might provide greater flexibility and cleaner code.

library(forecast)
library(forecastHybrid)

some_ts <- ts(1:144, frequency = 12)
model_1 <- forecast::stlf(some_ts)
model_2 <- forecast::ets(some_ts)
model_3 <- forecast::auto.arima(some_ts)
model_4 <- forecast::nnetar(some_ts)

ensembled_model <- forecastHybrid::hybridModel(model_1, model_2, model_3, model_4, ...) # other args
class(ensembled_model) # "forecast" "ensemble"

# other API calls consistent with forecast, e.g.
plot(forecast(ensembled_model, h = 14))

hybridModel <- function(models, ...) {
  for (model in models) {
    # code that fits and finds weights and ensembles
  }
  return(ensembled_model)
}

forecastHybrid::hybridModel auto-magically finds weights and returns an object of class c("forecast", "ensemble") that is consistent with all the other functions in the forecast package.

[dashaub]

I like this approach. So long as the individual models have a forecast method this would allow users to specify custom individual models as well.

The existing approach has one advantage in that it allows users to build ensembles quickly, e.g. hm <- hybridModel(some_ts)

Perhaps we should overload the method or create a wrapper similar to glm() and glm.fit() so that users can use either function, according to taste.

[dashaub]

This might cause some additional headaches when it comes time to implement parallelization. I'm planning to implement parallelization both between and within models (e.g. on a 6-core machine auto.arima runs with two cores, tbats with 2 cores, and ets with one, and nnetar with one. They are all called using foreach). This would involve lots of testing and tweaks to compare the average runtime of auto.arima/nnetar/ets/tbats/stlm models so that a relatively optimal parallelization strategy can be selected and the overall ensemble takes about as long as the slowest individual model. Custom models make this difficult. We'll also need to consider whether the custom models need a forecast() or also would work with a predict() method. Lots to consider, but I like the idea.