The code was only a few lines long, but it felt magical. Two qubits became entangled, and the simulator returned almost perfect results. Then I sent the same circuit to real hardware.

The magic faded a little.

The output was still recognizable, but the clean 50/50 distribution had become noisy. Additional errors appeared, and the circuit no longer behaved like the ideal version I had tested locally.

That moment taught me something important: the future of quantum computing isn't only about better algorithms. It's also about better architecture.

For years, many trapped-ion quantum computers have been built around one-dimensional (1D) linear chains of ions. These systems have achieved some of the highest gate fidelities in the industry, making them excellent platforms for early quantum computing.

But researchers are increasingly exploring a different idea: native two-dimensional (2D) trapped-ion arrays.

Table of Contents

• Prerequisite

• The Road That Got Us Here

  • Why Error Correction Pushes Quantum Hardware Toward 2D

  • A Simple Mental Model

• Why Connectivity Becomes Even More Important for Error Correction

  • A Common 2D Error-Correction Layout

  • Does Surface Code Only Work in 2D?

• What Changes for Developers?

• Why Researchers See 2D as a Natural Match

  • The Real Caveat

  • Current Breakthroughs in the Field

• Conclusion

Prerequisite

This article is a developer-friendly story of why that shift matters, what physical evidence supports it, and why 2D architectures may offer a more natural path to scaling quantum computers beyond today’s limits.

This article is written for software developers, computer science students, and curious engineers who want to understand the hardware ideas behind scalable quantum computing without needing a deep background in quantum physics.

The Road That Got Us Here

Imagine building a city. You start with a single street. It's easy to manage. Every house is visible, and traffic is simple.

That's essentially how a 1D trapped-ion quantum computer works:

In this image, the blocks on the left and right are electrodes that create electromagnetic forces to hold the ions in a straight line. The ions don't touch the electrodes. Rather, they're suspended and controlled very precisely.

The blue laser beams act like extremely accurate control signals. When a laser hits a particular ion, it changes the ion’s quantum behavior.

The highlighted region labeled Entanglement shows two ions becoming linked together. After this operation, measuring one ion gives information about the other, even though they're separate particles.

This approach has produced some of the most accurate quantum operations ever demonstrated. Researchers have achieved extremely high gate fidelities, long coherence times, and precise control over individual qubits. For early quantum computing, the 1D linear chain was a brilliant engineering choice.

So why are researchers looking beyond it?

Because the same simplicity that makes a short chain elegant becomes a limitation when the chain grows longer.

Think about that city again: a single street works well when there are ten houses. Add a hundred houses, then a thousand, and eventually every delivery truck, emergency vehicle, and commuter is forced to use the same narrow road.

Something similar happens in a long ion chain.

As more ions are added, the collective vibrational motion becomes increasingly complex. Addressing one ion without disturbing others becomes harder. Interactions between distant qubits may require additional operations, and the control system must manage a much larger set of coupled dynamics.

The challenge isn't that 1D architectures stop working. The challenge is that they become progressively harder to scale efficiently.

To see why this matters for developers, consider a simple quantum circuit:

from qiskit import QuantumCircuit

qc = QuantumCircuit(8)

# We want distant qubits to interact
qc.cx(0, 7)

print(qc)

On an ideal simulator, this is a single logical operation.

On real hardware, the compiler may need to insert additional routing operations depending on the device’s connectivity. Each extra operation is another opportunity for noise.

This is the hidden lesson many beginners miss: hardware topology affects software performance. A circuit that looks small in code may become much larger after compilation.

Now imagine a different city.

Instead of one long street, you build a neighborhood grid:

This image shows a quantum chip where ions are spread across a two-dimensional grid instead of a single row. The arrows represent the possible paths for moving ions around the chip, giving the system more freedom to connect nearby qubits and avoid the traffic bottlenecks that can occur in long 1D ion chains.

The geometric difference is profound.

1D chain: Capacity grows roughly with length

2D array: Capacity grows with area

If you double the length of a 1D chain, you roughly double the number of available ion sites.

If you double both dimensions of a 2D array, you can roughly quadruple the number of sites.

That may sound like a mathematical detail, but it changes the scaling story dramatically.

Researchers are exploring native 2D layouts because they can offer shorter average distances between qubits, richer connectivity, fewer routing operations, and a geometry that aligns more naturally with many quantum error-correction schemes.

One of the most important distinctions is between native 2D arrays and architectures that are still fundamentally based on elongated linear tracks.

A native 2D design is built around two-dimensional geometry from the beginning, rather than extending a linear architecture with additional zones.

Why does that matter physically? Because distance is expensive in quantum computing.

Imagine four qubits that need to interact frequently.

With a linear chain:

                q0 — q1 — q2 — q3

For q0 to interact with q3, the system may require multiple routing or transport steps.

With a 2D grid:

                    q0 q1 

                    q2 q3

Now several pairs can be close simultaneously.

This becomes especially important for algorithms with many entangling operations, such as quantum chemistry, optimization, and error correction.

And that brings us to one of the strongest arguments for 2D architectures: quantum error correction is naturally two-dimensional.

Why Error Correction Pushes Quantum Hardware Toward 2D

Earlier, we saw that qubits in a long 1D chain may need extra routing operations to interact with distant qubits.

Now let’s ask a bigger question: what happens when we need not just a few qubits, but thousands of qubits that must constantly check and correct each other’s errors?

That's the goal of quantum error correction.

A Simple Mental Model

Think of a classroom where every student must periodically compare answers with nearby classmates to catch mistakes.

If the students sit in a 2D seating arrangement, each student can quickly talk to neighbors on the left, right, front, and back.

This image shows a two-dimensional lattice of qubits. Each blue dot is a qubit, and the lines indicate which nearby qubits can interact with one another. The grid illustrates the kind of local connectivity that is useful for large-scale quantum computing, because qubits can exchange information with nearby neighbors without relying on long, complex communication paths across the chip.

This is very similar to how many leading quantum error-correction methods work.

Why Connectivity Becomes Even More Important for Error Correction

You've seen that a 2D trapped-ion layout can reduce the distance between qubits and potentially require fewer routing operations.

That's already useful for ordinary quantum algorithms. But there's an even bigger reason researchers care so much about connectivity: quantum error correction.

A real quantum computer will make mistakes continuously. Qubits lose information through noise, imperfect gates, and imperfect measurements.

To build a useful large-scale machine, the computer must repeatedly detect and correct errors while the computation is running.

Think of it like a spell-checker that works while you're typing, not after you finish the document.

A Common 2D Error-Correction Layout

One of the most studied examples is the surface-code.

I’m introducing it here because it directly connects to the connectivity problem we just discussed.

The important idea is that qubits are arranged in a 2D neighborhood, and error checks are performed mainly between nearby qubits.

A simplified example looks like this:

D — M — D 
|   |   | 
M — D — M 
|   |   | 
D — M — D


key: D = data qubit, M = measurement/check qubit

Notice what's happening:

• Each qubit talks mostly to its nearest neighbors.

• The pattern is naturally two-dimensional.

• The code doesn't require every qubit to connect directly to every other qubit.

Does Surface Code Only Work in 2D?

Not exactly. And this is a subtle but important point.

You can simulate or implement surface-code-style operations on hardware that's not physically arranged as a perfect 2D grid. Researchers can use additional routing, transport, or intermediate operations to reproduce the required interactions.

But doing so usually introduces extra overhead.

Think of it this way: with native 2D hardware, neighbors are already nearby. With 1D hardware, extra operations may be needed to create those neighbor interactions

So the question isn't "Can surface code run on 1D hardware?" The better question is, "How much additional work is required to make a 1D device behave like the 2D layout that the code expects?"

What Changes for Developers?

Suppose you write a quantum algorithm with many entangling operations.

On a sparse 1D topology, the compiler may insert many extra operations. On a richer 2D topology, fewer extra operations may be needed. That can lead to:

1. Fewer routing operations: less work moving quantum information around

2. Shorter effective distances: qubits that interact often can stay physically closer

3. Shallower compiled circuits: fewer additional gates inserted by the compiler

4. Less manual topology optimization: developers may spend less effort rearranging circuits for hardware constraints.

Notice that none of these benefits require a new algorithm. They come from changing the geometry of the hardware.

Why Researchers See 2D as a Natural Match

Researchers view native 2D trapped-ion architectures as an attractive long-term direction.

The argument is not that 2D automatically solves error correction.

The argument is this: Many leading error-correction schemes are based on local 2D neighborhoods, so hardware that already provides a 2D neighborhood may require less additional routing and coordination.

In other words, the geometry of the hardware is more closely aligned with the geometry of the error-correction scheme.

The Real Caveat

You should know that “easier to scale” doesn't mean “already scalable.”

Native 2D trapped-ion architectures may reduce routing overhead and provide more flexible connectivity, but researchers still have to solve several difficult engineering problems:

• maintaining very high gate fidelity as arrays grow,

• moving ions reliably across larger 2D structures,

• keeping crosstalk and unwanted interactions low,

• building control electronics that can manage hundreds or thousands of qubits,

• and demonstrating fault-tolerant quantum computation, not just small laboratory experiments.

So when people say that 2D trapped-ion quantum computers may be easier to scale, they don't mean that scaling is easy.

They mean that the geometry may remove one important source of scaling difficulty: the mismatch between a linear hardware layout and the highly connected, locally interacting structures needed for large-scale quantum error correction.

Current Breakthroughs in the Field

Researchers are pursuing an architecture intended to address these scaling problems, but it hasn't publicly demonstrated that those problems are solved.

Some of these researchers includes:

• ZuriQ / ETH Zürich trapped-ion laboratory

• NIST trapped-ion quantum computing laboratory

• University of Innsbruck / IQOQI trapped-ion laboratory

They have shown that a 2D array can be built and controlled, but they have not yet publicly shown that very large 2D arrays can maintain the extremely low error rates required for fault-tolerant computing.

One of the most interesting aspects of their architecture is that traditional 1D-based layouts often move ions through linear tracks and junctions. ZuriQ emphasize that ions can be moved more freely in a 2D geometry using a combination of electric and magnetic fields.

What this suggests:

• They're explicitly working on the ion-movement problem.

• Their architecture is designed to make movement less constrained by 1D junctions.

What's still unknown:

• How reliable that movement remains as the array becomes much larger.

• Whether movement can be performed repeatedly without introducing significant additional error.

So this isn't just a theoretical concern. It's a central engineering target of their approach.

Conclusion

This article explained why researchers are exploring native 2D trapped-ion quantum architectures as a potentially more scalable alternative to traditional 1D linear ion chains.

While 1D systems have achieved excellent gate fidelity and coherence, they become increasingly difficult to scale because distant qubits require extra routing operations, increasing noise and compilation overhead.

We looked at city-road and classroom-grid analogies to show how 2D layouts provide shorter qubit distances, richer connectivity, and better alignment with leading quantum error-correction methods such as the surface code.

We also discussed what these geometric advantages could mean for developers (like fewer routing operations, shallower compiled circuits, and less manual topology optimization) while emphasizing that large-scale fault-tolerant quantum computing remains an unsolved engineering challenge despite recent experimental progress in controllable 2D ion arrays.

That question catches almost every quantum developer by surprise. Understanding it is essential if you plan to build larger, more reliable quantum applications.

This tutorial assumes you're already comfortable creating and executing basic quantum circuits in Qiskit.

The first time you execute a circuit on real hardware, you'd expect the output to match the simulator. After all, the code, algorithm, and compiler remain the same. Yet the results often do.

Sometimes the difference is barely noticeable. Other times, a circuit that looked perfect in simulation suddenly produces outputs that are difficult to explain. As your circuits become deeper, involve more qubits, or include more gates, those differences become increasingly significant.

When I first encountered this behavior, my instinct was the same as many beginners: I must have made a mistake somewhere.

I reviewed my code, checked my gates, and compared the circuit diagrams. I reran the simulator. Everything looked correct. The problem wasn't the algorithm. It was the hardware.

Unlike the ideal environment simulated by Qiskit Aer, real quantum processors operate in a world filled with imperfections. Qubits gradually lose their quantum information. Gates are never perfectly accurate. Measurements introduce uncertainty. Even qubits waiting for their turn in a computation continue interacting with their environment, accumulating errors before they perform another operation.

These challenges are collectively known as quantum noise, and they are one of the biggest obstacles preventing today's quantum computers from performing long, complex calculations reliably.

Fortunately, quantum researchers haven't been standing still. Over the years, they've developed a growing collection of techniques to reduce the impact of noise and improve the quality of quantum computations. Broadly speaking, these techniques fall into two categories:

• Error mitigation, which estimates and compensates for errors after a circuit has executed.

• Error suppression, which attempts to prevent many of those errors from occurring in the first place while the circuit is running.

More recently, these advanced techniques have started becoming accessible through developer-friendly tools instead of requiring researchers to manually tune every circuit.

One of the newest examples is Orbit, an automated quantum error suppression solution available through the Qiskit Functions Catalog. Rather than requiring developers to become specialists in techniques like dynamical decoupling, Orbit is designed to integrate advanced error suppression into existing Qiskit workflows with minimal additional effort.

But before we can appreciate why tools like Orbit matter, we first need to understand the problem they're solving.

That's exactly what we'll do in this tutorial. Instead of jumping straight into a new tool, we'll investigate one of the most common and most important questions in quantum computing:

Why do quantum circuits behave differently on real hardware than they do in a simulator?

Along the way, you'll learn where quantum errors come from, how to reproduce many of them locally using Qiskit Aer, why larger circuits become increasingly difficult to execute reliably, and how modern error suppression techniques help developers get more useful results from today's quantum computers.

By the end of this guide, you'll understand not only what causes quantum circuits to fail on real hardware, but also what developers can do about it.

Table of Contents

• The Experiment: Running the Same Circuit in a Simulator and on Real Hardware

  • Starting with a Familiar Circuit

  • Step 1: Running the Circuit on the Simulator

  • Step 2: Running the Same Circuit on a Real Quantum Computer

• What Happens Inside a Real Quantum Computer?

  • From Python Code to Physical Qubits

  • Every Quantum Operation Is a Physical Process

  • What Is Quantum Noise?

  • Four Common Sources of Quantum Noise

  • Why Simulators Don't Show These Problems

• Simulating Quantum Noise with Qiskit Aer

  • Creating a Simple Noise Model

  • Running the Bell State with Noise

  • Comparing the Results

  • Making the Noise Worse

  • Why Not Just Remove the Noise?

• Error Mitigation vs. Error Suppression: What's the Difference?

  • What Is Error Mitigation?

  • What Is Error Suppression?

  • Comparing the Two Approaches

  • Why Error Suppression Is Becoming More Important

  • Introducing Dynamical Decoupling

  • Where Orbit Fits

• How Automated Error Suppression Fits into a Modern Quantum Workflow

  • Moving from Manual Optimization to Automated Workflows

  • What Orbit Publicly Says It Does

  • A Real Hardware Example

  • Should You Use Orbit?

The Experiment: Running the Same Circuit in a Simulator and on Real Hardware

One of the biggest advantages of learning quantum computing with Qiskit is that you don't need immediate access to a quantum computer. You can write, test, and debug your circuits locally using Qiskit Aer before running them on real IBM Quantum hardware.

Let's begin with one of the first circuits you may likely build as a quantum developer: the Bell State.

Starting with a Familiar Circuit

The Bell State is often the first example developers encounter when learning quantum programming because it demonstrates one of quantum computing's most fascinating properties: entanglement.

Create bell_state.py file:

from qiskit import QuantumCircuit

# Create a quantum circuit with two qubits and two classical bits 
qc = QuantumCircuit(2, 2)

# Place the first qubit into superposition 
qc.h(0)

# Entangle the second qubit with the first 
qc.cx(0, 1) 

# Measure both qubits 
qc.measure([0, 1], [0, 1]) 

print(qc)

In this code, the Hadamard gate places the first qubit into a superposition, while the CNOT gate entangles the second qubit with it. Once measured, both qubits should always produce matching values.

In an ideal quantum computer, you should expect only two measurement outcomes:

• 00

• 11

Each outcome should appear with roughly the same probability.

States like 01 and 10 shouldn't appear at all because they violate the expected Bell State correlations.

Step 1: Running the Circuit on the Simulator

You will begin by executing the circuit using the Qiskit Aer simulator:

from qiskit_aer import AerSimulator

simulator = AerSimulator()

result = simulator.run(
    qc,
    shots=4096
).result()

counts = result.get_counts()

print(counts)

Adding your simulator to bell_state.py, you now have:

from qiskit import QuantumCircuit
from qiskit_aer import AerSimulator

qc = QuantumCircuit(2, 2)

qc.h(0)

qc.cx(0, 1)

qc.measure([0, 1], [0, 1])

simulator = AerSimulator()

result = simulator.run(
    qc,
    shots=4096
).result()

counts = result.get_counts()

print(counts)

Make sure your virtual environment is activated (source .venv/bin/activate), and you installed Qiskit and Qiskit Aer (pip install qiskit qiskit-aer).

Run: python bell_state.py, a typical output looks like this:

{'00': 2039, '11': 2057}

Your numbers will likely be slightly different because quantum measurements are probabilistic. However, the overall pattern should remain the same.

Only 00 and 11 appear. There are no unexpected measurement outcomes, and everything behaves exactly as quantum theory predicts.

At this point, it's easy to feel confident that your circuit is correct. And it is. But there's an important detail hiding behind these perfect results.

Note: The simulator assumes an ideal quantum computer.

It doesn't have to worry about hardware limitations because it's simply calculating the mathematical evolution of your quantum state.

Among other things, the simulator assumes that:

• Every quantum gate is executed perfectly.

• Qubits never lose their quantum state.

• Measurements are always accurate.

• The environment never interferes with the computation.

• No additional noise is introduced while the circuit runs.

Those assumptions make simulators incredibly valuable for learning, debugging, and verifying quantum algorithms.

Unfortunately, real quantum processors don't operate under ideal conditions.

Step 2: Running the Same Circuit on a Real Quantum Computer

Now imagine taking this exact same circuit and executing it on a real quantum processor.

Notice that nothing changes. Not the code, algorithm, or the Bell State itself. The only thing we're changing is where the circuit runs.

If you submit this circuit to a real quantum computer, you might expect results that closely match the simulator. After all, if the algorithm is correct, shouldn't the output be the same?

In reality, you'll often observe something more like this:

{
    '00': 1912,
    '11': 1834,
    '01': 161,
    '10': 189
}

The first thing that stands out is the appearance of two unexpected outcomes: 01 and 10.

Those states weren't present in the simulator. So where did they come from? The answer isn't that your code suddenly became incorrect.

The Bell State circuit hasn't changed. The simulator wasn't misleading you.

Instead, the quantum hardware is introducing small imperfections while your circuit executes.

A gate may be applied with slightly less than perfect accuracy. A qubit may begin losing its quantum information before the computation finishes. A measurement may occasionally report the wrong value.

Individually, these errors are usually very small. Collectively, they begin to change the final measurement statistics. For a simple Bell State, the differences are relatively minor.

But quantum algorithms rarely stop at two qubits and two gates.

As circuits become deeper and more complex, these small imperfections accumulate. Eventually, they can overwhelm the quantum information your algorithm is trying to preserve, making the final results less reliable.

This is one of the biggest challenges facing today's quantum computers.

A simulator shows us how a quantum algorithm is expected to behave under ideal conditions.

Real hardware shows us how that same algorithm behaves in the presence of noise. Closing that gap is one of the central goals of modern quantum computing research.

Before you explore techniques like quantum error suppression or see how tools like Orbit help automate parts of that process, you first need to understand where these errors come from.

What Happens Inside a Real Quantum Computer?

At this point, we've established something that surprises almost every new quantum developer:

The same quantum circuit can produce different results depending on where it runs.

But that naturally leads to another question:

What exactly is happening inside a real quantum computer that doesn't happen inside a simulator?

To answer that, you need to look beyond your Python code and understand what happens after you click Run.

From Python Code to Physical Qubits

When you execute a circuit with Qiskit Aer, the simulator performs mathematical calculations to determine how the quantum state evolves. It works with complex numbers and linear algebra, faithfully applying each gate exactly as quantum mechanics predicts.

Nothing interferes with the computation unless you explicitly introduce a noise model.

Real quantum computers work very differently. Instead of manipulating mathematical objects, they manipulate physical qubits.

Depending on the hardware architecture, these qubits might be:

• superconducting circuits cooled to temperatures colder than outer space

• trapped ions suspended by electromagnetic fields

• neutral atoms held in optical tweezers

• another emerging quantum technology.

Although these platforms use different hardware, they all share one important characteristic:

Qubits are extremely fragile.

Unlike classical bits, which remain either 0 or 1 until they're changed, qubits must preserve delicate quantum properties such as superposition and entanglement throughout an entire computation.

Maintaining those properties is far more difficult than it sounds.

Every Quantum Operation Is a Physical Process

When you write code like this:

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

It looks almost effortless. Two lines of Python, less than a second to execute.

Behind the scenes, however, the quantum processor performs a carefully orchestrated series of physical operations.

Control electronics generate microwave pulses or laser pulses. Those signals travel through specialized hardware.

The pulses interact with individual qubits for incredibly short periods of time. The timing must be extraordinarily precise.

If any part of this process deviates even slightly from what was intended, the resulting quantum state can change.

Now imagine repeating this process dozens, hundreds, or even thousands of times within a single algorithm. Tiny imperfections begin to accumulate.

Eventually, those small errors become noticeable in the final measurement results. This is what we broadly refer to as quantum noise.

What Is Quantum Noise?

This is a general term for anything that causes a quantum computer to drift away from the ideal behavior predicted by quantum mechanics.

It doesn't usually mean something dramatic has happened.

Most of the time, the errors are incredibly small.

A gate may rotate a qubit by an angle that's only slightly different from the intended value.

A qubit may lose a little of its quantum information while waiting for another operation. A measurement might occasionally report the wrong state.

Each error seems insignificant on its own. The challenge is that quantum algorithms often involve many operations.

Even tiny inaccuracies begin to add up. Imagine trying to copy a handwritten page. One typo probably doesn't matter.

Copy the same page hundreds of times, introducing one small typo during each copy, and eventually the final document barely resembles the original.

Quantum circuits behave in much the same way. The longer the computation continues, the more opportunities there are for errors to accumulate.

Four Common Sources of Quantum Noise

Although researchers study many different types of quantum errors, most developers encounter four major categories.

Understanding these will help you make sense of why quantum hardware behaves differently from an ideal simulator.

1. Decoherence

One of the biggest challenges in quantum computing is decoherence. A qubit can maintain its quantum state only for a limited amount of time. Eventually, interactions with its surrounding environment cause it to lose the information stored in its superposition.

Think of spinning a coin on a table. When you first spin it, the coin exists in a rapidly changing state that's neither clearly heads nor tails. As time passes, friction slows it down until it finally settles.

Qubits experience a similar loss of information. Except instead of friction, they're affected by tiny interactions with the surrounding environment.

If your circuit takes too long to execute, some qubits may begin losing their quantum information before the computation finishes.

2. Gate Errors

Every quantum gate is a physical operation. Ideally, a Hadamard gate always performs exactly the same transformation. In reality, no hardware is perfect.

The pulse implementing the gate may be slightly stronger, weaker, or slightly delayed than intended. These tiny inaccuracies create gate errors.

One imperfect gate isn't usually a problem, hundreds of imperfect gates quickly become one

This is one reason deeper quantum circuits tend to perform worse than shallow ones.

3. Measurement Errors

Even if your computation completes successfully, there's still one final challenge:

Reading the result.

Measuring a qubit is itself a physical process. Sometimes the hardware incorrectly identifies a qubit as 1 when it should be 0, or vice versa.

Imagine stepping on a bathroom scale that occasionally reports your weight two kilograms heavier than it actually is.

The measurement instrument — not you — is introducing the error.

Quantum computers face a similar problem when reading qubit states.

4. Idle Errors

One of the least intuitive sources of quantum noise occurs when a qubit isn't doing anything at all.

Suppose one qubit is waiting while another qubit is being measured or participating in a multi-qubit operation.

Although it appears idle, it doesn't freeze in time. The qubit continues interacting with its environment. During that waiting period, it can gradually lose coherence.

As quantum circuits become larger, these idle periods become more common.

Reducing the impact of these waiting times is one of the motivations behind advanced error suppression techniques such as dynamical decoupling — a technique we'll explore later when we discuss Orbit.

Why Simulators Don't Show These Problems

If you've only worked with Qiskit Aer so far, you may wonder why you've never encountered any of these issues.

The answer is simple.

By default, the simulator isn't trying to model an imperfect quantum computer. It's trying to model an ideal one.

That makes it an excellent learning environment because you can verify whether your algorithm is logically correct without worrying about hardware limitations.

But it also means a simulator can't fully prepare you for what happens on real quantum devices.

To understand that difference, you need to recreate it yourself.

Fortunately, Qiskit gives us a way to do exactly that.

Instead of waiting until you have access to a real quantum computer, you can intentionally introduce realistic noise into your local simulator and observe how your Bell State begins to change.

Simulating Quantum Noise with Qiskit Aer

So far, you've compared two different worlds.

In the first world, our Bell State circuit runs inside an ideal simulator, where every quantum operation is mathematically perfect.

In the second world, that same circuit runs on a real quantum processor, where qubits are constantly affected by noise from their surrounding environment.

The obvious challenge is this:

What if you don't have access to a quantum computer?

Can you still learn how noise affects your algorithms? Fortunately, you can.

One of Qiskit's most useful features is its ability to simulate realistic hardware imperfections locally using Qiskit Aer. Instead of waiting until your circuit reaches a real quantum processor, you can inject different kinds of noise into your simulator and observe how those imperfections influence the final results.

This allows you to experiment, debug, and better understand the behavior of quantum algorithms — all from your own computer.

Let's see how it works.

Creating a Simple Noise Model

Qiskit Aer includes a collection of tools for building custom noise models. These models let you simulate many of the errors you've just learned about, including gate errors, measurement errors, and qubit decoherence.

For your first experiment, keep things simple by introducing a small amount of random error after every single-qubit and two-qubit gate:

from qiskit_aer.noise import NoiseModel, depolarizing_error

# Create an empty noise model
noise_model = NoiseModel()

# Define gate errors
single_qubit_error = depolarizing_error(0.01, 1)
two_qubit_error = depolarizing_error(0.03, 2)

# Apply errors to common quantum gates
noise_model.add_all_qubit_quantum_error(
    single_qubit_error,
    ["h", "x", "y", "z"]
)

noise_model.add_all_qubit_quantum_error(
    two_qubit_error,
    ["cx"]
)

In this code you created an empty NoiseModel and defined two depolarizing errors.

A depolarizing error is one of the most common ways to simulate hardware noise. Instead of applying a gate perfectly every time, the simulator introduces a small probability that the qubit's state becomes partially randomized.

Think of it like taking a slightly blurry photograph.

The picture still resembles the original, but every small imperfection makes it a little harder to recover the exact details.

That's essentially what depolarizing noise does to a quantum state.

Notice that we're using two different error probabilities:

• 1% for single-qubit gates

• 3% for two-qubit gates

This reflects an important reality of today's quantum hardware.

Two-qubit operations are generally more difficult to perform accurately than single-qubit operations, which is why they often have lower fidelities on real quantum processors.

Running the Bell State with Noise

Rename the bell_state.py we used earlier to bell_state_noise.py to specify adding a NoiseModel.

Reconfigure the simulator with our noise model:

from qiskit_aer import AerSimulator

noisy_simulator = AerSimulator(
    noise_model=noise_model
)

compiled = transpile(qc, noisy_simulator)

job = noisy_simulator.run(
    compiled,
    shots=4096
)

result = job.result()

counts = result.get_counts()

print(counts)

At this point your bell_state_noise.py should look like this:

from qiskit import QuantumCircuit
from qiskit_aer import AerSimulator
from qiskit_aer.noise import NoiseModel, depolarizing_error

# Step 1: Build the Bell State circuit
qc = QuantumCircuit(2, 2)

# Put qubit 0 into superposition
qc.h(0)

# Entangle qubit 1 with qubit 0
qc.cx(0, 1)

# Measure both qubits
qc.measure([0, 1], [0, 1])

print("Bell State Circuit")
print(qc)


# Step 2: Run on the ideal simulator

ideal_simulator = AerSimulator()

ideal_result = ideal_simulator.run(
    qc,
    shots=4096
).result()

ideal_counts = ideal_result.get_counts()

print("\nIdeal Simulator Results")
print(ideal_counts)


# Step 3: Create a noise model
noise_model = NoiseModel()

single_qubit_error = depolarizing_error(0.01, 1)
two_qubit_error = depolarizing_error(0.03, 2)

noise_model.add_all_qubit_quantum_error(
    single_qubit_error,
    ["h", "x", "y", "z"]
)

noise_model.add_all_qubit_quantum_error(
    two_qubit_error,
    ["cx"]
)

# Step 4: Run with simulated noise
noisy_simulator = AerSimulator(
    noise_model=noise_model
)

noisy_result = noisy_simulator.run(
    qc,
    shots=4096
).result()

noisy_counts = noisy_result.get_counts()

print("\nNoisy Simulator Results")
print(noisy_counts)

For windows, to run:

Activate your virtual environment source .venv/Scripts/activate then run python bell_state_noise.py

You may see output similar to this:

Your exact numbers will be different, but one thing should immediately stand out.

Unlike the ideal simulator, two unexpected states have appeared:

• 01

• 10

These outcomes shouldn't exist in a perfect Bell State.

Yet they now appear because we intentionally introduced hardware imperfections into the simulation.

Without changing a single line of our quantum algorithm, the results became noticeably less reliable.

Comparing the Results

Let's compare all three scenarios we've discussed so far.

The noisy simulator isn't trying to perfectly reproduce a specific IBM Quantum processor. Instead, it helps you understand how quantum noise changes the behavior of an algorithm.

That's an important distinction. You're no longer asking whether your Bell State circuit is correct. You already know it is.

Instead, you're asking a new question:

How resilient is my circuit when the hardware isn't perfect?

That's the kind of question quantum developers ask every day.

Making the Noise Worse

To see how quickly errors accumulate, try increasing the depolarizing probabilities.

For example, change the code to:

single_qubit_error = depolarizing_error(0.05, 1)
two_qubit_error = depolarizing_error(0.10, 2)

Run the circuit again.

You'll likely notice that the incorrect outcomes become much more common.

The Bell State begins to lose its characteristic correlation, and the measurement distribution drifts farther away from the ideal 50/50 split.

This simple experiment illustrates an important principle of quantum computing.

Small increases in hardware noise can have a surprisingly large impact on the quality of your results.

Now imagine running a circuit containing hundreds of gates instead of just two.

Each additional operation introduces another opportunity for error.

By the time the computation finishes, the accumulated noise may overwhelm the useful quantum information your algorithm was trying to preserve.

This is why reducing noise has become one of the biggest priorities in quantum computing.

Why Not Just Remove the Noise?

At this point, you might wonder:

If noise causes so many problems, why can't you simply eliminate it?

Researchers have been working toward that goal for decades.

The challenge is that quantum systems are extraordinarily sensitive.

Completely isolating qubits from their environment while simultaneously controlling and measuring them is one of the hardest engineering problems in modern science.

Instead of waiting for perfect hardware, researchers have developed techniques that help quantum computers produce more reliable results even when noise is unavoidable. These techniques fall into two categories as mentioned: Error mitigation* and *Error suppression

Although both approaches aim to improve the quality of quantum computations, they solve the problem in fundamentally different ways.

Understanding that distinction is essential before we explore how Orbit brings automated error suppression into modern Qiskit workflows.

Error Mitigation vs. Error Suppression: What's the Difference?

After seeing how even a small amount of noise can change the outcome of a simple Bell State circuit, it's natural to ask an important question:

If quantum hardware is so noisy, how do researchers still run useful quantum algorithms?

The answer is that they rarely rely on raw hardware results alone. Instead, they use error mitigation and error suppression to improve the quality of quantum computations.

Although these terms are sometimes used interchangeably, they solve two different problems.

Understanding the difference is essential because Orbit belongs to one of these categories — not the other.

Let's look at each approach.

What Is Error Mitigation?

Imagine taking a slightly blurry photograph. Once the picture has been taken, you open an editing application to sharpen the image, adjust the colors, and reduce the blur.

You didn't prevent the camera from capturing a blurry image. Instead, you improved the image after it was captured.

That's essentially what error mitigation does.

Error mitigation doesn't stop errors from occurring while the quantum circuit runs. Instead, it uses mathematical and statistical techniques to estimate how much noise affected the computation and then attempts to compensate for it after execution.

The goal isn't to create a perfect quantum computer. The goal is to extract a better approximation of the correct answer from imperfect hardware.

A simplified workflow looks like this:

Write Circuit
       ↓
Run on Noisy Hardware
       ↓
Collect Results
       ↓
Estimate Hardware Errors
       ↓
Correct the Final Output

This approach has become an important part of today's quantum computing landscape because it doesn't require fault-tolerant quantum hardware.

Instead, it works with the devices we have today.

Some common error mitigation techniques include:

• Measurement error mitigation

• Zero-noise extrapolation (ZNE)

• Probabilistic error cancellation (PEC)

• Clifford data regression (CDR)

You don't need to understand these techniques in detail right now.

The important takeaway is that error mitigation tries to improve the final answer after the computation has already finished.

What Is Error Suppression?

Error suppression takes a very different approach.

Instead of correcting errors after the circuit finishes, it tries to prevent many of those errors from happening in the first place.

Imagine you're hiking through a muddy trail. Error mitigation is like cleaning your boots after the hike. Error suppression is like wearing waterproof boots before you start walking.

Both approaches improve the final outcome. One acts after the problem occurs. The other acts during the journey to reduce the problem altogether.

A simplified workflow looks like this:

Write Circuit
      ↓
Reduce Noise During Execution
      ↓
Execute Circuit
      ↓
Measure Results

Instead of estimating corrections afterward, error suppression focuses on protecting fragile quantum information while the computation is taking place.

This often involves techniques that reduce the impact of environmental noise, improve gate execution, or protect qubits during idle periods.

One of the best-known examples is dynamical decoupling, a technique you'll explore shortly

Comparing the Two Approaches

Although both methods improve quantum computations, they operate at different stages of the workflow.

Neither approach completely eliminates quantum noise.

Instead, they complement each other.

In fact, you'll often get better results by combining both techniques

Why Error Suppression Is Becoming More Important

As quantum algorithms become larger, the number of opportunities for noise to accumulate also increases.

Imagine a circuit containing only two gates, a tiny error may have almost no noticeable effect.

Now imagine a circuit containing hundreds or thousands of gates. Those same tiny errors can accumulate until the final result becomes unreliable.

This is especially challenging for algorithms that require qubits to remain coherent over longer periods or spend time waiting while other operations complete.

In these situations, reducing noise during execution becomes increasingly valuable.

Rather than trying to recover lost information afterward, researchers look for ways to preserve that information before it disappears.

That's where error suppression techniques have attracted significant attention.

Introducing Dynamical Decoupling

This is one of the most widely studied error suppression techniques. The name sounds intimidating, but the underlying idea is surprisingly intuitive.

Imagine balancing a broomstick upright on your hand. If you leave your hand perfectly still, the broomstick quickly falls over. But if you make small, carefully timed adjustments, you can keep it balanced much longer.

You're not changing the broomstick. You're continually making tiny corrections that prevent small disturbances from growing into larger problems.

Dynamical decoupling works in a similar way.

While a qubit is temporarily idle, carefully chosen pulse sequences are applied to help reduce the effects of environmental noise and preserve its quantum state for longer.

The underlying theory has been studied for decades and has become one of the foundational techniques in quantum error suppression research.

However, applying these techniques hasn't always been straightforward.

Developers often needed specialized knowledge to determine when and where these pulse sequences should be inserted into a circuit.

For many software developers, that level of hardware expertise sits well outside their day-to-day workflow.

Where Orbit Fits

This brings us to the motivation behind Orbit.

Rather than expecting every developer to become an expert in dynamical decoupling and other advanced error suppression techniques, Orbit is designed to make those capabilities more accessible through a familiar Qiskit workflow.

Conceptually, the workflow changes from this:

Write Circuit
     ↓
Manually Analyze Idle Periods
     ↓
Design Error Suppression Strategy
     ↓
Modify Circuit
     ↓
Execute on Hardware

to something much simpler:

Write Circuit
     ↓
Orbit Applies Error Suppression
     ↓
Execute on Hardware

Notice what hasn't changed. You still design your quantum algorithm. You still write your Qiskit circuit. You still execute it on quantum hardware.

The difference is that the error suppression strategy can become part of the workflow instead of another manual optimization task.

In other words, Orbit isn't trying to replace Qiskit.

It's designed to help developers get more reliable results from the quantum circuits they already know how to build.

How Automated Error Suppression Fits into a Modern Quantum Workflow

By this point, we've established two important ideas.

First, today's quantum computers are inherently noisy. As circuits become larger and more complex, even small hardware imperfections accumulate and reduce the quality of the final results.

Second, developers have two broad ways to deal with that noise: error mitigation, which improves results after execution, and error suppression, which attempts to reduce errors while the circuit is running.

The obvious question now is:

How do developers actually apply error suppression in practice?

Historically, the answer hasn't been particularly simple.

Many error suppression techniques require a deep understanding of quantum hardware. Developers often need to analyze their circuits, identify where qubits remain idle, experiment with different optimization strategies, and repeatedly execute the circuit to determine which approach produces the best results.

That process can be both time-consuming and highly specialized.

Even worse, a strategy that improves one circuit may provide little benefit for another.

As Quantum Elements explains in its recent technical blog, developers often end up repeating a cycle of testing, tuning, and rerunning experiments because there isn't a one-size-fits-all solution to quantum noise.

Moving from Manual Optimization to Automated Workflows

Modern software development has steadily moved toward automation.

We use formatters instead of manually adjusting indentation. We use linters instead of searching for style issues ourselves. We use CI/CD pipelines instead of deploying applications by hand.

Quantum software is beginning to follow the same pattern.

Instead of asking every developer to become an expert in hardware-aware optimization techniques, newer tools aim to automate parts of that workflow while allowing developers to continue writing standard Qiskit circuits.

One example is Orbit, which Quantum Elements recently made available as a Qiskit Function for IBM Quantum Network members.

Conceptually, the workflow changes from something like this:

Write Quantum Circuit
        ↓
Study Hardware Characteristics
        ↓
Experiment with Error Suppression
        ↓
Modify Circuit
        ↓
      Execute

To a simpler workflow:

Write Quantum Circuit
        ↓
Apply Automated Error Suppression
        ↓
      Execute

The important thing to notice is that your algorithm doesn't change.

You still design the circuit and write Qiskit code. The goal is to make advanced optimization techniques easier to integrate into an existing development workflow.

What Orbit Publicly Says It Does

Quantum Elements has shared a high-level overview of how Orbit works without disclosing its proprietary implementation.

Orbit accepts an existing Qiskit circuit through the Qiskit Functions interface and prepares it for execution by applying a combination of techniques that may include:

• circuit-level optimization during transpilation,

• measurement error mitigation, and

• advanced dynamical decoupling sequences inserted during idle periods where qubits would otherwise accumulate additional noise.

Notice that none of these techniques require developers to redesign their algorithms from scratch.

Instead, the emphasis is on improving how an existing circuit executes on today's quantum hardware.

Exactly how those optimizations are chosen internally is part of Orbit's implementation, but from a developer's perspective the workflow remains familiar:

1. Build your quantum circuit.

2. Submit it through the supported workflow.

3. Execute the optimized circuit on compatible IBM Quantum hardware.

A Real Hardware Example

So far, you've seen how noise affects a simple Bell-state circuit. But the real challenge appears when circuits become larger and qubits spend more time waiting for other operations to finish.

That's exactly the kind of situation Quantum Elements used in a recent public benchmark for Orbit.

In the experiment, the circuit was executed on IBM's ibm_aachen quantum processor. The goal wasn't to show a completely different quantum algorithm. It was to test what happens when a circuit contains more operations, more waiting periods, and more opportunities for noise to accumulate.

As circuits grow, some qubits often remain idle while other qubits are being measured or processed. Earlier in this article, you learned that idle qubits don't freeze in time. They continue interacting with their environment, and that interaction can gradually destroy the quantum information you're trying to preserve.

According to Quantum Elements' published benchmark, Orbit applies error-suppression techniques during these idle periods and combines them with other circuit-level optimizations.

The company compared three versions of the same workload:

• a standard implementation,

• a dynamic implementation without additional protection, and

• the dynamic implementation with Orbit enabled.

The reported results showed that the protected version maintained stronger performance across multiple runs on ibm_aachen.

Quantum Elements also reported an increase in the effective qubit lifetime for this particular experiment, which allowed larger versions of the circuit to remain usable for longer.

The important takeaway isn't that every quantum circuit will improve by the same amount.

The more useful lesson is the one you've been building throughout this tutorial:

As quantum circuits become larger and qubits spend more time idle, reducing the accumulation of noise becomes just as important as designing the algorithm itself.

That's why automated error suppression is becoming an increasingly interesting part of modern quantum software workflows. Instead of manually analyzing every idle period and tuning every optimization yourself, tools such as Orbit aim to make those hardware-aware improvements easier to apply to circuits you've already written in Qiskit.

Should You Use Orbit?

If you're just beginning your quantum-computing journey, probably not yet.

Your time is better spent learning how quantum circuits work, becoming comfortable with Qiskit, and understanding concepts such as superposition, entanglement, quantum noise, and circuit depth.

However, once you start running larger circuits on IBM Quantum hardware, you'll likely encounter situations where noise becomes a practical limitation rather than just a theoretical concept.

That's the kind of workflow automated error-suppression tools are designed to support.

At the time of writing, Quantum Elements is offering developers three months of complimentary access to Orbit for eligible users through a request process. If you're already experimenting with IBM Quantum hardware and would like to evaluate how automated error suppression fits into your workflow, you can request access from Quantum Elements.

Whether you eventually use Orbit or another solution, the bigger lesson remains the same:

Writing a correct quantum algorithm is only part of the challenge. Learning how that algorithm behaves on real quantum hardware — and learning how to reduce the impact of noise — is becoming an increasingly important skill for every quantum developer.

That's exactly what I thought the first time I heard about quantum computing. I assumed quantum computers were machines hidden inside secret laboratories. I imagined researchers in white coats working with equipment worth millions of dollars.

Then I discovered something surprising: you can write and run your first quantum program using Python on a regular laptop.

No quantum computer required. No physics degree required. No advanced mathematics required.

Just Python.

In this tutorial, you'll learn how to build your first quantum circuit using Python and Qiskit.

By the end, you'll understand what a quantum circuit is, how qubits work, and how to create one of the most famous experiments in quantum computing called a Bell State.

Let's get started.

Table Of Contents

• What Is Quantum Computing?

  • Why Should Python Developers Care About Quantum Computing?

• What Is a Quantum Circuit?

• Quantum Gates Explained Like a Python Developer

  • X Gate: The Quantum Light Switch

  • Classical Example

  • Quantum Example

  • H Gate: The Spinning Coin Trick

  • Example

  • CX Gate: Making Two Qubits Work Together

  • How to Set Up Your Python Environment

• Building Your First Quantum Circuit

  • Creating Superposition

  • Creating Entanglement With the CNOT Gate

  • Measuring the Qubits

  • Running the Circuit on a Quantum Simulator

  • Your Complete Bell State Program

  • For Windows Users: A Common Qiskit Aer Error

  • Other Common Mistakes Beginners Make

• Visualizing Results With a Histogram

• Understanding What Just Happened

• What Is a Bell State?

  • Why Bell States Matter

• Real World Applications of Quantum Entanglement

  • Quantum Cryptography

  • Quantum Networking

  • Drug Discovery

  • Financial Modeling

• Beginner Experiments to Try

  • Experiment 1: Remove the Hadamard Gate

  • Experiment 2: Increase the Number of Shots

  • Experiment 3: Add an X Gate

  • Experiment 4: Create Three Qubits

• What Should You Learn Next?

  • Build Larger Circuits

  • Explore Real Quantum Hardware

  • Learn Quantum Algorithms

• Final Thoughts

What Is Quantum Computing?

Most software developers work on regular computers, just like yours - a laptop, smartphone, or gaming console.

Every one of these devices processes information using bits. A bit can only have one value at a time: 0 or 1 Nothing in between.

Quantum computers use something different. They use qubits. A qubit can behave like a 0 and a 1 at the same time until it's measured.

Don't worry if that sounds strange. It sounds strange to everyone the first time.

Think about a coin. When a coin is lying flat on a table, it's either heads or tails. That's exactly how a regular computer bit works. But now, imagine spinning that coin. While it's spinning, it's a blur of both heads and tails at the same time. That's exactly how a quantum bit works

This isn't a perfect explanation. But it's a useful one for beginners.

This ability allows quantum computers to solve certain types of problems differently from regular computers.

Why Should Python Developers Care About Quantum Computing?

You might be thinking: "I'm a Python developer. Why should I learn quantum computing?"

Good question.

The truth is that quantum computing is still in its early stages, but so was artificial intelligence a few years ago. Developers who learn early often gain an advantage.

Python has become one of the most popular languages for quantum programming because it is simple and beginner friendly. Many major quantum platforms provide Python libraries. These include:

• IBM Qiskit

• Google Cirq

• Amazon Braket

Among these options, Qiskit is one of the easiest places to start. That's what you'll use in this tutorial.

If you already know variables, functions, and basic Python syntax, you're ready to begin.

What Is a Quantum Circuit?

If you've built web applications before, you're probably familiar with workflows.

For example:

User clicks button 
        ↓ 
Data is validated 
        ↓ 
Request is sent 
        ↓ 
Response is returned

A quantum circuit works in a similar way. Instead of processing user input, it processes qubits.

A quantum circuit is simply a sequence of instructions applied to qubits.

Here's a simplified view:

Create qubits 
      ↓
Apply quantum gates 
      ↓ 
Measure results 
      ↓ 
Display output

At its core, a quantum circuit simply involves initializing qubits, performing operations, and measuring the results.

Quantum Gates Explained Like a Python Developer

If you've written Python before, you've probably changed values many times.

For example:

light = False

light = not light

print(light)

Output:

True

The not operator changes the value. It takes False and turns it into True.

Quantum computers also need ways to change values. Instead of using operators like not, they use something called quantum gates.

Think of quantum gates as special instructions that tell a qubit what to do.

Just like Python has:

• not

• +

• -

• *

Quantum computing has:

• X Gate

• H Gate

• CX Gate

Let's understand them one at a time.

X Gate: The Quantum Light Switch

Imagine the light switch in your room.

When the switch is OFF: OFF. Press the switch. Now it becomes: ON. Press it again. It becomes OFF.

The switch keeps flipping between the two states, and that's exactly what the X Gate does.

Classical Example

0 → 1
1 → 0

Quantum Example

qc.x(0)

This means: Apply an X Gate to qubit 0.

If qubit 0 was behaving like a 0, it now behaves like a 1.

If it was behaving like a 1, it becomes a 0.

Think of the X Gate as the quantum version of a light switch or a Python not operator.

H Gate: The Spinning Coin Trick

Now things get interesting. Imagine I place a coin on a table. It can only be Heads or Tails, right?

That's how a normal computer works. A bit is either 0 or 1

Now imagine I spin that coin. While it's spinning, can you confidently say it's heads at any given moment?

No.

Can you confidently say it's tails?

No.

It hasn't landed yet. It's in a special state where both outcomes are possible.

That's the easiest way to think about what the H Gate (or Hadamard Gate) does.

Example

qc.h(0)

This tells Qiskit to put qubit 0 into a superposition.

In beginner language, the qubit is no longer locked to just 0 or just 1. It now has a chance of becoming either when we measure it. Think of it like a spinning coin waiting to land.

Before H Gate:

0

After H Gate:

0 and 1 are both possible

This idea is one of the reasons quantum computers are so powerful.

Instead of exploring only one possibility at a time, they can work with multiple possibilities.

CX Gate: Making Two Qubits Work Together

The CX Gate, also called the CNOT (Controlled NOT Gate), is different from the X and H gates because it works with two qubits instead of one.

To understand how it works, let's use a simple real-life example.

Imagine you and your friend are playing a game. Before the game starts, you both agree on one rule.

If you raise your hand, your friend must immediately switch what they're doing. If they were standing, they should sit. If they were sitting, they should stand.

But if you keep your hand down, your friend does nothing and stays exactly as they are.

Notice something important: your friend's action depends entirely on what you do. They don't decide on their own.

That's very similar to how the CX Gate works.

Here's how we use it in Qiskit:

qc.cx(0, 1)

This line tells Qiskit: "Use qubit 0 to control what happens to qubit 1."

In this case:

Qubit 0 → Control qubit

Qubit 1 → Target qubit

The control qubit makes the decision, and the target qubit responds.

Here's what happens behind the scenes:

If the control qubit is 0, nothing happens. The target qubit stays exactly the same.

If the control qubit is 1, the target qubit flips: 0 becomes 1.

Think of the control qubit as a manager giving instructions to an employee. The employee doesn't act randomly. They only change what they're doing when the manager gives the signal.

By itself, the CX Gate is already useful.

But when we combine it with the Hadamard gate, something amazing happens. The two qubits become connected in a special way called entanglement. You'll learn about that later in this tutorial. Now, it's time to practice what you've learned using Python.

How to Set Up Your Python Environment

Here comes the fun part. Let's prepare your machine. Before you continue, make sure Python is installed on your local computer. For this tutorial, use Python version 3.12.8 or 3.13.8. Those versions work well with all the dependencies you'll be installing.

3.12.8

Step 1: Create a New Project Folder

Create a folder called: quantum-python and then open it in VS Code.

Step 2: Create a Virtual Environment

In your terminal (here I'm using Git Bash), run:

python -m venv .venv

Then activate it. On Windows using Git Bash, run:

source .venv/Scripts/activate

And on MacOS/Linux:

source .venv/bin/activate

Step 3: Install Qiskit

Run:

pip install qiskit qiskit-aer matplotlib

This installs:

• Qiskit

• Quantum simulator

• Chart visualization tools

Step 4: Verify Installation

Create a file called:

test.py

Add:

import qiskit

print(qiskit.__version__)

Run:

python test.py

If you see a version number, you're ready.

Congratulations! You've officially entered the world of quantum programming.

Building Your First Quantum Circuit

Create a new file called bell_state.py. This file will contain your first quantum program.

Now you need to import Qiskit. Add:

from qiskit import QuantumCircuit

qc = QuantumCircuit(2, 2)

This imports the QuantumCircuit class.

What does this mean? QuantumCircuit(2, 2) creates 2 qubits and 2 classical bits.

The classical bits will store the final results after measurement.

Let's print the circuit.

print(qc)

Output:

q_0:
q_1:
c:

Right now, nothing is happening. The circuit is empty. You're about to change that.

Creating Superposition

Let's add our first quantum gate: qc.h(0).

This applies a Hadamard Gate to qubit 0.

Your code becomes:

from qiskit import QuantumCircuit

qc = QuantumCircuit(2, 2)

qc.h(0)

print(qc)

Output:

      ───
q_0: ┤ H  ├
      ───
q_1: ─────
          
c: 2/═════

The H gate places qubit 0 into superposition. This is where quantum behavior begins.

You have officially created your first quantum state.

Creating Entanglement With the CNOT Gate

So far, we've only worked with a single qubit. Let's do something much more interesting.

You can make two qubits work together. This phenomenon is called entanglement.

If you've spent time on tech Twitter or watched science videos on YouTube, you've probably heard people call entanglement "spooky action at a distance."

Don't worry about the fancy name, just focus on the code.

Add this line beneath your Hadamard gate: qc.cx(0, 1).

Your program should now look like this:

from qiskit import QuantumCircuit

qc = QuantumCircuit(2, 2)

qc.h(0)

qc.cx(0, 1)

print(qc)

Output:

      ───     
q_0: ┤  H ├─■──
      ───  ─┴─
q_1: ────┤ X  ├
            ───
c: 2/══════════

But what exactly happened?

The first qubit entered superposition when we applied the H gate. The CNOT gate then linked the second qubit to the first. Now the two qubits behave as a connected system, not two separate pieces of information. Just one shared quantum state.

Think about two perfectly synchronized dice. Every time you roll them, they somehow always show the same number.

Sounds impossible, right? That's because it is impossible in normal classical computing.

But quantum mechanics plays by different rules.

Measuring the Qubits

Right now our qubits exist in a quantum state, but computers can't display quantum states directly.

We need to measure them. Measurement converts quantum information into classical information.

Add the following line: qc.measure([0, 1], [0, 1]).

Your code now becomes:

from qiskit import QuantumCircuit

qc = QuantumCircuit(2, 2)

qc.h(0)

qc.cx(0, 1)

qc.measure([0, 1], [0, 1])

print(qc)

What does this line do?

It means:

• Measure qubit 0

• Store result in classical bit 0

and

• Measure qubit 1

• Store result in classical bit 1

At this point our circuit is complete. Now we need to execute it.

Running the Circuit on a Quantum Simulator

Here's the cool part. You don't need a quantum computer. Your laptop can simulate one.

Create a new section beneath your circuit.

from qiskit_aer import AerSimulator

simulator = AerSimulator()

result = simulator.run(
    qc,
    shots=1024
).result()

counts = result.get_counts()

print(counts)

Let's break it down.

What Is AerSimulator That You Installed?

AerSimulator is Qiskit's local quantum simulator.

Instead of sending your program to a real quantum machine, it runs everything on your computer.

This is perfect for learning and experimentation, and it's completely free.

What Are Shots?

Notice this line: shots=1024.

A shot is a single execution of the quantum circuit. Quantum outcomes are probabilistic, which means that one execution isn't enough.

Running 1,024 shots lets us see the overall pattern.

Think of it like flipping a coin. One flip tells you nothing but a thousand flips reveal the probabilities.

Your Complete Bell State Program

At this point your file should look like this:

from qiskit import QuantumCircuit
from qiskit_aer import AerSimulator

qc = QuantumCircuit(2, 2)

qc.h(0)

qc.cx(0, 1)

qc.measure([0, 1], [0, 1])

simulator = AerSimulator()

result = simulator.run(
    qc,
    shots=1024
).result()

counts = result.get_counts()

print(counts)

Save the file.

Run: python bell_state.py.

You should see something similar to:

{
    '00': 504,
    '11': 520
}

Your numbers will be slightly different, which is normal. The important thing is that you see: 00and 11.

You should never see: 01 or 10

And that's the clue that tells us entanglement is working.

For Windows Users: A Common Qiskit Aer Error

If you're using Windows, you might run into this error when importing AerSimulator:

ImportError: DLL load failed while importing controller_wrappers:
The specified module could not be found.

This usually isn't a problem with your code. It happens because Microsoft Visual C++ Redistributable 2015–2022 (x64) isn't installed on your system.

To fix it:

1. Download and install the Microsoft Visual C++ Redistributable 2015–2022 (x64) from the official Microsoft website.

2. Restart your computer.

3. Reopen your terminal and run your program again.

Once the runtime is installed, AerSimulator should import successfully, and you can continue with the rest of the tutorial.

Other Common Mistakes Beginners Make

If your code doesn't work immediately, don't panic. Everyone hits errors.

Common issues include:

Module Not Found

ModuleNotFoundError

Solution: pip install qiskit.

Wrong Virtual Environment

Make sure your virtual environment is activated before running the script.

Missing Simulator

Install: pip install qiskit-aer.

Indentation Errors

Remember that Python cares about spacing. Check your indentation carefully.

Visualizing Results With a Histogram

Developers love visual feedback. A chart makes quantum behavior easier to understand. You can create one.

Add:

from qiskit.visualization import plot_histogram
import matplotlib.pyplot as plt

plot_histogram(counts)

plt.show()

Your bell_state.py file will now look like this:

# IMPORT DEPENDENCIES
from qiskit import QuantumCircuit
from qiskit_aer import AerSimulator
from qiskit.visualization import plot_histogram 
import matplotlib.pyplot as plt

# Create a Quantum Circuit with 2 qubits and 2 classical bits
qc = QuantumCircuit(2, 2)

# Create a Bell state (entanglement) using a Hadamard and a CNOT gate
qc.h(0)
qc.cx(0, 1)

# Measure all qubits into their corresponding classical bits
qc.measure([0, 1], [0, 1])


# Initialize the Aer simulator and execute the circuit for 1024 shots
simulator = AerSimulator()
result = simulator.run(
    qc,
    shots=1024
).result()

# Gather the resulting measurement counts
counts = result.get_counts()

# Print raw text counts and plot the histogram data
print(counts)
plot_histogram(counts) 
plt.show()

Run your program again, a histogram should appear.

It will look something like this:

For the complete project folder, you can get it from Github.

Understanding What Just Happened

Let's pause for a second because something incredible just happened.

• You created entanglement using Python on your laptop without owning a quantum computer.

• The first qubit entered superposition.

• The second qubit became linked to it.

When measurement happened, both became 0 or both become 1. The outcome was random, but they always agreed. That's the key observation.

What Is a Bell State?

The Bell State is one of the most famous examples in quantum computing. It's often the first experiment beginners learn.

Why? Because it demonstrates two important quantum ideas:

• Superposition

• Entanglement

Without Bell States, many quantum algorithms wouldn't exist because:

1. Quantum communication systems depend on them.

2. Quantum cryptography depends on them.

3. Future quantum networks depend on them.

The Bell State is basically the "Hello World" of quantum computing. Every quantum developer encounters it sooner or later.

Why Bell States Matter

At first glance, this experiment seems small: Two qubits, Two gates, and a few lines of Python. Yet, the idea behind it is huge.

Bell States do much more than demonstrate entanglement. Researchers use them as benchmark experiments to verify that quantum hardware can reliably create and measure entangled qubits.

For example, Bell State circuits are commonly executed on superconducting quantum processors to evaluate how accurately the hardware prepares entangled states before running more complex quantum algorithms.

Bell States also play an important role in quantum communication and serve as building blocks for larger quantum algorithms.

Think of them like functions in programming. A single function may seem small but complex applications are built from thousands of them.

The same idea applies here. Large quantum systems are built from smaller quantum operations.

Real World Applications of Quantum Entanglement

A common question beginners ask is: "When will I actually use this?"

Fair question.

Here are some real examples.

Quantum Cryptography

While traditional encryption relies on mathematical difficulty, quantum cryptography relies on the laws of physics, ensuring that any attempt to intercept data changes the quantum state and makes eavesdropping immediately detectable.

Quantum Networking

Researchers developing quantum internet technologies are heavily leveraging quantum entanglement to connect quantum devices across large distances.

Drug Discovery

Quantum computers may eventually simulate molecules more accurately than classical computers. This could help researchers discover new medicines, improve materials, and understand chemical reactions.

Financial Modeling

Large financial institutions are exploring quantum algorithms for:

• Portfolio optimization

• Risk analysis

• Market simulation

The field is still developing, but the potential is enormous.

Beginner Experiments to Try

The best way you can learn quantum computing is exactly how developers learn programming:

• Break things.

• Experiment.

• Change the code.

• Observe the results.

Let's try a few simple experiments.

Experiment 1: Remove the Hadamard Gate

Delete: qc.h(0) and run the circuit again. What changes?

Observe the output. Why do you think that happened?

Experiment 2: Increase the Number of Shots

Change: shots=1024 to shots=100000.

Run the simulation again. Notice how the results become more balanced. This is probability in action.

Experiment 3: Add an X Gate

Insert: qc.x(1) before the CNOT gate.

Run the circuit.

While studying the new output distribution, try predicting the results before running the code.

Experiment 4: Create Three Qubits

Change: QuantumCircuit(2, 2) to QuantumCircuit(3, 3).

Can you create a larger entangled system? Experiment and see.

What Should You Learn Next?

You've now built your first quantum circuit. That's a big milestone.

Here are some great next steps you can explore through IBM Quantum Platform:

• X Gate

• Y Gate

• Z Gate

• S Gate

• T Gate

Build Larger Circuits

Try:

• GHZ States

• Quantum Teleportation

• Deutsch Algorithm

Explore Real Quantum Hardware

IBM allows developers to run circuits on actual quantum computers. This is one of the coolest experiences in modern programming.

Learn Quantum Algorithms

Once you're comfortable with circuits, explore:

• Grover's Algorithm

• Shor's Algorithm

• Quantum Fourier Transform

Final Thoughts

A few years ago, quantum computing felt impossible to approach. It seemed reserved for physicists and researchers.

Today, that's no longer true. If you know Python, you already have a pathway into quantum development.

In this tutorial, you learned:

• What quantum computing is

• How qubits differ from bits

• What quantum gates do

• How to install Qiskit

• How to create a Bell State

• How to simulate a quantum circuit

• How to visualize results

• Why entanglement matters

Most importantly, you wrote your first quantum program. That's how every quantum developer starts.

One circuit. One experiment. One curiosity-driven question at a time.

Now open your editor and modify the code. Break things. Try new gates. And start exploring the quantum world for yourself.

We just posted a Quantum Computing course on the freeCodeCamp.org YouTube channel. This course, created by Michael from Quantum Soar, is designed to provide a solid foundation in quantum computing, guiding you from the basics to a thorough understanding of popular quantum algorithms.

Unlike classical computers, which use bits as the smallest unit of data (0 or 1), quantum computers use qubits. Qubits can represent and store data in multiple states simultaneously thanks to a property known as superposition. Additionally, quantum entanglement allows qubits that are entangled to be correlated in such a way that the state of one qubit can depend on the state of another, even across large distances. These properties enable quantum computers to solve certain types of problems much more efficiently than classical computers.

Here are some reasons you may want to learn about Quantum Computing:

1. Future Technology: Quantum computing is at the forefront of technological innovation. Learning about it now can place you ahead of the curve as the field grows.

2. Problem-Solving: Quantum computers are capable of solving complex problems in areas such as cryptography, optimization, and simulations, which are currently beyond the reach of classical computers.

3. Career Opportunities: As quantum computing technology evolves, there will be an increasing demand for professionals with expertise in this field.

4. Intellectual Challenge: Understanding quantum computing involves grasping complex mathematical and physical concepts, which could be a rewarding intellectual challenge.

The course is divided into two main sections: foundational mathematics and the mechanics of quantum computers. Here’s what you can expect:

Section 1: Essential Mathematics

• 0.1 Introduction to Complex Numbers

• 0.2 Complex Numbers on the Number Plane

• 0.3 Introduction to Matrices

• 0.4 Matrix Multiplication to Transform a Vector

• 0.5 Unitary and Hermitian Matrices

• 0.6 Eigenvectors and Eigenvalues

Section 2: Mechanics of Quantum Computers

• 1.1 Introduction to Qubits and Superposition

• 1.2 Introduction to Dirac Notation

• 1.3 Representing a Qubit on the Bloch Sphere

• 1.4 Manipulating a Qubit with Single Qubit Gates

• 1.5 Introduction to Phase

• 1.6 The Hadamard Gate and +, -, i, -i States

• 1.7 The Phase Gates (S and T Gates)

Advanced Topics and Algorithms

• 2.1 Representing Multiple Qubits Mathematically

• 2.2 Quantum Circuits

• 2.3 Multi-Qubit Gates

• 2.4 Measuring Singular Qubits

• 2.5 Quantum Entanglement and the Bell States

• 2.6 Phase Kickback

• 3.1 Superdense Coding

• 3.2.A Classical Operations Prerequisites

• 3.2.B Functions on Quantum Computers

• 3.3 Deutsch's Algorithm

• 3.4 Deutsch-Jozsa Algorithm

• 3.5 Bernstein-Vazirani Algorithm

• 3.6 Quantum Fourier Transform (QFT)

• 3.7 Quantum Phase Estimation

• 3.8 Shor's Algorithm

This comprehensive course is a great opportunity to get acquainted with the world of quantum computing. By the end of the course, you will have a strong understanding of both the theoretical and practical aspects of quantum computing.

Watch the full course on the freeCodeCamp.org YouTube channel (2-hour watch).

Google recently released a paper showing that its quantum processor, called Sycamore, solved a computing problem in 200 seconds that would have taken the world's best supercomputer 10,000 years to solve.

And Google says this is just the beginning of what quantum computers will be able to do.

What is quantum computing?

Quantum computing is a theory of how to build computers.

Quantum computers perform operations on data using ideas from quantum mechanics, such as superposition and entanglement.

In quantum computation, quantum properties are used to perform operations on data and represent it. This allows quantum computers to process massive and complex datasets more quickly than classical computers like the one you're reading this article with.

Bits VS Qubits

Classical computers store information in binary. It's always possible to know the exact state of a piece of data, or "bit."

Each bit can be either on or off.

Quantum computing, however, uses qubits instead of bits. Qubits can be either on or off. Or they can be on and off at the same time.

Quantum computation uses probabilities. You don't always know the exact state of the data. This uncertainty is what makes quantum computing so powerful.

Since quantum computers use the fundamentals of quantum mechanics, they can solve complex computations very quickly. While quantum computers are already used for some purposes such as cybersecurity, they have not been able to do much so far.

A lot of the ideas behind quantum computing are theoretical and it has been challenging to implement them on a large scale. However, this is starting to change.

So what did Google actually accomplish?

First of all, this is not necessarily the first sign that robots are about to enslave humanity. The computing problem solved with quantum computing was not actually that useful but it was something that a standard computer could not do in a reasonable period of time.

This is the definition of "quantum supremacy": getting a quantum computer to do something that a standard classical computer cannot reasonably do.

This was basically the quantum computer equivalent to a "Hello World" program to test the capabilities. The Google researchers used their quantum computer to run a random circuit program a million times and record the outputs.

The problem that Google solved with quantum computing was specifically designed to be very difficult for a classical computer to solve. The problem was to determine the likelihood of different possible outcomes from a quantum version of a random-number generator.

Google controlled for errors in their system enough so the outputs were close to the theoretical results. This has been a hard problem to solve with quantum computers and made Google's achievement even more unique.

A part of Google's quantum computer. Source: Google.

IBM on Google's Quantum Supremacy: "Really, though?"

Google competitor IBM wasn't so sure about Google's claims. According to IBM, Google overestimated the difficulty of the task.

While Google said the problem they solved would take 10,000 years on a classical supercomputer, IBM said it could be solved in 2.5 days. That's a pretty big difference.

In a blog post, IBM "urge[d] the community to treat claims that, for the first time, a quantum computer did something that a classical computer cannot with a large dose of skepticism."

Google representatives shot back at IBM with a challenge to prove their claim that the same problem their quantum computer had solved in 200 seconds could indeed be solved by a classical computer in 2.5 days.

What's Next?

This is still only the beginning. As Google said in a blog post, "Achieving the necessary computational capabilities will still require years of hard engineering and scientific work. But we see a path clearly now, and we're eager to move ahead."

It's still difficult to correct for errors in quantum computing. Google's quantum team recently estimated that we still have at least 10 years before there is an error-corrected quantum computer.

In a recent interview, Google CEO Sundar Pichai compared their quantum computing breakthrough to the Wright brothers’ first flight. “To borrow an analogy — the Wright brothers. The first plane flew only for 12 seconds, and so there is no practical application of that. But it showed the possibility that a plane could fly.”

From Schrodinger’s Cat to finding a needle in a haystack

_Source: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Quantum_Computing;_IonTrapping(5941055642).jpg" rel="noopener" target="blank" title=")

With the recent announcement of IBM Q System One — the first fully-integrated commercial quantum computer — by IBM at CES 2019, quantum computing is soon to enter mainstream computing. Housed in a nine-foot-tall, nine-foot-wide case of half-inch thick…

Hi everyone!

The other day, I visited D-Wave Systems in Vancouver, Canada. It’s a company that makes cutting-edge quantum computers.

I got to learn a lot about quantum computers there, so I’d like to share some of what I learned there with you in this article.

The goal of this article is to give you an accurate intuition of what a quantum computer is using a simple example.

This article will not require you to have prior knowledge of either quantum physics or computer science to be able to understand it.

Okay, let’s get started.

Edit (Feb 26, 2019): I recently published a video about the same topic on my YouTube channel. I would recommend watching it (click here) before or after reading this article because I have added some additional, more nuanced arguments in the video.

What is a quantum computer?

Here is a one-sentence summary of what a quantum computer is:

A quantum computer is a type of computer that uses quantum mechanics so that it can perform certain kinds of computation more efficiently than a regular computer can.

There is a lot to unpack in this sentence, so let me walk you through what it is exactly using a simple example.

To explain what a quantum computer is, I’ll need to first explain a little bit about regular (non-quantum) computers.

How a regular computer stores information

Now, a regular computer stores information in a series of 0’s and 1’s.

Different kinds of information, such as numbers, text, and images can be represented this way.

Each unit in this series of 0’s and 1’s is called a bit. So, a bit can be set to either 0 or 1.

Now, what about quantum computers?

A quantum computer does not use bits to store information. Instead, it uses something called qubits.

Each qubit can not only be set to 1 or 0, but it can also be set to 1 and 0. But what does that mean exactly?

Let me explain this with a simple example. This is going to be a somewhat artificial example. But it’s still going to be helpful in understanding how quantum computers work.

A simple example for understanding how quantum computers work

Now, suppose you’re running a travel agency, and you need to move a group of people from one location to another.

To keep this simple, let’s say that you need to move only 3 people for now — Alice, Becky, and Chris.

And suppose that you have booked 2 taxis for this purpose, and you want to figure out who gets into which taxi.

Also, suppose here that you’re given information about who’s friends with who, and who’s enemies with who.

Here, let’s say that:

• Alice and Becky are friends
• Alice and Chris are enemies
• Becky and Chris are enemies

And suppose that your goal here is to divide this group of 3 people into the two taxis to achieve the following two objectives:

• Maximize the number of friend pairs that share the same car
• Minimize the number of enemy pairs that share the same car

Okay, so this is the basic premise of this problem. Let’s first think about how we would solve this problem using a regular computer.

Solving this problem with a regular computer

To solve this problem with a regular, non-quantum computer, you’ll need first to figure out how to store the relevant information with bits.

Let’s label the two taxis Taxi #1 and Taxi #0.

Then, you can represent who gets into which car with 3 bits.

For example, we can set the three bits to 0, 0, and 1 to represent:

• Alice gets into Taxi #0
• Becky gets into Taxi #0
• Chris gets into Taxi #1

Since there are two choices for each person, there are 222 = 8 ways to divide this group of people into two cars.

Here’s a list of all possible configurations:

A | B | C
0 | 0 | 0
0 | 0 | 1
0 | 1 | 0
0 | 1 | 1
1 | 0 | 0
1 | 0 | 1
1 | 1 | 0
1 | 1 | 1

Using 3 bits, you can represent any one of these combinations.

Computing the score for each configuration

Now, using a regular computer, how would we determine which configuration is the best solution?

To do this, let’s define how we can compute the score for each configuration. This score will represent the extent to which each solution achieves the two objectives I mentioned earlier:

• Maximize the number of friend pairs that share the same car
• Minimize the number of enemy pairs that share the same car

Let’s simply define our score as follows:

(the score of a given configuration) = (# friend pairs sharing the same car) - (# enemy pairs sharing the same car)

For example, suppose that Alice, Becky, and Chris all get into Taxi #1. With three bits, this can be expressed as 111.

In this case, there is only one friend pair sharing the same car — Alice and Becky.

However, there are two enemy pairs sharing the same car — Alice and Chris, and Becky and Chris.

So, the total score of this configuration is 1-2 = -1.

Solving the problem

With all of this setup, we can finally go about solving this problem.

With a regular computer, to find the best configuration, you’ll need to essentially go through all configurations to see which one achieves the highest score.

So, you can think about constructing a table like this:

A | B | C | Score
0 | 0 | 0 | -1
0 | 0 | 1 | 1 <- one of the best solutions
0 | 1 | 0 | -1
0 | 1 | 1 | -1
1 | 0 | 0 | -1
1 | 0 | 1 | -1
1 | 1 | 0 | 1 <- the other best solution
1 | 1 | 1 | -1

As you can see, there are two correct solutions here — 001 and 110, both achieving the score of 1.

This problem is fairly simple. It quickly becomes too difficult to solve with a regular computer as we increase the number of people in this problem.

We saw that with 3 people, we need to go through 8 possible configurations.

What if there are 4 people? In that case, we’ll need to go through 222*2 = 16 configurations.

With n people, we’ll need to go through (2 to the power of n) configurations to find the best solution.

So, if there are 100 people, we’ll need to go through:

• 2¹⁰⁰ ~= 10³⁰ = one million million million million million configurations.

This is simply impossible to solve with a regular computer.

Solving this problem with a quantum computer

How would we go about solving this problem with a quantum computer?

To think about that, let’s go back to the case of dividing 3 people into two taxis.

As we saw earlier, there were 8 possible solutions to this problem:

A | B | C
0 | 0 | 0
0 | 0 | 1
0 | 1 | 0
0 | 1 | 1
1 | 0 | 0
1 | 0 | 1
1 | 1 | 0
1 | 1 | 1

With a regular computer, using 3 bits, we were able to represent only one of these solutions at a time — for example, 001.

However, with a quantum computer, using 3 qubits, we can represent all 8 of these solutions at the same time.

There are debates as to what it means exactly, but here’s the way I think about it.

First, examine the first qubit out of these 3 qubits. When you set it to both 0 and 1, it’s sort of like creating two parallel worlds. (Yes, it’s strange, but just follow along here.)

In one of those parallel worlds, the qubit is set to 0. In the other one, it’s set to 1.

Now, what if you set the second qubit to 0 and 1, too? Then, it’s sort of like creating 4 parallel worlds.

In the first world, the two qubits are set to 00. In the second one, they are 01. In the third one, they are 10. In the fourth one, they are 11.

Similarly, if you set all three qubits to both 0 and 1, you’d be creating 8 parallel worlds — 000, 001, 010, 011, 100, 101, 110, and 111.

This is a strange way to think, but it is one of the correct ways to interpret how the qubits behave in the real world.

Now, when you apply some sort of computation on these three qubits, you are actually applying the same computation in all of those 8 parallel worlds at the same time.

So, instead of going through each of those potential solutions sequentially, we can compute the scores of all solutions at the same time.

With this particular example, in theory, your quantum computer would be able to find one of the best solutions in a few milliseconds. Again, that’s 001 or 110 as we saw earlier:

A | B | C | Score
0 | 0 | 0 | -1
0 | 0 | 1 | 1 <- one of the best solutions
0 | 1 | 0 | -1
0 | 1 | 1 | -1
1 | 0 | 0 | -1
1 | 0 | 1 | -1
1 | 1 | 0 | 1 <- the other best solution
1 | 1 | 1 | -1

In reality, to solve this problem, you would need to give your quantum computer two things:

• All potential solutions represented with qubits
• A function that turns each potential solution into a score. In this case, this is the function that counts the numbers of friend pairs and enemy pairs sharing the same car.

Given these two things, your quantum computer will spit out one of the best solutions in a few milliseconds. In this case, that’s 001 or 110 with a score of 1.

Now, in theory, a quantum computer is able to find one of the best solutions every time it runs.

However, in reality, there are errors when running a quantum computer. So, instead of finding the best solution, it might find the second-best solution, the third best solution, and so on.

These errors become more prominent as the problem becomes more and more complex.

So, in practice, you will probably want to run the same operation on a quantum computer dozens of times or hundreds of times. Then pick the best result out of the many results you get.

How a quantum computer scales

Even with the errors I mentioned, the quantum computer does not have the same scaling issue a regular computer suffers from.

When there are 3 people we need to divide into two cars, the number of operations we need to perform on a quantum computer is 1. This is because a quantum computer computes the score of all configurations at the same time.

When there are 4 people, the number of operations is still 1.

When there are 100 people, the number of operations is still 1. With a single operation, a quantum computer computes the scores of all 2¹⁰⁰ ~= 10³⁰ = one million million million million million configurations at the same time.

As I mentioned earlier, in practice, it’s probably best to run your quantum computer dozens of times or hundreds of times and pick the best result out of the many results you get.

However, it’s still much better than running the same problem on a regular computer and having to repeat the same type of computation one million million million million million times.

Wrapping up

Special thanks to everyone at D-Wave Systems for patiently explaining all of this to me.

D-Wave recently launched a cloud environment for interacting with a quantum computer.

If you’re a developer and would like actually to try using a quantum computer, it’s probably the easiest way to do so.

It’s called Leap, and it’s at https://cloud.dwavesys.com/leap. You can use it for free to solve thousands of problems, and they also have easy-to-follow tutorials on getting started with quantum computers once you sign up.

Footnote:

• In this article, I used the term “regular computer” to refer to a non-quantum computer. However, in the quantum computing industry, non-quantum computers are usually referred to as classical computers.

In this article, I’ll introduce you to Q# — the new programming language from Microsoft for quantum computing. We will cover Q# data types, expressions, and statements with the help of code snippets.

Prerequisites

For an overview of quantum computing, please visit my earlier article: An Introduction To Quantum Computing. There, I also describe how to install Quantum Development Kit (QDK) in Visual Studio 2017.

What is Q#?

According to Microsoft:

Q# is a scalable, multi-paradigm, domain-specific programming language for quantum computing.

So, what do these terms actually mean? Let us dive into the details.

• Scalable
  Q# allows us to write code that can be executed on machines of varying computing abilities. We can use it to simulate a few Qubits on our local machine, or even thousands of Qubits for an enterprise level application.
• Multi-paradigm
  Q# is a multi-paradigm programming language. It supports both functional and imperative programming styles. If you are new to programming paradigms, I suggest you refer here.
• Domain-specific
  Q# is a programming language for quantum computing. It is to be used for writing algorithms and code snippets that are executed on quantum processors.

Getting started with Q# development

This article will assume you have already installed QDK for Visual Studio 2017. If not, then you can check my earlier article for instructions.

After you have successfully installed QDK, we need to verify if Visual Studio 2017 has all the required dependencies installed for Q# development. For this, we will clone and execute the quantum sample programs from GitHub provided by Microsoft.

Open VS 2017 and navigate to Team >> Manage Connections.

Select Clone under Local Git Repositories and enter the URL: https://github.com/Microsoft/Quantum.git and click “Clone”.

The repository will be cloned on your local computer and Visual Studio will switch to the Solution Explorer. It will display all the cloned libraries and samples.

Now, open QsharpLibraries.sln solution.

If you are prompted with the “Install Missing Features” popup box, click “Install” to allow the installation of the necessary features. This will download and install F# and other tools used by some of the samples. Make sure that you are connected to the internet.

To execute a sample program, right-click on the TeleportationSample project in “Samples > 0.Introduction folder” _of QsharpLibrari_es solution, and then click on “Set as Startup Project” and press F5.

If you can see an output screen similar to the one shown below, then congratulations, your VS 2017 is ready for Q# development.

Note that your output screen may vary because the data being teleported is random. But it should send 8 rounds of data, with all being successfully teleported.

Q# Type model

Let us understand what are the various type models provided by Q#:

Primitive Type

• Int: — It represents the 64 -bit signed integer. Notice the upper case ‘I’. This is in contrast to int in C# with lower case ‘i’.
• Double: — It represents double-precision floating point number. This also has a upper case ‘D’ in contrast to double in C#.
• Bool: — It represents the Boolean type and can take two values — true or false.
• Qubit: — This represents the Quantum bit. Qubit is the fundamental unit of processing information in quantum computers, similar to a bit in classical computers.
• Pauli: — This type is used to denote the base operation for rotations and to specify the basis of a measurement.
• Result: — This represents the result of a measurement. This can take two possible values Zero or One
• Range: — This represents a sequence of integers.
• String: — It represents a sequence of Unicode characters.

Array Type

We can create an array type of any valid Q# primitive type. Q# does not support rectangular multi-dimensional arrays. Instead, it supports only jagged arrays.

Int[], Qubit[][]

By default, all variables in Q# are immutable. Their values cannot be changed after they are bound. So, to create an array whose values can be set, we will use the mutable keyword:

mutable myArr = new Int [5];

This will create an integer array myArr of size 5. The elements of a new array are initialized to a type-dependent default value. In this case it will be 0, the default value for an integer type.

Arrays passed as arguments are immutable. All arrays in Q# are zero-based. That is, the first element of an array arr is always arr[0].

Tuple Type

The tuple type represents a tuple of values of any given primitive type. It is represented as (T1, T2, T3,…) where T1, T2, T3 are primitive types. The Q# tuple is immutable. We cannot change the contents of the tuple once it has been created.

A tuple expression can contain values of multiple primitive types. So, a tuple of type (Int, Double, Result) is a valid tuple.

We can create a tuple with single element also, like (2). This is known as a singleton tuple, and it is considered equal to the value of the enclosed type. This property is called singleton tuple equivalence.

For example, (2) is a singleton tuple of type Int, but it is considered equivalent to an integer 2.

We can create a user defined type of any primitive type. We can also create an array of user defined types or can also include it in a tuple. User defined types cannot have cyclic dependency on each other. So, it is not possible to create a recursive type structure.

A user-defined type is a subtype of the base type. This means it can be used anywhere a value of the base type is expected.

Operation Type

A Q# operation is a callable routine, which contains Q# code to carry out a quantum operation. An operation is the basic unit of quantum execution in Q#. The operation can only take single value as input in the form of a tuple. It returns a single value as output, specified after a colon, and may be a tuple.

An operation has a body section which contains the implementation of the operation. It can also have adjoint, controlled, and controlled adjoint sections. These are used to specify specific variants of appropriate operations. The arguments to an operation are specified as a tuple, within parentheses. The return type of the operation is specified after the colon.

Refer to a sample operation below:

operation AddInteger(a: Int, b: Int): Int {  
    body {  
        mutable c = 0;  
        set c = a + b;  
        return (c);  
    }  
}

Here, we have an operation AddInteger which takes a tuple (Int, Int) as input. It returns an output of type Int after performing addition operations on input integers.

Function Type

A Q# Function is classical subroutine used within a Quantum algorithm and can only contain classical code (but no quantum operations). Similar to Q# operations, a function will also take a single value as input and returns a single value as output. Both of them can be a tuple. Functions cannot allocate qubits or call operations.

Let’s look at a sample function.

function ProductNumber(a: Double, b: Double): Double {  
    mutable c = 0.0;  
    set c = a * b;  
    return (c);  
}

Here, we have defined a function ProductNumber, which takes a tuple (Double, Double) as input and returns an output of type Double after performing the product of input values. Also, notice that a function does not have a body section, as in the case of an operation.

Expressions in Q

Let’s take a look at various expressions provided in Q#.

Numeric Expressions

There are two types of numeric expressions provided by Q#:

• Integer numbers: these are represented by Int
• Floating point numbers: represented by Double

To represent a hexadecimal integer, we use the “0x” prefix.

We can also perform binary operations on numeric expressions to form a new numeric expression. The type of the new expression will be Double if both input expressions are floating point numbers, or will be an Int if both are integers.

Apart from binary operations, the numeric expressions also support modulus, power, bitwise AND, bitwise OR, bitwise XOR, and bitwise complement operations.

Qubit Expressions

Qubit expressions are the symbols that are bound to qubit values or the elements of a qubit array. Q# does not provide any support for qubit literals.

Pauli Expressions

As we have discussed earlier, the primitive type Pauli can take four possible values: PauliI, PauliX, PauliY and PauliZ. These all are valid Pauli expressions. We can also create an array of Pauli types, and the array elements are considered as valid Pauli expressions.

The two possible result values Zero and One are valid Result expressions. One important point to note is that One is not the same as integer 1, and Zero is not same as integer 0. Also, there is no direct conversion between them.

This is in contrast to C# where, boolean true is considered the same as integer 1 and boolean false is considered the same as integer 0.

Range Expressions

A range expression is represented as start..step..stop where start, step, stop are all integers. The range expression can take values as start, start+step, start+step+step and so on until stop is passed.

If only start and stop are mentioned in a range expression, then it will take the value of the step as set to 1 implicitly.

Let’s understand this with the help of an example:

• 1..3 — this indicates the range 1,2,3. This gives 1, 1+1, 1+1+1
• 1..2..6 indicates the range 1,3,5, or 1, 1+2,1+2+2
• 8..-2..3 indicates the range 8,6,4 or 8, 8+(-2), 8+(-2)+(-2)

Array Expressions

In Q# an array can be represented as a set of element expressions separated by semicolons and enclosed within square brackets. Similar to C#, all elements of an array in Q# should have the same type.

So, [1;2;3] is a valid array, but [1;2.5;Zero] is an invalid array.

We can also use the ‘+’ operator to concatenate two arrays of the same type.

So, [2;4;6] + [8;10;12] will give [2;4;6;8;10;12] as output.

To find the length of an array, we use the Length built-in function.

As an example, if myArr is an integer array having 5 elements, then Length(myArr) will return 5 as the output.

Q# Statements

Symbols in Q# can be mutable or immutable.

An immutable symbol cannot be changed after it has been bound. We use the let keyword to define and bind an immutable symbol.

let i=8;

This will bind the symbol i as an integer with value 8. If we try to reset the value of an immutable expression, we will get a compile time error.

Hence set i=10; will give an error in this case.

A mutable symbol value can be changed after it has been bound. We use the mutable keyword to define and bind a mutable symbol.

mutable i=8;

This will bind the symbol i as an integer with value 8.

To change the value of a mutable symbol, we use the set keyword:

set i=10;

This will update the value of variable i to 10

for-loops

Q# allows a for-loop to iterate over an integer range. The for statement consists of the keyword for, followed by an identifier, the keyword in, a Range expression, and a statement block.

A range is specified by the first and last integers in the range, for example: 1..5 represents the range 1, 2, 3, 4, and 5. If a step other than +1 is needed, then three integers with .. between them are used.

So, 1..2..10 is the range 1, 3, 5, 7, and 9. The range is inclusive at both ends.

for(num in 1..2..10)  
{  
   //Do something  
}

As the name suggests, this loop will repeat until successful operation occurs. This loop is based on the quantum “repeat until success” pattern. It consists of the keyword repeat and its statement block, the keyword until, a Boolean expression, the keyword fixup, and its statement block .

The statement inside the repeat block is executed, and then the boolean condition is evaluated. If the boolean condition evaluates to true, then the loop terminates. Otherwise, the fixup block is executed and the loop repeats once again.

The fixup block is always required — even if there is no fixup to be done — in which case it will be empty.

repeat {  
    //do something  
}  
until boolean condition  
fixup {  
    // do something  
}

Q# supports if statements for conditional execution, similar to C#. The if statement consists of the keyword if, followed by a Boolean expression and the statement block. An if block may have an optional else block, which is represented by the keyword else.

if (num % 2 == 0) {  
    return true;  
} else {  
    return false;  
}

A conditional statement can consist of a series of if-elseif-else chains. The else-if clause is represented by the keyword elif.

if (num == 1) {  
    //do something  
}  
elif(num == 2) {  
    //do something  
}  
else {  
    //do something  
}

Conclusion

In this article, we have learned the basics of the Q# programming language. We also installed QDK and verified the Q# execution environment with Visual Studio 2017. Please post your valuable feedback in the comments section and stay tuned for more on Quantum Computing.

You can always refer to my previous articles here.

You can also find this article at C# Corner

Originally published at ankitsharmablogs.com on Jan 16, 2018.

Disclaimer: This is a hypothetical think piece. It is a personal opinion and doesn’t represent the opinion of any of the companies (or secret societies) I may (..or may not) be involved with. If you tear a hole through space-time after reading this article… that’s your own fault.

If you haven’t heard, a research team out of China just made a huge leap with respect to realization of using Quantum Entanglement as a valid communication vessel. Their process was to use a low-earth satellite to create a pair of entangled photons and then send them to locations very far apart from each other. Even at never-before-done distances, the photons retained their entanglement, which has set the internet a buzz about the future of communication, and when the new quantum internet will happen.

Now, looking at the math, I’m still a bit dubious that quantum entanglement could be viably used for communication. This math person explains it a bit better than I ever could. However, there’s lots of people hypothesizing that this is the first steps in a new quantum internet where things like Entanglement Swapping and Twisted Light could bridge those gaps.

Then let’s propose a thought experiment: let’s assume there’s future where an internet exists, whose technology is based on quantum entanglement. This means that data can be transmitted between two locations, at close to speed-of-light without a physical connecting medium between the locations.

In such a world, does data compression matter any more?

A small idea on how a QE internet would work

We have to assume that due to current technology, the first realization of a QE Internet (QEI) would be very similar to the telegraph systems of the past. The cost to maintain and run these early QEI sites would limit their availability, meaning that communication could only occur between a handful of sites.

These sites would require two primary features:

1. A non-centralized system which can distribute entangled photon pairs to the sites (a low-orbit satellite, for example).
2. A recording system which logs the results of the entanglement tests and can store / retrieve them.

#2 would be most likely built on today’s modern technology. So you can expect a situation where a billion photon pairs are sent to a site, and sampled in unison, and stored as binary data at the location.

From that point, the data would be most likely distributed to it’s final destination using more conventional methods (e.g. fiber connection).

Limitations of a first generation QEI

Obviously, we still end up with some data-based bottlenecks here:

1. There is a physical limit to how many entangled pairs can be stored at a site, thus limiting it’s total bandwidth.
2. There is a physical limit to the speed in which entangled pairs can be sent from the distributor to the sites on a regular basis, thus limiting total system bandwidth.
3. Environmental factors will cause loss of data in the transfer of photons to the sites from the distributor system. Thus, there will be a need for redundancy in the process, limiting total system bandwidth.

When observing the above, you can quickly seen that the overall bandwidth of a QEI would be limited by the above systems, regardless of the ability for information to travel between sites through quantum means. So obviously, reducing the size of the data being sent through the sites will be important, but will today’s data compression algorithms make sense?

Data compression for a QEI

There’s a few definitions of “data” which represents it as a physical entity, and as the (potential) realization of a Quantum Internet is realized, the need for photon transferal makes this concept even more real.

In fact, that may be the largest ramification of a quantum entangled internet: your data now has a very physical manifestation and cost involved with it.

So it’s obvious that data compression, as a science, will still be needed in a QEI future, but the real question we should be asking ourselves is: Are today’s compression algorithms good enough to support a quantum internet?

My opinion? Not even close.

As explained in “Understanding Compression” today’s systems are still grounded around Shannon’s basic architecture of ‘the most frequent symbol gets the smallest bits.’ There’s a lot of power in this process, but until we move out of symbol space, and start gaining the computational power to handle compression entirely in bit-vector space, we’re going to be leaving a lot of information on the table. (But that’s my own unpopular opinion...)

Let’s look beyond that. Are there potential systems where, rather than applying Brotli to a data set, we instead can apply in to entangled photons directly? Will we start talking about algorithms to do diff’s against the photons on a site, and the data being transmitted, so we can reduce the number of updated pairs? What happens when we start thinking in terms of qubits, rather than just bits? Do we have to start thinking about LZ encoding in 8 dimensional space?

Obviously, the realization and standardization of Quantum Computing will create a massive technological shift in how our world works. And I’ve got every reason to believe that Data Compression will be right there, too.