Hello, Le 14/11/2011 16:34, luc.maison...@free.fr a écrit : > 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.
Thanks Gilles for having set up these interfaces. I have tried to create a SimpleBoundsOptimizerAdapter that would wrap a BaseMultivariateRealOptimizer and implement the BaseSimpleBoundsMultivariateRealOptimizer interface, thus allowing to use raw optimizers for solving bounded problems. It turns out to be impossible to hide the underlying function adapters in all cases. The problem lies with the mapping adapter, because it really changes the values. This implies it should be used not only for function evaluation only, but also for start point (this is easy), for result optimum (this is easy), for convergence checker (this is really difficult since convergence is based on deltas) and in the specific case of simplex optimizer, to the simplex itself (this is almost impossible since we have to know it is simplex based and since the initial simplex is also based on deltas). In fact, the existing test cases for the mapping function adapter already show what is needed. So I think we can't completely hide these function adapters, and we should simply let these adapters available for users, who can manage them appropriately and use their mapping in both directions when needed. The user guide was already updated and contains documentation for these function adapters in the optimizers section. This documentation can be extended to explain the convergence and simplex issues for the mapping adapter. Considering this, I am going to resolve issue MATH-196, except if someone complains. best regards, Luc > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
