I am pleased to announce that my quantum simulator Qubiter (available at GitHub, BSD license) now has a native TensorFlow Backend-Simulator (see its class `SEO_simulator_tf`, the `tf` stands for TensorFlow). This complements Qubiter’s original numpy simulator (contained in its class `SEO_simulator`). A small step for Mankind, a giant leap for me! Hip Hip Hurray!

This means that Qubiter can now calculate the evolution of a state vector using CPU, GPU or TPU. Plus it can do back-propagation on a quantum circuit. Here is a jupyter notebook that I wrote that uses Qubiter’s TF backend to do VQE (Variational Quantum Eigensolving). (I like to call VQE, mean Hamiltonian minimization)

Numpy is a tensor library in Python and TensorFlow (produced by Google) is another tensor library in Python. TensorFlow matches by name and functionality, almost 1 to 1, every function in numpy. But the TF namesake functions are much more powerful than their numpy counterparts. Besides accessing the usual CPU, they can access distributed computing resources like GPU and TPU. Furthermore, they can be asked to “tape” a history of their use, and then to replay that history in reverse, back-propagation mode so as to calculate derivatives of a list of user-designated variables. These derivatives can then be used to minimize a cost (aka loss or objective) function. Such minimizations are the bread and butter of classical and quantum neural nets.

These are exciting times for TF:

- Just last March, Google released officially TF version 2.0.
- In TF 2.0, the Eager mode (which is the mode that Qubiter’s TF backend uses) has been elevated to default. TF Eager uses dynamical graphs like the TF competitor, PyTorch, produced by Facebook, uses.
- TF 2.0 also incorporates “Edward”, a software lib by Dustin Tran for doing calculations with Bayesian Networks. Edward in its TF incarnation is called TF Probability. Plus TF 2.0 is also incorporating Keras (a library for doing layered neural nets) and PyMC (a lib for doing Markov Chain Monte Carlo calculations)
- Anyone can run TF 2.0 on the cloud via Google’s Colab. That is, in fact, how I developed and tested Qubiter’s TF backend.

In theory, all you have to do to convert a numpy simulator to a tensorflow one is to change all functions that start with the prefix `np.` by their namesakes that start with the prefix `tf.`. However, the devil is in the details. I, like most good programmers, hate repeating code. I try to avoid doing so at all costs, because I don’t want to have to correct the same bug in multiple places. So I built class `SEO_simulator_tf` by sub-classing the original numpy simulator class `SEO_simulator`. That is one of the beauties of “sub-classing” in OOP (Object Oriented Programming), of which I am a great fan: sub-classing helps you avoid repeating a lot of code. So `SEO_simulator_tf` ended up being a deceivingly short and simple class: all it does is basically turn on a bunch of flags that it passes to its parent class `SEO_simulator`. Most of the new code is in the parent class `SEO_simulator` and other classes like `OneBitGates` which have been modified to respond to all those flags that `SEO_simulator_tf` sets.

]]>`marquee`

.
]]>http://www.ar-tiste.com/threaded_grads_popular_talk.pdf ]]>

`adv_applications`

folder of Qubiter.
**What does the new code do?** I explain this in detail in a paper that I wrote for the occasion. The paper is entitled

Calculation of the Gradient of a Quantum Cost Function using ‘Threading’. Application of these ‘threaded gradients’ to a Quantum Neural Net inspired by Quantum Bayesian Networks

https://github.com/artiste-qb-net/qubiter/blob/master/adv_applications/threaded_grad.pdf

As usual, I included lots of docstrings explaining the code, and a main() method at the end of each class, illustrating its usage and testing it. I will also write some jupyter notebooks with examples of usage in the next week or so.

**So what do I mean by threading?**(I and most people use the words threading and multi-threading synonymously) I believe I am one of the first persons to use the word threading in connection with quantum computing. What I mean by it is the strategy of partitioning the qubits in a (gate model) quantum computer into small, disjoint sets (“islands”) that are uncorrelated from each other and run concurrently. The qubits within one of these islands are strongly correlated but qubits from different islands are probabilistically independent. This is an ideal scenario for NISQ (Noisy Intermediate Scale Quantum) devices and HQC (Hybrid Quantum Classical) computing being pursued by Rigetti Inc. and others. It is also a good fit for calculating the gradient of quantum cost functions: Each island, after many shots and final measurements, yields a mean value, and a linear combination of the mean values from all the islands equals the gradient. In an artistic, poetical sense, qc threading reminds me of what is commonly called “digital rain”, especially if one draws quantum circuits with time pointing downwards, like Qubiter does.

After weeks of deliberation, this weekend I finally decided on my own plan to meet this challenge. I am coding it as we speak. I’m lucky that I am the main author of the quantum simulator Qubiter, because it provides me a lot of polished tools that I know inside out, and that are necessary or extremely useful to meet this challenge. It’s a big head start on others who might embark on the same quest and would try to write their own Qubiter-like tools first. I am also fortunate that my friend Dr. Tao Yin is going to help me.

My idea looks very promising to me, but as Richard Feynman once warned in one of my favorite quotes of his, human beings are very good at fooling themselves, the easiest person to fool is yourself. So even though it looks great to me now, my algo might turn out to be a dud. Still, it will be a lot of fun to test its worth.

On previous blog posts, I have commented on the software PennyLane, which is attempting to meet this challenge. Tonight, during my daily visit to arXiv, I noticed two papers, one that came out today (https://arxiv.org/abs/1904.03206), and another that came out on Mar 28 (https://arxiv.org/abs/1903.12166) that attempt to meet this grand challenge too, by using a tomographic approach. PennyLane and this tomographic approach are formidable competitors to my approach, which is quite different to theirs. It will be fun to race them against each other, even if mine loses.

]]>“Calculating the Gradient of a Cost Function for a Parametric Quantum Circuit in FIVE EASY PIECES”

This weekend, I decided to add to that essay a new, more technical, 5 page appendix that fills some of the gaps left behind in the main part of the essay. So even if you perused the essay before today, you might be interested in re-opening it to take a peek at the new addition.

What I do in the new appendix is to show how to express the gradient of the cost function as a sum of mean values that are readily evaluated empirically on a real qc. So far, the PennyLane software only considers evaluating the gradient of cost functions wherein the parameters being differentiated only occur in one qubit gates with *no* controls. I show in this new appendix how to deal with the case when the parameters being differentiated also occur in gates with any (0, 1, 2, …) number of controls.

The Yellow Brick Road follows the gradient of a quantum cost function. God’s truth. To do back-propagation, “close your eyes and tap your heels together three times. And think to yourself, there’s no place like home.”

]]>https://arxiv.org/abs/1903.09650

“Differentiable Programming Tensor Networks”,

by Hai-Jun Liao, Jin-Guo Liu, Lei Wang, Tao Xiang

The authors are mostly from CAS (Chinese Academy of Science) in Beijing. Nice work like this convinces me that China is producing top quality work in AI and physics. I am very happy that Dr. Tao Yin, one of the cofounders of our startup, artiste-qb.net, is Chinese, currently living in Shenzhen. The paper in question has a very nice section explaining auto differentiation. Blogs make nice scrapbooks, so I copied that section and present it below.

]]>]]>

Technically, what Rigetti Cloud offers that is relevant to this blog post is

Hybrid Quantum Classical NISQ computing to implement the VQE (Variational Quantum Eigensolver) algorithms.

Phew, quite the mouth full!

The back-prop in Qubiter is currently done automagically by the awesome software Autograd (https://github.com/HIPS/autograd), which is a simpler version of, and one of the primary, original inspirations for PyTorch. In fact, PyTorch contains its own version of Autograd, which is called, somewhat confusingly, PyTorch Autograd, as opposed to the the earlier HIPS Autograd that Qubiter currently uses.

I also plan in the very near future to retrofit Qubiter so that it can also do back-prop using PyTorch and Tensorflow. This would enable Qubiter to do something that Autograd can’t do, namely to do back-prop with the aid of distributed computing using GPU and TPU. I consider enabling Qubiter to do back-prop via Autograd to be a very instructive intermediate step, the bicycle training wheels step, towards enabling Qubiter to do distributed back-prop via PyTorch and TensorFlow.

AI/Neural Network software libs that do back-propagation are often divided into the build-then-run and the build-as-run types. (what is being built is a DAG, an acronym that stands for directed acyclic graph). Autograd, which was started before Pytorch, is of the build-as-run type. PyTorch (managed by Facebook & Uber, https://en.wikipedia.org/wiki/PyTorch) has always been of the b-as-run type too. Tensorflow (managed by Google, https://en.wikipedia.org/wiki/TensorFlow) was originally of the b-then-run type, but about 1.5 years ago, Google realized that a lot of people preferred the b-as-run to the b-then-run, so Google added to Tensorflow, a b-as-run version called Eager TensorFlow. So now Tensorflow can do both types.

PyTorch and TensorFlow also compete in an area that is near and dear to my heart, bayesian networks. The original PyTorch and TensorFlow both created a DAG whose nodes were only deterministic. This is a special case of bayesian networks. In bnets, the nodes are in general probabilistic, but a special case of a probabilistic node is a deterministic one. But in recent times, the PyTorch people have added also probabilistic nodes to their DAGs, via an enhancement called Pyro (Pyro is managed mainly by Uber). The TensorFlow people have followed suit by adding probabilistic nodes to their DAGS too, via an enhancement originally called Edward, but now rechristened TensorFlow Probability (Edward was originally written by Dustin Tran for his PhD at Columbia Uni. He now works for Google.) And, of course, quantum mechanics and quantum computing are all about probabilistic nodes. To paraphrase Richard Feynman, Nature isn’t classical (i.e., based on deterministic nodes), damnit!

In a nutshell, the Bayesian Wars are intensifying.

It’s easy to understand the build-as-run and build-then-run distinction in bnet language. The build-then-run idea is for the user to build a bnet first, then run it to make inferences from it. That is the approach used by my software Quantum Fog. The build-as-run approach is quite different and marvelous in its own right. It builds a bnet automagically, behind the scenes, based on the Python code for a target function with certain inputs and outputs. This behind the scenes bnet is quite fluid. Every time you change the Python code for the target function, the bnet might change.

I believe that quantum simulators that are autograd-pytorch-tensorflow-etc enabled are the future of the quantum simulator field. As documented in my previous blog posts, I got the idea to do this for Qubiter from the Xanadu Inc. software Pennylane, whose main architect is Josh Izaac. So team Qubiter is not the first to do this. But we are the second, which is good enough for me. WooHoo!

PennyLane is already autograd-pytorch-tensorflow enabled, all 3. So far, Qubiter is only autograd enabled. And Pennylane can combine classical, Continuous Variable and gate model quantum nodes. It’s quite general! Qubiter is only for gate model quantum nodes. But Qubiter has many features, especially those related to the gate model, that PennyLane lags behind in. Check us both out!

In Qubiter’s jupyter-notebooks folder at:

https://github.com/artiste-qb-net/qubiter/tree/master/jupyter-notebooks

all the notebooks starting with the string “MeanHamilMinimizer” are related to Qubiter back-prop

]]>