Updated Sampler

[ihincks]

No description provided.

[ajavadia]

overall direction and philosophy looks good to me

[jakelishman]

Thanks for this, Ian. I think there's a few things in here that treat IBM-specific extensions as if they are part of the backend.run general interface, which might want removing / reducing.

On a larger note, I'm wondering how / if we can ensure that Sampler (and to a degree, Estimator) are expandable interfaces, potentially with some form of version negotiation, so we don't end up needing to make a SamplerV3 in the future that might return different types. This maybe is a concern too far and too late at this stage, though.

[jlapeyre]

My understanding is that primitives are meant to be universal interfaces. But references to other "tooling" above #56 (comment) make this less clear to me. The particular concern I have is that sampling a large number of shots from a modest number of qubits using a simulator might be inefficient to impossible without returning results in an associative array. Is there a way to accommodate this situation within this proposal? Or would that require completely separate tooling?

[blakejohnson]

@jlapeyre that comment is in reference to streaming interfaces, which are out of scope of this RFC.

The particular concern I have is that sampling a large number of shots from a modest number of qubits using a simulator might be inefficient to impossible without returning results in an associative array. Is there a way to accommodate this situation within this proposal?

It is no more difficult than handling the same number of shots from hardware.

[jlapeyre]

It is no more difficult than handling the same number of shots from hardware.

Yes, in principle. I used a simulator as an example because it's easy to quickly generate with a simulator more shots than you can store. Anyone currently doing experiments like this won't be able to use this interface.

Now that I think about it, if I understand you correctly, I agree that rather than special casing accumulating shots in a hash map, it's better handled as part of a more general streaming or "online" tool that can handle custom filters. And I see it's been suggested that this is out of scope: #56 (comment)

I'd consider making the streaming interface the fundamental one and provide a collect function to write to an array. Then build something like this proposal on top of that. But it looks like this is too late for this version.

EDIT: If this proposal is about an API boundary, suppose it doesn't preclude changing the implementation later.