Add apply_layout method to SparsePauliOp

[mtreinish]

Summary

This commit adds a new method, apply_layout, to the SparsePauliOp
class. It takes in either a TranspileLayout object or a list of
indices that represent a layout transformation caused by the transpiler
and then returns a new SparsePauliOp object that applies a matching
transformation.

Details and comments

This PR is based on top of #10835 and includes the contents of that PR. To see the content of just this PR you can view:

https://github.com/mtreinish/qiskit-core/compare/imrpove-transpile-layout...mtreinish:qiskit-core:apply-layout-spare-pauli-op?expand=1

[qiskit-bot]

One or more of the the following people are requested to review this:

• @Qiskit/terra-core
• @ikkoham
• @mtreinish
• @nkanazawa1989

[coveralls]

Pull Request Test Coverage Report for Build 6424225330

• 16 of 17 (94.12%) changed or added relevant lines in 1 file are covered.
• 26 unchanged lines in 4 files lost coverage.
• Overall coverage decreased (-0.02%) to 87.004%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/quantum_info/operators/symplectic/sparse_pauli_op.py	16	17	94.12%

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/expr.rs	1	93.76%
qiskit/pulse/library/waveform.py	3	93.75%
crates/qasm2/src/lex.rs	4	90.4%
crates/qasm2/src/parse.rs	18	96.67%

Totals
Change from base Build 6414428479:	-0.02%
Covered Lines:	74166
Relevant Lines:	85244

---

💛 - Coveralls

[jaygambetta]

can we also make it take a layout object

[ajavadia]

can you rebase this PR? Overall it looks good to me.
I opened an issue in Aer so that observables that are enlarged with I due to this PR still remain simulable: Qiskit/qiskit-aer#1952

[mtreinish]

can we also make it take a layout object

I'm not sure there is a simple path for supporting just a Layout object. A layout object maps virtual Qubit objects to positional indices and that isn't enough information to know how to apply the layout because we don't know the starting position for the virtual Qubit objects. The TranspileLayout contains a dictionary mapping the Qubit objects to the their initial position which final_index_layout() is using to build the output array used for qargs here.

[mtreinish]

can you rebase this PR?

Done

[ajavadia]

I'm not sure there is a simple path for supporting just a Layout object. A layout object maps virtual Qubit objects to positional indices and that isn't enough information to know how to apply the layout because we don't know the starting position for the virtual Qubit objects.

I'm confused, this current PR accepts a list of integers, which seems like it would contain strictly less information than a Layout object would. So if a list of integers is possible, Layout should be possible too?

[mtreinish]

I'm not sure there is a simple path for supporting just a Layout object. A layout object maps virtual Qubit objects to positional indices and that isn't enough information to know how to apply the layout because we don't know the starting position for the virtual Qubit objects.

I'm confused, this current PR accepts a list of integers, which seems like it would contain strictly less information than a Layout object would. So if a list of integers is possible, Layout should be possible too?

The difference is that a Qubit object doesn't have any associated position with it. It's just a Python object we don't know where it was in the circuit just from the object. For a concrete example, if you had an input circuit generated by this

qr = QuantumRegister(3)
qc = QuantumCircuit()
qc.add_bits([qr[i] for i in [2, 0, 1]])
qc.h(0)
qc.cx(0, 1)
qc.cx(0, 2)

if you had solely a Layout object from the transpiler output with this circuit as an input it would be the equivalent of a dictionary mapping something like:

{qr[0]: 0, qr[1]: 1, qr[2]: 2}

with solely this mapping you wouldn't know how to transform the operator as this layout object doesn't have any details about the starting position of each qubit. (I used registers here to illustrate you can't rely on ordering of bits, but also if you used bare Qubit() qubits there isn't anything in it). If you combined the circuit with the layout object you'd be able to figure out that qargs on the internal compose() call should be [2, 0, 1]. This is a big part of why I don't like the Layout class and prefer to use integers.

A list of integers is different because it maps ever index in the list to it's new position, so we have all the information needed to apply the layout.

[ajavadia]

Ok @mtreinish I think I see now the problem is with the Layout class. I'm fine with this PR

[kevinhartman]

LGTM