Hi, Le 03/12/2010 16:19, Gilles (JIRA) a écrit : > "solvers": Make the maximum number of evaluations a parameter of the "solve" > methods > ------------------------------------------------------------------------------------ > > Key: MATH-451 > URL: https://issues.apache.org/jira/browse/MATH-451 > Project: Commons Math > Issue Type: Improvement > Reporter: Gilles > Assignee: Gilles > Priority: Minor > Fix For: 3.0 > > > Currently, the number of allowed evaluations is set by the > {{setMaxEvaluations}} method. > In the ML, it was proposed to pass that parameter when calling the {{solve}} > method. The setter will be removed. > The existing {{solve}} methods will remain, using a default value (100) for > the the maximum number of evaluations. > >
For simplifying transition, this should probably be added in 2.X rather than in 3.0. Of course it IS an incompatible change since it is in a public interface, but this interface is not intended for people to implement it. It is rather an interface commons-math implements in the spirit of the algorithm design pattern: the user can rely on the interface definition if he wants a generic solver (or he uses a specific solver if a needs special features available only in one type of solver). So I would propose to first add the new methods in the interface in 2.X, and only deprecate the old ones without maxEvaluations. We would delete the deprecated methods as proposed in 3.0. I'm not sure if there should how the default value should be handled: an additional method in the interface or a special handling if for example the provided value is 0 or negative ? Also as this maxEvaluation is mostly used as a safeguard to avoid infinite loops, a default value should be much higher than 100. Probably something like 1000 or event higher. I would personnaly prefer to not have a default value and let the user always set one as he wants according to his type of problem. However, I'm on the fence on it. best regards, Luc --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
