commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [math] puzzled by generics in root solvers
Date Tue, 05 Jul 2011 21:34:44 GMT
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message