[
https://issues.apache.org/jira/browse/MATH-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772090#action_12772090
]
Jake Mannix commented on MATH-313:
----------------------------------
Ok, if people are typically out there using commons-math and implementing all
the interfaces in the analysis package in classes which have totally separate
functionalities and class hierarchies like you're describing (which is what I
was questioning whether it happens - I misunderstood you to be talking about
the Solvers themselves), then regardless of whether this is good design or not,
the interface should be left alone, and can be, even while allowing this
functionality for "throwaway functions".
I was thinking of the interface as primarily for lightweight callback-like
functions, which are effectively operated _with_, not operated _on_, which is
why having the ability to make method calls like:
{code}
RealVector v = w.map(Exp.preCompose(Negate.preCompose(Pow2)));
{code}
as opposed to this
{code}
RealVector v = w.map(new UnivariateRealFunction() {
public double value(double t) throws FunctionEvaluationException {
return Exp.value(Negate.value(Pow2.value(t))));
});
{code}
and instead puts the same boilerplate for composing functions, adding them,
subtracting them, multiplying them and scaling them away in an abstract class
instead of littering user code.
So like I said - knowing that these interfaces were designed to be used as
providing APIs for implementers to toss their own class instances into solvers
and other c-math algorithms (which I did not know, just looking at the set of
interfaces themselves), it's easy enough to leave the interface alone and make
a new one which extends from it which is designed for "pure functions on Real
numbers", that really are meant to be nothing *other* than a function. Maybe
that's a better name for this interface: RealPureFunction. But perhaps it
should *only* be an abstract class then, since you don't expect anyone to be
implmeneting their own composition methods.
> Functions could be more object-oriented without losing any power.
> -----------------------------------------------------------------
>
> Key: MATH-313
> URL: https://issues.apache.org/jira/browse/MATH-313
> Project: Commons Math
> Issue Type: New Feature
> Affects Versions: 2.0
> Environment: all
> Reporter: Jake Mannix
> Fix For: 2.1
>
>
> UnivariateRealFunction, for example, is a map from R to R. The set of such
> functions has tons and tons of structure: in addition to being an algebra,
> equipped with +,-,*, and scaling by constants, it maps the same space into
> itself, so it is composable, both pre and post.
> I'd propose we add:
> {code}
> UnivariateRealFunction plus(UnivariateRealFunction other);
> UnivariateRealFunction minus(UnivariateRealFunction other);
> UnivariateRealFunction times(UnivariateRealFunction other);
> UnivariateRealFunction times(double scale);
> UnivariateRealFunction preCompose(UnivariateRealFunction other);
> UnivariateRealFunction postCompose(UnivariateRealFunction other);
> {code}
> to the interface, and then implement them in an
> AbstractUnivariateRealFunction base class. No implementer would need to
> notice, other than switching to extend this class rather than implement
> UnivariateRealFunction.
> Many people don't need or use this, but... it makes for some powerfully easy
> code:
> {code}UnivariateRealFunction gaussian =
> Exp.preCompose(Negate.preCompose(Pow2));{code}
> which is even nicer when done anonymously passing into a map/collect method
> (a la MATH-312).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
