Re: [Gretl-devel] RFC: $sigma & co.
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