Does the LUDecomposition not use pivots? LU should always do so since it is numerically unstable otherwise. I would be surprised if it doesn't given the normal level of quality in commons math.
QR is, of course, almost always preferable to LU as you note. But I would be surprised at radically different answers. Perhaps the only real difference between the two methods in this one case is a difference in threshold. What is the condition number of your matrix? On Wed, Sep 7, 2011 at 6:34 AM, Gilles Sadowski < gil...@harfang.homelinux.org> wrote: > Hi. > > > >>> > > >>>In class "AbstractLeastSquaresOptimizer" (in > "o.a.c.m.optimization.general"), > > >>>the method "getCovariances()" uses "LUDecompositionImpl" to compute > the > > >>>inverse of a matrix. > > >>>In my application, this leads to a "SingularMatrixException". If I > change > > >>>"LUDecompositionImpl" to "QRDecompositionImpl", no exception is > raised. > > >>>Also, keeping "LUDecompositionImpl" but passing a much lower > singularity > > >>>threshold, does not raise the exception either. > > >>> > > >>>Thus, I wonder whether there was a reason for using "LU", and if not, > > >>>whether I could change the decomposition solver to "QR" (as this is a > > >>>cleaner solution than guessing a good value for the threshold). > > >> > > >>There are no reason for LU decomposition, and QR decomposition is > > >>known to be more stable. So I would also consider switching to this > > >>algorithm is a cleaner solution. > > > > > >Fine. I'll open a JIRA issue. > > > > > >A unit test "testNonInvertible" in "LevenbergMarquardtOptimizerTest" > fails > > >with the change to "QRDecomposition" because no > "SingularMatrixException" > > >is raised anymore. > > >What was the purpose of that test? > > > > The purpose was to check that impossible problems were detected properly. > > My question should have been clearer: Was the previous behaviour correct > (i.e. an exception *must* be raised somehow)? > The switch to "QR" seems to imply that a previously impossible problem is > now quite possible. So, is the problem really impossible or was the test > actually testing a fragile implementation of "getCovariances()"? > > > Regards, > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >