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] replace AbstractContinuousDistribution.getSolverAbsoluteAccuracy() with AbstractContinuousDistribution.getSolver()
Date Sun, 06 Nov 2011 22:16:03 GMT
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message