Hi Gilles, ----- Mail original ----- > 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.
This would be really difficult to understand for users. Most of them don't know which optimizer support bounds and which don't. I would expect them to rely on the fact the method is in the API or not. > > 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? I'm really not a big fan of adding methods just for throwing UnsupportedOperationException in many (if not most) cases. Also having the unbounded method call the bounded one which in turn can ignore the bounds is error prone. What about two different interfaces, one for unbounded optimization and one for simple boundaries ? Some optimizers would implement both, some would implement only one. Thes would be interfaces, not abstract classes in this case. It does make sense and is much simpler. Luc > > > > [...] > > > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
