Compute expectation value

[ludmilaasb]

Context:

It would be nice to have a function to calculate the expectation values of an operator $A$ given a state vector $\vert\psi\rangle$. This can be also used for computing the fidelity between a mixed and a pure state in simple way, avoiding eigendecomposition problems.

Description of the Change:

Added a overlap calculation between state vectors and density matrices

Benefits:

It is faster then computing $\text{Tr}(A \vert\psi\rangle\langle\psi\vert)$. No need for eigendecomposition, therefore, it is a way to avoid issues regarding differentiation as pointed on issue #4373.

Possible Drawbacks:

It does not work if the user pass as input two state vectors or two matrices. It is tailored to first input as (batched) matrices and the second one as (batched) state vectors.

Related GitHub Issues:
#4373

[dwierichs]

Thanks for this addition @ludmilaasb 🎉 💯

I left a number of comments regarding minor nitpicky stuff, a good part coming from porting functionality/docs over from other functions. Sorry if you were about to change those anyways, still!

One open question to me personally is whether we want to restrict to Hermitian matrices or not, and--connected to that--what output data type we want (real or complex).
This topic comes up repeatedly in the context of QNode expectation values of Hamiltonians, as far as I know, so it might deserve some discussion.
Once this is decided, I would suggest to add tests that

• test the return dtype
• test for some "more random" inputs and outputs. Maybe just adding a random matrix and state vector test would be a nice addition :)

[trbromley]

One open question to me personally is whether we want to restrict to Hermitian matrices or not, and--connected to that--what output data type we want (real or complex).
This topic comes up repeatedly in the context of QNode expectation values of Hamiltonians, as far as I know, so it might deserve some discussion.

Could we not have the Hermitian restriction, but also have a qml.math.real_if_close that wraps the return?

[dwierichs]

Could we not have the Hermitian restriction, but also have a qml.math.real_if_close that wraps the return?

data types have been causing quite a bit of headaches in the past, so having them be changed automatically scares me personally a little bit. Also, we get value dependent type changes that might not go well with JITting?

[ludmilaasb]

Thank you for the careful review! 😄

So, about the Hermitian matrices, it depends on what kind of operators you would like to work with. For instance, if the goal is exclusive "physically measurable quantities", i.e., observables and POVMs, then yes, they need to be Hermitian.

On the other side, if you consider things like annihilation and creation operators, they are non-hermitian. But I don't know if you guys want to go in this direction. 🤔

[dwierichs]

On the other side, if you consider things like annihilation and creation operators, they are non-hermitian. But I don't know if you guys want to go in this direction.

Good point. I can't judge what's needed here... We could also have "a physicist's expectation" as default, expecting a Hermitian and returning a real value. Then there could be a keyword argument is_hermitian that can be switched off to allow non-Hermitian obs.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.67%. Comparing base (94adc17) to head (3d2210c).
Report is 246 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4484      +/-   ##
==========================================
- Coverage   99.68%   99.67%   -0.01%     
==========================================
  Files         421      421              
  Lines       40435    40161     -274     
==========================================
- Hits        40306    40031     -275     
- Misses        129      130       +1     

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

[lillian542]

Looking good, thanks @ludmilaasb! 🚀 I left a couple of comments about tests and examples :)

[trbromley]

[sc-43438]

[mudit2812]

Just one comment, otherwise I'm ready to approve.

[PietropaoloFrisoni]

This is great, Thanks @ludmilaasb!

Just a few comments about documentation from me

[trbromley]

Thanks everyone for getting this merged!