2:46 p.m.
Hi,
consider this with gretl 2025a:
<console>
? matrix hello = {1/0} # to get invalid input
? = eigensym(hello)
Not a Number geschah bei Berechnung
? = eigen(hello)
1.#INF
? = svd(hello)
nan
</console>
So we have everything: a hard-stopping error, some IEEE code (?), and a
gretl code. Plus, with a 6x6 matrix input I also saw that eigen() spat
out a "Data error".
I think it would be good if this could be a little harmonized, no?
thanks
sven
2:52 p.m.
On 25/03/2025 15:46, Sven Schreiber wrote:
Hi,
consider this with gretl 2025a:
<console>
? matrix hello = {1/0} # to get invalid input
? = eigensym(hello)
Not a Number geschah bei Berechnung
? = eigen(hello)
1.#INF
? = svd(hello)
nan
</console>
So we have everything: a hard-stopping error, some IEEE code (?), and a
gretl code. Plus, with a 6x6 matrix input I also saw that eigen() spat
out a "Data error".
Ouch
I think it would be good if this could be a little harmonized, no?
Is it even possible to do without breaking backwards compatibility? I we
don't care about that, I'd favour stopping with an error rather than
returning NAs (FWIW, stopping with an error is what both Octave and R do).
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
3:02 p.m.
Am 25.03.2025 um 15:52 schrieb Riccardo (Jack) Lucchetti:
On 25/03/2025 15:46, Sven Schreiber wrote:
> <console>
>
> ? matrix hello = {1/0} # to get invalid input
> ? = eigensym(hello)
> Not a Number geschah bei Berechnung
> ? = eigen(hello)
> 1.#INF
>
> ? = svd(hello)
> nan
>
> </console>
>
> So we have everything: a hard-stopping error, some IEEE code (?), and
> a gretl code. Plus, with a 6x6 matrix input I also saw that eigen()
> spat out a "Data error".
Ouch
> I think it would be good if this could be a little harmonized, no?
Is it even possible to do without breaking backwards compatibility? I
we don't care about that, I'd favour stopping with an error rather
than returning NAs (FWIW, stopping with an error is what both Octave
and R do).
In this case I guess there will necessarily be some incompatibility
involved.
BTW, notice that with the input above you have to be careful how to
check for validity:
<console>
? = missing(hello)
0
? = isnan(hello)
0
? = ok(hello)
0
</console>
So only ok() indicates a problem here - I'm not saying those are bugs,
since it is true that 1.#INF is neither missing nor NaN in the narrow
sense (AFAIK), just that one has to be careful. As a side note, the
missing() reference doesn't mention a matrix type as input, and the ok()
reference explicitly says about the missing function that it's not for
matrices.
cheers
sven
8:11 p.m.
On Tue, Mar 25, 2025 at 10:52 AM Riccardo (Jack) Lucchetti
<p002264(a)staff.univpm.it> wrote:
On 25/03/2025 15:46, Sven Schreiber wrote:
>
> consider this with gretl 2025a:
>
> <console>
> ? matrix hello = {1/0} # to get invalid input
> ? = eigensym(hello)
> Not a Number geschah bei Berechnung
> ? = eigen(hello)
> 1.#INF
> ? = svd(hello)
> nan
> </console>
>
> So we have everything: a hard-stopping error, some IEEE code (?), and a
> gretl code. Plus, with a 6x6 matrix input I also saw that eigen() spat
> out a "Data error".
Ouch
> I think it would be good if this could be a little harmonized, no?
Is it even possible to do without breaking backwards compatibility? I we
don't care about that, I'd favour stopping with an error rather than
returning NAs (FWIW, stopping with an error is what both Octave and R do).
A couple of comments. First "1.#INF" is Microsoft-specific, other
operating systems would just say "inf" or "-inf". Second, I
wouldn't
rush to make this sort of thing a hard error in all cases. What about
matrix results that contain some nans or infs along with valid values?
But there's clearly an inconsistency between svd() and eigensym() that
should be resolved one way or another.
Allin
8 a.m.
On 25/03/2025 21:11, Cottrell, Allin wrote:
On Tue, Mar 25, 2025 at 10:52 AM Riccardo (Jack) Lucchetti
<p002264(a)staff.univpm.it> wrote:
>
> On 25/03/2025 15:46, Sven Schreiber wrote:
>>
>> consider this with gretl 2025a:
>>
>> <console>
>> ? matrix hello = {1/0} # to get invalid input
>> ? = eigensym(hello)
>> Not a Number geschah bei Berechnung
>> ? = eigen(hello)
>> 1.#INF
>> ? = svd(hello)
>> nan
>> </console>
>>
>> So we have everything: a hard-stopping error, some IEEE code (?), and a
>> gretl code. Plus, with a 6x6 matrix input I also saw that eigen() spat
>> out a "Data error".
>
> Ouch
>
>> I think it would be good if this could be a little harmonized, no?
>
> Is it even possible to do without breaking backwards compatibility? I we
> don't care about that, I'd favour stopping with an error rather than
> returning NAs (FWIW, stopping with an error is what both Octave and R do).
A couple of comments. First "1.#INF" is Microsoft-specific, other
operating systems would just say "inf" or "-inf". Second, I
wouldn't
rush to make this sort of thing a hard error in all cases. What about
matrix results that contain some nans or infs along with valid values?
But there's clearly an inconsistency between svd() and eigensym() that
should be resolved one way or another.
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.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
10:30 a.m.
Am 26.03.2025 um 09:00 schrieb Riccardo (Jack) Lucchetti:
On 25/03/2025 21:11, Cottrell, Allin wrote:
> On Tue, Mar 25, 2025 at 10:52 AM Riccardo (Jack) Lucchetti
> <p002264(a)staff.univpm.it> wrote:
>>
>> On 25/03/2025 15:46, Sven Schreiber wrote:
>>>
>>> So we have everything: a hard-stopping error, some IEEE code (?),
>>> and a
>>> gretl code. Plus, with a 6x6 matrix input I also saw that eigen() spat
>>> out a "Data error".
>>
>> Ouch
>>
>>> I think it would be good if this could be a little harmonized, no?
>>
>> Is it even possible to do without breaking backwards compatibility?
>> I we
>> don't care about that, I'd favour stopping with an error rather than
>> returning NAs (FWIW, stopping with an error is what both Octave and
>> R do).
>
> A couple of comments. First "1.#INF" is Microsoft-specific, other
> operating systems would just say "inf" or "-inf". Second, I
wouldn't
> rush to make this sort of thing a hard error in all cases. What about
> matrix results that contain some nans or infs along with valid values?
> But there's clearly an inconsistency between svd() and eigensym() that
> should be resolved one way or another.
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.
Yeah, same here, I guess. If we go for the hard-error way, advanced code
authors can always use "catch", right? And if it's the nan way instead,
one can check and intercept this with ok(). Under this assumption, it
appears to be mainly about consistency, not a clear preference.
thanks
sven
1:17 p.m.
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
7:11 p.m.
Am 26.03.2025 um 14:17 schrieb Allin Cottrell:
...
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.
Here's a small update for this devel list on further off-list
discussions about these issues since March:
checking other numerical software turned out that the world is very wild
out there; the various programs employ all sorts of error handling, and
they're all at least as inconsistent as gretl is. So it's not so obvious
what to do. (Also because the various error incarnations originate from
different underlying libraries/places, so it's not so easy to harmonize
them at an upper level.)
Just four everbody's general information, this thread didn't just die out.
cheers
sven
7
days inactive
161
days old
7 comments
4 participants
participants (4)
-
Allin Cottrell -
Cottrell, Allin
-
Riccardo (Jack) Lucchetti -
Sven Schreiber