New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some values of percent_pattern cause percentages in "Total" row or column to report 100% #10
Comments
This is quite a nice bug you found. It seems that replacing the 3 occurrences in any_p = pattern_vars %>% str_detect("p_row|p_col") %>% any() Could you test that it fits all your cases? I just tested on the cases you gave but there might be more to it. That being said, this makes me think that This would make more sense, as you could write |
Hi Philip, |
Thank you! It fixes the issue I identified - however, testing some different cases, I think there may be a regression in the dev version. If you do this...
In the released version, the result is correct:
But in dev, all the percentages are 100%:
This might be due to an unrelated change in dev - since you get the issue even without specifying |
I finally found some time to work on this, it should be solved now (in the dev). |
The dev version looks good to me now too. And thanks for a cool package! |
Describe the bug
Some choices of
percent_pattern
cause the percentages in the "Total" row or column to report as 100%. (The examples below are the best way to illustrate.)Reproducible example
percent_pattern
with a value that simply reformats the percentage in the non-total cells. The cells in the total row/column don't change their format accordingly, but they still report the right numerical percentage.percent_pattern
with a value that applies a formula top_row
. This breaks the percentage calculation in the total row and column, so that the cells in the total column all show 100% (formatted according to the pattern), while the cells in the total row show no percentage.paste
fixes the calculation and gives the same behaviour as (1):identity
instead gives the same issue as shown in (3):This seems to be due to the code around lines 126-139 of cross_categorical.R, which does this...
...and then uses that to decide whether to do a margin calculation. The dependency on having a glue variable that starts with the letter "p" would explain why using "paste" (as in (4)) is an effective workaround, but using "identity" (as in (5)) is not.
Matrix products: default
locale:
[1] LC_COLLATE=English_United Kingdom.1252 LC_CTYPE=English_United Kingdom.1252 LC_MONETARY=English_United Kingdom.1252 LC_NUMERIC=C
[5] LC_TIME=English_United Kingdom.1252
attached base packages:
[1] stats graphics grDevices datasets utils methods base
other attached packages:
[1] crosstable_0.4.1 forcats_0.5.1 stringr_1.4.0 dplyr_1.0.8 purrr_0.3.4 readr_2.1.2 tidyr_1.2.0 tibble_3.1.6 ggplot2_3.3.5
[10] tidyverse_1.3.1
loaded via a namespace (and not attached):
[1] xfun_0.29 tidyselect_1.1.2 haven_2.4.3 colorspace_2.0-3 vctrs_0.3.8 generics_0.1.2 htmltools_0.5.2 base64enc_0.1-3 utf8_1.2.2
[10] rlang_1.0.1 pillar_1.7.0 glue_1.6.2 withr_2.4.3 DBI_1.1.2 gdtools_0.2.4 dbplyr_2.1.1 uuid_1.0-3 modelr_0.1.8
[19] readxl_1.3.1 lifecycle_1.0.1 munsell_0.5.0 gtable_0.3.0 cellranger_1.1.0 zip_2.2.0 rvest_1.0.2 evaluate_0.15 knitr_1.37
[28] fastmap_1.1.0 tzdb_0.2.0 fansi_1.0.2 broom_0.7.12 Rcpp_1.0.8 renv_0.15.2 scales_1.1.1 backports_1.4.1 checkmate_2.0.0
[37] jsonlite_1.8.0 systemfonts_1.0.4 fs_1.5.2 digest_0.6.29 hms_1.1.1 stringi_1.7.6 grid_4.1.2 cli_3.2.0 tools_4.1.2
[46] magrittr_2.0.2 crayon_1.5.0 pkgconfig_2.0.3 ellipsis_0.3.2 data.table_1.14.2 xml2_1.3.3 reprex_2.0.1 lubridate_1.8.0 rmarkdown_2.11
[55] officer_0.4.1 assertthat_0.2.1 httr_1.4.2 rstudioapi_0.13 flextable_0.6.10 R6_2.5.1 compiler_4.1.2
The text was updated successfully, but these errors were encountered: