Re: [Gretl-users] Re: gretl development roadmap
El Viernes, 15 de Julio de 2005 02:44, Allin Cottrell escribió:
...
As for forecasting, that's now pretty much done in the latest
release. In gretl CVS we have seasonal ARMA and considerably
enhanced support for VARs. We don't yet have a serious start on
user-defined matrix manipulation, though many of the required basic
functions are there in gretl_matrix.c.
More generally, the question is, what level of sophistication is
gretl aiming for? My original idea (as I recall) was that I wanted
gretl to be an excellent tool for undergraduate-level econometrics.
In 2001 I was several months looking for an econometrics package I could offer
to my undergraduate students for free. I was just discovering "open source"
and Linux, and I was really surprised when I found Gretl. I liked the
structure of gretl just when I saw it, mainly because of its so user-friendly
interface. The Windows version of gretl was full of bugs, so I began to
collaborate sending very long reports of bugs. Now I think we have reached an
stage in which gretl is very stable and very appropiate for teaching
Econometrics in an undergraduate level. It covers now almost all the
undergraduate programs we teach at our University. (With the seasonal ARMA,
it will also cover the programs of the "Time series" subjects, thank you
Allin).
I think we've pretty much got there, but the target has moved.
I think the notion is: If gretl provides a good interface for doing
econometric work, why stop at the basics? The value of gretl, even
to undergrads, will be enhanced if they can continue to use this
program for professional work.
I do not agree with Allin at this subject. Postgraduate econometrics work
usually requires programming at a very specific level. We have a lot of
computer "languages" for doing econometrics at this specific level now:
Gauss, Rats (including the compile mode), Ox, Splus, R, Octave, ...
I the 90's I was a Rats user, and when I discovered the "open source"
philosophy, I thought in porting some of my programs to an "open source"
language.
R is a language and environment for statistical computing and graphics (see
http://www.r-project.org ) which is, as gretl, "open source and free
software", has a very strong user community, a very structured development
team, and a quality control that ensures that the published packages
(libraries and functions) has a very low probability of errors.
I think we should not dedicate much effort in adding new features to the gretl
console, but it will be better for the user to get a better relation with the
R language. At present, we can open a dataset in gretl and through
"Utilities/Start Gnu R" we can open an R session and read our dataset. It is
very usefull, because now we can operate with these data with all the
commands and functions of R. But now we would need a way to recover some of
the R results (yhats, residuals, coefficients, ..) passing them again to
Gretl.
Having this type of link gretl<-->R working, we will avoid the necessity to
program all the features that are already programmed in R. For example,
suppose you need to use the Kalman filter, Structural Time Series Models, or
whatever matricial operation, all of these can be done in R (reading the
manuals, of course).
I think Gretl and R are now complementary programs. Gretl for the basics and R
for the advanced econometrics. Increasing the capabilities of the gretl
console (gretlcli) will lead also the user "to look everything up in the
docs before he can work with data".
We should avoid that the user have to learn two different "languages" for
doing the same things (in R and gretl), and so we should avoid that gretl and
R compete for the users.
I'll try to summarize: My (immodest) notion is that gretl should be
an extremely user-friendly econometrics (and to some extent, general
statistics) package with true cross-platform GUI functionality and
also solid support for scripting. It should be a flagship for
free, open-source software in the statistical domain -- a program
which many users might prefer to expensive proprietary alternatives
(I have some evidence that this is true already).
I agree with almost all above. I only suggest that we should not define
another scripting language very different from the existing ones (specially
from the R language).
--
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU
http://www.bl.ehu.es/~etpdihei/