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