Use SamplerV2 and EstimatorV2 in tests

[garrison]

Eventually -- once support is added for SamplerV2 (#488) and once Qiskit Aer supports SamplerV2 and EstimatorV2 (Qiskit/qiskit-aer#2078) -- we should update the tests to use the v2 versions of the primitives.

At the moment, I expect the migration to EstimatorV2 to be relatively easy.

SamplerV2, however, is going to be a bit more involved. ExactSampler returns exact probabilities, but SamplerV2 has moved away from probabilities and instead provides memory-based access to each shot outcome. So, the idea of an "exact sampler" is incompatible with the v2 sampler interface. Thus, we will probably stick with ExactSampler using the V1 interface for as long as we can. Once the V1 sampler interface is deprecated, we will be forced to upgrade, and this might mean we are no longer able to use the Sampler interface for the exact tests from this point forward. This is probably not a big deal, but it will be a minor inconvenience for us. Still, the v2 sampler is unambiguously a step forward, so I eagerly await the day when we can use it exclusively.

[garrison]

Actually, since Sampler (V1) is in Qiskit 1.0, it won't be removed until Qiskit 2.0 at the earliest. So we have a year before we might actually be forced to do something here.

[ihincks]

I'd like to understand this issue better. Are there some examples you might recommend?

[garrison]

I'd like to understand this issue better. Are there some examples you might recommend?

We have a class called ExactSampler, which acts just like qiskit.primitives.Sampler (v1) does when shots=None, except it has workarounds for a few limitations in qiskit.primitives.Sampler. It provides exact probabilities, which is useful for us in two circumstances:

1. Testing. We have a test of exact reconstruction that makes sure the result after the QPD round-trip is exactly equivalent to the result without the quasi-probability decomposition, up to rounding error. In order to migrate to SamplerV2, we'll have to perform this testing at a more fundamental level (i.e., without using the SamplerV2 interface).
2. User experimentation. There are two potential sources of error (besides hardware noise): that one drew only a finite number of samples (subexperiments) from the QPD, or that one drew only a finite number of shots from each subexperiment. Our first two how-to guides allow the user to experiment with eliminating each of the aforementioned sources of error. (Obviously, we can only get the shots -> infinity limit on a simulator.) Having ExactSimulator allows users to see how much of the error is due to shot noise (which is amplified by the QPD sampling overhead, which can be quite substantial). In order to migrate away from SamplerV1 entirely, I suspect we'll need to get rid of that how-to.

[garrison]

In a SamplerV2 result, each outcome is assumed to contribute an equal weight of 1 / shots. However, this does not allow for representing probabilities that are not a multiple of 1 / shots. We could potentially break this assumption in our use of ExactSamplerV2 by having it store each unique measurement outcome (across all registers) in its memory, together with a weights array in the metadata, which would store the exact probability of each corresponding measurement outcome. All weights would sum to zero. Then, in CKT's post-processing, if metadata["weights"] is present it treats it like a per-outcome probability; otherwise, it uses 1 / shots as each probability. This is essentially the only way I can think of to make a drop-in replacement for ExactSampler implemented as a v2 sampler. Unfortunately, if someone were to use this sampler in any context that does not understand this metadata field (i.e., any context other than CKT), they will get nonsense results.

https://github.com/Qiskit-Extensions/circuit-knitting-toolbox/blob/7831bba05bf491729371959e2780166887daeb59/circuit_knitting/cutting/cutting_reconstruction.py#L138-L140

And, admittedly, this is kind of a roundabout way of re-inventing the v1 interface -- but at least with the improved register access ergonomics of the v2 interface.

[ihincks]

Thanks for all of the details. It seems to me that ExactSampler is fundamentally incompatible with SamplerV2, and I'm having trouble seeing a way to move forward with something resembling ExactSampler without just specifying a huge number of shots.

The issue is that SamplerV1 explicitly returns estimates of distributions defined by quantum circuits, whereas SamplerV2 explicitly returns samples from the distributions defined by quantum circuits. These returns are baked into the typing, and they are a shift in the role of the sampler. So if estimates of distributions are the main object that you need to be working with, and if this is a scalable approach to your goals, it might be worth looking into using a distribution object as an intermediate representation of the data between your application and the SamplerV2.

[garrison]

it might be worth looking into using a distribution object as an intermediate representation of the data between your application and the SamplerV2.

Thanks -- yeah, I agree that having our own data structure will be better than abusing SamplerV2 in the way I suggest. Actually, rather than use it as an intermediate, I expect we will want to be able to consume either (exact probabilities or samples) directly. The reason is that if we actually have samples to work with, then we should just use them as such so we can perform bootstrapping throughout the entire calculation (#257).