add pow method to operators

[albi3ro]

This PR adds the Operator.pow method. This method will provide easier ways to decompose an operator raised to a power. It will be purely developer-facing. Users will raise operators to powers through either a qml.pow constructor or op ** n.

Later PR's will:

• Add a Pow wrapper arithmetic class
• Add a qml.pow contructor transform
• Add a __pow__ method.

When the power does not exist for the provided exponent, it raises a qml.operation.PowUndefinedError.

[github-actions]

Hello. You may have forgotten to update the changelog!
Please edit doc/releases/changelog-dev.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 #2225 (0381cae) into master (8a4dd00) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff            @@
##           master    #2225    +/-   ##
========================================
  Coverage   99.57%   99.58%            
========================================
  Files         243      243            
  Lines       19480    19595   +115     
========================================
+ Hits        19397    19513   +116     
+ Misses         83       82     -1     

Impacted Files	Coverage Δ
pennylane/gradients/parameter_shift_cv.py	99.59% <ø> (+0.40%)	⬆️
pennylane/interfaces/execution.py	100.00% <ø> (ø)
pennylane/qnode.py	100.00% <ø> (ø)
pennylane/operation.py	96.73% <100.00%> (+0.03%)	⬆️
pennylane/ops/identity.py	100.00% <100.00%> (ø)
pennylane/ops/qubit/matrix_ops.py	100.00% <100.00%> (ø)
pennylane/ops/qubit/non_parametric_ops.py	100.00% <100.00%> (ø)
pennylane/ops/qubit/observables.py	100.00% <100.00%> (ø)
pennylane/ops/qubit/parametric_ops.py	100.00% <100.00%> (ø)
pennylane/ops/qubit/qchem_ops.py	100.00% <100.00%> (ø)
... and 1 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 1a13bef...0381cae. Read the comment docs.

[josh146]

wow @albi3ro this is one powerhouse of a PR - I didn't realize you had added __pow__ to every operator class! Even if this doesn't get merged in its current state (we still need to coordinate with @mariaschuld), this will be a good source of exponentiation relations between different operations.

[mariaschuld]

Great stuff Christina!

Except from some docstring clarifications, my only important comment is the return type!

Oh, and there are still many codecov issues, but I assume you're on it.

Note: I am not very clued up about power rules, so I haven't checked that they are true.

[albi3ro]

@mariaschuld Thanks for all the good comments. I'll get to responding to the rest in a moment, but I first wanted to address why I decided to return a list of operations instead of a single operation.

First, this will be used in Pow.compute_decomposition. Decompositions return lists, so even if pow returns a single operation, it will get promptly wrapped into a list in its one use case.

Second, how do we handle the identity use case? I was initially having the method return an Identity, but that identity is basically just a placeholder that we will have to deal with down the road somewhere. Plenty of operations, like Identity, Barrier, WireCut, etc. decompose to an empty list, so there's nothing wrong with having a power operator decompose to an empty list.

What happens if the base gate is across multiple wires, like CNOT? Do we return an Identity on every wire, or just the first one? If it's on every wire, we need to return a list of operations anyway. If it's just the first one, what's so special about that wire? It's no longer indicating all the places something used to be, so it's not really serving it's purpose as longer-term memory.

And lastly, what if we want to support more intricate rules later? For example, we could decide to decompose SX **-1 as both PauliX and SX together. In that situation, we would need to return a list instead of just a single operation.

[josh146]

For example, we could decide to decompose SX **-1 as both PauliX and SX together. In that situation, we would need to return a list instead of just a single operation.

In this case, could we just return PauliX @ SX? E.g., we would return an instance of Prod?

[albi3ro]

@josh146 So maybe my last point about longer decomposition might not hold as well in the future when we have a Prod class, but I still think the other arguments hold water.

[mariaschuld]

Once the pylint issues are resolved this is good to go from my side, as we decided to go with list return types for now!