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 ? Luc > > 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 > http://sb9.astro.ulb.ac.be/~pourbaix * mailto:pourb...@astro.ulb.ac.be > > --------------------------------------------------------------------- > 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
