this is about the issue of having more than one menu entry for a
function package, or (related but slightly different) having one menu
entry but wanting to offer two or more GUI interfaces when calling the
package from the package listing window.
(Currently, if I'm not very much mistaken, either a package has no
gui-main function and thus no menu entry either, and then all public
functions are offered for a choice in the GUI; or when there's a
gui-main function as required for a menu entry, then the other public
functions are scripting-only.)
The whole thought is prompted by the renewed demand for a SVEC(M) GUI
access with the SVAR addon. Extending the current SVAR GUI would not be
good because it is already a little overloaded.
I see two solutions:
1: Using the fact that recently function packages can depend on each
other, simply introduce a formally separate package, say guiSVEC, which
gets its own menu entry and a single public function. When called and
executed, it pulls in the SVAR addon on which it depends, and calls the
appropriate functions from SVAR in the background.
This solution wouldn't require changes in core gretl, AFAICS.
2: Extend gretl's function package apparatus by allowing designated
gui-2, gui-3 etc. public functions with corresponding menu-attachment-2
Not sure how disruptive such a change would be.
What do you think?
a colleague made me notice the stack() function for handling a specific
case of panel data import in section 4.5 of the guide. I must admit I
have never been aware of that function, and I have one or two questions
First, it does not appear in the function index (Gretl Command Reference
/ Functions proper, or in the built-in function documentation). Is this
an oversight, or is there a deeper reason?
Secondly, it is well documented in the guide section 4.5, but it appears
to be a strange beast: It is not a gretl command (gets function
arguments in parentheses, for example), but there are double-dash
options such as --offset or --length. I don't remember to have seen
something like this in gretl (or hansl) before.
I guess the story here is some path dependence of the early days, but I
wonder if this area could be cleaned up somehow?
Dear all (and merry Xmas to you),
we don't have 3-D arrays like Matlab has, but we do have matrix arrays,
which you can more or less use to the same effect. I thought it would be
nice to have a function (provisionally called coresample(), as in those
holes you drill through the ground) that fills a matrix with selected
elements from a matrix array. Example script attached.
My questions are:
(i) is this useful enough to be made a standard function, or should we
just mention this kind of technique in the cheat sheet chapter (if at
(ii) in case the answer is yes, should we add this to libgretl or just
provide the function in the "extra" addon?
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
in the brand new 2018d there is the facility to raise positive-definite
matrices to fractional powers, which is great. (See the changelog.)
I'm wondering what's then the role of the psdroot() function now. Is it
covering semi-definite matrices (the "s" in psd) for which the new
syntax would fail?
(I could just check and test, but first I'm lazy and secondly I'm asking
about the intended coverage, which may differ from what is the case now.)
When I run the standard script for estimating the Klein model (klein.inp from the Practice file... submenu) I get a popup window saying
'I' shadows a function with the same name
But I is a variable and not a function. So I don't see what the problem is.
And gretl turns into waiting mode (revolving indicator in the klein output window).
I have to close the popup window before Gretl continues.
I find this very annoying. In my opinion it would better and more user friendly if either
-- the popup window would not have to be closed before getting on with it
-- this warning message appeared in the output of the script that is being run (e.g. ) at the top
-- even better would be to not give this message for variables
I prefer the third and second option.
Running Gretl 2018d on macOS 10.14.2
I'll admit right away that this question has no real practical problem
behind it, it's just out of internal consistency:
The mean() function accepts a list and then averages across the members
of the list (and returns a series of per-obs-averages).
In contrast, the pmean() function doesn't have this second use, it only
accepts one series (as does mean). Any particular reason why not?
The same goes for pmax(), pmin(), psd(), psum(), and perhaps also
pxsum(), I guess.
Good morning to all,
Using gretl 2018d-git (MS Windows (x86_64) BUT this is something that
was present in previous versions of gretl
* Plot correlogram. Right click on the graph, option fonts does not
* In all? other plots
time series graph
when you open gretl plot controls through "edit", the fonts "button"
does nothing when pressed
Is it a bug? or have i done something awful? :)