Re: [eigen] Sparse Matrix Support |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Sparse Matrix Support*From*: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>*Date*: Fri, 18 Jun 2010 10:12:40 +0200*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=X7+YZCEJS+jSOcEiONf14mvqOa0NKu2bAGc7A4yTcRM=; b=xv89fyDgwBM8zN8qpTjloessj3VFymLF7XLg2AFMUt6f9F2THgTtwlz43N5nCoc7DF dXQ8Vy1qoykobkc2K8r3Hk40rTuSDIEvpr7pJBzZv/yumVNKH2iSHb8LU48GXcETPCYI 4j08TUaWi5+6K9amAC2KIMzkqsXRtj+aHHgRY=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=P+f1Q8XzFYtpM4X8gl7FCg2DQQ8XlEyCdkVqlV5upi60gjevZpmy8PUrIK4l0NxpDJ K/Qxdb6Id9Cz/3ZvUNYrhW1mqJds6FjhI5HFHgFhhwa8Grxpx7LGrejgPjZjNdXIOn/y TuCz6K8Kv/qsK0MLK8gHopgYrkgGhT5x8bkU4=

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 >>> >>> >>> >> >> >> > > >

**Follow-Ups**:**Re: [eigen] Sparse Matrix Support***From:*Trevor Irons

**Re: [eigen] Sparse Matrix Support***From:*Sameer Agarwal

**References**:**[eigen] Sparse Matrix Support***From:*Sameer Agarwal

**Re: [eigen] Sparse Matrix Support***From:*Gael Guennebaud

**Re: [eigen] Sparse Matrix Support***From:*Sameer Agarwal

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Performance gap between gcc and msvc ?** - Next by Date:
**[eigen] Sparse module updates** - Previous by thread:
**Re: [eigen] Sparse Matrix Support** - Next by thread:
**Re: [eigen] Sparse Matrix Support**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |