question about sparse routines matrix formats support

[JakubH]

Hi,

for example with the sparse-dense matrix-matrix multiplication routine: https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2025-0/mkl-sparse-mm.html

There is the table that lists which formats are supported in case of zero/one based indexing and and for row/column major layout of dense matrices.

I don't understand why e.g. for column-major layout and zero-based indexing, CSC sparse matrix format is not supported.

Calling the function with matrix A in CSR format and SPARSE_OPERATION_TRANSPOSE parameter is equivalent to calling the function with matrix A in CSC format and SPARSE_OPERATION_NON_TRANSPOSE parameter. But the latter is not supported. Why? Why do I have to do these workarounds myself, when you could easily implement it?

So, if you support the operation parameter, which effectively swaps between the matrix being CSR or CSC, why don't you also fully support both CSR and CSC formats?

Thanks,

Jakub

---

By the way this is not an issue only with MKL sparse, I see that most other libraries don't have this implemented, there must be a good reason for it, what is it?

[Aleksandra_K]

Hi,

Supporting different matrix formats isn't always as straightforward as performing simple operations like transposition. Some formats require unique optimizations to ensure that functions operate efficiently. We need to prioritize which formats to implement first based on their popularity and demand.

We really value your feedback, so if you have specific suggestions for adding a particular feature, please let us know.

Regards,

Aleksandra

[JakubH]

Hi,

thanks for the reply. I understand that adding support for another matrix format requires new code which requires further optimization.

But what I am talking about does not require any new kernel code, only some boilerplate code in the interface.

The key observation is, that a non-transposed CSR matrix and a transposed CSC matrix (or vice versa) are actually the exact same matrix (with swapped numrows and numcols and possibly uplo), so require exactly the same computation kernels. Swapping between CSR and CSC is equivalent to transposing the matrix (similarly you can swap between row-major and column-major layout of a dense matrix by treating the matrix as transposed). Calling the function with CSR matrix and non-transpose flag is the same as calling the function with CSC matrix and transpose flag.

So implementing support for both CSR and CSC formats should be as straightforward as implementing support for the transpose parameter. But the functions (e.g. mkl_sparse_?_mm) don't support both equivalents, as I described in the original post (e.g. for zero-based indexing and column-major dense layout, only CSR is supported, not CSC, but the transposition is still supported).

[Spencer_P_Intel · Accepted solution]

Hi Jakub,

You are, of course, correct that CSR and CSC formats have this nice transpose-relationship property similar to row-major and column-major formats in dense format(up to matrix dimensions needing to be swapped).  It means that if we happen to have a kernel that performs well on CSC format, then it could in theory, also cover CSR + Transpose and visa versa.  Many libraries have evolved through the years to use this duality, but often when we are prioritizing CSR format (one of the most commonly used formats for which new optimizations are regularly requested), we either miss or more likely purposely choose not to extend (due to other constraints) into other nearly immediately usable formats right then...  and sometimes this is because previous software design of the internals has not yet enabled sharing of kernels to be a simple thing (even though mathematically it is straight forward). 

Unfortunately CSC format has gotten the short end of the stick sometimes in our prioritizations, though we are planning on giving it more time than maybe has previously been given, many of our customer requests end up being for other formats...

Hopefully that makes sense...  Software design and development is always under some constraint or another (often time) and if we had all the time in the world, each format and each operation would get the full optimization treatment ... On the other hand, you do rightly point out that for some of these combinations, not even a default solution exists and that is something that we can do better at filling out. 

Best Regards,

Spencer

[JakubH]

OK, I understand.

Thanks for the reply