I'd like to try to consolidate several past threads that related to this
discussion further:
Matts initial 2 threads concerning Numeric Derivatives:
http://www.mailarchive.com/commonsdev@jakarta.apache.org/msg29788.html
http://www.mailarchive.com/commonsdev@jakarta.apache.org/msg30112.html
A discussion between Bren, J.Pietschmann and myself concerning the
decomposer API
http://www.mailarchive.com/commonsdev@jakarta.apache.org/msg28772.html
A discussion with code examples that Paul Libbrecht and myself had on
the commons user list. This is specifically a generic framework approach
for constructing equations with variables, operators, constants, etc as
a set of objects such that such an approach could support
transformations to accomplish differentiation and integration, equation
solving, etc (much like Mathematica in style, something approaching a
strategy for an implementation of OpenMath:
http://www.mailarchive.com/commonsuser@jakarta.apache.org/msg04566.html
I've attached the source we were exchanging to this email
I think its important to "coordinate" some of the design ideas under
these threads into a solid approach and API for the Functor style
strategies we are discussing in these threads.
Specifically that there multiple return types in our current approaches,
sometime Objects, sometimes primitive doubles. I think we should
consolidate some of these strategies into as common a set of interfaces
as possible (and I do know this not necessarily a simple task).
For instance:
We do have a couple double primitive interfaces rolling around with very
similar design principles, some take objects as parameters, some take
arrays, some take simple double values:
o.a.c.math.util.NumericTransformer
 double transform(Object o)
o.a.c.math.analysis.UnivariateRealFunction
 double value(double d)
o.a.c.math.stat.univariate.UnivariateStatistic
 double evaluate(double[] values)
Solvers approach the same concept, but with more "configuration" methods
available in the interface:
o.a.c.math.analysis.UnivariateRealSolver
 double solve(double min, double max)
Your proposal ultimately adds another interface
 UnivariateRealFunction evaluate(UnivariateRealFunction f)
Ultimately, its the primitive/Object return types of these different
Function implementations (as well as yours below), that limits finding a
"common" interface such as that found in Functors:
http://jakarta.apache.org/commons/sandbox/functor/xref/index.html
I know this probably sounds like I'm barking up the same old tree. The
big dilemma with return type may someday be solved with j2sdk 1.5 and
generics, but until then we are dealing with an issue here. Primitives
are very efficient to return, but very nongeneric and as nonObjects
they create a large design bottleneck in the whole Functional object
mode we are approaching.
On another note, I would like to get all the examples we have been
throwing around into an experimental cvs tree which we can build against
similar in fashion to the test directory
math/src/java/o.a.c.math...
math/src/test/o.a.c.math...
math/src/experimental/o.a.c.math...
Developers who use Eclipse would find it simple to add the directory to
their sources to experiment within against the java and test
directories, we could add some targets into an alternate ant build to
allow those who like to work with Ant or Maven to easily build that
tree. Others I'm sure will be able to modify their own environments to
work with it. Thoughts?
Mark
Matt Cliff wrote:
> in reference to bug #24717  an enhancement to add a numerical deriviate
> operator, I wanted to get some feedback on the following approach
>
> Basically I am thinking of introducing a new interface as follows:
>
> 
> public interface FunctionOperator {
>
>
> /**
> * Evaluate the Function Operator for a given real single variable
> function.
> *
> * @param f the function which should be evaluated
> * @return the resultant function
> * @throws MathException if the function couldn't be evaluated
> */
> public UnivariateRealFunction evaluate(UnivariateRealFunction f)
> throws MathException;
>
> }
> 
>
> In addition I also have a class something like
> 
> public class DerivativeOperatorFactory() {
> public static DerivativeOperatorFactory newInstance() {...}
>
> public FunctionOperator getDefaultDerivativeOperator() {...}
>
> public FunctionOperator getCenteredDifferenceDerivativeOperator()
> {...}
>
> .... // and so on for other implementations of numerical deriv's
> }
> 
>
>
> In order to use this in client code it would look like
>
> 
>
> UnivariateRealFunction f = new SomeUserDefinedFunction();
> FunctionOperator derivative =
> DerivativeOperatorFactory.newInstance().getDefaultDerivativeOperator();
>
> UnivariateRealFunction g = derivative.evaluate( f );
>
> // to obtain the value of f'(0.0) use
> double fprime_at_0 = g.value( 0.0 );
>
> 
>
> so f'(x) = g(x) for each value of x.
>
> as was mentioned in an earlier thread higher derivatives can be obtained
> by using the FunctionOperator twice.
>
>
> any thoughts or comments on this approach?
>
>
>

Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
