On Mon, Jun 27, 2022 at 9:41 AM Sven Schreiber <svetosch(a)gmx.net> wrote:
Am 27.06.2022 um 15:31 schrieb Sven Schreiber:
> Am 27.06.2022 um 14:35 schrieb Cottrell, Allin:
>>
>> I think the right thing to do is set the result to NA if an NA value
>> is encountered in the row or column in question. That's now in git.
>
> Thanks, Allin, that handling is certainly consistent with the behavior
> of similar such functions in gretl.
>
P.S.: I don't know how relevant this is, but this bugfix would change
the implicit behavior of these functions also in cases where the result
wasn't really wrong. What I mean is: If I understand you correctly, all
NAs except the (potential) one in the first element were implicitly
being ignored.
Yes, that's what was going on -- and it was clearly untenable. There's
no reason to treat NAs (NaNs) differently if they happen to fall in
the first element of a row or column versus later on.
Any fix is going to change the behavior of these functions, in the
pathological case where matrices contain NaNs. I'd rather insist on
propagation of NaNs according to IEEE rules than trying to concoct a
way of ignoring them. Maybe it's worth noting that if you're doing
something truly "matrix-y" with matrices (multiplication,
decomposition, inversion or whatever) there's absolutely no way to
ignore NaNs, and it's redundant to say "note that we're not ignoring
NaNs".
Allin