On Sun, Nov 18, 2012 at 8:51 AM, Allin Cottrell wrote:
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

I like this solution since, at least for my purposes, it solves an immediate problem.  I'm trying to stuff the std errors after a _restrict --full_ statement into a bundle.  The function that initiates the bundle fails because \$stderr is not returned.  I can _catch_ the error and put something into the matrix, but that defeats the purpose of using the _restrict --full_ in this case.   I realize the example is extreme, but I'm stress testing the set of functions for a RLS Stein-rule package I'm working on.

I probably need to reassess  how I'm computing the restricted estimates in order to make the thing backward compatible with previous versions of gretl.  My first version used something similar to the Greene example Allin gave, but the restrict function is so elegant I couldn't resist using it instead.  Still, being able to put matrices that contain NA into a bundle will pay dividends down the road I think, especially because there are so many accessors available for subsequent use  ....  gretl does contain several ways to dress these up once they are available (e.g.,  misszero() ).

Thanks,
Lee

--