-
-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extend QCircuit to QInterface #988
Comments
taking a look at this one |
I'm here to help if I can, @stevescia! |
great thx! do you prefer questions and comments here on github, or the discord qrack channel? i've looked at a few |
Either is fine! If it's easier, come to the Qrack channel! Otherwise, I'm here watching the repository issues, too. |
QCircuit
is our new class specifying and optimizing quantum circuits before running them. It specifies all gates in terms of "uniformly controlled" gates with a single target qubit, at base. A uniformly controlled gate, acting on one qubit target, specifies a different 2x2 complex operator applied for every permutation of control qubits. For example, we can combine the effect ofCNOT(0, 1)
andAntiCZ(0, 1)
into a single uniformly controlled gate on one target qubit: if the control qubit is in a "set" (|1>) state, then we apply a Pauli X "payload"; if the control qubit is in a "reset" (|0>) state, then we apply a Pauli Z "payload"; superposition of the control qubit leads to superposition of the "payloads" on the target qubit, entangled with the control state. (If the uniformly controlled gate is "sparse," with many fewer non-identity payloads than control combinations, thenQCircuit
will tend to expand the gate into controlled and "anti-controlled" gates, activated for only a single permutation of control qubits.)This is a universal interface: all possible quantum states can be reached through some combination of these available gates. However, it's currently not easy for the user to take advantage of arithmetic logic unit ("ALU") gate decompositions already defined in
QInterface
. Viewing the situation from one angle, this is becauseQCircuit
does not inherit fromQInterface
. If it did inherit theQInterface
API, it might be necessary forQCircuit
to overload the pure virtual gate methods at base ofQInterface
decompositions. Alternatively,QCircuit
might be better off re-implementing certain decompositions fromQInterface
without inheriting from it.The point of this task is to extend
QCircuit
to cover more of the API ofQInterface
, (at least ALU methods). It's probably better, for now, ifQCircuit
does not implement measurement operations, as this would require a mechanism for reporting measurement results from mid-circuit by the end of the circuit execution, for which we have no scaffolding, for now. (It's possible to achieve mid-circuit measurement anyway, by breaking aQCircuit
into two smallerQCircuit
instances on either side of a mid-circuit measurement round.)Please, implement at least the ALU methods decomposed in
QInterface
, inQCircuit
. (Not all ALU methods inQAlu
have a decomposition inQInterface
; these need not be implemented inQCircuit
for now.)The text was updated successfully, but these errors were encountered: