4:18 a.m.
On Fri, 15 Jul 2005, Ignacio DÃaz-Emparanza wrote:
> 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 have heard Ignacio's point many times, but I'm still not convinced. I
had nearly the same conversation with my friend Christine Choirat (of
OxJapi fame) a few months ago. She's an extremely good programmer, and her
line was basically "why re-invent the wheel?". Instead on working on
gretl, I remember she was planning to create a Tcl/Tk wrapper around R
which would mimic Pc-Give as much as possible.
Well, Allin already outlined a few reasons why the wheel is still worthy
of being worked on. First, R is hard. I consider myself above the average
econometrician when it comes to computer languages (perhaps immodestly),
and still working with R is a PITA for me. R's syntax is very
idiosyncratic, and either you work with it all the time, or you spend 1
hour doing your work and 9 looking at the manual. This is most likely a
big problem for someone who is not a full-time econometrician, but it is
likely to be a big hurdle for people who do applied research who want
something that "just works". Remember, these people form the vast majority
of the users of econometrics/statistical packages. Example: I had a
colleague who needed the HP filter. Fairly standard, no? It took me less
time to add it into gretl (with Allin's help) an give him the upgraded
package than it would have taken having him download and set up R,
learning how to import his data, perform the filtering, and going back to
the applications he normally uses. And once this is done, it's done for
everyone. Rather than the fish, you give people the fishing rod.
If the functionality of gretl as a R front-end can be enhanced, that would
be a very cool thing to have (for me at least), but there's no reason to
be tied to it for the less trivial computations. Besides, if you look at
the source, the infrastructure for adding more sophisticated stuff into
gretl is already there. As always, the most time-consuming thing is laying
out the foundations; user-visible changes are but the proverbial tip of
the iceberg. Case in point: the Johansen procedure for cointegration. This
procedure is possibly used hundreds of times a day by applied researchers
all around the world. My personal estimate is that most people use Eviews
or Pc-Give for this. Some others probably use RATS add-ons like CATS
(Juselius) or Malcolm (Mosconi). Maybe someone uses Stata, or custom-made
gauss or Ox routines. Very very few use R's urca module. As we stand,
no-one uses gretl, because the Johansen procedure is only sketched. Still,
the infrastructure is there, and (mostly thanks to Allin) it will take
only a few weeks to have the full Johansen procedure set up. Once we're
there, I have the feeling that the number of users who would choose gretl
would exceed those who use R by several orders of magnitude.
As for competition between R and gretl. In my view, competition is GOOD.
These are not commercial products. These applications are part of the free
software ecosystem, where biodiversity is essential for survival. Contrary
to commercial software, the existence of a competitor produces POSITIVE
externalities (take a look at KDE/Gnome). There is room for R and gretl,
and to spare, just the same way you get Debian, SuSe, Red Hat, Mandriva,
Ubuntu and all the various linux distros.
Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università di Ancona
jack(a)dea.unian.it
http://www.econ.unian.it/lucchetti