Direction of One-Sided Alternatives

[fpahlke]

I am wondering if, rather than specifying the direction of alternative downstream in these other functions, it would be preferable to specify the alternative in getDesignGroupSequential - the other functions could simply extract the direction of the alternative from the resulting trialDesignGroupSequential​ object.

This way, getDesignGroupSequential​ returns appropriate one-sided boundaries for 'less than' hypotheses without having to make manual corrections. The reported boundaries, plot()​ output, and so on would be ready to use both within and outside of RPACT, avoiding potential mistakes in manually correcting output (or failing to make that correction).

Just a thought for consideration: perhaps allow directionUpper​ to be passed as an argument in both getDesignGroupSequential​ and those downstream functions. For downstream functions with one-sided designs, if directionUpper​ is NULL, the direction is extracted from the trialDesign​ object. If directions were specified in both the directionUpper​ and the trial design object, check to see if they are consistent, and throw an error if they are not.

As a programmer, I know that backwards compatibility and validation are nontrivial things, and things that seem superficially simple almost never are, and would understand if this is not worth the potential headaches.

[fpahlke]

The first solution is implemented in dev/4.0.1. In the design the critical values remain positive for directionUpper = FALSE, but the direction will be respected in sample size, power, and analysis.

[danielinteractive]

Awesome, thanks @fpahlke!