Open brookslogan opened 1 year ago
While it generally makes sense for steps to add the columns they create as predictors (which is what I'm guessing happens in step_population_scaling
), I'm not sure if it makes sense here, because population scaling is so transformative that maybe it needs to be treated as "the new raw data" / raw data columns rather than immediately as predictors. (While there might be some cases where this isn't desired, like trying to estimate the "effective" population by regressing count data against rate data, I'd guess that those cases are less common, and can be handled by manually adding roles or doing a step_epi_lag(var_scaled, lag=0)
.)
Agreed. Default step_population_scaling()
should NOT create roles by default. I suspect the whole interface could use some cleaning.
See how the predictor selection varies when we use "analogous" workflows with vs. without population scaling (based on the example for
step_population_scaling
):Created on 2023-04-07 by the reprex package (v2.0.1)
In this case, the workflow with scaling has a lag-0 predictor, while the one without does not. If, instead, we were to use
lag = c(0, 7, 14)
, then both versions would have a lag-0 predictor, but the one with scaling would have two copies of it, and might cause issues for some engines.