Closed smite closed 5 years ago
Added two working examples on VQEs (need to be adapted once final API is out) Added one pseudocode example on CV quantum neural net.
There are 3 qubit and 2 CV examples on branch examples_maria. I will try to code up a CV GAN to have 6 in total.
However, none of the examples except one does what it is supposed to do and I think I need some help here.
Tut Q1 - works Tut Q2 - does not work with project Q backend Tut Q3 - does not work with regularizer (see #56), cost INCREASES, classifier always seems to predict either all -1 or all 1
Tut CV1 - gradient is always zero, although it clearly should not be Tut CV2 - does not learn much, although Juan Miguel's code in tensorflow with exactly the same settings learns nicely.
I have an inkling that we have a mix of bugs here.
You can use the .py file for convenience, or the jupyter notebook.
Does Tut Q2 work with the default.qubit backend? That's odd.
For Tut CV1, that sounds like the same issue that currently causes photon redirection to fail, which likely won't be fixed until @smite merges his next feature branch.
So definitely a mix of bugs!
Yes it seems to work with the default backend. Can the redirection bug be also responsible for the CV2 to fail?
I am going through T2 to see why it doesn't work with ProjectQ.
The first problem is definitely the preparation with QubitStateVector
. This is not a bug in the plugin but a "shortcoming" of ProjectQ. They don't know how to decompose the manually specified state into an elementary gate sequence that would prepare it. I don't think I can do anything about it. We could use a manually specified gate sequence instead of the initial state given as a vector. They do know ho to decompose arbitrary single qubit initial states.
For example, if I simply use qm.Hadamard([0])
instead of qm.QubitStateVector(initial_state, wires=[0, 1])
in ansatz()
. ProjectQ produces the same result for the optimization than the default plugin.
Maybe it is also good to not start with the weights initialized to zero? For some initial states I get stuck with both the default and the ProjectQ plugin. People might modify the example when they play around and get frustrated...
Waiting to update the examples when the new structure is out. I think Josh wanted to put the examples into the plugin repo and only keep two very minimal default templates for openqml itself. We can then make sure the ProjectQ examples do not use QubiStateVector hacks.
[This is more for myself as reminder]
Testing the examples with latest merge. Issues:
PQ: 1 Different behaviour of ProjectQ and default.qubit - PQ gets stuck on saddle point! 3a - Test state prep script. Does not learn. [KWARGS BUG] 3b - Does not learn [KWARGS BUG]
SF: 3 QNN Does not learn [KWARGS BUG]
I just realised that we're missing a Tutorials section in the docs sidebar, as we have with Strawberry Fields. I've added that in the latest master, it just needs to be populated now.
@mariaschuld, we could kill two birds with one stone, and embed the Jupyter notebooks for the examples directly in the docs? See https://strawberryfields.readthedocs.io/en/latest/gallery/state_learner/StateLearning.html for an example of what this looks like.
The advantages of this approach are:
Downsides, however, are
The docs for Notebook/Spinx plugin is available here: https://nbsphinx.readthedocs.io/en/0.3.5/
The alternative would be to convert the notebook to a rst file and make it static, right?
Will the docs tutorial section be distinguished into the different plugins? Is it not confusing that one needs different repos to run the tutorials?
Had a quick conversation with @mariaschuld, this was the consensus:
OpenQML shouldn't depend on any of the plugins, to avoid pulling in libraries the user might not want.
The docs should have a page(under 'Getting Started') that lists all 'official' plugins, and describes the plugin ecosystem for the user (i.e. OpenQML is designed to be used with plugins, these need to be pip installed, etc).
All tutorials for the 'official' plugins should be in the main OpenQML docs, with a disclaimer at the top (i.e. .. note::
or .. warning::
or .. info::
) which says
To run this tutorial, you must install
pennylane-sf
viapip install pennylane-sf
'
This keeps everything centralised (for the user) and easier to keep track of (for us).
The actual plugins will have their own docs, but bare bones and just to describe their API via Sphinx. These will be linked in the main OpenQML docs, and vice versa.
Just checking in on the status of examples.
As stated above, we want all examples/tutorials to be placed in the main library. This is so that users can find them easiest (it will not affect the dependencies of the library). We can also have copies in other repos, but we don't want them to be missing from the core docs
So far there are two tutorials ("Basic tutorial: qubit rotation" and "Photon redirection and hybrid computation") present in the main library documentation. These look great! (one todo still to take care of)
I added a QGAN example last night (worked right away, really cool :) ), but it'll need a bit more polishing
@mariaschuld where can we find the remaining examples/tutorials? Can we get these placed in the core library master
branch now?
Sure. My last bit of information was that we put them into the documentation of the main library but in the repo of the plugins to not to have code for plugins in the main repo. But we broke this rule anyways in the mini-demos by using SF for the Fock State preparation.
I can easily move the notebooks and .py files to the main repo. My suggestion is that I do this after the 3 PRs are merged, to avoid lots of work merging.
Examples are on add_examples... branch in the main repo and refactored.
Last things to do:
All running
More demos should be added (in the examples directory). They should be self-contained Python scripts that use OpenQML to do something interesting and educational. The demos should have lots of comments in them, ideally explaining both what we are doing, and why we are doing it.
Ideas: