Archive

Archive for the ‘Quantum’ Category

A Year of Q#

December 11th, 2018 No comments

The Quantum Architecture and Computation group launched Q#, our quantum computing programming language, a year ago on December 11th, 2017.

Q# 0.1 was the result of a lot of hard work from a small, dedicated team of developers, researchers, and program managers. We had made the decision to build a domain-specific language for quantum computing about six months before we launched, so we were on a very tight schedule. We were lucky to have a great team of people who all pitched in and did what needed to be done so that we could meet our extremely aggressive timetable.

Start!

Inside the team, we speculated on what level of interest Q# would attract. We hoped that we might receive a few hundred downloads, but we were blown away when we crossed 1,000 users by about 9 hours after launch. That said, with so many users installing the Quantum Development Kit and trying to write simple programs in it, bugs started popping up. In order to deliver the best experience for our users, we released a patch in January that addressed issues like floating-point literals that were handled incorrectly in certain locales, and allowed the simulator to run on older machines without vector instructions support.

We also addressed portability feature requests in our 0.2 release in February 2018, which saw us move from the .NET Framework to the open-source, cross-platform .NET Core. This allowed us to easily support macOS and Linux as well as Windows for building and running Q# code. We also added support for VS Code on all platforms (the 0.1 release was limited to Visual Studio on Windows). As part of the 0.2 release, we were able to make the majority of our libraries and samples available under an MIT license.

Long Hot Summer

We decided to take advantage of one of our team members’ expertise in organizing coding competitions and run a Q# coding competition to engage non-quantum developers with Q# and quantum computing. After a couple of months of preparation, we ran the Q# Coding Contest in early July. Again, the results exceeded our expectations: 514 participants in the warmup round, and 389 in the actual contest. 100 participants solved all the problems, and a lot of them even asked for more challenging ones!

To help make Q# and quantum computing more accessible to the public, we also launched self-paced programming tutorials: the Quantum Katas. We’re up to 10 katas already, and more are coming!

Spring, Summer, Autumn

We started planning the next major release in the spring of 2018, after shipping our 0.2 release: we wanted to rebuild our compiler to work as a language server, to give Q# developers the same interactive error checking and IntelliSense features they’re used to for languages like C# and F#. We knew this would be a huge amount of work and would require a significant re-architecture of the compiler in order to work incrementally. We didn’t want to wait longer to do this work, though, because we wanted to give our users the kind of modern programming environment they’re used to.

We spent the spring and summer re-architecting and rewriting the Q# compiler and shipped the new Q# compiler as our 0.3 release at the end of October.

The 0.3 release also includes a new, open source quantum chemistry library. This library integrates with NWChem, a powerful and popular open source computational chemistry package. The integration is based on the open source Broombridge schema.

Whatever Next

What’s next for Q#? No spoilers (yet!).

The last blog post of the calendar, scheduled for December 24th, will look at some of the things we’re considering for Q# in the coming year.

Until then, enjoy the holidays!

Congratulations to everyone who can figure out what the section titles have in common…

Alan Geller, Software Architect, Quantum Software and Applications
@ageller

Alan Geller is a software architect in the Quantum Architectures and Computation group at Microsoft. He is responsible for the overall software architecture for Q# and the Microsoft Quantum Development Kit, as well as other aspects of the Microsoft Quantum software program.

Categories: Q#, Quantum, Visual Studio Tags:

Qubits in Q#

December 1st, 2018 No comments

How should qubits be represented in a quantum programming language?

In the quantum circuit model, a quantum computation is represented as a sequence of operations, sometimes known as gates, applied to a set of qubits. This leads to pictures such as:

Teleportation quantum circuit

from Quantum Computation and Quantum Information by Nielsen and Chuang

In this picture, each horizontal line is a qubit, each box is an operation, and time flows from left to right.

When we want to design a programming language to express a quantum computation, the question naturally arises of whether qubits should be represented in the language, and if so, how. In the most naive model of such a picture, there would be a software entity that represented each horizontal line, with little or no accessible state other than perhaps a label, but there are other possibilities.

Quantum States as Linear Types

Quipper uses linear types to model quantum states, although it refers to the data type as Qubit. The intuition is that the no-cloning theorem prevents you from making a copy of the quantum state of a qubit, so it makes sense to use the type system to prevent you from making a copy of the software representation of quantum state. Linear types have proven useful in other contexts where copying the software representation of an entity would be bad, for instance in functional concurrent programming, so why not for quantum computing?

The argument for linear types is, as mentioned, that they reflect the no-cloning theorem in the language. The implication is that a software qubit represents a qubit state, rather than an actual object. The problem with this view is that, once entangled, it no longer makes sense to talk about the state of an individual qubit; that’s more or less exactly what being entangled means. To model this in software, an entangling gate such as a CNOT should take two single-qubit states as inputs and return a software entity that represents two-qubit state as output — as long as you never want to perform a CNOT on two qubits that are each entangled with other qubits.

The software entity as quantum state abstraction breaks down for two reasons:

  • because quantum computing works by applying operations to physical entities, not to quantum states, so the abstraction doesn’t correspond to operational reality; and
  • because in general there is no actual physical quantum state smaller than the state of the entire quantum computer, so the abstraction doesn’t correspond to physical reality.

Qubits as Opaque References

An alternate approach is to use an opaque data type that represents a reference to a specific two-state quantum system, whether physical or logical (error-corrected), on which operations such as `H` or `X` may be performed. This is an operational view of qubits: qubits are defined by what you can do to them. Both OpenQASM and Q# follow this model.

Quantum Computing is Computing by Side Effect

The representation used in Q# has the interesting implication that all of the actual quantum computing is done by side effect. There is no way to directly interact with the quantum state of the computer; it has no software representation at all. Instead, one performs operations on qubit entities that have the side effect of modifying the quantum state. Effectively, the quantum state of the computer is an opaque global variable that is inaccessible except through a small set of accessor primitives (measurements) — and even these accessors have side effects on the quantum state, and so are really “mutators with results” rather than true accessors.

In general programming, the use of side effects and global state is generally discouraged. For quantum computing, on the other hand, they seem to match the actual physical reality pretty well. For this reason, we decided that this abstraction was the right one to use in Q#.

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

Alan Geller, Software Architect, Quantum Software and Applications
@ageller

Alan Geller is a software architect in the Quantum Architectures and Computation group at Microsoft. He is responsible for the overall software architecture for Q# and the Microsoft Quantum Development Kit, as well as other aspects of the Microsoft Quantum software program.

Categories: Q#, Quantum, Visual Studio Tags: