Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: add the Rigetti Forest API as a backend #250

wants to merge 6 commits into from


Copy link

@mapmeld mapmeld commented Jul 29, 2018

Hi - this is still a work in progress, but I wanted to share it with the ProjectQ team now in case you have concerns or comments

I want to make ProjectQ more portable / universal by adding the Rigetti / Forest API as a backend

Rigetti has an assembly-like language for quantum computers (Quil) similar to QASM, a QVM (quantum virtual machine), and limited access to real quantum processors... so in many ways it is similar to IBM's offering. In 2017 I created a "jsQuil" module to create and run quantum programs from a Node.js environment. This would be a similar setup and you can see how I've started to make that work here

My next steps would be to check that implementation details are correct (which gates are and aren't allowed). Also I am a little uncertain of the equivalent of IBM5QubitMapper.

Copy link

Hi @mapmeld and thanks for starting to work on this!

I think it would be great to have more openly accessible hardware backends in ProjectQ. We were going to interface to Rigetti's chip a while back, but the terms for getting an API key were way too restrictive. I will check if these have changed in the meantime and if so, this would be a great contribution!

Concerning the mapping: The qubits of the 8-qubit chip seem to be arranged in a circle, so you can simply use the 1D chain mapper with periodic b.c. For the larger chip, one could implement a general mapper for arbitrary connectivity graphs with some (simple) heuristic, or just rely on the user to perform the mapping via a ManualMapper engine.

Copy link

mapmeld commented Aug 1, 2018

@thomashaener I am emailing with the Rigetti team now - once I have the API tested out on QVM jobs, they can schedule some time for me to test that it works with the real "QPU" devices, too

This is my first time reading this concept of mapping qubits, so I don't understand exactly. From the linear mapper example, it looks like... it depends how qubits are physically arranged because only nearby qubits can be connected through a quantum logic gate. That makes sense but I don't have insider knowledge. Is this something where it's easy to inherit from linear mapper, or that I should ask their team for advice on?

Copy link

Sounds good, thanks!

Yes, you can just use the linear mapper. When implementing an algorithm, you don't have to worry about the connectivity of the hardware. You can assume all-to-all connectivity and the compiler then takes care of mapping the circuit to the connectivity graph of the underlying hardware. This includes swapping a qubit around in order to make it adjacent to another qubit which it is supposed to interact with via, e.g., a CNOT.
We currently have 2 mappers in ProjectQ which do this; one for linear chains (which you can use here for the 8-qubit chip), and one for a 2D grid. You don't need any insider knowledge, you simply have to add a LinearMapper to your compiler engine list, which then looks similar to the list at

Copy link

mapmeld commented Aug 4, 2018

I got some programs running on Rigetti's QVM and returned results from the async job!

Gate compatibility issues (this may be me not knowing different names for the same gates, or different ideas of what counts as 1 or 2 gates)

Gates which ProjectQ/IBM have, but I had questions on:

[edit: resolved] Quil PHASE = ProjectQ's Phase-shift (R) 
Rx, Ry, Rz... I currently call Rx(0.25) and output 'RX(pi/4)' in Quil.
- If I call Rx(-0.25), I get angle 0.0811927499838429, why?
Tdag (Tdagger) and Sdag as inverse of T and S - I don't know how to represent this, NOT T ?

Gates which Rigetti/Forest/Quil has, but I didn't see their match here:

I gate ("identity")
CZ ("controlled Z")

Plus classical programming which I'll read up on with ProjectQ:

Wait, reset, NOP, HALT

Copy link

You can check the matrix of our gates to compare. Most of them are in
Ph is a global phase, so it's most-likely not what you are looking for.
projectq.ops.Rx does not have a math.pi in its definition.
What do you mean by

If I call Rx(-0.25), I get angle 0.0811927499838429, why?

Which Rx are you calling, and how do you get the angle?

To invert gates, you can do from projectq.ops import get_inverse and then, e.g., get_inverse(Rx(-0.25)) | qubit.

CZ is in projectq.ops, just make sure you have the newest version of projectq. In older versions, you could do from projectq.ops import C and C(Z) | (cqubit, target_qubit). CNOT and Toffoli can also be found in projectq.ops: from projectq.ops import Toffoli, CNOT. CSWAP is C(Swap), where Swap can be imported from projectq.ops.
If you have the gate matrices of the remaining gates, feel free to add new gates, it's really simple.

As a general note: In ProjectQ, controlled gates are represented as gates with additional control qubits; so when your backend gets a command cmd which describes a CNOT, then cmd.gate == X but the list of control qubits cmd.control_qubits will have length 1 and contain the control qubit. cmd.qubits is a tuple of quantum registers. For the CNOT, the tuple will have 1 quantum register of length 1 (the target qubit).

I would focus on the quantum instructions for now. We can then still add classical gates once everything works with quantum-only. Our reset would just be deallocation followed by a new allocation. Classical NOT = Quantum NOT applied to classical bit (=qubit which has been measured). But I would do this part in a second iteration.

Copy link

mapmeld commented Dec 6, 2018

Long time without me updating this! I got in sync with the latest develop branch, then made some changes to get Controlled gates, SWAP, Phase, and the Sdag and Tdag gates all working here.

I plan to change the tests and mock API responses in the next week

Copy link

Hi @mapmeld - saw your recent activity here, and wanted to chime in on behalf of Rigetti. In particular, I wanted to note that we're moving away from the http endpoint in favor of a new message spec called rpcq, which you can find here Please let us know if there's anything we can do to help- hopefully it should be easier to work with.

@thomashaener thanks for your feedback about the terms of service. We updated them in October, in part as a result of to the feedback you shared with me last summer. Let me know if you think the terms are still too stringent!

(cc @mpharrigan)

Copy link

mapmeld commented May 7, 2019

As mentioned earlier, the Rigetti API has changed a lot, and this branch is no longer able to communicate with a QVM or QPU.

If someone stumbles on this issue later, I have a JS library which I maintain at

@mapmeld mapmeld closed this May 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

None yet

3 participants