search

qiboteam / qibo-core

Core qibo elements
https://qibo.science
1 stars 0 forks source link

Gates' matrices #20

Open alecandido opened 2 months ago

alecandido commented 2 months ago

Some backends, especially external ones*, may already have definitions for the gate matrices. For this reason, I avoided encoding the matrices until now, since they are not always required.

However, backends designed within Qibo will often make use of these matrices, and there is no reason to repeat them, or to have a further dedicated package (with one million bindings) just for them.

The optimal solution I currently see is to define them within qibo-core, but behind a feature gate (including the obvious dependencies ndarray, rust-numpy, ... - there is limited utility in avoiding them), i.e. they will be conditionally compiled.

*i.e. where the quantum simulation is fully developed outside Qibo (but it also applies for some internal backends, with a non-matrix representation, e.g. Qibolab and Clifford)

stavros11 commented 1 week ago

The optimal solution I currently see is to define them within qibo-core, but behind a feature gate (including the obvious dependencies ndarray, rust-numpy, ... - there is limited utility in avoiding them), i.e. they will be conditionally compiled.

This solution sounds good to me, as long as we are able to load these matrices from Rust to other languages. I am not sure how easy is to have arrays/vectors accessible by different languages, but you probably know more on this.

Two potential arguments about why gate matrices are NOT "core" objects are:

  1. They are not needed by all backends. Qibolab does not need them, instead needs to map gates to pulse sequences (current compiler). Clifford backends probably also don't need, but I am not sure.
  2. Even backends that need matrices, do not always use the same matrices. For example, currently the NumpyBackend uses a 4x4 matrix for CNOT, while qibojit uses the 2x2 Pauli-X matrix for the same gate, because it implements the control using indexing of the state.

However, I think none of these are very important. For 1, backends can ignore matrices if they don't need them (which would make matrices redundant in that case, but well...). For 2, it should no longer be valid after #29 is implemented, as controls will be applied with indexing by all backends (the .is_controlled_by branch of apply_gate for the NumpyBackend) and if that is not possible we could just provide a function to control at the matrix level (https://github.com/qiboteam/qibo/pull/1367).

The clear advantage of putting matrices in qibo-core is that we don't have to repeat their definition multiple times in the backends. The disadvantage is that we make qibo-core slightly more complicated and external backends more dependent on it, as in if I have to add my own backend, I would probably have to comply with matrices provided by qibo-core to do things properly (even though in principle I could still get away with using my own matrices somehow, I guess).

alecandido commented 1 week ago

This solution sounds good to me, as long as we are able to load these matrices from Rust to other languages. I am not sure how easy is to have arrays/vectors accessible by different languages, but you probably know more on this.

For as long as they are C-like arrays, that should be fairly simple. Vectors could be slightly more complicated (because, for C, and everything directly using it, you should essentially bring them down to the arrays as well).

Two potential arguments about why gate matrices are NOT "core" objects are:

  1. They are not needed by all backends. Qibolab does not need them, instead needs to map gates to pulse sequences (current compiler). Clifford backends probably also don't need, but I am not sure.
  2. Even backends that need matrices, do not always use the same matrices. For example, currently the NumpyBackend uses a 4x4 matrix for CNOT, while qibojit uses the 2x2 Pauli-X matrix for the same gate, because it implements the control using indexing of the state.

Yes, I had the first argument in mind, and I assumed I wrote them in the issue. But that's not the case, thanks for putting them black-on-white. The other one I hope it will be solved as well.

The clear advantage of putting matrices in qibo-core is that we don't have to repeat their definition multiple times in the backends. The disadvantage is that we make qibo-core slightly more complicated and external backends more dependent on it, as in if I have to add my own backend, I would probably have to comply with matrices provided by qibo-core to do things properly (even though in principle I could still get away with using my own matrices somehow, I guess).

Agreed. That's why the plan is to keep them as isolated as possible, and conditionally compiled (in case we'll have them).