Add support for > 2 qubit quantum operations with known decompositions in IonQ device.
See original GitHub issueIs your feature request related to a use case or problem? Please describe. IonQ device supports arbitrary 1 and 2 qubit gates and provides decompositions to hardware native gates. However, for gates with > 2 qubits, it simply raises an error: https://github.com/quantumlib/Cirq/blob/12530f1531e5da663a6b172b1967763e08819912/cirq-core/cirq/ionq/ionq_devices.py#L104
Elsewhere (for eg, in Google’s Sycamore device), we tend to fallback on the default decomposition strategy, if available, for such operations. https://github.com/quantumlib/Cirq/blob/12530f1531e5da663a6b172b1967763e08819912/cirq-google/cirq_google/optimizers/convert_to_sycamore_gates.py#L126
I wonder whether it’s a conscious choice to not rely on the default decompositions or it just got missed ?
Note that, so far, the default strategy to define composite operations in Cirq is to create a new gate with specified decompositions to simpler gates. Some examples of such gates are QuantumFourierTransformGate
etc. Ignoring the default decompositions leads to not supporting such composite gates, which is bad? For eg:
num_qubits = 3
qubits = cirq.LineQubit.range(num_qubits)
cirq.Circuit(cirq.QuantumFourierTransformGate(num_qubits)(*qubits), device = cirq.ionq.IonQAPIDevice(qubits))
The above code works fine for num_qubits = 2
but fails for num_qubits > 2
with the following error:
ValueError: Operation {operation} not supported by IonQ API.
The error message should also be fixed as it’s not an f’string 😃
What is the urgency from your perspective for this issue? Is it blocking important work?
P3 - I’m not really blocked by it, it is an idea I’d like to discuss / suggestion based on principle
Issue Analytics
- State:
- Created 2 years ago
- Comments:6 (2 by maintainers)
Passing over to @Cynocracy please yell if you want help on any of these ionq issues.
This is fixed by https://github.com/quantumlib/Cirq/pull/5479