Re: [eigen] Bug(s) report: SparseQR on tall-thin matrices |

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

*To*: eigen <eigen@xxxxxxxxxxxxxxxxxxx>*Subject*: Re: [eigen] Bug(s) report: SparseQR on tall-thin matrices*From*: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>*Date*: Thu, 12 Jan 2017 22:44:50 +0100*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=PZk1ovclGchBxgp7gvinKIoeWLcmbh4hydQ9l+Qkak0=; b=tKC/2W5vbIuy1kMGNnK5Hqa08gHRhnKRXcoXfxxycWuGy5aQnnikhfXLNu2KO3F6AW AFQ06LEa3Z7eZ5C9jEVc8KFhm/m3HB7JabAXgEaUeZ+M0IR4gqyrMp4+8PlE1saOyBi5 Wo7kiESSslkb05TGmJUEJ1jXI+l4whvpfHIcKlw+7R26OCNBjrv8AggYFXXqZX7QL5fZ qhIEXgOlv57hgvT0xs5y9sEeZUIEwKX5MEt8q30WEP55F5+W6cgbvoIT+O0tnQB4L8GU v+FagrmyC1Kz+dGhkvaR7SW+Ba+iCbDMAF8eMRbVtWKlEQhR5T+D+6wyaEC0GTlQGuey S6UA==

Hi,

this is mainly an issue of "full QR" versus "thin QR", and the actual implementation seems to be inconsistent here. If the input matrix is m x n, m>=n, then:

qr.matrixQ().cols() == n

but

SparseMatrix Q = qr.matrixQ();

Q.cols() == m

To be consistent with the dense world, qr.matrixQ().cols() should be equal to m by default plus some mechanism to extract the thin part. We could also add a thinQ() method. Then regarding matrixR(), we could add a thinR() method for convenience.

gael

On Mon, Jan 9, 2017 at 3:51 PM, Julian Kent <julian.kent@xxxxxxxxxx> wrote:

2) qr.matrixQ() claims to be size m x n, as expected. However, trying to multiply qr.matrixQ() with a n x k dense matrix gives an assertion error:While trying to use SparseQR on a matrix A with rows > cols, I found 2 bugs:1) The size of qr.matrixR() is m x n, instead of n x n as expected. SparseQR.h:305 initialises m_R with size (m,n), and nothing does any resizing. For now I'm just taking the topRows(n), but I'm not entirely sure this is correct, and it certainly isn't the behaviour I expect. Shouldn't there be a non-destructive resize, if the extra rows are really necessary for intermediate procesing?

Eigen/src/SparseQR/SparseQR.h:640: void Eigen::SparseQR_QProduct< SparseQRType, Derived>::evalTo(DesType&) const [with DesType = Eigen::Matrix<double, -1, -1>; SparseQRType = Eigen::SparseQR<Eigen:: SparseMatrix<double>, Eigen::NaturalOrdering<int> >; Derived = Eigen::Matrix<double, -1, -1>]: Assertion `m_qr.m_Q.rows() == m_other.rows() && "Non conforming object sizes"' failed. In the .solve(...) only matrixQ.transpose() is used, which is probably why this hasn't shown up earlier.These bugs may be interacting with each other to fool any accuracy tests using A*P = Q*R on tall-thin matrices, with the extra rows in R passing the assert in Q.Let me know if you need example matrices to work with.ThanksJulian Kent

**Follow-Ups**:**Re: [eigen] Bug(s) report: SparseQR on tall-thin matrices***From:*Julian Kent

**References**:**[eigen] Bug(s) report: SparseQR on tall-thin matrices***From:*Julian Kent

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] New indexing/slicing API: almost ready to be merged** - Next by Date:
**Re: [eigen] Let's get reshape in shape for 3.4** - Previous by thread:
**[eigen] Re: Bug(s) report: SparseQR on tall-thin matrices** - Next by thread:
**Re: [eigen] Bug(s) report: SparseQR on tall-thin matrices**

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