Zip

Is your feature request related to a use case or problem? Please describe.

A very common pattern in building quantum circuits is to have a bunch of two qubit gates that you want to put into a circuit, and you do this by acting on qubits from two lists

for q0, q1 in zip(qubits0, qubits1):
  cirq.CNOT.on(q0, q1)

In a similar way to having on_each we could, for two qubit gates, have zip:

cirq.CNOT.zip(qubits0, qubits1)

I’m unsure if this could also be extended across multiple qubit gates (or even be another way to do on_each).

What is the urgency from your perspective for this issue? Is it blocking important work?

P2 - we should do it in the next couple of quarters

[maffoo]

What if instead we were to extend on_each to all gates and allow it to accept a sequence of tuples of cirq.Qid for gates that apply to multiple qubits? Then you could do

cirq.CNOT.on_each(zip(qubits0, qubits1))

This is not quite as concise, but more general since you can construct the sequence in other ways in addition to using parallel lists.

One problem with this would be that the current implementation of on_each tries to be flexible by “flattening” nested iterables down to a single list of qubits (it seems likely that this was meant to support cirq.X.on_each(q0, q1) and cirq.X.on_each([q0, q1]), but the actual implementation supports any amount of nesting of sequences). It’s possible this could be made to work by leaving the last level “unflattened” for multi-qubit gates. Probably would still not be able to support “variadic” gates like measure and wait since they could take one or more qubits.

[95-martin-orion]

This is complete: Gate.on_each(zip(qubits_0, qubits_1, ...)) provides the requested support and deprecated classes have been removed.