[math] Re: [jira] Created: (MATH-451) "solvers": Make the maximum number of evaluations a parameter of the "solve" methods

[Luc Maisonobe <Lu...@free.fr>]

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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [math] Re: [jira] Created: (MATH-451) "solvers": Make the maximum number of evaluations a parameter of the "solve" methods

[Gilles Sadowski <gi...@harfang.homelinux.org>]

Hello.

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

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

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

Best,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org