Closed dshemetov closed 2 months ago
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.
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?
Made #323 to track those
@dshemetov what is "partial" about the fix to #293?
In my notes from our last sync, we planned 3 PRs related to the discussions in that issue:
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.
Checklist
Please:
DESCRIPTION
andNEWS.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).epiprocess
version in theDESCRIPTION
file ifepiprocess
soonepipredict
andepiprocess
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 inepi_workflow$fit$meta$train_data
, hopefully won't clobber anything there. Might be able to use...
instead of duplicatingget_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 theforecast
function to the list. I thought about doing the whole dispatch thing withforecast.epi_workflow
, but it seemed like extra boilerplate. I could see it being handy if we expectforecast
to be a clobberable function name from other packages.TODO:
predict
in vignettes and examples withforecast
Magic GitHub syntax to mark associated Issue(s) as resolved when this is merged into the default branch