Re: [eigen] Sparse Matrix Support

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

On Mon, Jun 14, 2010 at 5:25 PM, Sameer Agarwal
<sameeragarwal@xxxxxxxxxx> wrote:
> As far as API goes, I think a triplet based constructor like matlab
> and cholmod provide, where you supply an array of (i,j,s) triplets
> where M(i,j) =s would be very useful. That way the user can build the
> matrix in whatever order they want and then just hand over the data to
> the SparseMatrix constructor.
>
> I have used this way of constructing sparse matrices with great
> success in both c++ and matlab code.

Ok, since that's a standard approach it's probably good to support
though I doubt it's the most efficient way of doing this. I plane to
simply provide a template Tripplet<Scalar,Index> class and then let
the user takes its favorite container like std::vector<Tripplet>.

> In terms of what the libary should support in the short term versus
> long term,  I would argue for basic BLAS level support for sparse
> matrices for now before we worry about LAPACK level stuff like
> solvers. Most people interested in sparse matrices would be more
> interested in support for various iterative solvers and
> preconditioners, all of which only require fairly basic operations.
>
> For now as long as you offer access to the internal storage of the
> sparse matrix or allow convenience functions for people to convert
> that data into something that they can pass to the sparse direct
> solver of their choice, they are free to call the solver any which way
> they please.

Yes I agree with that, I'll send an email to list about that very soon.

> And last but not the least, have you given any thought to supporting
> block sparse matrices?

This is very tricky and I'm still not sure how to implement it the
most efficient and simple way. Indeed, the idea is of course to reuse
the SparseMatrix class and let it stores small fixed size dense Matrix
for the scalar type. For instance, let's assume a 300x300 block matrix
represented as a 100x100 standard sparse matrix of Matrix3d. The pb is
that depending on the context, sometimes we want to see it as a
300x300 matrix of double, and sometimes as a 100x100 matrix of
Matrix3d blocks. So this probably requires a lot of work to get it
right.

>
> Sameer
>
> On Mon, Jun 14, 2010 at 12:43 AM, Gael Guennebaud
> <gael.guennebaud@xxxxxxxxx> wrote:
>> Hi,
>>
>> yes the sparse module will be official in Eigen 3.  However it is
>> still unclear whether it will be considered mature enough to be part
>> of the 3.0 release, or if it will make it for 3.1 only. The most
>> realistic is probably a mix of both, i.e., move all the part which are
>> not fully stable regarding the API to an "unsupported" SparseExtra
>> module.
>>
>> Actually the truth is that I mostly designed the entire module myself
>> and I don't feel confident enough to consider it API stable. I would
>> like that more people report on what is cool, what could be improved,
>> what is missing, etc. Of course patches would be even better, but
>> feedback on the API would already be of extremely great value :)
>>
>> For instance, I don't really like the way the direct solvers are
>> implemented and made available. This part certainly has to be
>> redesigned.
>>
>> I'm also not sure about the usefulness of the RandomSetters since we
>> have a dynamic sparse class which is more flexible.
>>
>> Last but not least, triangular-ness and selfadjoint-ness is currently
>> controlled as for dense matrices, i.e., via the selfadjointView and
>> triangularView. This is needed to maximize the source compatibility
>> between the two worlds, but for sparse objects which are aimed to be
>> large, we might also consider runtime flags...
>>
>> cheers,
>>
>> gael
>>
>> On Mon, Jun 14, 2010 at 3:44 AM, Sameer Agarwal
>> <sameeragarwal@xxxxxxxxxx> wrote:
>>> Hi Guys,
>>> I understand that the sparse matrix support in eigen2 was experimental
>>> and no more bug fixes to it are planned. What is the plan for sparse
>>> matrix support in eigen3. Is it going to remain an experimental part
>>> of the library or will it be a fully supported part of it?
>>>
>>> Sameer
>>>
>>>
>>>
>>
>>
>>
>
>
>