Hi. > > [...] > >> > >> In this case, the new API with boundaries setting should not be set > >at > >> the level of the abstract class that is share by CMA-ES, Bobyqa, > >> Nelder-Mead and MultiDirectional. > > > >You are right but this was considered as a compromise in order to avoid > >an > >additional level in the hierarchy: > >BaseAbstractSimpleBoundsScalarOptimizer<FUNC extends > >MultivariateRealFunction> > > extends BaseAbstractScalarOptimizer<FUNC> > > > >Shall I add it? > >If there aren't any drawbacks apart from an additional class, it is > >indeed > >clearer. > > If you think it's clearer, then go ahead.
In principle, it would be; but in practice, this entails adding one "...SimpleBounds..." class or interface for each existing class of interface that could support simple bounds. [Then, if someday we add another kind of constraint, this will again multiply by two the number of classes and interfaces...] I think this will complicate things a lot for no benefit. With the current version, I assumed that an algorithm may choose to ignore the bounds settings. If we must make things really fool-proof, the algorithms that do not support bounds could throw "UnsupportedOperationException" from the corresponding "optimize" (which must then be overridden in each affected class). What do you think? > > [...] Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
