trying to resist writing one, a few qs..

[experiment9123]

so I was about to try and write an sparse neural net ,structuring it with sparse vector / matrix operations, and in turn was about to write some helper code exactly like this. I have some questions

Q1 - does this have parallel implementations yet ? If not has it been considered, is there a roadmap?

seems there are a few ways to implement parallel sparse matrix multiply eg. avoiding locks for each accumulation

my use case is a static (or slow changing) matrix, with fast changing vectors. so having a precalculated index table in the matrix to accelerate 'a gather' approach to the accumulation might be worthwhile ( generate temporary of products, then gather those results)

.. but there's probably many ways to actually do this, all with different memeory-speed / dynamic-fixed tradeoffs

and actually the design I have in my head started as a "Parallel graph update" , which is why I have the picture of a vector of "edges" (==non-zero matrxi elems) and a "node-gather-from-edges index list" to accelerate parallel accumulation

I figured the "ParallelUpdatableGraph<Node,Edge>" type I had in mind could be created as a SparseVector , SparseMatrix, with "messages along edges" being a Node*Edge->Temp, and "acumulation of messages" being (Temp+Temp), and actual node update being some kind of "Node+=Temp, filter the result to re-sparsify"

Q2 would you consider adding constructors/accessors in the (i,j,T) format eg new_from_indexed_elems(vec![((i,j),T),((i1,j1),T1) ...]) or perhaps a "collect" , similarly that for the sparse vector vec![(index0,value0), (index1,value1) ...]

I've still got a strong NIH urge here, perhaps I should just go ahead and write a seperate lib that behaves the way i describe, and just try to make similar interfaces such that these two things could be interchanged

[mulimoen]

Q1: There is currently a multi-threaded matrix-matrix product computation in this crate, but no matrix-vector computations (PRs welcome!).

In the suitesparse library you can probably find some ideas for how to accomplish this, especially graphBlas seems to be something of interest. We already provide some bindings to other parts of suitesparse, you might be able to use this crate and some FFI to fit your usecase.

Q2: We have the TriMat type for conversion from the triplet format into CSR and CSC.

[experiment9123]

thanks for the reply.
one option is that I could go ahead and NIH the 'sparse matrix with parallel-gather acceleration table' - and offer conversions from this type - and look into consolidating this later (its probably easier to me to experiment independently).
At the very least i'll keep inspecting the code here and try to write it in a way thats easy to convert.

a type with a layout optimized for one task , wouldn't need all the impls, but conversion to and from other types would allow easily slotting it in

almost like using the "general purpose version" as a builder for the parallel-gather version. it seems you have the TriMat version as a builder.

(Just a comment , I find that name a bit unintuitive - I first guessed that it's a triangular matrix , which is something else that has reason to exist in matrix libraries. I'm not sure if you can rename it without irritating existing users ..thats a breaking change for sure..
perhaps you could rename for clearer docs and offer a pub type TriMat = TripletMat to keep user code working , and keep TriangularMatrix available..
)

[mulimoen]

High performance computing rather requires specialized solutions for maximum performance, the current focus on the CSR-type matrices for now. Additional types and methods are more than welcome. Please let us know what you end up with, I'd be happy to help with any problems you have using sprs.

The TripletMat type alias is a good idea, I'll keep this in mind for the next breaking version.

[experiment9123]

Now I've just googled and it seems this "CSR" is a well known acronym for a particular format, which might already be the exact 'gather' optimized format I had in mind. 'extents of the indices of non zero values in a second array' .

Let me think if it's possible to eliminate the extra array I had in mind..

EDIT so "CSR" = fast (and fast parallel, likely) SparseMatrix X DenseVector (just densify your sparse vector as a temporary ?)

what I had in mind (at the expense of an extra index table) is avoiding any kind of step with a buffer proportional to the entire vector size. pretty much a "scatter from sparse vector into edge indices", then "gather from the edge indices to accumulate".
but that would have needed a dense vector for the edges, and actually, there's going to be way more edges than nodes. So actually that might have been a dumb idea.

(Seems there's some other acronyms on the wikipedia page.. "COO" might be a candidate for renaming the triplet matrix ?)

[experiment9123]

Something else on my mind is how to implement a sparse matrix of 1 or 0
e.g. a struct One() that could be plugged in, with multiply operator T:Float * One -> T:Float, One*One->One, and a struct Zero() for completeness. My test case did actually use something like this (an edge with no data, just used to count occupied neighbours.), but that was a graph type taking update lambdas ("what do to on the edges..")

I'm trying to think how this would work in terms of the type system with conversions, e.g. SparseVec -> DenseVec
a SparseVec is pretty much a sparse binary vector a SparseMatrix seems like a way of representing a pure connection list.

does it need an explicit "sparse to dense with type conversion" to handle this sanely. Does it break anything if the T can't represent itself in dense format?

allowing this would save replicating all the COO -> CSR/CSC logic for an explicit "SparseBinaryVec, SparseBinaryMatrix" ?