Get ratio as an attributes of sim_pw_surv and pass it to wlr

[LittleBeannie]

[nanxstats]

It may be useful to have a vignette to document the randomization ratio workflow in simtrial. I'm happy to send a PR to create a vignette with the following Mermaid JS diagram digitalized from notes above but you'll need to fill out the text.

---
config:
  theme: mc
---
flowchart TB
    A["Data input"] --> B("Simulated via <code>sim_pw_surv()</code>") & C["Custom input"]
    B -- "attr <code>ratio</code>" --> D["<code>wlr.tte_data()</code>"] & E["<code>counting_process()</code>"]
    E -- "attr <code>ratio</code>" --> F["<code>wlr.counting_process()</code>"]
    C -- "① User-defined<br>② Empirical" --> G["<code>wlr.tte_data()</code>"]
    C --> H["<code>counting_process()</code>"]
    H --> I["<code>wlr.counting_process()</code>"]
    H -.-> J["Empirical ratio calculation"]
    J --> K["User-provided ratio"] & L["No user-provided ratio"]
    K --> M["Use user's ratio"]
    L --> N["Use empirical ratio"]
    style A stroke-width:1px,stroke-dasharray: 0
    style H stroke-width:1px,stroke-dasharray: 1

[jdblischak]

Could we please convert this example to an automated test so that we can confirm that manually providing ratio = 2 returns a different result compared to using the empirical ratio via ratio = NULL?

[LittleBeannie]

Hello @jdblischak, I appreciate you bringing this to my attention. I completely agree with you that adding tests is valuable and advantageous. But I tentatively prefer to keep it as it is. My reasons are listed as follows.

First of all, since there is no equivalence between the one with ratio=2 and ratio=NULL, it's challenging to compare these two on the same scale.

Second, rather than composing my own developer tests, I should seek volunteers for independent or double programming tests, which hold more value and solidity compared to my basic developer tests.

Third, instead of including the above in the tests, I would rather keep them as examples in the help page, where users can readily distinguish the two ways to set ratio, even if they don't review the test files.

[jdblischak]

I completely agree with you that adding tests is valuable and advantageous.

I'll add the tests in a follow-up PR

First of all, since there is no equivalence between the one with ratio=2 and ratio=NULL, it's challenging to compare these two on the same scale.

I don't understand the issue with the scale. I am requesting a test that confirms that the newly added argument ratio has an effect on the results. Thus something like the below would be sufficient:

wlr_w_ratio <- x |> wlr(weight = fh(rho = 0, gamma = 0.5), ratio = 2)
wlr_wo_ratio <- x |> wlr(weight = fh(rho = 0, gamma = 0.5))
expect_false(isTRUE(all.equal(wlr_w_ratio, wlr_wo_ratio)))

Second, rather than composing my own developer tests, I should seek volunteers for independent or double programming tests, which hold more value and solidity compared to my basic developer tests.

I do not understand this perspective. The potential for better tests in the future does not remove the requirement for basic developer tests. Tests are our best method to prevent the accumulation of technical debt. As a concrete, recent example, the argument ratio of gsDesign2::fixed_design_mb() had no effect because it was not passed to the downstream sub-functions (Merck/gsDesign2#463). A basic developer test could have caught this.

Third, instead of including the above in the tests, I would rather keep them as examples in the help page, where users can readily distinguish the two ways to set ratio, even if they don't review the test files.

I was not requesting that the examples be removed. I completely agree with you that the examples section is the correct place to document this for end users. My request was to use these examples as the basis for automated tests.

[jdblischak]

I'll add some tests in a follow-up PR

[jdblischak]

I completely agree with you that adding tests is valuable and advantageous.

I'll add the tests in a follow-up PR

First of all, since there is no equivalence between the one with ratio=2 and ratio=NULL, it's challenging to compare these two on the same scale.

I don't understand the issue with the scale. I am requesting a test that confirms that the newly added argument ratio has an effect on the results. Thus something like the below would be sufficient:

wlr_w_ratio <- x |> wlr(weight = fh(rho = 0, gamma = 0.5), ratio = 2)
wlr_wo_ratio <- x |> wlr(weight = fh(rho = 0, gamma = 0.5))
expect_false(isTRUE(all.equal(wlr_w_ratio, wlr_wo_ratio)))

Second, rather than composing my own developer tests, I should seek volunteers for independent or double programming tests, which hold more value and solidity compared to my basic developer tests.

I do not understand this perspective. The potential for better tests in the future does not remove the requirement for basic developer tests. Tests are our best method to prevent the accumulation of technical debt. As a concrete, recent example, the argument ratio of gsDesign2::fixed_design_mb() had no effect because it was not passed to the downstream sub-functions (Merck/gsDesign2#463). A basic developer test could have caught this.

Third, instead of including the above in the tests, I would rather keep them as examples in the help page, where users can readily distinguish the two ways to set ratio, even if they don't review the test files.

I was not requesting that the examples be removed. I completely agree with you that the examples section is the correct place to document this for end users. My request was to use these examples as the basis for automated tests.