feat: add forecast method

[dshemetov]

Checklist

Please:

• Make sure this PR is against "dev", not "main".
• Request a review from one of the current epipredict main reviewers:
  dajmcdon.
• Make sure to bump the version number in DESCRIPTION and NEWS.md.
  Always increment the patch version number (the third number), unless you are
  making a release PR from dev to main, in which case increment the minor
  version number (the second number).
• Describe changes made in NEWS.md, making sure breaking changes
  (backwards-incompatible changes to the documented interface) are noted.
  Collect the changes under the next release number (e.g. if you are on
  0.7.2, then write your changes under the 0.8 heading).
• Consider pinning the epiprocess version in the DESCRIPTION file if
  • You anticipate breaking changes in epiprocess soon
  • You want to co-develop features in epipredict and epiprocess

Change explanations for reviewer

A very simple PoC we discussed adding the forecast function. Not sure if I stored the train_data in the right place, currently in epi_workflow$fit$meta$train_data, hopefully won't clobber anything there. Might be able to use ... instead of duplicating get_train_data args (though might be moot if we're aiming to deprecate that function anyway).

The changes in _pkgdown.yml are mostly whitespace changes from my YAML linter (it likes that indent setting I guess). The only actual change was adding the forecast function to the list. I thought about doing the whole dispatch thing with forecast.epi_workflow, but it seemed like extra boilerplate. I could see it being handy if we expect forecast to be a clobberable function name from other packages.

TODO:

• more tests, with other arguments
• replace uses of predict in vignettes and examples with forecast

Magic GitHub syntax to mark associated Issue(s) as resolved when this is merged into the default branch

• Partial fix to Add forecast() method and "deprecate" get_test_data() #293

[dajmcdon]

• Major change: forecast needs to be a method, not a standalone.
• Minor issue: we should perhaps think about how many of the tests should be pivoted. I'm not sure it's a bad idea to duplicate or keep some as is to ensure that both options continues to work going forward.

[dshemetov]

Thanks for the review. Addressed your comments and the major point about forecast. Thinking we should handle the suppressWarning thing somewhere else, it seems to be kind of a rabbit hole (the answer isn't an easy "yea, no more warnings").

As for the tests comment, there are still many tests that I did not pivot over and those were the ones that used a non-standard new_data setting. I also have a test to compare the output of a forecast() call with an equivalent predict() call. So I don't feel like predict() is losing much in test coverage.

[dajmcdon]

On the warnings, it used to be that running a forecaster would always warn (because the data had as_of sometime in the past). I removed that warning. But all these others should be fixed. Agreed out of scope, but now that you've identified the problematic ones, can you create an issue for them?

[dshemetov]

Made #323 to track those

[dajmcdon]

Just a small suggestion for the method itself. Hopefully, you can just accept (assuming you agree) and CI will still pass.

[dajmcdon]

@dshemetov what is "partial" about the fix to #293?

[dshemetov]

In my notes from our last sync, we planned 3 PRs related to the discussions in that issue:

• Add a forecast() function (this PR)
• Rewrite the get_test_data() function (tbd)
• Change predict to “join new data onto old and forecast” (tbd)

I'm happy to tackle the latter two in the coming months, though we'll probably need to sync and clarify how we're going to tackle those.