Quantum Bayesian Networks

January 27, 2019

Artiste-qb.net will be at FOSDEM 2019, Feb 2-3, 2019

Filed under: Uncategorized — rrtucci @ 3:45 am

FOSDEM is a yearly hacker conference dedicated to open source software. It is usually attended by > 8,000 hackers. Its venue is the Université Libre de Bruxelles Solbosch campus in the southeast of Brussels, Belgium. This year, FOSDEM will be held on Saturday Feb 2 and Sunday Feb 3, and Henning Dekant, the CEO of our startup Artiste-qb.net, will be attending. Henning will give a short 25 minute talk entitled “Elevating the Stack” on Sunday morning, followed by a 4 hour workshop on Sunday afternoon.

If you are interested and want to prepare, Henning will issue the following grand, in your face, challenge to the attending hackers.

IBM Qiskit already provides software that converts quantum circuits to DAGs (aka, Quantum Bayesian Networks). Can you build an engine that does the reverse, converts Quantum Bayesian Networks to quantum circuits?

Someday, we hope Quantum Fog will be able to feed qb nets to Qubiter in this way. Quantum Fog and Qubiter are 2 open source Python programs that I wrote. You think you are so smart and such a great hacker, but are you smart enough to write such a translator before we do? In your face challenge.

January 26, 2019

Quantum Computing Startups That are like the ghost of Jacob Marley in Dickens’s novel “A Christmas Carol”

Filed under: Uncategorized — rrtucci @ 8:52 pm

A Trumpian argument that I often hear from VCs interested in investing in quantum computing startups is that software-only startups like Artiste-qb.net are too risky, whereas startups that are trying to build hardware and a full software library for that hardware, are much less risky.

Huh? This is the type of illogical thinking that Trump, his MAGA supporters, and Fox News commentators often use, a type of thinking that I find totally inscrutable. It flies in the face of all available evidence and facts.

Microsoft, Google and Facebook were originally software-only companies.

Hardware is 100 times more risky and expensive to develop than software. If you are going to invest in a qc company that does hardware, you should expect, optimistically, to have to wait at least 5 years before it builds a product, and 10 years before it makes a profit. And hardware development often fails. You can’t bullshit Mother Nature. Also, you should be sure that the startup will be able to procure from all sources at least $100M investment in it’s first 5 years of operation, like Rigetti has. Otherwise, your baby startup will die of malnutrition. In contrast, software companies like Artiste-qb.net can make a profit almost from day 1, by doing non-quantum AI programming on the side.

Software companies are very nimble; they can pivot quickly, changing their business plan and product if the current one is not working. Hardware companies are tied to their hardware like Jacob Marley is to his ball and chain.

Take DWave as an example. Sorry if I get into trouble for stating the obvious, but DWave will NEVER be able to recoup the $200M+ dollars that have been invested mostly in its hardware. DWave is now trying mightily to rebrand itself as an AI services company, but how far can they run with that annealer ball and chain tied to their leg, in the very crowded AI field? It is highly questionable whether their annealer device ever showed any sufficient advantage over classical devices to make it commercially viable, and now a bumper crop of new qc companies has taken the limelight away from them. I was always supportive of Dwave to some extent; they did start the current avalanche of interest in commercial qc, for which I am grateful. But, as far as Dwave investors are concerned, it was a TOTAL loss for them.

Despite DWave’s cautionary tale, I still find a lot of VCs trying to fund the next Dwave. I won’t name names, but some of the hardware qc startups that have been funded recently seem to be following in DWave’s footsteps, except I doubt they will find as much funding. I think they will die of malnutrition. DWave got so much funding because it was the first.

Artiste-qb.net is a software-only company. This is a VIRTUE, you low IQ person who thinks otherwise. Besides, we already have a product on the market, http://www.Bayesforge.com, not just a vague promise of a product. What we need now are investors to help us ramp up the product. For these reasons, we are 1/100 times as risky an investment as a hardware qc startup.

January 25, 2019

Chinese Startup, Origin Quantum, publishes impressive software, QRunes, for hybrid classical-quantum computing

Filed under: Uncategorized — rrtucci @ 7:44 am

Check this paper out, especially if you are a VC or work for Rigetti

“QRunes: High-Level Language for Quantum-Classical Hybrid Programming”, by Zhao-Yun Chen, Guo-Ping Guo, https://arxiv.org/abs/1901.08340

The authors work for Origin Quantum. Will this company someday provide a serious alternative to Rigetti’s hybrid classical-quantum cloud service? Maybe.

Origin Quantum is a very well funded Chinese startup, based in Heifei, that is working on qc hardware and software, both. I sincerely wish them success! They remind me very much of Rigetti in that they are developing both hardware and software, plus they are strongly committed to the hybrid approach. Not as advanced as Rigetti yet, but a serious challenger. They have the formidable advantage that they will be strongly favored over American companies like Rigetti, by Chinese users. Besides, quantum computing is a marathon, not a sprint, so Rigetti’s head start might turn out to be of little value in the long run.

As you can see from reading the numerous posts in this blog, our startup Artiste-qb.net is very different from both Origin Quantum and Rigetti, although in some very specialized areas, we think we are much stronger than both of them 😎. Our crown jewel is http://www.Bayesforge.com, a collection of many popular open source softwares in a docker image that is currently available on both the Amazon and Tencent clouds. Although Artiste is incorporated in Canada and based in Toronto, one of our cofounders, Dr. Tao Yin, runs an affilate company in Shenzhen, China. Our software Qubiter is similar to QRunes in some important respects.

January 24, 2019

Qubiter (a quantum programming language) now has functional placeholders

Filed under: Uncategorized — rrtucci @ 11:04 pm

On Jan 11, just 13 days ago (by comparison, Trump’s shutdown is now 34 days old), I wrote a blog post announcing that what I call “placeholders” had been incorporated into Qubiter. Since then, my ideas about placeholders have been undergoing a Darwinian evolution culminating with an update that I uploaded today to Qubiter’s Github repo, in which I add to Qubiter, a new kind of placeholder, what I like to call “functional placeholders”. (previous types of placeholders still work). In a functional placeholder, instead of entering a numerical rotation angle \theta for a quantum gate like R_Z(\theta), one enters a string that includes a function’s name. Here is an example written in the Qubiter language. In the example, '-my_fun#2#1' is evaluated to -my_fun(#2, #1). Notice from the example that we delay deciding the value of all placeholders until the moment right before we run the simulator, at which time we enter the values of all the placeholders as an input to the simulator. That is the essence of placeholders.

January 21, 2019

Qubiter TODO/Proposal: Loop Dependent Evaluation of Placeholder Variables (quantum programming languages, loops)

Filed under: Uncategorized — rrtucci @ 7:24 pm

This article is a proposal for a feature that I think would be cool for Qubiter to have. I’m not sure that there is a pressing need or strong interest for this feature in the community of qc programmers, so I will delay adding it to Qubiter until enough people ask for it. Color me doubtful that anybody will.

So this is the plan:

Below, we will use the language that Qubiter uses in its “English Files”. That language is explained succinctly in Qubiter’s Rosetta Stone pdf document:


Qubiter already has loops implemented. The beginning of a loop called 5 with 15 repetitions is indicated in an English File by the line


and the end of loop 5 is indicated by


In fact, Qubiter already accepts loops embedded inside loops, with an arbitrary number of embeddings possible.

Qubiter already has Placeholder variables implemented too. Their usage is illustrated in the following Jupyter notebook


The plan is to combine loops and placeholder variables. Here is a simple example that conveys the potential of this plan. Suppose we have an English File that looks like this:

ROTX #1 AT 0
ROTX #2 AT 0

Then we can feed to the simulator constructor a dictionary that looks like this

var_values =
(0, _): {#1: 0.1, #2: _}
(1, _): {#1: 0.2, #2: _}
(0, 0): {#1: _, #2: 0.0}
(0, 1): {#1: _, #2: 0.1}
(0, 2): {#1: _, #2: 0.2}
(1, 0): {#1: _, #2: 0.3}
(1, 1): {#1: _, #2: 0.4}
(1, 2): {#1: _, #2: 0.5}

The `var_value` dictionary gives the values that the placeholder variables `#1` and `#2` will be assigned for each repetition of the loops. The keys of the `var_value` dictionary are a pair of numbers indicating which repetition is being serviced. The first number is the repetition index of LOOP 1, and the second number is the rep index of LOOP 2.

Update (Jan 22, 2019): I was thinking of possible applications of single and nested loops in quantum languages. Implementing the Trotter approximation, Grover’s algorithm, and the algorithm commonly referred to as QAOA, with a single loop are 3 obvious applications. Implementing the Trotter-Suzuki approximation would require not just one loop, but several nested loops. Last night, I wrote a simple jupyter notebook investigating further the implementation of Trotter-Suzuki with nested loops. Here it is


The importance of loops in quantum languages begs the question, why do they arise at all? In classical programming languages, loops embody determistic repetitive (possibly adaptive repetitive) tasks. In quantum programming languages, they embody Markov chains. Both are ubiquitous in Nature. Nested loops describe tree structures, also very common in Nature.

Update (Feb.3, 2019): I decided to do this anyway. Here is a Jupyter notebook explaining what I did


January 20, 2019

Bad Chemistry Between the 3 Quantum Chemistry Supremos

Filed under: Uncategorized — rrtucci @ 6:43 am

On Oct 2017, a year and 3 months ago, I reported in this blog on some news that was making the competition in quantum computing between Microsoft, Google and IBM, resemble, at least to me, a fierce, vicious Sea Battle between 3 avaricious sea superpowers. Think Battle of Trafalgar.

A year later, things have only gotten worse. These 3 superpowers are now engaged in what the French call a Mêlée à Trois, a truel instead of a duel, a situation that resembles the Three Kingdoms Period (220–280 A.D.) in the history of China, when China was divided into 3 kingdoms of similar size, each having an emperor who claimed that he ruled over all of China.

As an example, take a look at their war of supremacy over the use of quantum computers to do Chemistry.

Google has a qc Chemistry library called OpenFermion. To their credit, they wrote an arxiv paper on October 2017 describing it. https://arxiv.org/abs/1710.07629
Here is the header of that paper.

As you can see, the paper has more than 30 authors, and not a single one of them is from IBM or Microsoft. And if you visit the github repo for OpenFermion today, you can read a more recent list of contributors that again shows no trace of Microsoft or IBM.

Not only that, but that list of OpenFermion contributors doesn’t show the names of Matthias Troyer (Microsoft) or Aspuru-Guzik (Zapata), two famous people in the qc Chemistry world that are often included in such collaborations.

Microsoft has also written its own qc Chemistry library with no apparent help from the other 2 Kingdoms (MS did enlist the help and rely on the old software of a DOE lab situated in Washington state, the Pacific Northwest National Laboratory)

About two weeks ago, IBM released their own qc chemistry library (qiskit-chemistry) and that one, once again, shows no hint of cooperation with the other 2 Kingdoms.

When I first started writing the Python version of Qubiter, I wrote some quantum chemistry code for Qubiter, but I soon sensed that the qc Chemistry community was very political and that those people would never welcome me or my software in their midst, so I stopped writing qc Chemistry software. Knowing now what has transpired since then, I think I made the right call then! Nowadays, I like to imagine our open-source software aggregator http://www.Bayesforge.com as a carrier pigeon, or a drone that flies high above several medieval, fortified, walled cities, taking messages from one to the other. The walled cities are called Microsoft, Google, IBM, Rigetti, IonQ etc.

IBM Qiskit major update, Qubiter follows suit 2 weeks later

Filed under: Uncategorized — rrtucci @ 2:22 am

Hello my fellow quantum computerists, this is my “State of the Qubiter” address delivered from a chamber of my House of Representatives.

In case you missed it, IBM recently released a major two-fer-one improvement to their quantum computer. On Jan 2, they delivered a new Batman inspired skin for their hardware (I reported on that in this blog post). Then on Jan. 7, they done gone released some major improvements to their software. (They wrote a nice blog post here about their new software releases for Qiskit-terra and Qiskit-aqua). From that blog post, I learned that they have added NOTs with multiple controls and a function that draws an ASCII picture of the circuit. BRAGGING: I’m glad they have done this, but let me point out to potential investors in our company Artiste-qb.net that Qubiter has had those 2 features for the last 2 years or longer. In fact, I wrote a short article 10 years ago in this very blog about ASCII pictures of quantum circuits. And I have been equally vociferous in advocating the need for qc simulators that support NOTs with an arbitrary number of controls.

Another important advance in the new release of the Qiskit software is that what IBMq now calls Terra is really a Python front end to what they had before, which was a language minted by them that they called qasm 2.0, quite independent of Python, for specifying quantum circuits. Qubiter, Rigetti Pyquil, and Google Cirq have always had a Python front-end for specifying quantum circuits, so this is just IBM belatedly joining all of us. Welcome IBM, better late than never.

IBM has essentially chosen to store a quantum circuit in memory as a Python list with gates as items. This is what PyQuil and Cirq have been doing from day one. This is not, however, what Qubiter normally does. Qubiter stores the circuits in text files. Or at least, that is what it used to do. In the last week, I have added a new class to Qubiter called EngFileLineList. This class can read a Qubiter English file and store that as a list with single gates as items. The class EngFileLineList owns such a list, and it has methods for reading and writing files of the English and Picture types used by Qubiter. So now Qubiter can store quantum circuits both as files and as lists in memory. Storing the whole circuit in memory is more convenient than storing it in a file, for some purposes, but for other purposes, the opposite is true. Luckily, now Qubiter can do both.

In the last week, Qubiter has been updated in many other ways besides adding the EngFileLineList class.

We have added Placeholder Variables, as reported in this blog post. This is an extremely useful feature, especially for doing hybrid classical-quantum Noisy quantum computing. Now Qubiter, PyQuil and Cirq have this feature, but IBM Qiskit still doesn’t, as far as I can see.

I have also updated Qubiter’s translation classes that translate Qubiter to the 3 target languages PyQuil, Cirq and IBM Qiskit. They now take into account and support all the most recent changes in Qubiter and in the 3 target languages. I admit it, I love ROSA (wRite Once, Simulate Anywhere). You will love her too.

Check out Qubiter’s new jupyter notebooks illustrating its new Placeholder and translation services.



January 13, 2019

Qubiter compared with other wines

Filed under: Uncategorized — rrtucci @ 4:49 am

The following cartoon by the famous author James Thurber makes me think of Qubiter as a young upstart wine and of myself as a wine lover.

Here is a table pointing out several cool features that Qubiter already has but that the 3 other most popular quantum computer languages don’t all have. (Having a feature is indicated by a gold star). I am sure that the big 3 will eventually catch up with Qubiter, but it may take a long time because big generic software/wine manufacturers can sometimes move as slowly as molasses.


I have previously compared Qubiter with the 3 other major qc languages using analogies to sea vessels


January 11, 2019

Qubiter now has Placeholders for gate angles

Filed under: Uncategorized — rrtucci @ 5:38 am


The word “Placeholder” is used in Qubiter (we are in good company, Tensorflow uses this word in the same way) to mean a variable for which we delay/postpone assigning a numerical value (evaluating it) until a later time. In the case of Qubiter, it is useful to define gates with placeholders standing for angles. One can postpone evaluating those placeholders until one is ready to call the circuit simulator, and then pass the values of the placeholders as an argument to the simulator’s constructor. Placeholders of this type can be useful, for example, with quantum neural nets (QNNs): in some QNN algorithms, the circuit gate structure is fixed but the angles of the gates are varied many times, gradually, trying to lower a cost function each time.

This brief blog post is to announce that Qubiter now has such placeholders. Hurray! Placeholders is a nice feature that Google’s qc simulator Cirq and Rigetti’s qc simulator PyQuil, already have (they call them parametric or symbolic gates), so it has been irking me for some time that Qubiter didn’t have them too. Got to keep up with the Joneses and the Kardashians, you know.

Qubiter implements placeholders via a class called PlaceholderManager. You can already read an example of placeholder usage in the main() method at the end of that class. I also intend to write a Jupyter notebook, probably this weekend, illustrating their use.

January 10, 2019

IBM Releases 20 Qubit Commercial Quantum Computer, Code Name “batbeer tank”

Filed under: Uncategorized — rrtucci @ 6:53 pm

On Jan 8, IBM unveiled the “World’s First Integrated Quantum Computing System for Commercial Use”. Just imagine, deep down in a shadowy batcave in Yorktown Heights, New York (conveniently located next to Gotham City), in a dank, dark corner of an already dark cave, amid the otherwordly din of bat squeaks and the flapping sound of their wings, and the overpowering smell of bat urine, sits a brewing tank for producing inky black batbeer, made with mysterious black waters found in the cave. Here is what it looks like (bat beer logo by Tony Matýšek)

There is a vast amount of prior research about the scientific subject of batbeer . Here is a small fraction of such work. This list was provided to us by U.S. Supreme Court Justice Brett Kavanaugh, compiled by him during one of the rare moments when he is sober and not barfing, or lifting weights with his buddies “P.J., and Squi, and Handsy Hank, and Gang-Bang Greg” (SNL/Matt Damon verified fact) , or dutifully filling his 2019 calendar/lab notebook. You can Google the keyword “batbeer” yourself and obtain a more complete reference list.


January 5, 2019

Daphne Koller: “Use the Bayesian-Network-Force, Luke. Let Go!”

Filed under: Uncategorized — rrtucci @ 7:47 pm

Daphne Koller, Stanford Prof., writer with Nir Friedman of a monumental and ground breaking book on Bayesian Networks, inventor of the concept of Markov blankets (my favorite security blanket) and much else related to B nets, cofounder with Andrew Ng of the Coursera MOOC company, where she taught a course based on her B net book, is at it again. On May 2018, she founded the startup Insitro (home page, crunchbase page) which promises to leverage the power of Bayesian Networks for drug discovery. At artiste-qb.net, we are big advocates of applying quantum bayesian nets (invented in 1997, also the name of this 10 year old blog) to quantum computing.

January 4, 2019

A quantum computing paradox, Generalized Toffoli Gates

Filed under: Uncategorized — rrtucci @ 12:32 am

Call me Simplicio.

Let a Generalized Toffoli (GT) gate be a quantum gate, acting coherently on N+1 qubits, that rotates a target qubit subject to the state of the other N qubits acting as controls. If you calculate, with a classical computer, the effect of a GT gate on an input state vector, the larger N is, the fewer multiplications you will have to perform. On the other hand, if you expand a GT gate into a sequence of single qubit rotations and CNOTs, the minimal number of CNOTs in such an expansion will grow exponentially in N. Huh?

This paradox seems to imply that it behooves quantum computerists to find a way of implementing GT gates in their hardware in a single step, as I advocated in this previous blog post of mine.

January 3, 2019

Primo job opportunity, Quantum Computing Job at Tencent America

Filed under: Uncategorized — rrtucci @ 8:12 pm

At artiste-qb.net, we admire Tencent very much. Our Bayesforge docker image is on the Tencent cloud. See


So we want to alert our friends to the following job opening:

Senior Researcher – Quantum Computing
Company Name: Tencent America
Location: Palo Alto, CA, US

Posted 3 weeks ago


Nostradamucci Prediction for 2019: Qubit Ring Molecules and Generalized Toffoli Gates will be crucial for quantum AI

Filed under: Uncategorized — rrtucci @ 5:09 am

Nerdy, speculative blog post ahead. Better skip this one and go on to the next one. Or, if you want really speculative, stoner lit., read a Quanta Magazine article instead.

Read this at your own peril!

Blog at WordPress.com.

%d bloggers like this: