Refactor Gate class (1)

[Mayank447]

• Merge changes from master branch (Removed unused variables and minor corrections #311 and Replace n with num qubits #317)
• Replaced get_compact_qobj with get_qobj and deprecated the former.
• Added is_clifford, self_inverse class attributes to Gate class.
• Moved num_ctrls class attribute, from Gate class to ControlledGate Gate class.
• Renamed ParametrizedGate class to ParametricGate`.
• Added num_params class attributes, validate_parameters method to Parametric Gate class.
• Removed ControlledParamGate class and included that functionality in ControlledGate class itself.
• Added a metaclass for Gate to disallow modification of Gate class attribution (since they are shared among all object instances).
• Added __init_subclass__ in Gate, ParametricGate, ControlledGate class and several checks on class attribute type and value.
• Rename gate factory functions to unitary_gate, controlled_gate.
• Spilt standard gates into operations/std/ dir, later renamed to /operations/gates dir in Refactor Gate class (2) #328.
• Deprecated redundant gates (Closes Depreciate SNOT and replace with H gate #296)
• Deprecated string gate input, control_value, arg_value and arg_label in add_gate method.
• Deprecated gates.py
• Added typing.py
• Minor fixes to qiskit backend, algorithms.

[BoxiLi]

Glad to see this coming! It seems like a very big collection. Are there ways to make it smaller? Maybe only the parts that resolve the master branch conflict?

[Mayank447]

Hi,

Yes, the number of commits did considerably exceed my expectation for this PR. And there is still a little work left.

I can split this PR into two (one before merge master) and one after, this should help with reviewing. Any changes as per the code review for the first half, I will do in the second PR to avoid any merge conflicts. How does it sound?

Also the major code changes are operations/, circuit.py and test_gates.py, it's better to review those files first.

[BoxiLi]

Any changes as per the code review for the first half, I will do in the second PR to avoid any merge conflicts. How does it sound?

Yes, that sounds better. The merging one will require less code review.

[Mayank447]

@BoxiLi I have splitted this PR into two. The failing tests in this PR are because of pytest raising error for DeprecationWarning, you can ignore that. Everything passes in #328 (the second PR).

This PR is ready for review.

[BoxiLi]

I was wondering about the name std can we find something more user-friendly? Or simply encourage people to import from the gateclass module.

from qutip.operations import gateclass
gateclass.X

Though I still think it would be convenient to keep the string input.

[BoxiLi]

Another thing I find slightly inconsistent is parameteric gates and std gates. For a parameteric gate, one calls parametricgate(argvalue).get_qobj(), for other gates like std, it is simply stdgate.get_qobj. A static method. I was wondering if it will cause confusion.

[Mayank447]

Another thing I find slightly inconsistent is parameteric gates and std gates. For a parameteric gate, one calls parametricgate(argvalue).get_qobj(), for other gates like std, it is simply stdgate.get_qobj. A static method. I was wondering if it will cause confusion.

Ok there is a deeper reason for it. A Parametric Gate needs to be initialised with the parameter RX(0.5) only then can any gate method on it be called e.g. get_qobj, decomposition method etc. Actually the same holds true for the ControlledGate with control_value. But a gate like X doesn't need any argument or initialisation for that fact. So X() is unnecessary, it just creates more object instances even though all of them are same, and each still occupies a different memory segment. So X gate should not be instantiable, and in the next PR by default in __init__ we raise an error if someone tries to do so. __init__ is overwritten in case of ControlledGate, ParametricGate as they require arguments to mean a gate.

Also static method does mean a property so it is stdgate.get_qobj() not stdgate.get_qobj.

[Mayank447]

I was wondering about the name std can we find something more user-friendly? Or simply encourage people to import from the gateclass module.

from qutip.operations import gateclass
gateclass.X

Yes, we can always rename std to something better (coming for a C/C++ background I agree even more). Unfortunately gateclass is a file so it won't work. How about we rename the following gates.py -> old_gates.py and std/ -> gates/, gateclass.py remains the way it is.

from qutip.operations import gates

qc = QubitCircuit(2)
qc.add_gate(gates.X, 0)

Though I still think it would be convenient to keep the string input.

I should have explained why I am in the favour of deprecating string input in the PR description. First this create inconsistency, "X" is fine but something like "RX" requires an arg_value which is really a property of the gate but is being handled in add_gate method, same holds true for control_value. Since we now allow custom gates via inheritance, user has the freedom to have his own arguments for the gate. So instead of us trying to handle these nuances in the add_gate method for string input, we make the user handle it himself. Also in my opinion, qc.add_gate(RX(0.5), 0) is cleaner than qc.add_gate("RX", 0, arg_value=0.5) (the user will have to use arg_value here because in the argument ordering controls comes before it).

Second thing, I agree string inputs are convenient. But now the user can do something like

import qutip_qip.operations.std as std

qc = QubitCircuit(2)
qc.add_gate(std.X, 0)
qc.add_gate(std.RX(0.5), 1)

so his string inputs only change from "gate" to std.gate.

Third thing, in the second PR I introduce the concept of namespaces. So each gate must belong to a namespace (default is std, not to be confused with the dir operations/std/). There are several reasons for it, first at several places we use gate.name for comparison. A user can define his own RX gate (since different conventions are still prevalent) and it will mess up our current decomposition routines entirely. A namespace will prevent any sort of name collision, he can still define his own RX but in a different namespace and we will compare RX wrt. the std namespace. Second the concept of namespaces is much broader and powerful, e.g. I can have std namespace for all these standard gates and another namespace for say noisy gates, or one for math components (Adders, Multipliers, etc.).

[BoxiLi]

Yes, we can always rename std to something better (coming for a C/C++ background I agree even more). Unfortunately gateclass is a file so it won't work. How about we rename the following gates.py -> old_gates.py and std/ -> gates/, gateclass.py remains the way it is.

This might work, but let's make it in a separate PR at the end.

I should have explained why I am in the favour of deprecating string input in the PR description....

Ok, I am convinced. gates.X should be sufficiently simple. I agree. Just one thing. We need to keep the backward compatibility for this in this PR. I think there are quite a few people using this interface. We should raise a deprecation warning for this first.

[Mayank447]

Ok, I am convinced. gates.X should be sufficiently simple. I agree. Just one thing. We need to keep the backward compatibility for this in this PR. I think there are quite a few people using this interface. We should raise a deprecation warning for this first.

Backward compatibility and the deprecation warning are already there in this PR.

[BoxiLi]

Ok great, I missed this. If circuit.add_gate("X", ... ) still works for this version and raises a warning, we are good to go.

[Mayank447]

@BoxiLi you can go ahead with the merge