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, 20 May 2009 06:57:34 -0400*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=dwhJoEeZNM/07LnSk28Bv/ADLYTVhKCyqPdOmisnM9o=; b=PCgqZeu6U6l8gra783Ob2VKz192SZVYahgMJdtWHVOYJUVw9AUW1t2nc8tXX5bZQgR tlFf4zq4cjMDIZ/mc02AZgHsOZK8aFbXk7GWeesd7Ma3ciNFQFuOWj9yuCwHRS006bd9 pcxceARng/VJgzT5KSikI15mZk9xar1N4mrXo=*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=Hnxup9DTmbopzkQqbWoaB/KtSlXfDP8hGykcVNYEe5l3dpUjudxfpfkML+x6A8/xmW LTftQ2XjkvpTLK/BJIV9eYBD3xBupKGYjsIqB/GfNOCpxSrKVewYyg7uKh1qP1DDPgum UmhrsTyBRlI4Q+1T3s4dsqVTctWQu0/I7pHMg=

About the idea of a common base class, I don't know. If it reduces the overall number of lines of code then yes it's a good idea. If both QR decomppositions have the same interface then it's also a good thing as it allows to write functions that take as parameter either decomposition. Maybe this is something about which you can think later: first code the decompositions separately and then see if they share enough to justify a common base class. Then that would put back on the table the alternative proposed by Hauke, to make the algorithm a template parameter to a common "QR" class. 2009/5/20 Andrea Arteaga <yo.eres@xxxxxxxxx>: >> But you can compute Q^T b by applying the Givens rotations directly to the >> vector b, for a cost of only O(n^2). > > You're right. > > It would be nice to know what QR serves to, before to computing the > decomposition. In case QR is needed only to solve a least squares system, > it's unuseful to form the Q matrix. You can add a parameter to the constructor of GivensQR, "bool needQ" or "bool wantQ", telling that. > > The QR class could have this behaviour: store the matrix of which *this is > de QR decomposition with the constructor and compute the decomposition only > then, when is strictly needed. For example, the solve() method doesn't > require the computation of Q, so Q were not computed. In my opinion, you can even do that by storing only a const reference to the matrix being decomposed, saying clearly in the documentation that it is assumed to not change. I already do that in LU for computing the image. (Others:opinions on decompositions storing such references?) I didn't understand clearly why you needed to compute Q explicitly (why it helped) but if storing that reference allows not to work without computing Q then it's clearly a good idea! Benoit

**Follow-Ups**:**Re: [eigen] Specialized QR***From:*Hauke Heibel

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

**Re: [eigen] Specialized QR***From:*Benoit Jacob

**Re: [eigen] Specialized QR***From:*Jitse Niesen

**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/ |