You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Matt Cliff <ma...@mattcliff.com> on 2003/11/19 16:29:01 UTC
[math] proposal for FunctionOpertor interface
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?
--
Matt Cliff
Cliff Consulting
303.757.4912
720.280.6324 (c)
The label said install Windows 98 or better so I installed Linux.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] proposal for FunctionOpertor interface
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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
Re: [math] proposal for FunctionOpertor interface
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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