Skip to content

Global phase in SingleQubitCliffordGate #2847

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
viathor opened this issue Mar 19, 2020 · 2 comments · Fixed by #5568
Closed

Global phase in SingleQubitCliffordGate #2847

viathor opened this issue Mar 19, 2020 · 2 comments · Fixed by #5568
Assignees
Labels
area/paulis kind/design-issue A conversation around design

Comments

@viathor
Copy link
Collaborator

viathor commented Mar 19, 2020

Filing to continue discussion started in the meeting by @fedimser.

Background

Clifford gates are often said to be the unitaries that map Paulis to other Paulis under conjugation. This yields an infinite group(*). However, there really is only a finite number of interesting classes of elements in this group, so the actual definition of the Clifford group generally involves the quotient of the above by U(1), i.e. we ignore the global phase. This yields a set of 24 elements in the single-qubit case.

Interestingly, it can be shown that the Clifford group is generated by Hadamard, phase and CNOT gates. Note that if you take this as the definition of the Clifford group then you end up with more elements than above, e.g. 192 in the single-qubit case. However, once again taking the quotient by U(1) saves the day yielding the same group as above.

This means that the fact that the global phase is ignored is important for some well-known properties of the Clifford group to hold.

Issue

In cirq, we don't keep track of the global phase of Clifford gates. By the statements above, this is the right thing to do. @fedimser pointed out that this may be misleading for the user. @fedimser what particular methods/functions did you have in mind? @Strilanc said we can either rename them to be clear about the loss of global phase or we can return a tuple (Clifford, phase). Is there a use-case in which the knowledge of the global phase is useful?

@cduck


(*) For example, multiples of identity exp(i theta) I satisfy the condition for a Clifford gate for any real theta.

@fedimser
Copy link
Contributor

I came up with this idea while working on PR #2803.

As @Strilanc suggested, I added a factory method from_unitary on class SingleQubitCliffordGate. When I am trying to simulate a Clifford gate, I am converting it to SingleQubitCliffordGate, then decompose to rotations and decompose rotations to H and S gates.
But we also need to keep track of global phase - it's stored in _ch_form.omega. I tried comparing unitary matrix of Clifford gate I am simulating to cirq.unitary of constructed gate, but that didn't always work, because in SingleQubitCliffordGate._decompose_ there is an optimization to return H matrix if this is H gate. Unfortunately, it's not the same matrix which we get if we decompose H gate to rotations.

In other words, SingleQubitCliffordGate._unitary_ returns some unitary matrix which has the same effect on Paulis as given gate, but there is no convention how to choose this matrix. I thought that we can solve this by agreeing on canonical unitary for Clifford gate (e.g. it should agree with decompose_rotation, or it's first non-zero element should be real and positive), and also adding field on SingleQubitCliffordGate._unitary_ to represent phase difference between canconical matrix and gate stored by this object.

Practical reasons to do this

  1. To make this expression true for every Clifford 2x2 matrix u:
    np.allclose(u, cirq.unitary(cirq.SingleQubitCliffordGate.from_unitary(u))).

  2. So we can have two SingleQubitCliffordGate objects representing two different gates which differ in phase, and they won't be equal.

  3. So user can construct SingleQubitCliffordGate representing any single qubit Clifford gate, i.e. with any phase. Because by definition, if you apply phase shift - it's still a Clifford gate.

To be honest, real problem is that SingleQubitCliffordGate._unitary_ is not always in agreement with SingleQubitCliffordGate.decompose_rotation(), because of special handling of Hadamard gate in SingleQubitCliffordGate._decompose_. I understand that this special case was added to get usual textbook definition of Hadamard gate, so we can't remove it (whoever added it implicitly admitted that Clifford gates differing in phase are not the same).
So I thought how to fix this issue and keeping track of phase is one possible solution.

@cduck
Copy link
Collaborator

cduck commented Mar 19, 2020

Another option would be to output a GlobalPhaseOperaton with the appropriate additional phase from _decompose_. This could be done in addition to adding a global phase attribute to SingleQubitCliffordGate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/paulis kind/design-issue A conversation around design
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants