You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A few tasks related to the TaperedQubitMapper were decided to be left out of #1031 and instead be tackled in a follow-up. This issue gathers these remaining tasks such that we do not forget about them:
deprecate the match_convert argument in hartree_fock_bitstring_mapped
This argument is no longer needed because the workflow has now changed. While this method is still being called from ElectronicStructureProblem.symmetry_sector_locator, this is now guaranteed to be provided with a QubitMapper which does not introduce any tapering (because this method is actually used to construct the TaperedQubitMapper). Given that we also change the BaseProblem.symmetry_sector_locator interface (see below), we can safely deprecate this now unneeded logic.
Deprecate BaseProblem.symmetry_sector_locator
This method is no longer needed in the public API since BaseProblem.get_tapered_mapper takes care of creating a TaperedQubitMapper. Thus, it may be beneficial so simplify the public API by deprecating this method and moving its contents to an internal method which a problem may implement to support tapering.
I am still open to discussion on this. The reason I am a bit hesitant, is that a user building a custom Problem with a custom symmetry sector logic would need to learn about this private method. However, this I would consider more a developers job who should also be able to familiarize themselves with an internal API.
rename all variables/arguments related to QubitConverter match the QubitMapper API
This is optional for now and depends on the deprecation path for the QubitConverter. But it would be nice to rename (qubit_)converter to (qubit_)mapper consistently
start the deprecation process of QubitConverter
In 0.6 we will be able to pending-deprecate the QubitConverter and point the users to use the QubitMapper objects directly. In the next release (or 3 months later) we will be able to then deprecate the QubitConverter.
The text was updated successfully, but these errors were encountered:
What should we add?
A few tasks related to the
TaperedQubitMapper
were decided to be left out of #1031 and instead be tackled in a follow-up. This issue gathers these remaining tasks such that we do not forget about them:deprecate the
match_convert
argument inhartree_fock_bitstring_mapped
ElectronicStructureProblem.symmetry_sector_locator
, this is now guaranteed to be provided with aQubitMapper
which does not introduce any tapering (because this method is actually used to construct theTaperedQubitMapper
). Given that we also change theBaseProblem.symmetry_sector_locator
interface (see below), we can safely deprecate this now unneeded logic.Deprecate
BaseProblem.symmetry_sector_locator
BaseProblem.get_tapered_mapper
takes care of creating aTaperedQubitMapper
. Thus, it may be beneficial so simplify the public API by deprecating this method and moving its contents to an internal method which a problem may implement to support tapering.implement
_ListOrDict.wrap
as suggested hererename all variables/arguments related to
QubitConverter
match theQubitMapper
APIQubitConverter
. But it would be nice to rename(qubit_)converter
to(qubit_)mapper
consistentlystart the deprecation process of
QubitConverter
QubitConverter
and point the users to use theQubitMapper
objects directly. In the next release (or 3 months later) we will be able to then deprecate theQubitConverter
.The text was updated successfully, but these errors were encountered: