Open pedrorrivero opened 3 years ago
Hi, I am interested with this project (listed in the unitaryHACK). Could you please elaborate a little bit more or share some guide? Thanks a lot!
Hi @eraraya-ricardo! Thank you so much for reaching out and showing interest.
In the next few days (before UnitaryHack officially begins on May 14) I will be pushing a new version of QRAND to the master
branch with a complete restructure of the source code. You can find a production version in the dev
branch.
In there, you will find a subpackage named platforms
containing modules for the following interfaces: QuantumPlatform
, QuantumBackend
, QuantumJob
, and QuantumCircuit
. Additionally there will be three more subpackages inside for each of the platforms that we need to implement (i.e. qiskit, q#, and cirq).
The goal is to implement those three interfaces in the modules CirqPlatform
, CirqBackend
, CirqJob
, and CirqCircuit
. You can take a look at the already implemented Qiskit versions for inspiration.
Let me know if you had any other questions, and good luck!
Dear @pedrorrivero, I have looked into the code, but I don't understand why we have to use the QuantumCircuit class as a parent for the QiskitCircuit as all of the methods in QuantumCircuit are empty (pass).
Instead of QuantumCircuit class, shouldn't the QiskitCircuit class inherit the QiskitQuantumCircuit? Since QiskitQuantumCircuit is the one that comes from the Qiskit package. I don't see how the QiskitCircuit class can access QiskitQuantumCircuit class methods by just inheriting QuantumCircuit class.
Sorry if this turns out to be a noob question haha, I am not too familiar with Python software development.
Hi @eraraya-ricardo!! Thanks for asking.
QuantumCircuit
is an interface. Roughly speaking it is meant to enforce certain methods on child classes in order to make them interchangeable. That way the rest of the code (or even the user) does not need care whether it is using CirqCircuit
or QiskitCircuit
, all it has to know is that it is using a QuantumCircuit
. It is a way of decoupling usage from implementation detail, and to make sure we all adhere to the same format when developing for different platforms.
TLDR: those methods are empty because you HAVE TO implement them for Cirq with that exact same signature, just as I did for Qiskit.
If you have any other doubts we can chat a bit more on Discord 🙂
Ok, let's discuss via Discord to minimize the spam here.
Hi! @pedrorrivero I am also working on this. I have implemented the CirqCircuit
. Please correct me if I'm wrong, unlike Qiskit which provides a unified backend API as abstract class BackEndv1, Cirq doesn't provide anything like that. So when we are implementing CirqBackend
, are we talking about the Quantum Engine API
provided in the cirq-google
, or do we want to wrap it in cirq.sim.simulator
for a custom simulator.
Hi @harry-stark! Thanks for showing interest.
So, I am not very familiar with Cirq, but I would say that CirqBackend
should be precisely that "unified backend API" for Cirq: meaning that it should handle both the Quantum Engine API as well as any simulators.
Generally, all that can be used to run a given circuit should be encapsulated inside the CirqBackend
.
Later, CirqJob
will bring together both a backend and a circuit and take care of the execution and any related parameters (e.g. number of measurements to be performed).
Hope this helps!
@pedrorrivero We can make a CirqBackend
and CirqJob
which can provide all the functioning require to run qrand in Google Quantum Computing Service similarly to IBMQ. But for simulators(that are not available in Google QCS) it is another story Cirq does not provide a common backend API for simulators. Unlike "Qiskit provider API" we have to implement an interface depending on the type of simulator qrand will interact with.
@harry-stark I see. What I meant was: can't you manually integrate both?
The following classes need to be developed implementing the corresponding interfaces:
CirqPlatform
←QuantumPlatform
CirqBackend
←QuantumBackend
CirqJob
←QuantumJob
CirqCircuit
←QuantumCircuit
The first of these classes follows the Facade/Abstract Factory pattern, while the other two are Class Adapters. For an example check the Qiskit variants.