Open 11D-Beyonder opened 4 weeks ago
I am not sure this can be classified as bug, since the input you give in the second case corresponds to the broadcasting conventions (instead of a 1-dimensional list of qubits, you pass a list containing another list). It's relatively simple to use the UCRYGate
in this case in a pythonic way:
circuit.append(UCRYGate(np.ones(4).tolist()), [qubit for reg in circuit.qregs for qubit in reg])
We can add such "flattening" at the beginning of broadcast_arguments
and check whether the obtained number of qubits corresponds to the total number of arguments of the gate; however, I need to think if it plays well and avoids ambiguity with multiple nesting levels, and I'm not sure it's worth the convention breaking.
I am not sure this can be classified as bug, since the input you give in the second case corresponds to the broadcasting conventions (instead of a 1-dimensional list of qubits, you pass a list containing another list). It's relatively simple to use the
UCRYGate
in this case in a pythonic way:circuit.append(UCRYGate(np.ones(4).tolist()), [qubit for reg in circuit.qregs for qubit in reg]) We can add such "flattening" at the beginning of
broadcast_arguments
and check whether the obtained number of qubits corresponds to the total number of arguments of the gate; however, I need to think if it plays well and avoids ambiguity with multiple nesting levels, and I'm not sure it's worth the convention breaking.
In my opinion, circuit.append(UCRYGate(np.ones(4).tolist()), [qubit for reg in circuit.qregs for qubit in reg])
is not elegant enough. The broadcasting conventions makes extending a gate like UCRYGate
a little counter-intuitive.
@gadial I agree flattening and checking whether (1) the number of arguments fits or (2) we have to try broadcasting would make sense. By reading the docs it should be possible to append the UCRYGate
in the above setting 🤔 Regarding nesting: we only support one level of nesting (i.e. Sequence[QuantumRegister]
), right?
Environment
What is happening?
Can't append a multi-control gate using
append
because broadcast.How can we reproduce the issue?
Suppose we construct an empty circuit and then use the
append
function to add aCRY
gate. The code is as follows:The quantum register named "control" serves as the control qubits, while the register named "target" serves as the target qubit. Since two control qubits are used here, but a CRY gate only requires one control qubit, Qiskit employs a broadcasting mechanism, interpreting the two bits in "control" as individual control qubits for separate CRY gates. Therefore, the resulting circuit appears as follows, with both serving as control qubits, resulting in two
CRY
gates.However, if we want to add a multi-control gate, such as
UCRYGate
.I get the following error.
What should happen?
The expected result should be two qubits in register "control" as the control qubits and "target" as the target qubit, constructing a 2-control qubit
UCRY
gate.Any suggestions?
The error comes from the
broadcast_arguments
function of classGate
.operation.broadcast_arguments
begins with a check:If we insert
CRYGate
, thenlen(qargs)
andself.num_qubits
are both 2 and will not report an error. If we insertUCRYGate
, thenlen(qargs)
is still 2, andself_num_qubits
is the number of control qubits dependent onUCRYGate
, which in the example is 3, so an error will be reported.Due to the existence of the broadcast mechanism, the multi-control gates such as UCRYGate cannot be merged simply by
append
whenqargs
is a list ofQuantumRegister
. Although we can setqargs
using the specific qubit index, this loses the point of using a quantum register to manage a set of qubits. I don't know if this is a Bug or Qiskit for some reason not to let us append multi-control gate throughQuantumRegister
?