Wrong simplification of Hamiltonians

[adamglos92]

Issue description

Multiplication of Pauli operators gives counter-intuitive reults. While PauliX(0) @ PauliZ(0) should produce a bug, PauliZ(0) @ PauliZ(0) should be simplified to identity.

import pennylane as qml

obs = []
obs.append(qml.PauliZ(0))
obs.append(qml.PauliZ(0) @ qml.PauliZ(0))

coeffs = [1, 1]
h = qml.Hamiltonian(coeffs, obs)
print(h)
print("Simplified:")
h.simplify()
print(h)

• Expected behavior: (What you expect to happen)

(1) [Z0]
+ (1) [Z0 Z0]
Simplified:
(1) [Z0]
+ (1) # or however an identity should look like

• Actual behavior: (What actually happens)

(1) [Z0]
+ (1) [Z0 Z0]
Simplified:
(2) [Z0]

• System information: (post the output of import pennylane as qml; qml.about())

Name: PennyLane
Version: 0.14.1
Summary: PennyLane is a Python quantum machine learning library by Xanadu Inc.
Home-page: https://github.com/XanaduAI/pennylane
Author: None
Author-email: None
License: Apache License 2.0
Location: /home/adam/anaconda3/envs/qhack/lib/python3.9/site-packages
Requires: networkx, appdirs, semantic-version, numpy, toml, scipy, autograd
Required-by: 
Platform info:           Linux-5.4.0-65-generic-x86_64-with-glibc2.31
Python version:          3.9.1
Numpy version:           1.19.2
Scipy version:           1.6.1
Installed devices:
- default.gaussian (PennyLane-0.14.1)
- default.mixed (PennyLane-0.14.1)
- default.qubit (PennyLane-0.14.1)
- default.qubit.autograd (PennyLane-0.14.1)
- default.qubit.jax (PennyLane-0.14.1)
- default.qubit.tf (PennyLane-0.14.1)
- default.tensor (PennyLane-0.14.1)
- default.tensor.tf (PennyLane-0.14.1)

Additional information

This is particularly important for designing binary models.

[antalszava]

Hi @adamglos92, thanks so much for the report!

Yes, this is a known behaviour for the Tensor class, see the issue on "Tensor product in Pennylane" #715. We'll revisit the linked issue again.

Until then, feel free to open another thread on our discussion forum if further help is needed with bypassing this behaviour for your use case.

[adamglos92]

Thank you and sorry for copying question! Would you accept a PR on this?

[antalszava]

Yes! One thing to note is that the situation might be a bit more complex than it seems at first.

Allowing @ to work as matmul for observables on the same wire will require:

1. Allowing the representation of non-Hermitian operators. This is required for cases like XY = iZ, where the result of the multiplication is non-Hermitian. This will require a change to the Operator class by implementing a more general matrix representation.
2. Disallowing computing statistics for non-Hermitian operators that are not of the form c * Herm (where c is a complex coefficient and Herm is Hermitian).
3. Finally, a change to the logic of the __matmul__ method of the Observable and Tensor classes.

Let us know if having a go at any of these changes would be interesting! 🙂

(As this is more of a new feature, rather than a bug with the current logic, removing the label.)

[adamglos92]

• @antalszava it is certainly a bug. Z(0) @ Z(0) can give only one output, otherwise, you cannot call @ a multiplication anymore. imagine you create an Ising model and you want to make a square of Hamiltonian.
• I noticed you allow PauliX @ Hadamard. This makes everything even more difficult, as we will have to check whether the product of operators is Hermitian in the meantime.
• Ad 2. See issues from my previous point. Although this could be done by simply including type assertion (is it Observable?)
• Actually I'm confused. what is the difference between Hamiltonian and Observable? Why did you separate this?
• I wonder whether we should distinguish @ for a tensor product from * for a multiplication product. Z(0) @ Z(0) would not be allowed then. This is a serious change though.

Should I move this to a discussion forum? :)

[antalszava]

Hi @adamglos92!

Z(0) @ Z(0) can give only one output, otherwise, you cannot call @ a multiplication anymore.

Note that @ stands for the tensor product in PennyLane and so specifying qml.PauliZ(0) @ qml.PauliZ(0) will lead to undefined behaviour as these two operators act on the same qubit. What would make that expression defined in PennyLane, is if @ also stood for matrix multiplication. This, however, is not a feature in PennyLane for Observable/Tensor objects. The bottom line is, that there are two alternatives:

1. add @ as matrix multiplication for observables acting on the same wires,
2. add explicit messages to notify users about this behaviour.

Out of these two, we prefer to go with 1.

I noticed you allow PauliX @ Hadamard. This makes everything even more difficult, as we will have to check whether the product of operators is Hermitian in the meantime.

Indeed this will make the required logic more complex. The multiplication of Observable objects will not necessarily be an Observable (hermitian) and hence as described above, we'll need the Operator class to be extended.

Ad 2. See issues from my previous point. Although this could be done by simply including type assertion (is it Observable?)

After a bit of discussion, we'd like to allow this feature to work even for some non-Hermitian operators, see the def. in 2 of the previous comment.

Actually I'm confused. what is the difference between Hamiltonian and Observable? Why did you separate this?

This has more so historic reasons: the Hamiltonian class was originally added having VQE in mind where computing the expectation value of a Hamiltonian on hardware is performed by computing multiple expectation values of Pauli strings and weighing in those results with pre-defined coefficients. For that reason the Hamiltonian class stores coefficients and operators (coeff and ops attributes) and is widely used with the ExpvalCost class (QNoceCollection).

Observable, on the other hand, is the main class for any observable including often used observables like the Paulis. At the moment, Observable objects are used within a single QNode. Further iterating on how the Hamiltonian class works (e.g., allowing a Hamiltonian to be used in a QNode) is on our roadmap.

I wonder whether we should distinguish @ for a tensor product from * for a multiplication product. Z(0) @ Z(0) would not be allowed then. This is a serious change though.

For matrix multiplication that would be somewhat confusing, as originally @ stands for matmul.

Should I move this to a discussion forum? :)

That's okay! We can discuss such questions here, and if there are any uncertainties regarding how PennyLane works, a new thread on the forum could be a great place.

[adamglos92]

@antalszava perhaps you could be interested in solving this issue through a QIntern 2021 event? https://qworld.net/qintern-2021/. I'm pretty sure there will be people interested in contributing to Pennylane :)

[antalszava]

@adamglos92 that's a nice idea, thank you for the heads-up! We'll consider it :)

[albi3ro]

With the completion of the operator arithmetic transition, we can now mark this issue as closed.