Hello. > >> 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.
OK, I'll create a JIRA issue. > > > > Finally, the solvers and the optimizers should have similar behaviours; we > > should make the same changes in both set of classes. > > Yes. And for this one too. > [...] > > > > > 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. But... in 2.2, the new code (contructors with 2 tolerances as parameters) does not exist, and in 3.0, the old code (constructor with a "maxIterations" and tolerance parameters) does not exist. So indeed, this former constructor should be deprecated (in 2.2) but there is nothing to remove (in 3.0). And still, code that uses the old interface with the new library will fail, as you described. [Or I didn't understand what the problem is, or the proposed solution...] Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
