Summary
Randomised property testing exists for the Clifford backend and nowhere else.
Every other suite in the tree states a property and then hand-picks the circuits
that exercise it, which means each one only ever visits the gate orderings
somebody thought of. Nothing generates a circuit corpus for the statevector,
density-matrix, MPS or qudit paths.
Gap
tests/test_v11251_clifford_random.cpp draws circuits from the entire Clifford
dispatch under fixed seeds and holds them to the exact statevector, the second
tableau layout, the outcome slab, both sampling routes, and the general per-shot
route. On its first run it contradicted two hand-written expectations that had
looked obviously true, which is the argument for the technique in one sentence.
The other backends have no equivalent. Their existing use of a random number
generator is seeding a simulator, not generating a corpus.
Proposed approach
This is a design problem per backend rather than a copy of the Clifford file,
because each needs its own oracle and only one of them has an exact reference
already available.
- Statevector. The hardest, because it IS the reference every other
comparison rests on, so it cannot be checked against anything else. Its
properties have to be internal: unitarity of the evolved state, reversibility
of a circuit followed by its inverse, agreement between a fused and an unfused
run of the same circuit, and agreement between gate decompositions that should
be equal. Worth doing first for exactly that reason.
- MPS. Exact only at a bond dimension covering
d^(n/2), so a random
comparison against the statevector is valid at that cap and undefined below
it. Depends on the open question of what fidelity a given cap should produce.
- Density matrix. Needs a noise model drawn alongside the circuit. The
statevector is a valid reference only in the ideal case, so the noisy case
needs its own properties: trace preservation, positivity, and agreement with
a Kraus-operator application of the same channel.
- Qudit. Needs a generator at general d, and shares no code with the qubit
layer, so it is independent work rather than a parameterisation.
Two properties of the Clifford file are worth carrying over regardless of
backend. Every draw is seeded from a fixed constant, so a failure is
reproducible and names the circuit that produced it rather than being a
run-to-run coin flip. And the quantifiers have to be stated carefully: a
property that holds for every state belongs inside the per-state loop, while one
that merely holds for SOME state has to be witnessed across the corpus. Getting
that backwards produces a test that fails on correct code.
Target
Not yet scheduled.
Status
OPEN.
Summary
Randomised property testing exists for the Clifford backend and nowhere else.
Every other suite in the tree states a property and then hand-picks the circuits
that exercise it, which means each one only ever visits the gate orderings
somebody thought of. Nothing generates a circuit corpus for the statevector,
density-matrix, MPS or qudit paths.
Gap
tests/test_v11251_clifford_random.cppdraws circuits from the entire Clifforddispatch under fixed seeds and holds them to the exact statevector, the second
tableau layout, the outcome slab, both sampling routes, and the general per-shot
route. On its first run it contradicted two hand-written expectations that had
looked obviously true, which is the argument for the technique in one sentence.
The other backends have no equivalent. Their existing use of a random number
generator is seeding a simulator, not generating a corpus.
Proposed approach
This is a design problem per backend rather than a copy of the Clifford file,
because each needs its own oracle and only one of them has an exact reference
already available.
comparison rests on, so it cannot be checked against anything else. Its
properties have to be internal: unitarity of the evolved state, reversibility
of a circuit followed by its inverse, agreement between a fused and an unfused
run of the same circuit, and agreement between gate decompositions that should
be equal. Worth doing first for exactly that reason.
d^(n/2), so a randomcomparison against the statevector is valid at that cap and undefined below
it. Depends on the open question of what fidelity a given cap should produce.
statevector is a valid reference only in the ideal case, so the noisy case
needs its own properties: trace preservation, positivity, and agreement with
a Kraus-operator application of the same channel.
layer, so it is independent work rather than a parameterisation.
Two properties of the Clifford file are worth carrying over regardless of
backend. Every draw is seeded from a fixed constant, so a failure is
reproducible and names the circuit that produced it rather than being a
run-to-run coin flip. And the quantifiers have to be stated carefully: a
property that holds for every state belongs inside the per-state loop, while one
that merely holds for SOME state has to be witnessed across the corpus. Getting
that backwards produces a test that fails on correct code.
Target
Not yet scheduled.
Status
OPEN.