This class will be used in more than just circuit ansatze and layers.

As far as I know (@naezzell correct me if I'm wrong), we're only using torch to do PCA. Torch is a huge download -- only using PCA from it is a waste. We should avoid this by using a native implementation of PCA, or another way around the torch dependency.

I'm not adding torch to requirements.txt with the expectation that it will be removed.

Currently, Encoding classes (AngleEncoding, DenseAngleEncoding) store a list of BaseAnsatz's with circuits for preparing each feature vector. This is inefficient.

See the unit test test_compiler() in network/_network_test.py. For some reason, compiling the Network's circuit (which is the concatenation of each encode, unitary, and measurement component) is causing the Rigetti API to have a KeyError.

The issue is not a connection issue, as other compiling tests are still passing.

@naezzell I think the input to LabeledCData in get_mnist_data is wrong. See TODO comment and please update when you can.

There are several unit tests failing in CData after some updates. (These should have been failing all along, the updates just revealed them.)

(1) The higher dimensional data example is not supported. The input data to any CData object must, as of know, be explicitly two-dimensional. I think this unit test should be removed. Thoughts?

(2) The train_test_split(...) unit test used to input one-dimensional data when creating a CData object, which is again nonsense. As such, the later checks are equally nonsense. Could you update this with sensible checks?

Thinking of something similar to printing a circuit in Cirq. This would be extremely useful for visualizing both circuits and the network.

Should take in an object that contains a pyquil Program and return a string corresponding to a visual representation of said program (for the circuit drawer).

For the network drawer, we may want to have "blackbox drawings" like

----[Encode]----[Transform]----[Measure]----[Relu]----[Encode]----...

or something similar.

Even after changing the default branch to dev on github, Travis still isn't able to build. Possible problems (literally just guessing):

(1) Something's wrong with the .travis.yml file. (I essentially copied this from OpenFermion and ProjectQ, making the appropriate changes.)
(2) It's because the repo is private, the branch is dev, or some other git related cluster fuck.

As of now, if one forgets to catch the output of utils.startQVMandQUILC() and pass this into utils.stopQVMandQUILC(), the processes remain running on their machines. This is undesirable. Ideally, some "safety checks" should be put in place. If not, we must be extremely explicit that this is going to happen, and warn users multiple times.

An "Angle Encoding" has already been defined in "Supervised Learning with Quantum Computers" by Schuld:

https://www.springer.com/us/book/9783319964232

which takes a single feature x_i to a qubit via the encoding

cos(x_i) |0> + sin(x_i) |1>.

The difference between our "AngleEncoding" is we also encode a feature into the relative phase \phi.

I propose to stick with Schuld's definition of AngleEncoding and rename our implementation to DenseAngleEncoding.

There seems to be no easy way to do this, unfortunately, as the length of a Program includes operations like "DECLARE."