Proposal for refactoring the gate class

[BoxiLi]

Background

In QuTiP, a quantum circuit is represented by a class QubitCircuit, with a list of Gate or Measurement instances saved in it. As the number of gate types increases, it is becoming harder and harder to maintain. In many methods, one needs to iterate over a list of all possible gates (resolve_gate, propagators and latex plotting). This makes adding a new gate very cumbersome. Although there is a class Gate, it is only used to check the input type as well as the name. To make further development on circuit simulation easier, a refactor for Gate is necessary.

Proposal

New Gate class architechture

A new structure for Gate class with different gates defined as subclasses:

Operation

• Gate
  • SingleQubitGate
    • X
    • Y
    • Z
    • ...
  • TwoQubitGate
    • CNOT
    • ISWAP
    • ...
  • ...
• Measurement
• Algorithm
• ...

Common methods for quantum gates such as resolve_gate can be then moved to each Gate subclass:

class X(SingleQubitGate):
    def __init__(self, name, ...):
        self.name = name
        ...
    def resolve_gate(basis=...):
        ...
    def get_unitary(expand=False, dims=None):
        return sigmax()

If a method is not supported for one class, we can simply define a method in the top-level parent class for error handling:

class Gate(Operation):
    def resolve_gate(basis=None):
        raise NotImplementedError("Method not implementated for {}".format(self.gate_name)）

This is a much better structure than a lookup table in every method.

The user interface should not change. However, to support the old syntax Gate("X", targets, controls, ...), we may still need a lookup table in the class Gate.

New way of defining a circuit

The current way of adding a gate to the circuit is the following

circuit.add_gate("X", 1)

With the new gate class, we should be able to also use the following syntax

circuit.add_gate(X(1), Y(2), CNOT(2, 1), ...)

which is more convenient. This could be implemented independently from the new gate class structure.

[purva-thakre]

@BoxiLi Where should I begin with these changes ? Wanted to check where my draft PR should go ? This repo or qutip/qutip where qip module already exists. From Projects tab, it appears you are still in the process of migrating things from the main repo.

For now, I will begin with the new subclasses. Your proposed changes to how a circuit is defined could be made later once all the gates are structured properly.

[BoxiLi]

Hi @purva-thakre , this repo, qutip/qutip-qip. In the next major release, a few modules in the core qutip will be moved out of the core qutip to keep it light while stimulating development in those modules. There will only be bug fix for qutip.qip. New big features shall be added here.

The migration is done! Sorry, I forgot to move the tags. I just added the FREDKIN here bug from the main qutip. Working on qutip-qip should be fine now.

[purva-thakre]

@BoxiLi Feel free to add to the checklist below.

• Move Gate class to gates.py in Operations folder (currently in circuit.py)
• Check that tests still pass.
• Define subclasses of Gate class in Operations folder's gates.py file
• Make sure import gate still works. Add references wherever needed without changing public user interface.

[purva-thakre]

@BoxiLi For the sub-classes of Gate class, do you prefer they be named based on the number of qubits a gate acts on ? From what you have above, the names would be SingleQubitGate, TwoQubitGate etc.

Would you prefer there also be sub-classes based of off what already exists here - single_qubit_gates, para_gates, ctrl_gates, swap_like, toffoli_like and fredkin_like.

[BoxiLi]

Good point, first, the convention for the class naming is the Camel case, so SingleQubitGate is preferred instead of single_qubit_gates. I guess you know this, just in case.

Then the main point about how to divide subclasses. My rule of thumb: How subclasses are defined depends on how many common methods/properties they share. In general, Python supports multiple Inheritance so CNOT can both be a subclass of ControlGate and TwoQubitGate, if needed.

I would say that you can start with each concrete gate, whenever you find that three or more gates sharing the same methods/properties, e.g. checking input, having a control qubit. You can consider making a parent class and define those methods there. It can be flexible and there is no need to follow either existing lists. Some examples I considered in my mind:

• SingleQubitGate definitely worth a subclass. They have a single target qubit, And they also need a special decomposition scheme (if we get your proposal approved by GSoC, which we will know soon), so that you can check easily if a gate is a single qubit gate.
• I'm not sure if TwoQubitGate is needed; I don't have in my mind what would be special for them. (Do they need a special decomposition scheme?)
• ParametricGate might be useful because they have parameters.
• I see no use defining toffoli_like and fredkin_like gate... There is just one gate.

You can define more gate sub-classes if you find them useful or remove them if it is just an empty sub-class

Hope this help

[BoxiLi]

BTW, if I were you, I would try to make two different ways of defining Gate be valid and work at the same time. That is, both Gate("X", 0) and X(0) (or XGate(0), if you prefer) give the same result. It will allow you to replace the old code part by part and test them along the way. Will make things easier I think.

[purva-thakre]

@BoxiLi

BTW, if I were you, I would try to make two different ways of defining Gate be valid and work at the same time. That is, both Gate("X", 0) and X(0) (or XGate(0), if you prefer) give the same result. It will allow you to replace the old code part by part and test them along the way. Will make things easier I think.

This would be done while defining the subclasses ? Or make changes to how Gate class accepts an input.

[BoxiLi]

Oh, sorry I missed this. Didn't get the email. I don't really get the question though. I was just saying that while defining new subclasses and replace the old use of Gate in the rest part of the code, it would be easier if one does it part by part and test each step, if possible.