Identity gate

[viathor]

Identity is a unitary. We probably want an explicit representation for it in cirq.

Rationale:

1. Many expressions evaluate to the identity exactly (e.g. composition of H with H) or up to global phase (e.g. composition of X, Y and Z). Code that detects and optimizes such expressions may need to return identity explicitly.
2. Identity is a convenient initializer for reduce-like operations on gates.
3. It's directly useful in expressions for quantum channels (see e.g. Powering vector of pauli components #1037).
4. It's one of the basis elements in the Pauli basis of the space of hermitian operators. Having explicit representation for it simplifies code for Representing Hamiltonians #491.
5. There are currently multiple hacky ways of specifying the identity (e.g. cirq.Y**0). If an explicit, elegant way (e.g. cirq.I or cirq.Identity) is provided, the users are more likely to eschew the hacky expressions.

Some things to consider in implementation:

1. It should be removed by all decompositions.
2. It should compare equal to expressions such as cirq.Z**0 or cirq.Rx(rads=0).
3. Do we need a gate for changing global phase? If so, that gate should probably be implemented simply as a phase factor for identity.
4. Circuits such as

0: ───X^0───

1: ───Y─────

should display as

0: ─────────

1: ───Y─────

or

1: ───Y───

[dabacon]

@Strilanc and I talked about this and I think we generally agreed that we need an identity. This is one of the reasons for #1291 : for the channel case you really want an identity gate that can operate on multiple qubits.

[andbe91]

I'm happy to work on this if you all agree on that it should be implemented.

[andbe91]

Hi @viathor, I got started on implementing the identity gate. A question regarding the equivalence to other gates. At the moment, two gates of different classes will not be equal in Cirq even if they have the same effect. E.g. cirq.X**0 == cirq.Y**0 returns False (via the @value.value_equality decorator). I guess one could compare the unitaries of two gates, and if they are equal, call the gates equal as well. Do you have any input on how to evaluate the equivalence?

[viathor]

Yes, gate class is currently part of the comparison key which makes this a little tricky. Have a look at what we're doing for PhasedXPowGate (see __new__()). I imagine this should work for identity gate, too?

[andbe91]

Thanks, that worked. I'm making good progress on this in general, but I have a one more question before I make a PR:
How do you want to handle multi-qubit identity gates such as cirq.CZ**0? At the moment, the identity gate that I implemented is a SingleQubitGate with the unitary [[1, 0, [0, 1]]. It would of course by easy to create a two-qubit version as well, or should I try to create a general N-qubit identity gate that adjustes according the number of qubits?

[dabacon]

Yeah when I did the identity gate PR I ran into this multi qubit problem which is what caused me to open #1291 I think we need to decide on this to unblock this.

[dabacon]

I think displaying it as empty isn't quite correct? Putting identity gates into a Moment is sort of saying "do nothing here and block anything else from happening here). If you don't show it then you will end up having odd things where you don't see that the identity gate is in a particular location.

[Strilanc]

I am completely happy for identity to not equal CZ**0. If you wanted to compare functionality, you'd say cirq.unitary(...) before doing the comparison.

[dabacon]

#1333

[dabacon]

Things we should probably prioritize:

Refactor Pauli to include identity. It's strange to have a Pauli representation that is only X, Y, and Z

[c-poole]

Is there additional functionality we want from the Identity gate as it stands?

[Strilanc]

Already done