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
<p002...@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
_______________________________________________
Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it
To unsubscribe send an email to gretl-devel-le...@gretlml.univpm.it
Website:
https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/
