commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [Math] "LUDecomposition" in "AbstractLeastSquaresOptimizer"
Date Thu, 08 Sep 2011 07:23:40 GMT
On 9/7/11 1:07 PM, Ted Dunning wrote:
> 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.

Me to.
> Perhaps the only real difference between the two methods in this one case is
> a difference in threshold.

Yup.  I think QR is effectively bugged because there is no threshold.
> What is the condition number of your matrix?

> On Wed, Sep 7, 2011 at 6:34 AM, Gilles Sadowski <
>> 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
>> 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
>>>>>> 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:
>> For additional commands, e-mail:

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

View raw message