OO approach instead of string approach for API about forecasthybrid HOT 2 CLOSED

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.

from forecasthybrid.

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.

from forecasthybrid.