Open Jaybsoni opened 2 years ago
its unclear if we should add expensive checks for hermiticity or if there is something more clever we can do.
A collaborator just reported something similar to me. As a consequence, even the more broad qml.is_hermitian
check fails in these cases, because it relies on the op.is_hermitian
property.
>>> qml.matrix( qml.PauliZ(0) @ qml.PauliY(0) )
[[0.+0.j 0.-1.j]
[0.-1.j 0.+0.j]]
>>> qml.is_hermitian( qml.PauliZ(0) @ qml.PauliY(0) )
True
One solution is to update qml.is_hermitian
to always check the matrix representation rather than op.is_hermitian
but that is less efficient. Another option is to add a check on commutativity of two operators when constructing their product, in order to properly set the value of is_hermitian
. This is pretty efficient when everything is a Pauli, but I think you'd have to resort to matrix representations if something is just a general qml.Hermitian
.
Expected behavior
We expect that when a non hermitian observable is passed into the measurement process, a reasonable error message is displayed which informs the user that they cannot perform such a measurement.
Actual behavior
Additional information
The Tensor class does not perform any validation to check if the tensor product of observables is in fact still hermitian. This causes issues when you compose hermitian observables which don't commute with each other. :tear
Source code
No response
Tracebacks
No response
System information
Existing GitHub issues