-
Notifications
You must be signed in to change notification settings - Fork 344
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
✨[Feature] Support list
and namedtuple
input types to forward
function
#798
Comments
@narendasan Let me know if the behaviors listed under Additional context make sense. In particular, I believe we currently ignore other input types going into I can try taking a crack at the implementation here later when I get a chance. |
Ah this might be a duplicate of #428, although this request might be slightly less ambitious. |
@chaoz-dev Yeah this is reasonable. We have been working on a design doc for these sort of features here #629. @inocsin Has been working on the first steps here with arbitrary mixes of tuples (since they are fixed size) and tensors as inputs and outputs. Need to check with him on if he has a public dev branch but help here is greatly appreciated. |
Sounds good, I'll take a look at the design doc and make some suggestions there for review. I had a quick look at the code and my naive first pass at this is to unpack input containers in |
Seems reasonable to take the step of adding support for one collection of inputs of any type. But we need to do this in |
Yeah that makes sense. I'll take a look at this shortly. |
This issue has not seen activity for 90 days, Remove stale label or comment or this will be closed in 10 days |
Initial feature support has been merged |
Is your feature request related to a problem? Please describe.
Currently, the
forward
function only supports tensor input types when compiling. However, sometimes we wish to supply many tensors into theforward
function at once (say, greater than 10); this results in a very longforward
API call where we have to list every tensor individually when callingforward
. It would be helpful if we could pass in a single container containing these tensors all at once instead, which results in a much cleaner API call.For this specific request, I focus on the
list
andnamedtuple
input types first, since these should cover most basic uses cases (and should functionally satisfy named tensor key-value pair type inputs).Describe the solution you'd like
Instead of supporting only the following, where we need to supply
torch.Tensor
s intoforward
:Support also inputting
namedtuple
orlist
intoforward
:Describe alternatives you've considered
Currently the only alternative is to supply tensors directly into the
forward
function; supplyingnamedtuples
will cause the compilation to segfault, and supplying lists will cause the compilation to fail to recognize the input altogether.Additional context
compile
call; ie. there must be oneInput
size for each tensor in the container and both are taken in the same order.forward
call (eg.forward(x: torch.Tensor, y: List[torch.Tensor], z: namedtuple[torch.Tensor])
). Any other types are treated as they are currently when input.The text was updated successfully, but these errors were encountered: