 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 nth derivate, they just call the getDerivate()
> > method n
> > > times, once on the original function and once on each of the
> returned
> > > functions. That way, commonmath 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, email: commonsdevunsubscribe@jakarta.apache.org
> For additional commands, email: commonsdevhelp@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 rootfinding algorithms that I am aware of that
have been coded for commonsmath 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 noninteger orders of derivatives.
Al
=====
Albert Davidson Chou
Get answers to Mac questions at http://www.MacMgrs.org/ .
__________________________________
Do you Yahoo!?
Yahoo! Calendar  Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
