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