Am 30.10.2020 um 23:41 schrieb Riccardo (Jack) Lucchetti:
Hm, this will require some more work than I had thought. In fact,
I'm
not quite sure we're doing the right thing in the current incarnation of
biprobit. Let me explain. The number of estimated coefficients is k1 +
k2 + 1, where k1 and k2 are the numbers of explanatory variables in the
first and second equation respectively, plus there's rho (actually, its
hypherbolic arctangent).
When we record $vcv into the MODEL struct, we treat the model as if the
number of parameters were k1 + k2, although the covariance matrix is 1
element bigger, with the result that
(a) the $vcv you now get after biprobit is buggy (it's not symmetric)
(b) we don't have in our MODEL struct the estimated variance for atan(rho).
Note that we treat $coeff in the same way, that is we don't store rho
among the estimated parameters, although its estimate is accessible as
$rho or $model.rho.
So I'm wondering: while we're at it, should we "correct" this, at the
risk of backward incompatibility, by including rho in $coeff and making
$vcv a square matrix of dimension (k1 + k2 + 1), or shall we just fix
$vcv and maybe provide an accessor for the standard error of rho?
If rho is appended at the end wouldn't that sort of minimize the disruption?
IMO we should change the output of biprobit and make rho a
"first class
citizen", that is include it in the output just like the other estimated
parameters as well as storing it as the last element of $coeff and
enlarging $vcv and $stderr as needed, but I'd like to hear your opinion
on this before I start working on the code.
If the previous thing was buggy, then I guess the incompatibility is
somehow unavoidable. In that sense I'd say go ahead.
cheers
sven