Strange behaviour of All about projectq HOT 5 CLOSED

Do you find its behavior to be inconsistent with the docs (http://projectq.readthedocs.io/en/latest/projectq.ops.html#projectq.ops.Tensor)? All should only be used to apply a single-qubit gate to multiple qubits, i.e., to a list of qubits (which is a quantum register).
In general, the syntax for every gate is gate | (qureg1, qureg2, ...) and All supports a single quantum register consisting of the qubits the gate should be applied to. Therefore both All(gate) | qureg and All(gate) | (qureg,) should work.

from projectq.

So gate | (qureg1, qureg2) works here (which was something I found pretty intuitive), and similarly I can do e.g. CNOT | (qureg[1], qureg[2]) (accessing qubits in qureg, also intuitive). However, if I try the same thing with All, All(X) | (qureg[1], qureg[2]), I get an AssertionError with no message (IMO both no message and the user-facing assert should be changed).

Basically I was surprised that list input should be required for All, i.e. All(X) | [qureg[1], qureg[2]] should work but that tuple input wouldn't be allowed. (List input to CNOT actually raises a projectq.ops._metagates.ControlQubitError.) I expected that tuple input would be OK throughout, but was also surprised that list input wasn't accepted as well.

from projectq.

As Thomas already mentioned, All works consistent with the description in the docs.

While the most general syntax of a gate is gate | (qureg1, qureg2, ... ), every gate defines how many qureg argument it expects (to define a nice syntax) in the docstring and users should follow it if they want correct results, there is no guarantee about what happens if you don't follow the pre-condition in the docs (you might get the wrong results, an exception, or something else...)

For convenience, if you give a single qubit instead of a qureg, it will be converted to a qureg of length one. And if if the gate expects a single qureg, it is not required to be put it into a tuple.

All requires one qureg and applies a single qubit gate to all the qubits. This syntax was chosen because most often you want to apply, e.g., H to all qubits in a qureg. Should you want to apply H to all qubits of two quregs:

All(H) | qureg1 + qureg2

CNOT is a shortcut for C(X). All controlled gates require that the control qubits are specified in the first (one or more) separate quregs (https://github.com/ProjectQ-Framework/ProjectQ/blob/develop/projectq/ops/_metagates.py#L128) , hence CNOT requires CNOT | (control_qubit, target_qubit) and not CNOT | [control_qubit, target_qubit].

from projectq.

"Consistency with the docs" isn't a defense for counter-intuitive behaviours that require me to dig through code to figure something out. You should have an error message like "ValueError: All takes a single register as input. Use [qureg1, qureg2] for registers or [qureg[0], qureg[2]] for qubits." (I stumbled across this in the second case - trying to do All on part of a register.)

The docs say that All(H) | x and All(H) | (x,) work, but don't mention that you have to convert multiple registers to a single one for All, or that you can do this using a list. I understand now that this is a backend requirement on All (strictly taking a single register), but I don't think I could have been reasonably expected to realize this / how to fix it, especially when all the other commands I've seen work with a tuple. If this raised an error message I could have been pointed in the right direction, but giving an empty AssertionError forced me to look through to figure out the appropriate syntax. So I understand why it's probably very difficult to change in the way I'd consider ideal, but you could instead solve the problem by laying things out more clearly user-side. Let me know if you want me to make a pull request for some error messages there or something :)

from projectq.

Thanks for this input. It is very valuable to us to know what might seem counter intuitive at first.
By the way, being consistent with docs means that you should not need to dig through code.

Use [qureg1, qureg2] for registers or [qureg[0], qureg[2]] for qubits.

You should use qureg1 + qureg2. A quantum register is just a list of qubits. + gives you another list, whereas [qureg1, qureg2] gives a list of lists which would be wrong. If you want apply the single qubit gate only to one part of a register, you can use slicing as this returns again a list:

All(H) | qureg[4:10]

I take from your comment that you would appreciate some more sanity checks, we certainly cannot check all possible input errors but we can introduce a debug mode (which we are already working on) which would check much more stuff and could give you more information. We will incorporate it directly there, so no need for a pull request but thanks for offering it :)

from projectq.