add dtype parameter to PauliSumOp.from_list

[kevinsung]

Summary

This change is needed for PauliSumOp to be able to pass type information to SparsePauliOp.

Details and comments

[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:

• @Cryoris
• @Qiskit/terra-core
• @manoelmarques
• @woodsp-ibm

[coveralls]

Pull Request Test Coverage Report for Build 3884574792

• 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.04%) to 84.596%

---

Totals
Change from base Build 3882540095:	-0.04%
Covered Lines:	64140
Relevant Lines:	75819

---

💛 - Coveralls

[ikkoham]

Sounds good. Could you add the release note please?

BTWm, it might be nice to support Parameters in another PR:
https://github.com/Qiskit/qiskit-terra/blob/6aad91418951484ee5cf808a0c147f96bc951223/qiskit/opflow/primitive_ops/primitive_op.py#L229-L252

[Cryoris]

While this is certainly better than having to wrap the coefficients into an array, I still think it's not very intuitive for users if they have to explicitly set the dtype when using the parameters.

Would checking the type of each coefficient add a noticeable overhead? Isn't the complexity of initializing already linear? 🙂 Otherwise how about allowing to set the dtype for efficiency but checking the type for the user by default?

[kevinsung]

Would checking the type of each coefficient add a noticeable overhead? Isn't the complexity of initializing already linear?

The overhead is pretty minimal. But I think it should be done in SparsePauliOp, not PauliSumOp. If that is agreed upon, I can make a PR for that.

[kevinsung]

I added the release note.

[Cryoris]

The overhead is pretty minimal. But I think it should be done in SparsePauliOp, not PauliSumOp. If that is agreed upon, I can make a PR for that.

@ikkoham what do you think about this, could we check the type of the coeffs on construction? 🙂

[Cryoris]

Let's merge this since specifying the dtype is required to have the same functionality as the SparsePauliOp. We can follow-up if we should make the dtype be derived automatically so we can avoid explicitly setting it to object for parameters.