commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From luc.maison...@free.fr
Subject Re: [Math] DirectSearchOptimizer vs NelderMead
Date Mon, 18 Oct 2010 13:21:50 GMT

----- "Gilles Sadowski" <gilles@harfang.homelinux.org> a écrit :

> Hi.
> 
> [This refers to classes in package "optimization.direct".]
> Currently the class "NelderMead" inherits from
> "DirectSearchOptimizer".
> However the method "doOptimize" is _implemented_ in
> "DirectSearchOptimizer".
> This is backwards from the intended design (where an "optimizer" is
> defined
> as a class that implements a specific algorithm within "doOptimize").
> According to this "terminology", "DirectSearchOptimizer" is the
> optimizer
> whereas "NelderMead" could be considered as a specific way to
> construct a
> simplex. [Indeed, that's what seems intended since it overrides the
> abstract
> method "iterateSimplex".]
> 
> So, I think that it would be better to create an interface "Simplex"
> that would contain a method equivalent to the current
> "iterateSimplex".
> "NelderMead" would thus implement "Simplex", and a object of type
> "Simplex"
> should be passed to the constructor of "DirectSearchOptimizer".

I agree DirectSearchOptimizer is a bad name. What is really inside this class is management
of a simplex.

> 
> Along those lines, I'd also try to avoid using "protected" fields such
> as
> the "simplex" variable (defined in "DirectSearchOptimizer" but
> modified in
> "NelderMead").

If we can get rid of protected field, it would be a good thing.

> 
> In this new scheme, the methods "evaluateSimplex" and
> "replaceWorstPoint"
> would also belong to "Simplex".
> 
> What do you think? [This is all untested, so I may have overlooked
> something.]

Just looking at you mail and from what I remember of the classes, your changes are an improvement.
I don't have the time right now to look at this in more details, so go ahead with some testing
and I'll look at it after that.

Luc

> 
> 
> 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