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 04:26:12 GMT
I've thought about this and I like the idea of getting some of this code 
available in the cvs for experimentation, I'm going ahead and adding it 
for others to look at and consider.

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/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?
>>
>>
>>
> 
> 
> ------------------------------------------------------------------------
> 
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message