Qiskit
Update advanced-techniques-for-qaoa tutorial
Addresses #4056 and updates the tutorial by running the experiment on a Heron device (ibm_kingston ). Matches the notebook presented in https://youtu.be/rBfK-l-qSNk?si=fl5nSsKxKe0clTc5.
Check out this pull request on 
See visual diffs & provide feedback on Jupyter Notebooks.
Powered by ReviewNB
![review-notebook-app[bot] avatar](https://avatars.githubusercontent.com/in/15474?v=4 "Published by a pub.dev verified publisher"){kind=small}
Thanks for contributing to Qiskit documentation!
Before your PR can be merged, it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient. Thanks! 🙌
One or more of the following people are relevant to this code:
- @a-matsuo
- @annaliese-estes
- @miamico
Thanks for contributing to Qiskit documentation!
Before your PR can be merged, it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient. Thanks! 🙌
One or more of the following people are relevant to this code:
- @a-matsuo
- @annaliese-estes
- @miamico
Looks good! Just a very minor adjustment to the text in the usage estimate. Replace the exact device name used with the type and revision number e.g. "Usage estimate: 3 minutes on a Heron r2 (NOTE: This is an estimate only. Your runtime might vary.)"
Thanks, @miamico . I just went ahead and made that change.
This does not seem to close #3534 - The graph displayed in the video and in this PR is visibly far from optimal. Note, for example, the two "tails" in
which can be altered to increase the score.
This does not seem to close #3534 - The graph displayed in the video and in this PR is visibly far from optimal. Note, for example, the two "tails" in
which can be altered to increase the score.
@matanninio is this due to a bug in the tutorial or simply further optimization? If it's a bug we should fix it. If we can improve results drastically with simple techniques like a swap search we could also implement that but I wouldn't go too far down the optimization rabbit hole
@matanninio is this due to a bug in the tutorial or simply further optimization? If it's a bug we should fix it. If we can improve results drastically with simple techniques like a swap search we could also implement that but I wouldn't go too far down the optimization rabbit hole
This could stem from different reasons. If it's the optimization, we are doing a horrible job as there are trivial changes that would improve it, and all in all it seems very from from optimal. But the reason for the original issue I posted is that bit-order reversal has had very similar effects on graphs in the past, and I do not know if the bug has been fixed or not in the video. If you have access to the solution, you can try to recreate the graph with the node numbers and try to compare it to the solution. I did try to do this manually from the images, and I think it may be the case, but it's hard to be convinced.
@matanninio is this due to a bug in the tutorial or simply further optimization? If it's a bug we should fix it. If we can improve results drastically with simple techniques like a swap search we could also implement that but I wouldn't go too far down the optimization rabbit hole
just to make this clear - this set of very trivial changes adds 14-15 edges to the solution. The picture does not represent a reasonable "optimal" solution by a long shot. if this is not a bug in the graph generation, this is a very strong statement ageist this method.
@matanninio I think the displaying of the final solution should be fixed now (the bit string needed to be reversed in the plotting code). Given everything else this PR was supposed to do has been done, I'll merge it. With regards to your comment on possible other improvements that can be obtained, I suggest opening an issue with the details so that we can consider them in future versions of the tutorial