commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luc Maisonobe (JIRA)" <>
Subject [jira] Commented: (MATH-535) Closing the loop in function objects
Date Thu, 24 Feb 2011 17:22:38 GMT


Luc Maisonobe commented on MATH-535:

Yes, the second proposal is far better than the first one.
The UnivariateRealFunction is a user interface. Users must implement it for example to solve
roots. Such user interface should be as simple as possible and should not define additional
In many case I know, such functions already extends user class (i.e. we have code like MyClass
extends SuperClass implements UnivariateRealFunction). So in such cases an abstract class
with a default implementation does not help, users would be forced to implement the additional
method even if they don't use it and the solver don't use it either.

> Closing the loop in function objects
> ------------------------------------
>                 Key: MATH-535
>                 URL:
>             Project: Commons Math
>          Issue Type: New Feature
>            Reporter: Gilles
>            Priority: Minor
>              Labels: api-change
>             Fix For: 3.0
> Some function classes (in package "analysis.function") now contains a "Parametric" inner
class that provides a parametric version of the function represented by the enclosing class.
> # We could enhance the "UnivariateRealFunction" interface to contain:
> {noformat}
>   public ParametricUnivariateRealFunction createParametricFunction();
> {noformat}
> which, e.g. for the "Gaussian" concrete class, would translate to:
> {noformat}
>   public Gaussian.Parametric createParametricFunction() {
>     return new Gaussian.Parametric();
>   }
> {noformat}
> # We could enhance the "ParametricUnivariateRealFunction" interface to contain:
> {noformat}
>   public UnivariateRealFunction createFunction(double[] param);
> {noformat}
> which, in "Gaussian.Parametric", would translate to:
> {noformat}
>   public Gaussian createFunction(double[] param) {
>     validateParameters(param);
>     return new Gaussian(param[0], param[1], param[2]);
>   }
> {noformat}
> In both cases, it would allow programming against interfaces.
> For the first case, not all current implementations of "UnivariateRealFunction" provide
a "Parametric" version (and for most there are no parameters). So either we create a new "AbstractUnivariateRealFunction"
that provides a default implementation of "createParametricFunction" (throwing an exception)
and make all current function classes extends this one, or we create a new interface (something
like "ParametricFactory") that declares the new "createParametricFunction()" and add the "implements
ParametricFactory" clause to any class that provides a parametric version.
> I think that the latter is the cleanest. Or is there still another possibility?

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message