Open dwierichs opened 1 year ago
Devices that do not support qml.Hamiltonian
natively will have such objects expanded:
https://github.com/PennyLaneAI/pennylane/blob/master/pennylane/_device.py#L738
This essentially means that in such cases it's not qml.Hamiltonian.diagonalizing_gates
but, the diagonalizing_gates
attribute of the terms themselves will be called.
Overall, it seems that this behaviour is indeed off, but with the potential superseding of the qml.Hamiltonian
class by operator arithmetic, it's questionable if we'd like to take any immediate steps here. For example, if we raised a warning/error, it would have to be suppressed anyways during device execution (or could there be another way to that? :thinking:).
Thanks @antalszava!
I agree, this is a bug with very low visibility. Conceptually, I'd prefer if there is an error raised and a device that supports Hamiltonian
measurements suppresses it, to be on the safe side.
However, this should be traded off against
Hamiltonian
measurement directly, i.e. not via decomposition.Hamiltonian
maybe being replaced via arithmetic.I think this can be left as-is due to the above reasons of low visibility. Leaving open to provide a reference for this behaviour.
if anyone else finds their way here, this PR is related: #3938
Expected behavior
The property
QuantumTape.diagonalizing_gates
always either returns the correct diagonalizing gates or raises an error (warning) if they are unknown.Actual behavior
When measuring, say, the expectation value or variance of a
Hamiltonian
, the tape always reportsdiagonalizing_gates=[]
, which is not correct whenever theHamiltonian
is not diagonal.Additional information
This is due to the code in
QuantumTape.diagonalizing_gates
itself, where the observable's diagonalizing_gates are queried, and if an error is raised (due to unknown diagonalizing gates), it is simply suppressed.I suggest that we either raise a warning, or better a
DiagGatesUndefinedError
. The method clearly does not return what it promises in the described case. The reason why these wrong diagonalizing gates do not cause problems in circuit evaluations is becauseDefaultQubit
has a separate logic forHamiltonian
andSparseHamiltonian
, which actually relies on the fact that we skip the rotation to the eigenbasis inQubitDevice.execute
. This is an dependency betweenQuantumTape.diagonalizing_gates
,QubitDevice.execute
andDefaultQubit.expval
, which is likely to cause (or have caused) trouble at some point for developers that build their device onQubitDevice
instead ofDefaultQubit
(as they are supposed to).More generally: I think there might have been a misunderstanding regarding the meaning of
diagonalizing_gates
raising the errorDiagGatesUndefinedError
. As far as I can tell it means "We do not know the diagonalizing gates", which most likely is because they are expensive to compute. The code inQuantumTape.diagonalizing_gates
treats this error as "We know the diagonalizing gates to be the empty set". We could/should make sure that there is a uniform understanding of theDiagGatesUndefinedError
, and that the misunderstanding/difference in interpretation didn't make it into the code base in any other way.Source code
Tracebacks
No response
System information
Existing GitHub issues