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. Yes. > >> 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... OK. > > 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, Luc > > > Regards, > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
