So the sparsity pattern will need to be fixed which should let you pre-calculate the pattern and do writes that are continuous in memory
I could see this working really nicely. How I do sparse design matrices now is I pass them in as big dense ones and then sparsify them in transformed data. I like it.
Well, internally everything is easier if they are separate types and externally we want people to be aware of what they’re doing so I think they should be a separate type in the Stan language as well.
I guess the other issue here is that there are lot of different, useful sparse matrix types that are at a higher level than the storage formats. Banded matrices vs. blocked in some way etc. etc. Personally I don’t like the cov_matrix type right now. It’s weird, and it makes me nervous I’m gonna mess up my performance (I think there’s a thread around here that Stan checks to make sure these matrices stay positive definite, which would be really hard). I like errors about Math assumptions being thrown at the solver level where possible.
I also don’t like the idea of a matrix type sometimes magically being sparse. Maybe I’m being inconsistent here.
I like:
csr_matrix, csc_matrix, matrix, etc.
I do not like:
banded_matrix, symmetric_matrix, etc.
To echo myself let’s go with Eigen
Seems like a fair plan. I never messed with that library till I ran into Stan, but I really like the dense stuff.
Long before we get there we probably need to flesh out interface
My gut feeling is that people mostly fail at sparse interfaces. So I think copying someone else’s design is best. Eigen seems cool, but I haven’t worked with their Sparse stuff. I could make a point of familiarizing myself with it though if that’d be valuable.