|Re: [eigen] Specialized QR|
[ Thread 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!