On Thu, 18 Jul 2013 09:16:46 -0400, Konstantin Berlin wrote:
Hi,
I have two points on this
1) See issue MATH-1009
This is not directly related to my question (about cleanup of
_existing_ code); it should thus be discussed in another thread.
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.
Examples?
Benchmarks?
[Currently there aren't any unit tests showing the advantage for
"GaussNewtonOptimizer". Contributions to this effect are most welcome.]
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.
If we know in advance the best method for a given curve fitter (among
those
instantiated in package "o.a.c.m.fitting", then we could maybe
"parameterize"
the optimizer to be used (e.g. through an abstract method
"createOptimizer()".
It would still be transparent to the users.
I think you can easily benchmark if this is the case.
I don't understand what this means.
Gilles
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
