Re: [eigen] Fast QR for 2x2, 3x3 |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Fast QR for 2x2, 3x3*From*: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>*Date*: Wed, 25 Feb 2009 11:40:17 +0100*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=tFjeJpuQWqX5hoBKdVvrM0pUBUGF/raZ+UNS+1sU6v0=; b=E1p34Mo8x8NIfFicOQftKrqqnyLaHeAkXyOpboGYGXyfWq5QWQp3+lGB2vc2UBIhvR jH+SFcMC5RBwnfmQpECt/H/Igwa3h3IGeTXsR9wZitA698KIpNs0lBZ35bp/m2aTxX7/ WqlVSc4OBYKRhZfTv3Ph+EE1M07TwpY4OebQ4=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=l7HdC0qmbowoomo0Sq9SzeqmsvO7hpnY+bwC8jNLamQhRzAlSoSQGQUdOdLEKY8o/H eLFWGQjOC9RJ98FnFpBNEesnNn5OBKj2blQpqA4zvfJ52z35vGwAz2HduLdg2LwZ+hHl D0mrF4txyiUwK0vBFm3FNZCSAi5zmpxj83T5c=

On Wed, Feb 25, 2009 at 11:30 AM, Andrea Arteaga <yo.eres@xxxxxxxxx> wrote: > > > 2009/2/25 Gael Guennebaud <gael.guennebaud@xxxxxxxxx> >> >> I don't think we want to provide multiple algorithms for the >> same matrix sizes. > > > That were useful to provide a performance comparation between Givens and > Gram-Schmidt in simply way, but for all other 'normal' jobs that is actually > useless. yes, exactly > In this case we can simply write specialized QR class, such as > template<typename _Scalar> > class QR<Matrix<_Scalar, 2, 2>; I proposed something more complicated because I think the same specialization could work for a range of sizes (with a few compile-time if()) > I didn't completely understand what matrix m_qr and Vector m_hCoeffs are and > how does QR compute the Q and the R from m_qr. But if m_qr is a matrix with > Householder vectors, she's not compatible with a specialized QR for others > algorithms, isn't it? > So if we want to specialize some QR class, we must to reimplement > _compute(), matrixQ() and matrixR(). Perhaps for small matrices, it makes > sense to compute and store directly Q and R at construction-time, with > _compute(), without m_q and m_hCoeffs. Or, if we find some method to > directly say at construction-time which matrices must be computed, we no > longer need m_qr, like gael said. > Before code something, I want to actualy understand all aspects of this QR > class. I think that what really matters is that all matrixQ and matrixR functions returns the same thing. So if for fixed sizes they return const reference to plain matrices, then we should do the same for the general case (using either lazy evaluation in matrixQ() or bit flags at the computation time) > Last note: don't forget the 2x3 and 3x2 matrices. QR is very useful for > non-quadratic matrices. > I'll be offline until saturday. > Andrea

**References**:**[eigen] Fast QR for 2x2, 3x3***From:*Andrea Arteaga

**Re: [eigen] Fast QR for 2x2, 3x3***From:*Benoit Jacob

**Re: [eigen] Fast QR for 2x2, 3x3***From:*Andrea Arteaga

**Re: [eigen] Fast QR for 2x2, 3x3***From:*grey_earl

**Re: [eigen] Fast QR for 2x2, 3x3***From:*Andrea Arteaga

**Re: [eigen] Fast QR for 2x2, 3x3***From:*Gael Guennebaud

**Re: [eigen] Fast QR for 2x2, 3x3***From:*Andrea Arteaga

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Fast QR for 2x2, 3x3** - Next by Date:
**Re: [eigen] Undesired formatting behaviour** - Previous by thread:
**Re: [eigen] Fast QR for 2x2, 3x3** - Next by thread:
**[eigen] Performance question**

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