Create 03_evaluating_performance.ipynb #28
Conversation
garrison
added
the
needs: changelog
|
This looks pretty good already. After reviewing the Diátaxis framework's distinction between tutorials and how-to guides, I actually now think this should be placed in the The other important thing to get a handle on is the performance, so that we can continue to regularly run all notebooks as integration tests (using treon). I'm beginning to investigate this. |
I wanted to change this label, since we will soon have a how-to guide that depends on cplex (#28), in addition to the existing tutorial. I first considered calling it `notebooks`, but it doesn't actually install any notebooks. I then settled on `notebook-dependencies`, which is a bit longer but (I feel) is more clear.
I wanted to change this label, since we will soon have a how-to guide that depends on cplex (#28), in addition to the existing tutorial. I first considered calling it `notebooks`, but it doesn't actually install any notebooks. I then settled on `notebook-dependencies`, which is a bit longer but (I feel) is more clear.
I wanted to change this label, since we will soon have a how-to guide that depends on cplex (qiskit-community#28), in addition to the existing tutorial. I first considered calling it `notebooks`, but it doesn't actually install any notebooks. I then settled on `notebook-dependencies`, which is a bit longer but (I feel) is more clear.
* Update requirements to not include notebook only dependencies This commit updates the requirements list to only include required packages for using qrao as a library. The requirements list get installed unconditionally as part of installing the library meaning that every user who tries to use qrao will get them installed too. Having heavy and closed source dependencies like cplex in the list is problematic for library users in particular because it makes it difficult for any downstream consumers to depend on the package since it will always pull those in. To avoid this issue this commit moves the tutorial specific requirements into an optional extra requirement. This then separates the concerns of library users and tutorial users. If you run tutorials you can just run 'pip install prototyp-qrao[tutorials]' which will install the library with the tutorials extras. At the same time these dependencies are added to the requirements-dev.txt list too so that tutorial dependencies are installed during documentation builds too. * Rename the `tutorial` extra requirement to `notebook-dependencies` I wanted to change this label, since we will soon have a how-to guide that depends on cplex (#28), in addition to the existing tutorial. I first considered calling it `notebooks`, but it doesn't actually install any notebooks. I then settled on `notebook-dependencies`, which is a bit longer but (I feel) is more clear. * Update documentation for how to obtain notebook requirements * Fix typo: `extra_require` should be `extras_require` https://setuptools.pypa.io/en/latest/userguide/dependency_management.html#optional-dependencies Co-authored-by: Jim Garrison <garrison@ibm.com>
|
I mentioned in #21:
One might reasonably hypothesize that repeatedly constructing the circuits takes more time than actually running them on the simulator. If so, then parametrizing the circuits might allow us to get many more shots than 1 (as this notebook uses currently) without much additional cost, as we would only have to generate the circuit once, regardless of number of shots. It would be interesting to evaluate whether my hypothesis is indeed correct (i.e., the relevant time spent generating the circuits vs. simulating them). |
Summary
In this notebook, we evaluate the performance of QRAO by determining how closely it approximates the exact solution to MaxCut for 100 random 3-regular graphs. We also compare the performance of QRAO used with two different rounding schemes. In the process, we reproduce the main results of the paper (i.e. Fig. 1).
Details and comments
Running the magic rounding QRAO for a 40-node graph instance takes a while on my machine, so I've set the quantum instance that performs magic rounding to only do 1 shot. We can adjust this easily if necessary. Adding a section to the notebook that analyzes magic rounding QRAO performance (both approximation ratio and execution time) as a function of the number of shots of the rounding quantum instance could be also be interesting.