Summary

This PR introduces qiskit.quantum_info.PauliLindbladMap, which is a representation of the Pauli-Lindblad parameterization of maps on n-qubits with a qubit-sparse data format.

This initial PR is for setting up the data format, and subsequent PRs will progressively add functionality. As the data-storage format requirements of PauliLindbladMap are the same as that of SparseObservable (storing/indexing/iterating over a list of tuples of [coeff, operator] in qubit-sparse format), this PR consists entirely of copying/modifying components of the SparseObservable mod.rs file. I've attempted to copy over all of the relevant instantiation and indexing functionality (and relevant tests).

Details and comments

The changes to the copied SparseObservable code are primarily due to the different interpretation of what the [coeff, operator] pairs being stored represent. SparseObservable represents the sum $\sum_{(c, A)} c A$ (for $c$ <-> coeff, $A$ <-> operator), whereas PauliLindbladMap represents $\exp(\sum_{(c, A)} c L(A))$, where $L(A) = A \cdot A - \cdot$. (I.e. the data of PauliLindbladMap are the terms in a generator sum, and the object itself represents the exponential.) Below is a list of (hopefully nearly-comprehensive) changes to the copied code:

• Handling of non-Pauli symbols has been removed
  • The non-Pauli parts of BitTerms have been removed (e.g. projections)
  • The bit-storage format for single-qubit terms is now just two bits for the standard symplectic form for representing Paulis.
  • Methods/functionality related to convert Pauli-projectors to Paulis (like pauli_bases) have been removed as they are no longer relevant if non-Pauli symbols are not present.
• the to_observable method of SparseTerm has been renamed to_pauli_lindblad_map
• Instantiation methods from_label, from_pauli, and from_sparse_pauli_op have not been included. These methods make sense for SparseObservable, but would be ambiguous or not well-defined/natural for PauliLindbladMap.
• The PauliLindbladMap.identity constructor method is implemented as SparseObservable.zero, and there is no PauliLindbladMap.zero map.
  • PauliLindbladMap.identity should build the identity map, which means a map with zero generator terms. Data-wise this is equivalent to what SparseObservable.zero (it builds an empty list, which is interpreted as the zero operator).
  • PauliLindbladMap.zero, if it were to exist, should represent the zero map, which can't actually be directly represented in the parameterization given by PauliLindbladMap (and is not particularly useful in any case).
• The coefficients in the model are now forced to be of type f64 (for SparseObservable they are of type Complex64).
  • This required adding/modifying some type-handling/checking and error raising.
• __repr__ has been changed to precede the operator parts in the string with an L, e.g. L(Z_1 X_0).
• In the documentation I've copied over, and in many parts of the code, I've changed various references to "observable" to "map" and "terms" to "generator terms". There are way too many to explicitly mention, so I won't list them here. Admittedly it will make reviewing the changes a bit harder when comparing to SparseObservable, but I think it was necessary to make things self-consistent.

Other notes for reviewers

• I had originally planned to change coeffs to rates for PauliLindbladMap, but at some point I decided coeffs was an acceptable name. I can still make this change if it makes sense.
• At some point we need to think about representing individual qubit-sparse Paulis. I originally though the SparseTerm class (both the rust/python variants) could be renamed to QubitSparsePauli, but SparseTerm here represents both a qubit-sparse Pauli and a coefficient, whereas QubitSparsePauli would be just the operator.
  • This class would be used, e.g., as input to a pauli_fidelity method for calculating the maps fidelity for a given Pauli.
  • Related to this is thinking about what format the output of a sample method would be (it will need to return a list of qubit-sparse Paulis in whatever format we decide on).
  • One option is to define QubitSparsePauli as a new class, and then rewrite SparseTerm to contain a coefficient and a QubitSparsePauli, and re-implement the attributes to just return the contents of QubitSparsePauli
  • I don't think these questions necessarily need to be settled in this PR.
• One of the rust method doc strings in PauliLindbladMap references the canonicalize method, which I haven't yet copied over. I'd like to do this in a subsequent PR but didn't want to delete the reference to this method so that I don't forget to put it back in later.