You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Gilles (JIRA)" <ji...@apache.org> on 2010/12/03 16:19:11 UTC

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

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


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Posted by 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


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

Posted by 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


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

Posted by "Gilles (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/MATH-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966929#action_12966929 ] 

Gilles commented on MATH-451:
-----------------------------

Deprecation done in revision 1042324 (MATH_2_X).


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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Posted by "Gilles (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/MATH-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gilles resolved MATH-451.
-------------------------

    Resolution: Fixed

The {{solve}} methods lacking the {{maxEval}} parameter were removed in revision 1042502 (trunk).


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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/MATH-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966840#action_12966840 ] 

Luc Maisonobe commented on MATH-451:
------------------------------------

I agree with your suggestion.

thanks

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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Posted by "Gilles (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/MATH-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966822#action_12966822 ] 

Gilles commented on MATH-451:
-----------------------------

I've committed the above change in revision 1042151.

Luc,

I think that the API will be a little (c)leaner if we indeed remove from the interface the {{solve}} methods that lack the "maxEval" parameter (as you suggested in the ML). Users that want a simple call can always resort to the method in class {{UnivariateRealSolverUtils}}. There, I've put the default value at {{Integer.MAX_VALUE}} but maybe it's a bit too high ;).
Please, let me know your final word on this. In case of removal, I'll also take care of deprecating in MATH_2_X.


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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.