commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jake Mannix (JIRA)" <>
Subject [jira] Commented: (MATH-313) Functions could be more object-oriented without losing any power.
Date Thu, 29 Oct 2009 22:51:59 GMT


Jake Mannix commented on MATH-313:

Of course, the easy alternative, if we really want to keep this interface the way it is, is
to extend it with an interface like "AlgebraicallyComposableUnivariateRealFunction" (with
a better name), which does have an abstract implementation (although we really don't want
AbstractAlgebraicallyComposalbeUnivariateRealFunction as a class name!!!), and people can
have both choices, and in fact, a concrete impl - DelegatingAlgebraicallyComposableUnivariateRealFunction
- could be implemented by taking a UnivariateRealFunction as a constructor arg, and delegates
value() to the delegate, and this way you can easily transition between using Functions as
genuine objects, and as an interface on your more complex object as well, and you have the
best of both worlds.

> Functions could be more object-oriented without losing any power.
> -----------------------------------------------------------------
>                 Key: MATH-313
>                 URL:
>             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
> 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.

View raw message