I'm wondering whether some of the function packages are still needed, because sometimes it looks as if the same functionality is already built into gretl. Here's a quick list in random order: 1) "clustered_ols" by Claudia Pigini. In what way is this different from the built-in "ols ... --cluster=xyz"? 2) "cnumber" by Monsueto, S.E -- Here I don't think it's redundant but I'm not getting the same results as with other code that should (?) be equivalent. Consider this example and please explain why the results are different: <hansl> include cnumber.gfn open greene12_1.gdt matrix X = {age, income, expend} cnumber (X) l = eigensym(X'X, null) # lines taken from Allin's email CN = maxc(l)/minc(l) # printf "CN = %g, (square root = %g)\n", CN, sqrt(CN) </hansl> 3) "fgls" by Yi-Nung Yang: the help just says feasible GLS which is very vague and generic; in what way is this different from gretl's "hsk" or "wls" commands? If it is different, I would suggest to make the help text more informative. 4) "GHegy" by Ignacio Díaz-Emparanza and "HEGY_test" by Jack Lucchetti. Could you guys perhaps consolidate these? 5) "HoltWinters" by Ignacio Díaz-Emparanza. This sounds a lot like it's also done by the "fcModels" package by Yi-Nung Yang. Is this true? 6) "JB" by Yi-Nung Yang. This does a Jarque-Bera test and even the help text mentions that it is built into gretl (as "normtest ... --jbera"). So it's not obvious to me what the purpose of the package is. 7) "MWU" and "mwu" by Yi-Nung Yang. AFAICS the only difference is whether you pass the arguments as series or as vectors (matrices). This may be a matter of taste, but personally I would suggest that you choose which is the interface of your function, i.e. series or matrices, and then the user/caller will have to follow that rule, and the other package with the other interface would be gone. And with respect to "mwu_dummy", this is even more of a personal taste thing, but perhaps you could consolidate all this into one function, for example by introducing a third function parameter with a default value: "function void mwu(series x, series y, int dummy[0])" So to do what "mwu_dummy()" does now you would pass your 'group' variable as y, and call the function with dummy=1.

Em 5 de novembro de 2005, Allin escreveu: (...) I won't go into all the specifics -- although I think you're right -- but rather I'll address the general issue here. We could really do with some editoral control over the function packages. Up till now we have been totally "laissez faire", but if the packages on the server are supposed to be a showcase for adding to gretl's built-in functionality they need to be pruned and consolidated. I wonder if we could assemble a committee of 2 or 3 members to work on this. I would like to be one of them. I really like to test that kind of stuff :-)

One other thought: some of the current packages that are strictly redundant might nonetheless be preserved in some form as nice examples of scripting. For example, Claudia Pigini's "clustered_ols". Maybe there should be an "example scripts" area separate from the function package area? Dear Allin, I think the introduction of an "example scripts" area is a very good idea. We could place it inside the "Tools" menu naming it with something like "Examples and books/articles replications".

Em 5 de novembro de 2005, Allin escreveu: (...) I won't go into all the specifics -- although I think you're right -- but > rather I'll address the general issue here. > > We could really do with some editoral control over the function packages. > Up till now we have been totally "laissez faire", but if the packages on > the server are supposed to be a showcase for adding to gretl's built-in > functionality they need to be pruned and consolidated. I wonder if we could > assemble a committee of 2 or 3 members to work on this. > I would like to be one of them. I really like to test that kind of stuff :-)

On Thu, 6 Nov 2014, Henrique Andrade wrote: > Em 5 de novembro de 2005, Allin escreveu: > > (...) > > I won't go into all the specifics -- although I think you're right -- > but >> rather I'll address the general issue here. >> >> We could really do with some editoral control over the function >> packages. >> Up till now we have been totally "laissez faire", but if the >> packages on >> the server are supposed to be a showcase for adding to gretl's built-in >> functionality they need to be pruned and consolidated. I wonder if >> we could >> assemble a committee of 2 or 3 members to work on this. >> > > I would like to be one of them. I really like to test that kind of > stuff :-) I believe that the Polish team has already done some preparatory work in that direction and it would be a shame it that gets wasted, so in my opinion the best thing would be to join forces. If nobody minds, I'd like to put forward a proposal: Henrique, Sven and someone else (nominated by Tadeusz, Marcin and Paweł) become the package maintenance team, with the following responsibilities: * short run: classify packages with a set of criteria like the ones we've been discussing so far, and make proposals about them (also in the light of the expanding set of features that Hansl has been gaining over the years). For example, Claudia's clustered_ols is IMO quite valuable in terms of example script, while for example I wonder whether we really need "cnumber" any longer, since a possible Hansl equivalent implementation may reduce to the 7-liner <hansl> function scalar cnumber (matrix X "set a variables matrix") matrix A = X ./ sqrt(sumc(X.^2)) matrix En = eigensym(A'A) # compute the roots of AA scalar cn = sqrt(maxc(En)/minc(En)) printf "Condition Number = %12.2f\n",cn return cn end function </hansl> On the other hand, more complex stuff like HIP may become an add-on. Sven's previous message was a very valuable start at this. * medium run: verify that all the packages install and run the provided example script on the widest possible assortment of OSes (various flavours of Windows/Linux/OSX): perhaps, it'd be nice to have someone with some OSX competence in the team, since I assume the people I mentioned can patrol the Linux/Win territory quite well. Of course, I don't mean to force anybody to do things they don't have time for or don't feel like doing, so I don't want anybody to feel obliged. ------------------------------------------------------- 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 ------------------------------------------------------- _______________________________________________ Gretl-users mailing list Gretl-users(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-users

Sorry for (huge) delay, by the paper for JSS consumed almost all my time. But for two weeks the paper is "conditionally accepted" so it's high time to do some funny work. The process of package verification is very complex. I was trying to start this work twice on summer and I found a lot of things (beside the list I've posted to the Gretl-devel in the email "Comprehensive quality control for function packages"). Let me explain just two main topics: 1. Tests Here we have the easiest work: since certain test tests certain thing, we can even run the script with procedure for testing the tests. This is not very complicated and possible to workout in few days. 2. Redundancy Let me give an example: HEGY and DHF tests: do we really have a redundancy here? Rather not, but in case of Jack's "Hegy" and Ignacio's "GHegy" rather yes. So we need procedure for deciding which one should stay or how to join them into just one package. This is (theoretical) easy, but... 2* Some packages consist on (or in more precise word: use) another package(s). So in my opinion in case of wasting the redundancy (what is basic thing in informatics) we MUST write wrappers. What I (now) want to do: this is may last really busy week, so up to 20th November I prepare draft of such procedure with my proposals. In case of the Team I think that we could split the work according to type of the package: tests, estimators and so on. Best Regards, Marcin W dniu 06.11.2014 o 17:52, Riccardo (Jack) Lucchetti pisze: > On Thu, 6 Nov 2014, Henrique Andrade wrote: > >> Em 5 de novembro de 2005, Allin escreveu: >> >> (...) >> >> I won't go into all the specifics -- although I think you're right >> -- but >>> rather I'll address the general issue here. >>> >>> We could really do with some editoral control over the function >>> packages. >>> Up till now we have been totally "laissez faire", but if the >>> packages on >>> the server are supposed to be a showcase for adding to gretl's >>> built-in >>> functionality they need to be pruned and consolidated. I wonder if >>> we could >>> assemble a committee of 2 or 3 members to work on this. >>> >> >> I would like to be one of them. I really like to test that kind of >> stuff :-) > > I believe that the Polish team has already done some preparatory work > in that direction and it would be a shame it that gets wasted, so in > my opinion the best thing would be to join forces. > > If nobody minds, I'd like to put forward a proposal: Henrique, Sven > and someone else (nominated by Tadeusz, Marcin and Paweł) become the > package maintenance team, with the following responsibilities: > > * short run: classify packages with a set of criteria like the ones > we've been discussing so far, and make proposals about them (also in > the light of the expanding set of features that Hansl has been > gaining over the years). For example, Claudia's clustered_ols is IMO > quite valuable in terms of example script, while for example I wonder > whether we really need "cnumber" any longer, since a possible Hansl > equivalent implementation may reduce to the 7-liner > > <hansl> > function scalar cnumber (matrix X "set a variables matrix") > matrix A = X ./ sqrt(sumc(X.^2)) > matrix En = eigensym(A'A) # compute the roots of AA > scalar cn = sqrt(maxc(En)/minc(En)) > printf "Condition Number = %12.2f\n",cn > return cn > end function > </hansl> > > On the other hand, more complex stuff like HIP may become an add-on. > Sven's previous message was a very valuable start at this. > > * medium run: verify that all the packages install and run the > provided example script on the widest possible assortment of OSes > (various flavours of Windows/Linux/OSX): perhaps, it'd be nice to > have someone with some OSX competence in the team, since I assume the > people I mentioned can patrol the Linux/Win territory quite well. > > Of course, I don't mean to force anybody to do things they don't have > time for or don't feel like doing, so I don't want anybody to feel > obliged. > > ------------------------------------------------------- > 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 > ------------------------------------------------------- > > > _______________________________________________ > Gretl-users mailing list > Gretl-users(a)lists.wfu.edu > http://lists.wfu.edu/mailman/listinfo/gretl-users -- Marcin Błażejowski GG: 203127

Sorry for (huge) delay, by the paper for JSS consumed almost all my time. But for two weeks the paper is "conditionally accepted" so it's high time to do some funny work. The process of package verification is very complex. I was trying to start this work twice on summer and I found a lot of things (beside the list I've posted to the Gretl-devel in the email "Comprehensive quality control for function packages"). Let me explain just two main topics: 1. Tests Here we have the easiest work: since certain test tests certain thing, we can even run the script with procedure for testing the tests. This is not very complicated and possible to workout in few days. 2. Redundancy Let me give an example: HEGY and DHF tests: do we really have a redundancy here? Rather not, but in case of Jack's "Hegy" and Ignacio's "GHegy" rather yes. So we need procedure for deciding which one should stay or how to join them into just one package. This is (theoretical) easy, but... 2* Some packages consist on (or in more precise word: use) another package(s). So in my opinion in case of wasting the redundancy (what is basic thing in informatics) we MUST write wrappers. What I (now) want to do: this is may last really busy week, so up to 20th November I prepare draft of such procedure with my proposals. In case of the Team I think that we could split the work according to type of the package: tests, estimators and so on. Best Regards, Marcin W dniu 06.11.2014 o 17:52, Riccardo (Jack) Lucchetti pisze: > On Thu, 6 Nov 2014, Henrique Andrade wrote: > >> Em 5 de novembro de 2005, Allin escreveu: >> >> (...) >> >> I won't go into all the specifics -- although I think you're right >> -- but >>> rather I'll address the general issue here. >>> >>> We could really do with some editoral control over the function >>> packages. >>> Up till now we have been totally "laissez faire", but if the >>> packages on >>> the server are supposed to be a showcase for adding to gretl's >>> built-in >>> functionality they need to be pruned and consolidated. I wonder if >>> we could >>> assemble a committee of 2 or 3 members to work on this. >>> >> >> I would like to be one of them. I really like to test that kind of >> stuff :-) > > I believe that the Polish team has already done some preparatory work > in that direction and it would be a shame it that gets wasted, so in > my opinion the best thing would be to join forces. > > If nobody minds, I'd like to put forward a proposal: Henrique, Sven > and someone else (nominated by Tadeusz, Marcin and Paweł) become the > package maintenance team, with the following responsibilities: > > * short run: classify packages with a set of criteria like the ones > we've been discussing so far, and make proposals about them (also in > the light of the expanding set of features that Hansl has been > gaining over the years). For example, Claudia's clustered_ols is IMO > quite valuable in terms of example script, while for example I wonder > whether we really need "cnumber" any longer, since a possible Hansl > equivalent implementation may reduce to the 7-liner > > <hansl> > function scalar cnumber (matrix X "set a variables matrix") > matrix A = X ./ sqrt(sumc(X.^2)) > matrix En = eigensym(A'A) # compute the roots of AA > scalar cn = sqrt(maxc(En)/minc(En)) > printf "Condition Number = %12.2f\n",cn > return cn > end function > </hansl> > > On the other hand, more complex stuff like HIP may become an add-on. > Sven's previous message was a very valuable start at this. > > * medium run: verify that all the packages install and run the > provided example script on the widest possible assortment of OSes > (various flavours of Windows/Linux/OSX): perhaps, it'd be nice to > have someone with some OSX competence in the team, since I assume the > people I mentioned can patrol the Linux/Win territory quite well. > > Of course, I don't mean to force anybody to do things they don't have > time for or don't feel like doing, so I don't want anybody to feel > obliged. > > ------------------------------------------------------- > 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 > ------------------------------------------------------- > > > _______________________________________________ > Gretl-users mailing list > Gretl-users(a)lists.wfu.edu > http://lists.wfu.edu/mailman/listinfo/gretl-users -- Marcin Błażejowski GG: 203127

There's one condition I have which I think is necessary for maintaining the function packages: Like I've said before I think we need a tagging functionality for the packages, such that we can classify/categorize them and such that users can do meaningful searches in the list of packages. Each package could have n > 0 tags. For the present packages the maintenance team could add them, and in the future it would be partly the responsibility of the authors to provide tags.

Dear all! On making Gretl (gui2) about.o requires several files from /usr/include/gtk-3.0/  Some files are moved to /usr/include/gtk-3.0/gdk/deprecated/, e.g. gdkcolor.h and to /usr/include/gtk-3.0/gtk/deprecated/ e.g. gtkmisc.h As a result, make ends with non-zero exit status. I use Debian/jessie Oleg

Hi everybody, 6) "JB" by Yi-Nung Yang. This does a Jarque-Bera test and even the help text mentions that it is built into gretl (as "normtest ... --jbera"). So it's not obvious to me what the purpose of the package is.

On Fri, 7 Nov 2014, yinung at Gmail wrote: > 2014-11-06 0:14 GMT+08:00 Sven Schreiber <svetosch(a)gmx.net&gt;: > >> Hi everybody, >> >> 6) "JB" by Yi-Nung Yang. This does a Jarque-Bera test and even the help >> text mentions that it is built into gretl (as "normtest ... --jbera"). >> So it's not obvious to me what the purpose of the package is. >> > > "JB" package was written by me before it was built into gretl. > Actually, I > am glad to see it as a built-in command now. However, there would be > still > a possible small improvement on this built-in command. > > JB is often used on checking the residuals of OLS in which the degree of > freedom should be taken into account in calculating the JB statistic. The > current "normtest" might consider adding a parameter specifying the > number > of coefficients in OLS if it is used on checking the residuals. That > would > make little numerical difference (for example, see codes below), but it > might be import in teaching undergraduate econometrics. I beg to differ: the JB test is a LM test of the null of normality versus the alternative hypothesis that the "real" distribution belongs to the Pearson family. All its properties rely on asymptotics: it is _possible_ that some degrees-of-freedom adjustment may marginally improve its size/power properties, but I'm not aware of any evidence on this.