I think the poster above clearly understood the problem domain, in that the most common uses for "sparse array" is a "sparse matrix" for numerical computations.

And moreover, as is the case, the problem domain of matrix computations is known to be deep and problem-dependent, with a wide variety of representations and solution categories.

| But by all means, go ahead and implement your own formats for each of the various types of sparse matrices you are likely to encounter. Then optimize operations for each. Then implement complex algebra (eigenvalues, svd, QR, the works). In the end, hope that your brand spanking new wheel has no corners and works for enough use cases to justify not employing a standardized wheel. A smarter person than me said something along the lines of premature optimization and evils, but I suppose it does not apply to your brand of genius.

I see an unjustified insult against the previous poster.

The various cases and solvers have already been implemented in many important software packages for different domains, and given the centrality of matrix operations in high performance computing, this is not a premature optimization but rather the essential, core implementation and algorithmic optimization flowing from the proper mathematical treatment of the problem.

And his point was not at all to re-do everything yourself, but to be aware that there are in fact many varieties of sparse matrices in various settings and that this is not just a software-abstraction problem but a key mathematical problem, and there is no simple over-arching software abstraction that works well universally. The post described well-established problem domains with high-quality solutions.

Simply being aware of this not-always obvious fact is an example of scientific maturity.