commons-issues mailing list archives

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

    [ 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.


Mime
View raw message