On Sun, 18 Nov 2012, Riccardo (Jack) Lucchetti wrote:

> On Sun, 18 Nov 2012, Allin Cottrell wrote:
>
>> If we were to do this, I'd favour restricting the "clean-up" to the
>> standard errors (printing 0 rather than NA) and let the $vcv
>> accessor show what was actually computed, warts and all.
>
> I think that the flaws from machine precision are of great didactical value.
> IMHO, teaching students that 1.2345e-30 is in fact zero and they should
> _distrust_ software that writes "0" instead of 1.2345e-30 is part of teaching
> good econometrics. That said, in a case like the one Lee brought up, better
> to have 0 than NA.

Agreed.

There are two aspects of our policy to date that are
questionable. First, when computing standard errors from a
variance matrix we've always set the s.e. to NA when we
encounter a negative diagonal entry. This is reasonable in
general, but is arguably too strict when we're producing
restricted estimates.

When we estimate subject to restriction, the "ideal" result is
that (a) the restrictions are met exactly and (b) whenever a
restriction stipulates a definite numerical value for a
parameter, its variance is exactly zero. But -- in line with
your point above -- in general that ain't gonna happen in
digital arithmetic. In a case like Lee's example, with a bunch
of zero restrictions, we expect to find the computed variances
distributed "randomly" in the close neighbourhood of zero,
with some of them likely negative. In that case I think it's
reasonable to print the standard errors as zero, if they're
close enough, but provide the "true" (numerical, ugly)
variance matrix for those who want to see it. That's now in
CVS.

Second, when it comes to retrieving the coefficient or
standard error vector from a model, we've checked for NAs and
if any are found we refuse to supply the object (as Lee
observed). OK, that seems too delicate, or paternalistic, or
something. So now in CVS you can access $stderr even if it
contains NAs.

Allin