Implement a `GraphQubit` type about cirq

[Strilanc]

QubitId is the fundamental type that gates care about, so it is very easy for others to implement their own. We don't have to do it for them.

I do think that QubitLoc should be moved into the google folder, and possibly renamed to XmonQubit.

[dabacon]

XmonQubit would be good. But there are certainly places where we are using adjacency information in gates. I think having qubits that have adjacency info is a good thing to support, and is a very general concept that is applicable to many use cases.

…

On Tue, Feb 13, 2018 at 3:35 PM, Craig Gidney ***@***.***> wrote: QubitId is the fundamental type that gates care about, so it is very easy for others to implement their own. We don't have to do it for them. I do think that QubitLoc should be moved into the google folder, and possibly renamed to XmonQubit. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#95 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFXpqLjofqmb1soRaZIqNcj8oLxM5YBks5tUhwrgaJpZM4SEhxe> .

[mrwojtek]

As a prerequisite to #470, some extension of interfaces discussed here is required. What is required for placement code is:

• a method to retrieve all qubits,
• a method to resolve qubits connectivity,
• a method to provide qubits and connections costs,
• a method to provide information which interactions exclude which qubits from participating in other interactions.
• a method to lay out a List[LineQubit] on arbitrary device.

I started to think about creating GridQubit, as discussed with @Strilanc, but all the methods I could think about fit GraphQubit much better:

class GraphQubit(metaclass=abc.ABCMeta):

    @abc.abstractmethod
    def can_interact/is_adjacent(self, other: 'GraphQubit') -> bool:
        pass

    @abc.abstractmethod
    def quality(self) -> float:
        pass

    @abc.abstractmethod
    def interaction_quality(self, other: 'GraphQubit') -> float:
        pass

    @abc.abstractmethod
    def interaction_qubits(self, other: 'GraphQubit') -> Set['GraphQubit']:
        pass


class GraphDevice(metaclass=abc.ABCMeta):

    @abc.abstractmethod
    def qubits(self) -> Iterable['GraphQubit']:

    @abc.abstractmethod
    def neighbors_of(self, qubit: 'GraphQubit') -> Iterable['GraphQubit']:

    @abc.abstractmethod
    def map_to_line(self, qubits: List['GraphQubit']) -> Iterable['LineQubit']:
        pass

What do you think about this?

[Strilanc]

@dabacon Do we need a graph qubit for the next milestone? My impression is that we don't; it's more abstract than what we need. At most we would need a GridQubit for 2d points, which is currently played by Xmon.

[dabacon]

We're going to need to deal with more arbitrary adjacency for ion trap devices, so I think we will need something like this. One thing to note however is that I don't think we want to have objects like quality on the qubits themselves. In my mind the QubitId is the generic object, and these sub-classed Qubits are about laying out a structure for thinking about moving from one qubit to another, BUT that might not even correspond to the allowed interactions. So it's more like the abstract layout of the qubit, and putting things like quailty (of which gate? what quality?) is something that will come from elsewhere (essentialy it should be at least close to the hardware spec)

[bryano]

It seems more natural for adjacency and gate information to be part of the device rather than the qubit. Why not just give GraphDevice a graph attribute whose vertices can be generic QubitIds?

[vtomole]

@bryano Is this related to all of your not-yet-merged pull requests?

[bryano]

Yea, specifically #1181

[bryano]

Can this be closed?