On Sat, 31 Oct 2020, Allin Cottrell wrote:
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!
Sorry, I meant "non-symmetric". That's where the negative diagonal
elements come from. They are, in fact, misplaced covariances.
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.
Ah, good idea.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------