commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] max evaluations in new root solvers
Date Wed, 01 Dec 2010 19:31:19 GMT

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

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


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

View raw message