[Gretl-devel] Uploading function packages

I have revised and extended my collection of functions to estimate stochastic frontier models. Now, the complete set includes versions for panel and non-panel data, both with and without heteroskedastic errors. I have some queries before I upload the new versions to the server. A. I have changed the conventions that I have used to name functions. As a result the new versions will not just overwrite the old versions. Is there a method by which I can delete or deprecate the old versions, so as to ensure that users get access to the updated functions? B. Allin mentioned the possibility of providing multiple entry points in a function package. Has this been implemented? At the moment, each of my function packages provides (i) a function for estimating the relevant model, and (ii) another function for obtaining the efficiency residuals using the estimated model. In the case of the panel functions there are subsidiary functions that are shared between the functions in the package. Hence, it would be convenient to load the functions as a package with multiple entry points rather than as separate functions. C. The example runs for the non-panel functions use one of Greene's data files from the standard gretl install package. However, I haven't identified a suitable test dataset for the panel functions, so I have created my test data (an extension of the test data used by Stata). Is there a way of uploading this data along with the sample programs so that users can experiment with a known example? D. I have mentioned previously that the functions can easily run into non-concave regions, which can cause mle using analytical derivatives to fail. [The root problem appears to lie in the behaviour of the function cnorm(x) for large values of x, since the likelihood function contains terms involving 1/(1-cnorm(x)). The fix-up causes discontinuities in the analytical derivatives, but not in the numerical derivatives.] This is a particular problem for the models with heteroskedastic errors. In my experiments I have found that mle using numerical derivatives is less likely to fail, though it may be slow. The current versions are programmed to use analytical derivatives, but it would be easy, though a bit tedious, to provide alternative versions that use numerical derivatives - just an extra option in the calling routine leading to a branch in selecting the versions of mle that are used. The disadvantage is that the function packages will become rather large - in excess of 1,000 lines of code each. Before I do this, I would like to enquire whether it might be possible to embed this directly as an option in mle, rather than via the presence of deriv or parameters commands. Gordon