Narrower types for overhead storage yield a smaller memory footprint for
sparse tensors and thus needs to be supported. Also, more value types
need to be supported to deal with all kinds of kernels. Since the
"one-size-fits-all" sparse storage scheme implementation is used
instead of actual codegen, the library needs to be able to support
all combinations of desired types. With some crafty templating and
overloading, the actual code for this is kept reasonably sized though.
Thanks for your work! It looks good to me and I only have a few minor comments.
Instead of saying "unsupported", would it be more helpful to say something more specific, such as the requested the data type doesn't match how the data is stored in SparseTensorStorage?
We probably don't need this until it needs an implementation that is different from what is in the base class.
The previous word was fine. It is "pointer structure" not "pointers structure". Right?
Similar to the above.
This is called sparsity in class SparseTensorStorage. Why don't we call it sparsity here?