Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4CF928E9.5020409@free.fr>
Date: Fri, 03 Dec 2010 18:29:13 +0100
From: Luc Maisonobe <Luc.Maisonobe@free.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: [math] Re: [jira] Created: (MATH-451) "solvers": Make the maximum
 number of evaluations a parameter of the "solve" methods
References: <4106785.94311291389551252.JavaMail.jira@thor>
In-Reply-To: <4106785.94311291389551252.JavaMail.jira@thor>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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