Expectation value of observables non diagonal in the computational basis

[BrunoLiegiBastonLiegi]

Currently, our SymbolicHamiltonian.expectation_from_samples only works for observables that are composition of Z operators. To compute the expectation value of some non-Z operator, for instance XZ + YX, one has to manually rotate the measurement basis accordingly, collect the frequencies and then calculate the expectation value of a ZZ operator starting from those frequencies. Therefore, in this example, one has to measure M(0,1, basis=["X", "Z"]) first, collect the frequencies and calculate the expectation of ZZ, then re-execute a second time measuring M(0,1, basis=["Y", "X"]), get the frequencies and again calculate the expectation of ZZ. The sum of the two expectations is then the global expected value.

This PR automatizes this process, by allowing circuits to be passed as inputs to SymbolicHamiltonian.expectation_from_samples.

Checklist:

• Reviewers confirm new code works as expected.
• Tests are passing.
• Coverage does not decrease.
• Documentation is updated.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.91%. Comparing base (e7276d8) to head (f9943d7).
Report is 261 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1489      +/-   ##
==========================================
- Coverage   99.93%   99.91%   -0.02%     
==========================================
  Files          81       81              
  Lines       11795    11804       +9     
==========================================
+ Hits        11787    11794       +7     
- Misses          8       10       +2     

Flag	Coverage Δ
unittests	99.91% <100.00%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[chmwzc]

Resolves #852, happy to see that this functionality is getting added in :)
Also, just FYI, I implemented something like this in Qibochem here, together with the use of qubit-wise commuting measurements to reduce measurement costs (Ref: https://arxiv.org/abs/1907.03358).

[marekgluza]

That is very cool and will be very useful for my work with @Sam-XiaoyueLi

@BrunoLiegiBastonLiegi you can request review from @Sam-XiaoyueLi and she can help add further docs or examples if needed

[BrunoLiegiBastonLiegi]

@stavros11 may I trouble you with the review of this PR? I changed some things in the SymbolicHamiltonian and related objects, which I presume you first implemented.

@Sam-XiaoyueLi feel free to suggest any meaningfull example for the docs, for the moment I just made up a random observable.

[marekgluza]

@Sam-XiaoyueLi maybe TLFIM or XXZ?

…

On Sun, 27 Oct 2024, 17:05 BrunoLiegiBastonLiegi, ***@***.***> wrote: @stavros11 <https://github.com/stavros11> may I trouble you with the review of this PR? I changed some things in the SymbolicHamiltonian and related objects, which I presume you first implemented. @Sam-XiaoyueLi <https://github.com/Sam-XiaoyueLi> feel free to suggest any meaningfull example for the docs, for the moment I just made up a random observable. — Reply to this email directly, view it on GitHub <#1489 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABU6DWAUFUHUOVZ7GMI6PHDZ5SNDRAVCNFSM6AAAAABP6QBQUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZZHEYTMNBVGE> . You are receiving this because you commented.Message ID: ***@***.***>

[stavros11]

I understand this is useful only for hardware execution, right? Since in simulation you could just simulate the circuit and use expectation directly, which should also be more efficient (and exact).

[BrunoLiegiBastonLiegi]

Yes I had exactly in mind hardware execution for this. But even for simulation, you wouldn't want the exact expectation from the final state (is this what you are suggesting? not sure) as this is supposed to be sample dependent.

[stavros11]

you wouldn't want the exact expectation from the final state (is this what you are suggesting? not sure) as this is supposed to be sample dependent.

Yes, above I meant to get the exact expectation from the final state, however you can still get a sample dependent estimate by first simulating the circuit with shots, getting the samples and using expectation_from_samples. I would expect this to be faster than using expectation_from_circuit for simulation, since in the first case the "state preparation" circuit is only simulated once, while expectation_from_circuit will repeat the simulation of the same circuit for every basis.

On hardware, or if you are simulating with noise, it is probably a different story.

[BrunoLiegiBastonLiegi]

Ah yeah, I see, I've been thinking about doing the state preparation first and then just measuring for simulation. To do that though, we should probably move (at least some part of) the expectation_from_circuit inside the backend, which I am not against by the way, but for the moment I decided to keep it simple. In any case, I was assuming that since execute_circuits launches several parallel jobs, if I am not mistaken, the overhead of running several copies of the same simulation would have been reduced, assuming you have many cores available.

[stavros11]

I also think we don't need to do anything about this, since it is already available by executing the circuit manually and then calling expectation_from_samples. This is a bit more manual for the user, but it is still fairly simple and it is not the best idea to provide multiple ways (almost equally simple) to do the same thing as it would increase maintenance from our side.

[stavros11]

Thanks for the updates @BrunoLiegiBastonLiegi.