Re: [eigen] Specialized QR |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Specialized QR*From*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Wed, 13 May 2009 17:17:49 +0200*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=qZen+T/XPSfhThnlv+ZZrXC0KMb5Ta5fkX3IaAtLJx0=; b=Az5KsxSbAHMePiAnp0yVYhQWzuS8q43A0HRDIchDlohZgxuZIGbUfyZkN/8rHHbrox xOgn3wJYGNQ5lPPZTJur9rM9g4OQteOsAntXIXX2vqq2GEhyYkl3n/2bJWsyStuUOMZT f092h9LIbgPi2A2D8B3W83IluaTYWnNmMsVAo=*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=UK57p1y+T7hLIPwAQKFfd+Jj3e6XzsvXEF5V2L0/kU0pCpWfQqPhsmsPqcnm64lpqX 6oBBE+GJMITln7ouPsrq8KKNwoJ1GJYh+b/HSj38IrhlB16Zf0SWIg/8R7xBAz5Uu6Mg RhjSU1G3sFih3IYail2zNWfkL1VPOOqeLRRGw=

Thanks for your email, I haven't had time yet to look at your code but I can already answer this: 2009/5/13, Andrea Arteaga <yo.eres@xxxxxxxxx>: > The result is: the QR_Givens class computes the QR > decomposition about 4 times faster than the QR class. For what sizes? > The relative errors > are > sometimes bigger than those of QR, but I never had errors bigger than 1e-13. > (I tested if Q^t * Q is the identity and if Q*R = A.) again, this makes more sense if you say which size. But yes, 1e-13 sounds nice. > > Furthermore, I noticed that Eigen QR class has (run-time) troubles with mxn > matrices, where m<n (I become this error: > "../eigen2/Eigen/src/Core/MapBase.h:166: > Eigen::MapBase<Derived>::MapBase(const > typename Eigen::ei_traits<T>::Scalar*, int, int) [with Derived = > Eigen::Block<Eigen::Block<Eigen::Matrix<double, 50, 100, 0, 50, 100>, 50, 1, Can you send us code reproducing the problem? Also, 50 and 100 are HUGE as compile-time fixed sizes. For matrices of this size, you should definitely use dynamic size. > In this moment my class works only with fixed-sized matrices. ah ok. > As I have > time, I > will implement the dynamically-sized version and try with larger matrices. Yes, that would be nice. This shouldn't be any more complicated and aside from possible meta-unrollers for fixed-size, both cases should be exactly the same code. You can have a look how Eigen's QR or LU does, to handle both cases at once. It's entirely implicit. > I also implemented a rank() method, but this is not very stable yet. See the other thread on LU precision tuning: QR is basically not rank revealing unless you add pivoting to it and even then i don't know exactly what it takes to be really rank revealing but Hauke found references to read on this topic. For a fixed-size QR, i'd say: nevermind rank-revealing QR, just focus on performance and no rank(). > Another question: the QR class returns a quadratic matrix R and a > rectangular > matrix Q; QR_Givens instead returns a rectangular R and a "really > orthogonal" > quadratic matrix Q. Very good catch. See the other thread (as above), we have also been discussing that issue. > Which behaviour is better? I would like us to standardize everywhere in Eigen on saying that, once and for all, "unitary" implies "square", so, unless otherwise explicitly stated (e.g. in a ThinQR class), all "Q" matrices are square. So: R rectangular and Q "really unitary". Notice that i say unitary instead of orthogonal because i want support for complex matrices. Cheers Benoit

**Follow-Ups**:**Re: [eigen] Specialized QR***From:*Andrea Arteaga

**References**:**Re: [eigen] Specialized QR***From:*Andrea Arteaga

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

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