Feature list on the web page
by Sven Schreiber
Hello,
I would suggest various additions to the frontpage on gretl.sf.net in
the Features section:
* add a "panel estimators" entry after time series and limited dep. vars
* perhaps also mention "structural VARs" under the time series methods point
* add the "Hansl" name at the bullet point "integrated powerful
scripting language", and integrate the following bullet point about
command loop structures; also, add keywords such as "matrix and algebra
programming"
* The point "Links to... <other languages>" is quite vague I think and
even somehow sounds as if gretl necessarily is not enough to do "further
data analysis".
Also while the "foreign" feature is quite cool for insiders and
experienced users I'm not sure whether it is a selling point for people
that don't know gretl yet.
Just some thoughts,
sven
9 years, 11 months
Proposal for function package cleanup
by Sven Schreiber
Hi,
[First of all, this goes especially to Henrique and Marcin, as we seem
to be a little bit responsible for package supervision. But I thought it
doesn't hurt if the gretl-devel list also reads it.]
Following up on my post from November "Possible redundancy of some
function packages?" and the ensuing discussion (see
http://lists.wfu.edu/pipermail/gretl-users/2014-November/010422.html), I
now propose to really do something about the following packages, and
sometimes that means to remove them. If you don't voice your opinion
now, my suggestions will become reality.
1) clustered_ols (Pigini) -- could serve as a nice example, but doesn't
have to be a package for that, should be moved as a script to the
exercise script collection. Read: should be removed from the package list!
2) cnumber (Monsueto) -- maybe I'm confusing things, but could this be
redundant when the stuff that Lee just presented at the conference is
packaged? (I guess it could stay until then.)
3) fgls (Yang) -- There was no feedback on what it actually does, should
be removed.
4) GHegy / HEGY_test (Diaz / Lucchetti) -- Guys, could you please get
your act together on this? It is ridiculous that two core gretl people
have competing or conflicting packages. It almost looks to me as if we
could remove HEGY_test by Jack because GHegy by Ignacio is a superset?
If no one intervenes, this should be the course of action.
5) fcModels / HoltWinters (Yang / Diaz) -- Again, cooperation would be
good. But both packages were updated relatively recently, which is also
a good sign. Don't know what else to do with this.
6) growth (Bala) -- I didn't mention this last time, but now it seems to
me this functionality is too small for a package (sorry, but this
regresses on a trend and just gets the coefficient, unless I'm missing
something). Should be removed.
7) JB (Yang) -- there was feedback and a small discussion last time,
which in my interpretation also boils down to: should be removed.
8) MWU / mwu / mwu_dummy (Yang): Yi-Nung, please consolidate these very
similar things into one package with different options. Please respond
to this message, otherwise I propose to remove two of these three packages.
This list is probably not exhaustive, there seem to be new packages, but
I don't have time right now to look at all of them.
thanks,
sven
9 years, 11 months
Suggestion for new unit root test formatting
by Sven Schreiber
Hi,
now for something completely different: As I mentioned in passing at the
conference, I have received some (mild) complaints about the output of
the ADF test in gretl. And indeed I think the arrangement of the
information is suboptimal. So here's a concrete suggestion with
before-and-after [need to view this with monospaced font]:
Now / before:
"
Augmented Dickey-Fuller test for LRM
including 4 lags of (1-L)LRM
sample size 50
unit-root null hypothesis: a = 1
test with constant
model: (1-L)y = b0 + (a-1)*y(-1) + ... + e
1st-order autocorrelation coeff. for e: 0.075
lagged differences: F(4, 44) = 4.290 [0.0051]
estimated value of (a - 1): -0.0591989
test statistic: tau_c(1) = -1.70189
asymptotic p-value 0.4303
"
And my suggestion / after:
"
LRM: Augmented Dickey-Fuller test
(H0: unit root, a = 1)
-------------------------------------
Test with constant
â - 1 = -0.0591989
Test stat tau_c(1) = -1.70189
Asympt. p-value = 0.4303
-------------------------------------
Test equation:
Dependent variable differenced: (1-L)LRM,
lagged level with coefficient a - 1,
including 4 lagged differences
(exclusion test F(4, 44) = 4.290 [0.0051]),
and constant term.
Residual 1st-order autocorr = 0.075
Sample size = 50
--------------------------------------
"
Now I'm not saying my suggestion is optimal, but I do think it would be
an improvement. If somebody directs me to the right places in the
source, I could try to make the corresponding changes.
What do you think?
cheers,
sven
9 years, 12 months
Strange behavior executing function package w/o dataset
by Sven Schreiber
Hi,
I just noticed that when I try to execute a package ("gears" button) and
no dataset is in place, the sample script is opened instead. From the
point of view of gretl it's perhaps understandable, but I was quite
confused even with all my gretl experience. Presenting an example is
nowhere near the definition of execution IMHO. I'd prefer a message like
"this package needs a dataset in place".
Also, what about packages that don't operate on actual data? I think
there was some discussion about it a while ago, but I don't remember the
conclusion.
thanks,
sven
10 years
Parser bug with ' and :
by Sven Schreiber
Hi,
this works:
<hansl>
matrix cumix = ones(3,1)
cumix = cols(cumix) > rows(cumix) ? transp(cumix) : cumix
</hansl>
but this --which should be equivalent, no?-- doesn't:
<hansl>
matrix cumix = ones(3,1)
cumix = cols(cumix) > rows(cumix) ? cumix' : cumix
</hansl>
The error is "invalid symbol ':' in this context". Yesterday's cvs and
snapshot.
Thanks,
sven
10 years
trading bundles with R
by Riccardo (Jack) Lucchetti
Folks,
it occurred to me that our way of communicating with R (and potentially
other packages, but let's focus on R for the moment) could be much
improved if we had R functions for reading/writing bundles as R lists.
I started experimenting a little with the "XML" R package. For example:
<hansl>
bundle a = null
a.n = 512
bwrite(a, "a.xml")
<hansl>
and then do
<R>
library(XML);
a <- xmlParse("a.xml");
b <- xmlToList(a);
c <- b[1]$`bundled-item`$text
n <- as.numeric(c);
print(n);
</R>
and this is quite cool. Of course this would have to be properly
generalised/extended on the R side. I suppose that for someone who's
fluent in R it shouldn't be too much work. Is anybody willing to help with
this?
-------------------------------------------------------
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
-------------------------------------------------------
10 years
luxury request: argument display in package GUI
by Sven Schreiber
Ok,
so this is a decadent request for luxury: it would be cool if some of
the arguments to a function package could be displayed in more detail in
the entry fields in the package dialog window.
Take lists for example. Say I have a list which I use as an argument of
a function package:
list myl = LRM LRY # taken from denmark.gdt
After choosing this from the drop-down menu in the package top-level
dialog this will be displayed in the entry field simply as "myl". What
if instead it would be displayed as:
"myl: LRM LRY"
The obvious advantage is that I don't have to remember how I defined my
lists in the beginning of a long session. If it's a longer list it could
be abbreviated as "myl: LRM LRY ...".
Similarly, but less necessary, for matrices; instead of displaying
"mymat" it could be shown as:
"mymat: {1, 5, 0.5; ..."
As I said, this is of course not _really_ necessary, but nice-to-have.
thanks,
sven
10 years
language mish-mash in function package GUI
by Sven Schreiber
Hi,
following up on the general discussion / request to localize function
packages: I haven't chosen my side on this one yet, but I do find it
problematic that when you invoke a function package in the GUI there are
some generic text components that are translated and then there are the
strings from the package which cannot be translated. All in the same window.
As an interim solution I would prefer if the marked-for-translation
property of the relevant strings in the C source were revoked such that
everything that has to do with packages is in a single language
(English). IMO this would not mean anything with respect to the
long-term language decision.
Any other opinions?
thanks,
sven
10 years
dealing with addons in CVS
by Sven Schreiber
hi,
I'm unsure how to deal with the official gretl addons (in this case
mainly SVAR) for building from CVS. When I build gretl (on Linux) in the
standard way, I don't get SVAR installed. But I think if I downloaded it
from within the running gretl, I wouldn't get the current CVS version of
the addon, just the current release version, right?
So would I have to do a cvs checkout for "gretl-addons" instead of just
"gretl", and then do "./configure" and "make" inside the gretl-addons
local workcopy directory?
(I cannot test this myself right now, only later.)
thanks,
sven
10 years
textplot with matrices
by Sven Schreiber
Hi,
I think it would be useful if the 'textplot' command also accepted a
matrix instead of a list of series. The columns of the matrix would
simply be interpreted as series.
The use case is that using textplot the length of the data vectors is
currently limited by the workfile range, since the data vectors must be
transformed into gretl series first. This is a limitation I'm
experiencing in my BreitungCandelonTest.gfn function package.
Of course this is not super important, but also I would expect that it's
not too much work to implement for the savvy coders out there, hence
this request. But maybe I'm wrong.
thanks,
sven
10 years