Generalize X and Z to Weyl–Heisenberg gates

[daxfohl]

Closes #4782, xref #3190

Implements X and Z as Weyl-Heisenberg gates, allowing them to operate on qudits of arbitrary dimension. The implementations are done via eigen_components, thus allowing interoperability with arbitrary exponents and global phase.

Tests are done to ensure the unitaries at exponent 1 correspond to the standard definitions of Shift and Clock, at dimension 3 and 4. We also test simulations at non-integral exponents to make sure they perform as expected.

Following the precedent set by the identity gate, the diagram labels remain X and Z when applied to qudits, as the qudit dimension itself is already labeled in the diagram.

There is no negative impact on standard X and Z performance. In fact the performance is slightly improved over the existing X and Z gate implementations because we now cache the eigen_components rather than generate them each time. Testing shows a roughly 10% improvement in unitary calculation due to this change.

Additionally this removes all the existing PlusGate definitions and replaces their use with the new X gate functionality instead.

[dabacon]

cache the eigen_components
I wonder if we should be doing this more generally?

[daxfohl]

cache the eigen_components
I wonder if we should be doing this more generally?

Not opposed (though outside the scope of this PR I think). Though it only saves ~10% on calculating the unitary, and calculating the unitary is only ~10% of simulating the gate, even on a single-qubit system (and obviously becomes negligible on more than ~2 qubits).

[vtomole]

From Cirq sync:

• The qudit gates might not be hermitian and this might be something we assume throughout the codebase
• Have linalg experts confirm that this behavior is what users would expect.

[daxfohl]

Yes, they will be non-Hermitian outside of dimension 2.

[daxfohl]

@MichaelBroughton I tested and it does continue to work for MPS simulator. I don't think it's necessary to add regression tests since it's just a sanity check. But the following passes (as does dim 4, and zpow).

def test_xpow_dim_3():
    x = cirq.XPowGate(dimension=3)
    sim = ccq.mps_simulator.MPSSimulator()
    circuit = cirq.Circuit([x(cirq.LineQid(0, 3)) ** 0.5] * 6)
    svs = [step.state.state_vector() for step in sim.simulate_moment_steps(circuit)]
    expected = [
        [0.67, 0.67, 0.33],
        [0.0, 1.0, 0.0],
        [0.33, 0.67, 0.67],
        [0.0, 0.0, 1.0],
        [0.67, 0.33, 0.67],
        [1.0, 0.0, 0.0],
    ]
    assert np.allclose(np.abs(svs), expected, atol=1e-2)

Or if the concern is that wider circuits that include these things wouldn't "merge" properly when entangled, the above test doesn't really check that. (We'd have to figure out what such a test would even look like; might require #4512 first).

[daxfohl]

@dabacon @maffoo Where do you configure the formatter not to reformat matrices for a file? I think it's better without the format change: https://github.com/quantumlib/Cirq/runs/6029681451?check_suite_focus=true

[95-martin-orion]

@dabacon @maffoo Where do you configure the formatter not to reformat matrices for a file? I think it's better without the format change: https://github.com/quantumlib/Cirq/runs/6029681451?check_suite_focus=true

You can do this with # fmt: off and # fmt: on comments.

[95-martin-orion]

Bump for @95-martin-orion to review!

[95-martin-orion]

I think I'll be comfortable approving this since the dimension parameter separates this from existing use cases, but let's verify with tests (see comment below).

[95-martin-orion]

Could you add tests demonstrating how a dim-3 qudit interacts with dim-2 X/Z, and vice versa?

[daxfohl]

It just fails .on(wrong_shape_qubit) because GateOperation checks the shapes match. However I added a test.

[daxfohl]

Also note @cduck has a SingleQubitSubspaceGate that would allow dim-K gates to be applied to a subspace of a dim-N qubit where N >= K (https://github.com/cduck/cirqtools/blob/2fbff43fa945dfa6155e83f4a72c16774ca26e42/cirqtools/qudit/common_gates.py#L85). That applies to any gate, not just these X/Z additions. However it sounds like that's not on the roadmap (#3190 (comment)).