Hello Luc.
> [...]
> >
> > If such a fine control ("AllowedSolutions") is a desirable/necessary
> > feature, couldn't we directly add it at the level of the base class
> > (and
> > interface)? I.e. the main "solve" method would become:
> >
> > public abstract class BaseAbstractUnivariateRealSolver<FUNC extends
> > UnivariateRealFunction>
> > implements BaseUnivariateRealSolver<FUNC> {
> >
> > // ...
> >
> > public double solve(int maxEval, FUNC f,
> > double min, double max, double startValue,
> > AllowedSolutions solutionType) {
> > // Initialization.
> > setup(maxEval, f, min, max, startValue, solutionType);
> >
> > // Perform computation.
> > final double baseRoot = doSolve();
> >
> > if (solutionType == EITHER_SIDE ||
> > this instanceof BracketedUnivariateRealSolver) {
> > return baseRoot;
> > } else {
> > PegasusSolver bracketing = new PegasusSolver(relativeAccuracy,
> > absoluteAccuracy);
> > double margin = 10 * absoluteAccuracy;
> > return bracketing.solve(getMaxEvaluations() - getEvaluations(),
> > f,
> > baseRoot - margin, baseRoot + margin,
> > baseRoot, solutionType);
> > }
> > }
> > }
>
> Yes, it is a smarter solution than mine, I like it, thanks!
You are welcome. :-)
> We should be careful when documenting this method, since it allows *all*
> solvers to use the bracketing feature magically and without user help,
> even the non-bracketing ones. I hope we can explain that without causing
> headache to our users or raising question like "hey, but then what is the
> difference between bracketing and non bracketing solvers?".
I think that it boils down to having the other "solve" methods keep their
current signature and call the above with "EITHER_SIDE" as the "solutionType"
argument. Thus, if not explicitely specified in the call to "solve", the
default behaviour of the algorithm is retained.
By the way, shouldn't "EITHER_SIDE" be renamed to "ANY_SIDE"?
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
