pharmaverse / pharmaverse/rtables

`ref_group` should not be limited to displayed split levels

Open
#1,116 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
R
Stars
260
Forks
53
PR merge metrics
No merged PRs in 30d

Description

Currently, ref_group appears to require the reference level to be included in the levels retained by split_fun. For example:

table(DM$ARM)

     A: Drug X     B: Placebo C: Combination 
           121            106            129

lyt <- basic_table() |>
  split_cols_by(
    "ARM",
    split_fun = keep_split_levels("A: Drug X"),
    ref_group = "B: Placebo"
  ) |>
  analyze("AGE")

build_table(lyt, DM)

results in:

Error in .add_ref_extras(spl, df, ret) : length(ref_ind) == 1 is not TRUE

From the user perspective, this seems to be an unnecessary and unreasonable limitation. I think ref_group should be allowed to be any valid level of the split variable, even if that level is not displayed or not observed in the data.

This includes:

  • A factor level that exists but is not observed in the data.
  • A factor level that is not present at all - in this case, perhaps a warning would be appropriate.

Simply put, the split function controls what is displayed, while ref_group should be allowed to specify the reference level independently.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the issue using the supplied split_cols_by(), keep_split_levels(), ref_group, and build_table() example. Start at the .add_ref_extras error path and verify that ref_group can refer to an un displayed or unobserved valid level independently of the levels retained by split_fun, with the requested warning behavior for an entirely absent level.

Written by the indexing model from the issue text.

Assessment

Tech stack
r
Domain
data
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.