Activity

1. brookslogan commented on Feb 10, 2026

   

   brookslogan

   on Feb 10, 2026

   ContributorAuthor

   More actions

   Also, it seems like one of "extend_ahead" / "adjust_lags" is probably aligning with the wrong lags in training data, and the one that's not may or may not have issues if the max time_value isn't the same for every epikey (from #409 I'm guessing maybe it is a problem?). In docs we should note these properties. And tell users when to use what thing.
2. docxology commented on Sep 16, 2026

   

   docxology

   on Sep 16, 2026

   More actions

   Upstream supplement draft — H3 → comment on #472

   Disposition: DOWNGRADED to supplement. #472 ("Documentation for arx_args_list(adjust_latency) is incomplete", open) asks whether "locf" was deprecated. It was not — it is still advertised — and the functional truth behind #472's question is worse than a docs gap: in arx_forecaster() the option is a silent no-op. Post this as a comment on #472 (or split out as its own issue if the maintainers prefer).

   ---

   Answering the "locf" question in #472 with code evidence from HEAD 43b352f / main 7d8539b (v0.2.7):

   "locf" is still advertised — R/arx_forecaster.R:331:

   adjust_latency = c("none", "extend_ahead", "extend_lags", "locf"),

   … and the roxygen describes it. But the latency block in arx_forecaster() only branches on "extend_ahead" and "extend_lags" (R/arx_forecaster.R:171-184); there is no branch for "locf". Selecting it adds no step_adjust_latency() at all — silently — while forecast_date still defaults to as_of (R/arx_forecaster.R:60-65, :147-158). So the answer to #472's "did we deprecate this?" is effectively no, but in arx_forecaster() it does nothing.

   arx_classifier() aborts loudly for the same input ("only extend_ahead is currently supported", class epipredict__arx_classifier__adjust_latency_unsupported_method, R/arx_classifier.R:315-321), which suggests the forecaster gap is unintentional.

   Repro (code-reading analysis; I don't have R available, so please confirm)

   library(epipredict)
   library(dplyr)
   
   jhu <- covid_case_death_rates |> filter(time_value >= as.Date("2021-12-01"))
   attributes(jhu)$metadata$as_of <- as.Date(max(jhu$time_value) + 5)  # latent as_of
   
   out <- arx_forecaster(
     jhu, "death_rate_7d_av", c("death_rate_7d_av", "case_rate_7d_av"),
     args_list = arx_args_list(adjust_latency = "locf")
   )
   
   recipes::tidy(out$epi_workflow$pre$recipe)   # no step_adjust_latency anywhere
   unique(out$predictions$forecast_date)        # stamped from as_of, unadjusted model

   Notably, tests/testthat/test-snapshots.R:99-109 constructs exactly this case (arx4 with adjust_latency = "locf") and then asserts nothing about it — the snapshot check that follows is on arx3, not arx4.

   Suggested resolution

   Either add the missing branch in arx_forecaster() (mirroring the classifier's fixed-forecast-date call), or abort for "locf" there the way the classifier does — and then the #472 docs fix becomes unambiguous either way. A regression test would close the loop (arx4 in test-snapshots.R is a natural place). Also related: #389 (locf/extend tests for the classifier).