You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 CNOTstructs 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.
The text was updated successfully, but these errors were encountered:
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
, andCNOT
structs will implement theGate
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 languagetrait
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 whatenum_dispatch
is actually using, though stopping to singletons - no guarantee we could bind this to other languages, but maybe we don't even have toI 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.
The text was updated successfully, but these errors were encountered: