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.
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'm running some Gret's performance tests and I think I found a bug. Using
a monthly time series dataset with more than 5000 variables I tried to plot
the complete data into only one graph (using the GUI).
Gretl can handle up to 1486 series. Any value above 1487 will crash Gretl.
I really don't need to plot all those series, it's just a test ;-)
Hi especially Oleh,
if you're reading this (we haven't heard from you in a while, hope
you're alright), could you take a look at the description of the feature
request and my comment on:
and then tell us if your package is relevant, I mean if it indeed covers
some aspects of the request.
The command "modtest --breusch-pagan" does a heteroskedasticity test,
fine. However, it could be mistaken for the panel homogeneity test from
the same authors.
Which also prompts the question: How to perform the Breusch-Pagan panel
homegeneity test (section "Testing panel models" in chapter 18)
explicitly, and then how to retrieve the test result? Currently it seems
it is printed out automatically after a panel estimation. But then the
$test and $pvalue accessors might hold something else? (Haven't tested
as I'm going through the open feature requests, I'm now here:
And I'm asking myself, if there is already the function "gretl.export()"
that is defined for R in an R session that has been launched from the
gretl side, why can't this function be used to enable the _importing_ of
R data into gretl more directly?
I understand that the conversion from R's formats are done by R, and
therefore R would be needed. So maybe this could be done conditional on
the existence of the R shared library path in gretl's preferences?
here's a very concrete feature request: In gretl's GUI window for
gnuplot there's still some space below the drop-down list for the point
symbol (which applies at least to "points" and "lines-points" styles).
IMO it would be useful to put a box there to specify the point size; for
example, a value of 0.5 would imply adding "ps 0.5" to the respective
gnuplot command line. The box could be exactly like the one for
linewidth, but of course would only be active whenever the point type
selector is active as well.
As a more general remark, I've learned that with gnuplot 5 it seems
easier (compared to gnuplot 4) to handle the data values that are given
"inline" in the gnuplot file, by specifying a named "datablock". Stuff
like shaded areas and so forth should be easier to achieve from gretl's
side I guess. But Debian for example switched to gnuplot 5 less than a
year ago (if I understand correctly, but could be wrong?). I wonder what
an acceptable timeframe for gretl would be to require gnuplot 5.
On Sun, 20 Mar 2016, Sven Schreiber wrote:
> Am 20.03.2016 um 00:50 schrieb Allin Cottrell:
>> OK, I take Sven to be saying (and also Artur) that if there's any chance
>> that renaming a series within a loop could lead to mischief, the general
>> ban on using the "rename" command within loops should be maintained
>> until further notice.
> It's not so much the renaming as such. So if the solution is to say "we'll
> just allow it" I guess I wouldn't mind. But I thought you were saying that
> some other checks have to be introduced in order to distinguish allowed from
> forbidden uses. And my worry is about the side effects of those new checks or
> extra treatments.
[Note: I've put the devel-list in cc, because I guess this discussion may
get quite technical, and that we may want to continue it there, so sorry
for the cross-posting.]
I've begun to think that we may wan to introduce an option to the loop
command to distinguish between a "safe" and a "hi-perf" mode.
Let me explain: initally, the loop .. endloop construct used to imply a
simple repetition of whatever was inside, with only a few specific caveats
and checks: eg, some commands were disallowed on the ground of common
sense (eg, nulldata), some others would partially change their meaning (eg
"print" in progressive mode) etc.
This has been silently changing for a while: as Hansl has grown in
ambitions, it's become evident that sometimes you must use loops for
specialised tasks which involve very few different instructions, but
should ideally run as fast as possible. Typically, those instructiona are
the various incarnations of "genr" and, possibly, basic estimation
commands such as ols or var. Think for example of implementing a bootstrap
procedure or MCMC; you'll never need the full array of Hansl syntax inside
those: genr and user-written functions are normally all you need, but
you'll want those instruction to run as fast as possible.
In the past year or so, Allin has been working on "compiling" loops, that
is, change the way hansl handles them going from mere repetition of their
contents to a more efficient treatment. This is very nice, but very
complex, since it's very hard to optimise a few things the hansl language
provides (eg string substitution) without risking complete breakage.
Therefore, I'm now thinking about the possibility of introducing something
like a --hi-perf option to "loop", which would disallow some instructions
but would make it possible to run the allowed ones at full speed without
having to bother with too many checks. What do you guys think?
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
I've run into a "matrix not conformable" problem, using the example
restriction code from ch. 27 (p. 237 in my A4 PDF version dated January
list vecmvars = PAU PUS E IAU IUS
vecm 2 4 vecmvars
# from here on code snippet from ch. 27 in user guide
matrix I4 = I(4)
matrix vR = I4**(I4~zeros(4,1))
matrix vq = mshape(I4,16,1)
R = vR
q = vq
This is on gretl 2016a, and the hansl code where I noticed the problem
first is not new, so I'm relatively sure that this used to work last
year (as it should).