[Gretl-devel] RFC: $sigma & co.

[Sven Schreiber]

Am 27.04.2008 16:48, Allin Cottrell schrieb:
> On Sat, 26 Apr 2008, Riccardo (Jack) Lucchetti wrote:

>> After estimating a system, $sigma holds the covariance matrix of 
>> the residuals and $vcv the covariance matrix of the parameters 
>> of the structural form; this is nice and consistent with, say, 
>> ols, but is _not_ consistent with VAR/VECM estimation, where 
>> $vcv holds the cov. mat. for the residuals and $sigma is unused. 
> 
> Yup, the VAR/VECM case should be made consistent with the others. 
> the only question is the timescale.  Sven commented not so long 
> ago on backward-incompatible changes; let's wait to hear from him.  
> In the meantime, however, I've made a change that I presume should 
> be uncontroversial: after estimating a VAR/VECM, $sigma now 
> retrieves the covariance matrix of the residuals (so does $vcv, 
> which we'll change at some point).
> 

Although I will be one of the (few?) affected users I agree with Jack 
that $vcv should be changed, especially because it's very simple to 
change $vcv to $sigma to get the scripts working again. (And I like the 
functionality that $vcv will deliver in VAR/VECM contexts.)

However, I still believe that backwards-incompatible changes should be 
addressed a little more formally, and I have a couple of mutually 
independent suggestions:

1. All function packages on the server must be tested to see if they 
will be broken because of the change. Or to put it differently: If they 
don't work any longer after the change, that's officially considered a 
bug in gretl. Otherwise function package contributors will get 
frustrated and the whole idea of enhancing gretl with those 
contributions loses appeal.

2. For each gretl release some notes (readme) are prepared which 
complement the changelog. They explain the backwards-incompatible 
changes and how to solve the associated problems.

3. Another sourceforge tracker is introduced as a database for 
incompatible changes, including information on when such a change was 
introduced (date and version numbers) and how to deal with it.

4. There is a period during which the use of recently changed functions 
triggers a warning that is printed in the output. The period could be 
six months or the duration of one release cycle, whichever is longer. 
(Six months because many Linux distros have that rythm.)

If they are adopted, I guess I would be willing to contribute the work 
behind suggestions 2 and 3. Number 4 would need to be done by the 
source-code-warriors. Number 1 is two-fold: the testing would need 
volunteers ("package maintainers"?), but simply agreeing to the bug 
policy is just a decision, not work.

thanks,
sven