Skip to content

Conversation

tnemoz
Copy link
Contributor

@tnemoz tnemoz commented Sep 14, 2025

Summary

Fixes #76 and fixes #241. The AmplificationProblem and EstimationProblem classes now use the grover_operator function instead of the deprecated GroverOperator class to build their respective oracle. The tests have been adapted to test for both, and the tutorial uses the new function.

The access to attributes of GroverOperator has been replaced with that of AmplificationProblem.

@coveralls
Copy link

coveralls commented Sep 14, 2025

Pull Request Test Coverage Report for Build 17765604336

Details

  • 9 of 11 (81.82%) changed or added relevant lines in 3 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage decreased (-0.02%) to 90.176%

Changes Missing Coverage Covered Lines Changed/Added Lines %
qiskit_algorithms/amplitude_amplifiers/amplification_problem.py 4 5 80.0%
qiskit_algorithms/amplitude_estimators/estimation_problem.py 4 5 80.0%
Totals Coverage Status
Change from base Build 17759027522: -0.02%
Covered Lines: 6664
Relevant Lines: 7390

💛 - Coveralls

Copy link
Collaborator

@Cryoris Cryoris left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The grover_operator function has only been introduced in Qiskit v1.3, but the qiskit-algorithms repo is currently stated to be compatible with qiskit>=1.0. To avoid a breaking change and remain compatible with Qiskit 1.0 we would have to treat both GroverOperator and grover_operator.


# construct the grover operator
return GroverOperator(oracle, self.state_preparation)
return grover_operator_builder(oracle, self.state_preparation)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could use qiskit.__version__ to check whether to return GroverOperator or grover_operator here. This should also be documented then

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In order not to introduce a breaking change then, is it OK if the function uses GroverOperator if the Qiskit version is 2.1.2 or older, and otherwise uses grover_operator? That way, it would prevent a breaking change from users upgrading qiskit-algorithms without upgrading qiskit.

This of course assume that the next qiskit-algorithms release is done before Qiskit 2.2.0 is out! Or we could test for < 3.0, since this is when GroverOperator is removed if I'm not mistaken. What are your views on this?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good questions -- my preference would be to use the grover_operator function whenever possible (i.e. qiskit>=1.3) since it's more efficient than the GroverOperator. But maybe it's safest to just sell this as bugfix and start using grover_operator with qiskit>=2.1 since the GroverOperator was deprecated in 2.1.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went for the latter and thus updated the release note to categorize this as a bug fix. Does that work for you?

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 this pull request may close these issues.

Take care deprecation of GroverOperator Grover assumes type GroverOperator
3 participants