Pre-specifying names of list members returned from a function call
by Sven Schreiber
Hi,
see feature request #85 (by myself I must admit):
https://sourceforge.net/p/gretl/feature-requests/85/
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
encapsulation.
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.
thanks,
sven
7 years, 11 months
mailing list vs. forum
by Sven Schreiber
Hi,
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.
thanks,
sven
8 years, 4 months
Gretl crashes plotting (too many) time series
by Henrique Andrade
Dear Allin,
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 ;-)
Best regards,
Henrique Andrade
8 years, 6 months
Ambiguous "modtest --breusch-pagan"
by Sven Schreiber
See:
https://sourceforge.net/p/gretl/bugs/195/
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
right now.)
Thanks,
sven
8 years, 6 months
importing R data
by Sven Schreiber
Hi,
as I'm going through the open feature requests, I'm now here:
https://sourceforge.net/p/gretl/feature-requests/89/
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?
thanks,
sven
8 years, 6 months
point size in gnuplot
by Sven Schreiber
Hi,
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.
thanks,
sven
8 years, 6 months
hiperf model for loops (was Re: [Gretl-users] Renaming variables not allowed within a loop)
by Riccardo (Jack) Lucchetti
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)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
8 years, 6 months
Special restriction syntax in VECM doesn't work anymore
by Sven Schreiber
Hi,
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
2016):
<hansl>
open australia
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)
restrict
R = vR
q = vq
end restrict
</hansl>
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).
Any ideas?
thanks,
sven
8 years, 6 months
