Shorter and more structured gate definitions (part 1)

[dmitrimaslov]

What is the expected enhancement?

Regarding the qelib1.inc file.

1. Line 13: It helps to double define the CNOT gate as the CNOT:

gate cnot c,t { CX c,t; }

2. Line 22: It helps to double define NOT gate as the NOT gate:

gate not a { u3(pi,0,pi) a; }

3. Lines 30-32: Phase gate is sufficiently often denoted as p. Physicists like s, but in CS, it is p. It is certainly worth having p, even if in addition to s;

4. Line 32: dagger may be coded as d since d is a clearly distinguishable suffix. d is shorter than dg and thus more compliant with the spirit of Shannon's optimal coding, as well as other notations, such as h for Hadamard;

5. Line 48: this is controlled-Z, not controlled-Phase;

6. Line 55: a shorter implementation of controlled-H is:

gate ch a,b {
    p b;
    h b;
    t b;
    cnot a, b;
    td b;
    h b;
    pd b;
}

It requires only one CNOT, but not two. Maybe worth writing the single-qubit sequence PHT (and, symmetrically, its inverse) using U gates, maybe not.

7. Line62: It is worth introducing controlled-Phase=controlled-sqrt-Z, cp, and controlled-sqrt-NOT, cv, as well as their complex conjugates, cpd and cvd. Controlled-sqrt-Y may also be there for symmetry, even though I have not seen it being used much. The ‘problem’ with controlled-sqrt-Y is it does not appear to have a standard notation. So maybe skip for now. Note that in the future cv will most likely be implemented directly as a single physical level two-qubit gate.

8. Lines 63-72. CCX is best implemented as:

gate rccx a,b,c
{
    h c;  
    t c;
    cx b,c; 
    tdg c;  
    cx a,c; 
    t c;  
    cx b,c; 
    tdg c;  
    h c; 
}
// note the relevance to Margolus gate, Nielsen-Chuang, page 183.
gate ccx a,b,c
{
    rccx a,b,c;  
    cz a,c;  
    cp a,b;
}

This exposes Toffoli gate’s structure: CCX is RCCX phase corrected by CZ(a,c) and CP(a,b). It is an important structure. It is also worth defining Toffoli as tof in addition to ccx.

9. Line 89: can be worth parallelizing the singe-qubit gates. There are two ways to do it such that phase applies to primary qubits a and b;

10. Note that in the future cv may be implemented directly as a single physical level two-qubit gate. This means some of the circuits will admit shorter implementations. Specifically, ccx (also helps to have it as tof) will require only 5 gates, and the cost of cswap will drop to 6 two-qubit gates.

More to come.

[1ucian0]

the qelib1.inc file should not be modified (see #6125). However, can somebody check if the cases of shorter gates definitions apply when calling gate.definition? Please, open issues/PRs for those cases.

[1ucian0]

An example of the current (0.19) definition:

from qiskit.circuit.library import CCXGate
CCXGate().definition.draw()

                                                       ┌───┐      
q_0: ───────────────────■─────────────────────■────■───┤ T ├───■──
                        │             ┌───┐   │  ┌─┴─┐┌┴───┴┐┌─┴─┐
q_1: ───────■───────────┼─────────■───┤ T ├───┼──┤ X ├┤ Tdg ├┤ X ├
     ┌───┐┌─┴─┐┌─────┐┌─┴─┐┌───┐┌─┴─┐┌┴───┴┐┌─┴─┐├───┤└┬───┬┘└───┘
q_2: ┤ H ├┤ X ├┤ Tdg ├┤ X ├┤ T ├┤ X ├┤ Tdg ├┤ X ├┤ T ├─┤ H ├──────
     └───┘└───┘└─────┘└───┘└───┘└───┘└─────┘└───┘└───┘ └───┘  

[ShellyGarion]

Note that there are several equivalent definitions for MCXGate: MCXGrayCode, MCXRecursive and MCXVChain
If you put n=2 they all provide the usual CCXGate.
We need to consolidate all these various definitions into a synthesis library, and then we can check what is the best definition also for a CCXGate.

Note that currently the equivalence library has a shorter definition for a CCXGate:
https://github.com/Qiskit/qiskit-terra/blob/6742941a62bf1a12c854f028dab15489118b6c15/qiskit/circuit/library/standard_gates/equivalence_library.py#L756-#L768

Perhaps we can add the suggested alternative of the CCXGate and the CSWAPGate to the equivalence library as well?

[jakelishman]

I'm going to close this issue now; the definitions given in the OQ2 include file aren't something we're going to change (ideally, it's a standardised include file), and don't impact any parts of synthesis. Some of these definitions could potentially be added / changed in the standard equivalence libraries, but that's a general synthesis problem that's not really related to the initial concern of this issue.

Feel free to re-open if there's more to discuss.