this is what I have in my mind for few months:
We should work out a coherent system of TAGs (beside the dataset type
and version). I my opinion it would be something like this:
1st level TAG - general functionality: estimator, test, other(?).
2nd level TAG - area of usage: statistics, general econometrics,
financial econometrics, spatial econometrics, dynamic econometrics, other(?)
3rd level TAG - complexity (for example number of public functions):
simple (DHF_test), advanced (gig).
At the beginning we should decide if we allow the redundancy or not?
If 'yes', there is no further action in this area, but if 'no' we should:
- decide whether given packages are redundant.
- which one is going to be left.
If we withdraw redundant package we should decide if there is sense
and/or possibility to write a wrapper for at least basic functionality.
Remember: some packages may consist on other packages.
- The problem occurs when we want to write a wrapper but we can't.
In such case we may:
* ask author(s) of combining redundant packages
* combine packages by ourselves
* let both packages to exist
3. Package verification
Allin wrote a nice code for fast verification of sample scripts. This
would be a start point, but later we should:
- Check if package is complete: name and email(!) of the author,
TAGs, version, help (we should think about PDF in the gretl (like gig
has) or available at the packages server to download) and sample script.
- Allin's code verifies the sample script, but at least for
estimators and test we could ask authors of sample data and benchmark
results. We were talking about it at Ancona this summer and I know that
there may be some copyright issues, but is such case we can think about
- If package collapses we:
* should withdraw the packages from the server
* can look at the problem and try to fix it by ourselves or
contact the authors; here we have such possibility that the problem lies
inside the gretl (for example backward incompatibility) - I don't have
an idea what we should do in such case?
* until the package is not fixed it cannot be uploaded to the server
4. Team work
I think we could think about 'maintainers' of the:
- 1st level TAG? or
- 2nd level TAG? or
IMHO we could have maintainers of the 1st level TAG.
If you agree I would be the 'maintainer' of the maintainers which means
I would take a decision on miss classified packages and give a green
light for fixed packages to be uploaded to the server and I don't know
What do you think?
All the Best,
W dniu 10.11.2014 o 12:21, Marcin Błażejowski pisze:
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
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.
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.
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
>>> 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
>>> 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
> 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
> 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
> Riccardo (Jack) Lucchetti
> Dipartimento di Scienze Economiche e Sociali (DiSES)
> Università Politecnica delle Marche
> (formerly known as Università di Ancona)
> Gretl-users mailing list