Family of iSwap gates

[Cryoris]

What should we add?

It would be nice to add variable iSwap gates instead of the fixed one we have right now. These could be used as the two-qubit interaction within qiskit.circuit.library.ExcitationPreserving and qiskit-community/qiskit-nature#462.

The current iSwap is defined as

exp(i pi/4 (XX + YY))

so the natural choice for a parameterized version would be just to replace pi / 4 by an angle and keep the interaction as XX + YY. What would be a good way to incorporate different interactions, such as YX - XY as in qiskit-community/qiskit-nature#462?

@kevinsung @ajavadia

[kevinsung]

I just realized now that gate exponentiation is indeed supported by qiskit. It was hard to discover because gate**x doesn't work, but gates have a power method defined (see #7473). So the parameterized family of iSwap gates you mention is already accessible. I think the method of exponentiating basic gates to access different interactions is a good general approach.

[jakelishman]

Using arbitrary matrix powers isn't necessarily ideal; doing so creates a UnitaryGate, which is essentially just a wrapper around a dense matrix, so it requires exponentiating arbitrary matrices which is a bit slow. The transpiler then has to perform fairly costly unitary synthesis to turn it back into useful basis gates as well. If there is a reasonable decomposition available (and here I'm sure there is), it's likely better to keep the gate in that form, which needs a general representation defined.

If there is a general representation, we can override power to just multiply the rotation angle by the new power for these. We'll need to go through a warning period for Gate.power, though, because we'd be changing its return type.

[kevinsung]

I agree that we should override power in cases where it is easily computed. The general representation of a gate can simply be the base gate along with the exponent. For example, the initialization of iSwapGate takes an exponent argument which defaults to 1.0.

[jakelishman]

I think defining this on top of iSwapGate is the wrong way around, but the principle is the same. By analogy to rotation gates, I'd think the more natural choice for the "base" of the exponent is exp(i (XX + YY)) in this case (what Julien suggested at the top, though maybe we'd want a factor of 1/sqrt(2) here?), and then base ** (np.pi / 4) would be equivalent to the current iSwapGate. In this form, calling the pi/4 parameter an "exponent" is probably confusing to users; by analogy to general rotations, it's like an angle rather than being defined as a ratio to the pre-existing pi/4.

Then we're back to the original question a little - we might want a slightly more general way of representing any such controllable n-qubit - we're interested in a general form that allows any Pauli vector as the interaction, while fitting within the transpiler requirements that gates separated by more than just Instruction.params have separate names.

[kevinsung]

I disagree that iSwapGate should be recovered by base ** (np.pi / 4). The "exponent" and "rotation angle" are distinct concepts which differ by a factor that involves pi, so it is confusing to define the base in a way that attempts to merge the concepts. While arbitrary powers of gates are not commonly referenced in the quantum computing literature, it is common to see references to the square roots of gates such as "square root of X" or "square root of iSwap" (exponentiation by 0.5), so this distinction is consistent with the literature.

It is definitely useful to be able to specify gates in terms of rotation angles rather than exponents. This can be achieved by providing constructor functions that take the angle as input:

def rxxyy(theta):
    return iSwapGate(exponent=-2 * theta / pi)

[ajavadia]

I just remembered that we recently added the XYGate. This is basically the same thing. A rotation about the XX+YY axis is typically called an XY gate in the literature (see this or this) - though I don't love the name.

But I think there is no new gate to be added here, right?

It would be nice to override the iSwapGate.power() method so that it gives an XY gate, rather than a UnitaryGate. The UnitaryGate thing is just a fallback so any arbitrary gate can be raised to a power.

It would also be good to edit the docstring for XYGate to mention these relationships. i.e. the fact that XY(pi,0) gives iSwapGate. Also perhaps adding a reference

[kevinsung]

@ajavadia Thanks for telling me about XYGate. I have closed qiskit-community/qiskit-nature#462 because indeed, no new gate needs to be added.

We should still override the power method of iSwap gate (and others, for that matter) so that the resulting gate stays of the same type.

[kevinsung]

Should we make iSwapGate a subclass of XYGate?

[ajavadia]

We should still override the power method of iSwap gate

I agree

Should we make iSwapGate a subclass of XYGate

I'm not sure, what is the advantage? Our gates don't currently have a lot of deep structure to them (i.e. RX/RZ/RY could all be UGate, but they are not).

[kevinsung]

The advantage would be that we would only have to implement and maintain the gate decomposition and exponentiation in one class instead of duplicating it between two classes.