Add pow as supported operation for ParameterExpression

[grossardt]

Summary

Adds powering for qiskit.circuit.ParameterExpression allowing to use a**n, n**a, a**b, pow(a,b) etc. for ParameterExpressions a, b and numbers n.

Details and comments

Minimal change using default support of pow by Sympy/Symengine.
Also added pow to list of operators in TestParameterExpressions test case for unit testing.
Fixes #8959
Changelog: New Feature

[qiskit-bot]

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the the following people are requested to review this:

• @Qiskit/terra-core

[coveralls]

Pull Request Test Coverage Report for Build 6914056656

• 4 of 4 (100.0%) changed or added relevant lines in 1 file are covered.
• 10 unchanged lines in 3 files lost coverage.
• Overall coverage increased (+0.02%) to 85.91%

---

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/expr.rs	1	93.76%
crates/qasm2/src/lex.rs	3	91.92%
crates/qasm2/src/parse.rs	6	97.6%

Totals
Change from base Build 6911016807:	0.02%
Covered Lines:	65947
Relevant Lines:	76763

---

💛 - Coveralls

[grossardt]

It seems that the Windows version (of Symengine I assume) introduces a small numerical error in pow that leads to some of the tests to fail. Not sure how to deal with this? Just loosen the test to only assert almost equal?

[jakelishman]

Hmm, this is a slightly tricksy question. On the one hand, I'm not keen to relax the tolerances of the test, because the expressions are a simple binary op, and the floating-point evaluation should be bit-for-bit identical between the two cases. On the other, complex-number powers are a mathematically tricky operation to perform, so they're not really akin to the simple +, -, * and / operations otherwise tested.

The failing test case is pow(-1, 2.3), which in pure real-number arithmetic should be equal to $e^{3i\pi/10} = \cos(3\pi/10) + i\sin(3\pi/10)$. The closest floats to those values would be (0.5877852522924731+0.8090169943749475j), which notably isn't the returned result from either component, so there's already a few-ULP difference in both pow(-1, 2.3) and the symbolic form. That's quite to be expected, since even one of the basic simplifications I did ($2.3 - 2 = 0.3$) is not exactly true in floating-point operations due to rounding in the [2, 4) interval being different to the [0.25, 0.5) interval: 2.3 - 2 != 0.3. That gets even more tricky when introducing pi, and that the power is eventually going to be evaluated by summing power series in some form or another.

I think preferentially I'd like to keep the exact bit-for-bit equality assertion for +, -, * and /, because those should be bit-for-bit equal. For power, perhaps it would be cleaner to introduce a new test for power. I don't mind too much if we want to make that use floating-point numbers that should produce bit-for-bit identical outputs, or if we want to relax the assertions to fuzzy matches with ~5 ULP tolerance (or whatever's appropriate).

---

The actual code and release note of this PR looks totally fine to me, thanks.

[grossardt]

@jakelishman Sounds good. I will add new tests for pow then (probably this weekend). Will opt for the fuzzy matches (mainly because the issue doesn't appear on Linux and I have no Windows environment for testing, so this seems easier).

PS: it looks like there are no tests for exp, log, sin, ...? or am I missing those?

[grossardt]

In TestParameterExpressions I changed supported_operations to a dictionary with values indicating tolerance for fuzzy comparison. This shouldn't break anything and leave the option to add more operations in the future.
I also used the opportunity to add a further test that asserts $x^y = exp(y log(x))$, hence testing both pow and exp, log methods (even though this mainly tests sympy functionality, that way exp, log get called at least once, which in my understanding they haven't - I was wrong about trigonometric functions which do have tests).
I hope the tests pass now (they did locally for me).

[jakelishman]

This looks great, thanks for the new tests!