Add optional qubit_set property to cirq.Device

[Strilanc]

• Make 'validate_operation' optional to implement
• qubit_set falls back to looking for qubit/_qubit fields/methods, otherwise returns None

This makes devices easier to consume (because a common task is to want to view the qubits, knowing that the device is not the unconstrained device) and easier to make (because when prototyping you don't care about validating operations yet).

The shortest interesting device class now looks like this:

class CustomDevice:
    def qubits(self):
        return cirq.LineQubit.range(6)

or this:

class CustomDevice:
    def __init__(self, qubits):
        self.qubits = qubits

[dstrain115]

This seems fine, but I would like to understand a bit more about what we are trying to accomplish with Device. It would be better to have a long-term strategy than have it grow organically.

(Though, having a set of qubits seems pretty standard to a Device, so I don't foresee any issues)

[dstrain115]

This is redundant with the Returns statement. I would probably keep one or the other rather than repeating it.

[Strilanc]

Done.

[maffoo]

As @dstrain115 mentioned, it'd be nice to have a plan for where we are going with Device so that we can converge on an interface in the future and get rid of this hack. Maybe create an issue to track this and reference the issue number here.

[Strilanc]

Acknowledged.

[maffoo]

Should be _qubits

[Strilanc]

Done.

[mpharrigan]

echoing others' comments about long-term-plan. "Qubits" are inexorably linked to gate sets.

Is set the right data structure here?

1. introduces asymmetry between the constructor and the property. You give a list but duplicates and order is "erased"
2. Confusion around the order of the returned thing and/or you can't index in

I might want to write:

qubits = Sycamore.qubits
cirq.Circuit(cirq.CNOT(qubits[0], qubits[1]))

but that's not possible, so I might write

qubits = list(Sycamore.qubit_set())
....

and then wonder why my program is different after python changes set ordering / we change how qubits are fed into the device constructor / who knows what

[Strilanc]

and then wonder why my program is different after python changes set ordering / we change how qubits are fed into the device constructor / who knows what

Sets preserve order in python 3, so you shouldn't see the order change like that.

[CirqBot]

Automerge cancelled: A status check is failing.

[Strilanc]

I have discovered that sets do not preserve order in python 3, only dictionaries.

[CirqBot]

Automerge cancelled: There are merge conflicts.

[CirqBot]

Automerge cancelled: A status check is failing.

[mpharrigan]

I have discovered that sets do not preserve order in python 3, only dictionaries.

See my concerns above. I think it will be more helpful to have ordered qubits in a device