see feature request #85 (by myself I must admit):
Currently a function with a list as a return type must internally set
the names of the list members (series) and the those names are
automatically exported to the function caller. If series with those
names already exist in the outer scope (at the caller level), they would
be overwritten. This is an exception of gretl's principle of function
I'm suggesting: To provide a cleaner solution of this name clash
problem, such a list-returning function should also accept a string
array argument. The string elements in this array would be used by the
function as the names of the exported list members.
In this context it would be useful to have a built-in easy mechanism to
take the labels from the string array and use it for the returned list
(inside the user-defined function). That is the concrete request right now.
I'm not suggesting to make this thing mandatory any time soon, because
of the backward-compatibility issue.
Dear Allin and Jack,
gretl (current cvs on ubuntu) crashes in the following case:
I defined a string with 8 entries (labeling 8 units) and run the
sprintf insttrs "DIW IFO IFW IMK RWI IWH HWWI GD"
setobs Institut insttrs --panel-groups
where "Institut" is a series of strings labeling a total of 11 units
existing in the dataset. I don't expect this to work, of course.
However, gretl should not crash in this case.
I know it's a never-ending discussion whether to have a forum or to use
mailing lists. So this is just a "ping".
First I've just noticed that you need 4 clicks to get from the gretl
homepage to the view of current threads in the list. And that assumes
that you know where to click each time. So I think one way to make the
mailing lists more "forum-like" (in a passive read-only) mode is simply
to provide a more direct access to the archives.
Secondly, Allin said that we might want to shop around for the most
suitable platform, instead of just using sourceforge. Ok, but where to
go shopping? Any concrete suggestions? I volunteer to check them out.
Finally, as the Wiki is de facto dead, I wonder if the link from the
homepage should be removed. IMHO it could be mistaken for the
(non-existent) forum and then creates a bad impression.
I've just noticed that it is possible to add (in the GUI) lags of the
binary dependent variable in the built-in Probit routine. However, there
are some subtleties involved in this context, so I'm wondering whether
this has always been possible? Could somebody provide some background on
For example, there is this quite recent paper:
ROBERT M. DE JONG, TIEMEN WOUTERSEN
DYNAMIC TIME SERIES BINARY CHOICE
Econometric Theory, 27, 2011, 673–702.
From the abstract: "... it shows in a time series setting the validity
of the dynamic probit likelihood procedure when lags of the dependent
binary variable are used as regressors ..."
Does gretl rely on this particular paper's findings?
as promised, the next packaging-related message:
When I create a package here on Windows 7 with gretl 2016b and two
public functions, I cannot designate (in the GUI package editor) which
is the gui-main function. The drop-down menu is inactive (greyed out,
And BTW, when I first wanted to create the package the main package
editor dialog window didn't have the two "Tag" drop-down lists. But
restarting gretl cured that, so I'm guessing/hoping that it might have
something to do with my (bad) habit of installing new gretl versions
without properly uninstalling the previous version. (Restarting gretl
didn't help for the other issue above, though.)
after creating the function package with a required version 2012a or
something like that, gretl reports a wrong required version "2.1.20" in
the Info text.
I have only used the GUI package editor (on the latest snapshot this
time), no manual messing.
I'm currently catching up on how to package a function nowadays. Expect
more emails to come...
The first thing is, I found in section 13.5 of the guide the statement:
"Creating a package via the command line
The mechanism described above, for creating function packages using the
But actually the GUI mechanism hasn't been explained before, I guess
it's because it has been moved to the separate packaging guide. Not sure
why the CLI mechanism still has to be in the main guide then.