predict() does not work when variables are transformed within formula
Closed this issue · 2 comments
lang-benjamin commented
predict()
won't work if some variable is transformed within the formula specificaton. For example:
library(mmrm)
#> Warning: package 'mmrm' was built under R version 4.2.3
fit <- mmrm(
formula = log(FEV1) ~ RACE + SEX + ARMCD * AVISIT + us(AVISIT | USUBJID),
data = fev_data
)
predict(fit)
#> Error in eval(formula_parts$full_formula[[2]], envir = data): object 'FEV1' not found
# session info
sessionInfo()
#> R version 4.2.2 (2022-10-31 ucrt)
#> Platform: x86_64-w64-mingw32/x64 (64-bit)
#> Running under: Windows 10 x64 (build 19045)
#>
#> Matrix products: default
#>
#> locale:
#> [1] LC_COLLATE=German_Germany.utf8 LC_CTYPE=German_Germany.utf8
#> [3] LC_MONETARY=German_Germany.utf8 LC_NUMERIC=C
#> [5] LC_TIME=German_Germany.utf8
#>
#> attached base packages:
#> [1] stats graphics grDevices utils datasets methods base
#>
#> other attached packages:
#> [1] mmrm_0.3.11
#>
#> loaded via a namespace (and not attached):
#> [1] Rcpp_1.0.12 TMB_1.9.10 pillar_1.9.0 compiler_4.2.2
#> [5] R.methodsS3_1.8.2 R.utils_2.12.3 tools_4.2.2 digest_0.6.34
#> [9] evaluate_0.23 lifecycle_1.0.4 tibble_3.2.1 checkmate_2.3.1
#> [13] nlme_3.1-160 R.cache_0.16.0 lattice_0.20-45 pkgconfig_2.0.3
#> [17] rlang_1.1.2 reprex_2.1.0 Matrix_1.6-5 cli_3.6.2
#> [21] rstudioapi_0.15.0 yaml_2.3.8 parallel_4.2.2 xfun_0.42
#> [25] fastmap_1.1.1 withr_3.0.0 styler_1.10.2 stringr_1.5.1
#> [29] knitr_1.45 generics_0.1.3 fs_1.6.3 vctrs_0.6.5
#> [33] grid_4.2.2 glue_1.7.0 fansi_1.0.6 Rdpack_2.6
#> [37] rmarkdown_2.26 purrr_1.0.2 magrittr_2.0.3 backports_1.4.1
#> [41] htmltools_0.5.7 rbibutils_2.2.16 utf8_1.2.4 stringi_1.8.3
#> [45] R.oo_1.26.0
Created on 2024-04-26 with reprex v2.1.0
danielinteractive commented
Thanks @lang-benjamin, I think we very recently fixed this in #438, can you please the try the current
development version if it works for you?
lang-benjamin commented
Thanks. Yes, it works with the development version! I was looking at closed issues, but apparently overlooked this one.