Note: this post is part of my series, Programming the Multiverse

The Bernstein–Vazirani oracle is a toy problem that starts to show how certain problems can be solved faster with quantum computers than classical algorithms.

The BernVaz Oracle

The BernVaz oracle is like a black box that can have at least 2 inputs and an equal number of outputs. In our example we’ll have 4 inputs. The goal is to guess a secret pattern that is encoded in the oracle.

The first 3 inputs, labeled \(q_0\) through \(q_2\), are inputs where you can feed your guesses of a 0 or a 1. The outputs corresponding to each guess input do not change the value, they simply echo back your input.

The last input, \(q_3\), is a status signal. If you correctly guess that any one of the wires is a 1, whatever value you feed into the status input will get flipped in a NOT operation. If you correctly guess a 0 on any of the inputs, \(q_3\) will not change. If you incorrectly guess a 0, \(q_3\) will also remain unchanged.

Here’s a sample for an incorrect guess:

Here’s a sample for correct guess:

A sample for a partially correct guess (note that the oracle doesn’t tell you whether you’re partially correct or totally correct):

And finally, a sample where we fully guess a code containing multiple ones:

Note that in the above example that the status input, \(q_3\) gets flipped twice.

How we would implement such an oracle

How would we implement this oracle? You may have already guessed that this involves some CNOTs. Basically we implement this by CNOTing every guess input with the status input when the secret value for the input is a 1. Here’s an example for an encoded value of \(011\):

The code for this is here.

The hulk-smash way of solving the oracle

A classical computer is limited to solving this the “hulk smash” way - that is, a brute force approach. Just like if the Hulk were to break into a building by smashing down a wall.

Image credit: serbiandude via Deviantart

We would have to guess a 1 for each input, one by one, to get an answer.

First guess:

This tells us that the first number is a 0 because our status input did not get flipped.

Second guess:

This tells us that the second number is a 1 because our status input did get flipped.

Third guess:

Similarly, this tells us that the third number is a 1 because our status input got flipped.

You can see that for larger oracles, we need more and more guesses. In fact, it’s a \(O(n)\) solution (for those familiar with big-Oh notation). In other words, the time taken to solve this increases at a linear rate with the increase in length of the secret code.

If this secret code was used as a password for a system, you could chose a password that’s 3 trillion bits long, which would take the world’s currently most powerful supercomputer a year to crack doing 1,700 petaflops per second.

The quantum ninja way of solving the oracle

Our new quantum computer, however, is like a ninja who is everywhere all at once and can sneak its way into any building.

Since we know how any oracle can be constructed using CNOTs, we can devise a special quantum algorithm to solve any BernVaz oracle:

• Each input is a qubit in superposition
• The status qubit is initialized to \(\ket{1}\) before putting it into superposition
• We use the H gate again on the outputs to bring every qubit back out of superposition

The python code to construct this circuit is here.

For this exercise, we’ll use a feature of Qiskit to build our own custom quantum gate that represents the BernVaz oracle. We define a function that returns a randomly-generated secret code along with the gate itself.

def create_random_oracle():
  # generate a 3-item array of random zeros and ones
  secret_code = random.randint(2, size=3)

  bv_circuit = QuantumCircuit(4, name="BernVaz\nOracle\n#{}".format(secret_code))

  # loop through each digit of our secret code and CNOT the appropriate
  # code qubit with the status qubit
  idx = 0
  for idx, digit in enumerate(secret_code):
    if digit == 1:
      bv_circuit.cx(idx, 3)

  # create our custom gate
  bern_vaz_oracle = bv_circuit.to_instruction()

  return [secret_code, bern_vaz_oracle]

We can then plug the oracle into our larger circuit

q = QuantumRegister(4, 'q')
c = ClassicalRegister(4, 'c')
qc = QuantumCircuit(q, c)

# put our input qubits into superposition
qc.h(0)
qc.h(1)
qc.h(2)

qc.x(3) # initialize the status qubit to |1>
qc.h(3)

secret_code, oracle = create_random_oracle()

# hook the custom gate into qubits 0-3
qc.append(oracle, [0,1,2,3])

# take the outputs out of superposition
qc.h(0)
qc.h(1)
qc.h(2)
qc.h(3)

qc.measure(0, 0)
qc.measure(1, 1)
qc.measure(2, 2)
qc.measure(3, 3)

Next we run the whole circuit through the Qasm simulator, which simulates an “ideal” quantum computer.

simulator = Aer.get_backend('qasm_simulator')
result = simulator.run(transpile(qc.reverse_bits(), simulator)).result()

This gives us the following output:

{'0111': 1024}

When we run the simulator, the simulator returns a python dictionary where each key represents a string of classical bits we got when we measured each qubit. The value associated with the key is the number of runs that resulted in that string. This is because the computer runs the simulation 1,024 times by default (more on this another time).

So yeah, our quantum computer just instantly solved the oracle!!

So how did this work?

Because we knew this oracle was implemented using CNOTs, we knew that we could use phase kickback to get the answer.

When a qubit maps to a \(\ket{0}\) value, it does not go through a CNOT. Therefore, the qubit is untouched by any other qubit. It effectively travels through two H gates:

The qubit, initialized to \(\ket{0}\) returns to the \(\ket{0}\) state.

When a qubit maps to a \(\ket{1}\), this qubit is used as a control on the CNOT. The target is initialized to \(\ket{1}\) and put into superposition. Let’s look at the matrix math happening just for a single code qubit and the status qubit, which is a simple CNOT:

Our matrix multiplication for this circuit is:

The state vector going into the CNOT is:

This means we have a 25% chance of each combination of qubits but that the phase is negative whenever \(q_1 = \ket{1}\).

After the CNOT, the state vector becomes:

The CNOT kicked the negative phase back up to the control qubit.

The key here is that when the negative phase is kicked back to \(q_0\), its individual state is \(q_0 = \frac{1}{\sqrt{2}}\ket{0} - \frac{1}{\sqrt{2}}\ket{1}\). This means when we apply the H gate to it, we have the following:

The negative phase of \(q_0\) caused the H gate to behave in an interesting way - it turns a qubit in superposition with negative phase into a \(\ket{1}\). We’ll cover what’s going on behind the scenes later but for now we were able to “hack” our H gate to help us!

Note: this post is part of my series, Programming the Multiverse

We’ve looked at the internals of a couple gates but let’s dive into the Hadamard gate. Here is its internal magic matrix:

Wait, what’s up with that negative \(\frac{1}{\sqrt{2}}\)?!

Remember our qubit in the \(\ket{0}\) state, represented by \(1\ket{0} + 0\ket{1}\). If we put it through the H gate, we get:

Note: the \(\frac{1}{\sqrt{2}}\) in front of the matrix is a shortcut for having to write the fraction four times inside the matrix. It’s a distributive multiplication on all the items.

Now let’s feed it a qubit in the \(\ket{1}\) state, represented by \(0\ket{0} + 1\ket{1}\).

So this means we have a qubit in this state: \(\frac{1}{\sqrt{2}}\ket{0} - \frac{1}{\sqrt{2}}\ket{1}\) or generalized as \(a\ket{0} - b\ket{1}\). That negative b indicates a negative phase.

A new dimension

Earlier I mentioned that a qubit is like a spinning die where you might decide a roll of 1 through 3 represents a classical bit equal to 0 and a roll of 4 through 6 represents a classical bit equal to 1.

Phase is like each die having a color you can control with a dial. You can spin the dial to cycle through an infinite number of shades. Phase does not directly affect the probability of whether the qubit is a \(\ket{0}\) or a \(\ket{1}\). But you can use the phase for various tricks.

When we have a negative phase, it’s not setting the phase to a negative numeric value, but it is saying “the phase of your qubit has an opposite phase value compared to the global phase that all the qubits started out in.” We’ll see later that putting two qubits with opposite phase through certain gates causes certain \(\ket{0}\) and \(\ket{1}\) combinations to cancel out.

If you look at the color wheel, you can think of qubits with opposite phase having complementary colors on the color wheel. Complementary colors look good next to each other but combining them results in a yucky brownish color. Other color combinations mix better to form new colors.

Getting kickbacks

Our first trick using phase is called phase kickback. This phenomenon applies to “controlled” gates like the CNOT. Let’s see how it works.

In order for the kickback to happen, the phase of the target qubit has to be negative. Its phase then gets transferred or “kicked back” up to the control qubit when the gate is applied.

Let’s create a circuit that does just that. To start out, we need both our qubits initialized to \(\ket{1}\) and we need to get our target into a negative phase (yes we’ll turn our qubit into a goth kid). We’ll use our handy H gate for that. By running this circuit we’ll copy the negative phase of \(q_1\) into \(q_0\).

Here’s the code to generate the above circuit:

from qiskit import QuantumCircuit, QuantumRegister, ClassicalRegister
from qiskit_aer import Aer
from qiskit.visualization import array_to_latex

q = QuantumRegister(2, 'q')
c = ClassicalRegister(2, 'c')
qc = QuantumCircuit(q, c)

qc.x(0)
qc.x(1)
qc.h(1)
qc.cx(0,1)

You can view the code for this part here.

Let’s use Qiskit’s statevector output to see what \(q_0\) and \(q_1\) look like after applying the gates:

from qiskit.quantum_info import Statevector

Statevector(qc).draw('latex')

When we examine our resulting state vector, we see:

IMPORTANT: Qiskit does something really weird that’s important to know - it reverses the order of the qubits when it prints statevectors and run results. So where all the mathematical literature uses \(\ket{q_0 q_1}\), Qiskit displays \(\ket{q_1 q_0}\). They claim it’s because they consider \(q_n\) the most significant bit when you use qubits to represent binary numbers, but I think they’re really just trolling people. If you want to output it in conventional order you can use:

Statevector(qc.reverse_bits()).draw('latex')

So \(- \frac{\sqrt{2}}{2} \ket{01} + \frac{\sqrt{2}}{2} \ket{11}\) respresents the probabilities of the combined states of \(q_0\) and \(q_1\). Remembering that we square the probability amplitudes to get our probabilities of each state, we get a 50% chance where \(q_0 = -\ket{1}\) and \(q_1 = -\ket{0}\). This means our CNOT flipped \(q_1\) from \(\ket{1}\) to \(\ket{0}\) but \(q_1\)’s negative phase going into the gate got copied up to \(q_0\). Rad!

So what’s actually going on in the land of matrices?

In this post we let Qiskit/python do all the matrix math here, but it’s interesting and useful to show how you would actually use matrix multiplication to represent what just happend.

A quick look at how to calculate multiple gate operations

Previously, in part 4, we multiplied a single qubit’s state vector times a single gate matrix. In order to work with a gate that operates on multiple qubits, we did some simple tensor products on the qubits’ individual state vectors to generate a combined state vector.

But now that we have multiple gates in a row, we have to do some more tricks. We have to do a dot product between the series of gates and the state vector. Let’s see how this works for two SWAP gates in a row:

When we have gates in series, we do a dot product of each gate’s matrices in reverse order and we multiply them by the initial state vector which is always the last item in the equation. For our example, let’s say \(q_1 = \ket{1}\).

We’ll start by multiplying the initial state by SWAP 1. We now get:

Notice that our statevector represents \(\ket{10}\). Finally, finish multiplying the current state by SWAP 2 and we get:

And we’re back to \(\ket{01}\). Our double-swap left our two qubits back in their original state.

If we had started from the left side and multiplied our two SWAP gates, we would get:

Notice that cool pattern of ones along the diagonal? That’s called an identity matrix. It means the matrix does not change a vector you do a dot product with. So our original state vector is unchanged after two swaps, as we’d expect.

When gates are uneven

In our kickback example, we did different gate operations on each qubit. So how do we represent that with matrices? If you said, “let’s use the same tensor product alchemy we used to create our 4-row state vector from two qubits” you’d be exactly right!

Looking at our kickback diagram, we have 3 columns of gates:

The entire circuit (the “composite system”) can be built from the following equation:

The columns are in reverse order because we’re doing a dot product of the gate matrices on the initial state vector and need to preserve the dimensions of the state vector throughout.

For \(A\) we can do a tensor product of the two X gates:

For \(B\) we need to use some cleverness. Nothing happens to \(q_0\) in column B, right? That means that we can think of it as if we applied one of those identity matrices that does nothing to the qubit! So just like we did a tensor product for A, we’ll do it for B between the identity and the H.

For \(C\) we just use the regular CNOT matrix since it spans all our qubits.

Our full equation is:

One thing to note here is that as the number of qubits increases, the size of the matrices needed to represent the whole quantum circuit exponentially increases. It becomes apparent that to simulate a quantum computer with a classical computer doing matrix multiplication it requires a ton of computing resources to execute. In fact, simulating around 50 qubits (requiring \(2^{50}\times2^{50}\) matrices) becomes impossible with today’s classical supercomputers.

The kickback in action

So back to the question, how does the phase get kicked back from the control input into the target input?

Let’s multiply our A and B matrices with the initial state to calculate what happens up until the point where we send the qubits throught the CNOT gate.

Notice the negative phase on the state where \(q_0 = \ket{1}\) and \(q_1 = -\ket{1}\). The other state means our H gate flipped \(q_1\) to be \(\ket{0}\) so we lose the negative phase.

When we expand out the matrix multiplication, we get:

So there we go, we went from a state of \(\frac{\sqrt{2}}{2}\ket{10} - \frac{\sqrt{2}}{2}\ket{11}\) to a new state of \(-\frac{\sqrt{2}}{2}\ket{10} + \frac{\sqrt{2}}{2}\ket{11}\). In the next article, we’ll see how we can use this neat trick.

Note: this post is part of my series, Programming the Multiverse

Prerequisites

I have to admit, I only know enough python to be dangerous. Ruby was always my go-to scripting language. But alas, because python is firmly embedded in the math/science communities with Jupyter Notebooks, it’s the default language for anything quantum related.

So first of all, you need python. I used homebrew to install pyenv to manage my python versions. I also use poetry to manage dependencies.

For this blog series I’ll be using IBM’s Qiskit library to define quantum circuits. It comes with some handy visualization features and allows you to compile and run your circuits on quantum simulators or even on actual quantum computers hosted by IBM.

If you’d like to follow along, simply clone the git repo for this blog series and follow the installation instructions in the README. The use of pyenv and poetry in that repo help ensure you have the right version of python that works with Qiskit 1.1.0.

Most of the code I’ll write will be in Jupyter notebooks. For simplicity, I like to render my notebooks in Visual Studio Code using the Jupyter extension but you’re free to run your own local jupyter server.

Our SWAP gate

Let’s code our first quantum circuit! We’ll be doing a simple swap on two qubits.

The first step is to import all the libraries we need:

from qiskit import QuantumCircuit, QuantumRegister, ClassicalRegister

The QuantumRegister represents a set of qubits. The ClassicalRegister represents those “wires” that we connect to the qubits when we perform a measurement and translate the result into binary zeros and ones that our classical (binary) computer can read.

The next step is to create those registers:

q = QuantumRegister(2, 'q')
c = ClassicalRegister(2, 'c')

The first line says “create two qubits labeled using a prefix of ‘q’.” The second line says “create two classical registers labeled using a prefix of ‘c’.”

Next, we create our quantum circuit (basically like our workspace) which includes our qubits and classical registers:

qc = QuantumCircuit(q, c)

With all that boilerplate out of the way, we can start wiring up our qubits to gates. Qiskit is a bit cryptic in that you have to reference qubits by their zero-based index. So this next line says “swap qubit q0 with qubit q1”:

qc.swap(0,1)

At this point we will now measure the qubits and map the results into our classical registers:

qc.measure(q, c)

And finally, we’ll display the circuit:

qc.draw(output='mpl')

When we run this in our jupyter notebook we see this:

Qiskit can also draw your circuits using LaTeX or even ASCII art.

Another handy tool is that qiskit will show you the matrix representation of any piece of your circuit. Let’s look at the SWAP gate:

from qiskit_aer import Aer
from qiskit.visualization import array_to_latex
from IPython.display import display, Markdown

q = QuantumRegister(2, 'q')
c = ClassicalRegister(2, 'c')
qc = QuantumCircuit(q, c)

qc.swap(0,1)
# NOTE: we cannot measure if we want a unitary!

simulator = Aer.get_backend('unitary_simulator')
result = simulator.run(qc).result()
unitary = result.get_unitary(qc)
unitary.draw('latex')

The above code re-creates the circuit because we can’t use the one above that has measurements added to it. It then creates an “ideal” quantum computer simulator (we’ll explore ideal vs real quantum computers later) and runs the simulation, extracting the “unitary” matrix that represents the gate. “Unitary” is just another name for the matrix representation of our logic gates. We’ll see later that we can build single unitaries out of combinations of multiple gates.

The output gives us the expected matrix representing a basic swap:

You can also output the state vector using a similar method:

simulator = Aer.get_backend('statevector_simulator')
result = simulator.run(qc).result()
state = result.get_statevector(qc)
state.draw('latex')

Which outputs the state vector representing the combined state of the two qubits:

Now we have all the tools we need to build all kinds of quantum circuits and evaluate their behavior using unitary matrices and state vectors.

Next article: Part 6 - Kickbacks

I remember reading this book in fourth grade

Step one was to get content for an adventure. I didn’t have any of the old books I could copy so I perused github for anyone who had implemented a CYOA game. I found this Go language exercise repo with a story written by barisere. And it was nicely formatted in JSON so I could simply parse the story and various choices.

Step two was to figure out, how would I fax this? As a result of a yearlong fight in 2020 with my insurance provider to get transgender health care coverage, I happened to still have a fax.plus account. They also have an API to send faxes!

Step three was determining a way for Greg to choose the various options. Sadly, fax.plus does not give me a fax number and Twilio’s faxing API was discontinued in 2021. But I do know that I can generate QR codes. So all I had to do was generate a URL for each choice, encode them into QR codes, and embed them on the pieces of the story I would fax him. Then when he scans one of the options, send the next part the story.

Page one of the story, showing the target layout

In order to send a fax, I needed to put the story and the QR code options into a PDF and then send it off to fax.plus.

My original design was to generate an initial page of the story by visiting https://my-app.com/story/intro/5551234567. This would generate the intro page PDF and fax the PDF using the fax.plus API. Embedded within the page would be QR codes for each option, each one linking to URLs corresponding to the next page, e.g. https://my-app.com/story/denver/5551234567 and https://my-app.com/story/new-york/5551234567.

So the URL has two inputs: the unique identifier of the part of the branch of the story to render and the phone number to fax it to. I wrote a simple ruby sinatra API to handle this.

As I proceeded, however, I realized I didn’t want to spend a ton of time on this, so I nixed the idea of sending the fax via API. In fact, I could just generate each PDF ahead of time and have the web app just notify me when Greg chose a QR code option.

I spent some time trying to get Twilio to send me an SMS but Twilio has really gone down hill recently and I was unable to just send a simple message. It was a combination of the confusing option for sending texts and having to get a 1-888 number verified that forced me to give up. In the end, I would just watch the logs of the web app to see when Greg made a choice and manually send the fax via fax.plus. I am my own AI-era mechanical Turk!

I deployed my tiny sinatra app onto Digital Ocean’s managed app service that is almost as good as Heroku was back in the day.

I then wrote a script to generate all the PDFs. I used the eternally-incredible prawn gem. To generate the QR codes, I used the handy rqrcode gem.

I sent the intro page and I waited…

And I got a reply! Well, Greg was cheeky and chose both options, so I acted like a computer and only sent the first option he chose. And hilarity ensued!

There’s a certain level of satisfaction to translating the ditial world into something physical and tangible (by Greg) and the excitement of waiting for your friend to read a dorky story about a Gopher and scan the QR codes.

Next steps for this if I had a ton of time would be to use AI to generate the story. Then, we’d have a perfect union of the pre-internet (fax) era, the web 1.0 (HTTP/PDF) era, the web 2.0 (QR code) era, and the AI era! There’s gotta be some way to shoehorn cryptocurrenty into it, too!

Note: this post is part of my series, Programming the Multiverse

As we saw in Part 3, a qubit has a formula associated with it, called bra-ket notation, that describes its probability of being a 0 or 1:

When we apply gates to the qubits, we’re adjusting a and b and the squares of a and b have to add up to a 100% probability (or just 1 in math terms):

So how do we get at those a’s and b’s?

The magic matrices

Let’s take a look at a simple gate, the Pauli-X gate.

This is essentially a NOT operation on a qubit (it’s a simpler version of our earlier CNOT, but without the control input). You give it a \(\ket{0}\) and get a \(\ket{1}\) and vice-versa.

If we dig inside the Pauli-X we discover that it’s hiding a magic matrix!

What’s a matrix? If you never took linear algebra or have repressed those memories, a matrix is like a two-dimensional array that has m rows and n columns.

The cool thing about matrices is that you can do math on them. When we apply a Pauli-X gate to a qubit, we are doing some matrix multiplication.

But first, in order to do this matrix multiplication, we have to turn our qubit into a matrix.

So let’s take our \(\ket{0}\) qubit, which is represented by:

We can take those a and b terms and put them into a 2-row by 1-column matrix (also called a unit vector):

So placing our 1 and 0, we get:

Now we can do the matrix multiplication (also known as the dot product). We always place the qubit matrix on the right and the gate matrix on the left:

When we multiply, we take every row in the left-hand matrix, A and multiply it by each column in the right-hand matrix. Let’s start with row 1 and column 1, the result of which we’ll put into the top cell of a new 2x1 matrix:

Remember, our rows are labeled \(m\) and our columns are \(n\). To designate a cell, we’ll refer to a row and column from \(A\) as \(A_{mn}\). Our new 2x1 matrix we’ll call \(C\).

To get the first cell in \(C\), we loop through each position in the row/column and multiply each cell in \(A\) with the matching cell in \(B\), then add them up:

To get the second cell in \(C\) we operate on row 2 of the gate matrix:

If you, like me, get sick of doing matrix multiplication by hand, you can use one of many online tools or use a programming language like Ruby or Python that have great matrix support.

OK, so when we multiply our input matrix by the gate matrix, we get:

And we transform the resulting matrix back into bra-ket notation by putting \(C_{1,1}\) into a and \(C_{2,1}\) into b:

We’ve done it! We flipped the qubit!

More inputs, bigger matrices

We just did the math for a quantum gate operating on a single qubit using a dot product. But let’s see what happens with a gate operating on two qubits. Let’s work with the SWAP:

The SWAP gate is represented by this magic matrix:

We need to do a dot product against our qubit vectors, but they’re too small to work with that matrix built for two inputs. We need a bigger vector!

A global representation of our qubit state

Earlier, we converted our qubit’s Dirac notation representation of \(q_0 = a\ket{0} + b\ket{1}\) into a vector that looks like:

And we can do the same with qubit \(q_1\):

What we want now is a vector representing the probabilities of getting every combination of each qubit’s possible values:

We some alchemy at our disposal, an arcane tool called a tensor product (more specifically, a Kronecker product) we can perform on the two vector matrices. Now you can sound fancy at your next cocktail party and talk about tensors.

How to do a tensor product

For two matrices A and B, where the dimensions of A are \(m \times n\) and the dimensions of B are \(p \times q\), we get a new matrix C that has dimensions \(pm \times qn\).

When we do a tensor product of our qubits, we essentially create a grid with all the possible combinations of each element of A and each element of B:

So plugging our numbers in for our two qubits, let’s set \(q_0\) to \(\ket{1}\) and \(q_1\) to \(\ket{0}\):

Finally, converting that vector back into our Dirac notation, we have:

We have a 100% chance of getting a combined state of \(\ket{10}\). In other words, \(q_0=\ket{1}\) and \(q_1 = \ket{0}\)

You can view the python code for this operation here.

Performing the swap

Now we can do a regular dot product between the magic matrix that represents a SWAP gate and the vector representing the combined state of our qubits. Note that the initial state vector is always on the right-hand side. When we do the multiplication we get a new output vector that represents the combined states of our qubits after the fact.

Which we put back into our super tensor ultra qubit:

This means we have a 100% chance of a combination of 0 and 1, Which means our two qubits are:

And that’s the magic behind a Freaky Qubit Friday!

OK that’s enough math for now, and trust me, you won’t normally need to do any matrix multiplication by hand unless you need to deeply debug something. But it’s good to know why everything is happening. But eventually you’ll be able to just glance at a matrix and see some patterns, like identity matrices, that give you an idea of what’s going to happen when you apply it.

Next article: Part 5 - Finally, Some Programming!

Note: this post is part of my series, Programming the Multiverse

More on the H gate

Last time, we introduced some basic gates, including the H gate. We saw that the H gate puts a qubit into a Superposition where it has a 50% chance of being a \(\ket{0}\) or a 50% chance of being a \(\ket{1}\) when measured.

What happens if we combine two H gates?

If we input a qubit set to \(\ket{0}\) through the two H gates, we get… a \(\ket{0}\)! Likewise, if we input a qubit set to \(\ket{1}\) we get a \(\ket{1}\).

What’s going on? Here’s where we have to finally delve into a little bit of math.

It’s all probability

The most important thing to remember is that qbits are never really representing actual data values, but they represent probabilities of seeing a 0 or a 1. And the gates are just manipulating those probabilities.

When we say a qubit is \(\ket{0}\) or \(\ket{1}\) what we’re saying is there’s a 100% probability of seeing a 0 or a 1.

Every qubit can be described by a formula:

If you recall, we pronounce it “ket-zero” and “ket-one.” Here we’re using Bra-Ket Notation. No, this does not have anything to do with anesthesia and intimate apparel, it’s just signifying that we’re talking about vectors (more on that later). It’s also called Dirac Notation.

The variables a and b are called the Probability Amplitude. The way this formula works is that a and b have to add up, such that \(\vert{a}\vert^{2} + \vert{b}\vert^{2} = 1\). So in this formula, the total probability is 1 (100%) and the squares of the probabilities, a and b add up to 1.

In the case of a qubit that is definitely 0, we have \(1\ket{0} + 0\ket{1}\). We can drop the \(\ket{1}\) since it’s multiplied by 0. Similarly, a definite 1 is \(0\ket{0} + 1\ket{1}\) which simplifies to \(\ket{1}\).

For a qubit that is in superposition, we have a 50% chance of a 0 or a 1. So if we solve backward from:

and get:

So that the squares cancel out the square roots:

So then a and b are both equal to \(\sqrt{\frac{1}{2}}\) which simplifies to \(\frac{1}{\sqrt{2}}\).

Our final state vector is: \(\ket{\psi} = \frac{1}{\sqrt{2}}\ket{0} + \frac{1}{\sqrt{2}}\ket{1}\)

If we had a 25% chance of 0 and a 75% chance of 1, it would be \(\ket{\psi} = \frac{1}{\sqrt{4}}\ket{0} + \frac{\sqrt{3}}{\sqrt{4}}\ket{1}\)

Back to the H gate

So the H gate is doing something to manipulate those probability amplitudes, a and b. But How? And how does it move each one from 0% or 100% to 50%? Stay tuned for Part 4.

Next article: Part 4 - The Guts of Gates

Note: this post is part of my series, Programming the Multiverse

We’re going to start with some basics. I mean, suuuuper basic. But it’s an important first step. Currently there are no widely-used programming languages for programming quantum computers the same way we write code for today’s computers. The languages that do exist are very esoteric. Instead, quantum computers today are programmed using gates similar to the logic gates we use in today’s computers. So, it’s all very low level.

So before we go into quantum gates and qubits, let’s review logic gates from the classic world.

Ye olde logick gates

You may remember these logical gate diagrams, like for the NOT gate:

This logical gate transforms a single bit, 0 into a 1 or a 1 into a 0. It’s one of the basic building blocks of every CPU and computing device.

AND Gate:

The AND gate outputs a 1 only if both inputs are a 1.

XOR Gate:

The XOR (exclusive OR) gate outputs a 1 if only one of the inputs is a 1.

Combining gates

We can combine the XOR and AND gates to build a very simple computer that adds bits! First, let’s see what happens when we mathematically add two binary bits:

Here is the logical gate diagram for an adder:

Our adder takes two inputs, A, and B, which represent each input bit. There are two output bits because adding 1 and 1 gives us a 2-bit result. For a result representing the binary value 01 C will be the first digit, 0, and S will be the second digit, 1. For a result of 10, C will be 1 and S will be 0.

Here are the results of running the binary adder:

Go ahead and trace the result of each gate given each combination of 0 and 1 for A and B and see what you get.

Data flow in logic gates

In classical computers, in a sense you can say the data is moving around through the gates. You can think of each gate as a function that takes data input, may modify it, then output a result.

Utlimately these logic gates form the thousands of building blocks that combine into our modern day, general purpose “integrated circuits” (e.g. CPUs).

A classical computer is limited in how many of these gate operations it can perform per second. For example an Intel i9 14900HX can run these gate operations up to 5,800,000,000 times per second. There is an upper limit on how many calculations a CPU can try per second to try and solve a problem.

The fancy new quantum gates

You’ve seen how logic gates work in classical computers operating on bits. Starting out, it may seem that quantum and classic logic gates are similar, but we’ll see that quantum computing is a complete shift in how we think of computing.

Now let’s dive into some of the foundational quantum gates. For now we’re just going to focus on their behavior but just know that the way these logical gates are implemented in actual quantum coputers vary and are still under constant development and innovation.

Quantum circuit diagrams

Here is the most basic quantum circuit diagram in the world. It does absolutely nothing, except measure the values of two qubits. Let’s break it down:

\(q_0\) and \(q_1\) are two qubits. By convention, they are intialized to \(\ket{0}\).

Whoah, wait a minute! What’s this \(\ket{0}\) thing? Well for now you can think of it just like a regular binary 0 from the classical world. \(\ket{1}\) represents a 1. It’s pronounced “ket-zero” or “ket-one.”

Back to the diagram, the c represents our “classical register.” You can think of this like the wire where our classical computer will read from to get the values of each qubit. The register has 2 outputs (shown by that 2 hovering next to the c), one for each qubit. So here we have qubit \(q_0\) outputting to classical register \(c_0\) and qubit \(q_1\) outputting to register \(c_1\).

There’s only one way to get data from a qubit - that is to “measure it.” That is what those meter icons represent. You measure a qubit and the result gets sent to the classical register. This touches on a core feature of quantum computing - the idea of superposition, measurement, and risking the life of Schrödinger’s cat - but we’ll get to that in the future.

So from the above diagram we’d read the values of \(c_0\) and \(c_1\) and get 00 because \(q_0\) and \(q_1\) are both initialized to \(\ket{0}\).

SWAP Gate

A swap gate is very simple. It simply swaps the inputs. If q0 is \(\ket{1}\) and q1 is \(\ket{0}\) then after the gate q0 becomes \(\ket{0}\) and q1 becomes \(\ket{1}\). Our classical registers would read 01 after the measurements.

Here’s a table to map all combinations of \(\ket{0}\) and \(\ket{1}\):

CNOT Gate

The CNOT is similar to your familiar old NOT gate. However, it has some special behaviors that we’ll cover later. For now, just know that it has a special “control” input that tells the gate whether to actually perform the NOT operation.

In the example above, q0 is set to \(\ket{1}\) and is sent to the “control” input of the gate. q1 is set to \(\ket{0}\) and is sent to the operand input. The result is that q1 changes to \(\ket{1}\). If q0 were set to \(\ket{0}\) then q1 would remain \(\ket{0}\).

H Gate

The H Gate, also known as the Hadamard gate, does something interesting.

By default, qubit q0 is set to \(\ket{0}\). If we were to run this circuit once, when we measure it we may get a \(\ket{0}\), but we may also randomly get a \(\ket{1}\). If you run this circuit repeatedly, about 50% of the time you get one result or the other. In a way this is like a random number generator, but behind the scenes, the H gate puts the qubit into Superposition.

One of the unique behaviors of quantum physics is that certain particles, for example electrons, are in an unknown state until we “measure” that thing. What do we mean by “measure?” Well that is an enormous philosophical question we don’t have time for here.

But to simplify, for an electron orbiting an atomic nucleus, we don’t know the actual position of that electron until we fire a laser at it (“measure” it) and read how the field of the electron altered the course of photons emitted by the laser. But we only know the position in that moment of time. We can measure this electron multiple times and get a probability distribution of where that electron tends to be located.

When we measure a qubit and put the result into the classical registers, the value that is measured is not binary, but it’s converted into a 0 or 1 value. A quantum computer interprets our quantum gates as instructions on how to alter the probability of the qubit of being converted into that 1 or 0 value.

Let’s say we use a 6-sided die to represent a qubit. And imagine it’s constantly spinning/rolling until we measure it. You could decide that a roll of 1-3 would give you a 0 and a roll of 4-6 would give you a 1. So when we “measure” the die by letting it fall on the table and settle onto a side, we convert the number we rolled into a 0 or 1 bit.

So to recap, the H gate takes our qubit that has a known state, either \(\ket{0}\) or \(\ket{1}\), and puts it into an unknown state, where if measured, will give us a 50% chance of getting a \(\ket{0}\) or \(\ket{1}\).

And that’s it! These are the building blocks to creating all kinds of fun quantum circuits. In the next part, we’ll dig into more quantumness and some simple mathematical notation to represent qubits.

But please beware! Any time we put a qubit into superposition and measure it, we are creating two new universes, one where the qubit is 0 and the other where it is 1. So please limit this operation so that the multiverse doesn’t run out of memory 😅

Next article: Part 3 - Superposition and Probability

Note: You can skip to the table of contents here

If you’re familiar with programming with classical languages, such as Python, Ruby, or Java, and you have seen binary logic gates (NOT, OR, AND) before, this guide is for you!

The goal of this series is to get you familiar with how quantum algorithms work and have some fun with some programming problems. The intention is to introduce topics gently and intuitively, rather than using lots of jargon, diving straight into Bloch Spheres, or showing off fancy equations (we’ll keep them super simple).

What is Quantum Computing?

Anything that uses the term “quantum” means using some of the special physical properties of subatomic particles like entanglement, superposition, and tunneling. We’ll get into what that means later. But unlike “classical” computers (i.e. the computers you use on a daily basis), quantum computers (QC) use these weird (some would say “spooky!”) quantum behaviors to their advantage.

Classical computers are boring, but reliable

Classical computers are great when you want to perform a scripted task quickly. They excel at CRUD operations - creating, reading, updating, and deleting data.

Quantum computers are weird, but useful

QC has traditionally been a hammer in search of nails, but some uses are slowly emerging. AI and QC seem to be a promising match as well as optimizing logistical problems. Instead of scripting out a process in steps, QC finds optimal paths through forests of data. Whereas classical computers try to Hulk Smash their way into a building, QC tries all the possible secret entrances simultaneously. But quantum computers are also a little flakey at the moment. Today they require strategies to reduce “noise” and multiple runs to get a set of results that give you an “average” answer.

Wait what does the Multiverse have to do with this?

One explanation for how quantum mechanics operates (the “Many Worlds” interpretation) states that every possible thing that can happen plays out in an infinite number of parallel universes branching out from the present. You just happen to be traveling down a certain branch of reality. With quantum computing, in a sense it’s like getting to define the possible set of multiverses that emerge from the present.

So prepare for a mind-bending ride!

Table of Contents

• Part 2 - Some Basic Gates
• Part 3 - Superposition and Probability
• Part 4 - The Guts of Gates
• Part 5 - Finally, Some Programming!
• Part 6 - Kickbacks
• Part 7 - Solving the BernVaz Oracle

Sources

If you’re interested in learning more on your own, I highly suggest these sources that provided a lot of inspiration and information for this series:

• Intro to Quantum Computing for Everyone by the folks at EPiQ / UChicago, delivered by edX.
• Intro to Quantum Computing for Everyone 2
• Qiskit Textbook from IBM

First, make sure you have the latest docker desktop that supports aarm64 (M1).

Next, create a docker-compose.yml for your app (for now I’m setting up compose so that I have to rebuild docker images on every code change, but you do have the option of mounting your local source directory, though, there are performance penalties to this).

You’ll need to specify that you want to build and run the image/container with the linux/amd64 platform.

# docker-compose.yml

version: "3.8"
services:
  app:
    build:
      context: .
    platform: "linux/amd64"
    # ...

The tricky part is that you can’t use docker-compose. First, it won’t use docker buildx which has cross-platform building capabilities. Second, for some weird reason, docker-compose 2.4 supported the platform setting but subsequent versions did not.

You have to use the new docker compose command and not the classic docker-compose:

docker compose run app

Possible tie-in with docker buildx

I did this on my local system but not 100% sure if it’s necessary. But it’s a cool feature for managing build environments. Create a docker buildx builder for your local app context:

docker buildx create --platform linux/amd64 --name my-app
docker buildx use my-app

Now when you run docker buildx build -t my-app . it will build the my-app image using the platform specified in the builder you created.