Verifying a DBCD Implementation with Hand Calculations

Why verify probabilities by hand?

A DBCD implementation can produce plausible-looking allocation probabilities while still using the wrong target, arm index, feedback direction, or normalization. A small hand calculation provides an independent reference: given fixed inputs, it establishes the probabilities the implementation should return. The goal here is to check that calculation, not to simulate assignments or assess a design over repeated trials.

For this check, treat the target shares and allocation counts as fixed inputs. In an actual response-adaptive design, a target may be estimated from response data; that estimation step is not recalculated in these examples. Keeping inputs fixed isolates whether the allocation rule has been implemented correctly.

Rule and assumptions for a hand check

Definition: For $K$ arms, let $\rho_k$ be the target share for arm $k$, $N_k$ its current allocation count, $N=\sum_{k=1}^K N_k$ the total count, and $q_k=N_k/N$ its current allocation share. For a fixed feedback parameter $\gamma\geq 0$, the DBCD weight and next-assignment probability for arm $k$ are $$ w_k=\rho_k\left(\frac{\rho_k}{q_k}\right)^\gamma =\frac{\rho_k^{1+\gamma}}{q_k^\gamma}, \qquad \pi_k=\frac{w_k}{\sum_{j=1}^K w_j}. $$

The $w_k$ are positive, unnormalized weights; the $\pi_k$ are probabilities. The rule requires $\sum_k\rho_k=1$, $N>0$, and positive $\rho_k$ and $q_k$ for every arm included in the calculation. In particular, this direct formula is not defined when an arm has zero allocation count or zero target share. A design must specify how such cases are handled; a hand check should not silently replace a zero with an arbitrary small number.

The calculation also assumes that the same arm ordering is used for target shares, counts, and returned probabilities; that the implementation uses the stated value of $\gamma$; and that no additional constraints or modifications are applied. These are fixed-input checks: if the program transforms the target, applies a cap, or uses a different rule, it will not be checking this formula as written.

A calculation that can be checked in stages

A reliable manual audit separates the arithmetic into stages. First calculate $N$ and each $q_k$. Then calculate each ratio $\rho_k/q_k$, raise it to $\gamma$, and multiply by $\rho_k$ to obtain $w_k$. Finally add the weights and divide each weight by their common sum. Keeping the intermediate values makes it easier to find the source of a discrepancy than comparing only the final probabilities.

Worked Example: Two Arms With Unequal Current Shares

Suppose a hypothetical two-arm calculation has target shares $\rho_1=0.60$ and $\rho_2=0.40$, allocation counts $N_1=36$ and $N_2=14$, and $\gamma=1$. Calculate the next-assignment probabilities.

Check the inputs. The targets sum to $0.60+0.40=1.00$; the total count is $N=36+14=50$. Both target shares and counts are positive, so the formula is defined.

Current shares. $q_1=36/50=0.72$, and $q_2=14/50=0.28$. The current shares sum to one.

Weights. Substituting $\gamma=1$, $$ w_1=0.60\left(\frac{0.60}{0.72}\right)=0.60(0.8333)=0.5000, \qquad w_2=0.40\left(\frac{0.40}{0.28}\right)=0.40(1.4286)=0.5714. $$ The weight sum is $0.5000+0.5714=1.0714$. Thus $$ \pi_1=\frac{0.5000}{1.0714}=0.4667, \qquad \pi_2=\frac{0.5714}{1.0714}=0.5333. $$

The first arm is currently above its target share, $0.72>0.60$, so its next-assignment probability is below its target share. The probabilities sum to approximately one; the small rounding difference reflects the displayed precision. This direction is a useful check, but it does not replace checking the arithmetic.

Why the checks work

The normalization step has two immediate consequences. Since each weight is positive, each $\pi_k$ is positive. Also, dividing every weight by the same positive sum gives $$ \sum_{k=1}^K\pi_k =\sum_{k=1}^K\frac{w_k}{\sum_{j=1}^K w_j} =\frac{\sum_{k=1}^K w_k}{\sum_{j=1}^K w_j} =1. $$ Therefore a reported probability vector that does not sum to one (apart from numerical rounding) cannot be the normalized result of these weights.

A second check comes from equal current and target shares. If $q_k=\rho_k$ for every arm, then $\rho_k/q_k=1$, so $w_k=\rho_k$. Because the targets sum to one, normalization leaves them unchanged: $\pi_k=\rho_k$. A third check follows when $\gamma=0$: every ratio raised to zero is one, so $w_k=\rho_k$ and again $\pi_k=\rho_k$, regardless of the current shares. This property applies to positive inputs under the stated rule.

The odds form is another way to inspect the calculation. For two arms, $$ \frac{\pi_1}{\pi_2} =\frac{w_1}{w_2} =\frac{\rho_1}{\rho_2} \left(\frac{\rho_1/q_1}{\rho_2/q_2}\right)^\gamma. $$ This follows because the common normalizing denominator cancels in the probability ratio. It provides an independent check of the relative weights. It does not, by itself, verify that the probabilities were normalized correctly.

Worked Example: Three Arms and a Weight-Sum Check

Consider a hypothetical three-arm calculation with $(\rho_1,\rho_2,\rho_3)=(0.50,0.30,0.20)$, counts $(N_1,N_2,N_3)=(20,15,15)$, and $\gamma=1$. Find the probability vector by calculating and normalizing each weight.

Check the inputs. The target shares sum to $0.50+0.30+0.20=1.00$, the counts are positive, and $N=20+15+15=50$.

Current shares. The current shares are $q_1=20/50=0.40$, $q_2=15/50=0.30$, and $q_3=15/50=0.30$. They sum to $1.00$.

Weights. With $\gamma=1$, $$ w_1=0.50\left(\frac{0.50}{0.40}\right)=0.6250,\quad w_2=0.30\left(\frac{0.30}{0.30}\right)=0.3000,\quad w_3=0.20\left(\frac{0.20}{0.30}\right)=0.1333. $$ The sum is $0.6250+0.3000+0.1333=1.0583$, to the displayed precision. Therefore $$ \pi_1=\frac{0.6250}{1.0583}=0.5906,\quad \pi_2=\frac{0.3000}{1.0583}=0.2835,\quad \pi_3=\frac{0.1333}{1.0583}=0.1260. $$

The probabilities sum to approximately $1.0001$ using these rounded values; unrounded arithmetic gives a sum of one. Arm 1 is below target currently, $0.40<0.50$, and its probability exceeds its target share. Arm 2 is at target, but its probability is slightly below its target because arm 3 is above target and the probabilities must share a total of one.

Implementation audit as a short process

Freeze and label inputs.
Record the target vector, allocation counts, arm order, and $\gamma$. Make sure all values belong to the same calculation step.

Calculate current shares.
Compute $N=\sum_k N_k$ and $q_k=N_k/N$. Verify that counts and shares sum to $N$ and one, respectively.

Calculate weights independently.
For each arm, record $\rho_k/q_k$, its $\gamma$ power, and the product with $\rho_k$.

Normalize and compare.
Divide each weight by the weight sum. Compare the implementation with the manual probabilities before rounding, allowing only a justified numerical tolerance.

Run structural checks.
Check the sum-to-one property and, using separate fixed inputs, verify target matching when $q=\rho$ and $\gamma=0$.

This process resembles the earlier material on separating response data, allocation counts, and target shares: a mismatch can arise before the formula is evaluated if values from different roles or steps are confused. Here the audit treats the supplied target and counts as fixed and asks only whether the specified probability calculation follows from them.

Worked Example: Testing the Gamma-Zero Case

For a separate hypothetical two-arm test, let $(\rho_1,\rho_2)=(0.70,0.30)$, counts $(N_1,N_2)=(40,10)$, and $\gamma=0$. The total is $N=50$, so the current shares are $q_1=0.80$ and $q_2=0.20$. Both targets and counts are positive, and the targets sum to one.

The weights are $$ w_1=0.70\left(\frac{0.70}{0.80}\right)^0=0.70(1)=0.70, \qquad w_2=0.30\left(\frac{0.30}{0.20}\right)^0=0.30(1)=0.30. $$ Their sum is $1.00$, giving $\pi_1=0.70/1.00=0.70$ and $\pi_2=0.30/1.00=0.30$.

This is a particularly useful unit test: under the stated rule, changing positive current counts cannot change the output when $\gamma=0$. If an implementation instead returns $0.80$ and $0.20$, it may be returning current shares rather than the specified probabilities.

Diagnostics, alternatives, and limits

A hand calculation is an independent oracle for a few fixed inputs. It is most useful when the chosen cases exercise different features: a two-arm case with unequal current and target shares, a multi-arm case that tests indexing and normalization, and a $\gamma=0$ or target-matching case with a known result. Compare unrounded outputs when possible; otherwise, set a tolerance appropriate to the program's numerical precision and report the rounding used in the manual calculation.

Several failures have recognizable signs. Probabilities that do not sum to one suggest a missing or incorrect normalization. A correct sum with probabilities attached to the wrong arms suggests an ordering or indexing mismatch. A probability vector equal to the target for every input may indicate that the feedback term was omitted. A vector that moves in the opposite direction from the target/current-share correction can indicate that the ratio was reversed or that the feedback sign is wrong. These patterns identify possible causes, not proof of a particular coding error: inspect the intermediate shares and weights to locate it.

The most direct alternative is to calculate the displayed weight formula and normalize it, as above. A second independent calculation uses the two-arm odds ratio, then obtains probabilities from $\pi_1=r/(1+r)$ and $\pi_2=1/(1+r)$, where $r=w_1/w_2$. Agreement between these routes is a useful check for two arms. It is not a substitute for a multi-arm check, and both routes can share an error if they use the same incorrectly specified inputs or formula.

Hand checks do not establish that the full design is appropriate, that target shares were estimated correctly, or that a simulation or trial follows every design specification. They test numerical implementation of the stated rule at the selected inputs. They also do not cover a different rule introduced by constraints or special handling of zero counts. Such cases require an explicit specification and their own test cases.

Common mistake

Common mistake: Treating the target share $\rho_k$ as the next-assignment probability, or treating the current share $q_k$ as that probability. Correction: For $\gamma>0$, calculate the DBCD weight using both the target and current share, then normalize all arm weights. The target share is an input to the rule; it need not equal the next-assignment probability at a particular step.

Another tempting shortcut is to compare rounded probabilities and declare a mismatch when the displayed decimals do not add to exactly one. Instead, keep sufficient precision through the weight sum and normalization, then round the final probabilities for reporting. Conversely, a sum near one is not sufficient evidence of correctness: many incorrect vectors can sum to one, so check the component values against hand-calculated results too.

Check Your Understanding

Use the stated DBCD formula and show intermediate values where requested. Solutions follow the questions.

For two arms, $\rho=(0.50,0.50)$, counts $(30,20)$, and $\gamma=1$, calculate $q$, the weights, and the probabilities.
Why must the probabilities from normalized weights sum to one?
For $\rho=(0.60,0.40)$, $\gamma=0$, and any positive allocation counts, what probability vector should the formula return? Explain.
A program returns probabilities that sum to one but assigns them in reverse arm order. What input/output check can reveal this problem?

Solutions. (1) $N=50$, so $q=(0.60,0.40)$. The weights are $w_1=0.50(0.50/0.60)=0.4167$ and $w_2=0.50(0.50/0.40)=0.6250$; their sum is $1.0417$. Thus $\pi_1=0.4167/1.0417=0.4000$ and $\pi_2=0.6250/1.0417=0.6000$, to four significant figures. (2) Each probability is its weight divided by the same weight sum, so the sum of probabilities is the weight sum divided by itself, which equals one. (3) The result is $(0.60,0.40)$: with $\gamma=0$, each positive ratio raised to zero is one, so the weights are the targets and already sum to one. (4) Use an input with unequal arm-specific targets or counts, calculate each expected probability by arm label, and compare the returned vector component by component in the documented order; a sum-to-one check alone cannot detect swapped components.