[eigen] Map and Ref for sparse matrices |

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

*To*: eigen <eigen@xxxxxxxxxxxxxxxxxxx>*Subject*: [eigen] Map and Ref for sparse matrices*From*: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>*Date*: Wed, 4 Feb 2015 17:31:59 +0100*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=99DmFtdJLPN7FQk3DZBa+8+xodkcveFFZ9P9Vym/rUc=; b=P/cjL0DlDa02RftRXrD+MWOTya4yUb5oCNSquFp6U/12GZV80/d2LEzfrsdud97ybT 2VapHnlrD3g8IQ0ruG/NgTpWOMCdOOn46UMBt/YgmdtO1CyKW6T3U6UlJFPaG0pszFEP wbKLFDXHezG3VcZlzw3GdJdoHWpG5L8HmFbVesnh5/hOeziecEjEvIVLgRzITW71o8Zl RzqriG/KM3gd57f03hMyI7vblQjGIjQ5Q656/l9f+1+esDsQWnupVHOZlDr3iSMLN36j e5lEZ2mA/gYu9tNFDqwWdOdliofXguHIJ//ETifQR1J67kcIKWOz+Tlu0HW26hyJYCdc y/0w==

I'd like to keep you informed of some API evolutions I'm planing in SparseCore (disclaimer, this email is a bit technical and assume some knowledge of Eigen's internals to be followed).

I'm currently refactoring a bit SparseCore to support Ref<> for sparse matrices. My current idea is to specialize Ref<> for SparseMatrix, and to be consistent I'm also specializing Map<> for SparseMatrix. This means that the MappedSparseMatrix class would become deprecated.

Also note that both Ref<> and Map<> accepts three template parameters.

The first one is the similar matrix type, i.e., a Matrix<...>, an Array<> or a SparseMatrix<...>.

The other two are optional and currently they only make sense for dense objects:

- an integer called "Options", currently used to specify alignment.

- a typename called "StrideType" controlling stride for dense objects.

At a first glance, these two parameters are rather cumbersome when talking about sparse matrices, and one could thus prefer to keep MappedSparseMatrix and similarly, add a new SparseRef class instead of specializing Ref<>. On the other hand, reusing Ref<> and Map<> leads to a more consistent API (IMO), and these two template parameters might become handy in the future to provide some compile-time hints (see below). The "Options" parameter is very generic, and the semantic of the last typename can still be completely redefined for SparseMatrix.

I'm also introducing a new base class called SparseCompressedBase<Derived>, which inherits SparseMatrixBase<Derived>, and will be a common base class for Map<SparseMatrix>, Ref<SparseMatrix>, and SparseMatrix. SparseCompressedBase provides direct access to the internal sparse-(un)compressed storage formats, that is, pointers to the inner-indices, values, starting positions of each inner-vectors, and optionally the numbers of non-zeros per inner-vectors (un-compressed case).

While writing this email, I'm thinking that the "Options" template parameter of Ref<> could be used to specify whether someone explicitly wants an object in compressed form? This option would not be needed by Map<SparseMatrix> because the compressed/uncompressed status is resolved at runtime.

The case of Block<SparseMatrix> is still an open-question though. When it represents a set of complete inner-vectors, then it can easily inherit SparseCompressedBase (this case is already handled at compile-time when using middleCols/middleRows and the likes). In the more general case, we have two options:

1 - make it a general _expression_ and implement in Ref<SparseMatrix> a special mechanism for Block<SparseMatrix> where Ref<> would only allocate and compute the respective starting position and per inner-vector number of nnz.

2 - Make Block<SparseMatrix> generates itself these two vectors such that it can also inherit SparseCompressedBase.

Option 2 is preferred when the Block object is used multiple times, but it adds an overhead in the other case. Therefore, I'm tempted by option 1: if one want to use a sub-matrix multiple times, better use a Ref<> to hold it anyways.

Let me know if you see any potential pitfalls with this approach or have better suggestions.

Cheers,

Gael.

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] When to mark EIGEN_DEVICE_FUNC** - Next by Date:
**[eigen] unsubscribe** - Previous by thread:
**[eigen] Re: Lanczos Algorithm** - Next by thread:
**[eigen] unsubscribe**

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