iSWAP gate and Givens gate

[dariavh]

To the best of my knowledge, the current code has no direct implementation for the

• iSWAP gate $\exp(i\frac{\pi}{4}(X \otimes X + Y \otimes Y))$
• Givens gate $\exp(-i \frac{\theta}{2} (Y \otimes X - X \otimes Y))$

I have implemented them using GeneralizedRotation gates. I have written some test cases for both gates as well. Please let me know if these gates are of any interest to you and if you have further remarks/requests.

[kottmanj]

Hi Daria, Thanks for contributing. We’re definitely interested in contributions like this.
I’m currently on vacation with marginal internet access and won’t be able to go over the code before September. It does however look good on first glance.

One thing I spotted:
I think the Givens gate is the same as “QubitExcitation” with target=[first,second]. Makes still sense to have it as an alias though. You can however then replace the GeneralizedRotation with the corresponding call to QubitExcitation(….).

A convenient iSWAP is however not there yet (know that, because people asked about it in the past :-) ).
Need to check one or two things with the GeneralizedRotation definitions in order to make sure that gradient building will work as expected. I’ll provide more details in ~1.5 weeks when I’m back.

Have a nice weekend.

[kottmanj]

The Givens Rotation is identical to a single-qubit excitation. Can you change the return to:

return QubitExcitation(target=[first,second], angle=angle, control=control, *args, **kwargs)

If done like this, then optimizations in compiling and gradients that are implemented in the QubitExcitation class are also used here.

Slightly different convention:
QubitExcitation generator: XY - YX while here you have YX-XY

If the sign difference matters, you can just switch the qubits in the call to the constrcutor:

return QubitExcitation(target=[second,first], angle=angle, control=control, *args, **kwargs)

[kottmanj]

Looks good!
One issue that will arise with gradient compilation:

The generator here has 3 distinct eigenvalues (+2,-2 and 0), so it is not directly shift-rule differentiable. One can however fix this by exploiting the fact that one of the eigenvalues is 0.

One can fix that in the following:

• write the generator as G = Gp + Gm, where Gp = G + P0 and Gm = G - P0 and P0 is the projector on the eigenspace with eigenvalue zero (in this case P0 = |00><00| + |11><11|)

Now both new generators are directly differentiable. If we know, that the wavefunction this gate is acting on has only real coefficients, the gradient compilation can be optimized further, this is why the assume_real flag can be set. Ideally you just allow this here as well (either explicitly in the declaration, or implicitly via args, kwargs)

The details behind this procedure: https://arxiv.org/abs/2011.05938

fortunately, the qubit excitation class then contains all the necessary technology. We just need to make sure, that specific optimized compilation routines are not called.

p0 = tq.paulis.Projector("|00>") + tq.paulis.Projector("|11>")
p0 = P0.map_qubits({0:first, 1:second})

gate = QubitExcitationImpl(angle=angle, target=generator.qubits, generator=generator, p0=p0, assume_real=assume_real, control=control, compile_option="vanilla", *args, **kwargs)

return QCircuit.wrap_gate(gate)

... this should work (let me know if not)

[dariavh]

@kottmanj Thank you for your extensive review. I have incorporated your comments into the last commit, let me know if you agree with those changes.