Skip to content

Conversation

dshemetov
Copy link
Contributor

@dshemetov dshemetov commented Apr 10, 2025

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

Ran across this issue when writing YJ tests:

r$> # add quantile_level to epi_df other_keys, if epi_df
      tib <- tibble(geo_value = c("a", "b"), time_value = as.Date(c("2021-01-01", "202
    1-01-02")), d1 = d1, d2 = d2)

r$> epi_df <- tib %>% as_epi_df() %>% pivot_quantiles_longer(d1)

r$> epi_df
An `epi_df` object, 6 x 5 with metadata:
* geo_type  = custom
* time_type = day
* as_of     = 2025-04-10 15:11:56.915382

# A tibble: 6 × 5
  geo_value time_value        d2 d1_value d1_quantile_level
  <chr>     <date>     <qtls(3)>    <int>             <dbl>
1 a         2021-01-01     [2.5]        1              0.25
2 a         2021-01-01     [2.5]        2              0.5 
3 a         2021-01-01     [2.5]        3              0.75
4 b         2021-01-02     [3.5]        2              0.25
5 b         2021-01-02     [3.5]        3              0.5 
6 b         2021-01-02     [3.5]        4              0.75

Not a big deal, but probably good to strive for epi_df key uniqueness, rather than breaking the model.

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

  • Resolves #{issue number}

@dshemetov dshemetov requested a review from dajmcdon as a code owner April 10, 2025 22:12
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.

1 participant