commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [MATH] Comment on MATH-352
Date Wed, 10 Mar 2010 20:08:43 GMT
Dimitri Pourbaix a écrit :
> Hi,
> I looked at the suggestion related to MATH-352 regarding the robustness of
> the determination of the rank of the Jacobian in Levenberg-Marquardt.  It
> does make sense indeed to replace ak2 == 0 with something more robust like
> ak2<= treshold.  However, if one uses the epsilon machine for the threshold
> as suggested, several tests in LevenbergMarquardtOptimizerTest and
> MinipackTest fail.  Strange, is not it: usually it goes in the other way
> round, when one becomes less strict, fewer tests fail.  Here, it is the
> opposite.

The check is in a shortcut in the algorithm. If ak2 is small, we
consider the matrix is rank-defficient (and we compute the rank). So
when we relax the threshold for the current pure 0 value, we consider
that some perfectly full rank matrices with very small but non null
norms in the final columns are in fact rank-deficient. Basically, we
don't consider these last columns and the solution we find is not the
optimum. This is not strange.

> Should one reassess some of these unit tests?

The failing test in LevenbergMarquardtOptimizerTest is related to
MATH-199. It is useful for the handling of NaN and infinities, but
cannot be seen as a reliable test for rank. So This test should probably
be modified after MATH-352 has been fixed, and its failure should not be
considered too seriously. It is simply probably badly written.

The failing tests in MinpackTest on the other hand should be considered
as reliable reference tests. It is the test suite used for minpack and
has been used for years. When these tests fails, this is a clear
indication something is wrong in the code. These tests are also quite
sensitive, they correspond to really ill-conditioned problems.

So I would suggest to put a customizable threshold with a default value
of MathUtils.SAFE_MIN and a setQRRankingThreshold(double threshold)
method. This will preserve compatibility. With this setting, one could
check all existing tests should pass. The solution proposed by the
reporter does not work on all cases because the threshold is far too
high for the ill-conditioned problems in the minpack tests. In fact, any
threshold greater than 1.0e-66 leads to some tests failing.

We should also use setQRRankingThreshold with more lenient settings to
check we either don't find the optimum or completely fail depending on
the rank we (badly) compute.

Do you want to take care of this issue ?


> Dim.
> ----------------------------------------------------------------------------
> Dimitri Pourbaix                         *
> Institut d'Astronomie et d'Astrophysique *      Don't worry, be happy
> CP 226, office 2.N4.211, building NO     *         and CARPE DIEM.
> Universite Libre de Bruxelles            *
> Boulevard du Triomphe                    *      Tel : +32-2-650.35.71
>  B-1050 Bruxelles                        *      Fax : +32-2-650.42.26
>     *
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message