Re: [Gretl-devel] eigsolve
On Mon, 7 Nov 2011, Riccardo (Jack) Lucchetti wrote:
On Mon, 7 Nov 2011, Allin Cottrell wrote:
> (b) added a function eigsort() (not yet documented), which
> reorders the eigenvalues and vectors to descending, and has an
> optional last integer argument to enable trimming of the
> eigenvalues and vectors, which can be useful in cointegration
> analysis.
Hmm, I don't know.
With all due respect, I have the feeling that we're all getting a bit carried
away with this. The amount of computation required to sort the eigenvalues is
absolutely minimal compared with the CPU requirements to compute them, so I'd
say this is not really an issue either way. Frankly, I'm a bit skeptical on
the necessity of introducing a new reserved word for doing something that
takes 2 lines of hansl code.
Is there anyone who shares my view?
Well, probably me, on reflection ;-)
If we scratch eigsort (I'm OK with that), that leaves the question
of whether we reorder the result from eigsolve (and also eigensym).
I'm not really pushing either way. But so far as backward compat is
concerned I agree with Andreas -- it's very unlikely that there's
any hansl code out there that _depends_ in any way on getting the
eigenvalues in increasing order.
One other consideration: in (almost?) all the internal uses where
gretl herself wants eigenvalues ordered, she wants them in
descending order. A common trope is to call
gretl_symmetric_matrix_eigenvals()
followed by
gretl_symmetric_eigen_sort()
which does the descending order thing. If the primary function
already put the eigenvalues in descending order we could therefore
do a bit of code cleanup.
Allin