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 Sat, 31 Oct 2009 21:06:59 GMT

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

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

bq. I agree with Luc on limiting abstract infrastructure to what we have practical use cases
for. See "guiding principles" on the home page.

Maybe I misunderstood the uses for this library - when I see classes like "Field<T>"
and "FeildElement<T>" in the main o.a.c.math package, I assumed that building in generic
mathematical actions is desired as well as simply a toolbox of specific use-cases.

bq. One thing to consider is do we require that Composable functions be total and finite-valued.
If not, documenting and debugging NaN/Inf/Exceptions could be tricky for users.

I wondered the same thing: why does UnivariateRealFunction throw a checked exception, forcing
users to deal with it on every call?  Could this not be a (specific subclass of) RuntimeException,
and let users who need to deal with it deal with it, and other people can ignore it, knowing
that they have safe/entire functions, or that they will handle the NaN/Inf cases on their
own.

bq. Also, do we require that composition be only "with" ComposableFunctions?

I didn't think that was necessary, no.  The implementation of preCompose, postCompose, plus,
minus, times, divide, scale don't require that the argument be ComposableFunction, but they
will return an anonymous subclass of ComposableFunction, which has the side benefit of trivially
allowing you to turn a non-composable function (Luc's HeatSensor) into a composable one, with
ComposableFunction composableHeatSensorFunction = Identity.postCompose(heatSensor);  (this
could just as easily be implemented with a delgating function as well, of course).

bq. I guess another thing to think about is inverses.

How would you implement this, in general?

> 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