[Gretl-devel] Re: different eigenvalue error handling for non-numeric input
On Wed, 26 Mar 2025, Riccardo (Jack) Lucchetti wrote:
[On what gretl should do if the input matrix for a decomposition
function contains non-finite values, and specifically whether we
should flag an error or return (if possible) a result that also
contains non-finite values.]
I'd be ok either way, as long as the inconsistency is resolved
and
the documentation is clear. Again, I have a slight preference for
returning an error since I can't think of a real-life situation
when the attempt to calculate the eigenvalues of a matrix
containing NAs is not the outcome of some previous mistake, but
it's not something I'll put up a fight on.
gretl's gretl_matrix.c contains a function gretl_matrix_na_check()
which can be used to pre-check the matrix argument for a user-space
function such as eigensym(). At present this is in fact used in only
two cases: eigensym() and eigsolve(). In all other cases we just
pass the argument to the relevant LAPACK function and let the chips
fall where they may: in some cases one gets output containing NAs --
with non-finite values propagating according to IEEE rules -- while
in others LAPACK/BLAS flags an error and we don't produce output.
Merely in terms of what's easiest to achieve consistency, we could
omit the current calls to gretl_matrix_na_check(). I can see a case
for the opposite policy, namely generalizing this check, but that
would involve more work and I'm not sure it would be optimal. Most
of the time matrices don't contain any non-finite values, and we'd
have to spend a bunch of cycles checking every element of big matrix
arguments.
Here's a thought. Not sure if it's worthwhile, but we could have a
"set" variable that turns on NA-checking for matrix arguments. That
would make it easier to determine where, in some complicated
contexts, things first go wrong.
Allin