There should be an easy way to compute expectation values for operators

What should we add?

Currently there is no way good way to compute expectation values in Qiskit. The StateVector and DensityMatrix objects in quantum_info have expectation_value methods, but there is no general way to do this.

In general expectation values are defined with respect to the operator in question and not the state. To quote Sakurai:

We define the expectation value of $A$ taken with respect to $|a\rangle$

So it makes sense to have the operator as the primary object, and having a method by which one can pass Counts, QuasiDistribution or the like and obtain the desired value. Obtaining these values requires the bit-string representation to be available via those objects efficiently.

There is no unique way to define operators in Qiskit, eg there is are Pauli and PauliOp. So not even sure what flavor of operator is primary to Qiskit as well.

[nonhermitian]

I would also say that Qiskit is about more than the Runtime. Other hardware vendors might not implement the Runtime interfaces, and anyway the base implementations are statevector only. Thus one still needs the expectation values from counts functionality somewhere if the reference implementations are modified to work with counts.

The Estimator could return counts, but then one could ask why do I need the Sampler? You also get into situations where I run readout mitigation, but cannot return the quasi-distribution. So one has to return the original. But then for parity reasons one should probably return the original distribution in the Sampler as well. And then people will complain about the data sizes being too large, etc etc. So taken as a whole, it seems like a lot of round-a-bout to avoid making a method whose functionality we already know how to code up, but have not done so to date.

[jlapeyre]

I pushed a branch implementing (some) methods for expectation_value using multiple dispatch.

Following is an example script that calls these methods:

import numpy as np

from qiskit.quantum_info.states import Statevector
from qiskit.quantum_info.operators import Pauli
from qiskit.quantum_info import expectation_value

diagop = Pauli('ZZ')
oneop = Pauli('Z')

state = Statevector([1, 2, 2, 1])
state = state / np.linalg.norm(state.data)


cs = state.sample_counts(10000)

# Compute expectation of ZZ operator on state
print(expectation_value(diagop, state))

# Explicitly specify all qubits
print(expectation_value(diagop, state, range(len(diagop))))

# Explicitly specify only first qubit
print(expectation_value(oneop, state, [0]))

# Compute expectation value from counts, using all qubits
print(expectation_value(cs))

# Explicitly specify all qubits
# Note, I probably will use a different interface here. Best is probably
# following exactly how qargs works above.
print(expectation_value(cs, '11'))

# Explicitly specify only first qubit
print(expectation_value(cs, '10'))

The meaning of method expectation_value(cs), is found in comments

Compute the expectation value of Counts in the same basis that was measured to collect the counts, for a subset of the qubits. op is a binary string specifying which qubits to include. For example 1100 specifies computing the expectation value of the first two qubits in a four-qubit register.

In addition to aiding in designing a uniform API, the complexity and repetition in the code can be reduced with MD. One example of the benefit of using multiple dispatch in this mathematical setting is the following: This branch implements expectation_value for both Statevector and DensityMatrix in a single method, rather than two. Furthermore, all details of the structure of the operator are hidden in this method. Note that some, but not all, of this can be done with single dispatch; for example with class methods. In any case, I find that the design style with MD encourages the factoring of code shown above.