Extend the list of well known gates

[burgholzer]

The current list of well-known gates (https://github.com/unitaryfoundation/jeff/blob/main/docs/spec.md#wellknowngate) already contains quite some gates, but might be missing a few, or, at least, I have some questions on how certain operations are expected to be represented.
I'll try to break it down gate by gate.

This is mostly inspired by our work on connecting the MQT's MLIR infrastructure from MQT Core with Jeff.

Two-qubit rotation gates

Gates:

• rxx (example definition at https://github.com/Qiskit/qiskit/blob/main/qiskit/circuit/library/standard_gates/rxx.py)
• ryy (example definition at https://github.com/Qiskit/qiskit/blob/main/qiskit/circuit/library/standard_gates/ryy.py)
• rzz (example definition at https://github.com/Qiskit/qiskit/blob/main/qiskit/circuit/library/standard_gates/rzz.py)
• rzx (example definition at https://github.com/Qiskit/qiskit/blob/main/qiskit/circuit/library/standard_gates/rzx.py)

are these supposed to be represented as Pauli-product rotations in Jeff or does it make sense to add them explicitly?

Qiskit also defines xx_plus_yy and defines xx_minus_yy, which each have two angle parameters.
Within the MQT, we support these as well. Similar question to above: does it make sense to add these explicitly, or are they supposed to be defined differently?

sqrt(X) or sx agte

The SX gate is a native gate on IBM machines (definition).
Is the intention to represent this as pow(0.5) @ X in Jeff or does it make sense to explicitly define this gate?

R gate

The R gate is the native single-qubit gate on IQM quantum computers (definition).
I suppose it makes sense to add this as an explicit single-qubit, two-parameter gate.

iSWAP gate

The iSWAP gate is a native gate on Google's quantum computers (definition).
I suppose it makes sense to add this as an explicit two-qubit, no-parameter gate.

ECR gate

The echoed cross resonance gate is a native gate on some superconducting systems that underlies the implementation of CX gates, for example (definition).
I suppose it makes sense to add this as an explicit two-qubit, no-parameter gate.

DCX gate

Qiskit does define the dcx gate as a double-cnot (two CNOTs with exchanged control and target).
I am not 100% sure, whether this particular gate is too important, but it probably would not hurt to explicitly add it.
One could also argue that it should simply be represented as two consecutive CNOTs.

U2 rotation gate

The U2 gate has been defined as a more specific U3 gate. Specifically, it is defined as U3(π/2,φ,λ).
Should Jeff define this gate explicitly or do we believe it is better to simply represent it through its definition via u3?

[josh146]

All good questions --- iirc our decision making here was to identify the smallest common subset of gates that are needed at the compilation level (due to the intricacies of maintaining a large list of gates and conventions).

Initially, we were trying to avoid having a set of gates altogether, but realized that given this is for compiler interop, we need some level of agreement (whether between tools or in the exchange format itself).

All this to say: all points are worth discussing, some ops might have been missed by us, and others we may decide should be represented with existing ops.

[dime10]

The philosophy was definitely erring on the side of minimalism regarding the "pre-defined" gate set, like Josh is saying. I think some of the more esoteric ones you propose are clear candidates for the extension mechanism we put in place, that is if two tools wish to exchange a gate known to both they can easily do so via the custom gate instruction.

Having said that, we're happy to amend the built-in list where needed. My 2 cents on some of the listed gates:

• RXX etc: special case of pauli product rotations
  • I think your suggestion is good. Special cases like these can easily be handled in the import/export process whenever such gates are available in a given tool from the more generic operator.
• xx_plus_yy: Doesn't fit into any existing operator, but I think this is a perfect use for custom since I've never come across it (although that doesn't have to mean much).
• DCX: I'm not sure of its importance either, custom or double cx seems reasonable.
  • Now unlike the special cases of single operators, one thing that we should avoid is having to rely on multiple instructions in order to "recompose" a given operator. That is, while RXX can easily be identified from a single PauliRot(XX), identifying DCX from two consecutive CX is much more involved. So the criteria for inclusion would probably be 1) commonly used or required and 2) can't be represented by an existing single operator.
• U2: another special case (of U3)
  • I'm not sure there is much to gain by adding it, since something like U3(0, b, c) should pretty much carry the same information content.
• iswap and sqrt(x): I think it's alright to add these, they seem to relatively common.

[glassnotes]

I'm wary of baking in hardware-native gates because hardware evolves over time, different providers with the same modality might use the same base gate but different sign / parameter value, etc.

Could there be an "in between" solution that adds a layer of infrastructure to develop and share custom gate libraries, kind of like how PennyLane has different device plug-ins for different providers? This might be preferable to a proliferation of individual gates, but does risk creating a proliferation of gate libraries which have to be maintained (but maybe they could be set up as user-provided and maintained add-ons).

[burgholzer]

Thanks for the feedback @dime10 and @josh146 🙏🏼

The philosophy was definitely erring on the side of minimalism regarding the "pre-defined" gate set, like Josh is saying. I think some of the more esoteric ones you propose are clear candidates for the extension mechanism we put in place, that is if two tools wish to exchange a gate known to both they can easily do so via the custom gate instruction.

Having said that, we're happy to amend the built-in list where needed. My 2 cents on some of the listed gates:

• RXX etc: special case of pauli product rotations

  • I think your suggestion is good. Special cases like these can easily be handled in the import/export process whenever such gates are available in a given tool from the more generic operator.

👍🏼 We should be able to work with this. @denialhaag, right?

• xx_plus_yy: Doesn't fit into any existing operator, but I think this is a perfect use for custom since I've never come across it (although that doesn't have to mean much).

👍🏼 Seems reasonable to me. To be fair, we also only support it because Qiskit defines it as one of its "default" gates. Using a custom seems entirely reasonable.

• DCX: I'm not sure of its importance either, custom or double cx seems reasonable.

  • Now unlike the special cases of single operators, one thing that we should avoid is having to rely on multiple instructions in order to "recompose" a given operator. That is, while RXX can easily be identified from a single PauliRot(XX), identifying DCX from two consecutive CX is much more involved. So the criteria for inclusion would probably be 1) commonly used or required and 2) can't be represented by an existing single operator.

👍🏼 That criterion makes sense. Although I have to say that I probably would not really apply it to the DCX gate, because I very much doubt that it is that important. I'd rather go the custom route here.

• U2: another special case (of U3)

  • I'm not sure there is much to gain by adding it, since something like U3(0, b, c) should pretty much carry the same information content.

👍🏼 Yeah, agreed. I think this is also more of a relic from the past that exposed some implementation details of how early-day IBM machines realized certain gates. It's not particularly important these days and can be inferred from the U3 case if necessary.

• iswap and sqrt(x): I think it's alright to add these, they seem to relatively common.

👍🏼 Great. That should be fairly straight forward.

---

This leaves the R gate and the ECR gate up for discussion.

Based on the discussion from above, I would probably specify the ECR gate as a "custom" gate as it is not that commonly used anymore in current-day devices.

For the R gate, I am not too sure. There is the equivalence R(θ, φ) = U3(θ,-π/2 + φ,π/2 - φ). So one could, with moderate effort, determine the R gate as a specialization of U3 similar to how this would work for U2 above. I am slightly worries about numerical inaccuracies in these conversions, which would probably trip up round-trips.

---

One other thing I am worried about is something that I believe I have brought up at IEEE Quantum Week last year already: Custom gates do not carry any semantic definition in Jeff at the moment. So two tools have to entirely agree on the semantics of two operations based on a string identifier. This seems fairly fragile.
Obviously nothing to be solved as part of this issue, but maybe an argument for revisiting whether it is really good to keep the list of known gates rather minimal as opposed to clearly defining them as part of the spec.

[josh146]

One other thing I am worried about is something that I believe I have brought up at IEEE Quantum Week last year already: Custom gates do not carry any semantic definition in Jeff at the moment. So two tools have to entirely agree on the semantics of two operations based on a string identifier. This seems fairly fragile.

💯, this is something I would love to have a novel solution for.

[burgholzer]

I'm wary of baking in hardware-native gates because hardware evolves over time, different providers with the same modality might use the same base gate but different sign / parameter value, etc.

I get your point. This is also apparent from some of the comments above. Some of these gates are definitely relics of the past or at least not that common anymore.

Could there be an "in between" solution that adds a layer of infrastructure to develop and share custom gate libraries, kind of like how PennyLane has different device plug-ins for different providers? This might be preferable to a proliferation of individual gates, but does risk creating a proliferation of gate libraries which have to be maintained (but maybe they could be set up as user-provided and maintained add-ons).

Hm. OpenQASM had this concept of "includes" (similar to C/C++) since OpenQASM 2. However, in practice, I have only ever seen people use the standard library that comes with Qiskit (which had evolved over time and did not match the Spec anymore; which led to the legacy QASM2 mess in Qiskit https://quantum.cloud.ibm.com/docs/en/api/qiskit/qasm2#legacy-compatibility).

That being said, some way of actually going beyond simply declaring custom gates via strings but rather via actual definitions, would go a long way here. These could either be unitary definitions (in case of small operations) or definitions in terms of other well-known gates.
The part of the OpenQASM 3 spec on this is actually quite interesting: https://openqasm.com/language/gates.html#defining-gates

There are 3 mechanisms to construct new gates:

• A new named gate can be introduced by a hierarchical definition from a sequence of existing gates;
• Anonymous new gates may be defined by applying gate modifiers to existing gates;
• The built-in gates comprising the one-qubit gate U(θ, ϕ, λ) and the zero-qubit gate gphase(γ). The definitions of these gates is part of the language specification.

The built-in standard library of OpenQASM 3 includes several gate definitions for convenience.

[dime10]

One other thing I am worried about is something that I believe I have brought up at IEEE Quantum Week last year already: Custom gates do not carry any semantic definition in Jeff at the moment. So two tools have to entirely agree on the semantics of two operations based on a string identifier. This seems fairly fragile.
Obviously nothing to be solved as part of this issue, but maybe an argument for revisiting whether it is really good to keep the list of known gates rather minimal as opposed to clearly defining them as part of the spec.

I think the ideas developed by @edyounis are meant to tackle exactly this problem.