Handle Qudits

[dabacon]

Currently we use "QubitId" everywhere, but tying ourselves to two level systems seems bad. How are we going to work with higher dimensional quantum systems, or boson or fermion (or heaven forbit para-fermion) based systems?

[Strilanc]

Everything we do with operations should correspond to twiddling some kind of quantum control knob. A Qnob if you will. QubitId doesn't have anything inherently binary about it. We could just rename it.

[singular-value]

I'm going to start making some changes in my local Cirq fork to support qudit handling (well specifically, I want qutrit simulation, but I'll plan to write qutrits as the d=3 case of qudits).

Do you think there will be a reasonable case to merge my (planned) local changes into Cirq? I can see a case for keeping everything in core Cirq in qubits (it could be irritating for beginners to need to be aware of qudits). But if you were definitely planning on building qudits into Cirq, I could do my best to do it exactly as you planned (e.g. rename Qubit to Qudit?). Let me know if you have any comments/suggestions. Thanks!

-Pranav Gokhale (PhD student at UChicago with Fred Chong)

[Strilanc]

The main blocker for supporting qudits is the fact that cirq.Operation has a method called qubits, and I suspect there is code that assumes the matrix of an operation should have a width and height equal to 2**len(qubits).

One possible way to fix this would be to replace all matrices with tensors. This would replace the size assumption with a dimension-of-shape assumption (len(cirq.unitary(op)) = 2*len(op.quwhatevers)).

[dabacon]

Suggested names for QubitId:

QuId QId Quid Qid

The thing that will happen here that is odd is that methods that return "qubits" now return "quids" which is not really discoverable. Also places where we pass in Qubits no take quids, which is also kind of odd.

[Strilanc]

I vote Qid. Get your votes in now, everyone! @kevinsung @viathor @vtomole @maffoo @kevinsung @babbush @mrwojtek @Ashalynd @cduck @bryano @ Ican'tremembereveryone'sscreennames

[bryano]

What about QuditId? Or just Qudit?

The easy thing here is to have QubitId just be a special case of QuditId with the dimension attribute set to 2. Things could then be generalized to qudits gradually.

[bryano]

Of the given options, I'm for Qid as well.

[mrwojtek]

My vote goes to quid; it has a nice ring to it and one can make useful variations out of it easily: qubid, qutid, quqid, qupid, etc,. if ever needed.

[vtomole]

I'll go with @bryano. QuditId is self-documenting. From the multiple choices, i pick Qid cause it's the shortest.

[Strilanc]

Note that this concept is slightly more general than qudits. An id could also refer to e.g. couplers and resonators that are control elements of the system instead of state elements. Things you want to give commands to.

[bryano]

@Strilanc Do you have specific examples in mind of a "Qnob" that is not a qudit?

In any case, it seems useful to have all three constructs: qubit, qudit, and q-whatever.

Half-serious suggestion for the latter: "Qbar" (rhymes with "foobar")

[Strilanc]

I just think of it as "generic target of operation", or "things I might want to bounce particular microwaves off of at particular times". I think Qid is generic sounding enough to include stuff like resonators, plus it's short and I like short.

[maffoo]

+1 for Qid

[vtomole]

Casey, Pranav, et.al. have open sourced their Cirq fork implementation for Qudits (but mostly qutrits): https://github.com/epiqc/qutrits