http://cvs.apache.org/viewcvs/jakarta-commons/math/src/experimental
This directory has some code from this discussion, it will not get compiled into the regular build process or future distributions. We can work on an ant script to do this if others think it neccessary.
-Mark
Mark R. Diggory wrote:
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.mail-archive.com/[EMAIL PROTECTED]/msg29788.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg30112.html
A discussion between Bren, J.Pietschmann and myself concerning the decomposer API
http://www.mail-archive.com/[EMAIL PROTECTED]/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.mail-archive.com/[EMAIL PROTECTED]/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 non-generic and as non-Objects 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?
------------------------------------------------------------------------
This body part will be downloaded on demand.
-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
