spmv: low-level API based on existing high-level API

[jvdp1]

Here is a proposition to add low-level API based on existing high-level API for spmv.

It is currently only for COO, to illustrate the proposition.

If there are no oppositions, I'll continue the implementation of low-level API for the other sparse matrices.
Some discussions will be needed about the names and API.

[jalvesz]

I think this is a good idea @jvdp1 and was exactly one of the reasons for breaking the spmv into files per type. I've been pondering also about which would be the best strategy to interface such low level kernels with also a view into enabling linking against libraries such as MKL (https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2025-2/sparse-blas-level-1-routines.html), NVPL (https://docs.nvidia.com/nvpl/latest/sparse/storage_format/sparse_matrix.html) and AMD (https://rocm.docs.amd.com/projects/rocSPARSE/en/latest/) . They all follow a structuring close to Sparse BLAS level 1,2 and 3, but they do use Classes to abstract away the data handlers for the matrices. I've been wondering if using iso_c_binding it would be possible to have C-preprocessing build-time switchs to either use the internal low-level kernels of stdlib or to link against such libraries.

I guess the first thing that could be tried is to have a "sparse_blas" like folder with the level2 procedures in non-oop version. And from there figure out the next steps ?

[jvdp1]

I think this is a good idea @jvdp1 and was exactly one of the reasons for breaking the spmv into files per type.

Good! I will push some low-level API, with some tests and specs.

I've been pondering also about which would be the best strategy to interface such low level kernels with also a view into enabling linking against libraries such as MKL (https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2025-2/sparse-blas-level-1-routines.html), NVPL (https://docs.nvidia.com/nvpl/latest/sparse/storage_format/sparse_matrix.html) and AMD (https://rocm.docs.amd.com/projects/rocSPARSE/en/latest/) . They all follow a structuring close to Sparse BLAS level 1,2 and 3, but they do use Classes to abstract away the data handlers for the matrices. I've been wondering if using iso_c_binding it would be possible to have C-preprocessing build-time switchs to either use the internal low-level kernels of stdlib or to link against such libraries.
I guess the first thing that could be tried is to have a "sparse_blas" like folder with the level2 procedures in non-oop version. And from there figure out the next steps ?

I think that it would be nice to propose interfaces to these optimized libraries. C-preprocessing build-time switchs are probably the easiest and most flexible solution. But as a first step, I agree we should first focus on low-level API.