On Sat, 31 Oct 2020, Allin Cottrell wrote:
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.
Since we have a release coming up -- once we've cleared the queue of
pressing bugs! -- I've committed to git what I believe is a
relatively safe fix for the broken $vcv after biprobit, namely
excluding the row and column pertaining to the "extra" parameter
rho.
The mess-up with $vcv was due to writing a covariance matrix of
dimension k+1 into the model struct, then accessing it on the
assumption it was of dimension k. Now we trim it to k before writing
it to the model.
We can revisit this later. It may be better to promote rho to full
"coeff" status, but for now I'm concerned about possible fallout
from that move.
Allin