alecandido
commented
3 months ago @stavros11
It would be possible to recover part of the functionality of the symbols by implementing a simpler computational graph representation and interpreter directly in qibo-core, possibly using some other library (if available).
In this way, backends may receive the evaluated result directly from a qibo-core gates iterator. But it also means that qibo-core would implement a non-trivial part of execution (possibly opt-in, through conditional compilation), with a certain amount of extra maintenance burden, for a project that aims to be as light as possible.
If instead the computational graph is directly exposed to the backends (another non-trivial option), it might be possible to compile a small amount of functions even on real-time hardware (this would be up to Qibolab).
I'm not sure whether it will ever be relevant. I just wanted to advertise the option, but for sure I would fully ignore it for the current implementation.
In #30, @stavros11 mentioned the option of having a separate gate to represent a collapsing measurement.
While this may be not ideal for the high-level interface (or maybe it is good as well, is it?), it is for sure useful for execution, since a collapsing and non-collapsing measurement are acting quite differently.
A further option, restricted to collapsing measurement, is to condition subsequent gates. This option is also available on hardware (introducing some complications in the experiment timing, but perfectly available). Currently, Qibo allows for an immensely vast amount of operations, since a symbol representing the outcome of the measurement is returned, that can be used in any other parametrized gate, evaluating a function that contains it. This chance was available only because most of the backends were simulation ones, sharing the same implementation language. Indeed, the function to be evaluated was essentially a Python function (not exactly, because it was actually a Sympy computational graph). In order to target multi-language backends, all the backends should be able to run an interpreter capable of executing these functions, that is almost impossible on hardware in real-time, but barely feasible even on simulators in a different language.
Because of this, the proposal is to retain only a single functionality in
qibo-core: branching. This means that it will be possible to condition the execution of some gates on the result of one or more measurements gate (if multiple ones, they will be treated in AND - any of them being returning the0state will prevent the gate to run).