This week's book giveaway is in the Reactive Progamming forum. We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line! See this thread for details.
I saw a few books being published or awaiting publication on quantum computing (QC) using current languages like Java and Python. Are the code and the algorithms in those books some sort of emulation of how QC might be achieved on an actual quantum computer? If so, I tend intuitively to think the speed might not be the same... Am I right?
In other words, I'm trying to make sense of QC and QC algorithms being implemented and run on a non-quantum computer...
I think, for the near future, QCs will not be computers which run a certain programming language. They should be thought of to be more like a certain hardware device, where you can write and read data (numbers) to/from certain channels. This shouldn't be a matter of the used language, which is run on an assisting classical (deterministic) computer.
Emulating such a hardware device is a pretty good thing to proof concepts (algorithms), but not to get productive results. If emulation would be fast enough, we wouldn't need QC at all...
I expect, that it's especially pretty difficult (tricky?) to simulate the superposition state - I wonder how they do that...
Jean-François Morin wrote:Are the code and the algorithms in those books some sort of emulation of how QC might be achieved on an actual quantum computer?
Yes, exactly. There are several ways to simulate a QC on a classical computer, depending on the desired result.
State Vector Simulation is the most common: reading ("measuring") one qubit produces one bit, so the sim must track the probability of each possible value which can be read from your qubits. For example, an 8-bit number can have 256 possible values, so the sim internally keeps track of all 256 "terms". These probabilities aren't just 0%-100%, they're complex numbers, which means each one is a floating-point 2D vector. In our book, we draw these 2D vectors using "circle notation" (see below) which is something I came up with more than a decade ago, as a way of building my own intuitive understanding.
Density Operator Simulation is like state vector sim, but with more detail. To do this you have to square the number of circles required. So for 8 qubits, instead of 256 circles you need 256*256=65,536 circles.
Stabilizer Simulation is much faster, and requires much less memory (O(n) instead of O(2^n)), but it can only simulate a very small number of quantum operations.
Physical Simulation is where the actual physical hardware is simulated in as much detail as possible. It's like simulating the transistors and capacitors of a digital computer, instead of just the bits and bytes. This may involve FDTD photon propagation using Maxwell's equations, or some other form of detailed physical dynamics. These simulations are typically used by teams building the QPUs, not using them. These sims are very time and resource intensive, and only very simple systems can be simulated.
Jean-François Morin wrote:If so, I tend intuitively to think the speed might not be the same... Am I right?
Frank Röber wrote:If emulation would be fast enough, we wouldn't need QC at all...
You are both exactly correct.
sometimes much faster: For a state vector sim of small quantum states (4 qubits = 16 terms = 256 bytes of RAM), a digital computer's manipulation of the state vector is much faster than a present-day quantum computer can operate. In fact, up to about 26 qubits, simulations can easily be done in a browser, even on a mobile phone.
sometimes much slower: For a state vector sim of bigger quantum states (40 qubits = 1.1 trillion terms = 16 terabytes of RAM), a digital computer's manipulation of the state vector is much slower than a present-day quantum computer can operate. Alternatively, a physical simulation of even a simple system may take weeks to complete a sim of a few nanoseconds of the device's activity.
sometimes impossible: For a state vector sim of a medium-sized near-future QC (200 qubits = 1.6x10^60 terms = 2.4x10^52 GB of RAM, which is more RAM than will ever exist on Earth, which has only about 10^80 atoms total), the simulation can never be done on digital computers as we currently know them.
There are some techniques to do approximate simulations of up to 70 qubits or so, but these are rough and require supercomputers to run.
Jean-François Morin wrote:In other words, I'm trying to make sense of QC and QC algorithms being implemented and run on a non-quantum computer...
Frank Röber wrote:I expect, that it's especially pretty difficult (tricky?) to simulate the superposition state - I wonder how they do that...
You'll be surprised to learn that the simulation itself is not complicated at all. It's simple enough to understand visually, and even do simple cases in your head or on paper. We use this in the book and it works really well. Using one circle to represent each term in a state vector, many QPU operations are easy to visualize.
For example, the book's explanation of the NOT (also called an X-gate) on a quantum superposition of values looks like a simple swap of the values:
As the state vectors get larger, we exaggerate the phase markings and colors, to make patterns easier to spot:
Doing it without a computer at all: In 2000, I wrote a whitepaper describing a way to do QC simulation with a pen and paper, which is not that useful but very fun. I still use this to work out details of some QPU programs while I'm sitting on the beach or in the park instead of in front of a screen.
The most recent version of this can be found here.