coveralls
commented
8 months ago Pull Request Test Coverage Report for Build 8718939695
Details
- 168 of 178 (94.38%) changed or added relevant lines in 3 files are covered.
- No unchanged relevant lines lost coverage.
- Overall coverage increased (+0.1%) to 86.883%
| Changes Missing Coverage | Covered Lines | Changed/Added Lines | % | ||
|---|---|---|---|---|---|
| qiskit_nature/second_q/operators/majorana_op.py | 165 | 175 | 94.29% | ||
| <!-- | Total: | 168 | 178 | 94.38% | --> |
| Totals | |
|---|---|
| Change from base Build 8662422324: | 0.1% |
| Covered Lines: | 8949 |
| Relevant Lines: | 10300 |
grossardt
woodsp-ibm
Summary
Adds a new class
.second_q.operators.MajoranaOpimplementing a Majorana fermion operator, along with aM̀ajoranaOp.from_fermionic_opconstructor method to convert aFermionicOpinto aMajoranaOp. Fixes #1257M̀ajoranaOpis implemented as aSparseLabelOp, closely following the implementation ofFermionicOp. The syntax for operator labels is'_0 _1'for $\gamma_0 \gamma_1$ etc.Details and comments
Label syntax
The reasoning for choosing
'_0 _1'as a label style was a compromise between compatibility (MajoranaOpshould also be aSparseLabelOpwith a syntax close to those ofFermionicOpandBosonicOp), readability, and sparsity. Technically, a Majorana operator is defined by just a list of indices, but any non-string format would be incompatible with the other operators. I was considering something like'$_0 $_1'with some character $ in order to have the closest possible format to the other operators, but since there is no canonical choice for the $ symbol ($\gamma$ would be, but is problematic as a non-ASCII character, I was considering'g_0','#_0', etc.) I thought, the most reasonable choice is to keep the underscore for readability and clarity that we are dealing with an index but omit the +/-/$/... completely. Since this is clearly a relevant choice and pretty subjective, I post this as a draft pull request and am looking forward to discussing this.Implementation of MajoranaOp
MajoranaOpis largely copy&paste fromFermionicOpwith some more or less trivial adaptions. The main differences areMajoranaOp.from_fermionic_opthat converts a Fermionic operator to Majorana. Conversion follows the same convention as in openfermion, i.e. $fk = (\gamma{2k} + i \gamma_{2k+1})/2$ is the $k$-th annihilation operator expressed in terms of the Majoranas.num_spin_orbitalsis truly meant to count the number of fermionic orbitals, hence indices run from 0 to2 * num_spin_orbitals - 1since every orbital with its creation/annihilation operators gets mapped to two Majorana operators.I documented everything mostly in the exact same style as in the docstrings for
FermionicOp- i.e. I believe that the documentation is taken care off, modulo the issue with arguments I opened in #1269 .I also implemented tests for all methods (again mostly just copy&paste from the corresponding tests of
FermionicOp).Order of operator classes in documentation
In
__init__.pyI addedMajoranaOpdirectly underneathFermionicOpwhich makes it the second operator to appear in the list in the API reference beforeBosonicOp. I guess this is debatable, sinceBosonicOpis clearly the more important operator, but then I think that it makes sense to group Majorana and Fermionic operators together. Alternatively, one could also putBosonicOpat the top, followed byFermionicOpandMajoranaOpwhich is the order in which one would most likely find them in a textbook, or simply opt for alphabetical order.Changes to FermionicOp
I made two changes to
FermionicOp:FermionicOp._index_orderis turned into a classmethod so it can be called from withinMajoranaOp.index_orderas well (to avoid redundancy).FermionicOp.to_matrixin the docstring since such a method does not seem to exist (unrelated to the Majorana changes)All changes are summarized in the release note.