Hello. > >Did you use the "MATH_2_X" or the "trunk" repository? > > > I think "MATH_2_X", but will test with trunk. I think the patch should > be against trunk?
Yes. There were some changes introduced in the 3.0 development version. Namely, please have a look at the "BaseAbstractScalarOptimizer" class in package "direct". It is meant that all implementations inherit from that class for consistency; it contains the boiler-plate code for e.g. counting function evaluations. In fact, subclasses only have to implement the "doOptimize()" method and the algorithm-specific code must call "computeObjectiveValue(point)" in order to evaluate the objective function at "point". If you encounter any problem, I'm ready to help in adapting the code. > > [...] > > >None of the CM algorithms do that. > >No logging is a CM limitation and sometimes a problem (e.g. for debugging). > > Adding the possibility to inject a logger/plotter (for instance as optional > constructor > argument) were only the interface is part of CM would not violate the > "no external libraries requirement". But it would not make logging/plotting > completely > impossible when using CMA-ES. The problem is that we would again be re-inventing some wheel which IMHO doesn't belong to a low-level math library such as CM. A basic logging interface already exists: It's "slf4j". Making a logging interface part of the algorithm interface is IMO far worse than accepting to depend on "slf4j". > [...] Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
