commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Al Chou <hotfusion...@yahoo.com>
Subject Re: [math] Priority
Date Fri, 30 May 2003 20:36:01 GMT
--- brent@worden.org wrote:
> On Fri, 30 May 2003 20:14:23 +0200, "J.Pietschmann" wrote:
> > Brent Worden wrote:
> > > I agree.  The this looks like a very solid framework.  One
> > suggestion I
> > > would like to make, is instead of a both a firstDirevative and
> > > secondDerivate method to evaluate the derivates.  Create a single
> > > getDerivate() method that returns a UnivariateRealFunction.  That
> > way if a
> > > user needs the n-th derivate, they just call the getDerivate()
> > method n
> > > times, once on the original function and once on each of the
> returned
> > > functions.  That way, common-math supports creating whatever degree
> > derivate a
> > > method might need without ever having to change the framework.  We
> > provide
> > > the maximum amout of derivate creation support to the user while
> > providing
> > > us with the minimual amount of maintenance.
> > 
> > Given that numerical algorithms try to avoid derivatives
> > for a number of reasons, a generic method to calculate
> > potentially arbitrary  derivatives seems to be overkill.
> > In fact, only very few methods even use a second derivative.
> 
> Just because we the creators of the framework see no need for higher
> order derivates, the end users, whose needs no one can fully
> enumerate, may have a quite reasonable use for them.  Your approach
> limits them to the 2nd derivate with no easy means a creating anything
> higher.  My approach doesn't limit the end user and gives them the
> flexibility to create any derivate they feel they need.
> 
> > 
> > Furthermore, the implementor of the function should know best
> > how the derivatives are calculated. Note that the contract
> > allows for numerical derivatives (although this is discouraged).
> > If a function object is returned, implementation is decoupled,
> 
> How are they decoupled.  If you create a function, you control the
> implementation for creating the derivative function object and is
> directly coupled to your object.  The implementor, you, is in control
> of all details of the function and its derivate.
> 
> > and higher derivatives might be implemented by someone who
> > does not match the precision and performance perceptions of
> > the implementor of the base function.
> 
> Since the same implementor is in control of both the function and its
> derivate that is fault of that one implementor.  Furthermore, why
> should we care?  If the user wants to create a function with less or
> more precision or performance, whose to stop them?  Your approach
> can't prevent it and it might be all the precision/performance they
> need.
> 
> > 
> > I'd like to keep it all in one object for this reasons.
> > I know this may seem to be a bit inconvenient for people who
> > want to find a zero of a derivative of a function they just
> > see lying around, but you definitely don't want to solve a
> > numerical derivative for a root, you'll just get garbage.
> 
> Again, you're pigeonholing the needs of the user.  The user might have
> needs we can't possibly anticipate.  That's the exactly reason we
> should make creating derivatives convenient and easy for the user.  We
> shouldn't take the arrogant position that we know best and prohibit
> users from doing the things they want to do.
> 
> > > Why not allow the user to supply any number of initial values and
> > design the
> > > solvers to compensate as best they can when not enough values are
> > provided.
> > > Each algorithm has criteria about the initial values that must be
> > met before
> > > root finding can be attempted.  If the user provided initial values
> > do not
> > > satisfy the criteria, the solver should first attempt to morph the
> > initial
> > > values into a set of values that do satisfy the criteria.  If this
> > can not
> > > be accomplish, then the solver would raise an exception.  This
> would
> > take
> > > away some of the user's responsibility of knowing how these
> > algorithms
> > > actually work and place it on us to create more robust components.
> > 
> > The user should have some rough ideas of the interval of the root.
> > It could be quite a large interval, but then the solver may complain.
> > There is no "best" algorithm, which can take arbitrary functions
> > and start values and produce a root with a reasonable amount of
> > work.
> 
> I never said anything about a best algorithm.  What i did say is every
> solver should take an arbitrary function and start value(s) and make
> its best effort to return a root.  If that means generating starting
> values, the solver should have the intelligence to do such a thing.
> 
> > Also, many functions have multiple roots. An exhaustive search for
> > all roots is often impossible.
> 
> When did I introduce finding all roots into this discussion?
> 
> > Therefore, the interval is mostly to
> > prevent the solver from finding a root outside of the domain of
> > interest for the user. There is no way to get the user's domain of
> > interest without explicit input.
> 
> Why can't the domain of interest and explicit input be a single value?
>  That's exactly how I did the CDF stuff using a root finding method
> which needs a bracket and it worked fine.  And it's a generic process
> that could be incorporated into all the solvers.
> 
> Brent Worden
> http://www.brent.worden.org/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


It seems to me that typical usage of the package will be (in pseudocode):

findRoot( f, x0, x1 ) ;

I personally want to be able to specify just a function and a region of
interest (no guarantee it brackets a root) and ask for a root, with an
indication if it turns out no root is found.  I think we would unnecessarily
complicate our first version of the interface by introducing the concept of
derivatives, which I hazard to guess most of the users of this package would
not be able to specify.  Of the root-finding algorithms that I am aware of that
have been coded for commons-math so far (viz., bisection, Brent's method,
Ridders' method), none require evaluation of a function's derivatives, so why
not leave it at that for now, as Phil said?  We will hear from those more
advanced users who want more explicit control -- if any such exist -- soon
enough after release of the package, and we can address their needs then.


To follow the derivative thread a step anyway, I would prefer to add a second
parameter to the derivative method, which is the order of the derivative, e.g.,

getDerivative( f, n ) ;

That way only one method call would be required on the user's part to get
whatever order derivative they want, rather than having to do n calls to
getDerivative( f ) explicitly.  Also (and I don't see any immediate use for
it), such an interface would allow for non-integer orders of derivatives.



Al

=====
Albert Davidson Chou

    Get answers to Mac questions at http://www.Mac-Mgrs.org/ .

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message