Support custom parameter in sequence template functions #331
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR enables custom parameters in the template functions
sequence.record(..)
,sequence.eval(..)
andsequence.evalAsync(..)
by replacing the specializations with a more generic approach.In theory the compiler should be able to deduce the correct Constructor of the passed Operation class if there is just one. However it seems to require at least the first argument type to correctly deduce the constructor when given an initializer list like
eval<op>({...})
.Currently this done with template specializations that passes either
std::vector<std::shared_ptr<Tensor>> tensors
orstd::shared_ptr<Algorithm> algorithm
to disambiguate the templates.I found a way to supply this first parameter type through the respective Operations class itself, rather than hard-coding them as template specializations.
This makes the code a little compacter, but more importantly it allows custom user operations to use the same template and thus, nice syntax.
This turns
into
The only change to existing operations is the addition of the first constructor type to each class.
The current functionality is not changed otherwise.