commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [math] proposal for FunctionOpertor interface
Date Thu, 20 Nov 2003 03:55:31 GMT
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/commons-dev@jakarta.apache.org/msg29788.html
http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg30112.html

A discussion between Bren, J.Pietschmann and myself concerning the 
decomposer API
http://www.mail-archive.com/commons-dev@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.mail-archive.com/commons-user@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 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?
> 
> 
> 

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

Mime
View raw message