Adding in folder for Tensor<T> info #315
Conversation
ericstj
requested review from
NiklasGustafsson,
stephentoub,
tannergooding and
eiriktsarpalis
There was a problem hiding this comment.
The proposed folder isn't really used anymore, instead things are meant to go directly into the accepted folder (the PR being merged is what makes it "accepted") and is meant to follow the general folder structure.
Thus, this would go under accepted/2024/tensors instead.
CC. @terrajobst
|
Correspondingly, you should also follow the general instructions under https://github.com/dotnet/designs/tree/main?tab=readme-ov-file#creating-a-proposal, to ensure it doesn't conflict with the design doc I'm working on and that it is correctly indexed |
| | long | X | X | X | X | X | | ||
| | ulong | X | X | X | X | X | | ||
| | bool (byte) | X | X | X | X | X | | ||
| | string (bytes) | | X | X | X |
There was a problem hiding this comment.
@NiklasGustafsson @tannergooding is using tensors with string elements common? It seems like it might be difficult to reconcile with a tensor type that has a generic number constraint.
There was a problem hiding this comment.
Same concern applies to a few other types in this list.
| | Supports Sparse Tensors | X | | X | X | | | ||
|
|
||
|
|
||
| * Both Numpy and TensorFlow support Non-Contiguous memory, but its often less performant |
There was a problem hiding this comment.
| * Both Numpy and TensorFlow support Non-Contiguous memory, but its often less performant | |
| * Both Numpy and TensorFlow support Non-Contiguous memory, but it's often less performant |
|
Closing as the info is being used directly in Tanner's PR. |
Adding in a folder under proposed for all the Tensor information. This folder for now contains the type/memory comparisons for tensors in different frameworks. More documents will be added to this folder in the future.