Support SparsePauliOp observables in estimator workflow

[garrison]

• wait for Final (0.2.0) cutting workflow #153 to merge

[garrison]

I've added this to the 0.2.0 milestone as it's something we'd love to have in that release, but we can bump it to 0.3.0 if it's not ready.

[garrison]

This is going to require a slight modification to the PartitionedCuttingProblem namedtuple (specifically, we need it to also include the qubit_map returned by separate_circuit). For this reason, we decided to bump this to v0.4, so that v0.3 will be a release that only adds improvements (i.e., it will contain no breaking changes).

[caleb-johnson]

The way I envision this is that a user may use CKT to conduct a workflow for one observable. Currently we treat PauliList like a list of operators, when the class itself behaves like a single operator, composed of individual operators (e.g. num_qubits, phase, qargs fields suggest a single operator representation).

Due to this, I think we can move from PauliList to supporting a single SparsePauliOp as input. Users who want expectation values over many observables should just create new experiments for each observable and reconstruct them individually in post-processing.

I don't see much value in over-complicating our source code to support multiple observables when creating experiments and reconstructing them for a given observable is fairly straight forward and can be done in a loop for many observables. Running the experiments for each observable group will take some time, and users should be at liberty to perform their own grouping across the observables and intelligently collecting results and disseminating them back to the observable terms they correspond to. In other words, I think CKT being a single-observable workflow is fairly natural. It makes the devs' lives easier and is a natural interface for end-users.

Implementing support for a single SparsePauliOp should be as easy as stripping the PauliList out of the input SparsePauliOp during decomposition and doing one additional weighting/collapsing of the PauliList expvals during reconstruction.

[caleb-johnson]

The way I envision this is that a user may use CKT to conduct a workflow for one observable. Currently we treat PauliList like a list of operators, when the class itself behaves like a single operator, composed of individual operators (e.g. num_qubits, phase, qargs fields suggest a single operator representation).

Due to this, I think we can move from PauliList to supporting a single SparsePauliOp as input. Users who want expectation values over many observables should just create new experiments for each observable and reconstruct th
Implementing support for a single SparsePauliOp should be as easy as stripping the PauliList out of the input SparsePauliOp during decomposition and doing one additional weighting/collapsing of the PauliList expvals during reconstruction.

After coding up an implementation of this, I am starting to feel like the easiest and correct thing to do is let end-users do the near-trivial task of compiling the expvals output from CKT into a single expval using some operator coefficients they have locally.

If users pass in SparsePauliOp(...).paulis as their observables, the phases will automatically be stripped and CKT can return expvals for the nophase Paulis. End users will be expected to keep up with the operator coefficients and handle any phase calculations, as those two values will never be passed into CKT.

#523 shows users how to use CKT to estimate expvals of SparsePauliOps

[garrison]

Due to this, I think we can move from PauliList to supporting a single SparsePauliOp as input. Users who want expectation values over many observables should just create new experiments for each observable and reconstruct them individually in post-processing.

Just adding -- and this is consistent with our offline discussion -- that I think actually if a user has multiple SparsePauliOp observables, they should provide them all upfront. But, we should provide a utility that allows them to distill that to a single PauliList and which will also allow them to reconstruct results of each observable of interest from that PauliList, rather than making this something that the CKT workflow does implicitly. I can code up a demo of this once #523 is merged.