On Mon, 2 Feb 2009, Riccardo (Jack) Lucchetti wrote: I'll look forward to hearing your suggestions; I'm not super-confident about what I've done with these things. Sounds great. Personally I don't expect to have time to plan this, but if anyone else is willing to take the initiative on gretl's behalf I'll be glad to "sign on". Good to hear! I've felt a bit in the dark as to how gretl works on the Mac, although it works fine on the one machine I'm able to test on (from time to time), running OS X 10.4. One thing I have in mind, but haven't managed to get to yet, is to try out the new native Quartz implementation of GTK+ for the Mac, which now seems to be reasonably mature. If we can get that working it would cut out the dependency on X11 and make gretl somewhat more Mac-ish. Allin.

I am glad that Jack brought up this issue. Last year, I have mentioned personally to Allin that applying to GSoC could be a good idea. It was too late to do it so, I had offered that I could help organizing this next (this) year. I haven't done this before but I think what needs to be done is we have to determine several potential projects that an interested CS student can undertake over the summer. Then, we need to apply to Google with a well written info on Gretl (and R if this is to be a joint effort) along with the proposed projects. So, first we need to discuss what would be some of the useful projects that we can propose. I think having the seperate library for filters for SPSS, Stata etc. sounds great for a project. So that is one. I can think of some others. What do you think of: 1)- Importing more statistical distributions to gretl using R's stats-library. Gnumeric is using R's library and that way they have the most accurate functions regarding statistical distributions and their inverses among the various spreadsheet software. I know this from my own published study: http://ideas.repec.org/a/eee/csdana/v52y2008i10p4579-4586.html I think we can have lots of new statistical distributions and their inverse functions if a student imported some of the code or implemented the algorithms from R or some other resource. 2)- I remember that at one point Allin asked for help regarding setting up a nicer and more detailed preferences menu where many things that are adjustable only with the command line is accessible from the GUI. I think a project involving this together with maybe some other GUI improvements can be a good idea. 3)- Another one is improving the gnuplot integration so that more and better looking graphs can be produced. I think visualization is very important for a program like gretl and I don't think we are using gnuplot to its potential (unless we learn gnuplot's own language). R is great in easily producing a large selection of beautiful looking plots and so should gretl, using its brilliant graphical interface. 4)- How about implementing or improving some simple statistical functionality? Simple things are useful especially in a classroom environment but their implementation can be delayed or neglected because the resources are limited. How about improving ANOVA for example? 5)- Related to the above, how about implementing the "confidence band plots for mean Y and individual Y values" as in Gujarati 4th edition p.144? I really like the confidence elipse and this one is also very nice. I find this especially useful in teaching and I think it would be good to have it. I am sure there are other things that you can think of. Once we decide on a list of potential projects, I can write a detailed description for each of them. Then, maybe Allin or Jack can help me refine them, which I can submit to Google afterwards. Once we apply to GSoC, can handle the various correspondence and bureacracy work. We also need to assign a mentor for each project. I can volunteer for mentoring too if it is something that I can do. What do you think? Cheers Talha -- "Remember not only to say the right thing in the right place, but far more difficult still, to leave unsaid the wrong thing at the tempting moment." - Benjamin Franklin (1706-1790) --

I would be lying if I said I am not surprised with the lack of response followed by Allin's response on this matter. Here is a well-written proposal from last year: Title: Connecting R and PostgreSQL using DBI The GSoC project involves creating an R add-on package that provides the 'glue' between the DBI package and PostgreSQL. This will bridge the existing gap for a DBI connection between the premier Open Source data analysis system R and the object-relational database management system PostgreSQL. I have seen quite a few projects which involve recoding something in C to gain speed and efficiency. Recoding may not be boring for the student if he is doing it for the first time. He will be learning a great deal, plus he gets paid for it. Good opportunity for us to get something done which would be really boring for a senior programmer. I see the point regarding some of the projects that I have proposed being not modular and therefore unfeasible. On the other hand I don't see what is wrong with my 5th proposal (regarding confidence bands) that you did not comment on. It is modular, relatively simple, something small but nice to have etc. I think it is perfectly doable. Here is another similar project from last year: Title: Adding 3D plots support for Gnumeric/GOffice Gnumeric is capable of working on large sets of data and has a variety of tools for visualising and analysis of 2D data. However, sometimes two spatial dimensions are not enough. Especially scientists often need to visualize their data in 3D. My goal will be to make it possible by implementing the most commonly used visualization method - a 3D surface plot. It will be implemented as a plug-in for GOffice library, like all the other plots. GSoC has some difficulties and extra work but I think it is worth it. One difficulty is we need Allin, Jack and maybe others to accept mentoring some of the students on the projects. As I said, I can mentor one (maybe the confidence band project). GSoC is very nice because that way you get more people involved, studying and understanding the code. This is useful and healthy to have in the long-run. Together with the filters library project, here I see 3 doable projects. Plus I was sure that some of you guys would come up with some other, nice, modular and suitable proposals. That did'nt happen. If you are set on doing the one joint project thing with R, there is nothing more I can say. Regards Talha -- “Remember not only to say the right thing in the right place, but far more difficult still, to leave unsaid the wrong thing at the tempting moment.” - Benjamin Franklin (1706-1790) --

gretl-devel-bounces(a)lists.wfu.edu skrev 2009-02-05 22:21:57 : Well, as soon as I have figured out how to compile gretl on code::blocks and started to study the code, I will start to add all basic statistical functionality (such as e.g. ANOVA) to make gretl a fully featured statistical software (not just an econometrics package). Then gretl may change the name to General Statistics, Econometrics and Time Series Laboratory, or just gretl for short. :-) Andreas

Nobody has replied to my latest email from Saturday. Jack has not said a word on this. He is the one who opened the discussion and I am sure he is aware of my messages. Noone except Allin proposed a project or commented on the ones that I have proposed. This is rather puzzling to me. I have already volunteered to prepare the applications, write the final reports, be the mentor for 2 of the projects etc. Why is it so difficult to say a few words on how to refine it or tell at least wheather you support it or why this cannot be done. It is not even like we will definitely get approved by Google anyway but at least we can try it. I can't see why we should not even try it. I can't see why we would not want to use this available resource to improve gretl a little bit and help a few students get involved and learn open source development. Sorry for taking your time. Talha -- “Remember not only to say the right thing in the right place, but far more difficult still, to leave unsaid the wrong thing at the tempting moment.” - Benjamin Franklin (1706-1790) --

On Mon, 9 Feb 2009, Talha Yalta wrote: You know, Talha, people happen to have lives :-) I'm going back to your 7/2 proposal: 1)- C library for various file filters 2)- Enhancing the gretl database server 3)- Adding more statistical distributions 4)- Improving the NIST test suite function 5)- Adding confidence bands plots and I could add 6)- Improving function packages management (more on this later) On (1) to (5), I'm with Allin. While (1) and (2) are doable, (3) is IMO not worth attempting, at least for now: for statistical distributions we rely ATM mostly on netlib. The R guys have their own code, and GSL is yet another independent implementation. I don't see huge advantages in standardising on one, plus it would be boring and complicated at the same time. I don't find (4) and (5) particularly exciting, so of course I'm not against them but it's not something I'm eager to spend any time on. (6) is probably something feasible and IMO worth doing. At the moment, we manage function packages from within gretl, which is a neat solution when packages are few and little. However, the present solution is not IMHO well suited for more complex contributions. What I'd like to see is something similar to R's library mechanism. Outline: a) we set up a sourceforge project called gretl-packages or so b) function writers upload to sourceforge tar.gz or zip archives, whose internal structure is well defined. I'd abandon our custom-made xml structure in favour of an ordinary archive which contains subdirectories. c) we introduce a gretl command (which could well be modelled after R's install.library() command) which takes care of connecting to sourceforge, downloading the bundle and uncompressing it in the proper place. Of course, a GUI interface could be added as well. For example: suppose that I wrote a package implementing (say) multivariate GARCH models. I'd produce an archive mgarch.tar.gz containing the following subdirs: src/ (with the actual functions) examples/ (with a few example scripts and datasets) doc/ (with pdf or tex documentations files) guihook/ (with xml descriptions of the GUI-callable functions) Then, I'd upload the tarball to sourceforge. The user would a) open gretl b) issue the command (say) "library mgarch --install". This would download the package from sourceforge and unpack it into a suitable subdirectory of his local tree (say, /usr/local/share/gretl_packages/mgarch/). Of course, there would be a GUI equivalent. c) issue the command (say) "library mgarch". This would "include" all the files in /usr/local/share/gretl_packages/mgarch/src/ and create an "mgarch" entry somewhere in gretl's GUI menu. d) use the functions and complain about the bugs :-) This seems doable, in a reasonable timespan, by someone with little prior knowledge of gretl's internals and would be IMO a nice improvement in the way 'outsiders' could contribute. Riccardo (Jack) Lucchetti Dipartimento di Economia Università Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti

Sorry if I sounded harsh. I was a bit frustrated with the lack of replies in general. OK let's forget about it for now. But I do think that sooner or later we will need more stats distributions at least for the sake of completeness. I think (4) is something Google would like to support. I don't know about (5) but, still, I can be the mentor for both of them and see if anyone will be interested in doing them. This sounds like a nice and well thought out project. So, all in all, does it sound good if we were to apply with (1), (2), (4), (5), and (6)? Jack, is it OK to be assigned as the mentor for (1) and (6)? Allin, is it OK being the mentor for (2)? I can be the general coordinator and the mentor for (4) and (5) if it is OK with everyone. I don't think being a mentor involves alot of time or work. I am sure everyone will try their best to help a student in this email list as well. Any more volunteers? Any more project ideas? Any more comments? Cheers Talha -- “Remember not only to say the right thing in the right place, but far more difficult still, to leave unsaid the wrong thing at the tempting moment.” - Benjamin Franklin (1706-1790) --

I have some feature requests regarding gretl's minimization algorithms, which are useful for user-written functions: As I understand it from the User's guide, gretl uses several numerical optimization algorithms, e.g. the Frisch-Newton interior point solver and the Barrodale-Roberts simplex algorithm for quantile esitmation, the Levenberg-Marquardt algorithm for NLS estimation and the BFGS algorithm for MLE. Of these algorithms only the BFGS method is available for user-written functions. Would it be hard to also make the other methods available for user-writen functions, just as the BFGSmax method is avaialble? If not I hope they could be made available. Secondly, if it is not too much work, I would like to see the Nelder-Mead numerical optimization algorithm implemented in gretl and available for user-written functions. Andreas

On Fri, 6 Mar 2009 andreas.rosenblad(a)ltv.se wrote: Thanks for working on this. It's about time that we got a proper build process for Windows worked out. I'll take a good look at this myself, but meantime here are some quick responses. This is a case where there are some additional dependencies for building the documentation: you don't need libxslt to build gretl itself. OK, I'll see about fixing that. "simple_client" is not part of gretl itself; it's a sample program that is supposed to mimic a third party using libgretl. So the idea is that when you're building simple_client, libgretl is already installed on the local system, and pkg-config can pick up the right path for the libgretl header files. build.h is a generated file, created by the perl script builddate.pl. It could easily be written manually, e.g. waverley:~/src/build$ cat build.h #define BUILD_DATE "build date 2009-03-06\n" Allin Cottrell

On Mon, 9 Mar 2009 andreas.rosenblad(a)ltv.se wrote: The necessary files are the ones referenced in win32/Makefile. I'm in the process of trying to construct a "native" Windows version of this file. Allin.