forecastML v1.0.0 and a list of breaking changes

[nredell]

forecastML v1.0.0 will probably drop in late July (I don't work on this full time so who knows). That's cool. What's not cool are breaking changes. I really want forecastML to have an API that is as close as possible to that in https://tidyverts.org/. The ML and statistical approaches to forecasting are complementary and I can easily see both fable and forecastML being used in the same script. API consistency will reduce switching costs.

This issue will contain a list of breaking changes that I'm planning. All future releases of forecastML will be backward compatible with v1.0.0. Eventually, I'll make a pkgdown site that will organize these changes and the general package structure, but for now we have this.

• fill_gaps()

  • The date_col argument will be changed to index and will take name or positional values.
  • The groups argument will be changed to key and will take name or positional values.

• create_lagged_df()

  • The outcome_col argument will be changed to outcome and will take name or positional values.
  • The groups argument will be changed to key and will take name or positional values.

• predict()

  • The prediction_function argument will likely change to predict_function.

• combine_forecasts()

  • The combine_forecasts(..., ) argument will be replaced with combine_forecasts(forecasts, ) to work better with many models. The forecasts argument will optionally be a list for 1 model and must be a list for >1 models.

• forecasting

  • Datasets of forecast results have the forecast column named forecast_period; this will be changed to index.

[mitchelloharawild]

Interested to see how this goes, please feel free to ask any questions for integration with fable. For full integration with fable you could also consider a wrapper package (much like https://github.com/mitchelloharawild/fable.prophet/) which provides a fable interface to the forecastML library. Some rough guidelines on how a fable model and its methods can be written is found here: https://fabletools.tidyverts.org/dev/articles/extension_models.html

API consistency will reduce switching costs.

Are you referring to mental costs in switching between interfaces, or computational costs in translating between data structures?

[nredell]

Thanks for dropping by. I wasn't aware of fable.prophet...actually only really looked at fabletools for the first time a week or so ago so your timing is good. fable.prophet looks fairly lightweight which is nice.

Mental switching costs. I'd like the forecastML API to look familiar even if a given function isn't calling tidyverts under the hood. It'd be difficult to maintain a complete start to end fable pipeline in this package because I'm aiming for a ridiculous amount of flexibility like ensembling a multi-output Julia neural network with direct forecast linear models in R while getting the data from a tiledb setup. Super generic.

At the same time, I'll probably take a dependency on fable in a couple places because I really like the use of vctrs for things like the prediction interval distributions, and I'm a fan of less redundancy in the R universe.

Thanks for the offer. I'll probably swing by sooner or later for some weird subclass that I'll try to implement.

[mitchelloharawild]

Sounds good.

At the same time, I'll probably take a dependency on fable in a couple places because I really like the use of vctrs for things like the prediction interval distributions, and I'm a fan of less redundancy in the R universe.

Unless you need the models provided by fable, at most you should need to depend on fabletools. However if you're just interested in prediction intervals and distributions, I've ripped this functionality out into a new package (https://github.com/mitchelloharawild/distributional) which fabletools will use in the next release.