search

quantumlib / Cirq

A Python framework for creating, editing, and invoking Noisy Intermediate Scale Quantum (NISQ) circuits.
Apache License 2.0
4.23k stars 1.01k forks source link

Supporting TFQ using IonqDevice #4769

Closed Cynocracy closed 2 years ago

Cynocracy commented 2 years ago

Is your design idea/issue related to a use case or problem? Please describe. Use case: using TF quantum with devices that have all to all connectivity but which address qubits linearly.

https://github.com/quantumlib/Cirq/issues/3447 is related, but we (Ionq) have support for all-to-all, but we enforce LineQubit because logically, the qubits are identified by location on the ion trap.

Describe your design idea/issue

Issue: TesnorFlow quantum only supports GridQubits as documented here https://www.tensorflow.org/quantum/api_docs/python/tfq/convert_to_tensor?hl=hi

Idea: support translating GridQubits into LineQubits for devices that have all to all connectivity.

Filing this to get feedback from the community, as I don't know much about the intent of these classes. Naively, I would assume that it would make sense to extend LineQubit (1d nearest neighbor), GridQubit (2d nearest neighbor) to AllToAllQubit (1d all 2q gates supported). Am happy to discuss other ways to solve the issue though :)

Cynocracy commented 2 years ago

cc @dabacon

dabacon commented 2 years ago

I believe that TensorFlow quantum has support for LineQubit's but this has not yet been released. https://github.com/tensorflow/quantum/pull/641 You should be able to get access to it by installing the nightly version of TFQ pip3 install -U tfq-nightly.

I think that support for LineQubit in TFQ is probably better than translating from GirdQubit or NamedQubit, but if we want to add some sort of support for this in cirq-ionq, we could do that (it would just be kind of adhoc...)

@MichaelBroughton any idea about timescale for the next TFQ release.

MichaelBroughton commented 2 years ago

Right, LineQubit support is now present everywhere in TFQ nightly builds. Would love it if anyone wants to poke around and see if things are working as intended. For the next TFQ release, we want to finish 1D MPS simulation which roughly entails:

  1. Merging this https://github.com/quantumlib/qsim/pull/490
  2. Cutting a qsim release. @95-martin-orion .
  3. Upgrading TFQ to that latest release.
  4. Reviving and merging https://github.com/tensorflow/quantum/pull/610 . @jaeyoo .
  5. Writing similar Sample and SampledExpectation versions of the logic above.
  6. Hooking this up to differentiators
  7. Cutting a release.

All this in mind I'd say an official release could be a month or two away give or take.

Regarding the more philosphical question of "should we design an all to all qubit type": I think the answer here is no, naming a type something like AllToAllQubit or other connectivity indicating variants like AllToOneQubit, ResourceToAllQubit etc. allow device related concerns to trickle down into the qubit types. Cirq currently has a device class (that will be undergoing a rework) who's job it is to look after these kinds of constraints. One way I think about this is: qubits serve as the adressing system, but devices serve as the next stage in validating a circuit. A device with qubits in a line might support all to all connectivity or there could be a totally different device with line qubits that might just support interacting with neighbors on their left and right. It feels like the device class is the right place to deal with these sorts of differences, otherwise we might get an explosion of different, but very similar sounding qubit types for each device we see in the future.

Cynocracy commented 2 years ago

Awesome, thanks for the info! Will let you know if we get a chance to test before things are released, I would definitely love to give it a spin 🙂

Re: leaking device behavior into other layers, I totally agree with your rationale. I'm curious to know if you think that GridQubit and LineQubit suffer from the same problem? I would think that if we don't want device properties to bleed into Qubit representations, it would make sense for them to be addressing veneers on the same primitive 'bag of Qubits' type used for serialization. You could imagine a new device with 3d addressing of Qubits wanting to use that addressing scheme, but today that would require changes to TFQ serialization (I think?)

Now whether it makes sense to actually plan a refactor like that, I don't rightly know 😅 mostly asking to confirm my own understanding of the libs.

Thanks again for the quick and comprehensive responses y'all!

Cynocracy commented 2 years ago

Had a chance to take tfq nightly for a spin, hit that we needed to implement https://quantumai.google/reference/python/cirq/work/Sampler and am taking a stab at it ;)

Edit, ha! and it's right there https://github.com/quantumlib/Cirq/blob/1d57c8197d3f5410873e7892d56d1902b1adf1ef/cirq-ionq/cirq_ionq/service.py#L115

Cynocracy commented 2 years ago

And with that, it all seems to be working well!

Thanks for the help folks :)