Hi, has anyone ever tried to use gretl's gmm ... end gmm block to
estimate a "classical" multiple-equation system? I'm not talking of
dynamic panels, but a traditional simultaneous equation system. AFAIK
the built-in offerings for a "system" stop at 3SLS and FIML.
this is a bit of an advanced panel data handling problem, but at the
same time practically relevant I think... Perhaps it might even qualify
as a bug, but let's see: I'm wondering whether appending a second panel
dataset (say, file2.gdt) to an open panel dataset (say, file1.gdt) is
perhaps made "too" simple with gretl, potentially resulting in a rubbish
combined dataset. The core problem seems to be that gretl (for
appending) matches the internal numbering of panel units, even though
this internal numbering isn't really meaningful.
Let me try to explain: The attached "file1_test.gdt" holds unbalanced
data for 4 panel units, while "file2_test.gdt" holds data for 5 panel
units. The overall time dimension for both is the same. With the 1st
dataset loaded, when I append the 2nd dataset (simple 'append', no
'join' or whatever), gretl does that without any complaints.
But suppose that the 4 panel units in file1 do _not_ correspond to the
first 4 units in file2. This is something that can easily happen in real
life. So the append operation doesn't get the matching right.
In addition, I tried a variation where the two panel data structures
were defined properly with panel index variables that had no missings.
Still, 'append' doesn't care about that, always just referring to the
internal but separate unit index numbering.
Yes, I'm aware that I can get the desired result using 'join', that's
not the point.
The point is about the following claim from the 'append' function
reference: "In the case of adding series, compatibility requires either
(a) that the number of observations for the new data equals that for the
current data, or (b) that the new data carries clear observation
information so that gretl can work out how to place the values." -- In
my example, condition (a) is clearly not the case, and I'd argue that
condition (b) is either violated as well, or that the
panel-index-variable information is ignored by 'append'. Perhaps
'append' should refuse to proceed in my example case, or it should ask
the user, or it should make use of the panel index variables, but
arguably it should not use the arbitrary internal unit numbers.
I hope that the problem description was clear enough!
I'm curious what your reactions and answers will be, thanks
I noticed this little thing
set verbose off
function scalar increment(scalar *n)
n += 1
n = 0
As you can see, seem like that "print" command calls the function twice.
Is it something wanted?
Hi, it's that time again when we translators finally have to update our
translations (but actually I think I'm the only laggard...).
But I only have one question:
- "Rationale" in the context of the new gretl editor program, which I
haven't used yet and so I'm not sure what that means.
It seems to be a button label or so.
I have completed the updated translation for the Greek language.
That means, for my level of expertise, I have the el.po and el.mo files
(I downloaded the el.po file from
https://sourceforge.net/p/gretl/git/ci/master/tree/po/ and did the
update of the translation)
Till now Allin helped me to complete the job as I sent him - in the past
- the el.po file.
Can you please mention the procedure that an ignorant (i do not build
gretl at all, i only use it and write funtions)) could follow (with git,
etc?) to complete the job for the upcoming gretl version?
Thank you all for your time.
At the end if I could not do it ... I will send the file to Allin :).
I attach the el.po file for your information.
Hi, this is a general remark, not a short-term or in any way urgent thing:
Maybe some stuff in the source repo could be renamed eventually to
reflect the evolution of gretl and to be more consistent. Here are two
examples of what struck me as not 100% clear:
- The IPS panel unit root test lives in lib/src/adf_kpss.c. OK, so the
idea behind the test is "ADF-ish", but still I'd think a better name
might be unitroot.c or so.
- We always try to explain to users the important difference between
commands and functions in gretl, but guess where the function reference
documentation lives? In the _commands_ subdirectory! I find this quite
I've been using GTK3 based gretl for years - without any problems.
Recently, I decided to move from the very old X11 graphics to Wayland
and I encountered the following two problems:
1. Drag-and-drop actions don't work (neither for scripts nor data).
2. Clipboard is one-directional: I can copy raw text from the operating
system to gretl, but I cannot copy enything from gretl to operating
system (scripts, results).
I checked GTK2 and everything is ok. I'm using current git version.
I'm asking for verification or falsification of my understanding how
arguments to functions are treated, specifically those (potentially)
involving a lot of memory. Consider these two similar functions:
function void hugematrix1 (const matrix m)
function void hugematrix2 (const matrix *m) # note the pointer form
The second function wants a pointerized argument. Do I understand
correctly that in this case the difference has no real effect? My
understanding is that when the arg has the "const" property, internally
gretl doesn't do a copy anyway. So in a way it's already involving a
memory pointer. And since with "const" the arg is immutable, it can't be
used as a way to grab the function's output, either.
So why would one ever use a pointer form along with "const"? Maybe it
even should be banned?
Well, there's one thing that I can imagine, but perhaps a little
far-fetched: The caller can pass an anonymous on-the-fly argument to the
non-pointerized form, but that isn't possible (AFAIK) with the
pointerized variant. So that could be a "clever" way for the function
author to force a named argument, for example to be able to use the
argname() function inside the user-written function. Is this the
background of this?