Adds observable evaluator with primitives.

[dlasecki]

Summary

This PR adds an observable evaluator that uses the Estimator primitive. It will be used by several primitives-enabled algorithms. It replaces the aux_ops_evaulator.py.

• Release notes.
• Handle 0 passed in as operators.
• Deprecation of aux_ops_evaluator.py. @manoelmarques

Closes: #8505

Details and comments

[qiskit-bot]

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the the following people are requested to review this:

• @Qiskit/terra-core
• @manoelmarques
• @woodsp-ibm

[coveralls]

Pull Request Test Coverage Report for Build 3062532045

• 45 of 58 (77.59%) changed or added relevant lines in 3 files are covered.
• 177 unchanged lines in 4 files lost coverage.
• Overall coverage decreased (-0.3%) to 84.203%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/algorithms/observables_evaluator.py	42	55	76.36%

Files with Coverage Reduction	New Missed Lines	%
src/sabre_swap/sabre_dag.rs	1	94.44%
src/optimize_1q_gates.rs	57	4.84%
src/sabre_swap/mod.rs	59	80.45%
src/results/marginalization.rs	60	54.02%

Totals
Change from base Build 3062284929:	-0.3%
Covered Lines:	59322
Relevant Lines:	70451

---

💛 - Coveralls

[Cryoris]

Some comments below otherwise LGTM 👍🏼 now we just need to convince @woodsp-ibm that we need this 😉

[woodsp-ibm]

now we just need to convince @woodsp-ibm that we need this

It seems fine - the Dict and List processing to handle None is beyond what the Estimator can handle to the data needs to be mapped in/out and this does that as a common function the algos can use.

Since the Estimator reports variance back, I am wondering whether we should just pass variance on back from here too, when its available. I am not sure about shots being present always to do the conversion and if using Estimator directly I get variance why not also when running an algo that uses it...

Handle 0 and None passed in as operators.

From the main description. While None was used in the lists to preserve order if an operator became invalid as part of transformation down through the stack, 0 is not a valid value. What you might mean by that is empty/zero operator i.e. a valid instance, a zero operator. I would hope Estimator handles that - I know with opflow additional work was done to select these out - which we did back in Aqua days too since the expectation is 0. I do not know what Estimator does.

[woodsp-ibm]

Any thought on this aspect from above

Since the Estimator reports variance back, I am wondering whether we should just pass variance on back from here too, when its available. I am not sure about shots being present always to do the conversion and if using Estimator directly I get variance why not also when running an algo that uses it...

[ElePT]

I found these small details while reviewing the PVQD PR, and thought it would make more sense to suggest here the changes. Otherwise, I'm using this code on my PR and it looks good to me :)

[dlasecki]

Any thought on this aspect from above

Since the Estimator reports variance back, I am wondering whether we should just pass variance on back from here too, when its available. I am not sure about shots being present always to do the conversion and if using Estimator directly I get variance why not also when running an algo that uses it...

Hello, I have been wondering about it myself. The primitive natively records a variance. I was thinking that if variance is present, shots should always be present, too. Any thoughts on that @t-imamichi?
The old auxiliary ops evaluator returns standard deviations and that's because some algorithms use it. So I decided to preserve that to avoid changes and potential complications in other places. Perhaps a good idea would be to return directly what the primitive reports, i.e. both variance and shots. But this would require some changes in algorithms...

I am fine either way.

[woodsp-ibm]

The old auxiliary ops evaluator returns standard deviations and that's because some algorithms use it.

I was not aware of algorithms using it as such, VQE/VQD/QAOAetc. They did return it as part of their result for anyone to use should they wish, that's the extent of the use I knew, where the aux ops evaluation was a value, std_dev tuple for each.

[ElePT]

The old auxiliary ops evaluator returns standard deviations and that's because some algorithms use it.

I was not aware of algorithms using it as such, VQE/VQD/QAOAetc. They did return it as part of their result for anyone to use should they wish, that's the extent of the use I knew, where the aux ops evaluation was a value, std_dev tuple for each.

Yes, none of these 3 algorithms does actually use these stdevs, they just return them as part of the aux_ops evaluation result. So I think that variance and shots could be returned without much hassle. We would only have to change one type hint in the base class, and the docstring of the aux_ops_result.

[t-imamichi]

As for std_dev, there is a PR #8105 to extend EstimatorResult to include not only variance but also std_dev or anything else. But, we didn't have enough discussion yet.

[declanmillar]

Do we want to handle cases where users pass in an empty list or dict for observables?

[dlasecki]

Do we want to handle cases where users pass in an empty list or dict for observables?

Good point! I just fixed 1 line to handle empty inputs such that empty outputs are returned with no error! Added unit tests for that.

[woodsp-ibm]

LGTM thanks.