commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] Re: [jira] Created: (MATH-451) "solvers": Make the maximum number of evaluations a parameter of the "solve" methods
Date Fri, 03 Dec 2010 23:35:22 GMT

> > 
> > Currently, the number of allowed evaluations is set by the {{setMaxEvaluations}}
> > 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.

Since it's breaking compatibility, I don't see how it could be allowed in

Then, why do you want to deprecate and remove the existing methods?

> 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 ?

With a negative value, the "solve" will just throw immediately, reminding
the user that his choice doesn't make any sense.

> 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 chose "100" because it is the default value for the number of iterations
in 2.1.
If there is a default, I think on the contrary that it should not be high:
when a user expects that an algorithm will take many iterations, he should
set the number explicitly. A relatively low number will help in drawing the
user's attention that some computation may be longer than he expects (or
maybe that the problem he tries to solve is ill defined).
The default should be a compromise between "works in most cases" and "don't
loose too much time before failing anyway".

> 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.

One reason for keeping a default is that we don't have to change all the
calls in the unit tests...


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message