Quantum Bayesian Networks

February 15, 2019

Derivative of matrix exponential wrt each element of Matrix

Filed under: Uncategorized — rrtucci @ 1:26 am

In the quantum neural net field, in order to do backpropagation, one often wishes to take the derivative of a unitary matrix with respect to a parameter it depends on. The wonderful software PennyLane by Xanadu evaluates such derivatives using a simple formula which gives an exact answer, albeit only in special cases. Here I will discuss a simple formula that is fully general, albeit only an approximation, although reputedly a very good approximation, probably due to its symmetric nature and the smoothness of exponential functions. The method is a simple symmetric finite difference approximation.

In a StackExchange question with exactly the same title as this post, somebody called Doug suggested what he calls Higham’s “Complex Step Approximation”, to wit:

If A is a Real matrix and E_{rs} is the matrix which is 1 at position r,s and zero elsewhere,

\frac{d}{dA_{rs}}e^{A} \approx  \frac{ e^{A + ihE_{rs}} - e^{A-ihE_{rs}} }{2ih} = \frac{{\rm Im}(e^{A + ihE_{rs}})}{h}

But what if A is a Hermitian matrix and we want the derivative of exp(iA)? Here is a simple adaptation of Higham’s formula to that case.

Let E^\pm_{rs} = E_{rs} \pm E_{sr}. Note that (E^\pm_{rs})^\dagger = \pm E^\pm_{rs}.

Define a matrix M(A) by

M(A) = \left[  \begin{array}{cc} 0 &-e^{-iA}\\ e^{iA} & 0 \end{array}\right]


M(A+ih) = \left[ \begin{array}{cc} 0 &-e^{-iA+h}\\ e^{iA-h} & 0 \end{array}\right]


M(A+ih)^\dagger = \left[ \begin{array}{cc} 0 &e^{-iA-h}\\ -e^{iA+h} & 0 \end{array}\right] =-M(A-ih)

From this, one learns the following simple recipe: the effect of the dagger on M(A) is to put a minus sign in front of the M and to take the Hermitian of the argument too.


\frac{d}{d{\rm Re\;}A_{rs}}M(A) \approx \frac{ M(A + ihE^+_{rs}) - M(A-ihE^+_{rs}) }{2ih}= \frac{{\rm Re\;}[M(A + ihE^+_{rs})]}{ih}


\frac{d}{d{\rm Im\;}A_{rs}}M(A) \approx \frac{ M(A + hE^-_{rs}) - M(A-hE^-_{rs}) }{2h}= \frac{{\rm Re\;}[M(A + hE^-_{rs})]}{h}.


\frac{d}{dx}M(A) = \left[ \begin{array}{cc} 0 &-\frac{d}{dx}e^{-iA}\\ \frac{d}{dx}e^{iA} & 0 \end{array}\right] ,

it follows that

\frac{d}{dx}e^{iA} = \left[\frac{d}{dx}M(A)\right]_{10}

for x = {\rm Re\;} A_{rs}, {\rm Im\;} A_{rs}

When A is Hermitian, A_{rs} and A_{sr} = A^*_{rs} are complex conjugates so they are not independent, but the real and imaginary parts of A_{rs} are independent, so one can treat A_{rs} and A^*_{rs} as independent and do a change of variables from (A_{rs}, A^*_{rs}) to ({\rm Re}A_{rs}, {\rm Im}A_{rs}).

For discussion about this topic, in the context of quantum neural networks, see the following thread of the Pennylane discourse website

February 9, 2019

Extra, extra, read all about it! Next Toronto Quantum Computing Meetup event just announced. The speaker will be physicist and tech start-up entrepreneur Wojtek Burko

Filed under: Uncategorized — rrtucci @ 6:13 pm

The Toronto Quantum Computing Meetup is the second largest meetup in the world dedicated to quantum computing, so we claim the silver medal of Quantum Meetup Supremacy, at least for now. (currently we have 1565 Supremos as members. The biggest club is in London with a distinguished 1756 Brexiters members. We used to be the biggest, but, oh well, sic transit gloria mundi).

Those poor Brexiters. We don’t envy them one bit, or one qubit. They are in a though spot. We are so worried for them that we will soon be shipping to them a few “brexit boxes”, just in case. Just like in quantum physics, their predicament can be illustrated very well using cats. The perilous Brexit cat jump

But I digress. The main purpose of this blog post is to cordially invite you to our next meeting on Thursday, February 21, 2019. At the usual outstanding venue, Rotman School, Univ. of Toronto. Our speaker is quite impressive. I will just quote the writeup:

We are delighted to have physicist and tech start-up entrepreneur Wojtek Burko to talk about the challenges to build a venture based on the current state of the art in quantum computing.

Wojtek not only co-funded Beit.tech and succeeded in making it cash-flow positive in less than a year, but also co-launched the Bitspiration Booster VC practice, which invests in and incubates deep tech start-ups.

Before that he served as Engineering Director at Google until 2014, Chief Technology Officer at Allegro until 2015, entrepreneur, mentor, advisor, angel investor; member of the Board in several start-ups incl. EGZOTech, JAM Vehicles, Airly; chairman of the Board at ASPIRE – representing the multinational corporate scene in Poland.

Microsoft reacquires ProjectQ

Filed under: Uncategorized — rrtucci @ 9:03 am

Huawei is a major Chinese company that produces smart phones, telecommunications equipment used in 5G, etc. This company has been much in the news recently because the founder’s daughter, Meng Wanzhou, who is also the CFO of the company, was arrested at the airport in Vancouver, Canada, at the request of the US government.

As far as the subject of quantum computing is concerned, on Oct 12, 2018, Huawei promised in a conference and accompanying press release, that it would soon provide a quantum computing cloud service named HiQ. As far as I know, HiQ hasn’t been opened yet to the general public. I have searched in vain for it on the internet. According to the press release, “Huawei also showcased its quantum programming framework for the first time, which is compatible with the ProjectQ.” As you can see by the two linkedin screenshots below (slightly cropped to omit my personal info), Huawei was employing, at the time of the press release, the two authors of projectQ, Haner and Steiger, whose thesis advisor at ETH Zurich was Matthias Troyer, a Microsoft star employee.

Seems like Haner and Steiger duped Huawei, they only stayed with Huawei for 3 months, while they were secretly looking for a job at Microsoft. They were hired in the last 1-2 months as Senior Quantum Computing Researchers by Microsoft. So ProjectQ was owned by Huawei for just 3 months and is now back in the hands of the evil empire Microsoft.

Huawei and China must feel “slightly” disrespected by Microsoft for hiring those two. What if the Chinese government bans Azure from China for this slight and for the arrest of Huawei’s founder’s daughter? And what about ProjectQ versus Q#? Does this mean, if we read the tea leaves, that ProjectQ/Troyer is back again in the ascendancy at Microsoft and Q#/Krysta is in the decline? It’s like a power struggle inside the Third Reich of Microsoft

February 8, 2019

Quantum Complexity Theory for Fish

Filed under: Uncategorized — rrtucci @ 6:29 am

(This graphic was inspired by a slide in a talk by John Preskill. His version makes no allusion to sea or fish. It just uses Venn diagrams)

February 4, 2019

Translating Between Quantum Programming Languages, The Importance of Being Qubiter

Filed under: Uncategorized — rrtucci @ 7:05 am

The United Nations has 6 official languages: English, French, Spanish, Chinese, Russian and Arabic. I think the more languages you learn, the smarter you become. Don’t you?

Qubiter, a computer program/quantum programming language that I wrote, can translate from itself to the 3 most popular quantum languages that currently have a hardware backend: IBM Qiskit, Rigetti Pyquil, and Google Cirq. Here is a Jupyter notebook illustrating this feature of Qubiter.


I’ve recently noticed that others, both in Academia and in Industry, are attempting to write their own translators between quantum languages, so there seems to be a lot of interest out there for this sort of thing. Many quantum computerists are interested in running the same quantum program side by side on the 3 hardware devices just mentioned (and others soon to come) to compare performance and final results, a worthy scientific goal.

I want to argue briefly here that Qubiter does it better 😎

Qubiter has ALL the features that each of the big 3 quantum programming languages has and then some. This makes it the most expressive tool in town. You get a more succinct, efficient translation if you using a more expressive computer language to express a command in a less expressive one. For example, if you

use more expressive to express less expressive,
less expressive -> more expressive
you might find
10 lines of code -> 10 lines of code,

whereas if you go in the opposite direction,

use less expressive to express more expressive,
more expressive -> less expressive
you might find
10 lines of code -> 30 lines of code,

because you are “trying to reinvent the wheel” in the second case.

So if Qubiter is to maintain its edge as a translator of quantum programming languages, it must always try to surpass all the other languages in expressiveness. This is what I have done so far and will try to do in the future. (For example, I recently added to Qubiter, placeholders and loops at the English file level. And take a look at the feature comparison table that I gave in a previous, recent blog post).

February 3, 2019

My Mini-Talk in absentia for FOSDEM 2019 Feb 2-3 (this weekend)

Filed under: Uncategorized — rrtucci @ 1:19 am

As I mentioned in the previous blog post, Henning Dekant, CEO of our startup Artiste-qb.net, will be speaking for our company at FOSDEM 2019 this weekend. I can’t be there so I prepared a mini-talk to be delivered long distance, via the old fashioned internet, as opposed to that new fangled technique that some are calling tête à tête. Henning is speaking mainly about Quantum Fog and Bayesian networks so I made my mini talk about a different topic; it’s a progress report on Qubiter, about the fact that Qubiter now supports Placeholders and loops at the English file level. Here is my mini-talk:


its front page:

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.

« Previous PageNext Page »

Blog at WordPress.com.

%d bloggers like this: