Closes #557, in-place implementation of expval for LightningQubit

[sbohloul]

Context:
This PR modifies the expval method for named operations using an in-place, OpenMP parallel, implementation to avoid creating an extra intemediate statevector.

Description of the Change:
The implementation closely follows that of MeasurementsKokkos.hpp. It adds the corresponding functors in ExpValFunctorsLQubit.hpp and modifies MeasurementsLQubit.hpp accordingly. It uses the existing tests of named operators in Test_MeasurementsLQubit.cpp to validate the changes.

Benefits:

• Avoiding creating an extra intermediate statevector
• An order of magnitude speedup in calculating the expected value of PauliX, PauliY, PauliZ, Hadamard, and Identity operators. See performance benchmark for some comparisions.

Possible Drawbacks:

Related GitHub Issues:
Closes #557

[sc-65192]

[sbohloul]

@Alex-Preciado Please see here for the benchmark script and its artifacts.

[Alex-Preciado]

Thank you so much for preparing this PR, @sbohloul ! The team will have a look next week, and we will come back to you with feedback. Let me know if you have any other questions in the meantime.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (028ad9b) 98.70% compared to head (2013366) 96.95%.
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #565      +/-   ##
==========================================
- Coverage   98.70%   96.95%   -1.75%     
==========================================
  Files         168      146      -22     
  Lines       22763    18113    -4650     
==========================================
- Hits        22468    17562    -4906     
- Misses        295      551     +256     

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

[AmintorDusko]

Hi @sbohloul, thank you for your contribution.
The Codecov report shows that some areas of your code are not been touched by the test suite. Could you please expand tests, so you can improve code coverage?

[mlxd]

Thanks for the submission @sbohloul

As suggested by @AmintorDusko it would be great to see some additional test coverage as reported by the CI.

Also, I have some questions based on the implementations:

[sbohloul]

Hi @sbohloul, thank you for your contribution. The Codecov report shows that some areas of your code are not been touched by the test suite. Could you please expand tests, so you can improve code coverage?

@AmintorDusko Thank you for your feedback. I expanded the coverage as suggested.

[sbohloul]

Thanks for the submission @sbohloul

As suggested by @AmintorDusko it would be great to see some additional test coverage as reported by the CI.

Also, I have some questions based on the implementations:

@mlxd Thank you for your feedback and questions. I applied several of your comments. Please find my answers in correspoding section.

[AmintorDusko]

Thank you @sbohloul, for the improvement in coverage. I have a few more questions/suggestions.

[mlxd]

Thanks a lot @sbohloul
Some final comments from me on this. Great work on the implementation.

[sbohloul]

@Alex-Preciado I was wondering if there are any other requirements to be fulfilled regarding this PR.

[mlxd]

@Alex-Preciado I was wondering if there are any other requirements to be fulfilled regarding this PR.

Thanks for the submission @sbohloul :) Happy to say we can come to this PR at a later date --- nothing left to do here for now. The team will reach out to you shortly about the next steps.

[sbohloul]

@mlxd @AmintorDusko Thank you again for your helpful comments to navigate this PR. I would be happy to finalize the work here since we already spent some time on it. Please let me know what are your toughts about this.

[vincentmr]

Hi @sbohloul , nice work there. If you have time, I'd like us to update and merge this PR. We should first merge master in this branch, update the CHANGELOG and fix conflicts accordingly. Next, I would like us to change the implementation to avoid the use of functors. This is too much boilerplate for host-only code (sometimes required for device-generic code as in Kokkos however). Could you have a look at the LM kernels's applyNC1? Could we write a lambda-templated method that accumulates the expval of a generic gate? We could then simply write something like

switch (expval_funcs_.at(operation)) {
[...]
case ExpValFunc::PauliX:
auto core_function = [](std::complex<PrecisionT> *arr,
                                const std::size_t i0, const std::size_t i1) {
            std::swap(arr[i0], arr[i1]);
        };
[...]
}
applyExpVal1<PrecisionT, decltype(core_function)>(wires, core_function);