-
Notifications
You must be signed in to change notification settings - Fork 0
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
Gates' matrices #20
Comments
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:
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 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). |
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).
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.
Agreed. That's why the plan is to keep them as isolated as possible, and conditionally compiled (in case we'll have them). |
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 dependenciesndarray
,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)
The text was updated successfully, but these errors were encountered: