This article is sort of a short follow-up to my December 1st, 2018 blog post. I make no promises about December 1st, 2020…

Functional Units, not Memory

Qubits are often described as the quantum analog to classical bits. Indeed, the word “qubit” comes from the phrase “quantum bit”. Wikipedia describes a qubit as the quantum version of the classical binary bit.

I’ve found for many people this is a misleading description since it leads them to think of a quantum computer working like a classical computer, where registers of qubits are sent around on data busses between functional units that apply gates and memory locations that provide storage. This isn’t how most real quantum devices work, though; instead, qubits are actual physical systems that can be controlled to perform quantum operations such as Hadamard or rotation gates. Qubits don’t move physically, although we might teleport a quantum state from one qubit to another. Qubits are really more like the functional units of a CPU, the integer and floating-point arithmetic units and other execution units that perform operations on memory, than they are like passive holders of information like classical bits.

Object-Oriented Qubits

In some ways, qubits are more like software objects: they are entities that have both state and behavior, and their state is private and only exposed (in a limited way!) through getter methods (measurements). Gates such as X or S would be public methods with no arguments that return void. CNOT could be a method on the control qubit that took the target qubit as an argument.

One problem with this approach is that it seems natural that a qubit should expose a getter method or methods that exposes its full state. Don’t most objects provide access to all of their interesting state? While this seems appealing, and in a pure simulation environment may even be helpful, in a production environment it violates an important principle: operationalism. This is the idea that a quantum programming language shouldn’t include constructs that can’t be realized physically. The physical state vector of a qubit cannot be determined from a qubit by an experiment; all that can be extracted is the result of measuring the qubit in some basis. In order to access the state of a qubit in actual operation, you need to be able to recreate the qubit in the exact same state many times and apply quantum state tomography. This is not a plausible operation to perform at an arbitrary point in a quantum algorithm.

Another problem is that this approach is misleading: once a qubit is entangled, it is no longer physically correct to talk about the state of that single qubit. Instead, one can only talk about the state of the entangled set of qubits, since the information in the system as a whole is more than the information in the individual qubits put together. In most quantum computing scenarios, qubits are almost always entangled, since otherwise you can efficiently simulate the computation classically.

When qubits are entangled, measuring one of the qubits impacts the state of all of the qubits. This behavior is what’s behind the EPR paradox. The notion that calling a getter method or reading a property value on one object might change the state of other, seemingly unrelated objects would be rather counterintuitive to someone experienced with object-oriented programming in C# or Java. This makes the object-oriented approach less appealing.

Qubits in Q#

For Q#, we wanted to have a more functional flavor, so our qubits are values of an opaque data type rather than objects. In our model, one can think of the qubits as representing the physical systems themselves, and the operations represent the control signals sent down to the quantum device that cause the physical state to change. Our model might be a bit less familiar to developers than the object-oriented approach, but by avoiding any representation of the quantum state in Q#, we avoid the entanglement confusion.

By keeping qubits opaque and property-less, we stay within the confines of operationalism. The key there is to avoid adding any simulator-specific intrinsic operations that provide access to the internal state vector that represents the current quantum state. We’ve resisted this temptation for about two years now, despite requests from several people, and our firm intention is to continue to resist the temptation indefinitely.

This post is the first one in the Q# Advent Calendar 2019. Follow the calendar for other great posts!