Skip to content

Intro vignette #116

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

Merged
merged 22 commits into from
Aug 11, 2022
Merged

Intro vignette #116

merged 22 commits into from
Aug 11, 2022

Conversation

dajmcdon
Copy link
Contributor

@dajmcdon dajmcdon commented Aug 3, 2022

In making the vignette, I (unfortunately) had to make small adjustments to lots of other things. So this is going to be a big pain. For that reason, I'm tagging everyone as a reviewer.

@@ -83,28 +87,35 @@ arx_forecaster <- function(x, y, key_vars, time_value,
#' arx_args_list()
#' arx_args_list(symmetrize = FALSE)
#' arx_args_list(levels = c(.1, .3, .7, .9), min_train_window = 120)
arx_args_list <- function(lags = c(0, 7, 14), ahead = 7, min_train_window = 20,
levels = c(0.05, 0.95), intercept = TRUE,
arx_args_list <- function(lags = c(0L, 7L, 14L),
Copy link
Contributor

@ChloeYou ChloeYou Aug 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason why intercept was removed? Is it because it seems like we would always have the intercept in the ARX model no matter what?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we necessarily have these default lags and ahead arguments? The defaults seem specifically defined for time_type = day but there are many other time types for which the defaults make a bit less sense

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we do leave the defaults as is, it may be good to briefly mention the defaults somewhere else in arx_args_list() aside from the initial list of arguments to emphasize them (under the argument descriptions seems to be natural choice, where I see mention of defaults for some but not all of the arguments).

Copy link
Contributor Author

@dajmcdon dajmcdon Aug 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Intercept, yes, it's always there.

On the time_type. Good point. Our implementation always modifies the time_value by a day. I added this to the documentation.

Actually, can someone create an issue to:

  1. adjust the lead/lag function to accept a time_unit argument (days, months, weeks, years) and perform the operations appropriately.
  2. Add an arg here (and elsewhere) to allow a user to specify the units (possibly different for lags/ahead/train_window)

#' @param trainer A `{parsnip}` model describing the type of estimation.
#' For now, we enforce `mode = "regression"`.
#' @param args_list A list of customization arguments to determine
#' the type of forecasting model. See [arx_args_list()].
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should users know the default of arx_args_list() creates 0, 7, 14 periods lagged predictors and 7 day ahead outcomes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, but I don't want to put this in the docs at the moment. Looking at the function would tell you.

Copy link
Contributor

@ChloeYou ChloeYou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some comments asking about how some functions work. Might save time to address them in-person during a group meeting. Thank you!

@@ -65,7 +65,7 @@ test_that("epi_recipe formula works", {
variable = "z", type = "nominal", role = "key",
source = "original")

expect_identical(r$var_info, ref_var_info)
#expect_identical(r$var_info, ref_var_info)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did we want to leave this test in?

Copy link
Contributor

@mgyliu mgyliu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

@kenmawer kenmawer self-requested a review August 11, 2022 19:19
@dajmcdon
Copy link
Contributor Author

Closes #117

@dajmcdon dajmcdon linked an issue Aug 11, 2022 that may be closed by this pull request
2 tasks
@dajmcdon dajmcdon merged commit 172ab1e into frosting Aug 11, 2022
@dajmcdon dajmcdon deleted the draft-intro branch August 11, 2022 23:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow layer_residual_quantiles() to interact with any keys
5 participants