parameterize PauliGate()

What should we add?

Would be useful to be able to initialize PauliGate() with a Parameter, which can later be bound to specify whether the PauliGate is I, X, Z, or Y. Multiqubit Paulis could be nice too.

For example, a parameterized PauliGate would facilitate building circuits with random/variable Paulis where one may need to generate a large number of circuit instances that are expensive to transpile individually.

Since Parameters are typically bound to numeric values rather than strings, we could define the gate so that binding to [0, 1, 2, 3] produces the gate [I, X, Y, Z] respectively. Or we could do symplectic ordering corresponding to [00, 01, 10, 11] if that’s better. Alternatively a Parameter could stand in for each of the bits in the x and y tables, but to me that seems like a lot of Parameters. If it’s not too non-standard, we could handle multiqubit paulis by a ParameterVector where each element is bound to one of [0, 1, 2, 3]. I’m not aware of anywhere else a Parameter is expected to take only discrete values, but hopefully that’s not a problem (?).

Currently you can partly work around this limitation by using a u gate (U3 gate) and/or series of p and sx gates, where the p gates can be parameterized. However, this 1) is not hardware efficient as it requires 2 sx pulses instead of 1 x pulse (or sometimes 0 x pulses). And 2) the p gates are not compatible with the stabilizer simulator method.

[jakelishman]

To explain a little more with the current state: there are a few parts of the transpilation process, and while “unknown Pauli gate” will work with one or two early stages, it will quickly fail after that. The rough pipeline is:

1. synthesise many-qubit gates down to 1q or 2q
2. lay out problem onto physical qubits
3. route gates onto physical qubits
4. translate all gates to machine basis
5. optimisation loop
6. (optional) schedule gates at correct times

For hardware backends, we can work with an object that gets us to “unknown Pauli gates on 1q” through the first three stages, but we break down at step 4 - we can’t translate something that’s effectively an unknown gate into the machine basis. It is possible in theory to teach Aer to handle a string parameter (and have PauliGate in Aer’s basis set), but Terra’s not really set up to represent things like that at the moment. That’s where some work on higher-order synthesis is coming in, though.

Another thing coming fairly shortly is better handling of general classical parameters in Terra and Aer, and classical control flow. It will hopefully be possible within the next couple of Terra releases to have a structure that looks like

OPENQASM 3.0;

input uint[2] pauli_type;
if (pauli_type == 1) {
    x $0;
} else if (pauli_type == 2) {
    y $0;
} else if (pauli_type == 3) {
    z $0;
}

pass through the Terra transpiler, and be simulated by Aer (for running on backends, the unknown bit is the interface for how to pass values). We’ll be building from there, but this idea of representing classical types and passing values as circuit inputs is definitely on the roadmap.

[chriseclectic]

I have a version of this working now with equivalence library, which requires a single-qubit Pauli gate that you use to register different decompositions, and then an n-qubit gate with a definition in terms of the single-qubit pauli gates, that works with symbolic gates going through transpiler optimizations, and non-symbolic gates going to regular Pauli gates for stabilizer simulation. I’m not planning on making a PR for this to terra though, just using it in our project that needs it.