Unexpected behaviour when using BasisStatePreparation after other gates

[mariaschuld]

Consider the following example:

@qml.qnode(dev)
def circuit():
    qml.PauliX(wires=(0))
    qml.templates.state_preparations.basis.BasisStatePreparation([1,0,0], wires=(0,1,2))
    return qml.state()

• Expected behavior: (What you expect to happen)

The user would expect that after a state preparation routine, the state is in |1,0, 0>. Note that this is in some sense unphysical (since it disposes of the state before state preparation), and a better behaviour would be to throw an error.

• Actual behavior: (What actually happens)

At the end of the circuit, the state is in |000>, since the BasicStatePreparation operation just applies PauliX gates - which turns the first qubit back to 0.

• Proposed short-term fix:

Register BasicStatePreparation with the list of operations that have to be applied first in a circuit.

Note that this is a breaking change!

• Long-term discussion:

We should revisit our system of considering operations as "first-only". For example, why are other state preparation templates not forced to be first in a circuit? Shall we impose this restriction at all?

[albi3ro]

On further thought, what if a user wanted to apply one state preparation on a portion of the the wires, and a different state preparation on a different section of the wires? They wouldn't overlap and would both be state preparations, just one would occur after the other. A state preparation only needs to be the first operator on those wires , not on the device as a whole.

[mariaschuld]

Yes, true. This discussion is actually a larger issue we had before - to make the "first operation" check consider the wires. But that would not only touch this template.

[co9olguy]

One thing to think about here (that we visited before in SF) is that it is relatively straightforward to do the bookkeeping to determine whether some wires have already been "used" before (and hence valid targets for state preparations), but doing so may introduce some extra overhead (whose magnitude depends on the implementation details).

Generally I'm in favour of allowing state preps to be more flexible (providing the bookkeeping is not introducing overead), not just purely as a user convenience, but also because we now have qubit resets on HW and plan future support in PL for measurement feedforward