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