Skip to content
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

Gate implementation #8

Open
alecandido opened this issue Apr 5, 2024 · 0 comments
Open

Gate implementation #8

alecandido opened this issue Apr 5, 2024 · 0 comments

Comments

@alecandido
Copy link
Member

Here the problem is slightly more subtle.

The idea is that we have many objects of different types, but all similar to each other. This usually means that they all inherit from the same parent class.
Not all the languages however have classes and inheritance. Luckily, Rust is one of those, so we are facing the problem immediately.

In Rust, the idiomatic way of expressing this idea is using traits (for those unfamiliar, you could consider them as an interface declaration). Then our H, X, RY, and CNOT structs will implement the Gate trait.

However, then we will have to handle a generic Gate in many situations. E.g. when collecting a list of gates (in a circuit), or when applying a gate (which you do not want to implement for each and every gate times each and every backend).

The possible schemes involved are dynamic dispatch and possible replacements.

One nice replacement is the following: https://gitlab.com/antonok/enum_dispatch, coming with a nice speed-up.
However, it's one more external dependency, that I'd be glad to avoid for our core (neither I want to manually reimplement the features, since macros do not always match the concept of "simple").

However, the other relevant problem are the bindings. Indeed:

  • struct is universal, together with functions that's the only thing that is guaranteed to be available in every language
  • trait is very Rust-specific, but we might have similar ways to implement dynamic dispatch in other languages (e.g. in Python is for free)
  • enum seems innocuous, until they contain other structs and tuples (a.k.a. algebraic data types, or simply sum types), this is what enum_dispatch is actually using, though stopping to singletons - no guarantee we could bind this to other languages, but maybe we don't even have to

I will first experiment with enum_dispatch, to check whether it's possible to bind to Python, C, and C++.
However, I expect we don't really care about this speed-up, since the heavy lift will happen in linear algebra, as usual. Thus, I intend to revert to dynamic dispatch, and avoid the dependency.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants