commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Berlin <kber...@gmail.com>
Subject Re: [Math] Cleaning up the curve fitters
Date Thu, 18 Jul 2013 13:16:46 GMT
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 <gilles@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message