Allow specifying the reference group for ANCOVA analyses via `set_vars()`

[wwojciech]

Currently, the ANCOVA analysis uses the first factor level of vars$group as the reference group. This is not always convenient, as users may want to choose a different reference group without having to manually reorder or relabel the treatment factor.

This limitation becomes even more apparent in multi-arm treatment settings (see PR #520 ).

It would be useful to allow the reference level to be specified as part of the vars object created by set_vars(). This would provide a more flexible and user-friendly interface while avoiding unnecessary modifications to the underlying treatment variable.

[wwojciech]

@danielinteractive - FYI.

[tobiasmuetze]

Could you elaborate why this should be in set_vars() and maybe highlight how you envisage this to be used? It would be important to clearly distinguish this from the meaning of the references argument in impute().

[wwojciech]

Thanks @tobiasmuetze. My original motivation was that, for a multi-arm study (I am using the code from PR #520), the default ANCOVA contrasts are currently of the form trt_L1_L0, trt_L2_L0,trt_L3_L0, where L0 is implicitly taken as the first level of vars$group. I thought it would be useful to allow users to specify which treatment level should act as the reference (L0), rather than having it hard-coded as the first factor level.

However, following your comment #520 (comment) , I agree that allowing users to specify the contrasts of interest directly would be a more general solution. It would naturally cover my use case (e.g., "Active Agent A" - "Placebo" and "Active Agent B" - "Placebo"), while also supporting comparisons between two active treatments when needed. In that case, there would no longer be a need for a separate mechanism to specify the reference level, as it would be implied by the requested contrasts.

[tobiasmuetze]

My preference would be to address this by allowing the user to specify contracts as part of #520

[wwojciech]

My preference would be to address this by allowing the user to specify contracts as part of #520

Agree. Thank you @tobiasmuetze for checking on this.