Add __pos__ for Parameter

[eendebakpt]

Summary

Add __pos__ for Parameter and ParameterExpression

Details and comments

The implementation is simular to the __neg__

[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 following people are relevant to this code:

• @Qiskit/terra-core

[jakelishman]

This seems sensible in spirit to me, thanks.

I guess it would have made more sense if we were able to use operator.pos in the _apply_operation, but that function seems to be set up to assume binary operations, so never mind on that front.

I'm not wild about introducing a floating-point number with this, though, and the same goes for __neg__. Definitely feels like we might at least want to make them multiplication by integers rather than floats (if we can't just use operator.pos and operator.neg directly) to avoid introducing imprecisions into the evaluation contexts.

Please could you also add a circuits feature release note about this?

[eendebakpt]

This seems sensible in spirit to me, thanks.

I guess it would have made more sense if we were able to use operator.pos in the _apply_operation, but that function seems to be set up to assume binary operations, so never mind on that front.

I'm not wild about introducing a floating-point number with this, though, and the same goes for __neg__. Definitely feels like we might at least want to make them multiplication by integers rather than floats (if we can't just use operator.pos and operator.neg directly) to avoid introducing imprecisions into the evaluation contexts.

Please could you also add a circuits feature release note about this?

Multiplication with an int seems nicer indeed. I can change it for this PR, but I am not sure whether there are any implications for __neg__. Let me know

[coveralls]

Pull Request Test Coverage Report for Build 9358258610

Details

• 3 of 3 (100.0%) changed or added relevant lines in 1 file are covered.
• 9 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-0.007%) to 89.591%

---

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/lex.rs	1	92.88%
qiskit/transpiler/passes/synthesis/unitary_synthesis.py	2	88.2%
crates/qasm2/src/parse.rs	6	97.61%

Totals
Change from base Build 9327235113:	-0.007%
Covered Lines:	62360
Relevant Lines:	69605

---

💛 - Coveralls

[jakelishman]

Let's make at least __pos__ be multiplication by integer here. I think we ought to change __neg__ too - if the tests don't complain about it (and hopefully nothing in our test suite depends on that questionable behaviour...), but happy to do that in a follow-up if you prefer.

[jakelishman]

Ace, thanks!