This bugzilla service is closed. All entries have been migrated to https://gitlab.com/libeigen/eigen
Bug 233 - Public BandMatrix functionality wish list
Summary: Public BandMatrix functionality wish list
Status: NEW
Alias: None
Product: Eigen
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: All All
: --- enhancement
Assignee: Nobody
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-24 05:10 UTC by Rhys Ulerich
Modified: 2019-12-04 10:34 UTC (History)
2 users (show)



Attachments

Description Rhys Ulerich 2011-03-24 05:10:41 UTC
Following up on http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2011/02/msg00087.html, just a kindly plea for public BandMatrix functionality compatible with BLAS/LAPACK's notion of general band storage and interoperable when RowMajor is selected.

Specifically, I'm after...
 - Coefficient access
 - Column and row access
 - {Super,main,sub,main}-diagonal access
 - alpha * BandMatrix + beta * BandMatrix with the result of appropriate size (like BLAST report's GB_ACC).
 - BandMatrix * Vector (like BLAS GBMV)

I've tried to play with internal::BandMatrix (and have noticed diagonal access) but haven't had any luck trying to work with it.

Gravy would be...
 - BandMatrix * Matrix (sadly not in BLAS but level 3-ish)
 - LU factorization and solve a la LAPACK's GBTRF/GBTRS
 - LU solve handling multiple right hand sizes for BandMatrix^-1 * Matrix ops
 - Handling of mixed real/complex arithmetic for the above.

My driving use case is B-spline collocation-based numerics.  These produce discrete operators with small bandwidths.  Turns out besides GBMV/GBTRF/GBTRS these operations tend to fall through the cracks.  The mixed real/complex is for use in Fourier/B-spline pseudospectral techniques.
Comment 1 Gael Guennebaud 2011-03-30 13:48:38 UTC
Hi,

all your requests are obviously planed. To reach these goals, the next step is to introduce the notion of "range vector" which is a column (or a row) where the nonzeros are known to be inside a given range. Then everything should be fairly easy to implement.

Actually, the most tricky part is probably:

BandMatrix3 = alpha * BandMatrix1 + beta * BandMatrix2;

which have to be implemented as:

1 - allocate space in BandMatrix3 and set it to zero
2 - BandMatrix3 += alpha * BandMatrix1
3 - BandMatrix3 += beta * BandMatrix2

With the work in progress refactoring of our expression tree and evaluation mechanism, such an evaluation of BandMatrix3 = alpha * BandMatrix1 + beta * BandMatrix2; should become possible.
Comment 2 Nobody 2019-12-04 10:34:27 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/233.

Note You need to log in before you can comment on or make changes to this bug.