Integrating the TwoQubitReduction into the ParityMapper

[mrossinek]

What should we add?

As outlined in #967 we want to extract the TwoQubitReduction from qiskit.opflow into the ParityMapper which is the only mapper that actually supports this hard-coded symmetry.

To achieve this, I envision an API similar to the following:

class ParityMapper:
    def __init__(self, two_qubit_reduction: bool = False, num_particles: tuple[int, int] | None = None):
        ...

We need to default the two_qubit_reduction to False because we do not know the num_particles by default.
Providing the num_particles at initialization time ensures that the mapper can be used right away. The downside is that this makes it stateful for the current problem.

I would also be open to discussing the following API (which I personally even prefer):

class ParityMapper:
    def __init__(self, num_particles: tuple[int, int] | None = None):
        ...

The idea here is that if num_particles is provided we enable the reduction and if it is None we do not. Simple and less redundant 👍

---

Implementation of this issue is blocked by Qiskit/qiskit#9140 because we would want to immediately use the new SparsePauliOp-based Z2Symmetries 👍

[Anthony-Gandon]

I can contribute here also

[Anthony-Gandon]

This PR is no longer blocked by #9140 from qiskit-terra so I'll start working on a draft.
I wanted to add another view point on the API choice: The tapering is often seen as the trade off "n qubits to n-m qubits but m symmetry sectors". THis in practice leads to no advantage until applied to problem for which the solution sector can be identified in advance.
The first API highlights this idea that one can reduce the size of the problem (qubit requirements) without deciding on the symmetry sector.
I'll also mention that only the symmetry sector locator is stateful.

[mrossinek]

The first API highlights this idea that one can reduce the size of the problem (qubit requirements) without deciding on the symmetry sector.

That is indeed a good point! I'm wondering whether we should then generalize the naming and find something better than num_particles. Although here (in the ParityMapper for FermionicOp instances), the particle-interpretation seems fine, too.

[Anthony-Gandon]

That is indeed a good point! I'm wondering whether we should then generalize the naming and find something better than num_particles. Although here (in the ParityMapper for FermionicOp instances), the particle-interpretation seems fine, too.

The num_particles is later transformed into a symmetry operator eigenvalue tapering_value so the variable name will certainly lie between these two concepts. It is more natural that the mappers implement this transformation so that users only provide a physical property (instead of the abstract symmetry sector). I personally like num_particles for the ParityMapper