Fix metric tensor for circuits with inverted gates

[dwierichs]

Context:
The generator and coefficient stored in op.generator are not modified when an operation is inverted. Therefore,
using this information in the metric tensor led to the wrong result for inverted gates. This is now fixed and three tests were modified to include this szenario.
Note that this bug affects both, the new Hadamard test-based metric tensor introduced in #1725 and the block-diagonal original version.

Description of the Change:
The coefficient is inverted with a minus sign if the operation in question has the inverse flag set to True. The documentation clearly states now that this assumes the generator of the operations for which the metric tensor is computed to be Hermitian.

Benefits:
bug fix and better documentation as well as test coverage.

Possible Drawbacks: n/a

Related GitHub Issues: n/a

[codecov]

Codecov Report

Merging #1987 (34bcf38) into master (53b3b2b) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #1987   +/-   ##
=======================================
  Coverage   98.81%   98.81%           
=======================================
  Files         227      227           
  Lines       17291    17293    +2     
=======================================
+ Hits        17086    17088    +2     
  Misses        205      205           

Impacted Files	Coverage Δ
pennylane/transforms/metric_tensor.py	99.49% <100.00%> (+<0.01%)	⬆️

---

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 53b3b2b...34bcf38. Read the comment docs.

[antalszava]

Hi @dwierichs, I'm wondering: should we fix this behaviour instead by negating the scaling factor on the operation level?

I.e., a potential solution would be to make generator attribute a property:

For qml.RX, we'd go from

generator = [PauliX, -1 / 2]

to

@property
def generator(self):
    scaling_factor = -1 / 2 if not self.inverse 1 / 2
    return [PauliX, scaling_factor]

I think this would be the intuitive thing for a user, given the docstring of the generator attribute.

Example

If a user would like to naively apply the formula from the docstring, they could do so by gathering the gate parameter and the generator.

op = qml.RY(0.3, wires=0).inv()

print('Theta: ', op.data, '\nInverse? ', op.inverse, '\nGenerator: ', op.generator)

Theta:  [0.3] 
Inverse?  True 
Generator:  [<class 'pennylane.ops.qubit.non_parametric_ops.PauliY'>, -0.5]

This is where the issue already arises: we store the information about taking the inverse of the operation in the op.inverse attribute.

[antalszava]

Note that this change would:

• Require changing the generator attribute on a case by case basis for several operations;
• Would likely affect the operation derivative capability (see here) (and maybe other places too?);
• Potentially be revisited: having both .inv() and the adjoint method of an operation act separately seems to be causing strange situations (e.g., inv() only flips a flag, whereas adjoint() may negate the gate parameter).

[josh146]

@antalszava the generator attribute is due to be refactored next week as part of the operator overhaul! So a hotfix for this release should be okay

[dwierichs]

I'm all in for deprecating the inverse flag 😅 I found it a bit counter-intuitive in all scenarios in which I came across it so far...
But I think it might be unnecessary to fix this now, given the changes that soon will be made to the Operator class. @mariaschuld what do you think about this? Would it pay off to address this issue now?

[antalszava]

Sounds good 👍 The changes here looked good as a hotfix.