Lukas Heidemann

Global phases and control

When designing a programming language, we need to decide on semantics: what is the colourful text in our editors supposed to mean in terms of running programs? In this post I want to explore a simple but slightly tricky edge case in modelling the semantics of the control construct in quantum programming languages.

Unitary maps between qubits are a reasonable starting point for the denotational semantics of quantum programs. We let denote the category whose objects are the natural numbers, representing numbers of qubits, and whose maps are unitary maps . Every quantum gate can be realised as a unitary, and the unitaries composed to give semantics to any pure quantum circuit in .

The construction that enhances an gate into its controlled variant can then be generalised to a functor that adds an additional control qubit and sends any unitary to its controlled version defined by

Via this functor, we can produce a controlled version of any unitary, on any arbitrary number of qubits, and thereby of any quantum circuit. This is a useful thing to do, which is why many practical quantum compilers support it. And in particular we recover and the Toffoli gate .

The description of a pure quantum program as a unitary carries some redundancy: unitaries that differ up to a global phase are physically indistinguishable. This gives us some useful optimisation oppportunities, since we can apply rewrite rules to a circuit even when they only preserve the unitary up to a global phase factor. To mark this in the categorical semantics, we can replace with its quotient that identifies two unitary maps whenever there exists a phase with . Let us write for the quotient projection.

There is a further reason why we would want to ignore global phase. A full quantum programming language would not only include pure quantum operations but also measurements, classical data, state preparations etc. All of these features admit natural semantics in the category of quantum channels, and the realisation map factors through the projection map:

The problem I want to discuss in this post already happens on the level of . Above we have constructed a functor that can make any quantum circuit controlled. However, this construction does not extend to :

The counterexample is quite simple: we have that but

Global phases aren’t physical and just artifacts of our mathematical description, so how could they matter here? This made me stumble a bit the first time I’ve encountered this in the context of a feature request for representing global phases, which seemed like an odd ask to me at first.

The answer is once again to be careful not to conflate the map and the territory. is a form of syntax for a pure quantum program while is a bit closer to its physical semantics. The construction that adds control to a circuit operates on the syntax and is not well defined on the semantics. This is not all too different from classical program transformations that modify the constructs of a high-level programming language but cease to make sense on the lowered assembly code.

This has some important practical consequences for quantum programming languages. There will be regions of a program that have to be interpreted differently depending on how they are used, as optimisations that don’t preserve global phase can only be applied on parts of the program that aren’t consequently made controlled.

How this is ultimately achieved is a design problem. We might decide to consider phase-relevant and phase-irrelevant versions of gates to be two entirely different operations; this would work but be rather cumbersome. Or we could be pessimistic and disallow all phase-changing transformations unless some analysis can prove that the code isn’t being used in a phase-relevant setting. Perhaps some form of effect system could encode this in the type system, allowing the information to be propagated across function boundaries?

I will not attempt to answer this question in this post. Rather I want this to reemphasise the point that there are tricky questions in the design of programming languages. This particular case might appear almost trivial, but it is something that is very easily overlooked when you were assigned the ticket for adding a control operation and the sprint is almost over (or, more accurately to the times, you have asked an LLM to implement the operation and are now skimming its outputs). In this case, the result could be a bug that is incredibly difficult to diagnose.