On Sat, 31 Oct 2020, Riccardo (Jack) Lucchetti wrote:
On Sat, 31 Oct 2020, Sven Schreiber wrote:
>> 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.
Not necessarily. We may decide to keep $coeff and $vcv the way they are now
(that is, without rho) and just fix $vcv. But as I said, I'd be happier if we
changed this design decision. If Allin gives me the green light on this, I'll
try to get things done asap (not before Monday, thoough, I'm afraid).
The "fix up $vcv" option occurred to me too, though I'm not saying
it's the best solution. Probably better to incorporate rho. BTW, in
the biprobit examples I checked I haven't seen the non-square $vcv
that Jack mentioned, though I have seen some negative diagonal
elements!
While we're at it, I think there may be one or two other cases of ML
estimation where there's an "extra" parameter excluded from $coeff,
$stderr and $vcv and tacked onto the model struct separately. But
I'll need to check properly.
Allin