On Sun, Nov 06, 2011 at 09:28:48AM -0700, Phil Steitz wrote: > On 11/6/11 7:59 AM, Gilles Sadowski wrote: > > On Sun, Nov 06, 2011 at 12:24:03AM -0700, Phil Steitz wrote: > >> On 11/6/11 12:18 AM, Sébastien Brisard wrote: > >>>> +1, but your observation above then leads to the question where are > >>>> you going to get this value from? There may not be a solver to read > >>>> it from. I guess the default impl in the base class could just > >>>> return BaseAbstractUnivariateRealSolver.DEFAULT_FUNCTION_VALUE_ACCURACY. > >>>> > >>>> Phil > >>>> > >>> Ah, that's one option I didn't think of. I intended to follow the same > >>> scheme as for getSolverAbsoluteAccuracy(), which returns > >>> solverAbsoluteAccuracy (private field), possibly initialized with > >>> DEFAULT_SOLVER_ABSOLUTE_ACCURACY (see AbstractContinuousDistribution). > >>> Actually, using the BaseAbstractUnivariateRealSolver default value is > >>> probably better. However, these default values are private... So maybe > >>> we will have to select reasonable default values here. > >> Ugh. I remember complaining about that (the fact that the defaults > >> were made private) for precisely this kind of reason. Have to clone > >> the value, I guess and keep it in synch with whatever Brent uses. > >> > >> Phil > >>> Sébastien > > [I did not follow all the details of this discussion; sorry if I'm slightly > > off base.] But, if somewhere some _default_ accuracy is needed to pass to a > > _default_ solver, I'd say: instantiate the solver using its _default_ > > constructor; thus, no need to chase up instance variables used further up > > the hierarchy. > > Read the post. What is being reused is the default value itself. > There may or may not be a solver instantiated.
If there is no solver, why would you want to access an instance variable of the solvers's base class? Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
