Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <985754492.1256854199495.JavaMail.jira@brutus>
Date: Thu, 29 Oct 2009 22:09:59 +0000 (UTC)
From: "Jake Mannix (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (MATH-313) Functions could be more
 object-oriented without losing any power.
In-Reply-To: <2066637627.1256803739367.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/MATH-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12771651#action_12771651 ] 

Jake Mannix commented on MATH-313:
----------------------------------

At least within Commons-math, nowhere do people have complex classes which implement UnivariateRealFunction, they have static inner classes (or anonymous inner classes) which do the work for them, and I was able to replace all such occurences with AbstractUnivariateRealFunction without much trouble.  I've already got a patch which easily takes care of this throughout all of commons-math.

Are you saying that people outside of commons-math, who are using it, have their solver classes implement a function interface as well?


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