On Fri, 3 Jun 2022, Cottrell, Allin wrote:
On Fri, Jun 3, 2022 at 11:05 AM Sven Schreiber <sveto...@gmx.net> wrote:
I'm wondering whether it would be useful (or more precisely, whether the
cost-benefit calculation would be net positive...) to generalize the
qrdecomp() function to allow column pivoting. Here are a couple of
thoughts and remarks on that:
1) First of all, qrdecomp currently does not return an ordered result.
For example, when doing this:
Q = qrdecomp(mnormal(4)~zeros(4)~mnormal(4) , &R)
then the middle column of R is zero, just following the input. Of
course, this is fully according to spec, nothing else is promised currently.
2) A QR decomposition with pivoting would provide a rank-revealing
operation. The natural workaround and alternative way to do this is SVD.
It is my understanding that SVD would be noticeably slower, however.
(Correct?)
Maybe, though I gather that for a matrix with a lot more rows than
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>
3) In Lapack this is given here:
https://www.netlib.org/lapack/lug/node42.html, and references the
routine xGEQP3 (Level 3 BLAS).
There's an interface to that in libgretl's gretl_matrix.c, namely
gretl_matrix_QR_pivot_decomp(), though it's not hooked up to any hansl
function at present. I find it kinda confusing trying to deal with
results after pivoting. You need to pay careful attention to the
reordering to avoid producing nonsense.
Me too.
4) In terms of a possible interface, the immediate idea would be to have
a third and optional boolean switch which defaults to the old behavior,
and if set to TRUE then it would use column pivoting. However, perhaps
one also wants to retrieve the resulting permutation matrix P in the
relationship AP=QR (where A is the input). Then perhaps the third
optional argument would be another pointer-to-matrix, just like the
second one. Then column pivoting would only be done if a matrix pointer
is actually provided in the third slot, capturing the P result.
So, what do you think, how difficult would it be to implement this, and
does it make sense?
It "makes sense" OK, and it's already part-way implemented. Whether
it's worthwhile -- I'm agnostic.
I'm not really sure what the benefit would be from having column pivoting,
which is relatively easy to do in Hansl anyway (note that P is a
permutation matrix, so it can be more compactly expressed as a set of
indices), although of course numerically speaking lapack is unbeatable.
Could you provide us with a use case where pivoting would be useful?
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucche...@univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
_______________________________________________
Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it
To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it
Website:
https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
