Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Follow-up to TaperedQubitMapper #1049

Closed
5 tasks
mrossinek opened this issue Feb 1, 2023 · 0 comments · Fixed by #1073
Closed
5 tasks

Follow-up to TaperedQubitMapper #1049

mrossinek opened this issue Feb 1, 2023 · 0 comments · Fixed by #1073
Assignees
Milestone

Comments

@mrossinek
Copy link
Member

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 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.
  • implement _ListOrDict.wrap as suggested here

  • 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.
@mrossinek mrossinek added this to the 0.6.0 milestone Feb 1, 2023
@mrossinek mrossinek self-assigned this Feb 1, 2023
@mrossinek mrossinek linked a pull request Feb 22, 2023 that will close this issue
@mergify mergify bot closed this as completed in #1073 Feb 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant