Re: [Gretl-users] svar inquiry
On Sat, 28 Jun 2014, Riccardo (Jack) Lucchetti wrote:
On Sat, 28 Jun 2014, Riccardo (Jack) Lucchetti wrote:
> Thanks for looking into this, Sven. I'll try to see what's wrong asap.
One thing is, the model is very probably under-identified. I _must_ find some
time to include into the SVAR package a few functions for checking for
identification before estimating the model.
However, SVAR, shouldn't give the error you saw. I debugged it a little and
it seems that we have a weird bug in hansl. I just uploaded a new version of
SVAR.gfn which contains a workaround, but still we ought to fix this
properly. The problem is exemplified by the following piece of code.
<hansl>
matrix C = { NA, 0; NA, NA }
print C
loop i = 1..2 -q
loop j = 1..2 -q
c = C[i,j]
if ok(c)
print i j
endif
endloop
endloop
</hansl>
I temporarily fixed this in CVS via the following change, but I'm still
puzzled and I'm not at all sure this was the proper way to do it; Allin,
could you please take a look?
--- lib/src/geneval.c 26 Jun 2014 13:59:50 -0000 1.892
+++ lib/src/geneval.c 28 Jun 2014 13:34:58 -0000
@@ -3522,7 +3522,7 @@
errno = 0;
- if (na(x)) {
+ if (xna(x)) {
switch (f) {
case F_MISSING:
return 1.0;
@@ -3530,7 +3530,7 @@
case F_MISSZERO:
return 0.0;
default:
- if (na(x)) {
+ if (xna(x)) {
return NADBL;
}
}
This is to do with the fact that we handle missing/non-finite values
differently in matrices versus series and scalars: the actual "missing"
code, represented by "NA", is only allowed in series and scalars while
"nan" (Not-a-Number) is only allowed in matrices. These values get
converted deoending of the target type in a "genr" expression: NAs get
converted into nans when writing a matrix, and nans get converted to NAs
when writing series or scalars.
The trouble with the hansl code above is that the variable "c" is not
explicitly typed. If you specify either "scalar c" or "matrix c" then
the
results of the ok() test will be consistent and as expected.
Now arguably it is a gretl bug that the type-ambiguity of "c" leads to
inconsistent results but I'm not sure what the correct fix would be; I'm
not convinced the change to geneval.c above is right.
Allin