Tutorials › Response-Adaptive Randomization › Handling Zero Counts and Undefined Plug-In Targets

Doubly Adaptive Biased Coin Designs · Tutorial 171 of 501

Handling Zero Counts and Undefined Plug-In Targets

Learn to detect when a response-based target cannot be evaluated and choose a prespecified, reproducible rule for handling the undefined calculation.

Advanced 10 min read

What You'll Learn

  • Define the response estimates and target-map inputs that can fail at zero counts or boundary estimates.
  • Distinguish an undefined target from a defined target at the boundary.
  • Apply Beta-pseudocount smoothing and calculate its effect on example targets.
  • Compare smoothing with delayed updates and prespecified fallback targets.
  • Use implementation checks to detect undefined values and document safeguards.

Why a Plug-In Target Can Fail

A response-adaptive design uses observed outcomes to update its target allocation. The calculation is usually described compactly: estimate response parameters from the data, then substitute those estimates into a target map. That substitution is valid only if the estimates exist and lie in the domain where the map is defined. Early in a trial, an arm may have no observations; later, a small sample may contain only successes or only failures. Either situation can make an otherwise valid formula impossible to evaluate.

This is not merely a numerical inconvenience. An undefined target leaves the design without a specified target for that update. Replacing the result with zero, a previous value, or an arbitrary small number changes the rule. A sound implementation therefore specifies in advance what data states trigger a safeguard and exactly what calculation is used instead.

Definition: For \(K\) treatment arms, let \(N_k(t)\) be the number of participants assigned to arm \(k\) by time \(t\), and let \(S_k(t)\) be the number of observed binary successes in that arm. When \(N_k(t)>0\), the empirical success-rate estimate is \(\hat p_k(t)=S_k(t)/N_k(t)\). A target map \(\boldsymbol{\rho}\) takes a vector of response parameters \(\boldsymbol{p}=(p_1,\ldots,p_K)\) in its domain \(\mathcal D\) and returns target shares \(\boldsymbol{\rho}(\boldsymbol{p})=(\rho_1,\ldots,\rho_K)\), with \(\rho_k\geq 0\) and \(\sum_{k=1}^K\rho_k=1\). The plug-in target is \(\boldsymbol{\rho}(\hat{\boldsymbol{p}}(t))\), provided the estimates exist and \(\hat{\boldsymbol{p}}(t)\in\mathcal D\).

A zero count, \(N_k(t)=0\), makes \(S_k(t)/N_k(t)\) undefined. It does not imply that the response probability is zero, and it does not supply an estimate of that probability. A boundary estimate is different: if every observed response in an arm is a success, then \(\hat p_k=1\); if every response is a failure, then \(\hat p_k=0\). These estimates are defined, but a target map may or may not accept them.

For example, the Bernoulli standard deviation is \(\sqrt{p_k(1-p_k)}\), which is defined at \(p_k=0\) and \(p_k=1\) and equals zero there. A target map that divides by a sum of such standard deviations is undefined if that sum is zero. A map involving \(\log(p_k/(1-p_k))\) is undefined at either boundary. In contrast, a target map that is defined on the closed interval from zero to one may produce a valid boundary target. The correct diagnosis depends on the actual formula, not on the word “boundary.”

Prespecifying a Safeguard

A safeguard is part of the allocation rule, not an informal repair made after seeing a problematic value. It should specify the trigger, the replacement calculation, and what is recorded. Three common choices are smoothing the response estimates, delaying target updates until a stated data condition is met, or using a fixed fallback target when the plug-in calculation is unavailable. These choices are not interchangeable: they define different rules and can produce different targets.

For binary outcomes, one simple smoothing rule adds positive pseudocounts \(a\) and \(b\) for successes and failures:

$$ \tilde p_k(t)=\frac{S_k(t)+a}{N_k(t)+a+b}, \qquad a>0,\quad b>0. $$

The same values of \(a\) and \(b\) are used for every arm unless a different arm-specific rule is explicitly prespecified. This estimate is defined even when \(N_k(t)=0\), and it is strictly between zero and one for any finite count. It can therefore be used as an input to many target maps that require interior response estimates.

The formula also shows what smoothing does. When \(N_k(t)>0\), write \(\hat p_k=S_k/N_k\). Then

$$ \tilde p_k = \frac{N_k}{N_k+a+b}\hat p_k + \frac{a+b}{N_k+a+b}\frac{a}{a+b}. $$

Thus the smoothed estimate is a weighted average of the observed rate and the fixed reference rate \(a/(a+b)\); the observed rate receives more weight as the count grows. For \(a=b=1\), the reference rate is one-half. This is also the posterior mean under a Beta\((a,b)\) prior with a binomial response model, but the formula can be used as a prespecified regularization rule without making a Bayesian analysis the goal of the design.

Smoothing does not establish that every target map is defined: its domain still has to be checked. Nor does it settle whether the resulting assignment rule has acceptable randomization properties. It only supplies response estimates for the target calculation. The safeguard and the map should be evaluated together.

Worked Example: An Arm Has No Observed Responses

Suppose a two-arm design uses the illustrative target map \(\rho_1(p_1,p_2)=\sigma_1/(\sigma_1+\sigma_2)\), where \(\sigma_k=\sqrt{p_k(1-p_k)}\), and \(\rho_2=1-\rho_1\). At an update, arm 1 has no participants, while arm 2 has 4 successes among 6 participants. Show why the raw plug-in target is unavailable and calculate the target using \(a=b=1\) smoothing.

The observed rate in arm 2 is \(\hat p_2=4/6=0.6667\), but \(\hat p_1=S_1/N_1=0/0\) is undefined. Therefore the raw plug-in target cannot be evaluated: the target map requires both response probabilities.

With the prespecified pseudocount rule, \(\tilde p_1=(0+1)/(0+2)=0.5000\) and \(\tilde p_2=(4+1)/(6+2)=0.6250\). The corresponding standard deviations are \(\tilde\sigma_1=\sqrt{0.5(0.5)}=0.5000\) and \(\tilde\sigma_2=\sqrt{0.625(0.375)}=\sqrt{0.234375}=0.4841\). Thus

$$ \tilde\rho_1 = \frac{0.5000}{0.5000+0.4841} \approx 0.5081, \qquad \tilde\rho_2=1-0.5081=0.4919. $$

Under this specified smoothing rule, the target shares are about 50.81% and 49.19%. They are target shares, not a claim that the next participant must be assigned in those exact proportions.

Boundary Estimates: Defined Inputs, Possibly Undefined Targets

A boundary estimate should be passed through the target map only after checking its domain and formula. The next example uses the same illustrative standard-deviation target. If one arm has an estimated standard deviation of zero and the other has a positive standard deviation, the denominator is positive and the target is defined. If both estimated standard deviations are zero, the denominator is zero and the target is undefined.

Worked Example: Both Arms Have Boundary Estimates

Suppose arm 1 has 5 successes among 5 participants and arm 2 has 0 successes among 5 participants. Use the standard-deviation target from the previous example. First evaluate the raw plug-in calculation; then apply \(a=b=1\) smoothing.

The raw estimates are \(\hat p_1=5/5=1\) and \(\hat p_2=0/5=0\). Both estimated standard deviations are zero: \(\sqrt{1(1-1)}=0\) and \(\sqrt{0(1-0)}=0\). Hence the raw formula for arm 1 is \(0/(0+0)\), which is undefined. The response estimates themselves exist; it is the target calculation that fails.

With smoothing, \(\tilde p_1=(5+1)/(5+2)=6/7=0.8571\) and \(\tilde p_2=(0+1)/(5+2)=1/7=0.1429\). Their estimated variances are both \((6/7)(1/7)=6/49\), so both standard deviations are \(\sqrt{6/49}\). Therefore

$$ \tilde\rho_1 = \frac{\sqrt{6/49}}{\sqrt{6/49}+\sqrt{6/49}} =0.5000, \qquad \tilde\rho_2=0.5000. $$

The smoothed target is defined and equal across arms for this example. That result follows from the selected smoothing rule and target map; it is not a general conclusion that opposing boundary estimates should always produce equal targets.

Other maps fail differently. Consider the illustrative map \(\rho_1(p_1,p_2)=\operatorname{logit}^{-1}\{\operatorname{logit}(p_1)-\operatorname{logit}(p_2)\}\), where \(\operatorname{logit}(p)=\log\{p/(1-p)\}\). Its input must be strictly between zero and one. Thus even a single all-success or all-failure arm makes the raw calculation undefined, although the standard-deviation target might remain defined in a corresponding one-boundary case.

Worked Example: Smoothing Inputs to a Logit-Based Target

For this illustrative map, suppose arm 1 has 3 successes among 3 participants and arm 2 has 1 success among 4 participants. Calculate the raw and smoothed status using \(a=b=1\).

The raw estimate for arm 1 is \(\hat p_1=1\), so \(\operatorname{logit}(\hat p_1)=\log\{1/(1-1)\}\) is undefined. The raw plug-in target is therefore unavailable, even though arm 2 has the interior estimate \(\hat p_2=1/4\).

The smoothed estimates are \(\tilde p_1=(3+1)/(3+2)=4/5=0.8000\) and \(\tilde p_2=(1+1)/(4+2)=2/6=1/3\). Their logit difference is \(\log(0.8/0.2)-\log\{(1/3)/(2/3)\}=\log(4)-\log(1/2)=\log(8)\). Consequently,

$$ \tilde\rho_1 = \frac{\exp\{\log(8)\}}{1+\exp\{\log(8)\}} = \frac{8}{9} \approx 0.8889, \qquad \tilde\rho_2\approx 0.1111. $$

The target is now evaluable because both smoothed inputs are interior. The numerical result is specific to this target definition and these counts.

Justification, Diagnostics, and Alternatives

The key justification for pseudocount smoothing is elementary but useful: for \(a,b>0\), \(S_k+a>0\), \(N_k+a+b>S_k+a\) whenever \(0\leq S_k\leq N_k\), and hence \(0<\tilde p_k<1\). This includes the empty-arm case, for which \(\tilde p_k=a/(a+b)\). Smoothing therefore removes undefined empirical rates at zero counts and avoids exact boundary inputs for finite binary samples. It does not guarantee that a target map’s other operations, such as division by a zero sum, are safe.

An implementation should check the inputs and outputs at each update. In particular, record whether each arm has observations, whether any response estimate is at a boundary, whether the target-map calculation is finite, and whether the resulting shares are nonnegative and sum to one within numerical tolerance. A non-finite value, a failed domain check, or a sum that does not equal one signals a calculation or implementation problem. Record which safeguard was invoked and the values used; otherwise a valid fallback can be difficult to distinguish from a coding error.

The main alternatives have different consequences:

ApproachRule when the raw calculation failsMain consideration
SmoothingReplace raw response estimates with a prespecified regularized estimate.Produces an update from early data but makes the target depend on the pseudocount choice.
Delayed updateDo not recompute the target until a stated data condition is met.Avoids a target calculation from insufficient data, but requires a defined rule for the period before that condition is met.
Fallback targetUse a prespecified target when the plug-in target is undefined.Is transparent if its trigger and value are fixed in advance, but does not use the unavailable plug-in calculation.

A defensible design states its choice before the trial, including any threshold for delaying updates, the pseudocount values, or the fallback target. It also states what happens if the safeguard itself does not produce a valid target. A safeguard should not be changed selectively after observing outcomes.

Common Mistake and Limitations

Common mistake: “An arm has no observed successes, so its estimated response probability is zero; I can substitute zero into the target map.” This confuses a zero success count with a zero success rate. If the arm has no participants, the empirical rate is \(0/0\), not zero. Even with participants, an observed rate of zero is a boundary estimate, and the target map may not be defined there. The correction is to check the count and the map’s domain, then apply the prespecified safeguard if needed.

A second mistake is treating every boundary estimate as an undefined target. A map may be defined at a boundary, as the standard-deviation formula is when only one arm has zero estimated variance. Check the full expression, including denominators and transformations, rather than rejecting boundary values automatically.

Smoothing is not a neutral repair. It changes the input estimates and can alter the target, especially when counts are small; different pseudocounts or reference rates can produce different updates. A fallback or delayed update also changes the design relative to a raw plug-in rule. These safeguards address undefined calculations, but they do not by themselves guarantee desirable assignment probabilities or resolve other design constraints.

Key takeaway: First determine whether a response estimate is missing or merely at a boundary; next check whether the actual target map is defined at those inputs. If not, use a prespecified, recorded safeguard rather than an improvised numerical substitution.

Check Your Understanding

Answer each question, then compare your reasoning with the solutions.

  1. An arm has \(N_k=0\) and \(S_k=0\). Is its empirical response-rate estimate zero or undefined?
  2. Under \(a=b=1\) smoothing, what is \(\tilde p_k\) when an arm has 2 successes among 3 participants?
  3. For the target \(\rho_1=\sigma_1/(\sigma_1+\sigma_2)\), with \(\sigma_k=\sqrt{p_k(1-p_k)}\), are raw estimates \(p_1=1\), \(p_2=0.4\) enough to make the target undefined? Explain.
  4. Name two prespecified alternatives to smoothing and one limitation of each.

Solutions. (1) It is undefined because the empirical rate is \(0/0\). (2) \(\tilde p_k=(2+1)/(3+2)=3/5=0.6000\). (3) The target is defined: \(\sigma_1=0\), while \(\sigma_2=\sqrt{0.4(0.6)}\approx0.4899\), so the denominator is positive and \(\rho_1=0\). Whether that target is suitable is a separate design question. (4) Delaying updates requires a prespecified rule for the period before updating and may postpone data-dependent targets; a fallback target is reproducible if fixed in advance but does not use the unavailable plug-in value.

Clinical Biostats