[BUG] Usingqml.sample(counts=True) twice (with and without observable) yields incorrect output

[meenu-kri]

Expected behavior

The output of qml.sample(counts=True) in return qml.sample(qml.PauliY(0), counts=True), qml.sample(counts=True) should correspond to raw computational basis state samples.

Actual behavior

The output samples correspond to qml.PauliY(0).

Additional information

No response

Source code

import pennylane as qml

dev = qml.device('default.qubit',shots=100,wires=3)

@qml.qnode(dev)
def my_circ():
        return qml.sample(qml.PauliY(0), counts=True), qml.sample(counts=True)

@qml.qnode(dev)
def my_circ2():
        return qml.sample(counts=True)
                                                     
print("Result of my_circ() is:", my_circ())
print("Result of my_circ2() is:", my_circ2())

>>> Result of my_circ() is: [{-1: 54, 1: 46} {'000': 46, '100': 54}]
>>> Result of my_circ2() is: {'000': 100}

Tracebacks

No response

System information

Name: PennyLane
Version: 0.25.0.dev0
Summary: PennyLane is a Python quantum machine learning library by Xanadu Inc.
Home-page: https://github.com/XanaduAI/pennylane
Author: 
Author-email: 
License: Apache License 2.0
Location: /Users/mkumari/qml/pennylane
Requires: appdirs, autograd, autoray, cachetools, networkx, numpy, pennylane-lightning, retworkx, scipy, semantic-version, toml
Required-by: PennyLane-Lightning
Platform info:           macOS-10.16-x86_64-i386-64bit
Python version:          3.8.3
Numpy version:           1.23.1
Scipy version:           1.8.1
Installed devices:
- lightning.qubit (PennyLane-Lightning-0.24.0)
- default.gaussian (PennyLane-0.25.0.dev0)
- default.mixed (PennyLane-0.25.0.dev0)
- default.qubit (PennyLane-0.25.0.dev0)
- default.qubit.autograd (PennyLane-0.25.0.dev0)
- default.qubit.jax (PennyLane-0.25.0.dev0)
- default.qubit.tf (PennyLane-0.25.0.dev0)
- default.qubit.torch (PennyLane-0.25.0.dev0)

Existing GitHub issues

• I have searched existing GitHub issues to make sure the issue does not already exist.

[CatalinaAlbornoz]

Hi @meenu-kri, thank you for reporting this bug!

[dwierichs]

Note that this bug also occurs when using qml.sample(counts=True) together with expectation values:

@qml.qnode(dev)
def circuit(x, y):
    return  qml.sample(counts=True), qml.expval(qml.PauliY(0))
circuit() # ({'00': 53, '10': 47}, 0.06) , which is wrong

[Jaybsoni]

Hi @meenu-kri,

Here is an update regarding this bug. I have been looking into it, and it seems that there are two main causes for this behaviour:

• Firstly, during execution we apply the diagonalizing gates and immediately generate samples (see figure 1). The issue here is that in cases like this, where we have measurements happening in two different basis, the samples are not re-generated.

Figure 1: _qubit_device.py

• Secondly, we support a special syntax for sample() in which we interpret the lack of sampling operator to mean that we want the "raw" computational basis state samples. Since there is no operator provided, we cannot check if this measurement basis is qwc with other measurements in the circuit and so it slips through the validation checks (see figure 2).

Figure2: _qubit_device.py

Now the question is, how should we handle this case? We have two options:

• We can raise an error that these are measurements in non-qubitwise commuting basis, so we cannot perform them.
• We can split the tape up (something like how we measure hamiltonians or this contribution) and combine the results in post processing

I still have to discuss this with the team before we decide which option (or alternative) we decide to go with!
Cheers,