[
https://issues.apache.org/jira/browse/MATH-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771695#action_12771695
]
Jake Mannix commented on MATH-313:
----------------------------------
I can totally see that many people would not care about composing the function
with other functions, but just as many people don't care about doing anything
with vectors other than adding them or dot()'ing them doesn't mean that giving
them the ability to do so isn't a good thing, right? From a design
perspective, what are the real cases where someone has a class which implements
UnivariateRealFunction, but also extends some other class? You mentioned
solvers or root finders, but all the solvers take functions which are passed
into them, so they're ok, these could be subclasses of
AbstractUnivariateRealFunction very easily. And even functions which go from
one domain to another can be composed with functions which go from the target
domain to itself.
But if people really are used to the interface living the way it is, that's
fine, in this case (unlike in the RealVector case) it's easy to extend the
interface, so I'll draw up a patch to do it in this non-invasive way.
> 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.
