commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [Math] MATH-1210
Date Wed, 18 Mar 2015 12:04:48 GMT
On Tue, 17 Mar 2015 13:36:36 -0700, Phil Steitz wrote:
> On 3/17/15 11:23 AM, Gilles wrote:
>> On Tue, 17 Mar 2015 10:35:15 -0700, Phil Steitz wrote:
>>> On 3/17/15 5:24 AM, Gilles wrote:
>>>> Hi.
>>>> Any objection to applying that patch?
>>> The error message should be more informative if we are going to
>>> enrich it.  A singularMatrixException with error message "{0} is
>>> smaller than the minimum ({1})" is a little cryptic.
>> For me, it's poor man's logging: the important thing for me is that
>> one can see what went wrong.
> We agree on that point - we want people to be able to tell what went
> wrong.   It's really nice when you can do that without looking at
> the source code. That's where meaningful error messages that make
> sense in the context where they happen can be useful.

Huge effort on myself to not copy/paste all the arguments from the ML
archive... :-}

>> But I don't want to rehash that
>> old discussion. The idea is just to be able to figure out how far
>> from the threshold the instance falls...
>> See my other question (about the covariance matrix) where the
>> discussion could lead to a more interesting improvement (code,
>> documentation and error reporting).
> Yes, that is a good question.
>>>  It would be
>>> better to refer to make explicit what quantity is underflowing.  I
>>> agree with Hank that it would also be good to report which element
>>> of the diagonal was below the threshold.
>> This is done in my working copy (with another "cryptic" message).
> I can't remember how exactly the min QR diag value measures
> near-singularity.  It would be great to at least just report that
> that is what we are using (instead of determinant or some other
> measure that one might expect a SingularMatrixException to report as
> "too small").

The underlying issue (best to discuss on the other thread!) is that
at this point, it should be (IMHO) kept as an implementation detail
(where one needs to read the source): a particular decomposition
method reached its limit, but another might not have. So in addition
to indicating the low-level source of the failure (with a possibly
"cryptic", source-related message), I suggest that we devise an
objective description of why the user's request might be flawed (such
as an indicator of how close to numerically singular the _matrix_ is,
not just of how well a decomposition method can cope with it); this
description deserves a "non-cryptic", high-level, error report.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message