in_rows loses .formats (at least when used with analyze_colvars)

[danielinteractive]

Example:

colfuns <- list(
  function(x) {
    in_rows(.list = list(a = mean(x)), .formats = "xx.x")
  },
  function(x) {
    in_rows(.list = list(a = median(x)), .formats = "xx.xxxx")
  }
)

l <- basic_table() %>% split_cols_by("ARM") %>%
  split_cols_by_multivar(c("value", "pctdiff")) %>%
  split_rows_by("RACE", split_label = "ethnicity", split_fun = drop_split_levels) %>%
  summarize_row_groups() %>%
  analyze_colvars(afun = colfuns)

l
library(dplyr)
ANL <- DM %>% mutate(value = rnorm(n()), pctdiff = runif(n()))

build_table(l, ANL)

So here the statistic a is just always printed with like all digits it has rather than the requested formats.

Session info:

R version 3.6.3 (2020-02-29)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 9 (stretch)

Matrix products: default
BLAS/LAPACK: /usr/lib/libopenblasp-r0.2.19.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8     LC_MONETARY=en_US.UTF-8   
 [6] LC_MESSAGES=C              LC_PAPER=en_US.UTF-8       LC_NAME=C                  LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] rtables_0.3.2.17.9031 magrittr_1.5          dplyr_0.8.5          

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.4.6     fansi_0.4.1      digest_0.6.25    packrat_0.5.0    crayon_1.3.4     assertthat_0.2.1 R6_2.4.1         lifecycle_0.2.0 
 [9] pillar_1.4.3     cli_2.0.2        rlang_0.4.5      rstudioapi_0.11  vctrs_0.2.4      ellipsis_0.3.0   tools_3.6.3      glue_1.4.0      
[17] purrr_0.3.4      compiler_3.6.3   pkgconfig_2.0.3  htmltools_0.4.0  tidyselect_1.0.0 tibble_3.0.1 

[gmbecker]

Hi @danielinteractive, this is a similar issue to what I said in #112 (the bug that I found remaining there not withstanding). The key thing about this is that .formats for in_rows sets row formats.

So while, similar to #112 it isn't doing what it should do here, what it should do is still not what you want. If you want different formats in the same row, regardless of how you're getting them, they need to be cell formats, not row formats.

And unlike in 112, in this case the "right way" does work:

library(rtables)
library(dplyr)
ANL <- DM %>% mutate(value = rnorm(n()), pctdiff = runif(n()))

colfuns2 <- list(
  function(x) {
    in_rows(.list = list(a = rcell(mean(x), format = "xx.x")))
  },
  function(x) {
    in_rows(.list = list(a = rcell(median(x), format = "xx.xxxx")))
  }
)
l2 <- basic_table() %>% split_cols_by("ARM") %>%
  split_cols_by_multivar(c("value", "pctdiff")) %>%
  split_rows_by("RACE", split_label = "ethnicity", split_fun = drop_split_levels) %>%
#  summarize_row_groups() %>%
  analyze_colvars(afun = colfuns2)

build_table(l2, ANL)

gives me

> build_table(l2, ANL)
                               A: Drug X        B: Placebo       C: Combination  
                            value   pctdiff   value   pctdiff   value    pctdiff 
---------------------------------------------------------------------------------
ASIAN                                                                            
  a                           0     0.4599     0.1    0.4826     0.1       0.41  
BLACK OR AFRICAN AMERICAN                                                        
  a                          0.2    0.5468    -0.2     0.596     0.2      0.5846 
WHITE                                                                            
  a                          0.2    0.6412    -0.3    0.4907     0.2      0.4295 

As desired.

[gmbecker]

@danielinteractive Looking at this more I've (somewhat experimentally, but i do expect it to stick) changed the in_rows() .formats argument to explicitly mean cell formats, not row formats. Do note that .indent_mods and .labels are still row entities, and when you cbind things together or when you use them differently in analyze_colvars that isn't a coherent specification and the disagreeing ones will be ignored.

Anyway, thanks for the reports!

[danielinteractive]

Thanks a lot @gmbecker !