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. >>>>> >>>>> https://issues.apache.org/jira/browse/MATH-1210 >>>>> >>>>> 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. Phil > > > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
