-
Notifications
You must be signed in to change notification settings - Fork 42
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 Request: Tensor Abbreviations #103
Comments
This is neat, but I don't think I will add it. I think this type of feature should be done with variables and not shorter strings. |
Do you want me to do a PR anyway, but with the abbreviations removed? It should be transparent above the schema level. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is actually more of a discussion thread since I have an implementation here, but I wanted to discuss the general idea before submitting a PR.
Essentially, I propose that we allow to access a tensor dimension by a one-character abbreviation as well as its name. This would make working with namedtensors a lot less verbose, however this might go against the general principles of namedtensor as ensuring greater safety.
Example:
Given tensor
t = ntorch.ones(2, 3, 5, names=('batch', 'width', 'height'))
then we can refer to these dimensions just by their first letter sot[{'b': 0}]
is equivalent tot[{'batch': 0}]
If there's ambiguity in abbreviations, we allow creation of the tensor:
But we throw an ambiguity error if we try to access in an ambiguous fashion:
To enable abbreviations to still be used with ambiguous names, we allow setting the abbreviation manually with
a:name
:Unfortunately this required a lot of code rewriting and adds a little bit more complexity,although the result is arguably more elegant, see the comparison. However I believe this is worthwhile, especially as it makes it easier to add in other features such as dimension labels.
The text was updated successfully, but these errors were encountered: