Add .apply_layout()method to Pauli class
#12066
Conversation
|
One or more of the the following people are requested to review this:
|
Pull Request Test Coverage Report for Build 8644607674Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
ElePT
added
Changelog: New Feature
| raise QiskitError("Provided layout contains indices outside the number of qubits.") | ||
| if layout is None: | ||
| layout = list(range(self.num_qubits)) | ||
| new_op = type(self)("I" * n_qubits) |
There was a problem hiding this comment.
I realize I did the same thing in #10947 but I'm wondering if there is a more efficient constructor here that doesn't require creating a giant string like this.
There was a problem hiding this comment.
Hmmm, as far as I know, there is no good way to "sparsely" define long operators with only a few non-identity terms, in fact, I think that this is exactly what this issue describes (the word "layout" has a different meaning here: #11891).
There was a problem hiding this comment.
Well, you can directly generate the symplectic Boolean matrices, but fundamentally, Pauli and SparsePauliOp aren't sparse over qubit number - the latter is "sparse" over the full Pauli vector.
Max's issue is about that sort of thing, yeah, although practically I don't think it's something we'll be able to put directly into Pauli and SparsePauliOp - I think it's something we'd do as new QI classes, probably directly in Rust space. This it the kind of thing that Paul's been interested in before as well, and similar to how OpenFermion and friends represent operators on huge spaces. The primitives want that as well.
Co-authored-by: Matthew Treinish <[email protected]>
| def test_apply_layout_with_transpile(self): | ||
| """Test the apply_layout method with a transpiler layout.""" | ||
| psi = EfficientSU2(4, reps=4, entanglement="circular") | ||
| op = Pauli("IZZZ") | ||
| backend = GenericBackendV2(num_qubits=7) | ||
| transpiled_psi = transpile(psi, backend, optimization_level=3, seed_transpiler=12345) | ||
| permuted_op = op.apply_layout(transpiled_psi.layout) | ||
| identity_op = Pauli("I" * 7) | ||
| initial_layout = transpiled_psi.layout.initial_index_layout(filter_ancillas=True) | ||
| final_layout = transpiled_psi.layout.routing_permutation() | ||
| qargs = [final_layout[x] for x in initial_layout] | ||
| expected_op = identity_op.compose(op, qargs=qargs) | ||
| self.assertNotEqual(op, permuted_op) | ||
| self.assertEqual(permuted_op, expected_op) | ||
|
|
There was a problem hiding this comment.
Just for completeness' sake, could you add a test that SparsePauliOp(Pauli(p).apply_layout(layout)) produces the same result as SparsePauliop(Pauli(p)).apply_layout(layout)? Just a consistency test, to enforce that we don't forget one or the other while updating.
There was a problem hiding this comment.
I think that you were meaning to say SparsePauliOp(Pauli(p).apply_layout(layout)) produces the same result as Pauli(p).apply_layout(layout), right? This is what I added in 434a21c.
There was a problem hiding this comment.
Yeah, that's fine too - you've ended up reducing the SparsePauliOp to a PauliList to check, whereas I was suggesting raising the Pauli to a SparsePauliOp to compare, but both test the same thing that I wanted to test.
There was a problem hiding this comment.
ahaa, I didn't notice the brackets. I can also do it the way you originally suggested (looks cleaner to compare the exact same type).
Summary
This PR adds an
apply_layoutmethod to thePauliclass, following what was done forSparsePauliOpin #10947. This was the agreed action to partially solve #11824 in the short term until a more permanent/extensible solution is designed.Details and comments