You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Gilles (JIRA)" <ji...@apache.org> on 2011/02/24 17:05:45 UTC
[jira] Created: (MATH-535) Closing the loop in function objects
Closing the loop in function objects
------------------------------------
Key: MATH-535
URL: https://issues.apache.org/jira/browse/MATH-535
Project: Commons Math
Issue Type: New Feature
Reporter: Gilles
Priority: Minor
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: http://www.atlassian.com/software/jira
[jira] Closed: (MATH-535) Closing the loop in function objects
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gilles closed MATH-535.
-----------------------
Resolution: Not A Problem
> Closing the loop in function objects
> ------------------------------------
>
> Key: MATH-535
> URL: https://issues.apache.org/jira/browse/MATH-535
> 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: http://www.atlassian.com/software/jira
[jira] Commented: (MATH-535) Closing the loop in function objects
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000601#comment-13000601 ]
Gilles commented on MATH-535:
-----------------------------
In the end, I don't think that these methods are useful. Within the current code, all they would do is hide a constructor call. In the case of "createParametric()" the returned object would not be very interesting: e.g. a caller that would treat it as a "ParametricUnivariateRealFunction" would not know how many parameters are needed to call "value(double x, double[] param)".
So, unless someone sees a real usefulness, I'm going to close this issue.
> Closing the loop in function objects
> ------------------------------------
>
> Key: MATH-535
> URL: https://issues.apache.org/jira/browse/MATH-535
> 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: http://www.atlassian.com/software/jira
[jira] Commented: (MATH-535) Closing the loop in function objects
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998943#comment-12998943 ]
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 methods.
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: https://issues.apache.org/jira/browse/MATH-535
> 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: http://www.atlassian.com/software/jira