|Re: [eigen] Sparse Matrix Support|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Sparse Matrix Support
- From: Sameer Agarwal <sameeragarwal@xxxxxxxxxx>
- Date: Mon, 14 Jun 2010 08:25:12 -0700
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1276529115; bh=qoaP9EB4DhIyEKUdLwzQ4xrWTM4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type:Content-Transfer-Encoding; b=o4CB3W4a5YGkUBzZlARvVZTlJZDSR8TJWv86G/lavi/zZYcjkoSWfVYfomI9ya+b+ LEUkzIxvrRCKnX/rljo2g==
- Domainkey-signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: content-type:content-transfer-encoding; b=BLIKz1d2Me7Ljam4FGhm5GHv9dHaZGdXoMhzpacpIMK9QckVSbG7U++58Q9A3OtkZ 9Ad3c2mDdVx5lS1tBUcnw==
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.
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
And last but not the least, have you given any thought to supporting
block sparse matrices?
On Mon, Jun 14, 2010 at 12:43 AM, Gael Guennebaud
> 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
> 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
> 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...
> 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?