-
Notifications
You must be signed in to change notification settings - Fork 61
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
Define a general agreement on what a Backend
should be able to do
#1474
Comments
Just to complement on this, I would like to summarize here the list of methods that are called through the git grep "self.np\."
git grep "backend.np\."
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now we support several backends, some inside
qibo
and others outside of it:qibojit
,qibo-cloud
,qiboml
,qibolab
...However it is nowhere defined what exactly each backend should provide to be compatible with the rest of the
qibo
API, for instance thequantum_info
module.At the moment we rely on the
self.np
orbackend.np
trick to trigger the "engine" of each separate backend. However this is neither consistent across the backends,PyTorchBackend
hasself.np = torch
whereasTensorflowBackend
hasself.tf = tf
andself.np = tf.experimental.numpy
orCupyBackend
hasself.np = numpy
andself.cp = cupy
, nor is enough to cover all the needed cases. A quick search withgit grep "if backend"
shows several situations in which we need to explicitely check which backend is used and act accordingly:git grep "if backend"
which is not a sustainable strategy with the inclusion of more and more backends. Especially, an external backend provider should be able to know which operations the backend has to support to have a reasonable "guarantee" of being compatible with
qibo
.I think, therefore, that we should compile a list of necessary functionalities, i.e. backend methods, that every backend has to expose to grant compatibility.
The text was updated successfully, but these errors were encountered: