Expose cutoff tolerances in Z2Symmetries

[Cryoris]

Summary

Allow setting the cutoff tolerances of the tapered operator in Z2Symmetries. This fixes Qiskit Nature CI, where some workflows pass the tapered operator into the Pauli evolution gate. This fails since #7551 since the tapering creates some spurious complex coefficients from roundoff errors but the Pauli evolution gate does not allow any complex parts at all.

Details and comments

This PR also add a new method the SparsePauliOp.chop to truncate real and imaginary parts of a coefficients individually. That means that coefficients like

[1+1e-17j, 1e-17j]

are truncated to

[1, 0]

This is different to SparsePauliOp.simplify which would simplify the above coefficient to

[1+1e-17j, 0].

This fix could be part of another PR but it's required to properly remove the imaginary parts of the tapered operator so I included it here.

WIP as it misses a test.

[coveralls]

Pull Request Test Coverage Report for Build 1860181076

• 24 of 24 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.006%) to 83.338%

---

Totals
Change from base Build 1859454297:	0.006%
Covered Lines:	52239
Relevant Lines:	62683

---

💛 - Coveralls

[Cryoris]

After discussions with @ikkoham and @jakelishman I updated the PR to do the following now: Leave simplify as is and instead add a new method

def chop(self, tol: float = 1e-14) -> SparsePauliOp:

which chops real and imaginary parts of coefficients that are within an (absolute) tolerance tol of 0. If a coefficient is completely chopped to 0 it is removed from the operator. So, for instance

>>> from qiskit.quantum_info import SparsePauliOp
>>> op = SparsePauliOp(["X", "Y", "Z"], coeffs=[1+1e-17j, 1e-17+1j, 1e-17])
>>> op.simplify()
SparsePauliOp(['X', 'Y'], coeffs=[1.e+00+1.e-17j, 1.e-17+1.e+00j])
>>> op.chop()
SparsePauliOp(['X', 'Y'], coeffs=[1.+0.j, 0.+1.j])

I chose the default 1e-14 a bit at random, since (1) I didn't want to use the SparsePauliOp.atol as thats the tolerance cutoff for the absolute value of a coefficient, not the real and imaginary parts individually and (2) using tol=0.0 wouldn't do anything per default which would be weird too. I'm happy to change the default if you have other preferences!

This method is a bit parallel to simplify now and calling both chop and simplify will copy the coefficients twice but if we want to keep these features (chopping absolute values and chopping real/imag parts) I don't think there's a way around that.

I ran the failing Nature tests locally and with this PR they run again as desired. 🙂

[ikkoham]

Thank you. I think this method is what we want. If we need different tolerance for real and imag, we can add them at that time. I can't think of any use cases at the moment. LGTM

[mrossinek]

Basically lgtm, just some minor observations 👍

[jakelishman]

I like the new SparsePauliOp.chop - to me, it's definitely a good solution to the general problem, and it's nicely composable for you guys downstream, which hopefully should lead to easier maintenance for everyone. Thanks for sticking with it.

[jakelishman]

What's the reason for adding a property to wrap the normal behaviour? It doesn't seem to be doing anything except adding overhead.

[Cryoris]

I added it for consistency with tapering_values which is the only other attribute that is settable. Personally I'd also prefer to just have it as public attribute (just self.tol in the init) 🙂

[jakelishman]

From the user's perspective there wouldn't be any inconsistency unless they're in the habit of requiring del x.tol to raise an error or other weird stuff. But also, I don't really care haha.

[jakelishman]

Looks good to me! Ikko already approved a slightly earlier version of this, so I'll assume he's fine with the minor performance tweaks, and set this to merge now.