since Sep 17, 2019

Eric Johnston ("EJ") is a co-author of Programming Quantum Computers from O'Reilly Media, and also an acrobat and competitive gymnast.

As an engineer, EJ values surprise and whimsy above all other things. He studied Electrical Engineering and Computer Science at U. C. Berkeley, and worked as a researcher in Quantum Engineering at the University of Bristol Centre for Quantum Photonics.

EJ worked at Lucasfilm for two decades as a software engineer for video games and movie effects, along with occasional motion-capture stunt performance.

Fun links: siggraph-talk / gears / gymnast-outtakes / my-instructables

As an engineer, EJ values surprise and whimsy above all other things. He studied Electrical Engineering and Computer Science at U. C. Berkeley, and worked as a researcher in Quantum Engineering at the University of Bristol Centre for Quantum Photonics.

EJ worked at Lucasfilm for two decades as a software engineer for video games and movie effects, along with occasional motion-capture stunt performance.

Fun links: siggraph-talk / gears / gymnast-outtakes / my-instructables

Boston and San Francisco

Cows and Likes

Cows

Total received

11

In last 30 days

0

Total given

0

Likes

Total received

6

Received in last 30 days

0

Total given

0

Given in last 30 days

0

Forums and Threads

Scavenger Hunt

Ranch Hand Scavenger Hunt

Greenhorn Scavenger Hunt

Hi Frank! This is a great question; the answer is sometimes simple and sometimes baffling.

I agree that this is useful. Considering a fault-tolerant QPU lets you focus on the issue, not the noise. And we'll have those soon enough. Here's a link to the company I work for, which is building one such device.

My statistics is also patchy, but if you know there's one correct answer, and a 98% chance of getting the right answer with one run, then there's a 1.0 - 0.02*0.02 = 99.96% chance that at least one of two runs will be correct. So that's also about the probability (seat-of-the-pants leap of logic here, someone please correct me) that if you do see two identical results, the answer you see is correct.

**However** there's a big (huge) help when it comes to many common algorithms: I's often hard to find the answer, but easy to verify it. For example, in the **Shor** chapter of the octopus book, the program produces factors of a number, so simple multiplication will tell you whether or not you need to re-run it.

In Figure 10-8 of the**Quantum Search** chapter you can also check the answer, but doing so requires possibly getting eaten by a tiger.

Both. For example, when using the IBM 5Q (as in the**Quantum Teleportation** chapter of the octopus book) you can specify a number of runs, and it will aggregate the results for you (see Figure 4.5). If you need to modify the program based on output from each previous run, then you'll need to run them one at a time.

Frank Röber wrote: For the following, let's ignore the noise of real existing systems. Im talking of an ideally QPU.

I agree that this is useful. Considering a fault-tolerant QPU lets you focus on the issue, not the noise. And we'll have those soon enough. Here's a link to the company I work for, which is building one such device.

Frank Röber wrote:For the following, let's ignore the noise of real existing systems. Im talking of an ideally QPU.

If Iknowthere is only one result, the candidate should be clear after let#s say 10 cycles. But this is just a feeling, I cannot evaluate the error rate.

If there're two expected results (e.g. root-finding like Newton), how many cycles would I need to become confident about the result? It gets worse if there are more roots I didn't expect...

My statistics is also patchy, but if you know there's one correct answer, and a 98% chance of getting the right answer with one run, then there's a 1.0 - 0.02*0.02 = 99.96% chance that at least one of two runs will be correct. So that's also about the probability (seat-of-the-pants leap of logic here, someone please correct me) that if you do see two identical results, the answer you see is correct.

In Figure 10-8 of the

Frank Röber wrote:As a QPU programmer, will I have to code that cycles explicitly or is this hidden by the device?

Both. For example, when using the IBM 5Q (as in the

2 years ago

Himai Minh wrote:Hi, Eric Johnson,

Would you be interested to be our next speaker of Washington DC quantum computing meetup group to talk about your new book?

If you are in DC, our group will meet up at Cambridge Quantum Computing office.

If you are not in DC, we can have online event via Brighttalk or Zoom or etc.

Thanks.

Hi Himai,

Thanks for this offer! I need to run it by my employer (so many IP issues just means we're thorough about these things). When you have a chance, please send info regarding the meetup to moosemeet@machinelevel.com

Cheers,

- ej

2 years ago

Hi Chris! Good to hear from you.

There are several "quantum internet" projects underway, and it's a hot topic of research. There are even satellite-based qubit transmission projects. One of the big challenges is that you need to send single photons (or qubits, anyway), and cannot use repeaters. That's the catch; anything which amplifies the signal will crush the quantum state, rendering it useless. The type of repeater normally considered for things like quantum encryption is a "trusted node" (basically a manned military bunker) which decrypts the data and then re-encrypts it.

As a specific answer to your questions, here are some guesses from me.

**Note that nothing here claims there will be FTL communication.** :]

**A Completely Made-up Timeline of Home QPU Technology:**

**When:** Today

**Home hardware:** Internet-connected PC

**Neat things you might be able to do**: Classical communication with a computer which controls a QPU. This allows you to write programs, execute them, and receive results. You can do this today, using the book sample code and the IBM Q Experience. This will also allow your mobile phone to transparently make use of QPUs without you realizing it. QRNG (quantum random number generation) which is neat, but pretty basic for a quantum computer.

**When:** Soonish

**Home hardware:** Optical fiber output (no input) port on your laptop or router, capable of sending 6 different raw single-qubit states (requires premium internet fiber package with extra sports channels)

**Neat things you might be able to do**: Ability to perform QKD-based quantum encryption. Ability to perform BQC (blind quantum computation) on a remote QPU, which is where the remote QPU does not know what operations you've asked it to run, and runs them anyway. This is a type of security which doesn't make sense on classical computers. A bunch of other QPU applications and experiments cooler than just digital-in/digital-out computation.

**When:** Also soonish

**Home hardware:** Hardware upgrade to optical fiber output (no input) port on your laptop or router with a mini-QPU which can generate, entangle, and measure arbitrarily rotated raw photonic qubits.

**Neat things you might be able to do**: Bi-directional quantum teleportation. Not sure why this is useful outside of a laboratory setting. Qubits may be stored in a spool of optical fiber, for a couple of nanoseconds per foot of fiber. Also enables all-local QRNG, so you can add a whole new level of randomness to your daily life.

**When:** Not as soon

**Home hardware:** Optical fiber bidirectional I/O port on your laptop or router, with a mini-QPU which can generate, entangle, and measure raw photonic qubits.

**Neat things you might be able to do**: Ability to function peer-to-peer, without a server-side QPU.

**When:** Even less soon

**Home hardware:** 1K-qubyte Fault-tolerant QPU the size of a desk, connected to laptop via digital and optical ports. $70k or so.

**Neat things you might be able to do**: Full-on QPU mayhem in the home.

**When:** 22 years after that

**Home hardware:** 1M-qubyte Fault-tolerant QPU inside your phone.

**Neat things you might be able to do**: No idea what this is for. Selfies maybe?

Note that the moment one of the readers of our book has an unexpected insight and invents the*Best QPU Application Ever™️*, then this table will require revision.

Maybe shape-shifting materials, doors with no hinges, or something from Diamond Age?

There are several "quantum internet" projects underway, and it's a hot topic of research. There are even satellite-based qubit transmission projects. One of the big challenges is that you need to send single photons (or qubits, anyway), and cannot use repeaters. That's the catch; anything which amplifies the signal will crush the quantum state, rendering it useless. The type of repeater normally considered for things like quantum encryption is a "trusted node" (basically a manned military bunker) which decrypts the data and then re-encrypts it.

As a specific answer to your questions, here are some guesses from me.

Note that the moment one of the readers of our book has an unexpected insight and invents the

Maybe shape-shifting materials, doors with no hinges, or something from Diamond Age?

2 years ago

Liutauras Vilda wrote:Thank you for answering questions. It has been a very active week for this book.

It's been a pleasure! Thank you all for a very fun discussion. :]

2 years ago

Campbell Ritchie wrote:So that Bristol encryption card would send all possible passwords and some way to work out which the correct password is? Also, if anybody snooped the password

in transit, would it become obvious immediately at the other end and allow us to repeat the encryption process?

Ah, nope. This card device implements something called QKD (Quantum Key Distribution).

There's a demo of this in chapter 2 in the book, in the

Here's how it works:

...so with QKD, no data of value is sent via the quantum channel at all.

2 years ago

Claude Moore wrote:

Well, one could argue that from a practical point of view, being able to train a model in a few microseconds would be the same as loading it from a persistent storage, wouldn't it be?

If the "trained" structure is qubit-based, then it can't be loaded, as loading involves making a copy of what's in the persistent storage. You could keep

If the "trained" structure is digital data and not qubits then yep, loading it will work.

There's a middle ground: As covered in chapter 9 in the book, one form of QRAM (quantum memory) is digital data which may be accessed in superposition (so you can load from multiple addresses at once into qubit registers). If this is used to store the trained structure, then loading will also work.

...so it depends on the design of your ML system.

2 years ago

Claude Moore wrote:Thanks a lot for your detailed answer. I am very excited about what you said about the superscalar speed up you can achieve on algorithms using QC:l can't stop thinking about what we could achieve in the field of Neural networks, and in AI in general...

There's an interesting aspect concerning AI which hasn't really been dealt with yet: Qubits can't be copied. They can be moved and transformed, but there's physically no way to duplicate even one.

So...

Thanks to Nic, Chapter 13 in the book covers Quantum Machine Learning!

It's all very early and experimental; QML systems in the near future will be trained in a few microseconds, use the knowledge, and lose it all a few microseconds later.

2 years ago

Michael Krimgen wrote:However, do you see any applications of the concepts of QC algorithms in other areas like concurrent programming?

Hi Michael,

The tricky thing about treating QC like classical forms of concurrency or parallelism is this: when you do things in parallel on a CPU, more work is done and you're able to save all of the results.

On a QPU, it's a bit different. When you execute multiple tasks in superposition, you can't get all of the results, but you can get things like the sum, or the average, or the parity. In general, the total

The best illustration of this is known as the Deutsch-Jozsa problem.

Here's (loosely) how it goes:

Imagine you have a function which takes in one bit (0 or 1) and puts out one bit (0 or 1).

The function takes an hour to run. Using it, you answer two questions:

Using a QPU function, you can run both in superposition. It runs all values simultaneously in a single run, and then you can transform the output to answer

(This is explained a bit better by Mercedes in chapter 14, and there's an accompanying code sample here.)

...so if someone tells you a QPU can "play all possible chess games at once" that's

2 years ago

Jay Ko wrote:I don't know anything about quantum computing, but as I read some of posts, it is not 0 and 1.(If it is wrong, please point out)

Then, do I need new computer in order to quantum computing?

If no, should I have to new OS?

Thanks!

Hi Jay, thanks for posting your question!

The first time you use a QC, you probably won't even know you've done it. Currently, when you use your phone's Maps app to plan a drive from LA to New York, it only takes a few seconds, which is amazing. It's fast because the route planning isn't actually done on your phone. It happens on a computer you never had to buy, in a server room in a building you've never had to think about. Similarly, the first useful QPUs will be in server rooms, performing computation (maybe even road trip planning) for people. They'll just get specific types of jobs done, more efficiently than a normal computer would have.

When you use an ATM, the transaction may be secured by a pair of QCs, just to combat hackers and increase security. At the University of Bristol in the UK, there's even a project where they've taken a quantum device and embedded it

Eventually, computers, tablets, and phones that you buy will have QPUs build into them (just as they currently have GPUs for graphics), but they'll likely use updated versions of the same operating systems we use now.

2 years ago

Hi Paul! Thanks for this question.

Looking forward to QPUs (quantum processing units) becoming "mainstream", the critical thing to watch is not the number of qubits, but the number of*fault-tolerant* qubits. This is what separates a mainstream QPU from an advanced science experiment. To illustrate, I'll use Mainak's example...

I really like this example.

**Imagine it's 1950**, and you're trying to implement a calculator using a "digital electronic computer" which is new and exciting. It's a big advanced model, so it has 64 bits of RAM. So you've got 8 bytes to work with. Is that enough to implement a calculator? For sure, if just a simple one. You can increment, add, divide-by-2 by bit-shifting, it'll be a fun project. **But then** you find out that the eight bytes aren't error-corrected or fault-tolerant. You can clear a register to zero, but as the next instructions execute some of the bits start losing their values, and after about 40 instructions it's gone completely random. Suddenly, making a useful calculator becomes a lot more difficult, so this computer might not be ready to be a "mainstream" product.

**In 2019**, the current state of the art in QC is 50-72 raw (non-FT) qubits, which is challenging (not impossible) to build a quantum calculator with.

...so it's really the number of FT qubits we need to watch when deciding when something will be mainstream. These are coming, but it's hard to peg a date until we can see them working.

Still, we can simulate FT Qubits with no problem:

In the book, chapter 5 (right near the beginning) contains everything you need to implement and simulate a calculator on a QPU using very few qubits. Basic math functions which work in quantum superposition are specified and demonstrated, with code samples that run in one click.

For example, Example 5-3 shows how to implement "a = a + b * b" in quantum superposition, and you can run it right now, on the**sample code** page.

This simple example can also be run for free on a physical QC, since the page contains Qiskit and OpenQASM versions. If you do that, you'll notice that non-FT qubits get really fuzzy.

Looking forward to QPUs (quantum processing units) becoming "mainstream", the critical thing to watch is not the number of qubits, but the number of

Mainak Biswas wrote:Authors - how many qubits would be required to do create say a calculator?

I really like this example.

...so it's really the number of FT qubits we need to watch when deciding when something will be mainstream. These are coming, but it's hard to peg a date until we can see them working.

Still, we can simulate FT Qubits with no problem:

In the book, chapter 5 (right near the beginning) contains everything you need to implement and simulate a calculator on a QPU using very few qubits. Basic math functions which work in quantum superposition are specified and demonstrated, with code samples that run in one click.

For example, Example 5-3 shows how to implement "a = a + b * b" in quantum superposition, and you can run it right now, on the

This simple example can also be run for free on a physical QC, since the page contains Qiskit and OpenQASM versions. If you do that, you'll notice that non-FT qubits get really fuzzy.

2 years ago

Roger Yates wrote:‘what language is/can be used to develop these native libraries for QPUs? Is this more assembly-like or are there already compilers for higher level abstractions?’

Hi Roger,

As you mention per the other Java thread, code to use the libraries can be developed in any language.

To develop the libraries themselves, it depends on whether you're doing...

2 years ago

Claude Moore wrote:In the authors' opinion, do they think that we need to redefine concepts we used to use in traditional informatics, for example the Turing Machine model, Big O complexity notation and so on, or the same will still be valid to study algorithms from a theorical point of view?

Hi Claude! Great question.

Nope, all of the information theory concepts you're mentioning still apply, exactly as they always have. The only thing QCs change is which operations can be done efficiently.

2 years ago

HI Jean-François!

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.

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.

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**.

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.

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.

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

As the state vectors get larger, we exaggerate the phase markings and colors, to make patterns easier to spot:

The most recent version of this can be found

2 years ago

David Sachdev wrote:Does your book go into what and why there are algorithms exclusive to Quantum computing? Does it have information on if it is the speed of quantum computing, the nature of it, or other reasons that the algorithms are targeted at the platform. Also, it seems more and more that algorithms aren't taught, but people are introduced to libraries where the low level algorithms are presented.

Hi David, thanks for these questions! Based on these, I think you'll really like the structure of our book. We dive straight into the quantum-specific algorithms such as QFT, Grover, Phase estimation, etc. We present them as library functions, and then go into detail about specifically what they're made of, why they work, and what aspects of a QPU (quantum processing unit) make it suited to them. Then, we take these functions and use them to construct higher-level applications, such as Logical search, Shor, and Quantum Supersampling.

By building it up in this way, we hope to convey not just a top-level understanding of what the functions are called, but what they actually do under the hood, so that readers can think about building primitives and applications of their own.

David Sachdev wrote:What are the languages and platforms that are leading the way when it comes to Quantum computing?

The QPU libraries themselves are accessible from a variety of languages. For example, the book sample code has versions which run in Python, JavaScript, C# and OpenQASM. But really if you have a QPU simulator or a physical QPU, the library functions are likely to be accessible through other languages as well (just as libraries for GPUs are).

2 years ago