commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] max evaluations in new root solvers
Date Wed, 01 Dec 2010 21:00:27 GMT
Le 01/12/2010 20:31, Gilles Sadowski a écrit :
> Hi.

Hi Gilles,

>> In the recent changes for 3.0, the solvers now have a setting for a
>> maximal number of function evaluations rather than a max number of
>> iterations. This number cannot be specified at construction time, but
>> only using a setMaxEvaluations() method declared in the
>> BaseUnivariateRealSolver interface.
>> Wouldn't it be wise to allow this setting ?
> If it would be specified in the constructors, then I would remove the setter
> because I don't think that it is wise to have more than one way to change
> some setting.
> Now the question is whether the number of evaluations is on the same footing
> as the tolerances. Does it make sense to fix it at creation or is it a value
> that should be modifiable, e.g. depending on the function one wants to
> solve?
> In the latter case, we could contemplate the possibility of passing that
> value to the "solve" method; after all, it is the number of allowed
> evaluations of the function object, one of the other parameters passed to
> the method.

I think this option is the best one.

> Finally, the solvers and the optimizers should have similar behaviours; we
> should make the same changes in both set of classes.


>> Also one of my coworkers was trapped by the changed signatures. Since
>> there is no constructor with one integer and one double, an existing
>> code that used the 2.X versions did provide the number of iterations and
>> the absolute tolerance. As integers are automatically promoted to double
>> when needed, his code was in fact calling a new constructor with two
>> doubles, and the first argument was considered to be a relative
>> tolerance ... Do you think we could set up some compliance constructors
>> that would consider the maxIterations as a maxEvaluation (as these are
>> mainly safeguard, it should be OK for many people) and provide a default
>> relative tolerance ?
> Whatever we choose for the above, I'd rather not keep ad-hoc constructors:
> If, for example, we'd decide that it's better that the "maxEvaluations"
> parameter should come last (e.g. because a default value is used in most
> cases), then having other "old-style" constructors will tend to be messy...


> In order to avoid nasty surprises, what about having these "old"
> constructors deprecated and throw a "MathUnsupportedOperationException" in
> 3.0 and remove them in 3.x? [This is an incompatible change but the
> exception throwing will make it sure that nobody can actually depend on this
> constructor.]

No, we can deprecate them as early as 2.2 and remove them in 3.0, just
as the other changes we already did.

best regards,

> Regards,
> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message