print of vqe.hamiltonian sorts terms by number of wires and coefficients

[albi3ro]

This is a minor aesthetic change to improve readability on printing objects of type pennylane.vqe.vqe.Hamiltonian.

Currently, the H2 hamiltonian from the VQE tutorial prints as:

(-0.04207897647782188) [I0]
+ (0.17771287465139934) [Z0]
+ (0.1777128746513993) [Z1]
+ (-0.24274280513140484) [Z2]
+ (-0.24274280513140484) [Z3]
+ (0.17059738328801055) [Z0 Z1]
+ (0.04475014401535161) [Y0 X1 X2 Y3]
+ (-0.04475014401535161) [Y0 Y1 X2 X3]
+ (-0.04475014401535161) [X0 X1 Y2 Y3]
+ (0.04475014401535161) [X0 Y1 Y2 X3]
+ (0.12293305056183801) [Z0 Z2]
+ (0.1676831945771896) [Z0 Z3]
+ (0.1676831945771896) [Z1 Z2]
+ (0.12293305056183801) [Z1 Z3]
+ (0.176276408043196) [Z2 Z3]

With this change, the terms will be sorted in the number of wires, and a tab \t attempts to line up the operation terms.

  (-0.24274280513140484)	[Z2]
+ (-0.24274280513140484)	[Z3]
+ (-0.04207897647782188)	[I0]
+ (0.1777128746513993)	[Z1]
+ (0.17771287465139934)	[Z0]
+ (0.12293305056183801)	[Z0 Z2]
+ (0.12293305056183801)	[Z1 Z3]
+ (0.1676831945771896)	[Z0 Z3]
+ (0.1676831945771896)	[Z1 Z2]
+ (0.17059738328801055)	[Z0 Z1]
+ (0.176276408043196)	[Z2 Z3]
+ (-0.04475014401535161)	[Y0 Y1 X2 X3]
+ (-0.04475014401535161)	[X0 X1 Y2 Y3]
+ (0.04475014401535161)	[Y0 X1 X2 Y3]
+ (0.04475014401535161)	[X0 Y1 Y2 X3]

This improves the user's ability to compare like terms. For example, now I can much more easily see that [Z0 Z2] and [Z1 Z3] have the same coefficient.

This new function doesn't distinguish trivial wires acted upon by the identity. For example, after sorting by the coefficient, the identity term gets mixed into the single wire terms. Fixing that would add more complexity to a fairly simple function, so I don't know if it's worth figuring that out.

[github-actions]

Hello. You may have forgotten to update the changelog!
Please edit .github/CHANGELOG.md with:

• A one-to-two sentence description of the change. You may include a small working example for new features.
• A link back to this PR.
• Your name (or GitHub username) in the contributors section.

[codecov]

Codecov Report

Merging #981 (182d1f4) into master (ab13725) will decrease coverage by 0.98%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master     #981      +/-   ##
==========================================
- Coverage   99.09%   98.11%   -0.99%     
==========================================
  Files         142      145       +3     
  Lines       10439    10943     +504     
==========================================
+ Hits        10345    10737     +392     
- Misses         94      206     +112     

Impacted Files	Coverage Δ
pennylane/vqe/vqe.py	92.81% <0.00%> (-7.19%)	⬇️
pennylane/tape/operation_recorder.py	64.51% <0.00%> (-35.49%)	⬇️
pennylane/measure.py	91.76% <0.00%> (-8.24%)	⬇️
pennylane/circuit_drawer/grid.py	88.70% <0.00%> (-7.72%)	⬇️
pennylane/grouping/optimize_measurements.py	92.30% <0.00%> (-7.70%)	⬇️
pennylane/configuration.py	93.10% <0.00%> (-6.90%)	⬇️
pennylane/about.py	95.45% <0.00%> (-4.55%)	⬇️
pennylane/operation.py	95.82% <0.00%> (-3.95%)	⬇️
pennylane/math/tensorbox.py	96.02% <0.00%> (-3.28%)	⬇️
pennylane/qnn/torch.py	96.72% <0.00%> (-3.28%)	⬇️
... and 24 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ab13725...182d1f4. Read the comment docs.

[josh146]

A nice improvement, thanks @albi3ro!

I might comment on each independently.

1. Sorting by the number of wires in each term is a great idea. This is something that has bothered me for a while, and I'm glad this is fixed.

2. I'm much more hesitant on including tabs. I find tabs are not consistent between editors, or even operating systems, and what looks nice on one users system might look worse on another- case in point, the PR comment example. I suggest reverting the tab change to be a single space, or, if possible, seeing if Python string formatting provides options for alignment.

Finally, it looks like the logic changes might need some new tests.

[albi3ro]

Will wait on Issue #982 to write up the tests.

[albi3ro]

Just updated this to just get it out of the way and clear the backlog.

[josh146]

Hi @albi3ro, just double checking the status of this PR - is it ready for re-review, is it still WIP, or has it been superseded?

[albi3ro]

@josh146 I can't even find what change you requested anymore, but this should finally be good to merge in.

[josh146]

Thanks @albi3ro! Looks good to merge now - I think my only requested change was removing the tab 😆

[josh146]

Could changing the spacing have any side effects? Maybe demos outputs/existing docstrings might not match any more?

[albi3ro]

Demo's won't match up anymore, but also because the terms will be in different orders.

docstrings might be an issue. I've been thinking as well about going through docstrings and making sure code samples still work. I think there may be multiple places code examples need to get updated. I made an Issue the other day about circuit drawing in the permute template.

[josh146]

I saw, that was a good catch!

[trbromley]

I like this change 👍

One place where this may be a surprise is when a Hamiltonian is used with ApproxTimeEvolution, since this operation uses the ordered terms in the Hamiltonian which may not match the printed terms.

For example, consider

>>> import pennylane as qml
>>> h = qml.Hamiltonian([1, -1, -2], [qml.PauliX(0), qml.PauliZ(0), qml.PauliY(0)])
>>> print(h.terms)
([1, -1, -2], [PauliX(wires=[0]), PauliZ(wires=[0]), PauliY(wires=[0])])
>>> print(h)
  (-2) [Y0]
+ (-1) [Z0]
+ (1) [X0]

So ApproxTimeEvolution will use [e^{i phi Y / n} e^{i phi Z / n} e^{i phi X / n}]^n but a user might be expecting it to do [e^{i phi X / n} e^{i phi Z / n} e^{i phi Y / n}]^n based on the printout. In the limit of large n these should be equivalent, but may result in surprising behaviour for intermediate n. One example is mixer_layer in the qaoa module, which approximates simulating a mixer Hamiltonian by using ApproxTimeEvolution with n=1.