Am 27.06.22 um 15:41 schrieb Sven Schreiber:
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. This is a reasonable behavior, even if it was unintended
-- such behavior is what Artur's feature request was about.
So if people were using the functions intentionally like that, their
code will now be broken. I'm not saying the bugfix is wrong, but maybe
we should think about how to deal with (or even detect such) possible
The minimum is to inform people via the mailing list that the behavior
of some built-in function(s) has changed - I would say.
_Every_ software project has bugs, and this just shows how crucial it is
to write tests when developing code. At the very end everyone is
responsible for his/ her own code and has, in the best case, written
tests to detect bugs or changes due to changed versions.
On the gretl developer side, we should try to do as best as possible to
avoid, detect and fix bugs. Luckily, we already have a suit of tests.
But, as this case has shown, we should also have some for apparently
trivial functions such as imaxr().
And to mention this: Interested people of the community can help us to
extend our already existing but non-exhaustive battery of tests ;-)
Please contact us, if you want to help us.