On Sun, Nov 06, 2011 at 10:47:31AM -0700, Phil Steitz wrote: > On 11/6/11 10:24 AM, Gilles Sadowski wrote: > > 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? > > What the code could use is access to the *default* function value > accuracy, essentially to reuse the default value. This is a reason > that it is good to expose default configuration properties as public > constants. What the code is doing is checking to see if the domain > upper / lower bounds return values under the function that are > within the default function value accuracy (logically a property of > the distribution at this point). If this test succeeds, one of the > domain endpoints will be returned and no solver will be > instantiated. It would be nice from a consistency perspective to > use the default that BaseAbstractUnivariateRealSolver defines.
On the one hand you say "[...] default function value accuracy (logically a property of the distribution at this point) [...]" On the other: "It would be nice from a consistency perspective to use the default that BaseAbstractUnivariateRealSolver defines." I don't see why it is logical that the default value in one context would be a good default in another. [I'm not even sure that it is a good thing to provide defaults for the solvers.]. >From my point-of-view, "BaseAbstractUnivariateRealSolver" is an implementation detail which shouldn't even be known from a user's perspective. The defaults there were defined only to allow the subclasses to be "sloppy" in that they don't have to define 2 out of the 3 "DEFAULT...", on the assumption (which may not always be correct) that for a solver instantiated with the no-arg constructor, the algorithm's stopping criterion that will matter is the "DEFAULT_ABSOLUTE_ACCURACY" and that one *is* indeed redefined in each solver. And again, I don't think that it is good that this default exists because it makes it much less obvious that the criterion might in fact not satisfy the user's actual need. Of course, we have to balance that with ease of uses in some cases... Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
