Re: [eigen] GivensQR |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] GivensQR*From*: Andrea Arteaga <yo.eres@xxxxxxxxx>*Date*: Tue, 18 Aug 2009 23:55:09 +0200*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=F9azSVz8BvE6w9lXDyC1xJq2zSOSvsn5PkzKijU4V6s=; b=MgzkL/DNCHdTZjL+8Ge3IrWYYekPQXkfjCdjAzTM7yaMT3AS7fe37W3iKuCv+PC82d OIu56Bb+ubnb36G5ZQsqdp31NMy20wRndsIdYVFbz6zWjW75sUZBAxTPoDzCLd5pYlzE fG8HsK2sj0Ao1a58mOp368AT41IOQqklWUkc4=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id; b=FPr6Fs3U2M3+VLFdS1OJzmnBDq911/Pg4T9k+nVY4XmmFC+vklZw2bpmkAxBkVjyVi XCkhW6aQVnpRtFEwolPYpYpi8bcO22brQxukZw77ID+QLm82kZ87joTWmkaA21AxSYSt T4mLQ0edOmfxMG0acmba7RDSDhXyA9sd6x1lQ=

> > > Pros: > > > > The computation of Q is performed only if strictly needed; by default (by > > the constructor) no computation is performed. Q is computed only if the > > user requests it. > > that's something we'll have to uniformize across various > decompositions later on. > Actually I believe that the default should be "convenient but not > fast" i.e. compute Q, with an option to not compute Q. But we had yet > to discuss that on the list. I implemented the class paing attention to the perfomance, but in facts the result is quite "comfortable". The idea behind the method compute() is not to ask the user which matrices are to be computed, but only a tool to update the decomposition if the matrix has changed (since the original matrix is stored as alias). The decision behind the behaviour of solve() is simply: there is no need for the unitary matrix in order to solve the sistem. The only "problematic" issue is: if one needs both Q and R, he should request Q and then R and not viceversa. In the first case, Q and R are computed and Q is returned and then R is simply returned; in the second one R is computed and returned and then Q and R are both (re-)computed and Q is returned. In other words: Matrix<...> m; /* ... */ GivensQR<Matrix<...> > qr1(m); qr1.matrixQ(); // Q and R are computed; Q is returned qr1.matrixR(); // R is returned (was computed before) GivensQR<Matrix<...> > qr2(m); qr2.matrixR(); // R is computed and returned; Q is not yet computed. qr2.matrixQ(); // Q and R are computed; Q is returned. The first case is faster than the second one, in spite of the same result. An alternative is: GivensQR<Matrix<...> > qr3(m); qr3.compute(); // Both matrices are computed and stored qr3.matrixR(); // R is returned; no computation qr3.matrixQ(); //Q is returned; no computation If the user doesn't care about performance, this issue is not a problem; if he does, the only think he must care is to call matrixQ() or compute() before matrixR() if he needs both Q and R. If you need help in order to wirk on my code, I can provide a fully-commented version. Just a note: I thought to store the R matrix in a row-major storage and Q in column-major and then I constructed the algorithm by updating R row-wise and Q column-wise. But I'm not sure about the performance and the stability, so I finally stored both in the default behaviour. What is your advice about that?

**Follow-Ups**:**Re: [eigen] GivensQR***From:*Benoit Jacob

**References**:**[eigen] GivensQR***From:*Andrea Arteaga

**Re: [eigen] GivensQR***From:*Benoit Jacob

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] GivensQR** - Next by Date:
**Re: [eigen] GivensQR** - Previous by thread:
**Re: [eigen] GivensQR** - Next by thread:
**Re: [eigen] GivensQR**

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