Qiskit / qiskit-fermions / 34600589741

98%

push

github

docs(transpiler): warn that qDRIFT's filter_trivial biases the estimator (#342)

The docs presented `filter_trivial` as a free optimization, on the grounds
that the rejected terms "cannot affect the sampled bitstrings". That framing
is wrong in a way that matters: qDRIFT's correctness rests on the
first-moment identity E[lambda * V_j] = sum_j c_j H_j = H, which holds only
for p_j = |c_j|/lambda. Rejection sampling renormalizes p over the accepted
subset, so the filtered channel's average generator is a different
Hamiltonian, with every retained coefficient inflated by the reciprocal of
the acceptance probability.

Nothing compensates for this. `lambd`, `delta` and `probabilities` are all
computed from the full weight vector before the filtering branch is reached,
so the distortion does not cancel into the timestep. The consequence is that
the feature is outright wrong when the sampled circuits feed an expectation
value, while remaining defensible for bitstring-sampling workflows like
SqDRIFT, where only the sampled supports matter. Making that split explicit
is the point of this change.

State what the filtering actually conserves, which is the budget of
`num_terms` sampled slots rather than the circuit depth. The motivation is
that a slot spent on an excitation that cannot move a particle yields no
information about the sampled bitstrings, so it is a slot wasted. Because
that budget is fixed, though, a rejected draw is replaced rather than
dropped, and a cheap diagonal rotation gives way to a coupling excitation
that costs more to synthesize, which makes the filtered circuit deeper than
the unfiltered one. Measured on a four-mode Hamiltonian, seeds whose draws
actually differ went from depth 33/25/23 to 50/36/39 with the filtering on.
The docs now say so, so that nobody reads the option as a depth optimization.

The acceptance rule is also an over-approximation rather than a test: it
compares mode supports only, carries no amplitude information, and ... (continued)

10 of 10 new or added lines in 1 file covered. (100.0%)

12129 of 12380 relevant lines covered (97.97%)

532439.82 hits per line