Fixing Operator.from_circuit for circuits with final layouts and a non-trivial initial layout

[sbrandhsn]

Summary

Operator.from_circuit generates a wrong operator when a final layout is specified with a non-trivial initial layout via the transpile function. This behavior is fixed in this PR while adding new tests to check the correct operator initialization using Operator.from_circuit. This PR also modifies the documentation on the Operator constructor slightly, i.e. there is a hint for using Operator.from_circuit when a non-canonical qubit order/permutation should be assumed for the initialization of the operator.

Details and comments

For example, Operator.from_circuit(transpile(qc, cm, initial_layout=[2, 3, 4, 0, 1])).equiv(qc) would incorrectly return false while Operator.from_circuit(transpile(qc, cm, initial_layout=[0, 1, 2, 3, 4])).equiv(qc) would correctly return true (with the only change being the initial layout).

This is error occurs because the specification of final_layout in Operator.from_circuit does not account for a permutation introduced by the initial_layout of a quantum circuit. However, this permutation is introduced by:

qiskit/qiskit/quantum_info/operators/operator.py

Line 422 in dd2570b

op._append_instruction(instruction, qargs=qargs)

In this PR, the permutation given by final_layout is first combined with the permutation given by the initial_layout before the permutation is applied to the operator.

[qiskit-bot]

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

• @Qiskit/terra-core
• @ikkoham

[coveralls]

Pull Request Test Coverage Report for Build 8454898984

Details

• 17 of 17 (100.0%) changed or added relevant lines in 1 file are covered.
• 6 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.002%) to 89.406%

---

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/expr.rs	1	94.03%
crates/qasm2/src/lex.rs	5	91.86%

Totals
Change from base Build 8454814185:	-0.002%
Covered Lines:	59921
Relevant Lines:	67021

---

💛 - Coveralls

[mtreinish]

Overall this LGTM, thanks for catching this and fixing it. I just had an inline question and a suggestion on the release notes.

[mtreinish]

I'm wondering if we can use final_index_layout() (https://docs.quantum.ibm.com/api/qiskit/qiskit.transpiler.TranspileLayout#final_index_layout) here to simplify this?

[sbrandhsn]

None of the *_*_layout() functions in TranspileLayout appear to yield the correct permutation pattern... :-/

[mtreinish]

I think it would be the inverse of final_index_layout, because final_index_layout returns the final permutation of each qubit but we need the inverse of that to reverse the permutation for the operator construction. Does something like this work?:

final_index_layout = layout.final_index_layout()
perm_pattern = [None]*len(final_index_layout)
for index, pos = enumerate(final_index_layout):
    perm_pattern[pos] = index

[sbrandhsn]

Does not appear to be the case... :-/ One explicit example is

1. [5, 1, 0, 2, 4, 3] - correct
2. [5, 3, 0, 4, 1, 2] - inverse final_index_layout
3. [2, 4, 5, 1, 3, 0] - final_index_layout
4. [5, 4, 1, 0, 3, 2] - initial_index_layout

My impression was that this code might become obsolete with #11399 which is why I did not spend a terrible amount of time on it. :-)

Do you want me to formulate this fix as a function of final_index_layout and initial_index_layout?

[mtreinish]

I'm pretty sure the index layout functions are correct in their current form. Or at least at the time we added them we did a fair amount of testing around that. But I have zero confidence in any statements about handling permutations, so either my assertion that the inverse of final_index_layout is what we want here is incorrect, or final_index_layout() is not correctly written. I'm more inclined the believe the former, but I could see either being possible.

[jakelishman]

Neither initial_index_layout nor final_index_layout are direct permutations within the same Hilbert space, nor are their inverses. They're both layouts - it's correct and expected that neither alone is a suitable permutation within the same space here, because both are $V \leftrightarrow P$ bi-maps and not $P \to P$ nor $V \to V$ maps.

When we're comparing the untranspiled qc to the result of a transpilation out, you can make a new circuit with the same virtual indices, then use initial_index_layout as an inverse permutation at the start (to convert the indices to physical indices of the transpiled one), and final_index_layout as a forwards permutation at the end (to convert back to the virtual indices of the original):

from qiskit import QuantumCircuit
from qiskit.circuit.library import PermutationGate

def undo(transpiled):
    initial = transpiled.layout.initial_index_layout()
    final = transpiled.layout.final_index_layout()

    out = QuantumCircuit(transpiled.num_qubits)
    out.append(PermutationGate(initial).inverse(), out.qubits)
    # After that permutation, the physical-qubit indices of `transpiled`
    # match the virtual-qubit indices of the current circuit.
    out.compose(transpiled, out.qubits, inplace=True)
    # Now map the virtual qubits back to their starting locations.
    out.append(PermutationGate(final), out.qubits)
    return out

Now:

import itertools
import math
import numpy.random

from qiskit import QuantumCircuit, transpile
from qiskit.transpiler import CouplingMap
from qiskit.quantum_info import Operator

def rand_circ(qubits, gates):
    rng = numpy.random.default_rng()
    links = list(itertools.permutations(range(qubits), 2))

    qc = QuantumCircuit(qubits)
    for _ in range(gates):
        qc.rzx(rng.random()*2*math.pi, *rng.choice(links))
    return qc

qc = rand_circ(8, 100)
transpiled = transpile(qc, coupling_map=CouplingMap.from_line(qc.num_qubits))

assert Operator(qc) == Operator(undo(transpiled))

(note that neither qc nor undo(transpiled) have a set layout). I've just used the #10835 methods on TranspileLayout (which already included all the information to make all the correct permutations) and our existing PermutationGate conventions, rather than the #11399 methods on Layout that need extra information and have a different set of conventions.

I haven't done the ancilla suppression here - there's a couple more tricks in doing that, and not doing it lets us treat the index layouts as a type of permutation - but I don't remember off the top of my head how we decided to handle that in Operator.from_circuit.

[jakelishman]

Just to be clear: I'm not necessarily suggesting building the new circuit the way I did in order to power Operator.from_circuit - if nothing else, I don't think that'd work too well with ancilla suppression. I was just using my undo as an example to show how the #10835 TranspileLayout API integrates with the existing PermutationGate and the existing Operator matrix expansions.

My aim with the example above was to show that the only valid use-cases for the #11399 method Layout.to_permutation are already covered by TranspileLayout. Then, in #9523 (comment), I also put in a couple of simple functions just illustrating that the #11399 Layout.compose and Layout.inverse are much simpler if they're only defined in terms of permutations in the already existing sense of PermutationGate.

[sbrandhsn]

Thanks for your suggestions, I still need to figure out the correct point of view when writing PRs and your feedback is very valuable for that! :-)

[alexanderivrii]

After several discussions with @sbrandhsn we have figured out a simpler way to implement the Operator.from_circuit method (which I have pushed here, with Sebastian's agreement). Note that this PR should be rebased on top of #11399 which adds a helper method Layout.to_permutation used here.

One way to think about the transpile function as taking an input quantum circuit C and producing a triple (output quantum circuit T, initial layout P, final layout Q). If there is no ancilla expansion, we have that $$T = P^{-1} - C - P - Q.$$
The notation means that a quantum circuit obtained by first appending $P^{-1}$, then $C$, then $P$ and then $Q$ is equivalent to $T$. Equivalently, the method Operator.from_circuit producing the original operator from the transpiled circuit should produce
$$P - T - Q^{-1} - P^{-1},$$ which is equivalent to $C$. This can be easily achieved by using the methods Operator.append_permutation that we already have in the Operator class.

This should also work when there are ancilla qubits, however $P - T - Q^{-1} - P^{-1}$ will no longer be equivalent to $C$, but to $C$ enlarged with the right number of ancillas. I have added a test for this.

[alexanderivrii]

I believe that the test was also wrong, this is why the behavior is changed after the bug got fixed.

[mtreinish]

LGTM, I agree the behavior was incorrect before and this fixes it.