Add utility for dealing with multiple SparsePauliOps
#587
Conversation
Pull Request Test Coverage Report for Build 9290402313Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
|
|
||
|
|
||
| def gather_unique_observable_terms( | ||
| observables: PauliList | Sequence[Pauli | SparsePauliOp], |
There was a problem hiding this comment.
I should swap the order here so PauliList gets secondary billing.
There was a problem hiding this comment.
I didn't know that the order mattered. Could you clarify what you mean here?
There was a problem hiding this comment.
I was talking about the type hints. The order does not have any impact other than how things are presented in the API docs. Since Sequence[Pauli | SparsePauliOp] is the typical way users will use this function, I want that type to appear first in the documentation.
There was a problem hiding this comment.
Okay, I now understand what you meant.
The previous code passed `observables_nophase` to the cutting code, so it wasn't even testing the phases through the workflow. The correct way to handle such observables with nontrivial phase is to use the utility introduced in #587.
* Migrate to `EstimatorV2` in tests Partially addresses #506. * black * Replace `observables` with `observables_nophase` The previous code passed `observables_nophase` to the cutting code, so it wasn't even testing the phases through the workflow. The correct way to handle such observables with nontrivial phase is to use the utility introduced in #587.
Remaining action items
how-tos/README.rst