Re: [Gretl-users] Possible redundancy of some function packages?

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