Calculating expectation value of a sum of Paulis

[rht]

According to the docstring of CircuitToEinsum.expectation, I can specify the Pauli string as either ["Z", "Z", "Z"], or {q: "Z" for q in qubits}. But this is restricted to <Z_1⊗Z_2⊗Z_3>. Is there a way to do <Z_1+Z_2+_Z_3> in one go? Currently, I have to compute <Z_1>, <Z_2>, and <Z_3> separately.

[yangcal]

Hello,

Currently CircuitToEinsum does not support direct computation of operator sums although this is on our radar.

One potential strategy to compute the operator sum more efficiently here is via our reduced_density_matrix approach. For instance, if you have Z1, Z2, Z3 on a, b, c qubits, you could do first contract the RDM on these three qubits, then contract them separately with the RDM and sum over. This should provide some speedup if you only have Pauli strings on a small subset of qubits but will not be efficient if they're placed on all qubits.

[rht]

I see, I think this question could be converted to an issue instead? I think even if there is no performance benefit (but I hope there is), it would still be convenient.

[mtjrider]

Hi @rht

Can you clarify any questions you still have on this subject?
If not, I will close this discussion and ask you to either reopen it or create a new discussion/issue.

[rht]

I was simply asking a convenient feature to calculate on a Pauli sum. There is a GH feature to convert this into an issue btw.

[mtjrider]

Yes. We’re aware of that GitHub capability. Thanks for pointing it out.

To appropriately prioritize any enhancement, we need to understand the workload. Can you provide more detail about how you’d use this feature?

[rht]

It's not a blocker, just a nice to have feature. As it is currently, I have calculated the expectation for each of the Pauli sum constituents. Qiskit and Cirq/qsim already have it, and so it's just for consistency purpose.

[mtjrider]

As it is, I'm not sure that there would much (if any) performance improvement provided by a feature enhancement for this. Depending on the broader context of the workload, the enhancement could prove beneficial.

As an example, if the workload required many batches of expectation values be calculated for the reduction, that would make a difference.

From the information you've provided, the largest benefit seems to be convenience.
Let me know if I have that wrong.

Regardless, I plan to generate an issue to track this feature request. Once created, it will be prioritized based on this discussion thread. At that time, I will lock this discussion, and any relevant information will need to be posted in the issue.

[rht]

I didn't know that the performance could be improved further via handling the batches efficiently. AFAIK, e.g. Cirq does it by doing each Pauli string separately, and then sum them all. If you have a more performant Pauli sum calculation, that would be a great addition to cuQuantum.

[mtjrider]

Yes, the issue is that there are many features in our pipeline that we've been asked to implement. It helps us to understand how any particular feature will be used so that we can gauge relative impact.

@tlubowe for visibility.

[yangcal]

Somehow I missed your earlier reply, my apologies.

From API perspective, it would be hard to provide such API to allow computation of sum of pauli strings in one shot. Parsing the operands for each pauli string is straighforward, but the current einsum format adopted in all packages (cuquantum-python, numpy, cupy) does not support sum of terms in the einsum expression. On top of my head, I can't think of a way to allow users to specify such sum forms elegantly though I do agree it could be a useful feature.

For performance consideration, when computing the output of each terms, users are encouraged to use the Network object with the reset method. This allows users to reuse library handle, path, contraction plan and so on.

[mtjrider]

@rht
I've created an issue to track your request.
Here: #91

[DmitryLyakh]

Hi @rht , FYI: Starting with cuQuantum-23.10, you can compute expectation values of any sum-of-Pauli-products operators directly via the cuTensorNet high-level API. Currently we only provide direct Python bindings, which look less Pythonic than CircuitToEinsum, but they provide full functionality (an example can be found here: https://github.com/NVIDIA/cuQuantum/blob/main/samples/cutensornet/high_level/expectation_example.cu).

[DmitryLyakh]

@rht , sorry, that was a C example, the Python example is here: https://github.com/NVIDIA/cuQuantum/blob/main/python/samples/cutensornet/high_level/expectation_example.py