On Sat, 31 Oct 2020, Riccardo (Jack) Lucchetti wrote:
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.
Ah, that makes sense. One more thought: there could be strange
fallout from including rho in $coeff and $stderr when it comes to
printing the model output, and possibly other contexts too. Needs
testing anyway.
Allin