Tried running the Data-reuploading classifer example, but changed the backend to cirq by doing the following:
dev = qml.device(“cirq.simulator”, wires=1)
Hi @thegajan! I believe the Cirq plugin uses dev.state instead of dev._state. So replacing all occurances of dev._state with dev.state should fix the issue
This is something that we have on our roadmap to standardize, so by the next PennyLane release, all plugins should use the same attributes for states.
Hi @thegajan, I was mainly responsible for creating the Cirq plugin, but the behaviour you point out is rather confusing because we basically just access Cirq’s internal simulator, so there should no be qualitative difference between cirq.simulator and default.qubit.
I’ll investigate this and look for some bug that’s hidden somewhere in the pre- and postprocessing and come back to you.
So, @thegajan, I found the reason for the bad performance. It is actually no bug in the PennyLane-Cirq plugin, but in the Data-reuploading classifier example.
The example should not use the internal state of the simulator to make predictions, because this is not hardware-friendly. In this special case using the internal state causes an error because the Cirq plugin applies gates under the hood to diagonalize the Hermitian observables with eigenvalues in ascending order. This means that the final state of the simulation is different for the Cirq simulator and the default qubit simulator which causes erroneous predictions and therefore poor performance.
We will work on fixing the Data-reuploading classifier as soon as possible!