Re: [eigen] Specialized QR

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

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