[Gretl-devel] Re: qrdecomp with column pivoting?
Am 04.06.2022 um 15:51 schrieb Sven Schreiber:
Am 04.06.2022 um 13:11 schrieb Riccardo (Jack) Lucchetti:
> On Fri, 3 Jun 2022, Cottrell, Allin wrote:
>> columns the execution time is not that different. Note: we
currently
>> assess rank using regular QR, by counting the R elements greater than
>> some specified "tiny" value.
>
> in Hansl:
>
> <hansl>
> R = {}
> Q = qrdecomp(mnormal(4)~zeros(4)~mnormal(4) , &R)
> scalar r = sumc(abs(diag(R)).>1.0e-12)
> print r
> </hansl>
OK, thanks, that's what I thought.
Hm, but plain QR is not rank-revealing in general, that's why the thing
with column-pivoting exists. Trivial example:
<hansl>
R = {}
A = zeros(4,2) ~ I(4,2)
print A
Q = qrdecomp(A , &R)
print rank(A) # correct: 2
scalar r = sumc(abs(diag(R)).>1.0e-12)
print r # wrong: 0
</hansl>
Now, I guess that in your internal usage this is quite unlikely to
happen, but still, if you don't want to use the SVD for that --and I
presume it's because of the computational expenses-- then maybe there's
a role for the pivoted QR thing?
> I'm not really sure what the benefit would be from having
column
> pivoting, which is relatively easy to do in Hansl anyway
AFAICS, it's not enough to wiggle around the columns of R ex-post-facto,
or am I missing something?
I'm not sure myself yet, let me think about it some more. What
the
Matlab people note is that for sparse inputs the result is much sparser
with permutation (see page linked above).
Addendum: Aiming for this sparsity is a deliberate choice, however, and
then the diagonal entries are not decreasing anymore. So it's a
different issue, I guess.
thanks
sven