Hi, I have two points on this 1) See issue MATH-1009 2) If LM was always better there would be no GuassNewton. Clearly this is not the case. LM is a mixture between GN and steepest descent, so it is only faster for "tougher" functions. In case of strictly convex function GN should be a good amount faster. So the correct method depends on the problem. Clearly for some of the fitters you know if the problem is well behaved, so they should use GN, for the general method you cannot say. I think you can easily benchmark if this is the case.
On Jul 17, 2013, at 11:16 AM, Gilles <gil...@harfang.homelinux.org> wrote: > Hello. > > Constructors of classes in the "o.a.c.m.fitting" are instantiated using > an (abstract) "MultivariateVectorOptimizer". The only concrete > implementations of this class are > * LevenbergMarquardtOptimizer > * GaussNewtonOptimizer > [I.e. the API suggests that the Jacobian is not necessary for > some optimizers but no such (vector) optimizer exists currently. > Anyways the Jacobian is computed automatically (in inner class > "CurveFitter.TheoreticalValuesFunction") so that an optimizer > without derivatives is never necessary...] > > Observing that > 1. almost all the unit tests for the fitters use an instance of > "LevenbergMarquardtOptimizer", > 2. some comments in the "GaussNewtonOptimizerTest" unit test class makes > one wonder when "GaussNewtonOptimizer" should actually be preferred > over "LevenbergMarquardtOptimizer", > I would propose to deprecate the non-default constructors in all fitter > classes (and let the fitting be transparently performed with an instance > of "LevenbergMarquardtOptimizer"). > > Any objection? > > > Regards, > 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
