commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [Math] MATH-1210
Date Wed, 18 Mar 2015 16:33:43 GMT
On 3/18/15 5:04 AM, Gilles wrote:
> 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.

Yes, and saying something meaningful about how we can tell from the
QR decomp that the matrix is near-singular is exactly what I am
advocating that we do in this case.  I don't have time atm to go
back and refresh my knowledge of this, but I will add it to my
personal todo to see if I can improve the error message and / or
consider patches that others may provide.

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

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

View raw message