7:55 a.m.
There is a problem with the eigsolve function. I am on the latest cvs and a 64 bit Linux.
Th code
A = I(2)
B = I(2)
C = {}
eigsolve(A, B, &C)
eigsolve(A, B, C)
print C
shows the problem and I think it can be solve if geneval.c line 6181 is substituted by
something like
} else if (r->t != EMPTY && r->t != U_ADDR) {
/* optional matrix-pointer */
node_type_error(f, 3, U_ADDR, r, p);
} else {
const char *rname;
rname = (r->t == U_ADDR)? r->v.b1.b->v.str : "null";
A = user_gensymm_eigenvals(l->v.m, m->v.m, rname, &p->err);
}
inspired by the normal eigenvalue function. I don't know if it is the right fix but at
least it runs.
Best
Andreas
--
Andreas Noack Jensen
Ph.d.-stipendiat
Økonomisk Institut andreas.noack.jensen(a)econ.ku.dk
Københavns Universitet http://www.econ.ku.dk/phdstudent/noack/
Øster Farimagsgade 5, bygning 26 Tlf.: 353 23094
1353 København K
3:50 p.m.
On Sun, 6 Nov 2011, Andreas Noack Jensen wrote:
There is a problem with the eigsolve function. I am on the latest
cvs and a 64 bit Linux. Th code
A = I(2)
B = I(2)
C = {}
eigsolve(A, B, &C)
eigsolve(A, B, C)
print C
shows the problem and I think it can be solve if geneval.c line
6181 is substituted by something like
} else if (r->t != EMPTY && r->t != U_ADDR) {
/* optional matrix-pointer */
node_type_error(f, 3, U_ADDR, r, p);
} else {
const char *rname;
rname = (r->t == U_ADDR)? r->v.b1.b->v.str : "null";
A = user_gensymm_eigenvals(l->v.m, m->v.m, rname, &p->err);
}
inspired by the normal eigenvalue function. I don't know if it is
the right fix but at least it runs.
Thanks, Andreas! I hope this doesn't sound patronizing, but I'm
impressed that you managed to find your way around the gretl code,
and moreover found the correct fix for the bug. The fix is now in
CVS.
Allin Cottrell
5:18 a.m.
Den 06/11/2011 kl. 21.50 skrev Allin Cottrell:
On Sun, 6 Nov 2011, Andreas Noack Jensen wrote:
Thanks, Andreas! I hope this doesn't sound patronizing, but I'm
impressed that you managed to find your way around the gretl code,
and moreover found the correct fix for the bug. The fix is now in
CVS.
Allin Cottrell
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
You are welcome. I it my first bug fix ever and I don't have C programming experience
so I was also a little surprised that it ran.
When talking about eigsolve it would nice if the Command Reference indicated in which
order the values and vectors are sorted.
Best
Andreas
--
Andreas Noack Jensen
Ph.d.-stipendiat
Økonomisk Institut andreas.noack.jensen(a)econ.ku.dk
Københavns Universitet http://www.econ.ku.dk/phdstudent/noack/
Øster Farimagsgade 5, bygning 26 Tlf.: 353 23094
1353 København K
2:59 p.m.
On Mon, 7 Nov 2011, Andreas Noack Jensen wrote:
When talking about eigsolve it would nice if the Command
Reference indicated in which order the values and vectors
are sorted.
Yes, granted. At present they're sorted from smallest to
largest, which is the way lapack's dsyev gives them. But while
we're thinking about this, is there a case for reversing the
order? It's more convenient to have them in descending order
for cointegration analysis but of course there are other uses
for eigen-calculations...
Allin
3:35 p.m.
On Mon, 7 Nov 2011, Allin Cottrell wrote:
On Mon, 7 Nov 2011, Andreas Noack Jensen wrote:
> When talking about eigsolve it would nice if the Command
> Reference indicated in which order the values and vectors
> are sorted.
Yes, granted. At present they're sorted from smallest to
largest, which is the way lapack's dsyev gives them. But while
we're thinking about this, is there a case for reversing the
order? It's more convenient to have them in descending order
for cointegration analysis but of course there are other uses
for eigen-calculations...
(Badly impersonating Sven:) But that would be backward-incompatible,
wouldn't it?
No, seriously. IMO, once we've made it clear what the function's behaviour
is, we're ok.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
3:58 p.m.
Den 07/11/2011 kl. 21.35 skrev Riccardo (Jack) Lucchetti:
On Mon, 7 Nov 2011, Allin Cottrell wrote:
> On Mon, 7 Nov 2011, Andreas Noack Jensen wrote:
>
>> When talking about eigsolve it would nice if the Command
>> Reference indicated in which order the values and vectors
>> are sorted.
>
> Yes, granted. At present they're sorted from smallest to
> largest, which is the way lapack's dsyev gives them. But while
> we're thinking about this, is there a case for reversing the
> order? It's more convenient to have them in descending order
> for cointegration analysis but of course there are other uses
> for eigen-calculations...
(Badly impersonating Sven:) But that would be backward-incompatible,
wouldn't it?
No, seriously. IMO, once we've made it clear what the function's behaviour
is, we're ok.
As a new user I have no idea about how much code there would be affected, but the fact
that it has not been documented so far makes it easier to change, I believe. Right now I
am reversing the order each time I use these functions so it would be easier for me if was
changed but on the other hand it is quite easy to do it. Just for comparison with the
other players, R and Ox have descending, Matlab one function for each direction of
ordering.
Best
A
--
Andreas Noack Jensen
Ph.d.-stipendiat
Økonomisk Institut andreas.noack.jensen(a)econ.ku.dk
Københavns Universitet http://www.econ.ku.dk/phdstudent/noack/
Øster Farimagsgade 5, bygning 26 Tlf.: 353 23094
1353 København K
4:16 p.m.
On 11/07/2011 09:58 PM, Andreas Noack Jensen wrote:
Den 07/11/2011 kl. 21.35 skrev Riccardo (Jack) Lucchetti:
> On Mon, 7 Nov 2011, Allin Cottrell wrote:
>
>> On Mon, 7 Nov 2011, Andreas Noack Jensen wrote:
>>
>>> When talking about eigsolve it would nice if the Command
>>> Reference indicated in which order the values and vectors are
>>> sorted.
>>
>> Yes, granted. At present they're sorted from smallest to largest,
>> which is the way lapack's dsyev gives them. But while we're
>> thinking about this, is there a case for reversing the order?
>> It's more convenient to have them in descending order for
>> cointegration analysis but of course there are other uses for
>> eigen-calculations...
>
> (Badly impersonating Sven:) But that would be
> backward-incompatible, wouldn't it?
>
> No, seriously. IMO, once we've made it clear what the function's
> behaviour is, we're ok.
As a new user I have no idea about how much code there would be
affected, but the fact that it has not been documented so far makes
it easier to change, I believe. Right now I am reversing the order
each time I use these functions so it would be easier for me if was
changed but on the other hand it is quite easy to do it. Just for
comparison with the other players, R and Ox have descending, Matlab
one function for each direction of ordering.
You have a point that it can be argued that the ordering was not a
feature of the function, just a coincidence.
In any case, if gretl adds a sorting layer on top, this will slow things
down. IMHO at least the user should have access to the faster version
without the additional sorting, for heavy-duty computations (presumably
loops and simulations and such). So syntactically either two function
variants or an additional argument.
cheers,
sven
4:21 p.m.
On 11/07/2011 10:16 PM, Sven Schreiber wrote:
On 11/07/2011 09:58 PM, Andreas Noack Jensen wrote:
> Den 07/11/2011 kl. 21.35 skrev Riccardo (Jack) Lucchetti:
>
>> On Mon, 7 Nov 2011, Allin Cottrell wrote:
>>
>>> On Mon, 7 Nov 2011, Andreas Noack Jensen wrote:
>>>
>>>> When talking about eigsolve it would nice if the Command
>>>> Reference indicated in which order the values and vectors are
>>>> sorted.
>>>
>>> Yes, granted. At present they're sorted from smallest to largest,
>>> which is the way lapack's dsyev gives them. But while we're
>>> thinking about this, is there a case for reversing the order?
>>> It's more convenient to have them in descending order for
>>> cointegration analysis but of course there are other uses for
>>> eigen-calculations...
>>
>> (Badly impersonating Sven:) But that would be
>> backward-incompatible, wouldn't it?
>>
>> No, seriously. IMO, once we've made it clear what the function's
>> behaviour is, we're ok.
>
>
> As a new user I have no idea about how much code there would be
> affected, but the fact that it has not been documented so far makes
> it easier to change, I believe. Right now I am reversing the order
> each time I use these functions so it would be easier for me if was
> changed but on the other hand it is quite easy to do it. Just for
> comparison with the other players, R and Ox have descending, Matlab
> one function for each direction of ordering.
>
BTW, w.r.t. Matlab the following snippet is interesting (taken from
http://www.mathworks.com/matlabcentral/newsreader/view_thread/297034):
"
We don't document the order in which either EIG or EIGS returns the
eigenvalues; if you want them to be sorted, call SORT on the output of
the function.
I wonder if we should put a statement in the documentation for these two
functions that explicitly states that the eigenvalues may or may not be
sorted and that users should not depend on them being sorted in a
particular order.
--
Steve Lord
slord(a)mathworks.com
"
-sven
4:30 p.m.
On Mon, 7 Nov 2011, Sven Schreiber wrote:
On 11/07/2011 09:58 PM, Andreas Noack Jensen wrote:
> Den 07/11/2011 kl. 21.35 skrev Riccardo (Jack) Lucchetti:
>
>> On Mon, 7 Nov 2011, Allin Cottrell wrote:
>>
>>> On Mon, 7 Nov 2011, Andreas Noack Jensen wrote:
>>>
>>>> When talking about eigsolve it would nice if the Command
>>>> Reference indicated in which order the values and vectors are
>>>> sorted.
>>>
>>> Yes, granted. At present they're sorted from smallest to largest,
>>> which is the way lapack's dsyev gives them. But while we're
>>> thinking about this, is there a case for reversing the order?
>>> It's more convenient to have them in descending order for
>>> cointegration analysis but of course there are other uses for
>>> eigen-calculations...
>>
>> (Badly impersonating Sven:) But that would be
>> backward-incompatible, wouldn't it?
>>
>> No, seriously. IMO, once we've made it clear what the function's
>> behaviour is, we're ok.
>
> As a new user I have no idea about how much code there would be
> affected, but the fact that it has not been documented so far makes
> it easier to change, I believe. Right now I am reversing the order
> each time I use these functions so it would be easier for me if was
> changed but on the other hand it is quite easy to do it. Just for
> comparison with the other players, R and Ox have descending, Matlab
> one function for each direction of ordering.
>
You have a point that it can be argued that the ordering was not a
feature of the function, just a coincidence.
In any case, if gretl adds a sorting layer on top, this will slow things
down. IMHO at least the user should have access to the faster version
without the additional sorting, for heavy-duty computations (presumably
loops and simulations and such). So syntactically either two function
variants or an additional argument.
Good point. What I've done in CVS at present is
(a) left the eigenvalues in ascending order, as supplied by
dsyev(), for speed (and noted the order in the help); and
(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.
Here's a complete script which illustrates the use of eigsort:
<hansl>
open denmark.gdt -q
list Y = LRM LRY IBO IDE
coint2 2 Y --rc
# now do (part of) the analysis manually
list dY = diff(Y)
list dY_1 = lags(1, dY)
list Y_1 = lags(1, Y) const
smpl +2 ;
matrix mX = {dY_1}
matrix mY = {dY} ~ {Y_1}
scalar T = rows(mX)
scalar n = nelem(Y)
matrix U
mols(mY, mX, &U)
U0 = U[,1:n]
U1 = U[,n+1:]
matrix S00 = U0'U0 ./ T
matrix S11 = U1'U1 ./ T
matrix S01 = U0'U1 ./ T
matrix A = qform(S01', inv(S00))
matrix evecs
matrix evals = eigsolve(A, S11, &evecs)
eigsort(&evals, &evecs, n)
print evals
print evecs
</hansl>
Allin
4:46 p.m.
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?
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
5:20 p.m.
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
4645
days inactive
4646
days old
10 comments
4 participants
participants (4)
-
Allin Cottrell -
Andreas Noack Jensen -
Riccardo (Jack) Lucchetti -
Sven Schreiber