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.

[jalvesz]

Hi @jvdp1 I went through the changes (sorry for the delay) and everything looks good. I don't understand why so many jobs failed but seems to be related to the runners and nothing related to the code changes.

[jalvesz]

@jvdp1 maybe updating this PR with the latest commit should retrigger the jobs properly

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 68.86%. Comparing base (0e45050) to head (4f43da7).
⚠️ Report is 3 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1184   +/-   ##
=======================================
  Coverage   68.86%   68.86%           
=======================================
  Files         408      408           
  Lines       13735    13735           
  Branches     1555     1555           
=======================================
  Hits         9459     9459           
  Misses       4276     4276           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.