[feature suggestion] sparse-dense abstraction layer

[smolkaj]

This is just an idea, but I think it would be nice to provide a vector/matrix interface that abstracts away the concrete encoding, spare or dense. The abstraction layer would automatically convert between encodings, transparently to the user. For example,

• multiplying two sparse matrices would yield a sparse matrix
• multiplying two dense matrices would yield a dense matrix
• multiplying a dense and a sparse matrix would either
  • if the dense matrix is spare, convert it to a sparse matrix and return a sparse matrix
  • otherwise, convert the sparse matrix to dense one and return a dense matrix etc.

Since sparsity checks may be expensive, an important consideration would be when and where to perform them. There could be both an automatic mode, where sparsity checks & conversions are performed fully automatically, and a manual mode, where the user could say explicitly through the API when to perform sparsity checks.

I think such an abstraction layer could be super useful for prototyping.

[ryanrhymes]

Good comment, really appreciate it. Indeed, interoperation on different number types is really desirable when fast prototyping. Most of the time in my research, I simply want to try something in utop quickly.

That is actually the motivation of Ext module in Owl. With Ext module, you can do basic math operations on different number types. Please refer to this tutorial: Operators and Ext Module.

But the price we pay for this convenience is: weaker type checking (by wrapping everything in one type) and performance degradation (due to the big match). I haven't really benchmarked about performance degradation yet. However, Ext is just an option for you to do fast prototyping. You can always use the corresponding functions in Owl for better type checking and performance. I think the the ultimate solution is whenever Modular Implicits is included in OCaml official release.

Currently, this interoperation only happens between dense data structures, but Sparse structure is definitely on my todo list. Actually, there is already placeholder in this file for the feature you suggested, I just need to implement the corresponding modules in that file.

Before this happens, I still need to refactor the sparse module a bit (dense module takes me most of the time at the moement).

[nilsbecker]

in my opinion abstracting sparse/dense is tricky. almost by definition, sparse matrices are big -- otherwise one would simply use dense matrices. but for big objects, you really want to be explicit about what you're doing to them, whether new memory is allocated etc. automating this is asking for unexpected out-of-memory situations.