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
