Skip to content
This repository was archived by the owner on Dec 7, 2021. It is now read-only.

Fix a bug in grover optimizer #1197

Merged
merged 14 commits into from
Aug 21, 2020
Merged

Conversation

t-imamichi
Copy link
Contributor

Summary

I found a tricky code in GroverOptimizer and this PR fixes it.

Details and comments

In GroverOptimizer.solve it computed the objective function value of the optimal values in the following line.
https://github.com/Qiskit/qiskit-aqua/blob/e13728e6cdfdb1438a7d2d11d856622c90ce328b/qiskit/optimization/algorithms/grover_optimizer.py#L263
However, this fval is not the optimal function value of the original problem because problem_ is modified from the original one as follows.

As a result, fval computed from problem_ is not what we expected. However, LinearEqualityToPenalty happens to correct the fval in the following line. So, it passes the unit tests.
https://github.com/Qiskit/qiskit-aqua/blob/e13728e6cdfdb1438a7d2d11d856622c90ce328b/qiskit/optimization/converters/linear_equality_to_penalty.py#L194

I modified the code so that OptimizationResult(x=opt_x, fval=fval, variables=problem_.variables) in the following line becomes the optimal solution to the original problem to improve the consistency of the code.
https://github.com/Qiskit/qiskit-aqua/blob/e13728e6cdfdb1438a7d2d11d856622c90ce328b/qiskit/optimization/algorithms/grover_optimizer.py#L264

stefan-woerner
stefan-woerner previously approved these changes Aug 13, 2020
@stefan-woerner
Copy link
Contributor

@t-imamichi good catch!

@stefan-woerner
Copy link
Contributor

@t-imamichi could you make sure the tests are covering this?

@t-imamichi
Copy link
Contributor Author

Because the fval is hidden in the solve method, we need to copy the fval as part of GroverOptimizerResult. Perhaps, we have to do a similar stuff for other optimizers too if they use any converters internally. Let me check other optimizers. By the way, this bug is found as part of #1196.

@woodsp-ibm woodsp-ibm added Changelog: Bugfix Include in the Fixed section of the changelog stable backport potential The bug might be minimal and/or import enough to be port to stable labels Aug 13, 2020
@woodsp-ibm woodsp-ibm added this to the 0.8 milestone Aug 13, 2020
@t-imamichi
Copy link
Contributor Author

t-imamichi commented Aug 14, 2020

The other optimizers don't have a similiar issue. So, we need to take care of Grover optimizers.

If we check the integrity of fval of problem_ and fval of problem as part of unit tests, we need to copy fval of problem_ to a new entry of GroverOptimizationResult, e.g., GroverOptimizationResult.fval2. But, users don't need it for applications because GroverOptimizationResult.fval == GroverOptimizationResult.fval2 is expected. So, I'm wondering what is the best way.

@t-imamichi
Copy link
Contributor Author

@stefan-woerner How about continuing to hide the internal fval? It might be complicated to add anther fval to OptimizationResult.

@woodsp-ibm
Copy link
Member

@t-imamichi Since there exists raw_results, and also its easy enough to add a new field to the GroverOptimizationResult, I am wondering why it seems so hard to return this internal fval, if that is what is wanted. Outside of unit tests do we ever assert fval and fval2 match? If they did not is it useful to the end user to have this internal fval so they can check/see any mismatch - I guess some explanation might be needed around these properties in that respect so an end user can understand this if its meaningful to inform them of the internal fval.

@stefan-woerner
Copy link
Contributor

@t-imamichi I think @woodsp-ibm is right, the raw_results should give access to the value for the modified problem, shouldn't it? The raw_results should actually provide the offset and the intermediate results, such that you could reconstruct the original problem at any stage.

@t-imamichi
Copy link
Contributor Author

t-imamichi commented Aug 19, 2020

I agree that adding offset and intermediate results is informative, but I have a doubt of the internal fval because it is essentially identical with the external fval. The internal fval is not necessary to reconstruct the original problem at all because the external fval is same.

But, I add the internal fval in the following commits. If you want to add more intermediate values to GroverOptimizationResults, please let me know.

@t-imamichi
Copy link
Contributor Author

I added intermediate_fval and threshold as part of GroverOptimizationResult and added a unit test using it.

@woodsp-ibm woodsp-ibm merged commit 9317bab into qiskit-community:master Aug 21, 2020
@t-imamichi t-imamichi deleted the fix_grover branch August 25, 2020 09:11
Cryoris pushed a commit to Cryoris/qiskit-aqua that referenced this pull request Sep 3, 2020
* fix a bug in grover optimizer

* add intermediate_fval and threshold to raw_results

* move intermediate_fval and threshold to properties

Co-authored-by: Manoel Marques <[email protected]>
Co-authored-by: Steve Wood <[email protected]>
pbark pushed a commit to pbark/qiskit-aqua that referenced this pull request Sep 16, 2020
* fix a bug in grover optimizer

* add intermediate_fval and threshold to raw_results

* move intermediate_fval and threshold to properties

Co-authored-by: Manoel Marques <[email protected]>
Co-authored-by: Steve Wood <[email protected]>
manoelmarques added a commit to qiskit-community/qiskit-optimization that referenced this pull request Jan 14, 2021
* fix a bug in grover optimizer

* add intermediate_fval and threshold to raw_results

* move intermediate_fval and threshold to properties

Co-authored-by: Manoel Marques <[email protected]>
Co-authored-by: Steve Wood <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Changelog: Bugfix Include in the Fixed section of the changelog stable backport potential The bug might be minimal and/or import enough to be port to stable
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants