I've been working on the manual to update the matrix chapter. Only now I realise that there is some inconsistency in the way dollar accessors are used, with respect to variances/covariances after estimation. Typically, after a model is estimated, we use $sigma for the residuals and $vcv for the parameters. However, this is not always the case; some exceptions are well justifed, some less well. 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.

Moreover, we have an accessor ($h) only used for garch estimation, which does the same job as $sigma (which is unused for garch models), when you take into account that the estimate of the conditional variance is not a scalar but a series in these models by their very nature.

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).

On Mon, 28 Apr 2008, Sven Schreiber wrote:

Suppose we change something that breaks an existing package: I guess it's OK if we're explicit about that, and put up a modified version of the package that works with the new release? (With judgment required, of course, on how often to do that sort of thing.)

> 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. Yes, we should do that.

> 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. If you (or someone else) is willing to take charge of that, that's fine by me.

> 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. I think it would be easier to roll such tests into the existing gretl regression suite. I can make this available via the web.

>>> 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. >> >> Yes, we should do that. > > If you want me to do that, I will need a couple of days warning > before an imminent release (maybe the same warning as for > translators)... Thanks, but I think it's probably easiest for me or Jack to do that bit.

On Wed, 30 Apr 2008, Allin Cottrell wrote: > On Mon, 28 Apr 2008, Sven Schreiber wrote: > > [re, reorganizing the $sigma and $vcv accessors] > >> 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.) > > OK. Coding $vcv for VARs should be quite easy. I'll try to see to that tomorrow. Things are a bit trickier for VECMs. Should we return the v-cov matrix of the coefficients in VECM or VAR form?

Am 01.05.2008 12:54, Riccardo (Jack) Lucchetti schrieb: > > Moreover, we have a slight inconsistency in the way we compute things: > $sigma uses the asymptotic formula (ie, E'E over T), while in the displayed > equations we use degrees-of-freedom corrected figures for standard errors. > I'm not overly bothered by this, but some may. What about $sigma in other contexts, is that asymptotic or dof-corrected? I think that should be made consistent.

Am 01.05.2008 14:03, Riccardo (Jack) Lucchetti schrieb: > On Thu, 1 May 2008, Sven Schreiber wrote: > >> Am 01.05.2008 12:54, Riccardo (Jack) Lucchetti schrieb: >> >>> >>> Moreover, we have a slight inconsistency in the way we compute things: >>> $sigma uses the asymptotic formula (ie, E'E over T), while in the >>> displayed equations we use degrees-of-freedom corrected figures for >>> standard errors. I'm not overly bothered by this, but some may. >> >> What about $sigma in other contexts, is that asymptotic or dof-corrected? >> I think that should be made consistent. > > I'm all for consistency in general, but this case is difficult. In OLS > estimation, for example, SSR/T and SSR/(T-k) are both consistent, but the > latter has the additional small advantage of being unbiased under certain > conditions, so that's traditionally what people use. I personally think > it's rather silly to worry about this when you have a decent sample size; > if you don't, well, I doubt very much you should be doing inference _at > all_. > > In other contexts, Tobit models for example, you simply don't have a > choice. In my view, the really important thing is that you know which > formula is used in each case, so that if you feel like re-computing $sigma > to your taste, you have the tools to do it. > I just meant "consistent definition" across the various contexts of $sigma, not consistent in the statistical sense. So if you are saying $sigma for Tobit models is w/o dof correction out of necessity but for OLS it currently is dof-corrected, then I would suggest the rule: "$sigma has a dof correction if at all feasible". That would mean dof correction for the VAR/VECM $sigma. BTW, I remember we had a discussion in the context of the vcv of the betas in the VECM, but I don't remember the result. Is there a dof correction there in the end? (I know I know it's probably in the manual...)

On Wed, 30 Apr 2008, Allin Cottrell wrote:

> I think it would be easier to roll such tests into the existing > gretl regression suite. I can make this available via the web. > Package maintainers could play a useful role, however, by > contributing scripts that exercise their packages. I agree. IMHO, writing test scripts for contributed function packages is be something the package writers should do. How am I supposed to write a test script for econometric techniques I may know nothing about?