If you don't have that information, you can look at how your matrix will be accessed. Do you need fast access to random rows, or columns? Do you need to write new values? Are those values already in the sparsity structure?
All of these questions can lead you to choosing the right sparse format, but it does take some experience to know where to look.
I think this is one of those shibboleths that separate folks who are experts in ML/data-science at scale vs those who are coming more from a enterprise/DBA background. I often have to convince folks why its not a great idea to write sparse matrix multiplication in SQL.
For many domains, it's a big worry. I routinely encounter large, sparse datasets where I/O and storage dominate other concerns. Big sparse tensors are worse than the "slowness" associated with a suboptimal sparse vector math implementation.
"I think this is one of those shibboleths that separate folks who are experts in ML/data-science at scale vs those who are coming more from a enterprise/DBA background."
I've been doing ML work for a long time. This is actually a shibboleth that separates folks who mostly do image classification from other kinds of ML people.
Interesting comment regarding image classification. I would have assumed they are the ones who don't have to worry about sparsity much. Physics, and image and video are some of the places you encounter large and dense matrices. Lapack's wet dream :)
But it also seems like for a given sparse matrix in a given situation, there's no guaranteed that there's algorithm for handling it. The whole thing requires deep experience or black magic.