ST: Finalizing the subtensor
Implementation.
#4
exclowd
started this conversation in
Project Subtensor
Replies: 1 comment 1 reply
-
I favor your second proposal.
I am not sure if we need a change. Perhaps you could provide a small example how a new
Correct. However, |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Before beginning to work on the
subtensor
implementation, I wanted to get everyone's views on implementing it. To me, there seem, two candidates, as I highlighted in my project proposal as well. Note I am comparing them from a design point of view only, as it seems there would not be any performance differences between the two cases.subtensor
as an independent type: This is the current implementation present here. It would be easier to build on top of this.subtensor
as an engine. This would create a better design IMO since there would be nothing assubtensor
, and it would essentially be atensor
. However, this might not be as straightforward to implement as having a separate type as we might need some changes in thetensor
itself to accommodate a new engine.The
subtensor
is so that any library user would(normally) not create and only be created by member functions and operators oftensor
.Since we already have an implementation corresponding to
1
, maybe I could create an implementation on the same lines as2
. Maybe that could help in the decision-making process?Well, that's all that I think. But, of course, it would be great to see other's points of view as well.
Beta Was this translation helpful? Give feedback.
All reactions