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.
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, and higher derivatives might be implemented by someone who does not match the precision and performance perceptions of the implementor of the base function.
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.
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. Also, many functions have multiple roots. An exhaustive search for all roots is often impossible. 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.
J.Pietschmann
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
