|Re: [eigen] Fast QR for 2x2, 3x3|
[ Thread 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
> 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
> 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
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.