--- [EMAIL PROTECTED] wrote:
On Fri, 30 May 2003 20:14:23 +0200, "J.Pietschmann" wrote:
Brent Worden wrote:returned
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
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.
wouldWhy 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
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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.
+1
We are really talking about two things here -- rootfinding and representing R->R functions. The first requries a bit of the second, but not much -- not even first derivatives if we skip Newton. I would prefer to focus on getting the rootfinding framework in place and postpone (or continue asynchronously ;-) what promises to be a lively discussion of how we should be thinking about functions. Note that R->R is just the beginning ...
FWIW, I think that it will be best for both us and our users if we try to stay as close as possible to the applications that we are working with and bring in mathematical abstractions only as we really need them.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
