Skip to content

Convert ARX forecaster to the correct format #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dajmcdon opened this issue Mar 6, 2022 · 1 comment
Closed

Convert ARX forecaster to the correct format #3

dajmcdon opened this issue Mar 6, 2022 · 1 comment
Labels
question Further information is requested

Comments

@dajmcdon
Copy link
Contributor

dajmcdon commented Mar 6, 2022

The proper forecaster signature should be:

prob_arx <- function(x, y, geo_value, time_value, args = prob_arx_args())

All args not in the epi_ data frame should be in an args list.

@brookslogan
Copy link
Contributor

I think we may want to consider instead

function(df, args = prob_arx_args())

or something mirroring fable, whatever its interface is.

As:

  • More commonly than not, users will probably will want (x,y,geo_value,time_value) in a data frame format to pass to a fitter function like lm, rq, etc. If they are given df as an input, this is less trouble.
  • The code to call a forecaster / list of forecasters seems easier:
fetch_latest_data_from_my_favorite_api() %>% prob_arx(my_args)
as_of(archive, forecast_date) %>% prob_arx(my_args)
snapshot = as_of(archive, forecast_date)
lapply(forecasters_with_args, function(forecaster_with_args) {
  forecaster_with_args$forecaster(snapshot, forecaster_with_args$args)
})

as opposed to something with do.call or tidy_eval or things along those lines. Although I'm not sure if taking df as an argument would make things easier or harder when using epi[x]_slide; I forget if slider expects functions to take in the columns or the df.

@dshemetov dshemetov added the question Further information is requested label Mar 9, 2022
@dajmcdon dajmcdon mentioned this issue Mar 26, 2022
kenmawer added a commit that referenced this issue Jun 7, 2022
Issue #22 of uniting lag and ahead functions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants