Public PlusGate

[daxfohl]

Is your feature request related to a use case or problem? Please describe.

We have PlusGate class implementation duplicated several times in tests, and there's now a copy of that class used in the internal implementation of ResetChannel.

Describe the solution you'd like

Should we just make a public implementation? (This could be a good first issue, no particular QC knowledge needed)

[optional] Describe alternatives/workarounds you've considered

Not make it public.

What is the urgency from your perspective for this issue? Is it blocking important work?

P3 - I'm not really blocked by it, it is an idea I'd like to discuss / suggestion based on principle

[daxfohl]

In light of #3190 (if I'm understanding correctly), would another option be to rewrite XPowGate as a PlusGate, with optional dimension and increment arguments?

Assuming my understanding of the issue is correct, this approach would match what we do with IdentityGate, where cirq.I is a single-qubit gate by default, but you can initialize cirq.IdentityGate(dimension=5) if you need to.

[daxfohl]

The PlusGate as implemented is probably insufficient. We'd probably want to figure out the EigenGate representation of it before adding it to our public gates. So one consideration is how it works under non-integer exponents. Integer exponents would just multiply the increment (meaning we don't actually need an increment, and can just use the exponent). However non-integer exponents, I'm not sure how that would work. There's an _eigen_components function that, if implemented, might allow things to "just work". I assume PlusGate has well-defined Eigen components, but not sure.

[daxfohl]

@Strilanc @viathor I'm having trouble understanding what _eigen_components does and how/whether it would work for PlusGate. Any google results I see just talk about the unitaries. Do you have any references?

[daxfohl]

I think I figured the math out, but it's coming out to there being no eigen components that satisfy a PlusGate. Eigenvalues (for a 3-value PlusGate) are the third roots of i, so half-turns are [0, 2/3, 4/3]. But the symmetry about the real line implies that the 2nd eigenspace has to equal the 3rd, so the complex values can cancel out. But if they're equal then, well, there's nothing to differentiate them. But they have to be different. So is a PlusGate not able to be an Eigen gate?

cc @cduck

Note I haven't done linear algebra in 28 years (and even that was a summer crash course), so.

[daxfohl]

I figured out the math, reversing the logic in EigenGate._unitary_ to get the required eigencomponents, which end up looking like

(0, np.array([[1/3, -2/3, 0], [0, 1/3, -2/3], [-2/3, 0, 1/3]])),
(2/3, np.array([[1/3, 1/3, 0], [0, 1/3, 1/3], [1/3, 0, 1/3]])),
(4/3, np.array([[1/3, 1/3, 0], [0, 1/3, 1/3], [1/3, 0, 1/3]])),

Plugging that into a new EigenGate Plus gives unitary(Plus)

[[0.+0.j 1.+0.j 0.+0.j]
 [0.+0.j 0.+0.j 1.+0.j]
 [1.+0.j 0.+0.j 0.+0.j]]

However unitary(Plus**0.5) gives:

[[0.+0.67j 0.-0.33j 0.+0.j  ]
 [0.+0.j   0.+0.67j 0.-0.33j]
 [0.-0.33j 0.+0.j   0.+0.67j]]

Looks like something that could plausibly be a unitary, but it isn't. Multiplying by adjoint gives:

[[ 0.56+0.j -0.22+0.j -0.22+0.j]
 [-0.22+0.j  0.56+0.j -0.22+0.j]
 [-0.22+0.j -0.22+0.j  0.56+0.j]]

So, I guess a PlusGate isn't an EigenGate (at least in dimension 3)?

[daxfohl]

I tried again, trying some linear algebra directly instead of reversing the existing EigenGate._unitary_. (https://en.wikipedia.org/wiki/Square_root_of_a_matrix#Matrices_with_distinct_eigenvalues)

Using that I ended up with what the unitary for Plus**0,5 should be.

[[0.33+0.58j 0.33-0.58j 0.33-0.j  ]
 [0.33-0.j   0.33+0.58j 0.33-0.58j]
 [0.33-0.58j 0.33-0.j   0.33+0.58j]]

Indeed when I plug that into a MatrixGate, and simulate it, it provides the following fun moment steps:

[1. 0. 0.]
[0.67 0.33 0.67]
[0. 0. 1.]
[0.33 0.67 0.67]
[0. 1. 0.]
[0.67 0.67 0.33]
[1. 0. 0.]

However I can't figure out what the _eigen_components need to be in order to make EigenGate._unitary_ output that value when exponent=0.5. (In fact, it seems that there are no such components, as when I worked the algorithm out backwards in my previous comment, that ended up being the unique solution that satisfied the exponent=0 and exponent=1 unitaries for what Plus should be.

So, it seems that Plus is an EigenGate. So is the implementation of EigenGate._unitary_ wrong since it seems not to be able to represent this case? (But it works for so many other cases, so I have a hard time believing that it would be).

[daxfohl]

Okay, looks like these components are projection matrices onto the eigenvectors. So, pretty sure I see the pattern for making the eigenvectors for a PlusGate (roots of unity and their powers). Still need to look up the formula for projecting onto a complex vector, but thinking this is getting close.

[daxfohl]

That seems to have worked for dimension 3. If I change X to:

    def _qid_shape_(self) -> Tuple[int, ...]:
        return (3,)

    def _eigen_components(self) -> List[Tuple[float, np.ndarray]]:
        L = (-1+np.sqrt(3)*1j)/2  # 3rd root of unity
        L2 = L ** 2
        return [
            (0, np.array([
                [1, 1, 1],
                [1, 1, 1],
                [1, 1, 1],
            ]) / 3),
            (2/3, np.array([
                [1, L, L2],
                [L2, 1, L],
                [L, L2, 1],
            ]) / 3),
            (4/3, np.array([
                [1, L2, L],
                [L, 1, L2],
                [L2, L, 1],
            ]) / 3),
            # (0, np.array([[0.5, 0.5], [0.5, 0.5]])),
            # (1, np.array([[0.5, -0.5], [-0.5, 0.5]])),
        ]

then it provides the nice step function, and X**0,5 moment steps are

[[1.  +0.j   0.  +0.j   0.  +0.j  ]
 [0.33+0.58j 0.33-0.58j 0.33-0.j  ]
 [0.  +0.j   1.  -0.j   0.  +0.j  ]
 [0.33+0.j   0.33+0.58j 0.33-0.58j]
 [0.  +0.j   0.  +0.j   1.  -0.j  ]
 [0.33-0.58j 0.33-0.j   0.33+0.58j]
 [1.  +0.j   0.  +0.j   0.  +0.j  ]]

So the answer to why QM requires complex numbers is: so that we can count to 3 by halves. :)

Anyway that seems to be a fairly straightforward pattern. I'll see what I can get for higher dimensions (I'm guessing it may be slightly different for non-primes) and then create a PR. (Not sure what I did wrong in my previous calculation that suggested such a decomposition wasn't possible, but oh well).