Add support for n-controlled gates

[mylesDoyle]

We add support for creating n-controlled gates using the decompositions described by Barenco et al. (https://arxiv.org/abs/quant-ph/9503016)

For this, we have added the following features:

• Intermediate gate creation and memoization to create the appropriate circuits.
• Recursively create n-controlled gates using qubit optimal and gate-depth optimal composition strategies.
• Special cases for optimisation of gate-calls where appropriate.
• Added example of n-controlled gate use case.
• Unit tests for the standard and optimised special cases of the n-controlled (NCU) gate with U={Pauli-X, Pauli-Y, Pauli-Z}.

[TysonRayJones]

Hi there,
Just out of curiousity, does qHipster allow the direct simulation of an n-controlled unitary without decomposition? I.e. with the same runtime cost as a singly-controlled gate?

[mlxd]

Hi @TysonRayJones to my knowledge this functionality does not exist in Intel-QS. Our proposed PR adds support for n-controlled gates using several decomposition strategies (using direct recursive, simple optimised known cases, or using auxiliary qubits to reduce depth).

Direct simulation without decomposition would be nice, but I am not aware of how this could be achieved to ensure adjustment of all coefficients in the appropriate manner. The above decomposition approach does achieve very good performance and utilisation of system resources. We have run it using between 8-14 control lines in recent experiments, and had good success using additional nodes in MPI with it.

[TysonRayJones]

Ah I see. I ask, because a direct n-controlled gate is actually quite straightforward if a 1-controlled gate already exists (and it's obviously faster and much more precise). Effecting an n-controlled gate involves modifying less amplitudes than the 1-controlled gate modifies.

The (serial) logic for the 1-controlled gate is:

for each amplitude:
    if control qubit is 1:
        update the amplitude according to the gate

The logic for the n-controlled gate is then simply:

for each amplitude:
    if all control qubits are 1:
        update the amplitude according to the gate

Even in a distributed application, evaluating the condition all control qubits are 1 is a simple bitwise test.

I implemented a distributed n-controlled gates in the Oxford simulator I work on (see here). While there's a bit of boilerplate there, the "main" part (that distinguishes it from the 1-controlled case) is here. Happy to explain the O(1) all control qubits are 1 test further if interested.

While supporting a decomposition to 1 and 2 qubit gates is certainly very useful to emulate precisely what a quantum computer (with those constraints) would effect (to e.g. capture noise accurately), it's unnecessary if one wishes to just effect the gate on the state. I'm happy to help out if you think this is worth adding to qHipster

[mlxd]

Ah, I understand. That sounds sensible, though you are correct in saying that matching the device (1 and 2 qubit) allowed gate-calls was the plan for the above work. I think it may be best to do this in another issue/PR following the merging of this work, as this is partly the result of an external collaborative project from the following repo: https://github.com/ICHEC/QNLP

Though, I am also interested in your implementation of this from a pure simulation perspective, and would like to listen in if the Intel team are interested in pursuing this.

[giangiac]

Hi @TysonRayJones and hi @mlxd,

Sorry for the late reply.
I think that including a direct n-qubit controlled gate is a great idea.

For how I see it, there are a few possibilities.

• One possibility is a generalization of the 1-qubit controlled gate following the reasoning of Tyson and paying attention of which among the control qubits and target qubit are local/global. There are a couple of utility functions that could be helpful here, for example "check_bit()" defined inline in qureg.hpp.
• Another approach is focusing on gates that are diagonal in the computational basis. In this case MPI communication is not needed and the gates are really simple to implement (look at the functions in "qaoa_features.cpp" since the implementation would be similar but with computing phases on the fly). In this approach, one could convert a CCX (2-qubit controlled X, non diagonal) to a CCZ (2-qubit controlled Z, diagonal) simply by applying Hadamard before and after the CCZ. I expect the overhead to be less than 3x (and most probably 2s) for reasonable implementations and all n-qubit controlled gates.

I agree with Lee that this should be a separate pull request.

Happy to discuss more about it.
Gian

[mlxd]

Hi all, sorry for the long delay, but only recently had time to revisit this. I have not been able to replicate the errors that appear on the Github Action test. Running locally on my Mac natively, in Docker, and inside a localised Github action version all pass. Simiarly, the same things are observed on the HPC system. Any thoughts as for why this is happening would be greatly appreciate. I initially thought it may be some thread safety issues with the Google testing framework on the Action, but it seems that may not be the case either.