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 Fri, 30 Oct 2009 21:11:59 GMT


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:

RealVector v =;

as opposed to this

RealVector v = UnivariateRealFunction() {
  public double value(double t) throws FunctionEvaluationException {
    return Exp.value(Negate.value(Pow2.value(t))));

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

> 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